Slashdot Mirror
Linux Number Crunching: Languages and Tools
ChaoticCoyote writes " You've covered some of my past forays into benchmarking, so I thought Slashdot might be interested in Linux Number Crunching: Benchmarking Compilers and Languages for ia32. I wrote the article while trying to decide between competing technologies. No one benchmark (or set of benchmarks) provides an absolute answer -- but information helps make reasonable decisions. Among the topics covered: C++, Java, Fortran 95, gcc, gcj, Intel compilers, SMP, double-precision math, and hyperthreading."
At least if you're developing in C....
Interesting numbers. Have you considered benchmarking Octave or rlab also? (Or is there a native MATLAB for Linus now?)
There is a quick and dirty intro to K over at Kuro5hin.
Some more links for more inforation:
Kernigan's benchmark test
more examples
Kx: the people who make K and KDB
Coyote Gulch Mirror
Be gentle! I'm sure my server is meltable, too! ;)
IN SOVIET RUSSIA, sig changes you!
wow, this makes about as much sense as this article from earlier today :-/
Ah ha! Someone who understands what benchmarks are for and how to use them - it sometimes seems like the corporate world uses numbers from benchmarks only when they prove their claims. Of course, that's the difference between open source and the business world - open source (ideally) looks at every benchmark result and asks "now how can we get all of these numbers better than the competition?" while more traditional businesses ask, "Which of these numbers make our product look the best?". *shrug* its just nice to see benchmarks used properly, is all.
KDB performs as well as it does because of this. It inverts the tables and store them by columns instead of rows. The K language goes along with that principle and has special meta-operators and operators for dealing with large amounts of data of the same type.
The language is interpreted, too.
I always find Intel C++ shines in all benchmarks. I wondered if anyone has ever tried to compile linux out of it? I know it might hurt your ideology but just for the fun of it. :)
The benchmark programs aren't free - this is a non-profit industry association that charges money to cover its costs, but there are a number of universities that are members or associates which may be able to do testing that could explore some of the compiler differences; poke around their website to see who's reported what kinds of results.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Its nice that the writer went to all the trouble to work on this and share it.
His conclusions are not very revealing. Anyone doing Java programming will quickly discover how slow it is esp. in regards to floating point. You don't need a benchmark for that.
That C++ performed as well as Fortran on the author's examples is interesting to me. Is the C++ implementations getting better or is the Fortan complier gone soft?
His reasons for staying with Fortran made me chuckle. Those are the same answers programmers gave back in 1983 when I asked them why they didn't convert after learning the new fangled languages C and Lisp. (Well new for me anyway at the time.) When it is right it is right. I guess Fortran is still alright.
This is everything but an troll... but:
As the article clearly shows, Java is lagging behind in speed, as it as since it first was released from Sun (remember the pre-1.3 days? if you do, you know that Java 1.3.1 and 1.4.x is a lot quicker today than it was back then)..
But then again, Java was never meant for big number-chrunching-applications was it? The way I see Java things, Java is designed to work on an end-user-level, thus speed is not (always) that critical. (Although implementing the wrong kind of algorithms (read: brute force) is just wrong anyway..)
What lacks in the article are languages that are designed specifically for the tasks he wants done...
Just my .02$ worth :-) Happy new year everyone!
I'm hardly a Java junky, but I've spent a lot of time recently with the language and I've heard a lot of complaints from my peers about Java being slow. Most of the time, just like this author, they're wrong! Java isn't slow, but sometimes you do have to program more thoughtfully to make Java fast.
First things first, though. No one would ever claim that JDK 1.4 is the ultimate Java speed demon. Even the "HotSpot" in server mode is going to be slow if your code isn't written well. But the author fails to do any profiling, and fails to give anyone even a hint as to why Java doesn't perform well. But I shouldn't get on him about his coding, or lack of profiling... neither issue is the reason his test showed Java to be slow.
The real problem: Firs, I'll cut him some slack for not profiling. However, I won't cut him any slack for using an interpreter instead of a JIT compiler. Java's been shown time and time again to be as fast as FORTRAN/C++ when using a good compiler, rather than an interpreter. *sigh* When will the madness end? A 0.07 second query to Google should explain that one to even a novice. Java IS fast. Interpreted byte-code is slow. Java != interpreted byte code; Java is a language.
Anyway, here's a link to a weak, biased, and not so rigorous argument backing up that statement. But, it's an easy read for Java newbies, so I'll risk posting it anyway: Java is Fast for Dummies(tm)
Can anyone suggest a good compiler for floting point number crunching on Athlon based systems? (For Linux, and preferably free or not too expensive)
He, who dies with the most toys, wins
I was surpries by the big difference between the gcc and icc compiler. Sure gcc ain't vectorizing, but there were huge improvements in gcc-3.x, which promised up to 30% faster code if I remember correctly.
Back in gcc-2.95 many optimazions were hard to implement due to portability, but those issues must have been resolved by now. Right?
He benchmarked gcc 3.2.1 and did not benchmark gcc 2.95.x . This in itself makes me doubt his work, especially if his C/C++ code is just C code "in disguise".
...
Plus, parallelization should not have been a part of such a benchmark.
Parallelization for a cluster _or_ a supercomputer has many issues
that have nothing to do with compiler/language performance, and has much to do with IPC, memory and cache hit/misses, and other pains, who provide many people with PHDs and careers. For a good reason.
I know he says it himself, but if you admit your results should not be taken seriously, don't publish them.
Object-oriented programming adds very little to the core functionality of a number-crunching application -- and performance is adversely affected by the overhead entailed in objects, exception handling, and other object-oriented facilities.
this means the man does not choose the right tool for the job. I agree that exception handling should not be used with numerical code, asserts work just fine. But objects and higher-level abstractions should very much be used in the 90% of the code which takes 10% of the runtime but still, say, >80% of development time
And don't let me get started on templates, which really made my work much easier when used properly.
And in many cases, function-oriented code exceeds the clarity of corresponding object-oriented code
as for function-oriented code supposedly exceeding clarity of OO code, I find this remark, Ahem, embarrassing. If your OO code looks less clear than functional code, you have quite a problem. It means you do not use abstractions to ease design, reduce code-redundancy and reduce module interdependancies.
It means, in short, that you are going through the motions, but do not think on what you do.
Working for necessity's mother.
The article claims that he *is* using a Just-In-Time compiler. What makes you think otherwise?
A very large part of clsoing the gap should be attributed to C++. It's a younger language, which means it's development is progressing faster. Both C++ and Fortran are probably approaching the theoretical maximum speed asymptotically, with a few years lead for Fortran. A extensive resource can be found here
Concerning what you have to say about OLTP processing, you might want to read Dennis Sasha's High Volume Transaction Processing paper. You are right on, as far as the architecture is concerned. There is a entire different set of concerns with KDB, but there are always tradeoff. This is too far offtopic to really go into any detail, though.
It is interesting to see somebody else with as KDB experience. Not a common system (but we can hope it grows in the future).
and Benchmarking?
Benchmarking on a platform that is as widely diverse as linux is pretty much useless. The odds are that *NOBODY* is running a system that is configured like the one the "benchmark tests" are running on so that the results are pretty much meaningless.
Here are some results from an AMD system and the IBM java runtime:
Athlon XP 1600
-mcpu=athlon-xp
-O3
-mmmx
-m3dnow
IBM java - build 1.4.0, J2RE 1.4.0 IBM build cxia32140-20020917a
58.8 seconds
58.9
Sun java - build 1.4.1_01-b01 Client VM
94.2
94.1
Sun java - build 1.4.1_01-b01 Server VM
82.1
81.6
gcj - version 3.2
82
82.1
gcc - version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
31.4
31.3
26.6 -ffast-math
26.6 -ffast-math
26.4 -ffast-math -funroll-loops
26.4 -ffast-math -funroll-loops
Compiling his benchmark with -ffast-math and -funroll-loops more than doubles the performance of the gcj built benchmark on my P3.
This brings it within spitting distance of g++.
time python -O almabench.py user: 22m19.354s
gcc -ffast-math -O3 almabench.cpp -lm time ./a.out
user: 0m50.348s
C++ is only 27 times faster than Python for planetary simulations.
Almabench.py is my own conversion from the cpp source. I will send it to the author for possible addition to the benchmark.
-- Imperial units must die --
It doesn't seem to acknowledge the widespread availability of file format libraries that are suitable for use with C++, such as libjpeg from the Independent Jpeg Group.
It also repeats the commonly stated claim that Java is free from memory leaks. Nothing could be further from the truth. While it is possible to carefully write a Java program that doesn't leak, I don't think it's any easier than making a leakproof C++ program.
How does Java leak memory? Simple. Just hold references to memory you don't need anymore. Holding a reference to any node in a DOM Tree will prevent the entire tree from being garbage collected. That's an easy way to leak tens of megabytes.
Garbage collection is no substitute for responsible memory management.
It also says that in C++, you have to implement graphics calls by coding to the native API of the OS. It says in Java, you have a portable way to do that.
But that's just bullshit. The article makes no mention of cross-platform application frameworks, a number of which were around before Java was ever dreamed off. If you use ZooLib, for example, to code in C++, you can do everything you want with graphics with no need for platform-specific code. There's lots of other cross-platform frameworks, such as wxWindows and Mozilla, even GTK+.
Request your free CD of my piano music.
Just to put some things into perspective, here are some numerical results. These were obtained on my dual-athlon 1.4GHz w/ 1GB of RAM. The task was to compute the TE and TM surface currents induced on a circular cylinder 10 wavelengths in circumferece and having a relative permittivity equal to 4-j2. The program simultaneously solves the perfect electric conducting case. The surface was discretized into 60 cells using 120 unknowns (way overkill, but just to prove the point) using the Integral Equation Asymptotic Phase method.
g77 Compiler (-O2 -malign-double -funroll-loops): 24.11s
Lahey Compiler (equivalent paramters): 16.45s
As you can see, there's really no comparison, except that the lahey-created binary uses about 10% more RAM than does the one created with g77. This is just a summary comparison as I did not go into measuring the difference in the error of the two results compared to a reference solution. I'm assuming that both solutions are about the same with regard to accuracy.
So how much will the beowulf project have to pay for parrallel tasking to rank over serial tasking in the tests!?
This is a joke, not libel. Beowulf is too poor to bribe.
You can't judge a book by the way it wears its hair.
Any benchmark without blood and guts and/or explosions cannot be taken seriously.
Using reference counting is one big help. And knowing how to write exception safe code is another. Yes, it's a difficult subject, but it is something you can learn.
It may be easier to write leak-free Java than C++, but I suspect that because many Java programmers blithely assume their code can't leak, there may well be more leaky Java programs than C++ ones.
I used to work at a web shop where we used the Enhydra Java application server. Enhydra is pretty well written, but the applications that the company originally developed for it were pretty sad. As a result they had to restart their servlet process every few hours because the JVM ran out of memory!
Request your free CD of my piano music.
When I run my QR decomposition "benchmark", IBM's virtual machine always comes out about 20% faster than Sun's. It would still be a lot slower than C++ or Fortran, but the gap should be smaller. On top of that, IBM's license does not require you to accept a license which says the VM may install any software on your machine and that you automatically accept the license of that new software. See http://hal.trinhall.cam.ac.uk/~nrs27/java_eula.htm l for all the fun.
I enjoy working with Swing
;)
And I almost took this guy seriously
Nah seriously, a great article with many insightful points. We need more of these and less those thinly veiled advertisements for blinkenlights.
I don't want to sound offensive, but this stuff mostly shows how low has the threshold become to make it to slashdot.
IMHO this has to be one of the poorer tests I've seen. It's between nowhere & nowhere, maybe because of the chosen code.
1 Only 2 machines, so unrelated you can't conclude anything out of that. Hmmm maybe a client-server example, but number-crunching is nothing you can consider a client-server typical application.
2 too few languages/compilers. Yes, you can use Java for number-crunching, but then you can consider a whole lot more. Moreover, that results for gcj are extremely different from what I got.
3 Running Linux on almost any platform, this test lacks depth. If you focus in "linux" and "number crunching", then choosing only "x86" is going a bit too far regardless being that the most used platform.
To me, this is more an anecdote than "an interesting read" that should be broadcasted at slashdot.
Anyone who's spent any time working with Sun's Wireless Toolkit to develop for mobile devices will have witnessed pretty serious memory leakage firsthand. I know I do! After starting an emulator 10-20 times to test code it's using so much RAM that it's necessary to kill and restart the Toolkit to get anything like reasonable performance back again!
;-)
I'll agree that Java makes memory management much simpler, (I've spent a lot of time hacking x86 assembler, Pascal, C and C++ over the years) but bad programming can lead to leaks just as well. You tend to discover leaks pretty quickly with a mobile phone that has only 200K of RAM to play with though
Code, Hardware, stuff like that.
...I've heard a lot of complaints from my peers about Java being slow.
Allow me to join the chorus.
Java isn't slow, but sometimes you do have to program more thoughtfully to make Java fast.
No. Java *can* be made less mind-bogglingly slow by avoiding certain things...preallocating a pool of objects and using primitive types (like int) whenever possible helps. The way the language is designed makes it *easy* to be mind-bogglingly slow. That doesn't mean that going out of your way to avoid these things makes Java fast. It makes it only "slow".
Java is Fast for Dummies
Ah, yes. A link tellings how Java isn't *really* that slow on "javaworld.com". I took a skim.
The first two pages say basically "Java isn't that slow". They then start rambling about various features that make Java a good language.
They claim that Java programs load faster than native programs. (The article was written, BTW, in Feb '98, to give an idea of how full of BS they are). This is stupid. JVM startup and load time *dwarfs* application link time. Write "hello world" in C++ and in Java.
First, they laud the small executable size of Java as being a performance boost based on binary format. Everything I've read points the *other* way...Java *is* fairly compact, but can contain data that isn't nicely aligned along host boundaries.
Second, what they're talking about, if it's even accurate these days, which I doubt, has a lot to do with the lousiness of the Windows runtime linker. This isn't really an issue for Linux.
Third, while insinuating that minimizing code size provides a performance boost, they talk about how great it is that Java lets you use *built in* libraries, whereas C++ progams need to *bundle* libraries. What? That's stupid. They're shifting the libraries around, but it sure as hell isn't decreasing total amount of data that needs to get loaded.
Fourth, this gem: Finally, Java contains special libraries that support images and sound files in compressed formats, such as Joint Photographic Expert Group (JPEG) and Graphics Interchange Format (GIF) for images, and Adaptive m -law encoded (AU) for audio. In contrast, the only natively supported formats in Windows NT are uncompressed: bitmap (BMP) for images and wave (WAV) for audio. Compression can reduce the size of images by an order of magnitude and audio files by a factor of three. Additional class libraries are available if you want to add support for other graphics and sound formats.
They're billing this as *improving* performance? Yeah, I'd love to have my app blow CPU time decompressing a JPEG image instead of reading a slightly larger BMP image if I'm trying to minimize load time. Oh, and have it load all the JPEG loading code, too.
They then proceed to ramble about selective loading, and try to imply that Java's runtime linking is faster than C++'s.
They *then* show off smaller binary sizes by embedding a BMP in the C++ binary and a GIF in the Java binary. Impressive.
They then claim that claims of poor Java performance are based on non-JIT implementations. This neatly lets them avoid actually citing numbers. Sure, I'll agree that Java went from "Performance Hideous" to "Performance Bad". Everyone uses JIT these days, and damned if Java isn't *still* slow.
They then try to talk about how JIT allows code to be optimized just like C++. Wow. Yup, JIT sure is known for impressive optimization, isn't it?
They then use the most artificial, contrived benchmarks I've ever seen (which conveniently avoid almost all of the Java pitfalls...they don't need to do array access, they're trivial to implement without heap allocation...)
They finish up talking about how C++ RTTI performance sucks compared to Java (ignoring the fact that Java hits RTTI code *far* more often than C++ does, like every time it yanks something out of a generic container class).
Finally, they finish up by talking about a bunch of random Java features that they think are great, like garbage collection "First, your programs are virtually immune to memory leaks." Hope you don't use hash tables, buddy.
Next, they talk about how a JVM can defrag memory. I'm going to have to just crack up at that. This isn't a performance boost unless you're using a language that *hideously* fragments memory and eats memory like a *beast* (granted, Java is the best candidate I know of). Runtime memory defragmentation went out of fashion with the classic Mac OS...it's pretty much a bad idea as long as you have a hard drive available. VM systems are pretty damn good these days...if you're trying to maximize performance, there are almost always better things to be doing than blowing cycles and bandwidth defragging memory. There's a reason we don't do it any more.
Basically, my conclusion is that "Java is Fast for Dummies" is primarily aimed at, well, dummies.
May we never see th
(never heard of them before, interesting). The basic version of their compiler (probably suitable for most student use?) is 249. There is an upsell version (looks like mainly a bunch of add-on or upgraded libs/tools like a gui constructor) for 695. Out of curiosity, what were the licensing restrictions you found objectionable? A cursury inspection of the site didn't reveal the licensing terms on the current product lineup (other than to mention that educational purchases can't legally be used to make commercial binaries, no big suprise there). thanks for the informative post, btw. :)
Many tiny, old, quick cores of i486 doing MultiThreading (MT) is better than P4 for quick boot, for older intensive applications, ...
...
P4 has XX millions of transistors, the same to build multicores of i486 doing MultiThreading
There are benchmarks between softwares but there are benchmarks between hardwares
The tip: parallelism of tasks & transistors (i486-MT) vs queue of tasks & transistors (P4-HT)
JCPM (copyright)
...what they are doing.
It's pretty clear this guy is not a Java programmer, or at least has limited knowledge of how to write efficient, well-designed programs in Java. Amazingly, that's actually not relevant. To get to the bottom line skip to the bottom of this post.
For starters, he's using 2-dimensional arrays, so of course Java is going to be slower. 2-dimensional arrays in C++ are actually 1-dimensional arrays with some syntactic sugar thrown in. In Java they are arrays of arrays (really akin to using vectors of pointers to vectors). Experienced Java programmers (and for that matter good C++ programmers) will use a Matrix class to both clean up the code structure and to provide a much more optimised 1-dimensional array structure for manipulations of the Matrix.
His benchmark doesn't have a warm-up run, and doesn't run nearly long enough to cause HotSpot to optimise the code thoroughly. Sure, this is fair if what you're measuring is how well the Java VM can execute a relatively short-run program (quick answer: not very well at all), but it is no indication of the kind of performance that Java can achieve.
The code essentially is not written like a standard Java program (and indeed, is a pretty evil C program if you ask me). I mean, any method with 30+ local variables is suspect in my book (particularly amusing is that some of them appear to be never used). As such, it doesn't play very well against the JVM's optimiser, which is oriented towards Java code with much different structure.
His TEST_LENGTH loop is long enough that he's potentially better off catching an array out of bounds exception than constantly checking the index.
This doesn't affect Java performance, but it's just silly to have a while(true) loop and then have a break on an if at the end of a block is just silly (it might trigger some optimization for a specific, broken C optimizer, but it's just silly to have that on a standard benchmark).
But ultimately this all doesn't matter. Why? Because the bottom line is this benchmark makes heavy uses of standard runtime functions (the trig and square root function). This means that large portions of this code are essentially out of the realm of the compiler, and in the hands of the runtime library. Doing stuff like this I can get widely different results just be linking in different floating point libraries. So, while he highlights the *compilers*, in fact what this is really stressing is the quality of the floating point libraries of the particular runtimes he's chosen. As such, it provides no insight in to the relative merits of using different compilers or languages. At worst, this might be misleading even for the specific application he has in mind. At best it suggests how a few different math libraries perform. The conclusions this guy draws from this are just rediculous.
sigs are a waste of space
My computer is a 900MHz Athlon, 256Mb RAM, running WinXP. Using J2SDK 1.4.1_01.
javac -g:none -O *.java
java -server almabench
Took a total of 107555ms
jview almabench
Took a total of 51073ms
Compare this with 76 seconds on his 2.8 GHz machine. JView (that's Microsoft's VM) was able to run in 51 seconds.
The two things of note:
Unfortunatly I have no c compiler on this machine to run them, that would be really interesting.
dominionrd.blogspot.com - Restaurants on
Using object orientation in C++ adds a very small overhead (in the vicinity of 10% if you're using virtual functions). Now I understand that the article was mostly concerned with benchmarking the languages, and I applaud the writer for specifiying that benchmarking is no "silver bullet". But I really want to stress:
Somebody has to develop and maintain the freaking program too!
Object orientation helps anything but the most trivial of applications to acvhieve better modularity and reuseability. Anyway your program is going to spend most of its time in development, not running, so anything that can help that process along is going to be a big help to your project. Please check out the benefits of the SW industries "best practices" and apply them to your project.
You will save days and months of development time, during which you can run your finished program to your heart's content.
A)bort, R)etry or S)elf-destruct?
Using both Sun's and IBM's Java virtual machines I get the following results from 'time'.
real 0m35.173suser 0m35.140s
sys 0m0.030s
The results vary from 35.130 to 35.160. When I run the c++ test with the following compiler options : -march=i686 -mcpu=i686 -O (somehow the mmx and sse option are rejected)
real 0m43.467suser 0m41.790s
sys 0m0.010s
Can somebody explain this please ?
> using an interpreter instead of a JIT compiler
No, he wasnt.
> Java's been shown time and time again to be as fast as FORTRAN/C++ when using a good compiler, rather than an interpreter. *sigh*
No it hasn't, because it isn't.
You can sigh all you like, it doesnt change a thing.
You acknowledge your link is weak and biased, why not try posting a reasonable link, particuarly one which seems to show that java is as fast as fortran or C++ for anything meaningful.
http://rareformnewmedia.com/
Yes, indeed, what about fp (functional programming) and numerics? :)
Funny thing is that the fp people have invested lots of brainpower into advanced functional programming techniques. Symbolic and logics math, yes I have seen software for it. But numerics?
Is it possible that a functional language beats FORTRAN eg in eigenvector calculations?
Regards,
Marc
so, if the "community" starts to wonder what all the tom shillerIE's about, they could just "move" the whole shooting match on over to: ...??? sourceforge?,,, uh,, no, let me think (you're right, that's a tough won for me, that's why we have you, to keep US on yOUR toes),,,,, osdn?, no.... how about ..........va.msn.net? ticker symbull: VAST?
that's probably already taken.
i get IT? do we smell sum plebytes getting roasted here?
I thought I still used Sun's VM as default, so that's why I thought it was just as fast as IBM1.3.1. When I explicitly select Sun1.4.1, the results are indeed _very_ poor.
real 1m54.370suser 1m53.440s
sys 0m0.040s
For IBM 1.4.0 I get the following
real 1m7.963suser 1m7.670s
sys 0m0.010s
I'm going to ask the IBM developer why 1.4 is so slow on their newsgroup. I hope they can fix the problem.
1. Fortran is no faster than C++, given decent compilers (Intel C++).
2. The g++ compiler is a pile of crap - it gave execution times more than double the times given by Intel C++. IMHO the difference is more than can reasonably be brushed off by saying that Intel know their own CPU better, or g++ has more features, or whatever the g++ fans will say. A difference as big as this means that - as an optimising compiler - g++ is broken.
What is it with Java people that they are all up in arms when someone posts what we all already know? Java is *slow*. It is wonderful for certain types of applications, but it is *slow*.
When I write an application, I want to write it in the most appropriate language, not just in the language I have a fetish for. If performance is important, you need to know how various languages perform. This page shows how java (the full system, ie. language, compiler, runtime, everyting) performs for a certain class of application, and it is performing badly.
As for why it is performing badly, that does not matter at all. The mere fact that it is doing so makes it inappropriate for this type of application. And that is a valid conclusion in my book.
In case any fellow beginning C++ programmer was wondering: This is because objects are only guaranteed to be destructed when an exception is thrown if and only if this exception is caught.
So no matter what you're doing in your program, its main() should always look a bit like this to make sure every exception is caught:
(Sorry, I can't seem to save indentation with /. HTML here)
Please note that this way, you also always assure to have a valid shell return code (EXIT_SUCCESS from your function() would be the OK code).
42. Easy. What is 32 + 8 + 2?
C is much better. As an OO lang. , C++ is pure crap. I have plenty of experience with it and the only reason I use it is the code base and employers asking for it (strong reasons :) )
Just a side note.
He complains about the Java compilers complete lack of optimisation flags (duh... making optimisations to platform independant byte code is pretty useless, and generally counter productive... it's all done by the JRE, which actually has a number of flags for tweaking things, and there are many JRE's to choose from). He talks about how the JIT doesn't perform processor specific optimisations (it does in fact perform many processor specific optimisations, unfortunately his benchmark is written in such a way that none of them will get used). He talks about there being no interest in high-performance Java (the Java Grande group would beg to differ). Best of all, he keeps calling Java an interpretted language... even though he used gcj as part of his own benchmarks... Sigh.
Worst of all he uses gcj without trying out TowerJ, which is a much more established Java-binary compiler. Sigh.
sigs are a waste of space
Believe it or not, I'm not a Java "ZEALOT". Indeed, at my current place of employ I don't write any Java, and I have written more C++ code than Java in general. I would write similar content about other interpreted languages (Self, LISP, APL, Smalltalk, etc.) had the original article referenced them in a similar manner. These kinds of silly, mindless comments come up all the time, and they show a total lack of knowledge about how to benchmark systems, and more importantly a lack of knowledge about the systems they are benchmarking.
sigs are a waste of space
Almost *ALL* of my email is related to Java. I'll be adding the IBM JDK and older versions of the Sun JDK later today, as per reader request.
I'm making minor updates to the article as the day passes. I appreciate comments from everyone; once I'm through with my e-mail, I'll respond to these Slashdot comments.
Additional benchmarks will be added to the article with time; I'm putting together a single-precision ("float") benchamrk, for example.
All about me
God, it feels like I've spent most of my professional life arguing with Fortran programmers. These people are ignorant, but arrogant. They think that because they have a Phd in Engineering (or Physics, or whatever) and can produce a syntactically-correct Fortran program, they know how to program, and can ignore advice backed up by thirty years of software engineering research and experience. Bizarrely, what little knowledge they have is about 35 years out of date, even for those in their twenties. They live in a ghetto.
As anyone with even the slightest real computing knowledge knows, what gives you performance is the algorithm chosen, not the implementation. Therefore, what matters is how easy it is to implement a good algorithm. Which means, how easy it is to write a program that implements a difficult to understand algorithm (because an inobvious algorithm-- of course, there are some exceptions). Which means that support for modern programming techniques that help you produce easy to understand programs is important for producing high performance programs. You know, things like the following that are absent from the still widely used Fortran-77:
So, comparing the performance of toy a Fortran program with its translation into C++ or Java shows nothing.
What has happended is a second Software Engineering Crisis. The first 'Crisis was in the mainstream, data processing, part of the software industry. The introduction of more powerful computers resulted in large, complex programs that were failures because they were complicated (See The Mythical Man Month). Since then, we have developed software engineering techniques to deal with their problems, so now large programs can be much more complex (composed of many parts) without being excessively complicated (difficult to produce and understand). Since about twelve years ago, the increasing performance of computers means that number-crunching programs (e.g. CFD programs) don't merely process large amounts of data; they are also large and complicated in their own right. The Software Engineering Crisis has caught up with engineers and scientists. The sad thing is, many don't know it, or ignore the advice (and screamingly obvious signs) that it is here.
Ne mæg werig mod wyrde wiðstondan, ne se hreo hyge helpe gefremman.
...the tools I have at hand. I have nothing against TowerJ, but can't test it if I don't own it. As for Java, I made note of a lack of flags, which is different from complaining. The -O flag is no longer supported by Sun's JDK according to the documentation.
All about me
As the author of the article states languages as Java and C++ contain a lot of functionality which has no additional use to the problems to be solved. I can imagine however some functional languages do.
Object oriented languages do come with a lot of overhead eg. memory management and exception handling, where a language as Fortran is optimized for and has proven its power when it comes to complex calculations.
As we all know should select the right language for the right job. Last year I've been working on an application which performs complicated flow calculations and presents the results through a web frontend. The easiest and (IMHO best) solution was to use three languages: Java, C and Fortran.
- Frontend Java (servlet), sending requests to a deamon (running on an another machine).
- Deamon C, receives requests, calls a Fortran function (which it was linked to) and returns the result.
- Calculations Fortran, for calculation precision and because the calculation libraries existed and were certified.
Ah, I forgot to mention it uses SQL to gather data from Oracle.Seemed a reasonable solution to me. Offcourse I could have used Perl, assembler and Lisp too and Prolog to solve queries, or Word97 macro's combined with Occam (which is very good at parallel computing) or whatever.
Sometimes discussions about Java start to look like discussions about religion. Bad. Scares the hell out of me.
giel.y contains 2 shift/reduce conflicts
Yes, look on Google for the language SISAL. That apparently beats Fortran.
Sisal was developed at Los Alamos IIRC and those dudes have some of the fastest supercomputers in the world so they should know.
The thing with FL's is not to use a lazy language, but a stract one (SISAL being a good example) should be able to be optimized quite heavily.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
I wasn't familliar with that site nor that author before but I love it!
I'm gonna go back after work and read around there a bit more.
There are some odd things afoot now, in the Villa Straylight.
Matlab for linux http://www.mathworks.com/products/system.shtml/Uni x
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Since more x86 benchmarks have been posted, people might have a look at some hints for optimization. I will only list some options important for Athlons ATM:
More in your favorite GCC docs.
42. Easy. What is 32 + 8 + 2?
From Kernigan's benchmark test
k is faster (sum of times)
k(32) perl(95) java(300) tcl(1400+)
[k is much faster than c on strings and memory management.]
k is shorter (lines of code)
k(9) awk(66) perl(96) tcl(105) scheme(170) vb(200) java(350)";
Interesting comparison. It took 350 lines of java to compare to 9 lines of k and 96 lines of Perl. also Java was 10 times slower than k and 3 times slower than Perl.
The title of the article CLEARLY states the limits of the tests: Linux Number Crunching: Benchmarking Compilers and Languages for ia32 That doesn't leave much room for doubt as to what I'm testing. I can add Solaris/SPARC numbers if anyone is interested.
All about me
I'm very interested in investigating the efficacy of functional programming for numerics. I've dabbled in Erlang and Haskell a bit, but haven't had an opportuntiy to study them in depth.
So many tools, so little time to understand them...
All about me
containing an item stop Now make another stop Now put them together in a new object stop Duplicate this object stop Now make a new object containing the two objects that were the result of the earlier operations stop Count the items in the latest object stop There are four of them stop stop
2+2=4
*Sometimes* purely symbolic typographical notation is *far* more readable than natural language.
A wise programer will use each method appropriately. First learn *math,* THEN learn programming.
KFG
Surely people remember that most excellent O'Reilly book, Numerical Recipes in AWK. Unfortunately the 1998 review of it has disappeared.
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
The answer is:
You haven't got an fscking clue Sparky.
I haven't given you any indication as to what sort of *conditions* performance will be measured under.
The author of this benchmark test seems to understand this. Did anybody wailing on him for failures of the tests bother to read his benchmark caveat?
All a benchmark test does is give you some understanding of how various things perform under the *precise* conditions applied during the test.
The real value of benchmarking only comes after performing hundreds of tests under hundreds of variants of enviromental conditions.
Doing so will increase your *human* wisdom about how certain things perform. Performance is a *value* judgement, and any human who abrogates their value judgment to a machine probably gets what they deserve.
Too bad that sort of shit usually rolls downhill though.
KFG
Back when I wrote reviews for print magazines (back when there were print magazines, that is), it was standard policy to limit reviews to the actually, shipping, commercial product. Demos often lack critical features (like optimizers) or are tuned for benchmark tests, so I've kept to that policy now that I write reviews for my own web site.
I own licenses for the Intel compilers, for example -- and, of course, gcc and Sun Java don't cost anything in the first place. I'm considering my options in this case; long gone are the days when a dozen Fortran or C compilers would arrive at my door for a magazine review. Heck, there aren't a dozen compiler vendors left... ;)
All about me
I wonder if anyone has compiled the Seti@Home client with ICC and benchmarked against GCC? Could be interesting. What about similar distributed projects?
Lump lingered last in line for brains, and the ones she got were sorta rotten and insane.
System: 1.0 Ghz P3, WinXP
l t compilation: jc almabench.class
Solution 1, Java, JET Compiler 3.0
http://www.excelsior-usa.com/jet.html
defau
Time: 40.1 sec
Solution 2, C++, GNU g++ 3.2 under cygwin
CPPFLAGS = -march=pentium3, -mcpu=cpentium3, -O3, -msse, -mmmx
Time: 82.0 sec
Solution 3, JAVA + JDK1.4.1_01 javac
javac -g:none almabench.java
Time: 114.6 sec
Times were computed by placing
System.CurrentTimemillis()/time() before and after the program loop and taking the difference for java/cpp respectively
From the results, the fastest solution I have at my disposal is java + JET. I need to get the Intel compilers, however. If relative speed of Intel vs. GNU holds, C++ and Java/JET will be about the same speed. I really get tired of "some language here" is slow/fast assertions. Whatever language you code in, you need to be efficient and have a good compiler. As always, there is more than one way to do things, and the most important requirement is to get the job done.
Since Java has such a different run model than Fortran/C++, the best way to get an apples to apples benchmark would be to write the Java code to run through the loop(s) a few hundred thousand times so the Hotspot compiler can optimize methods, then start the timer and run the timed loop(s).
Sure load time (and Hotspot method optimization time) counts in the real world, but if we're deciding which language to use on a multi-hour run, what we really want to know is, how fast is the language once the system has paid all start-up costs and settles down.
As for using this benchmark to reach sweeping conclusions about language speed, don't forget the obvious: everything depends on the speed of the languages double-precision math libraries, which most non-scientific applications don't use at all!
The intel libraries and compilers are nice and fast, but they don't optimize at all on AMD hardware, even though AMD hardware will do SSE as well. That bugs me a bit.
On this particular benchmark, "K" would probably perform very poorly--because it doesn't involve any big arrays. But, since you like "K" so much, why don't you try for yourself and report back?
"it has always been clear that Java is inferior to native code applications in terms of raw power. Computational performance depends on the effective use of a target processor's instruction set; such optimization can not be expected of Java given its goals of universality and portability."
This statement is simply not true! The portability nature of Java does not conflict with a virtual machine that does processor-specific optimizations. Take a look at Sun's HotSpot VM source code (it's publicly available!) In the IA32-specific code, you'll see lots of run-time switches to enable specific P4 optimizations, for example.
"Perhaps Java's Just-in-Time compiler could be enhanced to perform processor-specific run-time optimizations; on the other hand, doing so would require different JVMs (Java Virtual Machines) for different architectures, or a single bloated JVM with run-time architecture detection."
This already exists in the current HotSpot VM. There's an IA32 binary, which includes optimizations for several versions of IA32. It does not include PowerPC or SPARC code, as that's in a different binary.
" The "ia32" world is already fragmented between Pentium III, Pentium IV, Itanium, Athlon, and Opteron architectures, each having unique requirements for optimization;"
That's the challenges a VM writer has to deal with. And the HotSpot team did a great job in managing this complexity.
In the future, if you (or anyone else, for the matter) takes the time to write a paper, you should do more research. Some of the statements above are simply misleading.
This benchmark is about as "thoughtfully" written for Java as is possible--it includes only straight line arithmetic and a few simple array references. If a Java compiler/JIT can't do well on that, it's going to have real problems on other tasks.
But, more generally, I think there is something wrong with your attitude that you have to write the code "carefully". What is the point of writing numerical code in Java if I have to write it in a Fortran 77 style to get any decent performance? This is the 21st century--we use abstraction in our numerical code: classes representing complex numbers, quaternions, rotation matrices, and other algebraic objects. Fortran 95 compilers can handle that and so can C++ compilers. C# has the primitives to deal with it efficiently (value classes, operators), and its compilers will likely catch up performance-wise.
Only Java is conspicuously absent, lacking both the syntax to express such abstractions conveniently and the primitives to compile them efficiently.
(And this isn't even taking into account all the floating point related blunders in the Java language definition that make writing efficient numerical Java code hard even if you do stick to a Fortran 77 style.)
"Intel does not support all gcc language extensions; while it has been used to compile the Linux kernel and other free software projects, it is not a drop-in replacement for gcc."
e l_gcc_bench2.html
found at the bottom of http://www.coyotegulch.com/reviews/intel_comp/int
Second, who cares anyway? The reason why people don't bother hacking Fortran for Linux in a big way is because the people who could contribute to such an effort are already using C++. C++ has much better abstraction facilities for numerical code than Fortran 77 and even Fortran 95. And another big chunk of the market goes to Matlab, Numerical Python, and software like that. Dusty Fortran 77 decks can be compiled adequately with f2c or g77 and linked into C++, Python, or Matlab code.
What is the point of a portable programming language if you tie it to a specific platform? I don't see a Linux (or Mac, or Sparc, or...) version of Jet on their web site.
All about me
The benchmark also doesn't seem to be done very carefully: I didn't see any analysis of the generated assembly language (does the Intel compiler inline the code, does it use x87 instructions for trig functions), or verification of the results (do the different programs produce the same results when compiled with different compilers), or execution profiling (what dominates the running time). These ought to be part of any new benchmark program.
For the specific case of algorithms that can be expressed strictly in terms of bounded loops where the loop bounds can all be determined at compile time, so that there are no run-time tests needed to determine if some computation must be performed or not, functional programming styles can be near-optimal. Analysis techniques can radically restructure such programs, completely reorganizing the loop nesting.
There have been a variety of stream-oriented or single-assignment languages to make such things possible: Silage and DFL, Lucid, Lustre, Sisal, and others. You can get very good code from such languages, but they aren't very general.
You're right. I wish JET would work on Linux. Equivalently, I wish that the GNU g++ compiler made C++ code as fast as JAVA w/ JET compilation.
The point remains the same though, that JAVA code compiled to the native platform I'm using at the moment (WindowsXP) is faster than C++/FORTRAN by a factor of 2 over GNU GCC.
Reccomend what you like, but those are the numbers.
(btw, I'm a grad student with no affiliation to any vendor)
Thanks for the nice scientific computing benchmarks. The only thing that I could have asked for was a run of G77 code. Static memory and only pass by reference should make it quick, no? One day, I think I'll have to try it out myself.
Friends don't help friends install M$ junk.
Octave, and all but the very latest version (i.e., of some months ago) of MATLAB are interpreters, and therefore very slow on everything with loops. Granted, there is a lot you can do with some expressions in MATLAB, but anything more complicated than eigenvectors is going to need a loop, and thus will be slowed by the interpreter.
LOL, why is there always at least one K troll in every single thread that has anything about programming languages?
He didn't include a ton of languages, but that doesn't mean anything at all. It's hard to accurately benchmark in every single language ever made. Not only would you need to know how to optimize each one, but you would have to rewrite the tests in each language... c'mon.
People would be using K more if there was a reason. At least at this point in time there is no compelling reason to use K. It's slower than C/C++ for many things and is detrimentally terse (read: error prone).
K is written by the same person that orignially developer A+, Arthur Whitney. I have never used A+, but Arthur says that K is much faster than A+.
I know it costs a little money, but i would be very intrested to see the PGI compiler set tested up there as well.. I've seen on alot of CFD code have 10x speedups over g77 with pgf77. I do know that PGI has a 15 day trial license for their compiler, that should be long enough for a test run of the almabench to run.
In KDB, unlike many other databases systems, normailization will increase speed. Other multidimensional dbs will try to denormalize data to run faster, but KDB isn't like that.
KDB really has two query language (and a stored procedure language): SQL92 and KSQL. SQL92 is translated ti KSQL, a more featureful and simplier version of SQL. In KSQL joins are implemented as pointer chasing and very cheap: "Parent.Child.datum" will join tables Partent and Child on the key and return the datum field of table Child. No more complicated join syntax.
Yes, at some level this was an attention seeking post. I try to pump up the language whenever I get a chance to because I am amazed by it. This should be one direction the future of computer languages (and databases) takes. I still have a hard time grasping the simplicity and power in the language.
If there are any other K "trolls" (probably better called Kx shills... I'll admit to that one) here I would be surprised. I thought I was the only one.
I wasn't seriously expressing disbelief at him not including every language (especially unknown ones like K). I understand that the work it takes to do these things (and the tedium). However, maybe somebody will see this and next time they need to do something that fits K, they would think about it for a second... or maybe somebody will see this, become interested, and go learn K and use it in the future. That is how I became hooked. I used to use c, java, anc scheme (especially scheme and lisp) for everything. Now I use C when necessary and K for most other things.
In K you always want to deal with large chuncks of like data: bulk good, scalar bad. However, there seems to be a very small class of problems where you can't write an array version of them. And this array programming methodology happens to lead to very fast code, too.
I think I just understood what you meant concerning updates. Yes, in KDB batching updates together in bulk is much more efficient than doing singular updates.
I just ported the java version of almabench to c#.
I also compiled the cpp version , with MSVC 7.0, pentium pro optimizations. I obtained identical results from pentium and pentium pro optimizations.
I ran the two programs on my 3 machines and the results are:
1: AMD AthlonXP 1900+, 512 MB, Windows XP Pro:
cpp: 25 seconds, c-sharp: 27 seconds
2: Intel Pentium3 1300, 1024 MB, Windows XP Pro:
cpp: 33 seconds, c-sharp: 36 seconds
3: AMD AthlonXP 1500+, 512 MB, Windows 2000 Workstation:
cpp: 39 seconds, c-sharp: 43 seconds
Looks like c-sharp compares pretty well with c++, my guess for the slowdown is the array boundry checking.
If anyone wants a copy of the cs version, send me an e-mail.
That C++ performed as well as Fortran on the author's examples is interesting to me. Is the C++ implementations getting better or is the Fortan complier gone soft?
I would guess that the C++ code did just as well as the fortran code because it didn't use many object-oriented features. Intel knows how to make a fast compiler, and straight-forward procedural numerics in C++ should turn out to be just as fast as the fortran code.
While I used to be in the C/C++ crowd for performance back in the days of 233Mhz processors, with every GHz milestone this argument becomes more and more invalid. Remember, these days a 3Ghz machine is available for less than a thousand dollars.
If you're performing atmospheric simulations on a 50-Terahertz supercomputer use C. But with 90% of the code these days in business (which is the majority of custom code written in the world), Java's speed is acceptable and its portability and memory garbage collection outweigh any speed advantages of C/C++ in a Gigahertz world.
The portability issue is even valid in academicia, where in my school we had NeXT, Mac, Windoze, NeXT-x86, and SGIs, and now Linux. UNIX programs are pseudo-portable, but not like Java.
Most app slowdown these days is database processing and network transport.
Hey, I'm just your average shit and piss factory.
that someone could cook up a single line of Perl code that could do all that. Of course, the code would be write-only and hellishly slow (and probably involve one or more regular expressions of extraordinary length), so it wouldn't do much good though.
________
Entranced by anime since late summer 2001 and loving it ^_^
As I was saying, there is nothing special about "K", it's just like Matlab, Numerical Python, APL, A+, and lots of other tools. And your assessment that "This seems like something that would be perfect for the language." is just wrong: simulations of celestial bodies are about as ill-suited to array processing languages like "K" as can be.
That really leaves me wondering: what is your interest in "K"? It's the wrong tool for this job and there are plenty of other languages like it, many of them free and much more widely used.
Corman Lisp and MLton -- Other fast functional languages.
GNAT Ada -- Runs pretty close to C/C++ speed. Sometimes faster if the compiler can do expeditious compile-time optimizations.
Thanks for the pointer; however, I looked through the gcc documentation (on the gcc web site) for any options related to intrinsic functions. I didn't see what you allude to; which specific options did you use?
All about me
I really don't know the nature of celestial simulations. I used the think the same about many string processing routines, too, and that just proved that I didn't know how to vectorize the problem. So my history of knowing that is vectorizable isn't the best.
By "plenty" you mean APL, J, matlab, SAS, and a couple others? Well, I think that K has them beat in most categories. For simplicity trying to compare K against any of them is silly. J is a monstrously difficult and complex language to me. SAS has these huge tomes for manuals. In all fairness, it has a very large library, and that is most of the documentation. However, SAS (and matlab) are far more limited in aplicability. K is a general pupose language and is used in many different fields. You would not see a database written in matlab, because it is the wrong tol. However K is the right tool for that, and K is also the right tool for stock market analysis, and data mining, and even something like parsing is very simple in K. After having to learn SAS and other small specialty languages, I would rather just learn K once.
If you try to compare on performance considerations, it is also hard to beat K. I don't know clockins on matlab, but K for complex problems will run as fast (and often faster) than C. Beside just making array processing easy, it gives you excellend memory management and manipulation.
As with any language, there is a classes of problems that are not appropriate, but for K that seems to be a very small class. Celestial simulations might just be a problem that isn't easily vectorizable. Or maybe matlab might run it faster (I doubt it, though). The only way you really learn about the costs and benefits of a particular language is by using it, though.
The creator of K once posted a list of "you know you are getting better at K when..." to the mailing list. One of them was "You know you are getting better at K... when zip expands."
I believe the problem of optimizing byte-code for numeric work has essentially been solved, and for a byte-code system to turn in poor benchmarks means you have a bad library or a bad JVM or something. There may be reasons to stay with C++ -- templates, pure open-source implementations -- but numeric speed is not one of them unless you are quibbling over the last 10 percent.
Now GUI's and other libraries are another matter. Don't you think something like SWT, tuned for individual platforms, will knock the socks off Swing, generalized for all platforms?
The original article generated an exceptional collection of interesting and helpful of responses. In this section, I'll run down the important points people made.
Note: This is a duplicate of a new section I added to the review; I'm posting it here for posterity.
An overwhelming number of people suggested that I include results for IBM JDKs -- and I have. In fact, I've added results for Sun JDK 1.3.1_06, IBM JDK 1.4.0, and IBM 1.3.1 RC3. Adding these JVMs made a significant difference in the results, cutting runtimes in half. On the other hand, almabench runs as an infinite loop with Sun's 1.3.1 JVM (it starts, but never finishes). Note that I recompiled almabench with the corresponding javac for each JDK, so the JVMs were executing code generated by their corresponding compiler.
The problem with Java's performance is not my code or my lack of Java skills -- what real problem is that Java 1.4 is slow. Both the Sun and IBM JVMs lost significant performance in the move from 1.3.1 to 1.4, whether due to a new language requirement or other factors. My faith in Java is severely shaken when applications lose significant performance by upgrading to the current release of Java.
Java 1.4 added many new features to the language and packages; however, changing from version 1.3 to 1.4 should not double run-times! Nor am I comforted by the problems of Sun's 1.3.1 server JVM.
Given the nature of the problem, my conclusions about Java stand (albeit slightly softened). By Sun's own definition, JDK 1.3.1 is obsolete; the fact that it performs better than the most current JDK is indicative of a serious problem with Sun's improvements to their language. Since Java 1.4.1 is what Sun is promoting, so that is what I base my conclusion on. I can say that IBM's product is superior, and have already set it is my default JDK. It's no wonder Sun is upset about IBM usurping Java -- IBM is producing better tools.
Some people asked if my Java results were biased by the amount of time it takes to load the JVM. I've tested several empty and near-empty applications; a Hello, world program, for example loads and runs in less than 2/10ths of a second -- hardly significant. The start-up time increases with the number of imports -- but almabench.java imports only one small class package, java.math.*, which (in my tests) does not impose measurable overhead.
I did not include any commercial Java compilers. Most, like the oft-cited Excelsior JET, are Windows-only; this article is about Linux. I don't benchmark Visual C++ or C# for the same reason (although I will look at Mono and C# some time in the future). The free version of Borland C++ does not include a complete optimizer, so I don't think it fits in this review.
How do I know that the programs are producing the correct output? Each program includes code to display results; I run the programs with I/O to ensure that all calculations are being performed, then I comment out any header inclusions, imports, and print statements for actual testing.
How am I timing the results? With the Linux time command. Table 3 reports the real value reported by time (the elapsed time of execution.) Embedding timers in the actual code is fraught with problems; for example, each language implements different time scales and abilities. I'm sure someone will tell me that time is full of problems too, but it works for me and is consistent across all programming languages.
Amid the barrage of Java-related comments, a few people actually noticed the Fortran code. I am looking at other Fortran compilers for future updates. As for GNU g77 -- I wrote the code in Fortran 95 because I find Fortran 77 to be annoying. I wrote piles of Fortran 77 back in my CDC and VAX days, but these days I'm writing for environments where Fortran 95 is more appropriate. Believe it or not, Fortran 95 is a very clean, orderly language that eliminates many Fortran 77 idiosyncrasies while adding features important for high-performance coding.
All about me
PS: Please use a divider between your message and the signature. Less confusion that way.
Bad suggestion, no biscuit! If you are easily confused (as, I confess, I am), then enable the "Signature Dash" option in your user preferences. (I believe this is the default.) Adding a manual divider to your signature just makes it look stupid to the people who have this option enabled. And people who don't have this option enabled have noone but themselves to blame for any confusion they may experience.
Please don't harangue me about minor grammatical errors in the above; I'm tired, and pasted an old buffer (which I thought was a new buffer that I'd proofed. Damn these modern conveniences like cut-and-paste! ;}
I'm going to watch Reign of Fire with my lovely wife now.
All about me
... is the parent's subject. I forgot to change it. My bad.
I mean, take a look at this for example. Ouch. I mean, perl can be bad, C can get hairy, but sheesh. As far as hairy goes this is chewbacca overdosed on rogaine.
Too obvious: mild personal insults to make the poster want to refute you, vague hand-waving or nebulous "problems," easily beat down arguments to create more of an attraction, trying to play in the "language zealot" nature of many people, etc...
sorry.
I don't think anybody would argue that precedence rules would be bad if you only had to deal with the four major arithmetic operations. However, as soon as more operators are introduced the complexity quickly becomes not worth it. As proof look at what people do with C: they are encouraged to not even learn what the precedence levels (and associativity of each level) are and just use parenthesis.
The "technology testbed" probe, Deep Space 1, was programmed in Common LISP, I'm told. As I understand it, NASA engineers can (or could; I believe the probe is shut-down now) bring up a prompt and actively write/debug code while the probe was in space. Quite impressive; perhaps I need to brush-up on my LISP? ;)
The Space Shuttle is programmed in Ada -- not terribly surprising given the origin of the shuttles in the late-70s, early 80s. Ada is a pretty good language, from what I know of it.
NASA uses a lot of different tools and languages -- which proves that intelligent life exists on Earth. No one programming language is the ultimate tool, and people who cling to one language for all solutions are ignorant at best and foolish as worst.
All about me
My feeling about timing is that it is trivial to get the system time to less than a microsecond resolution on x86 systems, and the overhead of doing so is totally negligible in a reasonable benchmark, as long as it only happens a few times. I modified his Java benchmark to print out a little more information. I also followed some advice from the discussion on better compiler switches for gcj.
Here are the results I got this morning:
[glock27@rigel java]$ java -version ./almabench
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
[glock27@rigel java]$ javac *
[glock27@rigel java]$ java almabench
starting...
elapsed ms: 3915
elapsed ms: 3904
elapsed ms: 3893
elapsed ms: 3894
elapsed ms: 3888
elapsed ms: 3909
elapsed ms: 3893
elapsed ms: 3895
elapsed ms: 3897
elapsed ms: 3899
elapsed ms: 3893
elapsed ms: 3897
elapsed ms: 3890
elapsed ms: 3918
elapsed ms: 3893
elapsed ms: 3897
elapsed ms: 3891
elapsed ms: 3908
elapsed ms: 3893
elapsed ms: 3893
total elapsed ms: 78509
[glock27@rigel java]$ gcc --version
gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[glock27@rigel java]$ make
gcj -o almabench.o -march=athlon -mcpu=athlon -O3 -ffast-math -funroll-loops -fno-bounds-check -c almabench.java
gcj --main=almabench -o almabench -march=athlon -mcpu=athlon -O3 -ffast-math -funroll-loops -fno-bounds-check almabench.o
[glock27@rigel java]$
starting...
elapsed ms: 1227
elapsed ms: 1202
elapsed ms: 1209
elapsed ms: 1206
elapsed ms: 1209
elapsed ms: 1211
elapsed ms: 1207
elapsed ms: 1211
elapsed ms: 1219
elapsed ms: 1204
elapsed ms: 1212
elapsed ms: 1207
elapsed ms: 1205
elapsed ms: 1215
elapsed ms: 1207
elapsed ms: 1212
elapsed ms: 1205
elapsed ms: 1207
elapsed ms: 1207
elapsed ms: 1206
total elapsed ms: 24478
GREAT showing for gcj...now 3.2 TIMES faster than Sun JDK 1.4!!! I'll post results for gcc with similar mods later.
All times are on my completely stock Athlon 2100+ XP - which benched faster than his P4 2800 using JDK 1.4. Maybe he should check out AMD after all. ;-) My bench did not reflect startup time, but trust me it wasn't close to six seconds (more like less than one).
This has really changed my thinking about gcj, although I'm also impressed with his Intel compiler times. I'll see if there is a free trial and see how the Intel code does on my Athlon. I've heard the generated code runs well on AMD systems also - I suppose unless SSE2 is used. ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
But you've just made Linux Today, so I'm afraid the assault isn't over yet. :)
KFG
There's little that's inherently slow in using OO. Yes, you can have virtual function look-ups giving you an extra level of indirection, but to achieve the same result without OO, you'd just need some other (similarly time-consuming) technique. OO formalises stuff that people do anyway, it doesn't automatically generate new overheads.
A far more likely explanation is that C++ compilers now optimise better than they used to. Comparing native C and C++ procedural code, you should see identical performance, yet C-only compilers have always produced executables that outperformed C++ ones because they've had that much more experience optimising within the framework C creates. As the C++ compiler industry matures, better optimisations are being developed all the time, and the gap is closing as you would expect.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I've once again updated Linux Number Crunching article based on questions asked and suggestions made by readers. New options help GNU gcj produce code that is faster than the VM-based JDKs. I've also added an explanation of why Java became slower with its 1.4 release, and show that JVM initialization does not significantly affect test times.
I appreciate the comments and bits of information I've received from readers. Onward to accuracy!
All about me
There are way more important factors to consider when writting code, development time, maintainablity, code reuse, etc. Which is why nobody in their right mind would write an application in assembly anymore.