RE: Relative Speeds of XSL Engines Java vs. C++

[Simon Waddington <si...@viafone.com>]

>IMO this is an overstatement. A similar data manipulation algorithm
implemented
>in Java cannot be faster than the equivalent one in C++. The two years of
Java
>development cannot overcome the 15+ years of C/C++ compilation
optimizations.
>The two language runtime and compilation models are very different and Java
>cannot be faster than C++ for writing normal algorithms.

This is definitely heading down the road of advocacy and far away from
Cocoon but "cannot" is a very strong and black & white word to use.

Technological advances have shown over and over again that new advancements
can often make an overnight transformation to the playing field, or they can
start with initially lower "performance" and overtake existing technologies
and leave them in the dust.  Read the book "The innovators dilemma". 

Anyway, specially about Java vs. C++.  When you look at the latest JIT
compilers and technologies like the HotSpot VM it is easy to see how any one
simple, non-object oriented piece of code could in theory, if not in
practice be executed just as efficiently (admittedly ignoring overhead of
runtime compilation) by a Java VM as C++ or C compiled code.  

If you look inside HotSpot JVM you will find a compiler that is built on the
shoulders of all previous compilation technology with the added advantage of
*dynamic* runtime optimizations when required.  I had the pleasure to meet
and talk with some of HotSpot's designers and believe me they are very
smart, established engineers with years of experience in compiler technology
and every bit as state of the art as other compiler people I've ever talked
to at other pure "compiler" companies. 

So what I'm saying is you should be so black and white about dismissing Java
capabilities.  You should definitely consider that 

a) there is a great deal of variation in all compiler capabilities, not only
between companies producing them, but across processors and processor
variants they support.
b) a great deal of C/C++ performance tweaking requires some very intensive
analysis of code performance and playing with optimizer settings.
c) whatever system you design you always either have to rely on someone
else's code or write everything from the ground up (even to the OS level!)

The reality of a) is your mileage may vary.  If you have a great library in
C++ and you want to change compiler toolchain or even compiler options to
suit your needs you'll have to go get the source code.  Java lets you just
move the bytecodes and let the JVM do its job. 

The reality of b) is that few people ever bother to do it unless they are
extremely focused on performance - like graphics processing, game writing,
hardcode number crunching, or implementing embedded or other systems with
"hard" real-time scheduling constraints that can only be met by squeezing
every last drop of performance out of the processor (real-time is actually
my background area).  If you think about it that's probably a very small
percentage of all coding that is done - I'd be surprised if more than 1% of
all software developers fall into this category at the moment.

Because of this for a broader, more representative view you should compare
most used compilers, with typically optimization settings, average levels of
code quality and algorithm design and then see how your systems perform.

You could find many interesting results like your program is I/O bound,
memory bound, or system level code bound.  In those cases speed of your Java
VM or C++ compiler quality will have little effect on performance and both
could effectively as fast.  Similarly you may find that it is far far easier
to build a scalable architecture using the masses of existing Java APIs and
implementations that are out there to use and re-use, and solve performance
problems by throwing extra machines at it.  Time to market, ease of
development and scalability are extremely important for large projects.  You
may also find that with Java its far easier to move to a new platform, be it
the latest Intel processor, a better OS, or new machine with lots of
processors that can eat up all your multi-threaded Java code (hmmm, just how
many people do you know that can build multi-threaded C++ solutions that
actually work?).

The reality of c) is that few people have the time or resources to reinvent
the wheel every time so they are relying on more and more third party code.
Java's extensive APIs have been a huge boom for software development.  The
fact that a technology like Cocoon can be developed so quickly, to such
quality and functionality and worked on effectively by so many developers is
a great tribute to Java.  I'm not dismissing other open source collaborative
efforts like GNU, Linux, Apache etc. I'm just saying that Java can and is
delivering great things and enabling all kinds of new and interesting work
on the back of previous technologies.  Its amazing to see so much reuse and
bootstrapping of new ideas for a language so "young" and apparently as many
people seem to think, slow and ill equipped for "serious" development.


I recently interviewed an engineer from a company that was diverting almost
its entire engineering staff to recode their product in C++ to gain what
they hoped was a 2X performance increase.  That was probably going to cost
them several million dollars in engineering costs, and put them
significantly behind their competitors due to the defocusing of their
effort.  I asked the engineer if they had ever considered a scalable
architecture that would allow them to just utilize twice as much processing
power for maybe an extra $10K or so?  Guess what, they hadn't.  Their new
C++ implementation wasn't even going to be scalable.  He went away thinking
what a great idea that might be...

