Software vs Hardware
|
Prev: First Next-Gen CELL Processor: 2 PPEs - 32 SPEs - at least 1 Teraflop
Next: old microcode listings
From: rohit.nadig@gmail.com on 11 Dec 2006 17:27 Hello Comrades, I propose the following Premise: It seems to me that much of the features that would benefit the average user of a computer could be better implemented in hardware than in software. Currently most of these features (multimedia, networking/communication) are implemented as software applications. Corollary: Consequently, many features that are implemented in today's mainstream microprocessors DONT benefit the average user. Take for example the experience of watching videos on my computer. Lets just say that network latency coupled with a bulky protocol stack coded in software makes the experience mediocre. A microprocessor that implements a networking stack, graphics subsystem and general purpose integer and FP units would be MORE useful to the average user, than a microprocessor that allocates a large chunk of its die to make every Integer instruction run fast. Intel's latest core 2 duo CPU has 2M of cache memory. Why does an average user need such a high end Integer unit? I am assuming the bigger cache improves the integer performance of the microprocessor by reducing the impact of branch misprediction on the integer pipeline. In the ideal world, the communication stack would be handled by hardware that is tightly coupled to the media engine. The software could do the HTML rendering the higher level intelligent stuff like showing me a list of "other" videos that might be interesting based on my viewing history. The complexity would be in changing the hardware implemented networking stack. A microcode patch could probably do the trick, and IMHO is a good area of research. I'd love to hear from you, Rohit
From: Andrew Reilly on 11 Dec 2006 21:28 On Mon, 11 Dec 2006 14:27:21 -0800, rohit.nadig(a)gmail.com wrote: > It seems to me that much of the features that would benefit the average > user of a computer could be better implemented in hardware than in > software. Currently most of these features (multimedia, > networking/communication) are implemented as software applications. You will probably find that without too many exceptions, the features that you care about will be implemented in software (over appropriate hardware) even on devices that you regard as "hardware", and which currently give you a good or adequate experience. > Corollary: > Consequently, many features that are implemented in today's mainstream > microprocessors DONT benefit the average user. While there may well be some features in that category, (a) I doubt that they're the ones that you are thinking about, and (b) the marginal cost of providing them alongside the "good bits" may be close to zero. Regarding your network viewing experience: you probably have a legitimate quality-of-implementation complaint, but I suspect that it is probably much more influenced by the network delivery mechanism than any hardware/software tradeoffs in the terminal unit [although there are certainly quality-of-implementation issues in many popular software systems, too.] Cheers, -- Andrew
From: Del Cecchi on 11 Dec 2006 22:10 "Andrew Reilly" <andrew-newspost(a)areilly.bpc-users.org> wrote in message news:4u6ievF16lqnlU1(a)mid.individual.net... > On Mon, 11 Dec 2006 14:27:21 -0800, rohit.nadig(a)gmail.com wrote: > >> It seems to me that much of the features that would benefit the >> average >> user of a computer could be better implemented in hardware than in >> software. Currently most of these features (multimedia, >> networking/communication) are implemented as software applications. > > You will probably find that without too many exceptions, the features > that > you care about will be implemented in software (over appropriate > hardware) > even on devices that you regard as "hardware", and which currently give > you a good or adequate experience. > >> Corollary: >> Consequently, many features that are implemented in today's mainstream >> microprocessors DONT benefit the average user. > > While there may well be some features in that category, (a) I doubt > that > they're the ones that you are thinking about, and (b) the marginal cost > of > providing them alongside the "good bits" may be close to zero. > > Regarding your network viewing experience: you probably have a > legitimate > quality-of-implementation complaint, but I suspect that it is probably > much more influenced by the network delivery mechanism than any > hardware/software tradeoffs in the terminal unit [although there are > certainly quality-of-implementation issues in many popular software > systems, too.] > > Cheers, > > -- > Andrew Believe me I am a big fan of hardware. It feeds the family. But the original post strikes me as some sort of troll. Pretty surprising for comp.arch to be trolled. Multimedia in hardware? TCP/IP in hardware? far out man.
From: Andrew Reilly on 11 Dec 2006 23:55 On Mon, 11 Dec 2006 21:10:00 -0600, Del Cecchi wrote: > Multimedia in hardware? TCP/IP in hardware? Well there are "MPEG decode" accelerators in some PC graphics cards, and there are MPEG audio and Atrac (at least) decoders in ASICs for very low-function portable players[1], and there are "TCP offload engines" that nominally do a bunch of TCP functionality in "hardware"[2], so perhaps the OP wasn't totally off the beam, but even if you built a PC with all of those pieces in it, your viewing experience would still be predominantly affected by (1) conditions on the network pipe to the server, (2) quality of real-time response of the PC OS and (3) quality of PC playback application. Only the latter two are things that much can be done about at the end-user premises, and neither of those are much the domain of computer architects. So I think that you're right that the OP has mis-fired, at least :-) [1] The audio decode functionality is dwarfed by the processor requirements for other things like GUIs, games and cell-phones in high-function portable devices, so you might as well just let some spare CPU do it. Besides, the ASIC approach is only efficient if you only have one codec standard to support. [2] I expect that these are just more processors, though? Much like RAID controllers and other off-load peripheral controllers. Cheers, -- Andrew
From: Nick Maclaren on 12 Dec 2006 04:15
In article <4u6krtF16v85tU1(a)mid.individual.net>, "Del Cecchi" <delcecchiofthenorth(a)gmail.com> writes: |> |> Believe me I am a big fan of hardware. It feeds the family. But the |> original post strikes me as some sort of troll. Pretty surprising for |> comp.arch to be trolled. Multimedia in hardware? TCP/IP in hardware? |> far out man. God help us all, not far enough :-( The lower levels of the TCP/IP stack are being implemented in hardware as we speak. Those of us who know enough to know that almost all (probably all) TCP/IP software implementations are buggy and unreliable - I know of at least one serious generic bug - and that there are at most half a dozen people in the world who understand the TCP/IP stack (with perhaps none still working), don't like the idea of this ancient and arcane structure being enshrined in silicon. But the marketing executives do, so who are we peasants to complain? Regards, Nick Maclaren. |