xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Le Hors <leh...@us.ibm.com>
Subject Re: [spinnaker] Announce
Date Mon, 10 Jul 2000 15:37:28 GMT
Now looking at a few specific points.

If this has been seen as a Sun vs IBM war it can only be because of the
way James first presented this new project. I quote:

James Duncan Davidson wrote:

> After quite a bit of
> discussion, the rest of the XML team at Sun, the people who are responsible
> for the parser that will ship in the core of future JDKs, agree as well. It
> is important to stress that we want to ship an Apache based parser in the
> JDK for all the reasons that you'd expect.

It is crystal clear that this is all about Sun, not James as individual,
despite his later claims. Just a fact.

Stefano Mazzochi wrote:

> > So far the only proof I've got is that Hotspot miserably fails on
> > Xerces. This means to me that Hotspot has a problem, not xerces.
> Bullshit. 
> I used to optmimize x86 assembly code by hand for Pentium I dual
> pipeline, then worked great for Pentium I but failed miserably with
> Pentium II machines compared to what the C compiler produced
> automatically.

Did your code work slower on the Pentium II than on the Pentium I or
x86? I doubt it. It's also my experience that in the long run your code
works faster when you let the compiler do the optimizations. But it's
beside the point here. What we are seeing with Hotspot is that it is
slower than a regular VM (with a JIT). Profiling reveals that it fails
to compile most of the code and runs most of it in interpreted mode. Not
only that, but it performs better when profiling is on!! If this isn't a
proof that something is really wrong in Hotspot I don't know what is!
Besides, if anyone (and people from Sun in particular since I expect
them to be the best experts in the matter) would help improving Xerces
performance over Hotspot it would be great!!!

Stefano Mazzochi wrote:

> > >     * However, because Xerces was heavily pre-optimized, its
> > >       extremely complex to understand and delve into. I think
> > >       that this is best reflected in that most of the bits that
> > >       go into Xerces come from IBM Cupertino.
> > 
> > Not so. What you're refering to as "IBM Cupertino" is hardly a fixed set
> > of people. We've actually had a lot of turnover and we keep getting new
> > people involved in this project all the time. This hasn't prevented any
> > of them to contribute significantly. The only reason most bits come from
> > IBM is that nobody else has comitted as many resources to this project.
> I don't give a shit about who is paying whom to do anything as long as
> what is being done is good for me. I'm happy with Xerces and I use it.
> But if somebody is not, they have all the rights in the world to do
> something about it and if the community is not open enough to listen, to
> prove their points by creating new code and let the community decide.
> This is _NOT_ a IBM vs. Sun thing and I suggest everyone on this list to
> ignore any post that go in that direction.

You're completely missing the point. My point is that James argument
that the fact that most bits come from IBM Cupertino proves that Xerces
is too complex is bogus. This has nothing to do with IBM vs Sun. Read
what I write not what you want to read.

One last point, this is hardly a matter of misplaced sensitivity. None
of the authors of the original code are still involved in this project.
Most of us have only been involved in this for a few months. I just
think there is much more value in helping to improve the current code
than starting a competing project in parallel. For one thing, I don't
think this project can afford wasting resources. Andy Clark, Jeff
Rodriguez, and Eric Ye are struggling to finish up the implementation of
XML Schemas. I'm sure they wouldn't mind any help.
This is not to say that it's wrong to make experiments on the side. This
is to me a natural way of making progress. We do that all the time. As a
matter of fact I have three checkouts of the xerces source tree in which
I keep experimenting various ideas. In one of them I've even merged some
of the code from the crimson DOM into xerces DOM.

It's just that I have more faith in evolution than revolution.
Arnaud  Le Hors - IBM Cupertino, XML Technology Group

View raw message