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>
>