posted by Eugenia Loli on Tue 1st Apr 2003 11:25 UTC

"Miguel Interview, Part III"
8. How's Gnumeric development these days? How is the application holding against all these office suites available for Linux, and when it is going to be completely ported in GTK+ 2.0 as a stable release?

Miguel de Icaza: Gnumeric is being maintained by Jody Goldberg, I am no longer involved with the project.

Gnumeric has a number of unique features, and it is still one of the nicest code bases to work with.  Gnumeric's code was designed to be maintainable and clean, and this has paid off.   But Gnumeric is still far from being a drop-in replacement for Excel, although it has features that are unique to it (like the spreadsheet conversion tool) which will guarantee its continued development. 

From Ximian's perspective, we are focusing on improving Open Office as it presents a complete office suite that has the functionality and integration that users demand today.  You can see some slides of the work that Ximian has been doing on Open Office here.

Gnumeric will still have a market for smaller systems, or even for embedded situations like PDAs or whenever the engine has to be reused on special situations: Gnumeric is also very easy to modify and adapt, so its pieces can be reused in other setups. 

Answering your question about the Gtk 2 availability: I believe that Gnumeric has already been ported to Gtk 2.0, but I would have to differ to Jody on the precise answers.

9. Which part of Mono was the most difficult to implement, and which one you think you might get you some trouble in the future? How many people are in the "core team" of Mono today?

Miguel de Icaza: All of Mono has presented various challenges, and I have only hands-on experience on a few parts, but I know that various areas of Mono have proven to been challenging at times, and as such fun at times, and hard at others.

* The JIT engine is obviously non-trivial work.

* The Windows API emulation layer was required to provide matching implementations for the IO and threading subsystems on Windows for Unix.  This code is non-trivial, and its functionality not given the credit it deserves.

* The second-generation JIT is obviously non-trivial work.

* Application Domains and MarhsalByRef objects and the whole infrastructure for Remoting I know was complicated, but I could not say how much.

* Metadata handling: reflection and reflection.emit:  I know these were tricky, because they were part of our chicken-and-egg problem when initially bootstrapping the compiler.  The compiler was written in C#, and required extensive functionality from the runtime and the class libraries to be there.  Getting this working in such a short amount of time was a miracle.

* Threading and thread pools.

* The C# compiler is the part am most familiar with.  I have to say that writing a C# compiler in C# was both fun and challenging.  I wish I had more time to work on tuning the compiler speed.

It is hard to estimate how many people are in the "core".  150 developers have CVS commit access, but like every other open source project, contributors are not working full time on Mono, they come and go, depending on their spare time and their current obligations.  I would say that roughly 40 developers are actively involved on a given week in the project. This number I draw from the Mono Weekly News.

Anyways, there are plenty of fun activities in the Mono world, it is definitely the most fun project I have done, and it is also interesting because as an open source project, we get to work with the Windows developer community, a community that we have been historically isolated from.

10. I hear rumors... a new JIT for Mono, 'they' say. If this is true, why is the new JIT being developed in secret? And why the need for a new JIT?

Miguel de Icaza: I already talked about the new JIT properties and objectives before. An article with the details about the new JIT engine will be available at the time of the release.

The new JIT began as a research prototype, on a `minimally' new infrastructure that would plug into the current JIT (that is why it is internally called `mini').  And it kept growing until today's JIT, it grew out of a prototype. 

The new JIT development has never been a secret, but it has been developed internally.  It will be released when we feel that we can support it and answer questions about it.  We have already given early copies of the JIT engine to a few individuals that have been actively involved with the JIT engine.

11. How about performance? How Mono stacks up speed-wise against the .NET and dotGNU implementations?

Miguel de Icaza: It is hard to answer this question, because a complete benchmark is hard to build: it has to test raw performance, garbage collection, threading, scalability, features, modes of operations and more.

A complete benchmark suite is difficult to build, and so far, nobody has created a comprehensive one that could be used to compare it.

The JIT from Mono is obviously faster than PNet's interpreter, and the Microsoft JIT compiler is a well tuned engine that is better than Mono, something that we hope will change with our new JIT engine.

But even if we get better raw speed from code which is pre-compiled, scalability issues, thread pools, application domains and many more factors will play into competing performance wise with the Microsoft CLR.


UPDATE: The Gnumeric maintainer, Jody Goldberg, emailed us about some info regarding Gnumeric:
1) Gnumeric's distance from being a 'drop-in replacement for Excel' This is a matter of perspective. MS Excel does have features that Gnumeric lacks. However, they are not features that are necessary in most common use cases. The quality of what we do have is high. Especially the analytics (statistical tools, and worksheet functions). These implement almost a complete superset of MS Excel. We're missing 2 out of 400 odd functions in MS Excel, and have added an additional 50.

2) The projected use case for Gnumeric in 'embedded situations like PDAs'. Our target audience are spreadsheet users. Its true that Gnumeric is light and fast in comparison to OpenOffice. However, that is far from the main claim to fame. As mentioned previously our analytics are in good shape. We also have better quality support for some of MS Excel's trickier calculation mechanisms. Additionally we support things like encrypted or protected xls files.

In short we're still developing Gnumeric. For people that need an Office Suite, OpenOffice is a good choice. However, if someone is looking to use a spreadsheet, and wants easy extensibility and solid analytics, then I think Gnumeric is the way to go.

Table of contents
  1. "Miguel Interview, Part I"
  2. "Miguel Interview, Part II"
  3. "Miguel Interview, Part III"
e p (0)    55 Comment(s)

Technology White Papers

See More