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)
This is a wonderful thing to see. Distributed processing is a wonderful way to spend those extra clock cycles that most of us have, while at the same time benefitting someone else. I really hope to see more projects like this in the future.
Emailed this to the editor, but something must've gone wrong.
The URL to the photo soup image is missing the 'www'. The image can be seen here (you may want to do a 'Save Target As', as the mime-type seems to be a bit off).
nothing against Java it has its place, but for something this CPU intensive, it seems like you'd be wasting CPU cycles. This sounds like a job for C.
Kent Simon Multitheft Auto
Use ISO 8601 dates [YYYY-MM-DD]
I don't feel like donating a few trillion cycles to produce an image that says "The page cannot be displayed". Possibly if you made it say, "The photons cannot be displayed", I would think about it.
=P
The best time for these project is in the Winter time. Because, that's when I have my heater on. And if my CPU is running 100%, then the heat from it will help heat up my appartment rather then the heater needing to kick on.
I mean, I don't mean to belittle this project. But for all grid computing projects, there is a better time and place for this in my opinion.
Life is not for the lazy.
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.
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
FP ops in Java are incredibly slow and broken.
Er, do you have any more recent numbers than a lecture from 2001, originally published in 1998??
Being bitter is drinking poison and hoping someone else will die
Either I'm suffering deja vu, or this has been posted nearly verbatim before in a previous discussion of Java vs. C.
Astounding.
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?
What's to insure the trust within this project? Call me a cynic, but what's preventing some jerk from swapping some bytes in his set of data before sending it off, thus, rendering your combined result different from what you intended?
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.
Erm, that article is more than SIX years old, and one of the guys that wrote it now works for Sun. Apparently FUD is not something Microsoft has monopolized yet..
to^2
The fact of the matter is that a machine with 100% CPU utilization uses a lot more electricity than one with low utilization. The extra cycles aren't free.
I measured this in 1997 on some kind of AMD K6 machine. IIRC, running dnetc doubled the power consumption of the machine.
Applets are bad for a LOT of things. But this is one thing they would work really well for. Using an applet:
1. The client PC runs the program in a sandbox
2. Most client PC's don't need additional software installed (if written for JDK 1.1)
3. The user does not need to know how to invoke a Java application
4. There's no administrative overhead in iniating the application, just go to a URL
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
First there are resource allocation problems. The OS has to provide a sandbox with strict limits on all resources: memory, filesystem, and networking, as well as CPU time. It's fine with me if the "background compute demon" takes 25% of my processor but I don't want to take more than 10% of my memory.
Then there's the security issue.
But I see another problem which is even harder to solve: the tragedy of the commons. Consider a university campus, and suppose that anyone on campus can submit jobs to the Campus Grid. You come in the next morning and see that there are 10000 jobs in your grid queue, and 9800 of them are encoding random people's MP3's.
The problem is that if you give free resources to a large anonymous community, it takes only a few of those people to suck up all the resources. So you need some way of identifying everyone who submits a job, and some way of charging for the jobs.
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
Sorry, but the 80386 has 32 bit stack and move operations. Generally, people compile their program for 80386, because almost all optimizations that can be done automatically for Pentium does not harm performance on 80386.
If your program has a noticeable performance benefit from using SIMD instructions, you can move the relevant functionality into a shared object, and distribute the program with several versions of it, and dlopen() the correct one at runtime. The absence of programs that actually bother doing this, can serve as an indicator as to how big the performance benefit from SIMD optimizations really is.
Does that explain it better?
The world will end in 5 minutes. Please log out.
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!
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.
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.
1 Month on 100 sparcs? Peanuts! In my research simulations usually take (depending on the problem) up to 6 months on an average of 150 workstations (and some runs on large clusters). You wonder what I do? Spin glasses!
Spin glasses are systems in with the interactions between magnetic moments are in conflict with each other. These competing interactions make these systems extremely hard to simulate at low enough temperatures. If you have a linux box sitting around idle which is fast enough, let me know and I will provide you with some samples to run. Current project: 100 - 300 samples, each takes ~ 10 days on a 2.4 GHz Xeon... For information on how to contact me, go to duamutef.ethz.ch. Of course your name will be mentioned if you compute a considerable number of samples!
And pigs _can_ fly.
Here's the deal: when you perform fp ops in Java, operands go where? The _Java_ stack which actually resides on the heap. In C? Usually registers. The JIT register allocation algorithm cannot possibly optimize like a good C compiler can because of the purely stack-based architecture. What's worse - after each fp op, the CPU must fetch byte codes from the class pool which also resides on the heap. So farewell L1 cache line optimization (and sometimes L2 caching)
Note that most benchmarks are too limited, the Lx cache line problems appear in non-trivial applications with a bit more more than a loop doing fp addition.
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
Either I'm suffering deja vu, or this has been posted nearly verbatim before in a previous discussion of Java vs. C.
Not only that, Face the Facts (770331)'s last three or four posts are word-for-word copies of other people's posts, copied from anti-slash.org's "database tool".
Note only that, but anti-slash.org has posted links to his posts, asking their members to mod him up, with the notation "another karma whore account" -- which implies he's karma whoring in order to get mod points in order to troll.
(Implies but doesn't prove: anti-slash.org at one point asked its members to mod one of my posts up, why I'm not sure.)
But whatever Face the Facts (770331)'s motivations, his posts are plagiarism and he's a plagiarist, apparently not talented enough to write his own posts.
Mod him down.
Opinions on the Twiddler2 hand-held keyboard?
The parent post is stolen, word-for-word from this post by SharpFang (651121).
It was stolen via the anti-slash.org database
Mod parent down.
Opinions on the Twiddler2 hand-held keyboard?
I've looked on the dude's web page, but there's nothing there that tells us what this is about.
In what major way is photon simulation different from ray tracing?
Specialist Mac support for creative pros, Melbourne
Everyone works on the whole picture at once, but simulates different randomly-emitted photons. All you need is a different random seed for each client, which is trivial to manage.
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.
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
This thread is already full of very knowledgable people expoudning at great length as to why Java is not slower (and infact, is often faster than "native code"). Therefore, I will not waste my time writing an indepth response to those who would argue that 1 + 1 in Java is somehow slower than 1 + 1 in C/C++. This post does that quite well. What that comment does not do, however, is explain why some Java programs do, in fact, feel slower than native programs.
I'll simplify this as much as I can without diverging from the technical truth too much. Most complaints that Java is slow come from two sources. First, you must wait for the virtual machine to load, and depending on the libraries used by the program, that can be costly in terms of IO, which is always very slow. Second, Java's GUI toolkits are fairly heavy weight--they do a lot and many programs take advantage of much of the functionality they provide. I won't embark into the details, but to those inclined to find out why should read more about Swing and what Java2D libraries offer. Because of all they do, many Java programs with GUIs feel a little sluggish. Of course, keep in mind that most software sits idle 99% of the time while the user decides what to do. So otherwise, Java code that is not bound by user response time is very fast.
One quick post script: because the Java language is object oriented, complex software will do a great deal of memory allocation and garbage collection as objects come in and out of use. That too, is very expensive. However, there is no reason that you have to use the Java programming language to code for the virtual machine. Case in point: Jasmin. In theory, you could write compilers that generate JVM bytecode from any language (and a former professor of mine is currently in the proceess of writing a book that explains precisely how to do that).
Join Tor today!
Second, Java's GUI toolkits are fairly heavy weight
This is probably why SWT came about (in part thanks to IBM).
The first application to use SWT, Eclipse, doesn't feel like a java application because it's using native widgets, which gives the GUI a very snappy response.
If the only strong reason you have avoided programming applications in Java is because of their slow GUI response, I suggest looking into SWT. =)
Please consider making an automatic monthly recurring donation to the EFF