Can You Spare A Few Trillion Cycles? 570
"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."
More distributed processing (Score:4, Insightful)
Java? (Score:4, Insightful)
Oh boy... (Score:5, Insightful)
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.
Re:Java? (Score:5, Insightful)
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).
Re:Java is a slow cruncher (Score:5, Insightful)
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??
Re:Mirrored, just in case (Score:1, Insightful)
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.
Trust? (Score:5, Insightful)
which would you rather run? (Score:5, Insightful)
Re:Java is a slow cruncher (Score:3, Insightful)
power consumption (Score:5, Insightful)
I measured this in 1997 on some kind of AMD K6 machine. IIRC, running dnetc doubled the power consumption of the machine.
Enter applet. (Score:5, Insightful)
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
Anonymous grid computing (Score:5, Insightful)
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.
Re:Best time is Winter (Score:3, Insightful)
Re:Java is a slow cruncher (Score:2, Insightful)
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.
Re:Java is a slow cruncher (Score:1, Insightful)
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.
Java? No wonder you need cpu cycles. (Score:0, Insightful)
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
The Emporers New Clothes (Score:1, Insightful)
Re:Java? (Score:4, Insightful)
I think the primary reason is that there are enormous numbers of numerical routines in Fortran that are extremely well debugged and validated.
Change to other languages and those routines must be rewritten, redebugged, and revalidated.
Re:Oh boy... (Score:4, Insightful)
False, on all of the above.
For "networking", users will manually send him their cache directory (as the FP explicitly stated). As for threading... To do what? He wants to run a completely straightforward trajectory simulation, iterated a few "zillion" times. I'll admit that I have a bias against most uses of multithreading and consider them inappropriate 99.9% of the time, but if you can even force them onto this project, you need to go back to the drawing board.
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.
Umm... Yeah, whatever. He wants to run a CPU-intensive background process, performing a totally straightforward set of calculations, and nothing else. No GUI (beyond a few simple controls to make it play nice), and nothing server-side - sounds like a perfect candidate for anything but Java.
Personally, I'd say this even sounds like a good candidate for hand-tuned assembly. But then, at least from my alma-mater, they don't even require that to graduate in CS anymore. Sad... And people actually wonder why tech jobs keep heading for India. Well, the FP and you just provided a nice answer - Using Java for a tightly CPU-bound problem? Using threads for the same (Ever heard of "cache consistancy"? Yet another reason to avoid multithreading in a program of this nature)? Why not just downgrade to a 486? Same effect, less complex.
Re:Java eh? (Score:2, Insightful)
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.
Re:java 3000 times slower (Score:2, Insightful)
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.
Re:Java is a slow cruncher (Score:3, Insightful)
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.
Re:Real URL to image (Score:3, Insightful)
I bet if it was
Time to edit httpd.conf
Re:More distributed processing (Score:4, Insightful)
If you don't want to pay however much extra it might be, you don't have to participate; nobody's forcing you.
Re:Java can be faster then C sometimes (Score:4, Insightful)
Not only that, Face the Facts (770331) [slashdot.org]'s last three or four posts are word-for-word copies of other people's posts, copied from anti-slash.org's [anti-slash.org] "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.
Re:Java eh? (Score:5, Insightful)
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.
Photon Simulation vs Raytracing (Score:4, Insightful)
In what major way is photon simulation different from ray tracing?
Re:Java eh? (Score:3, Insightful)
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.
Re:Oh boy... (Score:3, Insightful)
You do. If you can't write assembly language, then you will never be as good a programmer as those who can. Whether you actually use it is another matter. I haven't had to actually write anything in assembly language for well over a decade. But the fact that I could if I needed to helps, even when writing in a higher level language, because I have some clue about what's going on under the covers.
Re:Broken link, java jab (Score:4, Insightful)
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.
Re:Java eh? (Score:3, Insightful)
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.
Re:Java eh? (Score:2, Insightful)
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....
Re:Java eh? (Score:5, Insightful)
Re:Java eh? (Score:3, Insightful)
gcc -msse -msse2 -mfpmath=sse -march=pentium4 -O3
Speed an issue - then why Java? (Score:3, Insightful)
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.
Re:Oh boy... (Score:5, Insightful)
Besides, by writing in Java and not hand-written assembly, he gets to run it on machines like mine, which probably weren't the original target platform. The name of the game in distributed processing is to use as many spare processors as possible, even if some are slow. An hour of work to promote his project is more likely to pick up 10% more (or 1000% more, with \.) CPUs than an hour of hand-tuning assembly is likely to get 10% more speed out of a particular processor.
Does anyone check before they moderate? (Score:3, Insightful)
Re:Java eh? (Score:3, Insightful)
Yes we know it CAN be done, but what is the PRACTICAL solution?
Re:More distributed processing (Score:1, Insightful)
Yeah, sure... (Score:3, Insightful)
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.
Re:Java eh? (Score:3, Insightful)
Besides, I have the source to my program; I can recompile it for the new architecture in 15 years' time.
Re:Java eh? (Score:1, Insightful)
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.
Re:Java eh? (Score:3, Insightful)
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.