I mean, cmon, if you're going to rehash old ideas, at least do your work thoroughly. There was another comment that mentioned the theoretical peak bandwidth of the P4 being quite a bit larger. That's issue one. Issue 2 is: the guy didn't even bother trying to recode in SSE2. Writing in C++ and compiling with optimizations doesn't get you there. You can get something like 2.5x when doing a matrix multiply in SSE land (depending on the version of the hardware you're using).
Second, P4ee is irrelevant because he did his tests on a Wilamette!
Note, too, that his 1500x1500 matrix is way too large for the CPU cache, so the whole process is memory bound, which shows you nothing about the computational power of the CPU. The GPU is always going to have the memory traffic, but it has a higher speed memory interface to it's internal texture memory, which implies that the GPU wins if you're just doing memory reads (though this is somewhat of a questionable arguement because the GPU still has to contend with the AGP bus).
Next, the guy goes on to try to analyze the bottlenecks in GPU design when he apparently didn't even try to figure out why his own damn code ran so slow.
Very weak, I say.
GPUs are great and all, but they're not the be-all end-all of computation. You can do simple mathematical operations (as long as you don't care about high precision math), but you don't get things you need for crypto or video encoding, like bit operations and good branching (though they are moving toward better dynamic branching).
So yah, you can do math on a graphics card...whoopdie doo.
Good luck finding a company that will actually code for a GPU. Unless the instruction sets and CPU interfaces stabilize, nobody will want to code for it. Standardized platforms. There is code on Wintel platforms that was coded 8 years ago and still runs. Good luck finding that with a graphics app.
Slashdot Mirror
I mean, cmon, if you're going to rehash old ideas, at least do your work thoroughly. There was another comment that mentioned the theoretical peak bandwidth of the P4 being quite a bit larger. That's issue one. Issue 2 is: the guy didn't even bother trying to recode in SSE2. Writing in C++ and compiling with optimizations doesn't get you there. You can get something like 2.5x when doing a matrix multiply in SSE land (depending on the version of the hardware you're using). Second, P4ee is irrelevant because he did his tests on a Wilamette! Note, too, that his 1500x1500 matrix is way too large for the CPU cache, so the whole process is memory bound, which shows you nothing about the computational power of the CPU. The GPU is always going to have the memory traffic, but it has a higher speed memory interface to it's internal texture memory, which implies that the GPU wins if you're just doing memory reads (though this is somewhat of a questionable arguement because the GPU still has to contend with the AGP bus). Next, the guy goes on to try to analyze the bottlenecks in GPU design when he apparently didn't even try to figure out why his own damn code ran so slow. Very weak, I say. GPUs are great and all, but they're not the be-all end-all of computation. You can do simple mathematical operations (as long as you don't care about high precision math), but you don't get things you need for crypto or video encoding, like bit operations and good branching (though they are moving toward better dynamic branching). So yah, you can do math on a graphics card...whoopdie doo. Good luck finding a company that will actually code for a GPU. Unless the instruction sets and CPU interfaces stabilize, nobody will want to code for it. Standardized platforms. There is code on Wintel platforms that was coded 8 years ago and still runs. Good luck finding that with a graphics app.