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?"

Comments

The lighter side...

[chimpo13]

Of an Alfred E. Neuman computing age. I can't wait to see Dave Berg's take.

Roger Kaputnik where art thou?

Re:The lighter side...

[mattsucks]

Sometimes I think we ARE in an Alfred E. Neuman computer era ... "What, Me Worry?" sounds an awful lot like the rationale for Palladium & "trusted computing"

Well,

[0x00000dcc]

Paradigms in science are not meant to last forever, they are usually broken, and computer science is no stranger to this candy.

Re:Von Neumann machines?

[PD]

Von Neumann means a processor hooked up to a single memory that contains both the program and the data, executing instructions one at a time in a sequence.

Compare this to the Harvard architecture used on some embedded processors: a processor hooked up to two separate memories, one containing the program, and the other containing the data. This is useful when you have your program in an EEPROM and your data in a little static RAM. Two types of memories naturally fit into a Harvard architecture, though it's simple enough to do the same thing with some memory mapping circuits.

Three articles

[stratjakt]

Two requiring a subscription, and one a goofy PR piece about wingnut FPGA "computers" that cost 200Gs and up.

Anyways. The FPGA machines sound intriguing, but really arent as 'all powerful' as the non-techie Forbes piece makes them out to be. Not everything is parralellizable, not everything is conducive to dynamically altering the instruction set as you run it.

The traditional von neumman architecture is the best solution for many processing tasks, lots of stuff is just conducive to a sequentially operating processor. It's probably the best for all around general computing.

And 200 grand is probably better spent on a beowulf cluster of something than one of these boxes, but I'm sure they have a niche of usefulness somewhere.

I dont expect to see the traditional computer go anywhere anytime soon.

I'll believe it when I see it.

[TerryAtWork]

I'm sure these articles mention the 'Von Neumann Bottleneck' which is a power distribution in instruction execution, as 10 % of the instructions get executed 90 % of the time.

But *I* say the REAL VNBN is that only 90 % of all computer scientists are only 10 % as smart as Von Neumann.

Re:Von Neumann machines?

[beezly]

A terrible Karma Whore opportunity, but from FOLDOC..

John von Neumann /jon von noy'mahn/ Born 1903-12-28, died 1957-02-08.

A Hungarian-born mathematician who did pioneering work in
quantum physics and computer science.

While serving on the BRL Scientific Advisory Committee, von
Neumann joined the developers of {ENIAC} and made some
critical contributions. In 1947, while working on the design
for the successor machine, {EDVAC}, von Neumann realized that
ENIAC's lack of a centralized control unit could be overcome
to obtain a rudimentary stored program computer. He also
proposed the {fetch-execute cycle}.

