Forgot your password?
typodupeerror
Graphics Software Java Programming IT Technology

Can You Spare A Few Trillion Cycles? 570

Posted by timothy
from the distributing-the-light dept.
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:
  • 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).

  • 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: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
    >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:Insightful my ass (Score:2, Interesting)

    by francium de neobie (590783) on Tuesday April 13, 2004 @04:44AM (#8845739)
    > 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
  • 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!
  • 3 cameras? (Score:2, Interesting)

    by 91degrees (207121) on Tuesday April 13, 2004 @04:46AM (#8845746) Journal
    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.
  • by Anonymous Coward on Tuesday April 13, 2004 @04:49AM (#8845755)
    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 [sun.com], 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.
  • by sonamchauhan (587356) <sonamc&gmail,com> on Tuesday April 13, 2004 @04:54AM (#8845785) Journal
    Optimising compilers can do much the same thing for C programs. Hotspot JVMs don't have an advantage over all C programs - just mostly those compiled with no optimization. I am not sure though, about the advantages JIT profiling gives to Java programs and whether some C compilers offer the same features to C programs.

    I recall an article by Intel engineers (recent DDJ I think) that described how an executable compiled with their compiler could detect the runtime platform and choose among code-segments optimized for different platforms. These compilers also automatically 'vectorize' non-vector instructions - i.e. they use MMX/SSE/SSE2/3DNow with unrolled loops.
  • by 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 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.
  • 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:Oh boy... (Score:3, Interesting)

    by ultranova (717540) on Tuesday April 13, 2004 @05:25AM (#8845892)
    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 this even sounds like a good candidate for hand-tuned assembly.

    Tuned for what processor ?

    But then, at least from my alma-mater, they don't even require that to graduate in CS anymore.

    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.

    Developer time is better spent optimizing algorithms than performing mechanical tasks that the computer can do for you.

  • by eric76 (679787) on Tuesday April 13, 2004 @05:26AM (#8845894)

    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 requirements, type of processors, and maximum length of time per processor).

    During spring break when everyone is out of town, processing power could become cheap enough to run some really big jobs. Saturday night when everyone is out partying might give one a chance to run some reasonably large jobs.

    In other words, the bidding system would try to maximize utility by giving priority to projects that the submitter thinks highly enough to offer more credits to run the project.

    Add the ability to do checkpointing so you can restart the tasks being handled by one computer on another. An ability to migrate tasks from computers that suddenly become busy to other, less busy computers would be invaluable, too.

    Some method of transferring credits from one person to another would help. You might be able to obtain additional credits from others by mowing their lawn or something.

    It could be the basis for a whole new economy.

  • Re:Java eh? (Score:0, Interesting)

    by marcovje (205102) on Tuesday April 13, 2004 @05:28AM (#8845904)

    C++ should be able to run circles around Java.

    And VS is not targeted at numeric work, but should
    be able to outrun Java.

    Of course, if your work is one or two loops inside one method, or one method with e.g. possible tailrecursion, language doesn't matter much, only compiler optimization. I think that happens to your mandelbrot, but that is not typical for scientific calculation.

  • by FireFury03 (653718) <slashdot@nexus[ ]org ['uk.' in gap]> on Tuesday April 13, 2004 @05:54AM (#8845970) Homepage
    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.
  • 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?
  • Re:Povray ? (Score:5, Interesting)

    by imroy (755) <imroykun@gmail.com> on Tuesday April 13, 2004 @07:33AM (#8846258) Homepage Journal

    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.

  • A: 1 Re:Photons (Score:2, Interesting)

    by feelyoda (622366) on Tuesday April 13, 2004 @08:19AM (#8846512) Homepage
    The dark adapted eye can detect a single photon. This is the only known direct macro observation in biology of a quantum mechanical event.
  • Re:Java eh? (Score:2, Interesting)

    by tolan-b (230077) on Tuesday April 13, 2004 @08:21AM (#8846526)
    I don't think Java will often be faster than C++, the point is that for a lot of things it needn't be noticeably slower. Yes SWT is native, but that's only one component, GUIs really are better in native code. Swing (or is it AWT? I've never used either) is native too, it's just built into the JVM instead of being separate.

    I know you've probably heard it before, but try Eclipse on Windows or OSX, bar the startup times, I find it indistinguishable from a native IDE.
  • Re:Java eh? (Score:5, Interesting)

    by Suidae (162977) on Tuesday April 13, 2004 @09:25AM (#8847061)
    I don't know why Java is so slow, but I wonder if it has something to do with memory requirements/managment?

    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:Photons (Score:3, Interesting)

    by Suidae (162977) on Tuesday April 13, 2004 @09:43AM (#8847248)
    I've seen information that rods are somewhat slower than cones, so that fast moving things in dim lighting can appear behind their actual position (I suspect that our brains make up the difference so we can still catch thrown balls, ect).

    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.
  • by Brandybuck (704397) on Tuesday April 13, 2004 @01:55PM (#8850497) Homepage Journal
    Java has been out for how long now? Nine and a half years. A whole freaking decade! Yet every damn time someone mentions the poor performance of Java, the same standard excuses are trotted out, with an exhortation to use the new and improved Java:

    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.
  • by Fjord (99230) on Tuesday April 13, 2004 @02:22PM (#8850872) Homepage Journal
    I've been sayign the same thing since 1996:

    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.
  • by orasio (188021) on Tuesday April 13, 2004 @03:02PM (#8851311) Homepage
    All those are reasonable claims. If you came bitchin about Slackware 3.4 I would tell you to go use Slack 9.1. You can say that all MS software is shit, but you should bitch about XP, not about win95. Same thing happens with Java.

    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 out of bounds!

    As most of my current work has a web interface, I like java servlets, because it is easy to program complex systems in java, and _for_me_ it's easier to maintain than php. Servlets are real fast.

    Anyway, java graphical interfaces are very slow. But compared to what? Windows, which takes forever to load its graphical interface? or kde, which takes a looong time intializing some DCOP crap when I want to load the only kde application I use? or gnome? well, gnome is not that slow, but it is slow anyway. I think that anyway, on load times, graphical java application are not the slowest, but among the fastest loaders.

    Now it comes to the issue of hardware acceleration. Windows graphical interfaces are fast because they use some acceleration that slow graphics cards (SIS, anyone?) provide, so windows interfaces are not thaaat slow. When you have a decent graphic card (not a gforcefx5950, just a matrox g100 or a savage4, or a TNT) you start to see that maybe it was not that slow. When you get a faster card, you start to understand that mabe java is just as fast in the desktop as it is in the server, it just was slow in its old version , with old video cards, and in windows, compared to others that were optimized for that situation.

    -- End of rant. --
    Java was always fast, on the server.
    Java was slow, on the GUI, in windows, with old video cards.
    Java is fast, on the GUI too, in any platform, with "new" video cards.

    And, if you don't want to try it, well, I think it's your loss, meanwhile I am going to finish my own photon mapping renderer for java, so I can match up my times with this guy's.

  • Re:Java eh? (Score:3, Interesting)

    by JWSmythe (446288) <jwsmythe@@@jwsmythe...com> on Tuesday April 13, 2004 @04:05PM (#8852069) Homepage Journal
    I've done some tinkering in Java. I don't *LIKE* the language, but that's another story.

    You're fairly close on the poor programmers. I was writing a java applet to handle streaming video for users (display in the browser). I wrote something myself, which ran ok. I also downloaded, decompiled, and read several other people's works. None of them worked very well, but they were what was available at the time (this was several years ago). I ended up taking his applet, and rewriting it. In the end, there was nothing left of the original program, but it gave me interesting design ideas.

    So by the time I was done, I had an applet that was fairly quick, and worked pretty well on x86 (Windows and Linux). Users reported that it worked on other *nix's also. Then came in the Mac complaints.

    It took a couple weeks to work it out so it would work as expected on the major platforms. It would still crash random people's browsers, or even their whole machines, but it wasn't reproducable on any of our machines, even with the same os and browser versions as they had.

    In the end, I spent another day writing a cute chunk of javascript, which did the same job *MUCH* more efficently. It worked on every browser that supported JavaScript with almost no exceptions (like, none I can think of, but...). The JavaScript was much smaller, and much faster, to do the same job.

    I don't write in Java any more. Well, I guess I could, I just don't. Looking at other people's Java work, I don't see much use into getting back into it. Their applications do hog much more of the machine than they should. If they work, they're fine, but the odds of getting a particular application to work on a particular platform are slim, unless you're using the specific platform that it was written for.

    One case in point was a java program written on RedHat 7.3, using IBM's distribution of Java (I think) and IBM DB2.

    Try tried to run it on RedHat 9 with Sun's Java, and IBM's DB2. It would run for about a day and then crash. Not much good for a production web site, right?

    They tried various combinations, and finally ended up with an older RedHat, with an older version of Java. Write once, Run everywhere, failed.

  • Re:Java eh? (Score:3, Interesting)

    by angel'o'sphere (80593) on Wednesday April 14, 2004 @09:04AM (#8858871) Homepage Journal
    Well,

    Eclipse might be indistinguishable from a native Application. For me it is not. A SWT application has the typical SWT look just like a Swing application has the typical Swing look.

    I have my skins set to Win95 style(on windows), for me a Swing application looks very windowish ... there are differences, but the ordinary user won't notice it. Just as you claim not to notice the SWT differences to the native OS widgets.

    Regarding speed ... what good is an IDE where the GUI is some 1/1000 seconds faster than a compareable Swing GUI? I mean: a dialog or a menu pops up faster than I can notice under Swing, and SWT is just a glimps faster. But: Eclispe is an incredible slow IDE on big projects, build times, simple searches, refactorings, everything takes 10s of seconds up to minutes.

    I use in my own company CodeGuide from Omnicore.com ... that IDE is in real work 100 times faster than Eclipse ... and the fact that a menu is not up in 1/100 of a second but only in 1/50 of a second ... that I don't need. That the preference dialog looks more native in Eclipse than in CodeGuide ... I don't need either. Furthermore ... but that drives me away from your argument: the GUI of Eclispe is not that well designed, a lot of often needed functionality is difficult to access e.g.: right mouse -> search -> reference -> work space. And back to my previous note, that takes about 30 seconds on Eclispe while CodeGuide does it in 1 or 2.

    angel'o'sphere

If bankers can count, how come they have eight windows and only four tellers?

Working...