You may argue that if they'd designed a scalable architecture in C++ from
the start they wouldn't have to waste any money or time.  However ask
yourself how many people you know that could right that kind of system in
C++ and how long it would take, not counting the amount of time it would
take to find the quality C++ coders you need.  Most C++ enabled resumes you
find are truly Microsoft Visual C++ engineers who've only ever tackled GUI
design issues.   Basically I believe that "the problem with C++" is its an
inherently harder and more complicated task to implement good object
oriented architectures in C++ than it is in Java.  By good I mean ones that
have few latent bugs (like memory leaks or concurrency problems), are easy
to test, can be scaled easily, and have a good chance of being reused and
built upon by future developments.  Hence there will always be a bigger pool
of engineers to build Java solutions, and it will always be easier to throw
more CPU at performance issues in Java systems than try to build the
equivalent system in C++.

So it all down to practicalities - I may be able to find a really great
compiler, some really great C++ engineers and designers who know C++
overhead issues inside out, and who aren't afraid to look at assembly level
code generation issues when they need to optimize the code (and pray they
don't have to interface with anyone else's unoptimized code), but then again
I probably wont be able to or wont have the time to look for them.

Please note that I am not proclaiming myself to be an "expert", my opinions
are based on 15+ years of software development of compilers and toolchains,
CASE tools, GUIs, real-time system code, embedded Java VMs and more recently
based Java systems.  This has been in companies of all sizes and in all
kinds of languages from C, C++, Lisp, Ada, Pascal, Prolog, Java, Occam,
assembly code and damn it, even Basic!  While I've occasionally been
adversarial in this email please realize that my opinions are not black and
white or to be taken as a dogma that I insist you agree with.  

I only urge people to consider the wider picture of all software engineering
issues before focusing on a very specific issue like performance or C++ vs.
Java.  If C++ vs. Java was all about performance its pretty clear that Java
would never have got off the ground or probably never ever been conceived
of.

Simon

Kill this thread (was: Relative Speeds of XSL Engines Java vs. C++)

[Kirk Woerner <ki...@stoneseeker.com>]

Ridiculously off topic no?