{(http://www.sis.pitt.edu/~mbsclass/is2000/hall_of _fame/vonneuma.htm)}.

{(http://ei.cs.vt.edu/~history/VonNeumann.html)}.

{(http://ftp.arl.mil/~mike/comphist/54nord/)}.

--
Basically a von Neumann machine takes instructions in serial and process them one by one, altering the course of it's instruction flow based upon the instructions preceeding it (i.e. normally it carries on to the next instruction except for jumps and things like that). Nearly all current (All? can any one suggest any others in frequent use) computers are Von Neumann architectures.

Re:Von Neumann machines?

[sketerpot]

I'm not a real computer scientist either, but I think that Von Neumann came up with the basic model of computers that we take for granted today. For example, a processor that accesses memory, and does instructions in a linear sequence, or something like that.

The implication is that we are approaching a transition to some seriously wacked out computer designs. I look forward to seing what these people are coming up with. DNA computers, for example, have a different model of computation.

not a hoax...

[Anonymous Coward]

For those of you skeptics (like myself when I first saw the articles) and for those that didn't RTFA:

Allan Snavely, a computer scientist at the University of California at San Diego Supercomputer Center, has been using a Star Bridge machine for about a year. He says he originally contacted Star Bridge because he suspected the company was pulling a hoax. "I thought I might expose some fraud," he says.

But after meeting with Gilson and seeing a machine run, he changed his mind. "They're not hoaxers," he says. "As I came to understand the technical side I thought it had a lot of potential. After talking to Kent Gilson I found he was very technically savvy."

Silicon Graphics has also asked Star Bridge to send along a copy of its hardware and software. The $1.3 billion (fiscal-year 2002 sales) supercomputer maker wants to explore ways to make a Star Bridge system work with a Silicon Graphics machine.

Over the past two years Star Bridge has sold about a dozen prototype machines based on an earlier design to the Air Force, the National Security Agency and the National Aeronautics and Space Administration, among others. It has also sold seven of the new models.

Olaf Storaasli, a senior research scientist at NASA's Langley Research Center in Hampton, Va., has been using Star Bridge machines for two years and says they are very fast but not yet ready to handle production work at NASA. "It's really a far-out research machine," he says. "It's more about what's coming in the future. I would not consider it a production machine."

One problem, Storaasli says, is that you can't take programs that run on NASA's Cray (nasdaq: CRAY - news - people ) supercomputers and make them run on a Star Bridge machine. Still, he says, "This is a real breakthrough."

"A microprocessor can only do one thing at a time"

[ssimpson]

...Well, that's what the article says. I guess they haven't heard about pipelining, multiple execution units, SIMD etc etc.

Re:Von Neumann machines?

[Mr. Slippery]

Aren't Von Neumann machines self-replicating devices, which AFAIK we don't have?

Von Neumann was smart enough that there is more than one thing named after him. A Von Neumann machine is a self-replicator. A Von Neumann architecture is a computer architecture where programs and data are stored in the same manner.

Sometimes the latter is also referred to as a Von Neumann machine.

Futureware

[Ghoser777]

"Gilson has not subjected his machines to industry benchmark tests."

Yeah, I have a computer doing 1 trillion giggaflops a second powered by my pet hamster. No test results can disprove me yet!

"I live in the future."

Clearly.

"'It's really a far-out research machine,' he says. 'It's more about what's coming in the future.'"

Yep. So the title is kind of misleading. This is all stuff in the future, like flying cars and such. We could make flying cars if we wanted to, but we really don't want to yet (economic and regulatory reasons). This technology has the impedments of still really being explored and economic feasibility.

It'll rock when they're ready, but it's nothing to go nuts over yet.

F-bacher

Yeah, and look what happened to BOPS

[leek]

BOPS tried the same thing with FPGAs, and look what happened to them.

Also see this thread.

What I think might have merit...

[Fnkmaster]

Much like custom vertex shaders and reconfigurable GPUs have greatly increased the capability of modern graphics cards and greatly reduced the amount of CPU cycles required for very complex real-time 3D graphics, I think that a reconfigurable logic coprocessor model has real potential to take certain computationally intensive repetitive tasks off the hands of a dedicated CPU. The problem of course is that the technology doesn't currently exist to, say, compile an arbitrary chunk of C code into a program that can run on an FPGA computer - the compiler technology is mentioned in the article as the current limiting reagent. A common understanding of how this should work needs to be developed, and rules for when it's useful, and the relationship between I/O constraints and processing speedups needs to be taken into consideration.

In general this "partitioning" process seems to be somewhat domain-specific and difficult. If you could do something like integrate into a JIT environment something that identified computationally intensive, repetitive, small-sized chunks that aren't I/O constrained, and be able to generate FPGA code on the fly, that would be tres cool.

Can anybody really explain why it's so hard to make a somewhat higher level language that can be compiled down to VHDL and combined with various chunks of library code into a specific FPGA configuration?

Re:What I think might have merit...

[Obsequious]

It depends on what you're trying to do.

Usually when you are trying to compile something down to logic gates, you have to handle instruction scheduling. For example, in any conceivable situation, division always takes longer than addition. So, you have to make sure that while you're waiting for a division to complete all the rest of your data doesn't evaporate.

This isn't like a general purpose processor == there are no persistent registers here. Use it or lose it. So you have to stick in tons of shift registers everywhere, as pipeline delayers.

So it's not as simple as just saying res = (a + b) /r + (q * p); or something, because you have to synchronize all the data. All this, of course, is just for a calculation: imagine the difficulty when you are waiting for signals on off-chip pins, when you don't even know how long you're going to be waiting. Also consider how you handle cases where you have to talk to memory: you usually have to write your own memory CONTROLLER, or at least use someone else's, meaning you actually have to worry about row and column strobes, whether it's DDR or not, and so on.

If you've done multithreading programming and understand those difficulties, then take that and multiply the difficulty by a couple times, and you just about have it.

All that said, though, you're right: it shouldn't be that hard. If all you want to do is use C to express a calculation, that is fairly easy to boil down to a Verilog or VHDL module.

The problem is that most of the 3GL-to-HDL vendors try and boil the whole ocean. They want you to use nothing but their tool, and never have to look at Verilog. That is where things really start to break down.

An example of this done mostly RIGHT is a company whose name I can't remember. (AccelChip?) They make a product that takes Matlab code and reduces it to hardware. That's easier in a lot of ways, because Matlab is really all about simply allowing you to easily express a mathematical system or problem. There aren't all these control flow, I/O, and other random effects. My understanding is that this Matlab-to-VHDL tool works quite well.

So, it all depends on what you want to do with the FPGA. :)

Re:What I think might have merit...

[Fnkmaster]

That makes a lot of sense. I have done simple VHDL programming before, so I do have some sense of the complexity involved in synchronizing data flow between different circuits and logic paths (and god knows, I know all about the complexity of multithreaded programming - I'd say only about 10%-20% of programmers have a proper sense of how to write safe multithreaded code).

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).

Re:"A microprocessor can only do one thing at a ti

[IWannaBeAnAC]

Sure, but they are only variations on the theme of single threaded execution. There is still only one Instruction Pointer, even if it is not always exactly defined due to out-of-order execution or other trickery. Logically, there is still only a single instruction sequence that appears as if it is executed in order. It is nothing like the concurrent processing of, say, the brain, or even a transputer.

Even hyperthreading is only a minor improvement in parallelism, exchanging one instruction pointer for a small number (2? 4?). Hardly a different architecture.

Von Neumann Machines Defined

[Nyarly]

The basis of almost every digital computer is a basic cycle, viz:

1. Load the next instruction from the memory location indicated by the program counter.
2. Decode the instruction.
3. Execute the instruction.

Some implementations add a step between 1 and 2 that says "increment the program counter" and leave jumps up to specific instructions. Others associate program counter changes with every instruction (i.e. jumps go to somewhere specific, every other instruction also implies PC++.)

There's nothing more to Von Neumann machines. They are unrelated to finite state machines or Turing machines, except that every Von Neuman machine can be modelled as a Turing machine. The difference is that a Turing machine is a mathematical abstraction, whereas Von Neuman machines are an architecture for implementing them.

Whoo hoo. And yes, I am a computer scientist. Or maybe a cogigrex.

Oh god, here we go again with the hype...

[Obsequious]

Okay, no. FPGAs are NOT going to completely change computing.

First, you have to understand what they are: basically an FPGA is an SRAM core arranged in a grid, with a layer of logic cells (Configurable Logic Blocks, in Xilinx's parlance) layered on top. These logic cells consist of basically function generators that use the data in the underlying SRAM to configure their outputs. Typically they are used as look-up tables (LUTs) -- basically truth tables that can represent arbitrary logic functions -- or as shift registers, or as memories. On top of THAT layer is an interconnection layer used for connecting CLBs in useful ways. The FPGA is re-configured by loading the underlying SRAM with a fresh bitmap image, and rebuilding connections in the routing fabric layer.

You write for FPGAs the same way you build ASICs. You use the same languages (Verilog, VHDL) and sometimes the same toolchain. The point being: this is HARD. Trust me, I've been doing it. Verilog is damn cool, but remember that you're still building this stuff almost gate-by-gate.

There are a number of tools out there that do things like translate 3GL languages (such as Xilinx's Forge tool for Java, or Celoxica's DK1 suite for Handel-C) to an HDL like Verilog. Other tools like BYU's JHDL are essentially scripting frameworks for generating parameterized designs that can be dumped directly into netlist (roughly equivalent to a .o file.)

My job for the past several months has been to obtain and evaluate these tools. I can tell you that these tools are not there yet.

So what do you use FPGAs for? Well, for the next 5 years, likely one of two things: either really cheap supercomputers (which is what we are working on) or as a "3D Graphics card play." The supercomputing play is obvious, the the other one bears explanation.

Anything you can think of goes faster if you implement it in hardware. 3D graphics is a great example: most cards today consist of a bunch of matrix multipliers plus some memory for the framebuffer, and a bunch of convenience operations that you do in hardware as well (like textures and lighting and so on.) Because it's in hardware, it's way faster than anything you could do on a general purpose processor.

Now, the problem is that hardware means ASICs (until recently.) ASICs are only cheap in large volumes. Thus, for applications that are not mass-market (like graphics cards are) it is not practical to build out an industry building hardware accelerators for them.

That's where FPGAs come in. FPGAs cost more per ASIC, but less than ASIC in small volumes. This suddenly makes it practical to make custom hardware accelerators for almost anything you can think of.

This is also true of supercomputing: supercomputers are still general-purpose, just not THAT general-purpose. Your algorithm still benefits when you can just reduce it to logic and load it onto a chip. You might only be running at 200MHz, but when you get a full answer every clock cycle, you suddenly do a lot better than when you get an answer every 2000 cycles on your 2GHz processor.

So to get back on topic, where will we see FPGAs? Well, you might expect to see an FPGA appear alongside the CPU on every desktop made in a few years; programs that have a routine that needs hardware acceleration can just make use of it. (Think PlayStation 4, here.)

You might also see things like PDAs come with FPGA chips: if your car's engine dies, you can just download (off your wireless net which will be ubiqutious *cough*) the diagnostic routine for you car and load it into that FPGA and have your car tell you what's wrong.

Aerospace companies will love them, too. Whoops, didn't catch that unit conversion bug in your satellite firmware before launch? Well, just reprogram the FPGA! No need to send up an astronaut to swap out an ASIC or a board.

What you're NOT going to see is every application ported to FPGAs willy-nilly, because like I said, this stuff is not easy. I'm coming a

Re:Oh god, here we go again with the hype...

[Obsequious]

I am mostly familiar with Xilinx's parts, but my understanding is that really the only other maker is Altera and they are a couple years behind.

The Virtex II (Xilinx's latest) clocks at up to 200MHz, though the more complicated your circuitry, the lower it gets. 200MHz is a theoretical max -- like Ethernet; you never quite reach it in practice.

It includes a number of on-chip resources, such as block memories (which are more like cache SRAM than DRAM DIMMs you are probably used to) and 18-bit-wide hardware multipliers. The Virtex II Pro line is a Virtex II plus an actual processor core -- PowerPC, ARM, or their own MicroBlaze I believe. (That alone is proof enough that von Neumann machines aren't dead -- Xilinx INCLUDES one in some of their FPGA parts!)

You can get them in various sizes, which basically means how many CLBs they have. Xilinx measures these in "logic gates" though that is really a somewhat sketchy metric (like bogomips, sort of.)

And yes, you can actually run data through and get results back one per cycle. To accomplish this, you usually HAVE to pipeline the design. Typically you end up with a scenario where you fill up the chip's logic with your design, and start feeding it data at some clock speed. Then a few hundred cycles later, you start getting results back. Once you do, they come at one per cycle.

We have an application where we are actually clocking the thing at 166MHz -- which is the speed of a memory bus, not coincidentally. Given this config, we are basically clocking the chip as fast as the memory can feed us data. The idea is that we read from one bank at 166MHz, and write to another at 166MHz.

One way to think of this is as a memory copy operation, with an "invisible" calculation wedged in between. When you consider what a Pentium 4 would have to do (fetch instructions from cache/memory, fetch data from cache/memory, populat registers, perform assembly operations, store data back, not to mention task switching on the OS, checking for pointer validity, and so on) you begin to see the advantage of FPGAs.

billions of operations: on what?

[studboy]

I've programmed on the old bit-sliced Connection Machines, which are vaguely similar. Two points to ponder:

- 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 ...? Is there a bunch of DRAM somewhere or do you carve memory out of the (expensive) FPGA?

FPGA's for Sw engineers:so how hard is this stuff?

[gwappo]

I've had the pleasure of doodling with an XSA-100 board for some time now, this has a nice little sdram (8mb) some flashram, a CPLD connected to your parallel port, plus, every geeks favorite, it has a vga-port connected to it with some simple two-bit/channel resistor based DA converter for your rgb. Add the free (beer) Xilinx Foundation kit, and you've got yourself a hip VHDL (=language) setup.

Hw vs. Sw - which is more difficult to "doodle" with?

Me also having a software background allowed me to relate to your story a little bit. However, our experiences have differed I think, cause in all honesty, judging from the *hobbying* I've done, software is *far* more complicated than hardware, reason being the volume of logic involved. As long as your ambitions are not to exceed the next Intel design, doing your own VHDL design is a fun, enjoyable, well overviewable and especially *rewarding* endeavour!

Designing stuff

In a hardware design, your design = your code (want a schematic, do it in a schematic! -- and not like UML 'roundtrip' engineering, no, the real thing), with software this is rarely the case. Furthermore, because a hardware design has a very focussed purpose, its more streamlined, software tends to need all bells and whistles you can throw at it to further complicate the design and thus introduce much more bugs - with hardware, things *typically* stay reasonably elegant since the way you like to think about it, is the way you'll be implementing it.

The only big problem I encountered with coding FPGA's is the *enormous* difficulty in Debugging your code. Many linuxers that are "printf" inclined to debug will have to learn that a bunch of leds is all you got when hobbying. (The "free" tools for signal simulation is just a royal pain -- I didn't get one to work due to the "free" license key I needed to install). This involved a _lot_ of theorizing on my end as to why it didn't work. (Eg. driving a vga signal, "why is my screen flickering" is the only info you've got (but hey, it's better info "why is my screen smoking?", right?)).

Anyway, Jolly good fun, I can recommend it to any software engineer - wouldn't call it the next best personal development step from Java but if you know your way around CPU's and can recognize Pascal type languages, VHDL ain't that hard.

Books Some books I found useful in my endeavours :

VHDL for Designers, fun book, good read, introduces VHDL as a language and how to write your stuff. Also relates it to the various VHDL "compilers" so you know what works where.

ASIC Handbook, little book, handy overview of process / project management, if you're inclined to go the asic route.

Art of Electronics, you'll need to understand what happens on your circuit board, and be able to read diagrams.

and lots and lots of datasheets, but you can get those off the net!

Great fun, and not as hard as it sounds - buy a board, download the Foundation kit, and doodle!

Wilkes Machines Defined

[Baldrson]

Von Neumann came up with the idea of storing computer instructions as data. Previous computers were programmed by changing jumpers, boards, etc. They had to be reprogrammed between tasks. Von Neumann let computers reprogram themselves, an amazing advance.

You're talking about Maurice Wilkes, not Von Neumann.

Already there

[Tim Sweeney]

If you're running a 3D-accelerated PC game or modelling application, the majority of your computer's FLOPS are already consumed by a non Von Neumann computing device.

For better or worse, most of the PlayStation2's computing power is locked up in a non Von Neumann architecture.

So the evolution of computing to non Von Neuman architectures isn't so much news as a gradual shift that began about 5 years ago with 3dfx, and is really starting to happen large-scale right now.

The justification for FPGA's in consumer computing devices could be seen as a generalization of the rationale behind 3D accelerators: they bring you the ability to get a 10X-100X speedup in certain key pieces of code that are inherently very parallel and have very predictable memory access patterns.

I think the timeframe for mainstream FPGA style devices is quite far off, though. They need to evolve a lot before they'll be able to beat the combination of a Von Neumann CPU augumented with several usage-specific non Von Neumann coprocessors (the GPU, hardware TCP/IP acceleration, hardware sound...)

Here are the major issues:

- You'll need a lot more local memory than these devices have now -- there is a very limited set of useful stuff you can compute given a 32K buffer (a la PS2) and significant setup overhead.

- The big lesson from CPU's (and I expect from GPU's in the next few years) is that things REALLY flourish once you have virtualization of all resources, with a cache hierarchy extending from registers to L1 to L2 to DRAM to hard disk. For virtualization to make sense with FPGA's, Star Bridge's quoted reprogram times (40 msec) would need to improve by about 10,000X. Without this, you can really only run one task at a time, and that task can only have a fixed number of modules that use the FPGA.

Even then, it's not clear whether the FPGA's will be able to compete with massively parallel CPU's. In 3 more process generations, you should be able to put 8 Pentium 4 class CPU's on a chip, each running at over 10 GHz, at the same cost as current .13 micron CPU. Such a system would be VERY easy to program, a couple orders of magnitude more so than an FPGA. So even though it wouldn't have as much theoretical computing power as an FPGA, massively parallel CPU's are likely to win out because they have the best cost/performance when you factor in development cost.