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."
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
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?
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.
MD5Crk.com has an applet on their site that does distributed calculations so long as it is visible in the browser (and assuming that you have specifically permitted it to do so). They are trying to find a collision to demonstrate that MD5 is insecure.
This is great for a simple calculation that returns simple results (e.g.MD5), but probably wouldn't work in a situation where you have to have lots of data to work from. Of course, if you can break it down sufficiently, it might work, and I guess he has already done the work in figuring out how to break it down and recombine the results.
See MD5Crk for the applet in question.
It depends. If you use Java Objects instead of C / C++ int, then probably yes. If you use Java int instead of C++ int, then the speed is about the same. And you will find absolutely no difference if you need floating point.
I did quite a lot of C++ and Java programming. At one point, I thought: 'oh, I have now a beautiful and quite fast Java fractal application (mandelbrot), let's convert that to C++ and it will be even faster.'. It was even slower in C++ (probably because of the C++ compiler, Visual Studio). And that was quite a long time back. The link is: http://users.quick-line.ch/thomasm
I'm just guessing here, but it sounds like he's doing forward ray-tracing on the whole scene. Conventional ray-tracing traces the light rays backwards, i.e from the camera/eye out into the scene and finally back to the light(s). The only problem is that it doesn't really do caustics or diffuse lighting well. POVray faked caustics in version 3 (IIRC), and Radiance has done excellent diffuse lighting using a monte-carlo simulation for about a decade. In recent years photon maps have also developed. These apply forward ray-tracing to selected areas, usually selected refractive and reflective surfaces. The impact points for the photons are recorded and then used in a regular renderer (either scan-line or ray-tracer) as an additional source of light.
Again, it sounds like this guy wants to do this to the whole scene, and to a very high degree of precision. I'm not sure why. Any decent ray-tracer would get a 99% solution in a fraction of the time. Hell, in good hands even scan-line renderers can get a 90% solution even quicker, just look at all the motion-picture visual effects (and whole movies) rendered with Pixar PRman. Most effects don't even need a good ray-tracer to look realistic to most people. Unless he's rendering something more interesting than shiny balls and a mirror, or going to do something interesting with the trillions of photons (near-real-time camera-independent renders?), I really don't see the point. It's still kinda interesting though, if only because of the scale of the work. It might lead somewhere, you just never know.
I don't know why Java is so slow, but I wonder if it has something to do with memory requirements/managment?
All the Java apps I use that are not trivial tend to eat at least 100Mb of ram, and sometimes several hundred. They also tend to stomp all over my poor CPU, which, at 500-1000Mhz, really ought to be fast enough for most things (seriously, I'm not trying to crunch SETI data or crack an RC5 key here).
I attribute most Java slowness to poor programming techniques. Its got to be, since Java programmers are always telling me how fast the code really is; it must just be that most Java coders are so crappy that they drag that blazing fast JVM to its knees.
Java has been out for how long now? Nine and a half years. A whole freaking decade! Yet every damn time someone mentions the poor performance of Java, the same standard excuses are trotted out, with an exhortation to use the new and improved Java:
1) That's because you're using Java 1.x. Use Java 1.y instead, it's got all these new performance features...
2) That's because it's using the old GUI toolkit. Use the new one instead...
3) That was with the old JVM. Use the new one...
4) That was with the old JIT. Use the new one...
5) That's because you're using a slow XX Hz CPU. Don't be a tight wad and upgrade to a YY Hz CPU intead...
Why should I believe you this time? You might actually be right, but I really don't care anymore. You had your chances, nine and a half years of them, so I'm not giving you any more.
Don't blame me, I didn't vote for either of them!
I've been sayign the same thing since 1996:
That's because the programmers don't know how to program.
I was making systems that output efficient usable applets in 96. I've taken serverside systems that could barely handle a single user to handling 1300 simulataneous users. My experience has been very few people know how to code usable Java, and when their Java is unusable, they give up and say "it's because Java is slow." Of course, I never really believed that since I played a Quake map via an applet on a 200MHz Pentium Pro. I figured if whoever did that could get 30fps, I could have my lists drop down in a timely fashion.
-no broken link
All those are reasonable claims. If you came bitchin about Slackware 3.4 I would tell you to go use Slack 9.1. You can say that all MS software is shit, but you should bitch about XP, not about win95. Same thing happens with Java.
The biggest problem is that Microsoft shipped a shitty 1.1 java version for many years, thus people who thought they had java, just had a 4 year old VM.
Java is faster where it matters, debug time!! I as a programmer am very happy not having to deal anymore with alloc's and arrays out of bounds!
As most of my current work has a web interface, I like java servlets, because it is easy to program complex systems in java, and _for_me_ it's easier to maintain than php. Servlets are real fast.
Anyway, java graphical interfaces are very slow. But compared to what? Windows, which takes forever to load its graphical interface? or kde, which takes a looong time intializing some DCOP crap when I want to load the only kde application I use? or gnome? well, gnome is not that slow, but it is slow anyway. I think that anyway, on load times, graphical java application are not the slowest, but among the fastest loaders.
Now it comes to the issue of hardware acceleration. Windows graphical interfaces are fast because they use some acceleration that slow graphics cards (SIS, anyone?) provide, so windows interfaces are not thaaat slow. When you have a decent graphic card (not a gforcefx5950, just a matrox g100 or a savage4, or a TNT) you start to see that maybe it was not that slow. When you get a faster card, you start to understand that mabe java is just as fast in the desktop as it is in the server, it just was slow in its old version , with old video cards, and in windows, compared to others that were optimized for that situation.
-- End of rant. --
Java was always fast, on the server.
Java was slow, on the GUI, in windows, with old video cards.
Java is fast, on the GUI too, in any platform, with "new" video cards.
And, if you don't want to try it, well, I think it's your loss, meanwhile I am going to finish my own photon mapping renderer for java, so I can match up my times with this guy's.