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

  • by LarsWestergren (9033) on Tuesday April 13, 2004 @04:22AM (#8845624) Homepage Journal
    He sounds like a clever guy, but "pure Java" for number crunching!?! With "pure C", it'd take half the time with half the number of computers.

    ...but he would have to spend a lot more time porting it between different architectures and OSes. God, how many times do you have to explain this to people? These days, processing cycles cheap, programmer time expensive.


    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??
  • by Anonymous Coward on Tuesday April 13, 2004 @04:22AM (#8845627)
    Thanks for the mirror -- the site is down. I have to admit, the image is not what I'd expected.

    The story submitter talked about simulating a number of photons, which made me assume this was a simulation of quantum mechanics or perhaps of quantum fields.

    But the image looks like it is somebody's ray tracing project. This is geometrical optics, and not quantum mechanics. The term "photon" should not be used in this context, as it is misleading.

    Ray tracing is a discretization strategy used to approximate a (usually continuous) distribution. In this case a Monte Carlo approach would evidently be used...

    Whereas the term 'photons' implies field quantization. This is a much more complicated situation than the rays used in geometrical optics.
  • 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?
  • 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.
  • by blinkie (27148) on Tuesday April 13, 2004 @04:30AM (#8845666) Homepage
    Erm, that article is more than SIX years old, and one of the guys that wrote it now works for Sun. Apparently FUD is not something Microsoft has monopolized yet..
  • power consumption (Score:5, Insightful)

    by lightray (215185) <tobin@splorg.org> on Tuesday April 13, 2004 @04:32AM (#8845676) Homepage
    The fact of the matter is that a machine with 100% CPU utilization uses a lot more electricity than one with low utilization. The extra cycles aren't free.

    I measured this in 1997 on some kind of AMD K6 machine. IIRC, running dnetc doubled the power consumption of the machine.
  • 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 mec (14700) <mec@shout.net> on Tuesday April 13, 2004 @04:36AM (#8845693) Journal
    First there are resource allocation problems. The OS has to provide a sandbox with strict limits on all resources: memory, filesystem, and networking, as well as CPU time. It's fine with me if the "background compute demon" takes 25% of my processor but I don't want to take more than 10% of my memory.

    Then there's the security issue.

    But I see another problem which is even harder to solve: the tragedy of the commons. Consider a university campus, and suppose that anyone on campus can submit jobs to the Campus Grid. You come in the next morning and see that there are 10000 jobs in your grid queue, and 9800 of them are encoding random people's MP3's.

    The problem is that if you give free resources to a large anonymous community, it takes only a few of those people to suck up all the resources. So you need some way of identifying everyone who submits a job, and some way of charging for the jobs.
  • by Exiler (589908) on Tuesday April 13, 2004 @04:41AM (#8845722)
    Good thing the other half of the world is in winter then, isn't it?
  • by Anonymous Coward on Tuesday April 13, 2004 @04:49AM (#8845754)
    FP ops in Java are incredibly slow and broken.

    Originally presented 1 March 1998

    and ONLY 6 years have passed... no way they could have fixed any of those FP ops that were broken.
  • by Anonymous Coward on Tuesday April 13, 2004 @04:49AM (#8845757)
    These days, processing cycles cheap, programmer time expensive.

    Are you a project manager or something? He's asking for a 'zillion' machines to run it on, so processing cycles are not quite that cheap it seems.
  • by leereyno (32197) on Tuesday April 13, 2004 @04:59AM (#8845811) Homepage Journal
    Why would anyone want to use Java for something like this? That's like buying a Ferarri and trying to race it after disconnecting half the spark plugs.

    I am not a fan of Java. I don't have any problems with the language itself. What I have a problem with is the fact that it is crippled by the lack of native compilers. And by that I mean comprehensive compilers that work. Something like gcj that won't compile everything that Sun's "compilers" will just doesn't count.

    Interpreting bytecode for the purpose of cross platform capability is all fine and good. There are times when this is very beneficial. But not having the ability to target your programs for a particular platform is insane because it kills any chance at implementing an efficient solution for anything. It is the primary reason why I don't use Java for anything. I'm not going to use a language depends upon a virtual machine that eats 20+ megs of ram just to run hello world...slowly. And that is PER INSTANCE mind you. Shared libraries that eat up tons of ram are one thing, but having multiple programs whose memory footprint is such that they might as well have been statically linked is quite another.

    Then of course there is the speed issue. The lack of native compilers is what doomed IBM and Corel's attempts to create Java-base office suites. They could write the code, but running it was another matter altogether. I suspect that the projects at both companies were thought up by suits who bought into Sun's marketing. No one but a suit would believe that you could create something as complex and resource hungry as an office suite using an interpreted language.

    Java and especially .NET, are examples of what I call Gate's law. Gate's law is the counterpoint to Moore's law. Moore's law states that speed of new computer hardware at a given price point will double every 16 to 24 months. Gate's law states that the efficiency of new computer software will be cut in half every 16 to 24 months. This is why we have to have desktop systems with enough raw power to simulate nuclear explosions just to run Word and Excel at a decent clip. To be sure there is going to be some loss of efficiency due to newer programming strategies that attempt to maximize code maintainability and speed of development, but I seriously doubt that these factors alone are enough to account for the way that most current software packages waste system resources. The only sort of software that still operates at a respectable level of efficiency is computer games. The fact that games are the most perfect example of Gates' law in action would be ironic if it were not for the quantum leaps that have been made in game design over the past quarter century. We've gone from PC-Man to the Lawnmower Man in just under 25 years. Packages like Word should not rightfully require computers with VR-capable speed and memory just to run. Unfortunately they do.

    I'm sure I'm going to get flamed for this post, but then if I cared whether people bitched at me I'd just keep my mouth shut wouldn't I?

    Java advocates are perfect examples of the old adage that if the only tool you have is a hammer then every problem looks like a nail. Java has its uses and its place. The problem is that far too many people want to use it for things that it is not well-suited for. If we can get good optimizing native compilers for the language then most of the problems with Java will disappear and I'll have nothing but good things to say about it. Till then I'll stick to C and C++ thank you very much.

    Lee
  • by Anonymous Coward on Tuesday April 13, 2004 @05:03AM (#8845822)
    Am I the only one to see that the Emporer is wearing no clothes? That's a whole lot of CPU power being used. For what? I pretty simple looking ugly raytraced picture. Aren't there more worthy causes out there to donate our CPU cycles to?
  • Re:Java? (Score:4, Insightful)

    by eric76 (679787) on Tuesday April 13, 2004 @05:04AM (#8845827)

    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.

  • 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:Java eh? (Score:2, Insightful)

    by marcovje (205102) on Tuesday April 13, 2004 @05:20AM (#8845876)
    Wonder why this got modded up Funny.

    It is simply true, and so obvious it struck me immediately too.

    Java for intense computation? Months? Go away :-)

    Nothing against Java, but it isn't suitable for this.
  • by kirinyaga (652081) on Tuesday April 13, 2004 @05:25AM (#8845889) Homepage
    Not really. There is an overhead in java, indeed, but it's caused mainly by objects management. To perform pure calculation, about any language will perform the same. The limit here is the CPU.
    Try to factor a big number in C, C++, java or fortran, it will take exactly the same time. The few seconds difference you'll get after a day of calculation are the language overhead that occurs between calculation loops, totally irrelevant when what you do is _only_ those calculation loops (a situation that occurs rarely in traditional development, granted).
    Of course, the guy wants his program to run on several kinds of platform but probably cannot afford to develop and test on a lot of OS & machines, so Java seems to be the proper solution.
  • by jabbadabbadoo (599681) on Tuesday April 13, 2004 @05:42AM (#8845945)
    "...things can actually roll on faster than c"

    And pigs _can_ fly.

    Here's the deal: when you perform fp ops in Java, operands go where? The _Java_ stack which actually resides on the heap. In C? Usually registers. The JIT register allocation algorithm cannot possibly optimize like a good C compiler can because of the purely stack-based architecture. What's worse - after each fp op, the CPU must fetch byte codes from the class pool which also resides on the heap. So farewell L1 cache line optimization (and sometimes L2 caching)

    Note that most benchmarks are too limited, the Lx cache line problems appear in non-trivial applications with a bit more more than a loop doing fp addition.

  • by jridley (9305) on Tuesday April 13, 2004 @05:56AM (#8845976)
    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
  • by Stween (322349) on Tuesday April 13, 2004 @06:07AM (#8846010)
    It's voluntary.

    If you don't want to pay however much extra it might be, you don't have to participate; nobody's forcing you.
  • by orthogonal (588627) on Tuesday April 13, 2004 @06:09AM (#8846015) Journal
    Either I'm suffering deja vu, or this has been posted nearly verbatim before in a previous discussion of Java vs. C.

    Not only that, Face the Facts (770331) [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 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.
  • 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?
  • Re:Java eh? (Score:3, Insightful)

    by tap (18562) on Tuesday April 13, 2004 @07:19AM (#8846220) Homepage
    It seems like your trying to say that the C compiler must produce 16 bit code for a 386, but the java JIT compiler will produce 32 bit code.

    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 lowest common denominator. When I compile scientific programs at work, I sure as hell don't compile for a 286. I don't even have a compiler than can produce 16 bit code! I always tune the compile for the specific CPUs.
  • Re:Oh boy... (Score:3, Insightful)

    by Tet (2721) * <slashdot@astraEI ... minus physicist> on Tuesday April 13, 2004 @07:21AM (#8846224) Homepage Journal
    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.

  • by ajs (35943) <ajs@@@ajs...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.
  • Re:Java eh? (Score:3, Insightful)

    by markbthomas (123470) on Tuesday April 13, 2004 @08:12AM (#8846478)
    Of course SWT is faster than Swing. SWT interfaces to the native toolkit, which is, of course written in C or C++. In Java, the only fast method is a native method.

    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 course, which is closer in actual behaviour to JustTooLate) will in most cases outweigh what tiny improvements you can get in the part of the program that matters for performance. Remember that 90% of CPU time is spent in 10% of the code.
  • Re:Java eh? (Score:2, Insightful)

    by essreenim (647659) on Tuesday April 13, 2004 @08:45AM (#8846706)
    Dammit this is infuriating!
    Stop comparing java to c, it s so.. last decade!
    Sun have excellent c compilers. Thats really all Java is these days. Its a load of stack instructions that are completely platform neutral.
    that are optimized according to the particualar target platform and translated into c binary.

    This translation is often worth the cost because of the optimizations gained.

    If you cannot understand this, then you will not grasp why J2ME CDC/CLDC is generally the preferred solution for mobile communication and embedded software....
  • Re:Java eh? (Score:5, Insightful)

    by BlackHawk-666 (560896) <ivan.hawkes@gmail.com> on Tuesday April 13, 2004 @09:10AM (#8846916) Homepage
    If this is true then why is Java so goddammed slow still? Why is it every medium sized or above Java app I've used performs like crap compared to a similar one compiled in C++ or simlilar languages? It just seems to me there is a major disconnect between what the Java adherants are claiming and the reality I am faced with every time I use a Java app.
  • Re:Java eh? (Score:3, Insightful)

    by 42forty-two42 (532340) <{moc.liamg} {ta} {nalnodb}> on Tuesday April 13, 2004 @09:26AM (#8847069) Homepage Journal
    the C code will be forced to generate non-SSE instructions to support the old Pentium Is out there.

    gcc -msse -msse2 -mfpmath=sse -march=pentium4 -O3
  • by aksansai (56788) <aksansai@gm a i l . c om> 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.
  • 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.

  • by donscarletti (569232) on Tuesday April 13, 2004 @10:36AM (#8847837)
    Funny, I allways thought that the 80386 was a 32 bit machine, I thought it was actually the first *86 to have has the EAX register and the STOSD instruction (but strangely not the STOD instruction)
  • Re:Java eh? (Score:3, Insightful)

    by stephenisu (580105) on Tuesday April 13, 2004 @11:35AM (#8848629)
    and what if the user can't compile for some reason?

    Yes we know it CAN be done, but what is the PRACTICAL solution?
  • by Anonymous Coward on Tuesday April 13, 2004 @12:56PM (#8849720)
    It would be great if everyone on the net would allow their machines to be used to do important things, such as curing cancer. However, the average person who writes such code is also the same person who wouldn't let you touch their keyboard yet alone play on their machine. Then that same type of person wants everyone else to run code (compiled code at that) on their home machines. I'd do it if I were allowed to get the source, then compile myself. Otherwise, I could write code to do something important, release it asking everyone to run it in the background. I could then be the most distributed spammer on the face of the earth (Muhaha Muhaha).
  • Yeah, sure... (Score:3, Insightful)

    by Gruneun (261463) on Tuesday April 13, 2004 @09:43PM (#8855908)
    I'd do it if I were allowed to get the source, then compile myself.

    I love this argument. I hear it from more than a couple people who "want to know exactly what that programmer is up to" before they run it on their own machine. None of them actually read the code. In reality, they want people to think that they can comprehend someone else's code, while truly only proving that they can run a makefile.

    I write clear, organized code and I place clear, concise comments where needed. I work with some intelligent, organized people who do the same. The reality is that, even being fully comfortable with their coding styles, I find it very tedious to read their code... even when I know exactly what they're attempting to do. Somehow, I doubt that most people, even programmers, could comprehend the math that goes into the typical raytracing program, let alone one developed by a complete stranger.
  • Re:Java eh? (Score:3, Insightful)

    by markbthomas (123470) on Wednesday April 14, 2004 @10:49AM (#8859695)
    I don't buy the idea of having to take a significant performance hit now and for the forseeable future for the sake of hypothetically being able to run my program faster in 15 years time on a hypothetical machine that doesn't exist yet.

    Besides, I have the source to my program; I can recompile it for the new architecture in 15 years' time.
  • Re:Java eh? (Score:1, Insightful)

    by Anonymous Coward on Wednesday April 14, 2004 @12:00PM (#8860528)
    there are lots of Java programs doing something which a simnilar C program does, but the Java program is faster. Example: Apache Tomcat versus "Apache, the Web Server". The Java Tomcat is faster under load, it serves more pages.

    Only for workloads that are specifically chosen to play to Tomcat's strengths. Anyone can cook a benchmark, but it takes a real designer to design a webserver that's really faster for real-life workloads. You'll never be a real designer, from what I've seen.

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

    by gtrubetskoy (734033) * on Wednesday April 14, 2004 @03:46PM (#8863130)
    Apache Tomcat versus "Apache, the Web Server". The Java Tomcat is faster under load, it serves more pages.

    This has got to be an urban legend of some sort. I cannot see how Tomcat would ever be faster than Apache. If what you say were the case, why would people go through all the trouble of putting Tomcat behind Apache with mod_jk, etc to seprate static content serving from dynamic requests?

    I can also say that my unscientific tests of Tomcat vs Python running under mod_python showed no clear winner. The point is that Python does not proclaim to be ultra-fast, while Java does.

Debug is human, de-fix divine.

Working...