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."
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.
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
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
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?
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.
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.
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?
This is true for pure number crunching where you spend a lot of time in loops.
Java is quite good at that.
Now, try writing a real application. One with an interface, one that does real work and spends most of its time interacting with a user rather than banging numbers. Run the test again and you'll find that C++ is significantly faster than Java in this situation because Swing is slower than arthritic snail carrying a small planet and Hotspot isn't good at optimising the sort of stuff a general program has to do.
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
It seems like your trying to say that the C compiler must produce 16 bit code for a 386, but the java JIT compiler will produce 32 bit code.
The problem with that is that the 386 is 32 bit! You're comparing a C compiler making 16 bit code for a 286 to a java compiler for a 32 bit platform. Unless you know of a java runtime that works on 286 or worse processor, that's not a fair comparison.
It's still silly anyways. Compilers can produce code tuned for different CPUs. There is no need to compile for the lowest common denominator. When I compile scientific programs at work, I sure as hell don't compile for a 286. I don't even have a compiler than can produce 16 bit code! I always tune the compile for the specific CPUs.
Yeah, tools like this are excellent. In the astro community, they use a tool called IDL (interactive data language, I think?) which is similar. High level constructs, with lots of big primatives to get you very fast computation.
Perl has an excellent tool called PDL that does roughly the same thing, and is used by the Perl/Gimp interface, yeilding some wonderful possibilities.
That said, Java was the right choice for this. Java may have poor systems integration and a host of issues that arise from that (i.e. Java's platform agnosticism, which actually turns into a sort of single-platform dependence on itself with little or no integration with its actual platform), but when it comes to handing thousands of people a program that is going to run mathematical calculations EXACTLY THE SAME WAY on every machine, Java has Python, Perl, Ruby, C# and a host of other high level languages beat because it allows you to enforce very specific constraints on how the math will be done. All of the others just provide you with varying degrees of abstraction on top of your native execution models.
Once Parrot is done, I suspect that more languages, ported to run on top of Parrot, will also offer these constraints as optional features, but time will tell.
If this is true then why is Java so goddammed slow still? Why is it every medium sized or above Java app I've used performs like crap compared to a similar one compiled in C++ or simlilar languages? It just seems to me there is a major disconnect between what the Java adherants are claiming and the reality I am faced with every time I use a Java app.
All those moments will be lost in time, like tears in rain.