RE: [xml-dev] Speed in Languages and Browser Architectures

[<Peter.Kirkham@generaldynamics.uk.com>]

Whether C (as compiled by MS Visual C++ 6.0) is faster than Java (as
implemented in Sun's JRE version 1.6) depends more on whether you use
Java in an object-oriented manner or a Fortran-esqe manner. If you're
only operating on arrays of numbers, such as in the SciMark tests, or
many 3D operations, there's no speed difference C to Java [
http://blogs.sun.com/dagastine/entry/java_is_faster_than_c ]. More
modern C compilers (VS2005, g++ 4) create faster C programs.

Of course many Java programmers don't program Java as though it were C,
and the lack of 'const' or any more advanced memory write-locking
techniques in Java means it often has to copy arrays for safety, so it
suffers in the many real world uses.

Comparing C to C++ depends whether you are writing safe, portable C++
and using stl containers (sometimes only half the speed of C in tight
loops) or using processor architecture specific SIMD intrinsics and
direct pointers for arrays (for SSE2, up to twice the speed of C for
doubles, four times for floats, 16 times for octets, depending on degree
of parallelisation available in the algorithm and the capabilities of
the target architecture). 

Many of the differences between OSes are now cosmetic - so you have to
rewrite your front end whatever language you're using, but any
algorithmic code will probably be compatible for the same processor
architecture and different standard library implementations. If you're
not using the same processor architecture, then intrinsics need to
change [
http://developer.apple.com/hardwaredrivers/ve/sse.html#Translation ]. If
you have appropriate unit tests and text processing tools, that sort of
change is not anyway near as hard as getting a Java app to look right on
both OS X and Vista.

Currently, the tamarin project [
http://www.mozilla.org/projects/tamarin/ ] is using on-the-fly
compilation and type annotation to improve performance of JavaScript.
This trades some of the advantages of Variant types in rapid development
for a simple mechanism to improve performance. It's still not
competitive with VC++6.0/Java for speed - its goal is to make JS ten
times faster, not a thousand.

Projects such as Self indicate that it is possible to use HotSpot-like
on-the-fly compilation for dynamically typed languages [
http://www.cs.ucsb.edu/~urs/oocsb/papers/tapos96.shtml ]; if you had a
runtime for dynamically typed languages which used such techniques to
generate SIMD, cache line optimised code, it should be competitive with
C or even Fortran, even when using a more modern compiler which also has
parallel optimisations. It may be that the dynamic extensions to the JVM
will allow this, but I suspect the granularity of its object model will
limit its optimisations - given f(x)=>x+1, g(x)=>x+1, it can't optimise
f(g(x)) to \(x)=>x+2, or a loop using f(0..9) to one using [1..10]. 


Pete


-----Original Message-----
From: Tei [mailto:oscar.vives@gmail.com] 

If you really need raw speed C or C++ will be always faster than Java.
But will be even more expensive than Java, because you need to rewrite
code for different OS.

Theres also stuff, like the Variant type, usefull to make code cheaper,
but slower.
--


This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof.  General Dynamics United Kingdom Limited, Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in England and Wales No: 1911653.