Slashdot Mirror
Can You Spare A Few Trillion Cycles?
rkeene517 writes "11 years ago I did a simulation of 29 billion photons in a room, that got published at SIGGRAPH 94. The 1994 image, called Photon Soup is
here
.
Now computers are 3000 times faster and I am doing it again only much better, with a smaller aperature, in stereo, with 3 cameras, and with some errors fixed, and in Java.
The 1994 image took 100 Sparc Station 1's a month to generate.
I need volunteers to run the
program for about a month in the background and/or nights. The
program is pure Java." Read on for how you can participate in the project.
"The plan is to run the program on a zillion machines for a month and combine the results. All you have to do is run it and when the deadline arrives, email me a compressed file of the cache directory. So email me here and I'll send you the zip file. The deadline will be June 1st 2004.
The running program has a More CPU/Less CPU button. Every half hour it saves the current state of the film. The longer and more machines that run this, the cleaner and sharper the image gets. If you have a lot of machines, I can give instructions how to combine the results so you can send in a single cache directory.
Of course, you will get mention in the article if it gets published."
Java eh? So it should run at about the same speed now on modern hardware as it did a decade ago? Chortle.
I hear they use cycles big time there. Pretty cheap too comapared to cars.
"When the only tool you own is a hammer, every problem begins to resemble a nail." - Abraham Maslow (1908-1970)
This is a wonderful thing to see. Distributed processing is a wonderful way to spend those extra clock cycles that most of us have, while at the same time benefitting someone else. I really hope to see more projects like this in the future.
Emailed this to the editor, but something must've gone wrong.
The URL to the photo soup image is missing the 'www'. The image can be seen here (you may want to do a 'Save Target As', as the mime-type seems to be a bit off).
nothing against Java it has its place, but for something this CPU intensive, it seems like you'd be wasting CPU cycles. This sounds like a job for C.
Kent Simon Multitheft Auto
Use ISO 8601 dates [YYYY-MM-DD]
I don't feel like donating a few trillion cycles to produce an image that says "The page cannot be displayed". Possibly if you made it say, "The photons cannot be displayed", I would think about it.
=P
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
The best time for these project is in the Winter time. Because, that's when I have my heater on. And if my CPU is running 100%, then the heat from it will help heat up my appartment rather then the heater needing to kick on.
I mean, I don't mean to belittle this project. But for all grid computing projects, there is a better time and place for this in my opinion.
Life is not for the lazy.
The link to the image should be http://www.cpjava.net/raytraces/DRUN.GIF (The www is necessary and was left out of the link in the article.)
People are already cracking jokes about how the fact that it's in Java will mean that it will run a lot slower than it could. While I love to pick on Java as much as the next person, I am curious how much it actually makes a difference for raytracing - does anyone know? My experience with numerically-intensive algorithms is that Java is 2-4x slower than C. You can get it within 2x of the speed of C if you ignore object-oriented programming and you're really good at Java optimization, but that's it. And it will run much slower on some architecetures because Java guarantees certain floating-point operation semantics at the expense of speed.
If I were writing a new numerically-intensive program from scratch that I wanted to use for a cross-platform distributed computing project, I'd probably do it in Numerical Python (NumPy) - my experience has been that it can be within a factor of 2-3 of the speed of C, but it's much more concise, requiring half as many lines of code as Java or C to do the same thing. And these days Python is just as cross-platform as Java - it definitely runs great on Mac, Windows, and Unix.
Go outside (No, it won't kill you) and look up at a bright star. Now imagine that star is in the center of a sphere and your eye is on the surface of the sphere. The aperture of your eye captures enough photons to image the star constantly. Now imagine that same amount of photons reaching all points of the sphere's surface. That's a serious bunch of photons. And the star outputs them constantly, for billions of years.
Any biology majors here care to tell me how many photons the eye needs to 'see' a reasonably bright star? With that information, you can calculate the rest (left as an exercise for the reader).
Money for nothing, pix for free
"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
FP ops in Java are incredibly slow and broken.
Er, do you have any more recent numbers than a lecture from 2001, originally published in 1998??
Being bitter is drinking poison and hoping someone else will die
Either I'm suffering deja vu, or this has been posted nearly verbatim before in a previous discussion of Java vs. C.
Astounding.
I would like to know what I see in the picture before I dedicate my cycles to the project. What are those "bubbles" in the pic for example?
What's to insure the trust within this project? Call me a cynic, but what's preventing some jerk from swapping some bytes in his set of data before sending it off, thus, rendering your combined result different from what you intended?
A much larger version of the SIGGRAPH `94 image "Photon Soup", clocking in at 840x560, can be found HERE.
wow, its slower than C. i'd rather run a random java app than a random native app because you can easily sandbox it and know its not going to screw your computer. thats one less barrier to people helping the dude out. and theres no recompile for the various linux platforms, win32, solaris, macOS, etc etc. its certainly slower, but more friendly to the community.
Erm, that article is more than SIX years old, and one of the guys that wrote it now works for Sun. Apparently FUD is not something Microsoft has monopolized yet..
to^2
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.
Applets are bad for a LOT of things. But this is one thing they would work really well for. Using an applet:
1. The client PC runs the program in a sandbox
2. Most client PC's don't need additional software installed (if written for JDK 1.1)
3. The user does not need to know how to invoke a Java application
4. There's no administrative overhead in iniating the application, just go to a URL
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
First there are resource allocation problems. The OS has to provide a sandbox with strict limits on all resources: memory, filesystem, and networking, as well as CPU time. It's fine with me if the "background compute demon" takes 25% of my processor but I don't want to take more than 10% of my memory.
Then there's the security issue.
But I see another problem which is even harder to solve: the tragedy of the commons. Consider a university campus, and suppose that anyone on campus can submit jobs to the Campus Grid. You come in the next morning and see that there are 10000 jobs in your grid queue, and 9800 of them are encoding random people's MP3's.
The problem is that if you give free resources to a large anonymous community, it takes only a few of those people to suck up all the resources. So you need some way of identifying everyone who submits a job, and some way of charging for the jobs.
Dude, is your C compiler that bad? I like Java a lot, and use it for compute intensive applications, but I think you're either pretty bad witha c compiler or trolling. if you're doing something CPU intensive in C, you need to use gcc -O2 (or -O3, depending), with -march=cputype. This will allow gcc to generate exactly the same code you just described, since it is not limited to 386 instructions. And if you need even more performance, you can just use Intel's C compiler for a lot of things (non-commercial is free as in beer), though it doesn't support some GNU extensions and I think has trouble with some things like the Linux kernel.
I added "www." to the URL, it works.
Try this...
Trolling using another account since 2005.
My experience with numerically-intensive algorithms is that Java is 2-4x slower than C. You can get it within 2x of the speed of C if you ignore object-oriented programming and you're really good at Java optimization, but that's it. And it will run much slower on some architecetures because Java guarantees certain floating-point operation semantics at the expense of speed.
The speed difference oft cited is about 20% on numerical apps. Check out http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html. He brings up "
Benchmarking Java against C and Fortran for Scientific Applications as well.
You have to remember that Java's speed disadvantage is mainly in the JVM startup and GUI areas. Although a good Java dev team can make Swing fly ( checkout JBuilder for instance ).
Java being Just-In-Time compiled can even take advantage make runtime optimizations that your C/C++ application may not.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
> 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.
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.
330am your time buddy.
It's the middle of the morning here in europe and we've taken over the slashdotting duties while you guys get some shut eye.
tom-george.comBecause geeks rate higher t
Ray-tracing traces rays from the eye towards the lights and uses this to simulate how bright a light you see for each pixel. This is great for some things, but isn't realistic, as many lighting effects can't be simulated. Radiosity fills in some of the gaps, but there's still a lot missing. For example if you shine a light onto a mirror at 45 degrees (specular reflection), it won't make light shine onto a diffuse surface at 90 degrees to the mirror, which it would do in real life.
Photon simulation does the opposite of ray tracing and traces the paths of photons leaving the light source and calculates where each photon would hit the view plane if at all. It takes a lot of calculation because you have to send of millions of photons in all directions from the light sources. You can simulate all known light effects this way, just very very slowly. In the image you can see light shining from the light source onto the rear mirror and bouncing off onto the diffuse surfaces at the side.
Both are great for parallel processing because each photon/ray is pretty much independent of others.
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.
Eh... .NET is natively compiled when it's run for the first time. It also optimizes for the platform (even CPU) it runs on.
Supplies!
Two words: Photon Mapping
The simulation you are trying to run does not the kind of compute effort that you are planning on using. I implemented a photon map based renderer for a rendering class last year and it can render a room like the one you showed in a couple of minutes.
The reference you are looking for is:
Realistic Image Synthesis using Photon Mapping
By Henrik Wann Jensen
He is the guy who got the technical oscar this year for being one of the inventors of a method to render materials which display subsurface scattering, e.g. skin and marble.
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
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.
Not really. There is an overhead in java, indeed, but it's caused mainly by objects management. To perform pure calculation, about any language will perform the same. The limit here is the CPU.
Try to factor a big number in C, C++, java or fortran, it will take exactly the same time. The few seconds difference you'll get after a day of calculation are the language overhead that occurs between calculation loops, totally irrelevant when what you do is _only_ those calculation loops (a situation that occurs rarely in traditional development, granted).
Of course, the guy wants his program to run on several kinds of platform but probably cannot afford to develop and test on a lot of OS & machines, so Java seems to be the proper solution.
Kirinyaga
As founder of the Distributed Hardware Evolution Project which is written in Java, I'd like to remind you all that the Just-In-Time compiler coupled with the real time profiling and dynamic on-the-fly optimisation that goes on in the Server VM makes the difference between C and Java minimal for code which is in the critical region. This is specially the case for code which is executed over and over again, such as with these distributed processing projects. In fact the guys at Sun are doing such a good job at exploiting the ever more complex characteristics of different processors that Java code is expected to run faster than C in the future. Also, during the weeks that you would spend debugging and porting your C code, your Java code has gone miles ahead doing useful stuff! If you would like to start your own Java distributed processing project, DistrIT might help.
1 Month on 100 sparcs? Peanuts! In my research simulations usually take (depending on the problem) up to 6 months on an average of 150 workstations (and some runs on large clusters). You wonder what I do? Spin glasses!
Spin glasses are systems in with the interactions between magnetic moments are in conflict with each other. These competing interactions make these systems extremely hard to simulate at low enough temperatures. If you have a linux box sitting around idle which is fast enough, let me know and I will provide you with some samples to run. Current project: 100 - 300 samples, each takes ~ 10 days on a 2.4 GHz Xeon... For information on how to contact me, go to duamutef.ethz.ch. Of course your name will be mentioned if you compute a considerable number of samples!
And pigs _can_ fly.
Here's the deal: when you perform fp ops in Java, operands go where? The _Java_ stack which actually resides on the heap. In C? Usually registers. The JIT register allocation algorithm cannot possibly optimize like a good C compiler can because of the purely stack-based architecture. What's worse - after each fp op, the CPU must fetch byte codes from the class pool which also resides on the heap. So farewell L1 cache line optimization (and sometimes L2 caching)
Note that most benchmarks are too limited, the Lx cache line problems appear in non-trivial applications with a bit more more than a loop doing fp addition.
"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.
Hiya, this would be great. 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. It could also be extended quite easily to do what you're saying, and have a central server where you get credits for donating your CPU cycles and then you can upload your processing task and get other people in the pool to run it.
You could cut your rendering time down to about 1/200th sec by employing the following hardware:
...whatever that blurry thing top right is supposed to be.
old cookie tin
2 marbles
cheap disposable camera and a...
The resultant time saving could be usefully employed learing how the gif file format works.
A pizza of radius z and thickness a has a volume of pi z z a
Either I'm suffering deja vu, or this has been posted nearly verbatim before in a previous discussion of Java vs. C.
Not only that, Face the Facts (770331)'s last three or four posts are word-for-word copies of other people's posts, copied from anti-slash.org's "database tool".
Note only that, but anti-slash.org has posted links to his posts, asking their members to mod him up, with the notation "another karma whore account" -- which implies he's karma whoring in order to get mod points in order to troll.
(Implies but doesn't prove: anti-slash.org at one point asked its members to mod one of my posts up, why I'm not sure.)
But whatever Face the Facts (770331)'s motivations, his posts are plagiarism and he's a plagiarist, apparently not talented enough to write his own posts.
Mod him down.
Opinions on the Twiddler2 hand-held keyboard?
The parent post is stolen, word-for-word from this post by SharpFang (651121).
It was stolen via the anti-slash.org database
Mod parent down.
Opinions on the Twiddler2 hand-held keyboard?
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?
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
I'm just guessing here, but it sounds like he's doing forward ray-tracing on the whole scene. Conventional ray-tracing traces the light rays backwards, i.e from the camera/eye out into the scene and finally back to the light(s). The only problem is that it doesn't really do caustics or diffuse lighting well. POVray faked caustics in version 3 (IIRC), and Radiance has done excellent diffuse lighting using a monte-carlo simulation for about a decade. In recent years photon maps have also developed. These apply forward ray-tracing to selected areas, usually selected refractive and reflective surfaces. The impact points for the photons are recorded and then used in a regular renderer (either scan-line or ray-tracer) as an additional source of light.
Again, it sounds like this guy wants to do this to the whole scene, and to a very high degree of precision. I'm not sure why. Any decent ray-tracer would get a 99% solution in a fraction of the time. Hell, in good hands even scan-line renderers can get a 90% solution even quicker, just look at all the motion-picture visual effects (and whole movies) rendered with Pixar PRman. Most effects don't even need a good ray-tracer to look realistic to most people. Unless he's rendering something more interesting than shiny balls and a mirror, or going to do something interesting with the trillions of photons (near-real-time camera-independent renders?), I really don't see the point. It's still kinda interesting though, if only because of the scale of the work. It might lead somewhere, you just never know.
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!
hmmm. like perl!
here
This comment does not represent the views or opinions of the user.
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.
For instance, let's say you have an interface I, and a class X that implements I. If X is the _only_ implementation of I loaded at the moment, then all calls to methods on I can be direct, non-virtual calls because there's only one choice! In fact, HotSpot will even inline the method calls if it decides it will be beneficial.
But then a class B is loaded. HotSpot will de-optimize the inlined and direct calls to methods on I.
There are many more examples, such as loop bounds-checking elimination, and other things HotSpot can do because it sees the state of the running system.
If you've used a slow Java program, it's no doubt the result of a poor design and coding job by the programmer. "I'll just pick up Java for Dummies in 24 Minutes. Now I'm a 1337 j4v4 h4x0r!!" You may also have been using an old, slow JVM. The performance increases between Java 1.2, 1.3, and 1.4 are truly awesome. Also, Sun's Java 1.5 starts up on my machine in less than half the time that 1.4.2 did, and the graphics as OpenGL accelerated now, ... the list goes on and on. For anyone who had used a Java IDE, especially NetBeans/Forte (which I like, except that it's so freakin' slow I fall asleep between operations), you must try IntelliJ IDEA. It is so responsive and just a joy to use. On the systems I've run it on, it is significantly more responsive than Eclipse.
Dr Superlove 300ml. I use my powers for awesome
This thread is already full of very knowledgable people expoudning at great length as to why Java is not slower (and infact, is often faster than "native code"). Therefore, I will not waste my time writing an indepth response to those who would argue that 1 + 1 in Java is somehow slower than 1 + 1 in C/C++. This post does that quite well. What that comment does not do, however, is explain why some Java programs do, in fact, feel slower than native programs.
I'll simplify this as much as I can without diverging from the technical truth too much. Most complaints that Java is slow come from two sources. First, you must wait for the virtual machine to load, and depending on the libraries used by the program, that can be costly in terms of IO, which is always very slow. Second, Java's GUI toolkits are fairly heavy weight--they do a lot and many programs take advantage of much of the functionality they provide. I won't embark into the details, but to those inclined to find out why should read more about Swing and what Java2D libraries offer. Because of all they do, many Java programs with GUIs feel a little sluggish. Of course, keep in mind that most software sits idle 99% of the time while the user decides what to do. So otherwise, Java code that is not bound by user response time is very fast.
One quick post script: because the Java language is object oriented, complex software will do a great deal of memory allocation and garbage collection as objects come in and out of use. That too, is very expensive. However, there is no reason that you have to use the Java programming language to code for the virtual machine. Case in point: Jasmin. In theory, you could write compilers that generate JVM bytecode from any language (and a former professor of mine is currently in the proceess of writing a book that explains precisely how to do that).
Join Tor today!
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
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
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
I'd do it if I were allowed to get the source, then compile myself.
I love this argument. I hear it from more than a couple people who "want to know exactly what that programmer is up to" before they run it on their own machine. None of them actually read the code. In reality, they want people to think that they can comprehend someone else's code, while truly only proving that they can run a makefile.
I write clear, organized code and I place clear, concise comments where needed. I work with some intelligent, organized people who do the same. The reality is that, even being fully comfortable with their coding styles, I find it very tedious to read their code... even when I know exactly what they're attempting to do. Somehow, I doubt that most people, even programmers, could comprehend the math that goes into the typical raytracing program, let alone one developed by a complete stranger.
I 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.