Can You Spare A Few Trillion Cycles? 570
"The plan is to run the program on a zillion machines for a month and combine the results. All you have to do is run it and when the deadline arrives, email me a compressed file of the cache directory. So email me here and I'll send you the zip file. The deadline will be June 1st 2004.
The running program has a More CPU/Less CPU button. Every half hour it saves the current state of the film. The longer and more machines that run this, the cleaner and sharper the image gets. If you have a lot of machines, I can give instructions how to combine the results so you can send in a single cache directory.
Of course, you will get mention in the article if it gets published."
Java eh? (Score:5, Funny)
Re:Java eh? (Score:5, Interesting)
I did quite a lot of C++ and Java programming. At one point, I thought: 'oh, I have now a beautiful and quite fast Java fractal application (mandelbrot), let's convert that to C++ and it will be even faster.'. It was even slower in C++ (probably because of the C++ compiler, Visual Studio). And that was quite a long time back. The link is: http://users.quick-line.ch/thomasm
Re:Java eh? (Score:5, Insightful)
Java is quite good at that.
Now, try writing a real application. One with an interface, one that does real work and spends most of its time interacting with a user rather than banging numbers. Run the test again and you'll find that C++ is significantly faster than Java in this situation because Swing is slower than arthritic snail carrying a small planet and Hotspot isn't good at optimising the sort of stuff a general program has to do.
Re:Java eh? (Score:3, Insightful)
I've still yet to be shown an example of a Java program that runs faster than an equivalent C or C++ program, whereas I've had a wealth of experience with things being around the other way (one extreme example was Java: 8 hours, C: 30 seconds).
The Hotspot argument is hot air, since the time you spend re-compiling the whole program (JIT of cou
Re:Java eh? (Score:5, Informative)
Given that this was an exercise, I'm somewhat tempted to ask whether you aren't counting the JVM startup time on top of a very short problem instance.
C: 30 seconds, Java: 8 hours. No kidding. These were running on the same laboratory machines, the Java programs using the latest Sun JVM at the time. The exercise involved calculating some statistics from a simulation run for one virtual year. Most of the people doing the Java version had to leave it running overnight. Besides, JVM startup time is a performance issue, you can't just dismiss it out of hand.
That, or whether the exercise involved lots of dynamic creation of objects (in which case your program was by definition not doing the same thing as the Java implementations). The exercise you mention sort of sounds like that.
In the Java version, each event was an object. In C each event was a malloc'd struct. These are analagous in that they are the correct way to solve the problem in that particular language. The fact that object creation and destruction is a lengthy process is an important reason why Java is so slow. It's an object-oriented language, its raison d'etre is to create and destroy objects. If it can't do that fast enough then what's the point in it being able to do anything else with speed?
I know at this point the Java apologists will say "just use a pool of pre-created Objects, that'll speed it up". This misses the point in two ways: (1) Java was supposed to obviate the need to perform manual memory handling. Now I have to not only remember to de-allocate my objects when I am done with them, I have to write a Pool class within which to store my not-currently-in-use objects?! (2) I can do that in C, too, if I really want to, and it'll make the C version faster again.
I am well aware of the forte of Haskell and its different interpreter implementations. To the degree that I wouldn't be surprised if the Haskell implementation did better than your C implementation.
They didn't. I was told they took around 10 minutes to run, but I never actually saw them working. When I produced results from a simulation that ran for 1000 years (an overnight run for my C program), the professor was amazed. But yes, in my experience interpreted Haskell is very fast, which makes Java look even more foolish.
I've done this four times now; written a C equivalent of a Java program and found it at least one, often several orders of magnitude faster. I've yet once to be shown a Java program that is significantly faster than its C equivalent.
This does not mean that Java should not be used as a programming language. The language features (especially those in version 1.5) are useful for working in a collaborative environment with mediocre programmers, and where the raw performance of the application is not critical (such as a GUI front-end to a server application). Just don't bullshit about it being faster than C, or even "fast" and expect me to believe it.
I'm willing to be proven wrong, but until someone can actually show me proof that it can be done, I'm not going to believe the hype, hand-waving and hot air.
Re:Java eh? (Score:4, Informative)
pop AX
STOSW 0x0005
pop AX
STOSW 0x0005
Even though the code may be running on a Pentium Pro (which is optmized for 32 bit code), it's still going to execute those 4 statements.
Now, the Java Hotspot compiler will start and notice the fact that you're running on a Pentium Pro. So when it converts the bytecode to machine code, it creates the following instructions:
pop EAX
STOD 0x0005
That's twice as fast as the C code!
Real code would tend to be running on modern processors, so this example is a little contrived. However, the JVM can (and will) use SSE instructions to do multiple calculations in one instruction, while the C code will be forced to generate non-SSE instructions to support the old Pentium Is out there.
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.
Does that explain it better?!
--
This post is open source, retransmit as desired.
Re:Java eh? (Score:3, Insightful)
The problem with that is that the 386 is 32 bit! You're comparing a C compiler making 16 bit code for a 286 to a java compiler for a 32 bit platform. Unless you know of a java runtime that works on 286 or worse processor, that's not a fair comparison.
It's still silly anyways. Compilers can produce code tuned for different CPUs. There is no need to compile for the
Re:Java eh? (Score:5, Insightful)
Re:Java eh? (Score:5, Interesting)
All the Java apps I use that are not trivial tend to eat at least 100Mb of ram, and sometimes several hundred. They also tend to stomp all over my poor CPU, which, at 500-1000Mhz, really ought to be fast enough for most things (seriously, I'm not trying to crunch SETI data or crack an RC5 key here).
I attribute most Java slowness to poor programming techniques. Its got to be, since Java programmers are always telling me how fast the code really is; it must just be that most Java coders are so crappy that they drag that blazing fast JVM to its knees.
Re:Java eh? (Score:3, Insightful)
gcc -msse -msse2 -mfpmath=sse -march=pentium4 -O3
Does anyone check before they moderate? (Score:3, Insightful)
Re:Java eh? (Score:5, Informative)
rkeene517 is asking for volunteers to run the program. If rkeene517 does it in C/C++ then rkeene will have to compile for the different x86 types and ensure that volunteers download the right binary. From experience you end up getting a high number of people getting the generic x86 binary instead of the optimized one because in order to avoid zillions of support queries, you have a "If you are unsure, click on i386".
Of course you could bundle all the various binaries and add code or a binary that figures out what x86 it is and runs the relevant binary.
But that involves a step more than what you suggest.
Re:Java eh? (Score:3, Informative)
Re:Java eh? (Score:4, Informative)
Sure, you can configure compilers as narrowly as you like, but in most cases, compliation will be targeted at the lowest common denominator.
If your compiling for yourself, you have the luxury of building for your own CPU. This isn't the case here.
Why do you think Linux binary rpm's, for years, were compiled for 386 chips. It's only recently that some (all?) distributions have started distributing 586 based rpms.
The point is, Java can make this decision at run-time, and hence target the actual CPU. C++ code can not (without a lot of pain, at least).
But HotSpot compiles and RECOMPILES on the fly (Score:5, Informative)
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 [intellij.com]. 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.
Re:But HotSpot compiles and RECOMPILES on the fly (Score:5, Interesting)
1) That's because you're using Java 1.x. Use Java 1.y instead, it's got all these new performance features...
2) That's because it's using the old GUI toolkit. Use the new one instead...
3) That was with the old JVM. Use the new one...
4) That was with the old JIT. Use the new one...
5) That's because you're using a slow XX Hz CPU. Don't be a tight wad and upgrade to a YY Hz CPU intead...
Why should I believe you this time? You might actually be right, but I really don't care anymore. You had your chances, nine and a half years of them, so I'm not giving you any more.
Re:But HotSpot compiles and RECOMPILES on the fly (Score:4, Interesting)
That's because the programmers don't know how to program.
I was making systems that output efficient usable applets in 96. I've taken serverside systems that could barely handle a single user to handling 1300 simulataneous users. My experience has been very few people know how to code usable Java, and when their Java is unusable, they give up and say "it's because Java is slow." Of course, I never really believed that since I played a Quake map via an applet on a 200MHz Pentium Pro. I figured if whoever did that could get 30fps, I could have my lists drop down in a timely fashion.
Re:But HotSpot compiles and RECOMPILES on the fly (Score:3, Interesting)
The biggest problem is that Microsoft shipped a shitty 1.1 java version for many years, thus people who thought they had java, just had a 4 year old VM.
Java is faster where it matters, debug time!! I as a programmer am very happy not having to deal anymore with alloc's and arrays
Re:But HotSpot compiles and RECOMPILES on the fly (Score:3, Informative)
I don't think HotSpot takes nearly as much resources as people think it does, and gains quite a bit with (seemingly) simple optimizations.
Sun (am probably others) also have a statistic
Re:Java eh? (Score:3, Insightful)
Yes we know it CAN be done, but what is the PRACTICAL solution?
Sick of the clueless blasting Java performance... (Score:4, Informative)
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 [slashdot.org] 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 [nyu.edu]. 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).
Re:Sick of the clueless blasting Java performance. (Score:4, Informative)
This is probably why SWT [eclipse.org] 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. =)
Dude, you should try out China (Score:5, Funny)
More distributed processing (Score:4, Insightful)
Re:More distributed processing (Score:3, Funny)
Re:More distributed processing (Score:3, Interesting)
Re:More distributed processing (Score:4, Insightful)
If you don't want to pay however much extra it might be, you don't have to participate; nobody's forcing you.
Real URL to image (Score:4, Informative)
The URL to the photo soup image is missing the 'www'. The image can be seen here [cpjava.net] (you may want to do a 'Save Target As', as the mime-type seems to be a bit off).
Re:Real URL to image (Score:3, Insightful)
I bet if it was
Time to edit httpd.conf
Re:Real URL to image (Score:3, Informative)
IE ignores the MIME type provided it by the server, in violation of RFC 1945 and RFC 2616 ("Hypertext Transfer Protocol -- HTTP/1.0" and "...-- HTTP/1.1") sections 7.2.1 (reprinted below from the latter), and instead sniffs the content to determine how to render it. Anything served as "text/plain" is treated with suspicion and reinterpreted by IE in violation of this section.
Java? (Score:4, Insightful)
Re:Java? (Score:3, Informative)
Re:Java? (Score:4, Insightful)
I think the primary reason is that there are enormous numbers of numerical routines in Fortran that are extremely well debugged and validated.
Change to other languages and those routines must be rewritten, redebugged, and revalidated.
Oh boy... (Score:5, Insightful)
He needs networking connection, a decent threading model and doesn't want to crash your box.
So while he could spend a huge amount of time doing all these basic things in C and still have major risks for the people running it, he has chosen to use the right tool for the job.
Also the Maths libraries are IEEE compliant in Java and not in C on the PC, so I'm assuming that also played in to his reasoning.
Re:Oh boy... (Score:4, Insightful)
False, on all of the above.
For "networking", users will manually send him their cache directory (as the FP explicitly stated). As for threading... To do what? He wants to run a completely straightforward trajectory simulation, iterated a few "zillion" times. I'll admit that I have a bias against most uses of multithreading and consider them inappropriate 99.9% of the time, but if you can even force them onto this project, you need to go back to the drawing board.
So while he could spend a huge amount of time doing all these basic things in C and still have major risks for the people running it, he has chosen to use the right tool for the job.
Umm... Yeah, whatever. He wants to run a CPU-intensive background process, performing a totally straightforward set of calculations, and nothing else. No GUI (beyond a few simple controls to make it play nice), and nothing server-side - sounds like a perfect candidate for anything but Java.
Personally, I'd say this even sounds like a good candidate for hand-tuned assembly. But then, at least from my alma-mater, they don't even require that to graduate in CS anymore. Sad... And people actually wonder why tech jobs keep heading for India. Well, the FP and you just provided a nice answer - Using Java for a tightly CPU-bound problem? Using threads for the same (Ever heard of "cache consistancy"? Yet another reason to avoid multithreading in a program of this nature)? Why not just downgrade to a 486? Same effect, less complex.
Re:Oh boy... (Score:3, Interesting)
There's this thing called SMP, which lets you have multile CPU's in one machine. But, to take any advantage of it, you'll need one thread per CPU.
Re:Oh boy... (Score:3, Insightful)
You do. If you can't write assembly language, then you will never be as good a programmer as those who can. Whether you actually use it is another matter. I haven't had to actually write anything in assembly language for well over a decade. But the fact that I could if I needed to helps, even when writing in a higher level language, because I have some clue about what's going on under the covers.
Re:Oh boy... (Score:3, Informative)
This is a very special case he has - HPC. It's one of the few that actually do benefit from hand-tuning optimizations in some places.
Re:Oh boy... (Score:5, Insightful)
Besides, by writing in Java and not hand-written assembly, he gets to run it on machines like mine, which probably weren't the original target platform. The name of the game in distributed processing is to use as many spare processors as possible, even if some are slow. An hour of work to promote his project is more likely to pick up 10% more (or 1000% more, with \.) CPUs than an hour of hand-tuning assembly is likely to get 10% more speed out of a particular processor.
Re:Oh boy... (Score:3, Informative)
Incidentally, C99 has very nice support for IEEE 754 (improved numerics support was, in fact, one of the biggest additions compared to the old C89 standard).
Re:Java? (Score:5, Insightful)
Java can actually be quite fast and efficient for number crunching or scientific applications because of the JIT compilers and automatic optimisation. Its only painfully slow when you need a GUI. It also has a great class library so he should be able to do things like the visualisation and the networking for the clients to send the data home relatively easily, whereas it would take a lot longer to write and debug in C.
Also with Java, he can just offer the JAR file on his site or whatever and people can d/l it and run it. I guess this isnt really important if he's aiming at geeks, but if he's trying to get others to participate, it is handy that people wont need to worry about compiling it themselves or picking the right version (like at the seti@home site).
Re:Java? (Score:5, Informative)
Hi-quality pr0n (Score:4, Funny)
Nah (Score:4, Funny)
=P
Comment removed (Score:4, Funny)
Re:Best time is Winter (Score:3, Insightful)
Broken link, java jab (Score:5, Informative)
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) [pfdubois.com] - 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.
Re:Broken link, java jab (Score:5, Informative)
1. Learn to use java -Xprof. This is a rudimentary profiler, but even the most basic data is useful. Concentrate on the parts that get the most use.
2. If -Xprof says the garbage collector is taking more than about 1-2% of the cpu, it's a problem. If it's at 10%, it's costing you well more than 10% speed -- lots of reasons, like cache misses, thread switching, and the allocations in the first place.
3. Don't delete objects in the main loop. Use factory methods and the like if you have to. This is how you decrease GC times.
4. Some of the standard API pieces are very slow. I've had particular trouble with anything related to the Collections framework, and Strings are even worse. Avoid these.
Now, all this takes work, but it's not particularly harder or easier than doing good optimization of C Code.
Re:Broken link, java jab (Score:4, Informative)
Numpy is great, but... (Score:3, Informative)
you need to work on your java skills then... (Score:5, Informative)
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 [idiom.com]. He brings up "
Benchmarking Java against C and Fortran for Scientific Applications [philippsen.com] 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.
Re:Broken link, java jab (Score:4, Insightful)
Perl has an excellent tool called PDL that does roughly the same thing, and is used by the Perl/Gimp interface, yeilding some wonderful possibilities.
That said, Java was the right choice for this. Java may have poor systems integration and a host of issues that arise from that (i.e. Java's platform agnosticism, which actually turns into a sort of single-platform dependence on itself with little or no integration with its actual platform), but when it comes to handing thousands of people a program that is going to run mathematical calculations EXACTLY THE SAME WAY on every machine, Java has Python, Perl, Ruby, C# and a host of other high level languages beat because it allows you to enforce very specific constraints on how the math will be done. All of the others just provide you with varying degrees of abstraction on top of your native execution models.
Once Parrot is done, I suspect that more languages, ported to run on top of Parrot, will also offer these constraints as optional features, but time will tell.
Photons (Score:5, Interesting)
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).
Re:Photons (Score:5, Interesting)
>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).
The rods in human eyes are incredibly efficient photoreceptors. They can reportedly be triggered by individual photons under optimal conditions. This was proven by experiment in the mid 1950s sometime in a pitch black room after 30 minutes of adaptation. A controlled light source was placed at an angle of 20 degrees or so away from the eye plane and tests were done such that the absolute minimum threshold of light intensity was found. Calculations based on angle, spread, etc were made and the area the light source would hit in the eye. It was found that, as stated above, rods could reliably detect single photons.
It's an evolutionary limit of sorts. I may be off on the procedure as I'm recalling it from an odd psychophysics book I read back at uni but I'm fairly sure of the single photon thing.
Re:Photons (Score:3, Interesting)
You notice it when there is a small bright light source on a moving object in a dim area. For instance, one of those bouncy balls with flashing LEDs embedded in them. If the ball is rolling across the floor, sometimes the flashes will appear to slightly preceed the ball.
Re:Photons (Score:4, Interesting)
The colour sensors (cones) are less sensitive. Whilst googling for the sensitivity of these I found a page detailing the sensitivity of the eye [nus.edu.sg] It needs about 500 to 900 photons/sec to actually register. However, I've already written about rods so I'm not going to delete that!
Re:Photons (Score:3, Informative)
View photons at home, $25 (Score:3, Informative)
Re:Photons (Score:3, Funny)
I suppose a disclaimer should be made for our sun being an exception. =P
Re:Photons (Score:5, Funny)
For example, when looking at a photon detector.
Explain picture (Score:5, Interesting)
Re:Explain picture (Score:5, Informative)
Trust? (Score:5, Insightful)
Re:Trust? (Score:3, Informative)
-
Re:Trust? (Score:3, Informative)
Photon Soup: Longer and Uncut (Score:5, Informative)
Re:Photon Soup: Longer and Uncut (Score:3, Informative)
which would you rather run? (Score:5, Insightful)
Enter applet. (Score:5, Insightful)
1. The client PC runs the program in a sandbox
2. Most client PC's don't need additional software installed (if written for JDK 1.1)
3. The user does not need to know how to invoke a Java application
4. There's no administrative overhead in iniating the application, just go to a URL
There are better ways of doing this (Score:5, Interesting)
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.
Re:There are better ways of doing this (Score:4, Informative)
By the way, I'm going out on a limb here, but I have a feeling that someone who's been published in SIGGRAPH (THE graphics conference) is aware of the state of rendering algorithms in general, and of the existence of photon mapping in particular. Just a guess.
I like the Md5Crk applet model (Score:4, Interesting)
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 [md5crk.com] for the applet in question.
Java has come a long way since 1998 (Score:5, Informative)
I need cycles, too! for spin glasses... (Score:4, Informative)
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 [duamutef.ethz.ch]. Of course your name will be mentioned if you compute a considerable number of samples!
Use real photons (Score:5, Funny)
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.
isn't this duplicate work (Score:3, Interesting)
Re:isn't this duplicate work (Score:4, Informative)
Photon Simulation vs Raytracing (Score:4, Insightful)
In what major way is photon simulation different from ray tracing?
Re:Photon Simulation vs Raytracing (Score:5, Informative)
Ray tracing: "reverse ray tracing". Emit "sight rays" from the eye, have them bounce off scenery, and see where they hit light sources.
That's simplifying, of course.
Forward ray tracing was here first, but was quickly (all but) abandoned, since it is computationally way more intense (why, 10 years ago, it would have taken 100 Sparc Station 1's an entire month just to calculate one small image!). Imagine simulating a zillion photons just to discover that over 0.99 zillion had failed to reach the eye...
On the other hand, it is physically more correct, since effects like caustics are very difficult to do right in "reverse" ray tracing.
Re:Photon Simulation vs Raytracing (Score:3, Informative)
A slightly odd looking mirror (from google) (Score:3, Informative)
Speed an issue - then why Java? (Score:3, Insightful)
Being an regular software developer and a web applications developer, I have found the versatility of Java does not outweigh the performance penalty attributed to emulated code execution. Java (historically) does not, in my opinion, adequately take advantage of new processor features (MMX, SSE, etc.) to accelerate code execution. I believe, in fact, it was only announced recently that Sun would be aggressively adding better MMX and SSE support in the virtual machine. Even poorly written C++ code will be optimized by a smartly written compiler to run very fast.
Could Java's lack of aggressive optimization be due to Sun's focus on reality being away from the most popular instruction set on the planet for personal computing (x86)? Further, why re-emulate the same byte-code over and over? The JIT has to produce the equivalent native language codes to get it to run on a particular processor platform. Why not cache these codes (like what DEC did with the Alpha's x86 interpreter or like
There are emerging languages and technologies that are attempting to complement older languages, provide the wealth of structure that Java has laid out, but still build further to make it that "answer to all problems" language. Sun's interdicting hold on Java makes its development as fast as its developers and contractors can muster. Other companies or open source communities have the potential to make great strides in rapid development. Look where C# is (upon the Mono or
A side arc (experiment, if you will) would be to port the application to C++ and to C# (CLR) and run the calculations on both Windows and Linux - take a comparison against Java running on those two platforms. I believe it is quite obvious WHICH language(s) would be declared the winner. So, instead of us having to dedicate a few trillion cycles, maybe one trillion would do.
Re:Java is a slow cruncher (Score:5, Insightful)
FP ops in Java are incredibly slow and broken.
Er, do you have any more recent numbers than a lecture from 2001, originally published in 1998??
Re:Java is a slow cruncher (Score:3, Insightful)
Re:Java is a slow cruncher (Score:3, Insightful)
And pigs _can_ fly.
Here's the deal: when you perform fp ops in Java, operands go where? The _Java_ stack which actually resides on the heap. In C? Usually registers. The JIT register allocation algorithm cannot possibly optimize like a good C compiler can because of the purely stack-based architecture. What's worse - after each fp op, the CPU must fetch byte codes from the class pool which also resides on the heap. So farewell L1 cache line optimization (and
Re:Java can be faster then C sometimes (Score:4, Informative)
Astounding.
Re:Java can be faster then C sometimes (Score:4, Insightful)
Not only that, Face the Facts (770331) [slashdot.org]'s last three or four posts are word-for-word copies of other people's posts, copied from anti-slash.org's [anti-slash.org] "database tool".
Note only that, but anti-slash.org has posted links to his posts, asking their members to mod him up, with the notation "another karma whore account" -- which implies he's karma whoring in order to get mod points in order to troll.
(Implies but doesn't prove: anti-slash.org at one point asked its members to mod one of my posts up, why I'm not sure.)
But whatever Face the Facts (770331)'s motivations, his posts are plagiarism and he's a plagiarist, apparently not talented enough to write his own posts.
Mod him down.
Re:Java can be faster then C sometimes (Score:5, Informative)
Re:Java can be faster then C sometimes (Score:3, Informative)
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 d
Re:Java can be faster then C sometimes (Score:3, Interesting)
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 optim
power consumption (Score:5, Insightful)
I measured this in 1997 on some kind of AMD K6 machine. IIRC, running dnetc doubled the power consumption of the machine.
Anonymous grid computing (Score:5, Insightful)
Then there's the security issue.
But I see another problem which is even harder to solve: the tragedy of the commons. Consider a university campus, and suppose that anyone on campus can submit jobs to the Campus Grid. You come in the next morning and see that there are 10000 jobs in your grid queue, and 9800 of them are encoding random people's MP3's.
The problem is that if you give free resources to a large anonymous community, it takes only a few of those people to suck up all the resources. So you need some way of identifying everyone who submits a job, and some way of charging for the jobs.
Re:Anonymous grid computing (Score:3, Informative)
Most (all?) universities already have an authentication-system in place that is used on campus-computers, both for local and remote login. This can be applied to grid-computing, too. That way you can punish those who abuse resources like you already do if somebody deci
Re:Anonymous grid computing (Score:3, Interesting)
Go a bit further and institute a bidding system for allocation of resources.
For example, if I want to run some monster job and don't have the credits, I have to wait for credits to accumulate by letting others use my computer. Or I could submit a bid for the credits I have available in case the bid might win during a period when usage was light.
The bid would include the total number of credits offered to do the job, the amount of processing power desired (number of processors, minimum processor requirem
Re:Wireless or not... (Score:3, Informative)
It was stolen via the anti-slash.org database
Mod parent down.
Re:Bad link (Score:4, Informative)
Try this [cpjava.net]...
Re:Mother Goose (Score:3, Funny)
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.
Re:Java? No wonder you need cpu cycles. (Score:4, Informative)
Re:Java? No wonder you need cpu cycles. (Score:3)
Re:Povray ? (Score:5, Interesting)
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 [povray.org] faked caustics in version 3 (IIRC), and Radiance [lbl.gov] 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.