Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Graphics Software Java Programming IT Technology

Can You Spare A Few Trillion Cycles? 570

rkeene517 writes "11 years ago I did a simulation of 29 billion photons in a room, that got published at SIGGRAPH 94. The 1994 image, called Photon Soup is here . Now computers are 3000 times faster and I am doing it again only much better, with a smaller aperature, in stereo, with 3 cameras, and with some errors fixed, and in Java. The 1994 image took 100 Sparc Station 1's a month to generate. I need volunteers to run the program for about a month in the background and/or nights. The program is pure Java." Read on for how you can participate in the project.

"The plan is to run the program on a zillion machines for a month and combine the results. All you have to do is run it and when the deadline arrives, email me a compressed file of the cache directory. So email me here and I'll send you the zip file. The deadline will be June 1st 2004.

The running program has a More CPU/Less CPU button. Every half hour it saves the current state of the film. The longer and more machines that run this, the cleaner and sharper the image gets. If you have a lot of machines, I can give instructions how to combine the results so you can send in a single cache directory.

Of course, you will get mention in the article if it gets published."

This discussion has been archived. No new comments can be posted.

Can You Spare A Few Trillion Cycles?

Comments Filter:
  • Java eh? (Score:5, Funny)

    by Anonymous Coward on Tuesday April 13, 2004 @04:05AM (#8845535)
    Java eh? So it should run at about the same speed now on modern hardware as it did a decade ago? Chortle.
    • Re:Java eh? (Score:5, Interesting)

      by Anonymous Coward on Tuesday April 13, 2004 @05:23AM (#8845885)
      It depends. If you use Java Objects instead of C / C++ int, then probably yes. If you use Java int instead of C++ int, then the speed is about the same. And you will find absolutely no difference if you need floating point.

      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)

        by AllUsernamesAreGone ( 688381 ) on Tuesday April 13, 2004 @06:33AM (#8846073)
        This is true for pure number crunching where you spend a lot of time in loops.

        Java is quite good at that.

        Now, try writing a real application. One with an interface, one that does real work and spends most of its time interacting with a user rather than banging numbers. Run the test again and you'll find that C++ is significantly faster than Java in this situation because Swing is slower than arthritic snail carrying a small planet and Hotspot isn't good at optimising the sort of stuff a general program has to do.
    • by Jerk City Troll ( 661616 ) on Tuesday April 13, 2004 @10:22AM (#8847682) Homepage

      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).

      • by jafuser ( 112236 ) on Tuesday April 13, 2004 @11:45AM (#8848791)
        Second, Java's GUI toolkits are fairly heavy weight

        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. =)
  • by alphakappa ( 687189 ) on Tuesday April 13, 2004 @04:06AM (#8845546) Homepage
    I hear they use cycles big time there. Pretty cheap too comapared to cars.
  • by isugimpy ( 769087 ) on Tuesday April 13, 2004 @04:06AM (#8845550)
    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.
    • Sorry, I don't have any. I've already donated everything I have to Seti@home. If I get some new PCs I might reconsider where to donate to but I run four PCs at home just for Seti@home. No space cycles yet. I have a rusty racing cycle if you are interested. :)
    • I'd love to see some estimates on how much more electricity the average workstation uses when having all it's idle CPU time being sucked up by these distributed clients. Yes, distributed computing is a nice idea, but I don't see the benefits for the people actually running the client machines since they're not getting paid for their trouble and it's actually costing them for the juice.
  • Real URL to image (Score:4, Informative)

    by FrenZon ( 65408 ) * on Tuesday April 13, 2004 @04:06AM (#8845551) Homepage
    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 [cpjava.net] (you may want to do a 'Save Target As', as the mime-type seems to be a bit off).
    • by jridley ( 9305 )
      This is because his web server is claiming that the MIME type of the GIF is "text/plain"
      I bet if it was .gif instead of .GIF it wouldn't to that. But his server should work either way.

      Time to edit httpd.conf
  • Java? (Score:4, Insightful)

    by Kent Simon ( 760127 ) on Tuesday April 13, 2004 @04:08AM (#8845559) Homepage
    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.
    • Re:Java? (Score:3, Informative)

      by bishiraver ( 707931 )
      Or FORTRAN. FORTRAN is more traditionally used in scientific computing anyways.
    • Oh boy... (Score:5, Insightful)

      by MosesJones ( 55544 ) on Tuesday April 13, 2004 @04:19AM (#8845604) Homepage

      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)

        by pla ( 258480 ) on Tuesday April 13, 2004 @05:07AM (#8845832) Journal
        He needs networking connection, a decent threading model and doesn't want to crash your box.

        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)

          by ultranova ( 717540 )

          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.

          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.

          Personally, I'd say th

          • Re:Oh boy... (Score:3, Insightful)

            by Tet ( 2721 ) *
            Apart from compiler writers, who needs hand-tuned assembler ?

            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)

            Apart from compiler writers, who needs hand-tuned assembler ? It's impossible to port without a complete rewrite, difficult to upkeep, and you'd need to retune your programs every time a new processor comes out.

            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.
            • you hand-tune for your main workhorse arch - that would be mostly for weird cases to use vector units (think SSE1/2/3 or AltiVec) so not a large amount of asm is re
        • Re:Oh boy... (Score:5, Insightful)

          by David Leppik ( 158017 ) on Tuesday April 13, 2004 @10:27AM (#8847734) Homepage
          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.
          Except that what makes Java slow is its do-it-yourself GUI and run-time object management. Those disadvantages mostly go away if you program Java as if it were C: use and re-use arrays of primative types in preference to short-lived objects, and cluster things together in memory (via arrays) when they are used together. The just-in-time compiler will convert the bytecode into machine instructions on the fly, using information that's not available at compile time.
          Personally, I'd say this even sounds like a good candidate for hand-tuned assembly.
          Okay, I'll bite. I've got two macs and to Linux boxes here. Each has a different processor architecture (Celeron, Athalon, G3, G4.) I don't know much about hand-tuning for x86, but on the G4 you shove your floats into 128-bit vectors and do your ray tracing in chunks of four floats. The G3 lacks the vector coprocessor, so you'd optimize it in a very different way.

          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)

        by joib ( 70841 )
        This presentation [berkeley.edu] explains the problems with Java floating point.

        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)

      by hayds ( 738028 ) on Tuesday April 13, 2004 @04:22AM (#8845622)

      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)

      by Anonymous Coward on Tuesday April 13, 2004 @04:32AM (#8845679)
      Not really that slow, depends on what you're doing. At work we're using a CPU intensive Java based "optimizer" that runs a hybrid Genetic Algorithm. We also have a very similar version that was coded in C++. Chances are that the C++ coders sorta sucked, but the end result has been pretty much the same. The only difference was that our Java application actually DOES run on many platforms, including Windows, SuSE, and MacOS X, without a problem. And I can't say it enough times, it's just as fast as the C++ version that only runs on Windows .
  • by Compact Dick ( 518888 ) on Tuesday April 13, 2004 @04:08AM (#8845561) Homepage
    Now ... I am doing it again only much better, with a smaller aperature [sic], in stereo, with 3 cameras ...
    The world needs more dedicated releasers like you.
  • Nah (Score:4, Funny)

    by AstrumPreliator ( 708436 ) on Tuesday April 13, 2004 @04:10AM (#8845569)
    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.

  • by DigiShaman ( 671371 ) on Tuesday April 13, 2004 @04:12AM (#8845579) Homepage
    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.

  • by Dominic_Mazzoni ( 125164 ) * on Tuesday April 13, 2004 @04:14AM (#8845583) Homepage
    The link to the image should be http://www.cpjava.net/raytraces/DRUN.GIF [cpjava.net] (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) [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.
    • by evanbd ( 210358 ) on Tuesday April 13, 2004 @04:30AM (#8845669)
      Not so slow as that... I have no idea about raytracing, but I've done several compute-intensive applications with Java. Both of them, the Java code has run at most 20-30% slower than the C. The two that I have worked with recently are a program that plays Amazons (a modern board game; fairly nifty) and recently one that does stuff with MD5 (searching for partial collisions). Now, I consider myself competent at Java optimization, but by no means an expert. So, a couple minor pieces of advice for anyone who wants to make their java programs a bit faster, and doesn't really know how:

      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.

    • by XNormal ( 8617 )
      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.
    • by Kunta Kinte ( 323399 ) on Tuesday April 13, 2004 @04:44AM (#8845736) Journal

      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.

    • by ajs ( 35943 ) <ajs AT ajs DOT com> on Tuesday April 13, 2004 @07:48AM (#8846339) Homepage Journal
      Yeah, tools like this are excellent. In the astro community, they use a tool called IDL (interactive data language, I think?) which is similar. High level constructs, with lots of big primatives to get you very fast computation.

      Perl has an excellent tool called PDL that does roughly the same thing, and is used by the Perl/Gimp interface, yeilding some wonderful possibilities.

      That said, Java was the right choice for this. Java may have poor systems integration and a host of issues that arise from that (i.e. Java's platform agnosticism, which actually turns into a sort of single-platform dependence on itself with little or no integration with its actual platform), but when it comes to handing thousands of people a program that is going to run mathematical calculations EXACTLY THE SAME WAY on every machine, Java has Python, Perl, Ruby, C# and a host of other high level languages beat because it allows you to enforce very specific constraints on how the math will be done. All of the others just provide you with varying degrees of abstraction on top of your native execution models.

      Once Parrot is done, I suspect that more languages, ported to run on top of Parrot, will also offer these constraints as optional features, but time will tell.
  • Photons (Score:5, Interesting)

    by richie2000 ( 159732 ) <rickard.olsson@gmail.com> on Tuesday April 13, 2004 @04:17AM (#8845593) Homepage Journal
    Thought experiment:
    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)

      by Bandwidth_ ( 91035 ) on Tuesday April 13, 2004 @04:41AM (#8845716) Homepage Journal
      >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

      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:4, Interesting)

      by Yarn ( 75 ) on Tuesday April 13, 2004 @04:46AM (#8845745) Homepage
      I'm a physicist, but IIRC a rod (monochrome sensor) absorbs a photon 50% of the time, and from that absorbed photon outputs a signal about 50% of the time. Hence, about 4 photons to have a high probability of detection.

      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)

        by jcupitt65 ( 68879 )
        I remember doing an experiment in Physics at school to show this. Here's what we did:
        • get an LED, a variable power supply and a sensitive ammeter
        • sit with this stuff in a completely darkened room for 10 minutes so your eyes adapt
        • sit a known distance (eg. 1 meter) from the LED and slowly turn down the power until you can only just see it
        • wait a bit, try looking with your peripheral vision, wait a bit more, you'll find you can turn it down further
        • there's a point where if you concentrate you c
    • You can view individual photons with a Spinthariscope [unitednuclear.com] - that web page has a good description, and it's $25.
    • Re:Photons (Score:3, Funny)

      by jafuser ( 112236 )
      Go outside and look up at a bright star.
      I suppose a disclaimer should be made for our sun being an exception. =P
  • Explain picture (Score:5, Interesting)

    by miike ( 770833 ) on Tuesday April 13, 2004 @04:25AM (#8845639)
    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?
    • Re:Explain picture (Score:5, Informative)

      by rkeene517 ( 637993 ) on Tuesday April 13, 2004 @10:07AM (#8847537) Homepage
      The old 1994 picture is of a cubic room with mirrors on the near and far walls. The 'bubbles' are refletive spheres. A beam of light comes out of the left wall, hits a prism and forms a spectrum on the right wall. The depth of field is very shallow so only objects exactly on the focal plane are in focus. The black fuzzy blob is the camera aperature, out of focus, being reflected in the far mirror. There is an error in the image. The corners of the room are bright and should not be. This is due to a poorly chosen diffuse scattering model. The current project is an almost identicle setup, with 1/4 as big of aperature. I have done about 1 billion photons on my 3 computers, and the new image looks much cleaner. I expcet it will take about a trillion photons to make a realy smooth image.
  • Trust? (Score:5, Insightful)

    by wan-fu ( 746576 ) on Tuesday April 13, 2004 @04:26AM (#8845641)
    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?
    • Re:Trust? (Score:3, Informative)

      by Alsee ( 515537 )
      He's mapping out millions of independant random photons. A handful of stray photons out of millions would have no visible effect. It's not a problem unless you submit a pretty massive number of bogus results. And if the effect was noticible it could probably be traced back you your currupt batch and simply tossed. Tossing data does not currupt the result, it just makes the final image a tiny bit dimmer.

    • Re:Trust? (Score:3, Informative)

      by rkeene517 ( 637993 )
      I will be combining the result in a graphical tool that lets me look at each submission before it gets summed into the result. This will at least prevent some pr0n picture from getting merged in. Also a few bad submissions or duplicates will not throw off the total results.
  • by Xenoproctologist ( 698865 ) on Tuesday April 13, 2004 @04:29AM (#8845661)
    A much larger version of the SIGGRAPH `94 image "Photon Soup", clocking in at 840x560, can be found HERE [uni-hamburg.de].
  • by theguywhosaid ( 751709 ) on Tuesday April 13, 2004 @04:29AM (#8845662) Homepage
    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.
  • Enter applet. (Score:5, Insightful)

    by Kingpin ( 40003 ) on Tuesday April 13, 2004 @04:32AM (#8845681) Homepage
    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

  • by sandwichmaker ( 565653 ) on Tuesday April 13, 2004 @05:13AM (#8845857)
    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.
    • by Gromer ( 9058 ) on Tuesday April 13, 2004 @01:28PM (#8850158)
      The photon map algorithm is great for rendering realistic-looking images, but it is definitely not appropriate for a genuine, hard-core simulation like this guy wants to do. The photon map algorithm is based on physics, certainly, but it makes a lot of simplifications in order to make the rendering efficient. For one, it completely ignores diffraction and interference, treating photons as discrete particles travelling in straight lines. If you really want a physically accurate numerical simulation of the way light behaves in a given physical setting, you need to resort to these much more brute-force techniques.

      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.

  • by Gollum ( 35049 ) on Tuesday April 13, 2004 @05:21AM (#8845879)
    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 [md5crk.com] for the applet in question.
  • by Avt232 ( 691144 ) on Tuesday April 13, 2004 @05:36AM (#8845925)
    As founder of the Distributed Hardware Evolution Project [susx.ac.uk] 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 [sun.com] 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 [sf.net] might help.
  • by dummkopf ( 538393 ) on Tuesday April 13, 2004 @05:38AM (#8845934) Homepage
    1 Month on 100 sparcs? Peanuts! In my research [duamutef.ethz.ch] 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 [duamutef.ethz.ch]. Of course your name will be mentioned if you compute a considerable number of samples!
  • by Andy_R ( 114137 ) on Tuesday April 13, 2004 @06:06AM (#8846004) Homepage Journal
    You could cut your rendering time down to about 1/200th sec by employing the following hardware:

    old cookie tin
    2 marbles
    cheap disposable camera and a... ...whatever that blurry thing top right is supposed to be.

    The resultant time saving could be usefully employed learing how the gif file format works.
  • by cornjones ( 33009 ) on Tuesday April 13, 2004 @06:16AM (#8846039) Homepage
    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?
  • by PhunkySchtuff ( 208108 ) <.ua.moc.acitamotua. .ta. .iak.> on Tuesday April 13, 2004 @06:37AM (#8846081) Homepage
    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?
    • by Anonymous Coward on Tuesday April 13, 2004 @08:04AM (#8846424)
      Photon Simulation: "forward ray tracing". Emit photons from light sources, have them bounce off scenery, and see where they hit the eye.

      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.
      • A reasonable explanation. There is a new technique called photon mapping too. Photons are emitted from the light sources much like this guy is doing. However, each time a photon hits a surface, the impact is stored in a big data structure - the photon may then be reflected depending on surface properties. This "photon map" is view independant. Rendering an image then consists of doing ray tracing from the eye into the scene, but to calculate surface illumination where the ray hits a surface, you use the pho
  • by t_allardyce ( 48447 ) on Tuesday April 13, 2004 @09:20AM (#8847006) Journal
    here [uni-hamburg.de]
  • by aksansai ( 56788 ) <aksansai&gmail,com> on Tuesday April 13, 2004 @10:26AM (#8847723)
    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.

    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 .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.

    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 .NET platform) in the last few years compared to Java in the first few years.

    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.

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein