How to Kill x86 and Thread-Level Parallelism

kid inputs: "There's an interesting article discussing how one might go about 'killing' x86. The article details a number of different technological solutions, from a clean 64-bit replacement (Alpha?), to a radically different VLIW approach (Itanium), and an evolutionary solution (Opteron). As is often the case in situations like these, market forces dictate which technologies become entrenched and whether or not they stay that way (VHS vs Beta, anyone?). Another article by the same author covers hardware multi-threading and exploiting thread level parallelism, like Intel's Hyperthreading or IBM's POWER4 with its dual-cores on a die. These types of implementations can really pay off if the software supports it. In the case of servers, most applications tend to be multi-user, and so are parallel in nature."

Comments

endian-little post first!

[zulux]

Post! First

A From Litte A system endian!

Rules! x86

Don't forget

[Misinformed]

The space shuttle still uses 16-bit x86s, the financial system is reliant on v_e_r_y old systems which spew out dot-matrix printed backups. Old systems survive today, and IMHO will always. It has to be organic.

This is what SUN calls

[caesar79]

"Throughput computing"..where the performance is measured not individually but in aggregate.
See their media kit available at
http://www.sun.com/aboutsun/media/presskits/thro ug hputcomputing/ for more details.

However, I believe the whole idea is nothing new. AFAIK, there are only two ways of increasing the performance of a processor (Operations Per Second) - either increase the IPC (Instructions per cycle) by increasing parallelism or decrease the cycle time by increasing the clock Rate (Ghz).

Each method has its limits and follows the law of diminishing returns - for e.g. increasing the clock rate implies increasing the number of stages in the pipeline...and after say 10000 stages, the penalties imposed due to flushing the pipeline might compensate for the increased GhZ. Similarly if you manage to place 100000 cores on a chip, scheduling amongst these cores and providing realtime access to the memory for all these cores will become the bottleneck. Hence, I take statements like "how to kill the x86" with a pinch of salt.

Finally, it will the fabcrication (physical) technology that decides which one of these dies. For e.g. if tomorrow someone is able to come up with a process that enables 100Ghz chips at the (think extensions of SOI etc) decreasing the cycle time will win. Similarly, if someone comes out with femto (10^-15 ) metre fabrication technology, then parallelism will win.

Architecture for software reliability

[Animats]

Depends on the goal. Here's an architecture for reliability. If vendors had to pay whenever a program crashed, we would have seen this years ago.

• Channelized I/O With current peripheral bus to memory interfaces, peripherals can store anywhere in memory. So drivers impact system stability. It doesn't have to be that way. IBM got this right in mainframe design in the 1960s. You want an MMU between the peripherals and memory. Drivers then become non-privileged programs. Existing peripherals don't even need to know there's an MMU in the middle, just as programs don't.
• High-speed copy. Copying data in memory should be really fast, so fast that it's almost free, even if it takes copy-on-write hardware in the cache to do it. Why? Because then the temptation to put everything in one big address space decreases. With good interprocess communication (think QNX messaging, not CORBA, or horrors, SOAP), building programs out of components can actually work. This includes the OS. File systems, networking, and drivers should all be user programs.

  The neat hardware implementation of this would be to make all MOV instructions take nearly the same time, regardless of the amount of data moved. A MOV should result in a remapping of the source and destination memory in the cache system. Even if this were just implemented for aligned moves, it would be a big help. When your application's 8K buffer needs to be copied to the file system, that copy should be done by updating cache control info, not by really doing it.

• Graphics MMUs Get rid of the "window damage" approach, and have real hardware support for overlapping windows. All that's needed are big sprites. Then programs don't have to know or care which window is on top. "Overlay planes" do some of this, but it's not general enough.

  With this, windowing becomes far simpler. Each window is maintained locally. Shared window management is reduced to screen space allocation, which is done by commanding the window MMU.

Re:Architecture for software reliability

[RalphBNumbers]

Actually, what you refer to under "Graphics MMUs" has been done for a while under OSX with Quartz and Quartz Extreme.
Windows are drawn on OpenGL surfaces and their layering is handled entirely by the GPU in Quartz Extreme, and plain old Quartz does basically the same thing in software buffers. In either case, an app never has to do any redreawing when one of it's windows is revealed, it's all handled by Quartz.
And supposedly, whenever it eventually comes out, Longhorn will do more or less the same thing.

Channelized I/O is probably a good idea, but it's either going to cost you some bandwidth (route all IO through a expanded version of current MMUs), or be expensive (a seperate MMU for IO). I'm not saying it might not be worth it in the long run, but it will take a bite out of price/performance in the short term for questionable immeadiate stability gains (one would hope that most people writing kernel space drivers have the sense to KISS).

High speed copy sounds really interesting, but I'm not sure how practical it is to add to current systems.

Multiple chips

[Tablizer]

Why not define a new standard machine code set and start making new chips with it? Old software can use the old chip and new software use the new chip. Game machines do something like this.

Emulators can be implemented such that old chips can still run code from the new standard (and visa versa), just slower. For development, training, simple apps, and testing that is usually fast enough.

A box could come with both an X86 and an Alpha-clone, for example. Eventually over time the X86 chip is not worth it. The few old apps laying around just use emulation mode.

Re:Let's kill x86!

[Valar]

The problem with keeping the x86 architecture and the ISA are that it is carrying around legacy burdens from the 286. Even the p4 still boots into real address mode at boot up, and has to be PUT into protected mode. There are hundreds and hundreds of instructions, over 100 registers (but still only 8 GPRs), many of which overlap in purpose or are used for entirely non-intuitive purposes (CMPX EAX, EAX). x86 is ready, at the least, for a real version 2, that isn't afraid to break compatibility in order to add major architectural advances (I wouldn't mind a register ring :).