First of all, the C++ was crappy as many people pointed out.
Second of all, I'm sure that loading the C++ program takes some time more than just loading the byte codes (though that's probably mitigated somewhat by the byte code translation).
Third, the optimization options he used for gcc are a joke. -march=i686 is not even relevant to much larger platforms that can benefit from other optimizations.
And, 4th, and this is the big one, this guy does not know how to benchmark. Anyone who has actually benchmarked their own application knows that if you want to figure out how fast something is, you have to time it IN THE PROGRAM!!!! This would avoid allocation/cout/unnecessary function overhead, when all you're trying to test is a specific operation. I BET (and at some point I will test this) that if you used timing mechanisms INSIDE the programs, that C++ would come out much faster, with the exception of object management and memory stuff (excepting garbage collecting...). Even then, much of that stuff can be overcome by memory pooling, which a surprising number of people ignore.
Until someone does something like all these language comparisons are totally pointless because you are NOT ACTUALLY BENCHMARKING the topic you are looking at. Please lets have someone be intelligent about this for once....
Yeah, there are plenty of things that are nice about dev. in linux. However, two things still bug me about linux (admittedly I am somewhat new). I have yet to get a debugging environment running without problems (soooo many issues...). And, there are definitely issues getting updated graphics drivers (not linux's fault...). I could also complain about build systems, but I haven't really experimented enough to claim anything but that I think autoconf/automake is a huge mess (at least the way we're using it):).
It's kind of rough, there are many really nice things. I wish windows would stop sucking in all the little ways, or linux would pull itself together and become super popular so all companies would support it (here's to hoping...).
I'm not sure why no one has mentioned gpgpu.com (been posted on slashdot before). They have real time ray tracers based on GPU processing.
I'm pretty sure that most people doing generic stream processing on a GPU have done so without the behest of nvidia. The only thing they've said is that their chip is a super scalar design, which is true. If you want to see real uses of crazy graphics take a look at the million particle demo (gdc 2004 paper I think), and see if you can implement that in real time on a CPU just as fast.
For Ray tracing, I don't think GPUs will really out pace CPUs. However there are plenty of other uses for a semi-specialized highly parallel chip besides raytracing.
Slashdot Mirror
First of all, the C++ was crappy as many people pointed out.
Second of all, I'm sure that loading the C++ program takes some time more than just loading the byte codes (though that's probably mitigated somewhat by the byte code translation).
Third, the optimization options he used for gcc are a joke. -march=i686 is not even relevant to much larger platforms that can benefit from other optimizations.
And, 4th, and this is the big one, this guy does not know how to benchmark. Anyone who has actually benchmarked their own application knows that if you want to figure out how fast something is, you have to time it IN THE PROGRAM!!!! This would avoid allocation/cout/unnecessary function overhead, when all you're trying to test is a specific operation. I BET (and at some point I will test this) that if you used timing mechanisms INSIDE the programs, that C++ would come out much faster, with the exception of object management and memory stuff (excepting garbage collecting...). Even then, much of that stuff can be overcome by memory pooling, which a surprising number of people ignore.
Until someone does something like all these language comparisons are totally pointless because you are NOT ACTUALLY BENCHMARKING the topic you are looking at. Please lets have someone be intelligent about this for once....
Yeah, there are plenty of things that are nice about dev. in linux. However, two things still bug me about linux (admittedly I am somewhat new). I have yet to get a debugging environment running without problems (soooo many issues...). And, there are definitely issues getting updated graphics drivers (not linux's fault...). I could also complain about build systems, but I haven't really experimented enough to claim anything but that I think autoconf/automake is a huge mess (at least the way we're using it) :).
It's kind of rough, there are many really nice things. I wish windows would stop sucking in all the little ways, or linux would pull itself together and become super popular so all companies would support it (here's to hoping...).
Heh, my bad it's www.gpgpu.org.
I'm not sure why no one has mentioned gpgpu.com (been posted on slashdot before). They have real time ray tracers based on GPU processing. I'm pretty sure that most people doing generic stream processing on a GPU have done so without the behest of nvidia. The only thing they've said is that their chip is a super scalar design, which is true. If you want to see real uses of crazy graphics take a look at the million particle demo (gdc 2004 paper I think), and see if you can implement that in real time on a CPU just as fast. For Ray tracing, I don't think GPUs will really out pace CPUs. However there are plenty of other uses for a semi-specialized highly parallel chip besides raytracing.