Slashdot Mirror
End of The Von Neumann Computing Age?
olafo writes "Three recent Forbes articles:
Chipping Away, Flexible Flyers and Super-Cheap Supercomputers cite attractive alternatives to traditional Von Neumann computers and microprocessors. One even mentions we're approaching the end of the Von Neumann age and the beginning of a new Reconfigurable computing age. Are we ready?"
IANAReal Computer Scientist, but aren't all current microprocessors and computers Turing machines? Aren't Von Neumann machines self-replicating devices, which AFAIK we don't have?
...Well, that's what the article says. I guess they haven't heard about pipelining, multiple execution units, SIMD etc etc.
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
I've programmed on the old bit-sliced Connection Machines, which are vaguely similar. Two points to ponder:
...? Is there a bunch of DRAM somewhere or do you carve memory out of the (expensive) FPGA?
- it was a *tremendous* pain in the ass. This Star Bridge machine isnt a general-purpose solution, it's only for applications that can stand writing 100% custom software in a custom language.
- the data has to come from somewhere. So you can do 1G operations per second. What's the I/O like? Do they use a PC for a host or an SGI or
I think you're right - handling arbitrary control flow, branching and so forth is a complex part of modern compilers, and of modern CPU hardware - and it is only possible because the CPU hardware handles all of the crazy stuff like ordering instructions, managing register contents (especially with all the voodoo that goes on behind the scenes in a modern CPU) and so forth. If you tried to do all of that in the compiler (which is effectively what you are talking about here), the compiler seems like it would have to do a lot more work than standard compilers generating machine code.
The instruction set of a modern CPU serves as the API, the contract between software land and hardware land, and that is what allows the CPU designers to go behind the scenes and do all sorts of optimization, only incrementally versioning the instruction set for large changes (like SIMD). When you eliminate that contract with the generalized computing hardware, and basically are compiling down to arbitrary HDL and gate configurations, it seems like too many degrees of freedom to manage the complexity, without additional constraints (like only trying to solve matrix or other mathematical problems, like the interesting product you point out).
1. This article is worthwhile reading:
"The future of computing-new architectures and new technologies"
By Paul Warren (04-Dec-2002)
The worlds of biology and physics both provide massive parallelism that can be exploited to speed up lengthy computations-with profound consequences for both everyday computing and cryptography.
2. Yes, it's been apparent for the last few years that computing is entering a new phase with diversity of computing 'substrates' as one key theme. Ameoba, Java, .NET, CORBA and GRIDs also point to the other theme of distribution and transparency.
The implications are that you should be able to design software that chooses an appropriate substrate for the problem at hand, such as RNA based computing for graph minimisation problems. If you can't afford to have this kind of computing substrate locally, you should be able to pay for the services over the net to someone who offers the raw power - e.g. an IBM style raw computing data centre. This is where computing is a commodity product, and organisations will pay for the appropriate computing power where it demonstrates productivity enhancements (e.g. completing a complex CFD simulation in minutes rather than hours).
I'll tackle this answer, since I'm fairly qualified to answer. FPGA's very typically run at clock rates of 100 to 300 MHz. You might see 100 MHz rates done by beginners or sloppy ASIC coders, and 300 MHz by experienced designers who spend extra timing making sure there are enough pipeline registers. The *highest* speeds I've seen are around 650 MHz, and these only occur in extremely specialized circuits designed at a very low level by guys with Godlike powers of intuition and creativity (& patience!). Next year, you can multiply these figures by 30 or 40 percent. These speeds are far lower than your typical Athlon or Pentium, but with enough parallization and pipelining, you can actually far outperform them. But, as you've no doubt read, it's HARD. Tools are getting better, but it will be a while before you can get Borland tools for FPGA design.
The program counter stuff and instruction cycle is just an implimentation. It's not the important part.
I can only wonder what sort of favors Daniel Lyons is receiving from Star Bridge. The only news here is that Forbes is being so blatant about whoring themselves out as a PR machine for a troubled company. No wait, that's not news either.
Slashdot - News for Herds. Stuff that Splatters.
About three years ago, Forbes ran an article on 64 bit computing in which they claimed that a 64 bit computer could address 64! bytes of memory. That same article called Unix a programming language and had several other silly inaccuracies. Be wary, your PHB will soon be asking for a demo.
FreeSpeech.org
Another thing you didn't mention is that despite the cost tradeoff, FPGAs are MUCH slower than ASICs for the same logic. They do not run as fast (which you touch on in a subsequent reply) but they also cannot do even close to same amount of work at the same speed often due to wiring congestion/routing issues.
:) I consider C a convenient macro language for assembly. But we hardware guys are all about cycle per cycle efficiency and most CS guys are all about development time. It's a tradeoff.
You usually have to do more than a linear amount of pipelining, put it that way.
As far as aerospace applications, i doubt this very much. Being that they are a vast sea of SRAM, charged particles and radiation in outerspace would make the sram grids very unreliable. bits could be flipping right and left and totally changing the behavior of the underlying logic. you'd have to have massive error correction going on. heavy duty ECC that would make it not too practical.
as far as high level tools for hw, you hit it on the head there. hardware design needs to be done at the gate level with verilog. there is way too much optimization needed for timing and efficiency to depend on some BS java crap. java is stupid and inefficent for software and make me laugh when applied to hardware design. but i'm the kind of guy who still thinks assembly code is the way real men optimize
Hypercomputing. Gilson is a salesman. What I want to know is who is the technical designer on his team? Note that Gilson's machine is based on a paper published by Mark Oskin, Fred Chong, and Tim Sherwood. (This paper was about something called "Active Pages" and has a lot to do with Processing-In-Memory, research that we are also working on). I would think of Chong as being the lead investigator. Here's his homepage: Active Pages This article is chock full of no-namers, but one name does have weight. That's Allan Snavely, who published a very informative piece on benchmarking the Tera MTA. It doesn't surprise me that he was trying expose Gilson's machine as a hoax - Snavely has a big interest in multithreaded parallel machines, and so PIM-like Distributed Memory Architecture like this one is rather suspect. He's also a performance nut (what self-respecting computer engineer isn't?) Take Snavely's comments with a grain of salt. Snavely has most likely read Chong's Active Pages ISCA paper, made back in 1998. He's known about the possibilities of reconfigurable FPGA computing for 5 years, and this is probably his first experience interacting with an actual compiler for it. In our business, whenever anyone sees a compiler for a machine - even if it is theoretical, it's automatically known to have "have promise". Just don't hold the future of computing to that.