Slashdot Mirror
Can You Spare A Few Trillion Cycles?
rkeene517 writes "11 years ago I did a simulation of 29 billion photons in a room, that got published at SIGGRAPH 94. The 1994 image, called Photon Soup is
here
.
Now computers are 3000 times faster and I am doing it again only much better, with a smaller aperature, in stereo, with 3 cameras, and with some errors fixed, and in Java.
The 1994 image took 100 Sparc Station 1's a month to generate.
I need volunteers to run the
program for about a month in the background and/or nights. The
program is pure Java." Read on for how you can participate in the project.
"The plan is to run the program on a zillion machines for a month and combine the results. All you have to do is run it and when the deadline arrives, email me a compressed file of the cache directory. So email me here and I'll send you the zip file. The deadline will be June 1st 2004.
The running program has a More CPU/Less CPU button. Every half hour it saves the current state of the film. The longer and more machines that run this, the cleaner and sharper the image gets. If you have a lot of machines, I can give instructions how to combine the results so you can send in a single cache directory.
Of course, you will get mention in the article if it gets published."
The link to the image should be http://www.cpjava.net/raytraces/DRUN.GIF (The www is necessary and was left out of the link in the article.)
People are already cracking jokes about how the fact that it's in Java will mean that it will run a lot slower than it could. While I love to pick on Java as much as the next person, I am curious how much it actually makes a difference for raytracing - does anyone know? My experience with numerically-intensive algorithms is that Java is 2-4x slower than C. You can get it within 2x of the speed of C if you ignore object-oriented programming and you're really good at Java optimization, but that's it. And it will run much slower on some architecetures because Java guarantees certain floating-point operation semantics at the expense of speed.
If I were writing a new numerically-intensive program from scratch that I wanted to use for a cross-platform distributed computing project, I'd probably do it in Numerical Python (NumPy) - my experience has been that it can be within a factor of 2-3 of the speed of C, but it's much more concise, requiring half as many lines of code as Java or C to do the same thing. And these days Python is just as cross-platform as Java - it definitely runs great on Mac, Windows, and Unix.
A much larger version of the SIGGRAPH `94 image "Photon Soup", clocking in at 840x560, can be found HERE.
Not really that slow, depends on what you're doing. At work we're using a CPU intensive Java based "optimizer" that runs a hybrid Genetic Algorithm. We also have a very similar version that was coded in C++. Chances are that the C++ coders sorta sucked, but the end result has been pretty much the same. The only difference was that our Java application actually DOES run on many platforms, including Windows, SuSE, and MacOS X, without a problem. And I can't say it enough times, it's just as fast as the C++ version that only runs on Windows .
Dude, is your C compiler that bad? I like Java a lot, and use it for compute intensive applications, but I think you're either pretty bad witha c compiler or trolling. if you're doing something CPU intensive in C, you need to use gcc -O2 (or -O3, depending), with -march=cputype. This will allow gcc to generate exactly the same code you just described, since it is not limited to 386 instructions. And if you need even more performance, you can just use Intel's C compiler for a lot of things (non-commercial is free as in beer), though it doesn't support some GNU extensions and I think has trouble with some things like the Linux kernel.
I added "www." to the URL, it works.
Try this...
Trolling using another account since 2005.
My experience with numerically-intensive algorithms is that Java is 2-4x slower than C. You can get it within 2x of the speed of C if you ignore object-oriented programming and you're really good at Java optimization, but that's it. And it will run much slower on some architecetures because Java guarantees certain floating-point operation semantics at the expense of speed.
The speed difference oft cited is about 20% on numerical apps. Check out http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html. He brings up "
Benchmarking Java against C and Fortran for Scientific Applications as well.
You have to remember that Java's speed disadvantage is mainly in the JVM startup and GUI areas. Although a good Java dev team can make Swing fly ( checkout JBuilder for instance ).
Java being Just-In-Time compiled can even take advantage make runtime optimizations that your C/C++ application may not.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Eh... .NET is natively compiled when it's run for the first time. It also optimizes for the platform (even CPU) it runs on.
Supplies!
As founder of the Distributed Hardware Evolution Project which is written in Java, I'd like to remind you all that the Just-In-Time compiler coupled with the real time profiling and dynamic on-the-fly optimisation that goes on in the Server VM makes the difference between C and Java minimal for code which is in the critical region. This is specially the case for code which is executed over and over again, such as with these distributed processing projects. In fact the guys at Sun are doing such a good job at exploiting the ever more complex characteristics of different processors that Java code is expected to run faster than C in the future. Also, during the weeks that you would spend debugging and porting your C code, your Java code has gone miles ahead doing useful stuff! If you would like to start your own Java distributed processing project, DistrIT might help.
Ok. My assembly is a little rusty, so bear with me. Let's say we have equivalent Java and C programs. They both have to run on a 386 or higher. (Bear with me. I haven't kept up with the MMX/SSE/SSE2 instructions, so I'll have to fake this a little.) Now, your C compiler will see that you want to store a 32 bit value, but has to generate code for a 386. So, it generates the code:
pop AX
STOSW 0x0005
pop AX
STOSW 0x0005
Even though the code may be running on a Pentium Pro (which is optmized for 32 bit code), it's still going to execute those 4 statements.
Now, the Java Hotspot compiler will start and notice the fact that you're running on a Pentium Pro. So when it converts the bytecode to machine code, it creates the following instructions:
pop EAX
STOD 0x0005
That's twice as fast as the C code!
Real code would tend to be running on modern processors, so this example is a little contrived. However, the JVM can (and will) use SSE instructions to do multiple calculations in one instruction, while the C code will be forced to generate non-SSE instructions to support the old Pentium Is out there.
Hotspot is also capable of analyzing the running code and regenerating even better assembly that would perform poorly in other circumstances. For example, let's say Hotspot notices that the bounds can't be exceeded on an array. Well, Hotspot will then recompile to remove the bounds checking.
Does that explain it better?!
--
This post is open source, retransmit as desired.
His argument isn't invalid.
rkeene517 is asking for volunteers to run the program. If rkeene517 does it in C/C++ then rkeene will have to compile for the different x86 types and ensure that volunteers download the right binary. From experience you end up getting a high number of people getting the generic x86 binary instead of the optimized one because in order to avoid zillions of support queries, you have a "If you are unsure, click on i386".
Of course you could bundle all the various binaries and add code or a binary that figures out what x86 it is and runs the relevant binary.
But that involves a step more than what you suggest.
His argument is quite valid.
Sure, you can configure compilers as narrowly as you like, but in most cases, compliation will be targeted at the lowest common denominator.
If your compiling for yourself, you have the luxury of building for your own CPU. This isn't the case here.
Why do you think Linux binary rpm's, for years, were compiled for 386 chips. It's only recently that some (all?) distributions have started distributing 586 based rpms.
The point is, Java can make this decision at run-time, and hence target the actual CPU. C++ code can not (without a lot of pain, at least).
Photon Simulation: "forward ray tracing". Emit photons from light sources, have them bounce off scenery, and see where they hit the eye.
Ray tracing: "reverse ray tracing". Emit "sight rays" from the eye, have them bounce off scenery, and see where they hit light sources.
That's simplifying, of course.
Forward ray tracing was here first, but was quickly (all but) abandoned, since it is computationally way more intense (why, 10 years ago, it would have taken 100 Sparc Station 1's an entire month just to calculate one small image!). Imagine simulating a zillion photons just to discover that over 0.99 zillion had failed to reach the eye...
On the other hand, it is physically more correct, since effects like caustics are very difficult to do right in "reverse" ray tracing.
For instance, let's say you have an interface I, and a class X that implements I. If X is the _only_ implementation of I loaded at the moment, then all calls to methods on I can be direct, non-virtual calls because there's only one choice! In fact, HotSpot will even inline the method calls if it decides it will be beneficial.
But then a class B is loaded. HotSpot will de-optimize the inlined and direct calls to methods on I.
There are many more examples, such as loop bounds-checking elimination, and other things HotSpot can do because it sees the state of the running system.
If you've used a slow Java program, it's no doubt the result of a poor design and coding job by the programmer. "I'll just pick up Java for Dummies in 24 Minutes. Now I'm a 1337 j4v4 h4x0r!!" You may also have been using an old, slow JVM. The performance increases between Java 1.2, 1.3, and 1.4 are truly awesome. Also, Sun's Java 1.5 starts up on my machine in less than half the time that 1.4.2 did, and the graphics as OpenGL accelerated now, ... the list goes on and on. For anyone who had used a Java IDE, especially NetBeans/Forte (which I like, except that it's so freakin' slow I fall asleep between operations), you must try IntelliJ IDEA. It is so responsive and just a joy to use. On the systems I've run it on, it is significantly more responsive than Eclipse.
Dr Superlove 300ml. I use my powers for awesome
The old 1994 picture is of a cubic room with mirrors on the near and far walls. The 'bubbles' are refletive spheres. A beam of light comes out of the left wall, hits a prism and forms a spectrum on the right wall. The depth of field is very shallow so only objects exactly on the focal plane are in focus. The black fuzzy blob is the camera aperature, out of focus, being reflected in the far mirror. There is an error in the image. The corners of the room are bright and should not be. This is due to a poorly chosen diffuse scattering model. The current project is an almost identicle setup, with 1/4 as big of aperature. I have done about 1 billion photons on my 3 computers, and the new image looks much cleaner. I expcet it will take about a trillion photons to make a realy smooth image.
Inside every complex program is a simple solution trying to get out.
Given that this was an exercise, I'm somewhat tempted to ask whether you aren't counting the JVM startup time on top of a very short problem instance.
C: 30 seconds, Java: 8 hours. No kidding. These were running on the same laboratory machines, the Java programs using the latest Sun JVM at the time. The exercise involved calculating some statistics from a simulation run for one virtual year. Most of the people doing the Java version had to leave it running overnight. Besides, JVM startup time is a performance issue, you can't just dismiss it out of hand.
That, or whether the exercise involved lots of dynamic creation of objects (in which case your program was by definition not doing the same thing as the Java implementations). The exercise you mention sort of sounds like that.
In the Java version, each event was an object. In C each event was a malloc'd struct. These are analagous in that they are the correct way to solve the problem in that particular language. The fact that object creation and destruction is a lengthy process is an important reason why Java is so slow. It's an object-oriented language, its raison d'etre is to create and destroy objects. If it can't do that fast enough then what's the point in it being able to do anything else with speed?
I know at this point the Java apologists will say "just use a pool of pre-created Objects, that'll speed it up". This misses the point in two ways: (1) Java was supposed to obviate the need to perform manual memory handling. Now I have to not only remember to de-allocate my objects when I am done with them, I have to write a Pool class within which to store my not-currently-in-use objects?! (2) I can do that in C, too, if I really want to, and it'll make the C version faster again.
I am well aware of the forte of Haskell and its different interpreter implementations. To the degree that I wouldn't be surprised if the Haskell implementation did better than your C implementation.
They didn't. I was told they took around 10 minutes to run, but I never actually saw them working. When I produced results from a simulation that ran for 1000 years (an overnight run for my C program), the professor was amazed. But yes, in my experience interpreted Haskell is very fast, which makes Java look even more foolish.
I've done this four times now; written a C equivalent of a Java program and found it at least one, often several orders of magnitude faster. I've yet once to be shown a Java program that is significantly faster than its C equivalent.
This does not mean that Java should not be used as a programming language. The language features (especially those in version 1.5) are useful for working in a collaborative environment with mediocre programmers, and where the raw performance of the application is not critical (such as a GUI front-end to a server application). Just don't bullshit about it being faster than C, or even "fast" and expect me to believe it.
I'm willing to be proven wrong, but until someone can actually show me proof that it can be done, I'm not going to believe the hype, hand-waving and hot air.