Owen wrote:arkain wrote:Owen wrote:The fact that video decoders and GPUs exist is testament to the failings of CPUs as computation devices, not to the advantage of a special purpose core in this regards.
2. Using dedicated hardware in conjunction with GP hardware allows for better use of the GP hardware...
But that dedicated hardware sits idle most of the time
That depends on the nature of the hardware involved doesn't it? Is it so bad that my sound card sits idle most of the time? What about my network card (actually, it doesn't. It's almost always in use.)? And I dare say that my graphics card is never sitting idle unless the display has gone to sleep or I've turned the machine off. (neither of these happen very often)
Owen wrote:arkain wrote:3. The use of co-processors in general increases the flexibility of what can be done...
No it doesn't: You would have more flexibility if you applied the same resources to the CPU itself.
Incorrect both in theory and in practice. If this were the case, then you'd be hard pressed to explain why there is such a thing as DMA... even harder pressed to explain Bus Mastering. The simple fact is that while PIO can do these things just fine, it's far faster to off-load the work onto a dedicated co-processor and let the CPU spend its time on the more general task of running applications.
Owen wrote:arkain wrote:There are more points to be made, but they all point out an oversight in your argument. A GP CPU was never designed to be a solely computational device. That's why they're called "general purpose." ...
As a "computational device," all GP CPU's fail, but only because that wasn't the focus of their design.
What is a CPU? It is a device for processing data; quite simply: it is a computational device designed to do anything. If you need another piece of hardware to do what you want/need to... Then it is evidently true that the CPU is failing at being general purpose.
Again, incorrect. A CPU is a device for performing actions. It's entirely possible, although useless, to write a program that collects no data and produces no output. That data processing is a common part of what CPUs do is a testament to the fact that people do not like to use useless software.
All of the examples of co-processors that have been mentioned so far can be implemented in software (and at some point, probably has been). The simple fact is that if a dedicated piece of silicon smaller than the width of a fingernail can perform a reasonably often repeated task with sufficiently greater efficiency than an equivalent software encoding, people will make a specialized processor specifically for that function.
If you still want to offer that a co-processor doesn't increase the flexibility of what's possible, then do explain why 3D applications did not appear in abundance until the invention of the GPU. My answer is simply this: 3D applications did appear, but were limited due to the large amount of time required to perform the vector calculations needed to create a single rendering. It's not that the CPU failed to do the work, and thus failed to be general purpose. It's that moving the calculations to a co-processor that was dedicated to vector calculations and able to push the result to the screen on demand freed the CPU to manage the contents of the 3D image.
If this doesn't qualify as an increase in flexibility, I can offer you other examples, like the difference between repeatedly probing i/o ports to produce a series of square waves that approximate a given frequency (Apple ][ sound programming) vs a sound card. Co-processors increase flexibility by reducing the need to manage low-level, complicated details, freeing resources to do other things.