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.
or bad DNS? Either way, I can't resolve.
political_news.c: warning: comparison is always true due to limited range of data type
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).
yes, computers are now 3000 times faster, but with java 3000 times slower than C, there won't be much difference...
Brand new article and it's already slashdotted to hell. He must be running the webserver on one of those old crappy sparc machines he talks about.
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]
It's a Java Trap.
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
It's just a graphic, so I doubt it will go down, but here is a mirror just in case.
http://www.antigamer.com/DRUN.GIF
Don't sweat it, I got a copy of the linked image.
:-)
The original was silly, too -- it sent back the image as Content-Type: text/plain. I don't understand it at all, but since the server is toast now, it doesn't really matter either way.
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.
Give me a client I can run on my (Series 60) mobile phone, just to say that I have, and I'll think about running your apps. Meanwhile, for my PCs I prefer D.Net because of its seriously optimised core -- if I'm going to donate CPU cycles I want to know they're not being wasted by computing overhead. (Usefulness of the project itself aside.)
Although it sounds like a good idea, JAVA is not the ideal tool to build the app for that purpose. As other guys said, java is abs('slow'). C is the best choice (except if you code in machine code). I know that java should be the most portable language, but the awful speed is a heavy downside. Anyway I think if you want to make a good film, you should find Pixar, Dreamworks or Disney -- because they have a render farm.
By the way, are you requiring openGL or something like that to speed up the raytrace?
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
"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."
I wonder if this works better than pictures of naked women...
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
I could spare a few cpu cycles during the day while I am at work and from about 1am till I get home from the office :-D
It was slashdotted even before it went public! Or perhaps the URL is bad?
Martin
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?
Hmm, it would be very interesting if it could be used as a form of payment. For example at a University you might be able to run the a client that would do the number crunching on some of the on campus research projects. In return you'd get $500 waved off of your housing fees. The money that the University didn't have to pay to buy another super computer could be used to help lower tuition, or cost of books or cost of food. On a more global scale, you could, say get DSL through AT&T, install AT&T's distributed computing client and get $10 a month knocked off your bill.
It would also help us geeks justify the rediculously fast hardware we buy. It would almost make computer hardware closer to an investment than a money sink. Now I'm just dreaming.
-Mr. Lizard
^I'm with stupid.^
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?
This image looks like something you could do in under 500bytes of PovRay code... Anyone cares to comment on the difference ?
Non-Linux Penguins ?
That's like what... 3-4 seconds? A few trillion being 12-15 seconds these days. Are you sure that's all that's required?
Government of the people, by corporate executives, for corporate profits.
Can anybody explain me what in the world can be learned from the picture like that?
Second, to add to discussion of: "java is slow": Actually, thanks to JITs, it can be acceptably fast (near to C speed, sometimes even faster(!)), but, at least once upon the time Java's main problem for floating point calculations was described in
William Kahan's "How JAVA's Floating-Point Hurts Everyone Everywhere" (http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf)
Does anybody know the current state of the problems described there?
The human eye can detect a single photon, thats enough to trigger the rest of the stimulation pathways.
:P
But to actually see a star, well, i'd guess more than 1.
Of course if you put any kind of counter on it and post the results you could get various hardware hackers competing. Getting a pretty picture might be more interesting than RC5 cracking.
He chose Java for portability, not performance.
AC
Thought I recognized it. I wasn't sure if I was losing my mind or if it was just getting a bit too late. (4:30am here, lol.)
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
Who's interested in a technique/algorithm that takes many month-machines?
Personally if I were a siggraph reviewer I'd reject this submission as "impractical".
Now is the right time to publish the 1994 algorithm, and when computers get another 3000 times faster it will be the right time to publish *this* article.
This is assuming that no one can do better with less in the meanwhile, which is probably what will happen.
So this stuff is worthless now, and will probably be worthless in the future too.
the .gif is slashdotted at frickin' 3:30am
Your site is returning gibberish on my Mozilla, and here's the wget output...
.gifs as plain text file and screwing up browsers.
[snip]
Found www.cpjava.net in host_name_addresses_map (0x8074330)
Registered fd 3 for persistent reuse.
Length: 71,283 [text/plain]
[snip]
Apparently your server is sending out
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.
Numerical Python is great, but not necessarily suitable for this task. It's good when you're performing the same operation on the items of a vectors. When the vectors are long enough it indeed approaches the performance of C code. But in ray tracing every photon can take a different route depending on what it hits. I'm not so sure Numpy would perform nearly as well in this case.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
What is it with the moderators today?!?!
People are posting things like "gee this is a great idea" and getting modded as a Troll, people are
posting simple and obvious and funny jokes and being modded as Flamebait!
?
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.
This sounds similar to what some people (such as Entropia) are attempting on "The Grid" (see The Globus Project for more wiffly utopian detail on that).
Of course, it also leads to problems. Like security - how much can you trust an autonomous node to return correct data?
To what extent is there scope for malicious nodes deliberately returning incorrect results? And given the autonomous nature of the nodes, they can turn on and off (crash, be turned off) at any time and their performance will fluctuate depending on what other load (that you can't control) is placed on them, so you may want checkpointing and/or redundancy going on.
Which leads to the question of how to co-ordinate it all to maintain consistancy should you wish to roll back. All very app-specific, to be sure, but it's the detail that prevents stuff like this from being used by more people.
Blah!
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 agree, right now the people who would do this either:
:)
run SETI@home already
or don't really like the idea of someone else benefitting from their pipe.
It's very similar to the cable modem "hack" that can suck bandwidth out of a "cluster" of served modems...the people who would use it would tend to abuse it.
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
> pop AX
> STOSW 0x0005
> pop AX
> STOSW 0x0005
Are you still using Windows 3.1 + DOS 6.22 now?! No one compiles a C into "pop AX" in the 21st century x86s! We're all using the 32-bit registers instead of the 16-bit ones (i.e. EAX instead of AX).
If your compiler is still giving this kind of output, grab a new one at
http://gcc.gnu.org
Wouldn't it be just as fast to stud the entire wall with cameras? They're not even real, so you can have as many as you want in one place, and just duplicated the ray if it hits more than one lens.
I think this is a great idea! What is needed is some not-for-profit organization to oversee the open source project and ensure that all data that goes on the network is digitally signed and encrypted, to protect the generous souls hosting nodes as much as anything else. Who would be willing to take a crack at this? It's way out of my league right now, maybe in a few years, though...
Like what I said? You might like my music
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.
Now, your C compiler will see that you want to store a 32 bit value, but has to generate code for a 386.
Not if I distribute in source format.
Hotspot is also capable of analyzing the running code and regenerating even better assembly that would perform poorly in other circumstances. For example, let's say Hotspot notices that the bounds can't be exceeded on an array. Well, Hotspot will then recompile to remove the bounds checking.
In other words, your program can't take full advantage of whatever processor it's on because Java keeps analyzing/recompiling the code. The overhead is unacceptable to begin with (I can't imagine what it'd be like running this on a 386), but it's also variable. If you need to time your algorithm, Java with Hotspot isn't an option.
Lastly, if you bother to swing by Sun's Java page, you'll notice that the 386 processors aren't even supported. If you need to run your Java program on a 386, you're shit out of luck.
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.
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.
Optimising compilers can do much the same thing for C programs. Hotspot JVMs don't have an advantage over all C programs - just mostly those compiled with no optimization. I am not sure though, about the advantages JIT profiling gives to Java programs and whether some C compilers offer the same features to C programs.
I recall an article by Intel engineers (recent DDJ I think) that described how an executable compiled with their compiler could detect the runtime platform and choose among code-segments optimized for different platforms. These compilers also automatically 'vectorize' non-vector instructions - i.e. they use MMX/SSE/SSE2/3DNow with unrolled loops.
By jove, I think he's got it. The "www." addition did indeed work, aye what old chap!
Hey, take a 3GHz CPU, 3 billion cycles each second.
Assuming 1 trillion = 1000 billion (which isn't true in my native language, but I guess in english it is), you need ~300 seconds, i.e 5 minutes for 1 trillion cycles.
The article might be six years old, but Sun hasn't fixed it in that time. Indeed, one of the guys now works for Sun, but still we will have to wait for java 1.6,7,8,9? to see these problems addressed. No, 1.5 does not address it.
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.
On universities, 99% of computers run with nearly zero CPU load for most of the time. Now imagine, we install a "cluster server" on all networked computers.
Some universities, such as my own University of Texas at Austin, are doing just that.
The problem with God is that he thinks he's Richard Wagner
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?
well, if you don't have the source and the binary you got is for an old 386, then you're stuck. Te cool thing with java is that already bytecode compiled code can be optimised on the fly
if (!signature) { throw std::runtime_error("No sig!"); }
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!
It's just a number cruncher. There should be no OS specific code in there. Pure mathematical code can usually be ported simply by using a compiler for the OS targetted.
The parent has no idea what he's talking about, and needs to be modded down.
The generated code is not what makes Java slow; and given the example from parent's post, a c compiler (e.g. gcc) can also make the same optmization as a Java Virtual Machine and compiler.
What makes Java slow is the transition from bytecode to machine binary code: it takes time to translate and optimizes codes on the fly. This might be a moot point for some program, but there is also another reason why Java is slower: its garbage collector. Because of it, Java programs are guranteed to run at least 5% slower than C programs.
actually, java isn't too bad for number crunching since it involves lots of loops, which gives the JIT a good chance of optimising the code on the fly, things can actually roll on faster than c
if (!signature) { throw std::runtime_error("No sig!"); }
Ok. My assembly is a little rusty
Yes, I can definitely see that. You have a point, but you got just about every detail wrong. (80386 is 32-bit, stosw doesn't take parameters, using SSE doesn't yet imply proper vectorization, C wouldn't check for bounds anyway..)
Ahem... the compilation to native code is only done once in a optimization process :-)
You can notice that java programs become significantly faster within the first 30 seconds after startup...
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.
Especially with photon calculation speedups among other improvements in the beta release of POV-Ray v3.6, it would be interesting to do a comparison between the two photon models...
The Great Win32 Computer Language Shootout
While Java is not "unacceptably slow" or "1000 times slower" as some claims, it is generally slower than C and much more resource intensive nevertheless.
Actually if one wants to write this kind of math intensive apps, pure Java is really not the best choice. Even pure C isn't. He should think about implementing some of the highly used routines in assembly (no joke). And since photon tracing can be done parallelly, one would find the SSE and 3DNow! families of instructions useful.
And finally, besides the CPU, you can also try to do the calculations in your GPU. You'll need a new-fangled PCI-X card in the future to do the calculations efficiently tho.
Take a look at this site BrookGPU
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.
I'm running windows so its LoadLibraryEx() you insensitive clod!!. Seriously though, that sounds like a really good idea. I've not done real programming in assembly, if I ever do I'll keep that in mind.
My defense for programming in windows. Programmers solve problems. Pick something with alot of problems.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
The dude has >12 years programming experience, he isnt a 12 month jock.
Surely he should be able to code it in C in his sleep while he is drunk.
Hell, if you cant debug/code in ASSEM while on LSD, then you are just not good enough.
Liberty freedom are no1, not dicks in suits.
What proof do we have that this isn't some hideous spyware project?
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.
Hmmm ... thinking about it, I might grab my old Sparcstation IPX, get it operational once more and have it spare some cycles while doing ... nothing ... :)
To hell with ecology, I'll turn of a streetlamp on my way to work, that ought to level the waste of energy out.
Actually gcc would never generate shits like "pop AX" twice for a 32-bit number, as long as you're running it on at least a 386 and a 32-bit OS.
Saying C sucks just because some damned old compiler and OS don't use the 32-bit registers is nuts. It is mostly a mistake of the user, it has nothing to do with the language.
I'm not trying to be a pain in the ass or knocking what you're trying to do, but I don't get the point of the experiment. I'm sure that there is one, and I'm too dumb to work it out, so could someone explain it to me? I can see the point in protein folding, SETI etc but I can't figure out what the end result of this is. If someone could explain it to me, I might donate some CPU time...
Rather than have people email him to get the code, why not just allow them to download it themselves? Rather than require that people email him their cache directories at the end of it, why can't they be uploaded automatically?
What a shame.
winosi (winosi.onlinehome.de)
does all the submitters program does and more.
Its a "raytracer that works by shooting photons from lightsources and looking where they hit the scene. Its slow, but accurate and allows the mergins of multiple runs from different computers, too.
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
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.
Yes, that's why I said that's a moot point for some programs (mainly the ones that has only a small chunk of codes, while processing a large chunk of data).
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!
If not, I am proposing this methodology here right now (*cough prior art cough* - see, academia has ruined me forever now!). The crux of the matter, then, seems to be this: if there is not such a system, would you guys use/desire one? I know that I would, especially as I'm looking at doing some distributed programming myself here in the vaguely-distant future (read: when I get around to it *wink*).
If you want the maximum speed out of processor, surely assembly would blow the socks of ANY other language...
$0.02
I've never shoed a horse, but I once told a donkey to piss off!
This idea was floated at my university (Uni of Queensland, Brisbane, Australia). With a very large number late model user lab PCs available, and many simply idling (no user at all, only a screensaver).
The idea was shot down by the Physics department when they calculated the added cost of electricity and air conditioning.
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.
Have a look at the Condor Project - I think they're already on it :-)
In any non-trivial app, C is MUCH faster in this respect.
Not trying to debunk Java here - just pointing out that Java is a silly choice for number crunching apps.
"Of course, you will get mention in the article if it gets published."
:)
10 pages of article, 300 pages of contributors listed as e-mail addresses and slasdhot ID's
I rather suspect that none of the smaller contributors will get mentioned in the article (probably the largest installations will). I would guess that a link with contributors will be given.
------- Sorry about the spelling, I suffer from two problems. Dyslexia makes it difficult to spell well, lazy makes it
You really should catch up on current technology. Java is only interpreted at program startup. It is compiled down to native code just like C++ is, except the compilation happens at runtime when there is more information available (e.g. which method calls are really virtual and which are not). So, yes, the first couple of seconds of your program are interpreted but the rest of the time the speed will be just as fast as C++, sometimes faster.
true, especially cache misses makes java hog
Move it SSE awair code and I will eb glad to join.
...so I can detect photons that arn't here.
You say no OS-specific code, but note that C/C++ don't understand things like directories in their default setup.
So for a start you need linux/windows
With this kind of application endian could be important, so you have linux/windows/mac os x.
Then of course he might have to compile it against multiple libcs under linux.
And you are going to want different versions optimised for the various different processors.
I'm up to at least 10 or so versions here and I'm not even really trying
Oh yes, *BSD users might want a version to, theres another 3 or so.
Or one java version
Combination - fun iPhone puzzling
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
Interesting, the C++ results are run with full optimization on, while Java is run without optimization turned on. I'm not saying the results are purposely biased, but you have to know what you're doing when benchmarking.
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?
if I interpret my 80386/80486 "handbook for programmers" - Microsoft Press *eg* - correctly, the x386 family already had a stosd to store dwords. And that mighty processor introduced eax/ebx/ecx/edx, so why should the C compiler use 16 bit registers?
:) and if I know one thing for sure it is: respect the way the hardware works, and you'll get the fastest program that's possible. In this case, it was a multitasking OS kernel that booted from BIOS to command line in less than 2 secons on a 133MHz P1 - pretty much the same as BeOS... :)
Then, the 4 statements would be running in pipes on anything >x486. Of course you'll get a block because ax is used in both statements, but it should be possible to run the second pop while the stosw is executed. Don't remember the names for the pipe states right now, so I can't explain better.
Additionally, if one distributes source code, the compiler could produce highly optimized code that would outrun java on *any* machine, but I think someone else mentioned this.
I have been hardcore-coding assembler back in 1995 for about 6 month (more than 10.000 lines. well I think the code was not *good* or anything, but I did...
Anything that moves you away from hardware access makes it slower, because it's adding overhead that could have been avoided using the mighty brain of (wo)men.
Right now, the compiler optimisations are so good that it's nearly no need anymore to write assembler code to get speed improvements. But the Java VM is still not the same as native compiled C. I like Java for some things, but number crunching is not one of them.
" I think has trouble with some things like the Linux kernel."
.a = 1
.b = "hello"
Thats probably because some kernel code uses C++ type syntax, its not pure C. Function pointer calls spring to mind plus the gcc specific
(or is it c99 syntax?) method of defining structure values. eg:
struct fred f {
etc
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?
If you parcel the same zip out to everybody and they start crunching it, won't everybody be working on teh same part of the picture? Even w/ a pseudo random start point how are you guaranteeing all the nodes are working on all the pieces. I assume you have thought of this. The post seems to say that the more people you get, the more resolution you will have at the end. How are you doing this? How are you piecing together all the crunched numbers?
"The plan is to run the program on a zillion machines for a month and combine the results."
...
Really? Have you done the math on that? Are you sure that only a zillion machines can do the work in a month? You might need a few more, I mean, a zillion seems like enough, on the face of it, but you might need a few kajillion more just to make sure
On the other hand, it should be easy to get a zillion volunteers. More than that might be a problem, though.
"Well it's not Victory - but then it's not Death either."
The issue is that to do that you'd need to give everyone source and they's all have to compile it themselves. You're not going to get many people to do that.
You really need a simple download-and-run file. If you compile some C you need to compile it to the lowest common denominator or it's going to choke on some systems.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
They did that with me too. I look at anti-slash with a guarded eye.
He who laughs last is stuck in a time dilation bubble.
... 300 pages of contributors listed as e-mail addresses ...
.TXT format, and costs only $.02 per unique email address.
that can be bought separatedly on a CD in a
One thing I never understood about java is how it got known to most people as more powerful, expressive and 'modern' than C++.
.class files.
:) (It's still nice work, but is not the straight-forward way to do it)
This is simply not true. Java is still more or less a subset of C++. Good for the people who are ok with that, but I really do not need a language which forces it's views onto me.
So I'd like to have a bytecode backend (e.g. JVM) and a class library for C++. I think most of the dispute over Java/C++ would end because everyone can write in his/her preferred language and run the code on the same meta-platorm.
Although RMS argues against it (with fears I do not understand), it would be nice to have a JVM backend for GCC. One would have C,C++,Java, Scheme (via bigloo!), Obj.-C, even Fortran as a compile-once-run-everywhere language, hopefully in a way compatible with java
Yes, I know that there is mips2java, but excuse me if I call it a temporary kludge
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 took you a month to learn to use lens flare filters?
Now, where's my publication in SIGGRAPH 04?
-Bow for the Gimp!
I am actually about to publish a paper with the aliases and team names of the 20 top contributors of the Distributed Hardware Evolution Project. The names of the circuits in the figures were also chosen by contributors. If anyone is interested in having their own island in an island based coevolutionary genetic algorithm evolving the next generation of safe hardware circuits across the internet, join DHEP! You will be contributing cutting edge research.
HA! ok there goes my idea.. =P
-ashot
Compare:
Java is still more or less a subset of C++.
and:
I'd like to have a bytecode backend (e.g. JVM) and a class library for C++
You are contradicting yourself.
a
b
Function pointer calls and designated initializers are both defined in the c99 standard.
But the kernel does indeed heavily depend on some gcc extensions.
Just wondering
I'm currently about to extend DistrIT to make a system so that researchers can book CPU time from all the unused cycles of my Department's PCs. Using Java would make it secure and transparent for windows and linux users..
Hmm... not every machine is an Intel box running a Microsoft O/S
Using Java has advantages:
(1) Can run on multiple O/S's including Linux
(2) Can run on alpha and other non-Intel hardware
(3) Has well defined mathematical results regardless of O/S and hardware
(4) Java Applets are sandboxed by default, thus giving more peace of mind than using other languages
Also, with the standard JIT compilers, performance is similar to C; sometimes faster, but mostly a little slower.
For numerically intensive Java applications I use the -server optimisation flag. I gained about a 10% performance improvement over the -client (default) optimisation.
-Nivag
If you are still running a compiler from an old 386, then maybe it's time to upgrade. there are plenty of much, much newer compilers which are free to download. just try googling for a few minutes and you should find quite a few.
If you can read this then I forgot to check "Post Anonymously"
No, I'm not.
I am talking about the language Java and the language C++. C++ as a language is a superset of Java as a language.
The java class library is indeed more comprehensive than the C++ 'counterpart', the STL, but there are of course lots of additional libraries for C++.
I was talking of linking this hypothetical C++ bytecode to the java class library or a similar C++ library.
> I'm sure I'm going to get flamed for this post
This in fact should get modded flaimbait or troll.
It's no use, fellow AC, spare your fingers. You can lead a rightwinger to the facts, but you can't make him read or think.
Who tells me that you won't do research for nucular Weapons?
Maybe Laser-Gun?
Yeah. The sysadmin where I worked had set up a bunch of the workstations to run that stuff. Trouble is, the nightly builds were falling over. People were pissed.
Wansu, th' chinese sailor
No reason you can't call fortran routines from LAPACK or whatnot from a C program.
Fortran was the first high level programming language. It was created to write scientific programs in. Hence, the some of the oldest programs around are scientific programs written in fortran. That's why scientific code has this huge legacy of fortran, that you don't see elsewhere.
You said two years ago, that was before 1.4.
Java, well Swing is getting better.
There were two factors you encountered back then.
Swing back then was less optimized than it is today, and back then Swing didnt revert to the underlying hardware acceleration but the the Windows native toolkits already did.
The situation currently is more or less, that the speed difference in Swing compared to native toolkits is neglectable and in some cases even better.
The reason for this is, that Swing now reverts to hardware acceleration for its 2d drawing functions and the library is better optimized.
The current situation is following:
Windows JDK 1.4: Speed difference neglegtable and acceptable
Windows JDK 1.5: Speed difference barely visible at all
Linux: JDK 1.4 Sun: Swing is still much slower than every other toolkit but has acceptable speed
Linux Sun JDK 1.5: Swing is faster but still slower than GTK2 (havent tried the OpenGL option yet)
Linux Blackdown 1.4.2RC1: Swing is faster than GTK2 and a tad slower than Qt
Mac: no noticable speed difference since 1.4, in fact with a little bit of tweaking you dont notice any difference to nativ apps at all due to the excellent L&F Apple provides.
So the situation is not that bad as everbody shouts. The funny thing is most people who scream Java is slow, Java guis are slow neither have seen the SWT in action nor have probably seen a post JDK 1.3 JDK, their knowledge basically is outdated by more than two years.
Over here we slowly are moving away from web based guis, due to the imminent fork of Microsoft with HTML which currently is in the beginning stages and will be completed with Longhorn.
Swing has become fast enough and is very flexible.
Mmmm... 8-bit photon mapping! How about some true colour!?
+n Flamebait, for suitably large $n\in\mathbb{N}$
Christopher Harrison
If the class library for C is written such that it never requires the use of a pointer I'd be all for it.
Half the value of Java is that the entire language is implemented in a non-pointer-dependant manner. Where do you think all the buffer-overflows come from?
Pointers should be a feature reserved for bleeding-edge optimization and low-level operations. They should not be required to do so much as use the scanf function. Sure, they're a fundamental function of how computers actually work at the machine code level, but they're probably the most frequent source of bugs.
Java did well not to implement them...
To a man with a hammer, everything looks like a nail.
The dark adapted eye can detect a single photon. This is the only known direct macro observation in biology of a quantum mechanical event.
Robo-Blogs of the world: UNITE!
""handbook for programmers" - Microsoft Press *eg* - correctly"
Why did you put *eg* in there? eg means "for example", I don't get it.
How smart is it to give out your email on ./ ?
His email server is likely 'Illuminated' by it's own flame.
You'd think he would have thought of a better ditribution process.
Hmm... not every machine is an Intel box running a Microsoft O/S
True, but that's not a reason to use pure java. Compare with setiathome, which is available in binary for a lot of processors and operating systems.
There's also the new BOINC architecture...
cpghost at Cordula's Web.
I would love to help, but my linux box does not have an x server, so I would not be able to run a java app with any kind of gui.
Is there a non gui option? Something I can run from the command line?
The submitter mentions "you will get a mention in the article if it gets published" but never states who will own the image after it's complete. In this day of intellectual property pissing contests I think it's rather interesting and important to address.
Personally if I contributed to the project I'd like a copy of the image myself. This could actually be a model for collaborative work, give me your cycles and I'll give you a copy of what we create together.
-- Button up, your ignorance is showing
These days, processing cycles cheap, programmer time expensive.
Thank you! you exposed the SINGLE reason that software completely sucks today.
This mentality is why games are bloatware, Office suites suck, Operating systems use 2X the resources than the last iteration... (linux kernel excluded as I can remove crud, and linus and the crew are always optimizing that bugger)
Until someone starts smacking people hard who say that the state of general computing will continue to spiral into the toilet.
Gnome 1.X would run fine on a Pentium 233 with 64 meg of ram... today, gnome, KDE and everything else linux is requireing way too much memory and processor to do the same job. and Windows is 2X worse... (Xp is NO DIFFERENT than W2K other than silly eye candy.. yet it is massively slower than 2K...)
Luckily there are exceptions.. the Blender programmers are making things faster and smaller, Mozilla are also striving to that end....
Do not look at laser with remaining good eye.
You're talking about C. I was talking about C++.
The only thing C++ has in common with C is that the C++ language contains the C language as a subset.
In C++, you have pointers, but you can live well without pointers, for example by using the STL (standard template library). You can wrap pointers in 'safe-pointers'. You have the power to use pointers, but you can hide them and program in a very Java-like way.
If you compare C with Java, I agree completely. But I suggest that you take a deeper look at C++, you'll find that you can easily move to C++ without being restricted by anything - and you can take advantage of the low-level possibilities (pointers and such) of C/C++, if you ever need to do.
You say no OS-specific code, but note that C/C++ don't understand things like directories in their default setup.
They just need files.
With this kind of application endian could be important, so you have linux/windows/mac os x.
This is easy enough to deal with in a macro.
Then of course he might have to compile it against multiple libcs under linux.
Distribute it as source. Use static linking for the binary distribution.
And you are going to want different versions optimised for the various different processors.
The C compiler can do that perfectly adequately. How many optimisations are there that slow down another machine noticeably? Even if they could, the architecture specific optimisations in Java aren't going to give anything like the same optimisation.
I'm up to at least 10 or so versions here and I'm not even really trying
I make it 3. Linux, Windows, Apple.
Oh yes, *BSD users might want a version to, theres another 3 or so.
I thought BSD could run ELFs.
hmmm. like perl!
The eye candy is one of the resons for XP asthmatic performance
Saying Apple is better than MS is like saying Botulism is better than rabies.
It seems that the discussion degenerated to bashing Java for being slow, arguing that it isn't and speculating about doing the same in some other bizarre programming language. But I would like to ask a very simply, yet, profound question. Why? What exactly the point of this project? It's not that I am against distributed computing, Java or rendering of strange bubbles. I just honestly don't understand (from reading the writeup and meditating over the 11-year old gif) what rkeene517 is trying to achieve.
The picture he rendered 11 years ago could now be rendered in about a millisecond on top of the line Radeon. Does he want to up the resulution? Does he want to better simulate the physics of light? Does he want to simply increase the number of photons a thousandfold and see what comes out of it? Does he want to test the limits of Java programming or distributed computing? The inquiring minds want to know.
Future Wiki -- If you don't think about the future, you cannot have one.
I believe you are mistaken. In no online forum have I ever seen a comparison to the performance of Java vs. C. You must be thinking of a different type of deja vu, called deja view, which has (obviously) much lower performance.
---gralem
except easier to reverse engineer
Can you cite one real (as in "used for real production") CG renderer out there? If not, how come?
Just wondering...
Exactly,
For me this is the foundation of Java. Don't look at is a language - its strength is its ability to employ its father - c - when necessary.
For me, Java is much more a framework. It is THE intermediate code (and in my opinion JVM bytecode is the language every student should start off learning, I say controversially!).
You can even argue for it on ethical grounds.
It promotes many rivall architectures, as Java is compatible with them all.
Until someone comes up with a rival intermediated code representation (there is no point in doing this), Java may be around allot longer than you might think. If a rival (final and eternal) intermediate code doescomes along, I believe Sun would be the company to create it.
But why bother??
How about you write something that does some serious number crunching, in C, and in Java, using the currently released JDK (1.4.2).
Compare how long it takes and how easy it is to write in the two languages, and then compare running times.
Then write up a report and post it somewhere and provide us with links.
Or you could just google for ancient outdated annecdotal evidence.
Advanced users are users too!
The 1994 image took 100 Sparc Station 1's a month to generate.
Probably because you used Java...
--
Adobe's anti-counterfeiting softw
here
This comment does not represent the views or opinions of the user.
I bet this thing is a spam relay...
several things....
1) Programmer time goes for about $50/hr. That means that a prrogrammer spending 20+ extra hours could have pretty easily bought you an extra dual CPU computer to run the thing on. That's only 2/3 days of work. Java can easily shave off much more than that.
2) Java isn't that slow. Depends on what you're doing and how you're doing it, but it's not crazy to get java to be less than 50% slower than C. It's also not really uncommon for it to be faster. When it is faster it's almost always because better algorithms are used, but that isn't an accident. It's much easier to write good algorithms with a garbage collector sometimes, as you don't have to track down and delete all the stuff you unlinked.
3) The one weakness of java (until VM sharing becomes available) is memory usage, but memory is really cheap now, same basic logic as CPU time, but even more so.
4) Lots of additional optimizations are possible in VM based languages that aren't tried by any modern VM. When they start to come online, expect the performance of the VMs to surpass compiled code. Here are some examples....
a) Escape analysis: all stack frame scoped data goes on the stack. Basically it makes optimal use of the stack, can't really be improved any. This is why C#'s "value" types are so stupid, they shouldn't be able to help (and would probably hurt) a good VM. Anything larger than a pointer should be a reference, the VM can put it on the stack if it's possible to do so.
b) Method virtualization: a good VM should strip down pretty much all of the V-tables and just regenerate what it actually uses. This is why the "virtual" keyword in C# is so stupid, it should have no effect on performance assuming a smart VM. Can also do all sorts of inlining that a normal compiler can't do (someone could link to your library, you can't inline away public functions).
c) "incorrect" optimizations: The VM can create optimal code that is not actually a valid representation of the given code for all inputs. Can then revert the code if an input is given for which it is not valid.
d) Profiling: a VM can (and modern ones do) profile the code and optimize the common cases at the expense of the uncommon ones.
e) Hardware knowledge: a VM can always produce code that is optimal for exactly your hardware, right down to cache sizes, processor model, and memory latency.
Just though I'd throw these things in. Those who expect VM based languages to always be slower will probably be in for a shock in the future. Remember, the cost of compilation is basically constant whereas the payoff from optimizations is linear in CPU speed. At one point the optimizations will exceed the cost of compilation. It's only a matter of time.
...he'd used a Beowolf cluster.
He'd have got twice the speed for half the cost, even in 2020 dollers!
Makes sense when you look at it like that.
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
LOL!
OH MY GOD YOU ARE UP LATE!
F"en asdo crazy man
LOLFMAOMO@!
hahaha
Way to plagiarize, loser.
8 16 00&cid=7165838
http://developers.slashdot.org/comments.pl?sid=
Can someone explain why this scene was selected to be raytraced?
I see there are some interesting things in it, such as the rainbow reflection in the mirror, but what specifically is technically interesting about the composition of this scene?
Eh... .NET is natively compiled when it's run for the first time. It also optimizes for the platform (even CPU) it runs on.
Actually, most programs native compile it during the install. Only if the assembly is not natively compiled does it get so on load time...
I am disrespectful to dirt! Can you see that I am serious?!
The 1994 image took 100 Sparc Station 1's a month to generate
:)
Just give me 5 minutes and photoshop
While most of what you said is true (although I should point out that fully half your post is about cases where Java may become faster, rather than cases where it is faster), #2 isn't valid - an algorith isn't "faster" if you just ignore the memory issues, because the garbage collection overhead is real and signifigant. Java profiling ususally disables GC and ignores startup time, but you could write the exact same thing in C and just let all your pointers leak all over. Memory has to be dealt with somewhere, and just ignoring GC and claiming you've got a better algorithm because you don't have to free memory is dishonest.
The bytecode for a method declares the maximum size the stack can grow to within that method. If this number is small enough, everything can be stored in registers.
When someone writes a new program, the question of how well it would run if this person was in fact not writing this program and only had an obsolete copy lying around is fairly irrelevant when they choose the language that they will use.
Your argument is like a jockey saying: "well, I have a three year old tortoise and a three year old thoroughbred horse. But hypothetically if I didn't have them and I had a 50 year old horse and tortoise, the tortoise would be faster because the horse would be dead. Therefore I should probably race on my tortoise at the track today.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
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!
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
By what meaning of the word "superset"? By some interpretations, one would expect to be able to take a Java progam and successfully compile it with a C++ compiler, which obviously isn't true. This would be a reasonable interpretation, since the "superset" idea is often applied to language pairs like C/C++ and C/ObjC. One genuinely can compile a plain C program with a C++ compiler or an ObjectiveC compiler.
So, if that's not the intended meaning of "superset", then you must be claiming that there are semantic constructs that you can do in C++ that you cannot do in Java, but not the other way around. multiple-inheritance-of-implementation and operator-overloading would be the obvious examples for things that C++ can describe that Java cannot, but then Java provides runtime access to class names, method names, and instance variable names...while C++ does not. So again there's not a true superset/subset relationship here either.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
That's pure theory and doesn't work out in real life. Why? Because the registered are occupied with VM internals (to speed up VM loops, in particular)
You should ask over on indiadot.org (sorry, unintentional pun), they're cycles are a tenth of the price.
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
...an email address has been slashdotted Oh yeah, except for that spammer.
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
You can view individual photons with a Spinthariscope - that web page has a good description, and it's $25.
HIV Crosses Species Barrier... into Muppets
These days, processing cycles cheap, programmer time expensive.
That claim is valid (to an extent) when you're talking about something running on one machine, or a small number of them.
This is a project that's going to run for a month on hundreds of machines. Lets assume 30 days on 500 machines. That's 15,000 computation days. Say he spends one day making the code 1% faster. That one day of time results in a gain equivalent to 150 computation days. In this example, 1 day of work was equal to adding 5 more computers to the project. You'd have to be taking in a really big paycheck for that optimization to not be worth it.
Keep in mind that a lot of posters on this story are claiming that a 2-4x speed increase by rewriting in C would be realistic. Assuming that's true, a C version would be well worth doing.
We are offering free distributed computing services to people who have worthy projects they want to run across our network over thousands of members around the world on their PCs. If you got an algorithm and some code, we've got a lot of bandwidth and processing power. If your project is cool, or of worthy scientific or societal interest, and not too onerous to integrate into our platform, then we would like to process your projects for free.
For more information visit http://www.ubero.com/freeservices.asp
I know you've all been waiting: here is the final word on Java vs. the world.
Emacs starts up faster than JEdit, therefore Java loses. Emacs is obviously the most complicated program ever invented! LOLOLOL!
How old is your C++ standard you're refering to?
:)
This is one of the 'PR' problems of C++, early implementations had many deficiencies and people are refering to old information.
Fact is: C++ has RTTI - run time type information. Try it out, it's nice
rkeene517.... why'd'ya mangle your email in the body of the article, when the very first bit of
.zip'd
the post already contains your email in perfect form?
ah well, guess you weed out the 'also rans' before
wasting your time mailing them with the
workload
Aay! I dont know WHAT IS THIS, but you could render this image in a day on a 486 with POV-RAY
>This in fact should get modded flaimbait or troll.
>It's no use, fellow AC, spare your fingers. You can lead a rightwinger to the facts, but you can't make him read or think.
So in other words you're going to pay attention to his sig and not his post?
Now who isn't reading or thinking?
Hey. Lets render this. If it works out, this guy will have my kudos, which of course isn't worth anything. ;-)
Meme of the day: I browse "Disable Sigs: Checked". So should you.
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
We would implement it in C++ using the A* algorithm, a heuristic technique of Artificial Intelligence.
open4free (c)
True, I was partially keeping to cases where it could (and someday, presumably, will) be faster. Anyway, I'm not claiming that you can turn off garbage collection. I'm claiming that people can often write better algorithms when they don't have to manually manage memory than they can when they have to track down every pointer that might become unreachable and delete it.
I just don't like the assertion that much of slashdot makes that VM languages will always be slower. In the long run the reverse should be true. The first cars were slower than horses, but it was only fools who believed that would long be the case. Slashdot seems full of such fools.
Hmm...
$ echo "ceci n'est pas une pipe" | sed -Ee 's/(eci n|pas )//g'
has BUTNOSPAM in it in the link he provided, but the link from his username doesn't. hmmm that sounds less effective.
this sig is deprecated
With greatest respect to all the brilliant coders, there are just somethings which are "out of the box".. that can't be arm waved and approximated into submission. This is obviously a true experiment (and capital A Art), there is no room to fudge the numbers.. even if they are close.
You all know the scientific method.. Do not forget about the artistic process. Both require getting your hands dirty to produce empirical results. The original image has a certain ineffable realistic quality which even the best renderers generally lack. Hats off to this artist's endeavour!
Will I get a copy of final picture with small red circle around the photon that I helped to compute ?
I started working on some computationly heavy statistical distribution equations in C++ in order to prototype some functions. I used doubles for eveyrthing because I needed the precision.
When I moved it over to C# the speed went noticibly up.
But then again compiled QuickBASIC could do math as fast as any other language. It was just the graphics that were slow. Fast math isn't much of a trick since all the basic computations are done in hardware. The compiler just needs to take advantage of it.
If you need real time, new and delete are about 10 times slower than free and calloc. You don't have access to those functions in Java or C#. If you need raw speed, higher level languages aren't going to cut it. They have too much "safety" built in which kills performance in some cases.
If all you need is math, then any language will do.
Ben
Work Safe Porn
If its in java it can be run on 32/64 bit processors just the same.. Well, almost. I've heard that a rocket slightly missed its trajectory because the inintial computation was done on 64 bit machines and then transfered over to 32.
Wouldn't the data be kind of pointless if different machines will introduce different rounding errors?
best regards
Oleg M
I"m sorry, I know this is incredibly naive of me. Go ahead and mod me down, I know I deserve it. I have some karma to spare. I'm sure I'm just ignorant of what this really is and what makes it so cool. But you ran 100 machines for a MONTH and you got THAT?!?! It just had to be said. Seems like you could have rendered Manhattan or something in the same amount of time.
Again, pure ignorant drivel here. I just couldn't pass it up.
RP
I was only half-aware of RTTI; thanks for pointing that out. I read a bit about it this morning, and it looks like the capabilities that it provides is a strict subset of those provided by the reflection facilities in Java.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Why waste CPU time writing it in Java if it's computationally intensvie. Write it in C, and compile for various platforms.
And pigs _can_ fly.
DAMN those police helicopters!
I've already seen this comment. In another, much older story...
...
Guess the trolls are plagarizing again (unless this AC is the OP?), though I suppose it doesn't matter since they're not getting any karma to post Goatse ASCII at +2
Excuses, excuses, excuses. Java has been out nine years, and I'm getting tired of all the damned excuses.
Don't blame me, I didn't vote for either of them!
Reflection is part of the java class library, not the language.
This is why I was calling for an equivalent C++ class library (or a link C++->Java Class Library). C++ with JVM backend should of course have access to all the capabilities provided by the JVM.
Now, as for your claim that you can write better algorithms - algorithms don't care about memory, thats an implementation detail. And keeping track of every pointer and when it might go out of scope is exactly what GC does. It's fundamentally less efficent than manual memory management - a tradeoff of runtime performance for ease of implementation. Although, again GC overhead gets flattened out as computers get more powerful.
Sun doesn't provide their own JRE for the BSDs, and FreeBSD's JRE is only at version 1.3.1 (I don't even know if this much is available for NetBSD and OpenBSD). If you want the current JRE (1.4.2), you're going to have to pay for a commercial one. On the other hand, GCC and the GNU C library work on all the platforms you mention (and many more besides that, some where a JRE does not even exist). In a way, it's not surprising that ISO C is the most portable language available, but when you look at the calendar, it is also kind of sad. This is of course talking about source distribution, but when some person on Slashdot asks to run his programs on hundreds of other people's computers, it would be a little suspicious for him not to provide the source code.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
It actually seems to me that it could be cool to create a an Open source distributed Computing Hub. Tasks like this that are finite in a meaningful length of time could be farmed out... .... thats a lot of power wasted...
That is set up a site and some software that downloads the next tasks - and computes till its done (you know - maybe limit these things to 1 - 3 months or something. In fact technically - at first thought - this seems easy...) The harder issue would be to prioritise the tasks.... Is my spin glass project better than my photon task and so on (ANd Ive always meant to write a evolving algorithm that tries to predict the stock market on the basis that given enough CPU your bound to find something that works !!!)
I have access to 3 Intel PCs with another soon AND also on occasion a 10 CPU Sun Server that sits there unused on weekends and over night
Does anyone know of anything like this in the works ? What do people think?
phill@wall.name (too lazy to login )
I'll bite.
WHO still runs 386 these days except for nostalgic reasons? Did you run 286 in 2001?
With low CPU prices these days, running anything but the simplest programs on a 386 (especially if you want performance out of it) will probably cost MORE than say, a Pentium.
The JVM and .NET CLR both enforce a strongly typed object model at the lowest levels. As much as Microsoft would like you to think otherwise, the .NET CLR leverages heavily on Microsoft's experience writing a JVM. Both virtual machines can trace their lineage to Sun's Oak project, designed to express the symantics of only a strongly statically typed language and be interpretable on 8-bit microcontrollers in toasters and fridges. Stack based virtual machines are simple to implement and are nearly ideal for interpreters (see Xavier LeRoy's design paper for Zinc, the Ocaml VM) but very much not ideal for just-in-time compilation (see Ken Tompson's design paper on Dis, the Inferno OS VM). There's simply a lot of work that has to be done in order to get the abstract syntax tree back out of the stack-based byte code.
Essentially, your stack-based bytecode is optimized for a two-register machine (the top two values on the stack). If you're close to having only two spare registers after the VM claims a couple for overhead, then directly JIT compiling stack based VM code doesn't create code that's that bad. In this sense, stack-based JIT VMs aren't so bad on register-starved architectures like x86. However, on architectures like x86-64, PowerPC, Itanium, and Sparc, and MIPS, you really want to work backwards from the bytecode to the AST and then generate RTL and finally do register folding on the RTL so that it will run on the number of registers you really have.
On the other hand, Parrot bytecode with its 3 sets of 16 registers can probably be directly translated to RTL and generate very good code on most architectures. (Itanium has many more than 32 GP and 16 FP registers, so it will take a lot of work to get Parrot to take full advantage of Itanium. Register folding even on x86 should take much much less time than AST and RTL generation from stack-based bytecode.)
Finally, the Dis virtual machine has more or less 4 billion registers (it's a memory-based virtual machine). If a partucular routine for Dis takes more registers than physically available, then your JIT compiler will need to perform register folding, but for most machines with fewer than 4 billion physical registers, Dis should generate good native code very quickly and easily.
Something like Parrot or Dis would make a much better target for a C++ compiler because of the less restrictive object models. If you wanted pointer safety or a more strict object model, that could be enforced more flexibly in the (replaceable) class loader than in the VM's low-level functionality.
There's also the point that the JVM provides no opcodes for pointer arithmetic and no way to cast between pointers (references) and integers. Using a class loader that allows integer opcodes when a reference is on top of the stack will break on VM implementations that use a seperate reference stack to improve garbage collection. You could have all of your objects live in an array of ints and emulate pointer arithmetic with index changes and bit shifts, but that makes using standard Java libraries with your objects much more difficult and slower.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
I have no reason to expect that he will whisk out a boring image of some glass balls that he rendered in (e.g.) maya in 5 minutes... So what's the rest of the processing time for?
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.
Others who've replied have been a little off, but they raise good points. F90 is around, which is more feature-rich than F77, but pretty close to backwards compatible. No one switches over to F90. Why?
Well.. F90 supports pointers.
Yep. That's it, really. F90 has pointers. Not having pointers is why F77 can compile to greased lightning on crack. This is critical when your supercomputer time (variable expense) is at a premium with respect to your salaried coder's time (fixed expense) and you're working off a grant (with finite cash but loose deadlines.)
And yes, I'm young and I still know Fortran. Like my father and his father before him.
I have received about 900 emails today. I will be posting the program on http://www.cpjava.net in a day or two so everyone can download it. Not to self: don't post email address :-(
Inside every complex program is a simple solution trying to get out.
Why is this a troll? It's true software is getting bloated because new hardware is cheap. It's people who keep suggesting to throw hardware at the problem make software bloated.
Why would you need tons of CPU cycles now to do the same thing you wanted to do 10 years ago?
hi, im interested in participating, but when i sent you an email to the address provided, i got a return email saying your address is not valid.. my email is illusions0912@hotmail.com i would like to participate
What will having this image do/help? Im all for supporting things that will help society in some way or another, but this just seems to be a picture atm??
alice@ozforces.com
Maybe I don't understand something [1], but image looks just poor. Why should anyone donate cpu cycles for producing such image? What's the point?
[1] It's a science project, not fun, but what exactly can be read from this picture?
Sheesh. People -- headless Java apps aren't slow. Java compiles the code with a "Just In Time" (JIT) compiler, so you may experience a bit of a delay the *first* time the app does any one function as the bytecode is "really compiled", but after that, there really isn't an issue. In benchmarks that remind me more of the Apple vs. Pentium Photoshop numbers than anything else, you can certainly find people who experience *faster* execution times in Java than in native code [using compiler X]. It all depends on what you're doing. But that you can even venture that Java is faster at some things now tell me it's up to speed.
What's slow about Java and where does the conception come from?
The main culprit is Swing, Sun's preferred GUI toolset, which is gosh awfully derned slow. Unfortunately GUIed applications (like Limewire) are where many people form their Java speed impressions. Here, Swing (perhaps more properly, the implementation of Swing) is relatively slow compared to native GUI code on most every platform. I've heard it said that Swing is good for debugging server-side apps, and sometimes, I regret to admit, I think that statement's more on the money than off. When you compound the problem by creating a relatively complex GUI like Limewire or Netbeans, you really see the problem.
(Luckily it looks like that might be changing. And try Eclipse, the Java IDE from IBM, and compare to Netbeans, Sun's Java IDE. Both are built in Java. Netbeans uses Swing and runs dog slow at times. Eclipse uses SWT (see above link) and flies.)
What else is slow? The *first* time you start your Virtual Machine -- again, depending on how the program's written, and particularly slow when you have to get Swing up & running -- can take a while.
But take Apple's virtual machine. The first Java app that starts can often speed up each that follows -- and restarting the same app a second time without rebooting will cut startup times dramatically as parts of the VM stay on the ready.
Anyhow, I digress. The point of it is that you can use JIT compiling to make your bytecode run quite quickly, expecially for GUIless application. Do you really think so many large companies would use Java for their web presence if Java couldn't at least move bytes around quickly? Sun's smart enough to compile Java into native code in the VM (that's its job, after all), and when you're just dealing with numbers, after the first compile from bytecode, "Java is C", in a sense.
It's all 0s and 1s. Or it's not.
Now you can put your computer where your mouth is (?) and help us crack DES i one week. We have a distributed system, and a client written in C/Assembler that contacts the server, gets three bytes and it checks all alternatives that start with those three bytes. Interested? Read more here!
So the question is: can you spare us a few million cycles?-)
I came up with this tag first!
/fredu