Reverse Multithreading CPUs

microbee writes "The register is reporting that AMD is researching a new CPU technology called 'reverse multithreading', which essentially does the opposite of hyperthreading in that it presents multiple cores to the OS as a single-core processor." From the article: "The technology is aimed at the next architecture after K8, according to a purported company mole cited by French-language site x86 Secret. It's well known that two CPUs - whether two separate processors or two cores on the same die - don't generate, clock for clock, double the performance of a single CPU. However, by making the CPU once again appear as a single logical processor, AMD is claimed to believe it may be able to double the single-chip performance with a two-core chip or provide quadruple the performance with a quad-core processor."

Comments

Isn't that just superscalar?

[tepples]

Multiple cores presented as one sounds familiar. Last time I heard about that, it was just called "superscalar execution". As I understand it, multithreading and multicore were added because CPUs' instruction schedulers were having a hard time extracting parallelism from within a thread.

Huh?

[SilentJ_PDX]

What's the difference between 'reverse multithreading' (it sounds like having one execution pipeline on a chip with enough hardware for 2 cores) and just adding more Logic/Integer/FP units to a chip?

Software isn't evolving.

[Anonymous Coward]

Part of the problem is that we're still writing software using techniques that were designed for single-processor systems. Languages like C and C++ just aren't suited for writing large distributed and/or concurrent programs. It's a shame to see that even languages like Java and C# only have rudimentary support for such programming.

The future lies not with languages such as Erlang, and Haskell, but likely with languages heavily influenced by them. Erlang is well known for its uses in massively concurrent telephony applications. Programs written in Haskell, and many other pure functional languages, can easily be executed in parallel, without the programmer even having to consider such a possibility.

What is needed is a language that will bring the concepts of Erlang and Haskell together, into a system that can compete head-on with existing technologies. But more importantly, a generation of programmers who came through the ranks without much exposure to the techniques of Haskell and Erlang will need to adapt, or ultimately be replaced. That is the only way that software and hardware will be able to work together to solve the computational problems of tomorrow.

Amdahl's Law

[overshoot]

OK, I know some of the gang doing architecture for AMD and they are damned sharp people.

What I want to know is which of the premises underlying Amdahl's Law they've managed to escape?

Re:Amdahl's Law

[grumbel]

Quick guess:

Amdahl's Law has little impact when the number of cores is small and the available task is "large", as todays multitaskin OSs are.

Of course that doesn't mean that AMD will get a 100% improvment, but something close to that migth be doable if they can break the tasks at hand into parallel stuff at a much smaller level then threads.

No, superscalar is different

[overshoot]

Superscalar refers to having multiple execution paths inside of a single processor, allowing the dispatch of multiple instructions in a single clock cycle. However, the register sets (etc.) maintain a common state (although keeping the out-of-order updates straight sucks a huge amount of complexity and power.)

In this case, AMD appears to be trying to decouple the states enough that the out-of-order resolution doesn't require micromanaging all of the processes from a single control point.

Yes, AMD! You get it!

[totro2]

As a systems admin in a large datacenter with many AIX, Solaris, HPUX, Redhat, and Suse boxes, I'm glad to see a vendor who wants to simplify management of systems (one processor is easier to manage than two). This is to say nothing about all the developer effort that would be saved from not needing to make making SMP-safe code. I want large, enterprise level boxes to be just as easy to administer/use as the cheapest desktop in their line. The OS should see as-simple-as-possible hardware. You wouldn't believe all the different kinds of "system managent consoles" I have to log into, which are always vendor specific and annoying.

K8L

[Anonymous Coward]

This would be, perhaps, more useful with the quad-core version - appearing as two processors to still allow the OS to allocate multiple threads?

But what I really want to know...

[Joebert]

Is Microsoft going to recognise this contraption as a single, or multi-liscense-able processor ?

And

Will AMD only hide the fact there's multi-cores from Operating systems other than Microsoft ?

Speculative Multithreading

[DrDitto]

This was proposed in acadamia over 10 years ago. Its called speculative multithreading, or "multiscalar" as coined by one of the primary inventors at the University of Wisconsin (Guri Sohi).

Basically the processor will try to split a program into multiple threads of execution, but make it appear as a single thread. For example, when calling a function, execute that function on a different thread and automatically shuttle dependent data back/forth between the callee and the caller.

This is Like RAID for CPU's

[Marc_Hawke]

Striping: What is that? Raid 1? Raid 0? You take multiple disks, present them as one, and let the controller make the most effecient use of them while the OS and all the programs just have to deal with one big disk.

Looks like the same thing. You take multiple CPU's present them as one, and let the controller figure out how to best use them.

This could make for hot-swappable CPUs (heh) and the ability to have a CPU die without taking out your system. The redundacy nature of the other RAID configurations don't seem to translate very easily, but the 'encapsilation' concept seems to fit nicely.

What about this...

[Darkenreaper57]

I don't have a lot of background in CPU architechture, but what if there was a parallel processing unit designed specifically to allocate threads to the cpus? This way, the cores can all function as one at the hardware level, rather than the software level (thus making it easier on developers and potentially increasing performance). Would it be better to have a dedicated unit/sector to process this information and divy it up to the separate cores, or no?

Or maybe predicting both branches?

[silverdirk]

As one reply stated, you can't know which is right unless you had 3 cores.

But, with two cores, you could have a way to predict "branch" and "not branch" at every prediction spot. The core that gets it right sends the registers to the other core so they can continue as if every branch were predicted correctly...

That would only work if you had a nice fast way to copy registers accross in a very small number of clock cycles... so again, just a bunch of speculation. But it was a neat enough idea I had to say it.