Comment by fnid | Hacker News Reader

Comment by fnid | Hacker News Reader

Parent Full thread

It's endlessly hardwareable.

What I mean is, every algorithm or solution designed with software can always, by definition be implemented in hardware, bringing vast improvements in performance and scalability. This will always happen as long as hardware continues to get faster and there is no reason to believe that it won't continue to get faster exponentially for the foreseeable future. Quantum computing, 3D processors, light based data storage, carbon nanotubes, dna circuits...

Soon, we will have Databases and Web Servers implemented in hardware... When graphics was the rage, Intel put MMX in the CPU. Now we have two CPUs in the CPU, or four. We put SSL in hardware to speed that up. We can and do put it all in hardware eventually.

There are already lots of instant hardware solutions you can burn with EEPROM, PLAs, and the like. I don't see any reason Intel or AMD won't let consumers upload programs to burn right into the silicon. It'll be like embroidering polo shirts.

Hardware tends toward being general-purpose over time. It only makes sense to do dedicated hardware for things that aren't feasible to do using general-purpose silicon at the time (notable exceptions are for simpler things like ethernet controller chips, although if a general-purpose CPU is cheap enough to replace the chip, maybe that will change). As you pointed out, hardware speeds do get exponentially faster over time, which makes it less desirable to go to the effort of designing purpose-specific hardware.

The problem with current FPGA and CPLD solutions where you would be able to upload your own algorithms is that currently they operate much more slowly than mask manufactured ASICs. Not to say that couldn't change at some point, but even then the line between software and hardware is pretty blurry. Tools for designing correct implementations of an algorithm in hardware that take full advantage of being in hardware (very fine-grained concurrency, etc) are difficult to master.

Sorry, it is hard to hit these points in depth in a short post, but hardware has a set of concerns that are separate from software, and treating them as exactly equivalent is not really accurate, even if functionally and algorithmically they are the same.

You are right about the tools being difficult to master. I've been doing some work with FPGAs lately, and I see one big problem. The hardware is really cool. But the software is horrible.

I'm working with Altera tools. To do any work, I need to download about 5Gb of stuff. The IDE is painfully slow, badly designed, and crashes about once every hour. Everything is closed-source. Basically, the development process is at least a decade behind that for software work.

Xilinx tools are also closed (don't know if they are as unusable though). I think that if one of the FPGA companies opened up their toolkit, they could win big. But they are too worried about their proprietary routing algorithms to do that.

don't know if they are as unusable though

Pretty much.

Of course, that's a given. This whole business with Ln caches and cache-line misses is a sort of déjà vu in scale (and now people are talking about MVCC and transactions at the memory level ;)

So yes, any software system can be embodied in hardware, but when a problem is so fiendishly difficult and optimal solutions require (sophisticated) algorithms matched to hardware specifics, then the cost equation tips heavily in favor of hardware embodiment. A significant barrier to the n-core future is pedagogical and I'm guessing that will further tip the balance towards a systemic solution embodied in hardware to hide the concurrency issues.

Well, that will be okay. Do you want to spend your time building the game or writing ray tracing algorithms? You want to call Array.sort(), not write a sort. It just takes up time.

It's interesting that CISC won out over RISC considering the conversation we are having. It's simpler for the builder. You can repeat yourself less. Imagine doing a quicksort in assembly. No way, right? Not today. Why?

CISC won over RISC? I think you meant that in reverse :)

Just look at the i86/x64 instruction sets + extensions. It's rather large.

x86 is king. a terrible, ugly and far past its prime king, but king none-the-less.

Edit: The replies below are insightful, I should not have been so reductionist.

And beneath that CISC instruction set is a RISC core and a translation layer. The fact that the instruction set is CISC has more to do with backwards compatibility (hello, Windows) than an actual advantage of CISC.

It also has to do with CISC code being more compact. With memory getting slower and slower relative to the CPU, this is increasingly an (overlooked) advantage. Maybe at some point CPUs will do automatic code decompression in hardware.

Until you look at anything other than PCs. I'm reasonably sure there are more ARM chips in operation than x86, and ARM is (if I recollect correctly) a RISC processor.

Reply on news.ycombinator.com