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."
Java eh? So it should run at about the same speed now on modern hardware as it did a decade ago? Chortle.
I hear they use cycles big time there. Pretty cheap too comapared to cars.
"When the only tool you own is a hammer, every problem begins to resemble a nail." - Abraham Maslow (1908-1970)
Go outside (No, it won't kill you) and look up at a bright star. Now imagine that star is in the center of a sphere and your eye is on the surface of the sphere. The aperture of your eye captures enough photons to image the star constantly. Now imagine that same amount of photons reaching all points of the sphere's surface. That's a serious bunch of photons. And the star outputs them constantly, for billions of years.
Any biology majors here care to tell me how many photons the eye needs to 'see' a reasonably bright star? With that information, you can calculate the rest (left as an exercise for the reader).
Money for nothing, pix for free
He needs networking connection, a decent threading model and doesn't want to crash your box.
So while he could spend a huge amount of time doing all these basic things in C and still have major risks for the people running it, he has chosen to use the right tool for the job.
Also the Maths libraries are IEEE compliant in Java and not in C on the PC, so I'm assuming that also played in to his reasoning.
An Eye for an Eye will make the whole world blind - Gandhi
Java can actually be quite fast and efficient for number crunching or scientific applications because of the JIT compilers and automatic optimisation. Its only painfully slow when you need a GUI. It also has a great class library so he should be able to do things like the visualisation and the networking for the clients to send the data home relatively easily, whereas it would take a lot longer to write and debug in C.
Also with Java, he can just offer the JAR file on his site or whatever and people can d/l it and run it. I guess this isnt really important if he's aiming at geeks, but if he's trying to get others to participate, it is handy that people wont need to worry about compiling it themselves or picking the right version (like at the seti@home site).
I would like to know what I see in the picture before I dedicate my cycles to the project. What are those "bubbles" in the pic for example?
A much larger version of the SIGGRAPH `94 image "Photon Soup", clocking in at 840x560, can be found HERE.
wow, its slower than C. i'd rather run a random java app than a random native app because you can easily sandbox it and know its not going to screw your computer. thats one less barrier to people helping the dude out. and theres no recompile for the various linux platforms, win32, solaris, macOS, etc etc. its certainly slower, but more friendly to the community.
1. Learn to use java -Xprof. This is a rudimentary profiler, but even the most basic data is useful. Concentrate on the parts that get the most use.
2. If -Xprof says the garbage collector is taking more than about 1-2% of the cpu, it's a problem. If it's at 10%, it's costing you well more than 10% speed -- lots of reasons, like cache misses, thread switching, and the allocations in the first place.
3. Don't delete objects in the main loop. Use factory methods and the like if you have to. This is how you decrease GC times.
4. Some of the standard API pieces are very slow. I've had particular trouble with anything related to the Collections framework, and Strings are even worse. Avoid these.
Now, all this takes work, but it's not particularly harder or easier than doing good optimization of C Code.
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.
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
Two words: Photon Mapping
The simulation you are trying to run does not the kind of compute effort that you are planning on using. I implemented a photon map based renderer for a rendering class last year and it can render a room like the one you showed in a couple of minutes.
The reference you are looking for is:
Realistic Image Synthesis using Photon Mapping
By Henrik Wann Jensen
He is the guy who got the technical oscar this year for being one of the inventors of a method to render materials which display subsurface scattering, e.g. skin and marble.
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.
You could cut your rendering time down to about 1/200th sec by employing the following hardware:
...whatever that blurry thing top right is supposed to be.
old cookie tin
2 marbles
cheap disposable camera and a...
The resultant time saving could be usefully employed learing how the gif file format works.
A pizza of radius z and thickness a has a volume of pi z z a
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