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
Thanks for the mirror -- the site is down. I have to admit, the image is not what I'd expected.
The story submitter talked about simulating a number of photons, which made me assume this was a simulation of quantum mechanics or perhaps of quantum fields.
But the image looks like it is somebody's ray tracing project. This is geometrical optics, and not quantum mechanics. The term "photon" should not be used in this context, as it is misleading.
Ray tracing is a discretization strategy used to approximate a (usually continuous) distribution. In this case a Monte Carlo approach would evidently be used...
Whereas the term 'photons' implies field quantization. This is a much more complicated situation than the rays used in geometrical optics.
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.
Good thing the other half of the world is in winter then, isn't it?
Banaaaana!
FP ops in Java are incredibly slow and broken.
Originally presented 1 March 1998
and ONLY 6 years have passed... no way they could have fixed any of those FP ops that were broken.
These days, processing cycles cheap, programmer time expensive.
Are you a project manager or something? He's asking for a 'zillion' machines to run it on, so processing cycles are not quite that cheap it seems.
Why would anyone want to use Java for something like this? That's like buying a Ferarri and trying to race it after disconnecting half the spark plugs.
.NET, are examples of what I call Gate's law. Gate's law is the counterpoint to Moore's law. Moore's law states that speed of new computer hardware at a given price point will double every 16 to 24 months. Gate's law states that the efficiency of new computer software will be cut in half every 16 to 24 months. This is why we have to have desktop systems with enough raw power to simulate nuclear explosions just to run Word and Excel at a decent clip. To be sure there is going to be some loss of efficiency due to newer programming strategies that attempt to maximize code maintainability and speed of development, but I seriously doubt that these factors alone are enough to account for the way that most current software packages waste system resources. The only sort of software that still operates at a respectable level of efficiency is computer games. The fact that games are the most perfect example of Gates' law in action would be ironic if it were not for the quantum leaps that have been made in game design over the past quarter century. We've gone from PC-Man to the Lawnmower Man in just under 25 years. Packages like Word should not rightfully require computers with VR-capable speed and memory just to run. Unfortunately they do.
I am not a fan of Java. I don't have any problems with the language itself. What I have a problem with is the fact that it is crippled by the lack of native compilers. And by that I mean comprehensive compilers that work. Something like gcj that won't compile everything that Sun's "compilers" will just doesn't count.
Interpreting bytecode for the purpose of cross platform capability is all fine and good. There are times when this is very beneficial. But not having the ability to target your programs for a particular platform is insane because it kills any chance at implementing an efficient solution for anything. It is the primary reason why I don't use Java for anything. I'm not going to use a language depends upon a virtual machine that eats 20+ megs of ram just to run hello world...slowly. And that is PER INSTANCE mind you. Shared libraries that eat up tons of ram are one thing, but having multiple programs whose memory footprint is such that they might as well have been statically linked is quite another.
Then of course there is the speed issue. The lack of native compilers is what doomed IBM and Corel's attempts to create Java-base office suites. They could write the code, but running it was another matter altogether. I suspect that the projects at both companies were thought up by suits who bought into Sun's marketing. No one but a suit would believe that you could create something as complex and resource hungry as an office suite using an interpreted language.
Java and especially
I'm sure I'm going to get flamed for this post, but then if I cared whether people bitched at me I'd just keep my mouth shut wouldn't I?
Java advocates are perfect examples of the old adage that if the only tool you have is a hammer then every problem looks like a nail. Java has its uses and its place. The problem is that far too many people want to use it for things that it is not well-suited for. If we can get good optimizing native compilers for the language then most of the problems with Java will disappear and I'll have nothing but good things to say about it. Till then I'll stick to C and C++ thank you very much.
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
Am I the only one to see that the Emporer is wearing no clothes? That's a whole lot of CPU power being used. For what? I pretty simple looking ugly raytraced picture. Aren't there more worthy causes out there to donate our CPU cycles to?
Wonder why this got modded up Funny.
:-)
It is simply true, and so obvious it struck me immediately too.
Java for intense computation? Months? Go away
Nothing against Java, but it isn't suitable for this.
Not really. There is an overhead in java, indeed, but it's caused mainly by objects management. To perform pure calculation, about any language will perform the same. The limit here is the CPU.
Try to factor a big number in C, C++, java or fortran, it will take exactly the same time. The few seconds difference you'll get after a day of calculation are the language overhead that occurs between calculation loops, totally irrelevant when what you do is _only_ those calculation loops (a situation that occurs rarely in traditional development, granted).
Of course, the guy wants his program to run on several kinds of platform but probably cannot afford to develop and test on a lot of OS & machines, so Java seems to be the proper solution.
Kirinyaga
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.
This is because his web server is claiming that the MIME type of the GIF is "text/plain" .gif instead of .GIF it wouldn't to that. But his server should work either way.
I bet if it was
Time to edit httpd.conf
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.
Of course SWT is faster than Swing. SWT interfaces to the native toolkit, which is, of course written in C or C++. In Java, the only fast method is a native method.
I've still yet to be shown an example of a Java program that runs faster than an equivalent C or C++ program, whereas I've had a wealth of experience with things being around the other way (one extreme example was Java: 8 hours, C: 30 seconds).
The Hotspot argument is hot air, since the time you spend re-compiling the whole program (JIT of course, which is closer in actual behaviour to JustTooLate) will in most cases outweigh what tiny improvements you can get in the part of the program that matters for performance. Remember that 90% of CPU time is spent in 10% of the code.
Dammit this is infuriating!
Stop comparing java to c, it s so.. last decade!
Sun have excellent c compilers. Thats really all Java is these days. Its a load of stack instructions that are completely platform neutral.
that are optimized according to the particualar target platform and translated into c binary.
This translation is often worth the cost because of the optimizations gained.
If you cannot understand this, then you will not grasp why J2ME CDC/CLDC is generally the preferred solution for mobile communication and embedded software....
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.
gcc -msse -msse2 -mfpmath=sse -march=pentium4 -O3
Having been exposed to so many different languages, I'm not quite understanding the selection of Java for processor intensive applications when so much more is offered - all the while keeping the spirit of platform independence. Not to troll, but if I'm running processor intensive simulations, I want to take advantage of the processor power available to produce a result in the least amount of time.
.NET's CLR compiler)? Nonetheless, Sun has much learning to do to make Java the "answer to all problems" language it was touting in the later 90's. While people may believe that opening the source of Java is the answer, I firmly believe that like C++, Java is beginning to show its age.
.NET platform) in the last few years compared to Java in the first few years.
Being an regular software developer and a web applications developer, I have found the versatility of Java does not outweigh the performance penalty attributed to emulated code execution. Java (historically) does not, in my opinion, adequately take advantage of new processor features (MMX, SSE, etc.) to accelerate code execution. I believe, in fact, it was only announced recently that Sun would be aggressively adding better MMX and SSE support in the virtual machine. Even poorly written C++ code will be optimized by a smartly written compiler to run very fast.
Could Java's lack of aggressive optimization be due to Sun's focus on reality being away from the most popular instruction set on the planet for personal computing (x86)? Further, why re-emulate the same byte-code over and over? The JIT has to produce the equivalent native language codes to get it to run on a particular processor platform. Why not cache these codes (like what DEC did with the Alpha's x86 interpreter or like
There are emerging languages and technologies that are attempting to complement older languages, provide the wealth of structure that Java has laid out, but still build further to make it that "answer to all problems" language. Sun's interdicting hold on Java makes its development as fast as its developers and contractors can muster. Other companies or open source communities have the potential to make great strides in rapid development. Look where C# is (upon the Mono or
A side arc (experiment, if you will) would be to port the application to C++ and to C# (CLR) and run the calculations on both Windows and Linux - take a comparison against Java running on those two platforms. I believe it is quite obvious WHICH language(s) would be declared the winner. So, instead of us having to dedicate a few trillion cycles, maybe one trillion would do.
Ayup
Funny, I allways thought that the 80386 was a 32 bit machine, I thought it was actually the first *86 to have has the EAX register and the STOSD instruction (but strangely not the STOD instruction)
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
and what if the user can't compile for some reason?
Yes we know it CAN be done, but what is the PRACTICAL solution?
Sigs? We don't need no stinking sigs!
I'd do it if I were allowed to get the source, then compile myself.
I love this argument. I hear it from more than a couple people who "want to know exactly what that programmer is up to" before they run it on their own machine. None of them actually read the code. In reality, they want people to think that they can comprehend someone else's code, while truly only proving that they can run a makefile.
I write clear, organized code and I place clear, concise comments where needed. I work with some intelligent, organized people who do the same. The reality is that, even being fully comfortable with their coding styles, I find it very tedious to read their code... even when I know exactly what they're attempting to do. Somehow, I doubt that most people, even programmers, could comprehend the math that goes into the typical raytracing program, let alone one developed by a complete stranger.
I don't buy the idea of having to take a significant performance hit now and for the forseeable future for the sake of hypothetically being able to run my program faster in 15 years time on a hypothetical machine that doesn't exist yet.
Besides, I have the source to my program; I can recompile it for the new architecture in 15 years' time.
Only for workloads that are specifically chosen to play to Tomcat's strengths. Anyone can cook a benchmark, but it takes a real designer to design a webserver that's really faster for real-life workloads. You'll never be a real designer, from what I've seen.
This has got to be an urban legend of some sort. I cannot see how Tomcat would ever be faster than Apache. If what you say were the case, why would people go through all the trouble of putting Tomcat behind Apache with mod_jk, etc to seprate static content serving from dynamic requests?
I can also say that my unscientific tests of Tomcat vs Python running under mod_python showed no clear winner. The point is that Python does not proclaim to be ultra-fast, while Java does.