It just doesn't work that way. GPU's get their advantage because they are highly parallel and heavily pipelined. This makes it easier and cheaper to add more computational power to the card. The problem is that there are a lot of things you just can't do efficiently. The time it takes for one piece of data to get through the pipeline prohibits many general purpose operations. The big advantage for a lot of applications is that it takes just about the same amount of time for thousdands to millions of pieces of data to get through the pipeline, they just can't depend on each other.
Go read a tutorial on CPU architecture and where it talks about pipelining replace the pipeline that takes 5 cycles end to end with one that takes thousands of cycles and imagine how you could write basic algorithms. Worse yet, imagine how you would handle IO or interrupts.
Actually, transfer time is usually somewhat insignificant. I worked on a GPU-based SVD algorithm in a class taught by a Gamma member at UNC, and transfer between the GPU and CPU took less than 1% of the running time of my algorithm, even on AGP.
In addition, who said that we necessarily need the results on the CPU? If we really just want to compute the FFT and then check a couple of things or perform more computation with it, it may be more efficient to leave the data on the GPU and run it through another GPU program. In that case, it is unfair to include transfer time in the computation time of the FFT, because we don't need to transfer it.
Generally you will only notice a difference if you are running another GPU intensive program at the same time. Most GPGPU programs (including ones made by Gamma) use extensions such as the frame buffer object so that you don't need to see the mathematical garbage in a graphical sense. Thus the only side effect is that it needs a significant amount of video memory and GPU processing time, both of which will be shared with other programs trying to use them. So if you try to compute the FFT of something that barely fits in video memory while playing UT 2004 at 1600x1200 resolution, you might have a problem. Otherwise, you probably won't notice.
Do they console you for the money they charge to restore your data too?
I have a friend whose hard drive just went crazy on him. Dell gave him a replacement drive, but doesn't offer to get the data off the old one. So we've been looking for a good program to try to recover the data from two (apparently slightly corrupt) NTFS partitions. We found a variety of programs, but the best deal we could find was one that would let you recover 1 MB for free and you have to pay for the rest. It seemed to recover the data fine, but it wants him to pay over $100 to get the data back. So maybe they should console users on the cost of recovering data if they can get the data back...
By the way, if you know of any free (or cheap) way to recover the data off of slightly corrupt NTFS partitions on an IDE drive, please let me know.
Slashdot Mirror
It just doesn't work that way. GPU's get their advantage because they are highly parallel and heavily pipelined. This makes it easier and cheaper to add more computational power to the card. The problem is that there are a lot of things you just can't do efficiently. The time it takes for one piece of data to get through the pipeline prohibits many general purpose operations. The big advantage for a lot of applications is that it takes just about the same amount of time for thousdands to millions of pieces of data to get through the pipeline, they just can't depend on each other.
Go read a tutorial on CPU architecture and where it talks about pipelining replace the pipeline that takes 5 cycles end to end with one that takes thousands of cycles and imagine how you could write basic algorithms. Worse yet, imagine how you would handle IO or interrupts.
Actually, transfer time is usually somewhat insignificant. I worked on a GPU-based SVD algorithm in a class taught by a Gamma member at UNC, and transfer between the GPU and CPU took less than 1% of the running time of my algorithm, even on AGP.
In addition, who said that we necessarily need the results on the CPU? If we really just want to compute the FFT and then check a couple of things or perform more computation with it, it may be more efficient to leave the data on the GPU and run it through another GPU program. In that case, it is unfair to include transfer time in the computation time of the FFT, because we don't need to transfer it.
Generally you will only notice a difference if you are running another GPU intensive program at the same time. Most GPGPU programs (including ones made by Gamma) use extensions such as the frame buffer object so that you don't need to see the mathematical garbage in a graphical sense. Thus the only side effect is that it needs a significant amount of video memory and GPU processing time, both of which will be shared with other programs trying to use them. So if you try to compute the FFT of something that barely fits in video memory while playing UT 2004 at 1600x1200 resolution, you might have a problem. Otherwise, you probably won't notice.
Do they console you for the money they charge to restore your data too?
I have a friend whose hard drive just went crazy on him. Dell gave him a replacement drive, but doesn't offer to get the data off the old one. So we've been looking for a good program to try to recover the data from two (apparently slightly corrupt) NTFS partitions. We found a variety of programs, but the best deal we could find was one that would let you recover 1 MB for free and you have to pay for the rest. It seemed to recover the data fine, but it wants him to pay over $100 to get the data back. So maybe they should console users on the cost of recovering data if they can get the data back...
By the way, if you know of any free (or cheap) way to recover the data off of slightly corrupt NTFS partitions on an IDE drive, please let me know.