Software vs Hardware
|
Prev: First Next-Gen CELL Processor: 2 PPEs - 32 SPEs - at least 1 Teraflop
Next: old microcode listings
From: JJ on 12 Dec 2006 13:47 Del Cecchi wrote: > "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. I don't think he is trolling, just showing a lack of experience, maybe just starting out in hardware design, seen some HDL coding, confusing that with software design. Lots of HDL starting examples are also familiar algorithms to CS101. The question is legitimate, any seasoned engineer esp one that does hardware & software usually knows the right way of doing things and partitioning between the two. For the OP, many algorithms can be built as hardware or software, the choice is usually obvious but not always. It is work thinking in terms of algorithms in a neutral way so that they can be implemented both ways, one has to consider how many multiplies or divides, adds, shifts, ram accesses, locality of reference and a myriad of other factors and the cost of each operator. PCs are good at FP, and perfoming 'normal' math on data sets with high locality esp if cache friendly. Hardware is far better at bit twiddly operations, ie roll your own custom math or when connected to peripheral interfaces or accessing memory with poor locality. Hardware (FPGAs esp) generally run much slower than PCs at clock rates about 10x less, but in return a great deal of parallelism is possible. While a PC may be able to twiddle through L1 cache at near 1ns rates, it can only do so on one path and requires a few instruction codes and cycles to do something interesting. A high end FPGA or ASIC can twiddle through many memories at 3ns rates or so, in some cases upto 500 ways with some Virtex parts. Consider most of the multimedia interfaces you mentioned, with PCs being mostly >90% idle it makes far more sense to emulate or implement those in software unless the burden should be so great as to cripple the PC. The first generation multimedia was done in hardware back in the 486 days, remember Ccube, but that multimedia hardware didn't do very much compared to todays gear. High end video work though can still warrant add in cards likely based on FPGAs and also likely firmware/bitware upgradeable. Consider the classic FFT, so many uses. Use it occasionally, so do it in software probably in FP. Put it in a radar signal processor, better do it in hardware almost certainly integer and some oddball word size. Now consider more esoteric uses such as crypto or mersenne primes factoring. It is more of a toss up, here a poor hardware design in FPGA comes out maybe just soso faster than the PC software version but costs proportionately more so no net gain. Do the hardware design right and take maximum advantage of how the FPGA or ASIC methodology works and the toss up can swing to hardware but design costs may go way up, faster hardware design takes far more resources. If you have volume or deep pockets maybe worth doing in hardware even to the max effort. One way to consider hardware v software is to look at algorithms as processes in the CSP, or occam sense which may contain an arbitrary mix of parallel & serial processes nested in some static pattern. Such descriptions can be executed as code on a suitable processor that has runtime support for occam (transputer etc) but can also be directly synthesized into hardware. occam might be called a poor man hardware description language as well as a poor mans software language but it is right in the middle, pity about the syntax. Also occam was commercialized into a HDL but then evolved right back into C (HandelC). Now today some folks try to use C based languages to do hardware design, SystemC and a bunch of others too, most based on C++ classes to add a concurrency model. You can use those to model systems that might later be built as hardware after further translation or synthesis or you might just run it as code since it is just C++ code. I'd still like to see a replacement for occam that borrows more from Verilog in the bit twiddly sense but retains a subset of C++ syntax, such a language can easily be synthesized to hardware if its in the RTL form but can also just run as efficient code if not in the RTL form. Using current HDLs to write software is even worse than using plain C to design hardware but that doesn't mean a common bridge language can't be built after occam. food for thought John Jakson transputer guy
From: paanwaala@gmail.com on 12 Dec 2006 14:03 > 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. Why would you say I was trolling? I spent 6 years in the Pentium-4 processor design team working on various aspects of Design Automation from 2000 to 2006. I am not offended at all, just terribly surprised. If you look at Windows Vista, the OS expects fairly high end graphics and networking hardware. They mandate that some of these expensive operations be taken over by the hardware layer. DirectX is a classic example. Look at Video interviews of architects from Microsoft who will http://channel9.msdn.com
From: Del Cecchi on 12 Dec 2006 14:37 paanwaala(a)gmail.com wrote: >>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. > > > Why would you say I was trolling? I spent 6 years in the Pentium-4 > processor design team working on various aspects of Design Automation > from 2000 to 2006. I am not offended at all, just terribly surprised. > > If you look at Windows Vista, the OS expects fairly high end graphics > and networking hardware. They mandate that some of these expensive > operations be taken over by the hardware layer. > > DirectX is a classic example. > > Look at Video interviews of architects from Microsoft who will > http://channel9.msdn.com > Apologies for misconstruing your post. -- Del Cecchi "This post is my own and doesn�t necessarily represent IBM�s positions, strategies or opinions.�
From: Robert Myers on 12 Dec 2006 22:42 paanwaala(a)gmail.com wrote: > > Why would you say I was trolling? I spent 6 years in the Pentium-4 > processor design team working on various aspects of Design Automation > from 2000 to 2006. I am not offended at all, just terribly surprised. > > If you look at Windows Vista, the OS expects fairly high end graphics > and networking hardware. They mandate that some of these expensive > operations be taken over by the hardware layer. > This whole discussion is surprising. Implementations of the TCP/IP stack in hardware can be bought off the shelf. Every contributor to this thread must know that. There's a card out especially for gamers that implements a network stack. If there were any edge to anything else, somebody'd be doing it, if only for the gamers. If it isn't being done, it's because there's no advantage to it. Robert.
From: Nick Maclaren on 13 Dec 2006 05:21
In article <1165981337.336317.84290(a)80g2000cwy.googlegroups.com>, "Robert Myers" <rbmyersusa(a)gmail.com> writes: |> |> This whole discussion is surprising. Implementations of the TCP/IP |> stack in hardware can be bought off the shelf. Every contributor to |> this thread must know that. There's a card out especially for gamers |> that implements a network stack. The whole stack? I didn't know that. Do you have a reference? Regards, Nick Maclaren. |