GCC and Fortran eat GCJ for lunch at number crunching

[Linuxhippy]

Hi there!

I dont understand all that traffic about such a stupid content!

Java is a very great language for developing, its really safe (many of 
todays security-holes shouldnt occur in programs written in Java) and 
has also very many comfort-features.
Java was never thought to be a language for big apps such as JBuilder or 
netbeans, but I think it can do that very well!
Nobody will use Java for Numbercrunching-Software, Java wont have 
enought programming-benefits that are really needed for stupid math-stuff.

So, what I want to say in my very bad english: Java was never thought to 
be a language for topics where only speed matters.
Fortan and C are really low-level languages and shouldnt be compared to 
java/gcj, thats stupid stuff.
I've never seen anybody comparing assembler with C.
Nobody compares perl or python with C because thats absoltly not useful. 
Also if it would be possible to compile perl it'll be slower that C, of 
course.
Hmm, nobody will be so stupid to write an numbercrunching-software in 
perl!!!!

Mfg Linuxhippy

>On Thu, 2 Jan 2003, Erik Poupaert wrote:
>  
>
>>Is there any fundamental reason for gcj to be slower than equivalent
>>(garbage-collected) C++?
>>    
>>
>
>Probably, but not often 3x slower.
>
>The benchmark author used multidiensional arrays extensively in his C++
>and Java code.  Statements like
>
>        da  = a[np][0] + (a[np][1] + a[np][2] * t ) * t;
>
>work very differently in the two languages.  (Although CSE should prevent
>evaluting a[np] thrice, the array elements do not lie in contiguous
>memory, affecting spatial locality).
>
>I've also noticed GCC's register allocator struggles with large, complex
>routines like in almabench.java.  Re-running the benchmark with -fnew-ra
>on my PIII is good for about a %20 speedup.
>
>Jeff
>
>
>  
>