> -----Original Message-----
> From: Simon Waddington [mailto:simon@viafone.com]
> Sent: Tuesday, February 06, 2001 3:52 PM
> To: 'cocoon-users@xml.apache.org'
> Subject: RE: Relative Speeds of XSL Engines Java vs. C++
>
>
> >IMO this is an overstatement. A similar data manipulation algorithm
> implemented
> >in Java cannot be faster than the equivalent one in C++. The two years of
> Java
> >development cannot overcome the 15+ years of C/C++ compilation
> optimizations.
> >The two language runtime and compilation models are very
> different and Java
> >cannot be faster than C++ for writing normal algorithms.
>
> This is definitely heading down the road of advocacy and far away from
> Cocoon but "cannot" is a very strong and black & white word to use.
>
> Technological advances have shown over and over again that new
> advancements
> can often make an overnight transformation to the playing field,
> or they can
> start with initially lower "performance" and overtake existing
> technologies
> and leave them in the dust.  Read the book "The innovators dilemma".
>
> Anyway, specially about Java vs. C++.  When you look at the latest JIT
> compilers and technologies like the HotSpot VM it is easy to see
> how any one
> simple, non-object oriented piece of code could in theory, if not in
> practice be executed just as efficiently (admittedly ignoring overhead of
> runtime compilation) by a Java VM as C++ or C compiled code.
>
> If you look inside HotSpot JVM you will find a compiler that is
> built on the
> shoulders of all previous compilation technology with the added
> advantage of
> *dynamic* runtime optimizations when required.  I had the pleasure to meet
> and talk with some of HotSpot's designers and believe me they are very
> smart, established engineers with years of experience in compiler
> technology
> and every bit as state of the art as other compiler people I've
> ever talked
> to at other pure "compiler" companies.
>
> So what I'm saying is you should be so black and white about
> dismissing Java
> capabilities.  You should definitely consider that
>
> a) there is a great deal of variation in all compiler
> capabilities, not only
> between companies producing them, but across processors and processor
> variants they support.
> b) a great deal of C/C++ performance tweaking requires some very intensive
> analysis of code performance and playing with optimizer settings.
> c) whatever system you design you always either have to rely on someone
> else's code or write everything from the ground up (even to the OS level!)
>
> The reality of a) is your mileage may vary.  If you have a great
> library in
> C++ and you want to change compiler toolchain or even compiler options to
> suit your needs you'll have to go get the source code.  Java lets you just
> move the bytecodes and let the JVM do its job.
>
> The reality of b) is that few people ever bother to do it unless they are
> extremely focused on performance - like graphics processing, game writing,
> hardcode number crunching, or implementing embedded or other systems with
> "hard" real-time scheduling constraints that can only be met by squeezing
> every last drop of performance out of the processor (real-time is actually
> my background area).  If you think about it that's probably a very small
> percentage of all coding that is done - I'd be surprised if more
> than 1% of
> all software developers fall into this category at the moment.
>
> Because of this for a broader, more representative view you should compare
> most used compilers, with typically optimization settings,
> average levels of
> code quality and algorithm design and then see how your systems perform.
>
> You could find many interesting results like your program is I/O bound,
> memory bound, or system level code bound.  In those cases speed
> of your Java
> VM or C++ compiler quality will have little effect on performance and both
> could effectively as fast.  Similarly you may find that it is far
> far easier
> to build a scalable architecture using the masses of existing
> Java APIs and
> implementations that are out there to use and re-use, and solve
> performance
> problems by throwing extra machines at it.  Time to market, ease of
> development and scalability are extremely important for large
> projects.  You
> may also find that with Java its far easier to move to a new
> platform, be it
> the latest Intel processor, a better OS, or new machine with lots of
> processors that can eat up all your multi-threaded Java code
> (hmmm, just how
> many people do you know that can build multi-threaded C++ solutions that
> actually work?).
>
> The reality of c) is that few people have the time or resources
> to reinvent
> the wheel every time so they are relying on more and more third
> party code.
> Java's extensive APIs have been a huge boom for software development.  The
> fact that a technology like Cocoon can be developed so quickly, to such
> quality and functionality and worked on effectively by so many
> developers is
> a great tribute to Java.  I'm not dismissing other open source
> collaborative
> efforts like GNU, Linux, Apache etc. I'm just saying that Java can and is
> delivering great things and enabling all kinds of new and interesting work
> on the back of previous technologies.  Its amazing to see so much
> reuse and
> bootstrapping of new ideas for a language so "young" and
> apparently as many
> people seem to think, slow and ill equipped for "serious" development.
>
>
> I recently interviewed an engineer from a company that was
> diverting almost
> its entire engineering staff to recode their product in C++ to gain what
> they hoped was a 2X performance increase.  That was probably going to cost
> them several million dollars in engineering costs, and put them
> significantly behind their competitors due to the defocusing of their
> effort.  I asked the engineer if they had ever considered a scalable
> architecture that would allow them to just utilize twice as much
> processing
> power for maybe an extra $10K or so?  Guess what, they hadn't.  Their new
> C++ implementation wasn't even going to be scalable.  He went
> away thinking
> what a great idea that might be...
>
> You may argue that if they'd designed a scalable architecture in C++ from
> the start they wouldn't have to waste any money or time.  However ask
> yourself how many people you know that could right that kind of system in
> C++ and how long it would take, not counting the amount of time it would
> take to find the quality C++ coders you need.  Most C++ enabled
> resumes you
> find are truly Microsoft Visual C++ engineers who've only ever tackled GUI
> design issues.   Basically I believe that "the problem with C++" is its an
> inherently harder and more complicated task to implement good object
> oriented architectures in C++ than it is in Java.  By good I mean
> ones that
> have few latent bugs (like memory leaks or concurrency problems), are easy
> to test, can be scaled easily, and have a good chance of being reused and
> built upon by future developments.  Hence there will always be a
> bigger pool
> of engineers to build Java solutions, and it will always be
> easier to throw
> more CPU at performance issues in Java systems than try to build the
> equivalent system in C++.
>
> So it all down to practicalities - I may be able to find a really great
> compiler, some really great C++ engineers and designers who know C++
> overhead issues inside out, and who aren't afraid to look at
> assembly level
> code generation issues when they need to optimize the code (and pray they
> don't have to interface with anyone else's unoptimized code), but
> then again
> I probably wont be able to or wont have the time to look for them.
>
> Please note that I am not proclaiming myself to be an "expert",
> my opinions
> are based on 15+ years of software development of compilers and
> toolchains,
> CASE tools, GUIs, real-time system code, embedded Java VMs and
> more recently
> based Java systems.  This has been in companies of all sizes and in all
> kinds of languages from C, C++, Lisp, Ada, Pascal, Prolog, Java, Occam,
> assembly code and damn it, even Basic!  While I've occasionally been
> adversarial in this email please realize that my opinions are not
> black and
> white or to be taken as a dogma that I insist you agree with.
>
> I only urge people to consider the wider picture of all software
> engineering
> issues before focusing on a very specific issue like performance
> or C++ vs.
> Java.  If C++ vs. Java was all about performance its pretty clear
> that Java
> would never have got off the ground or probably never ever been conceived
> of.
>
> Simon
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>