I myself am an engineer for AMG. We manufacture products to compete with the motorboats produced by Intel.

We have come up with a "reverse hyper-sailing" technology for making two motorboats appear as one. This will probably be used on the QE10.

Discuss :-P

That report on x86 has to be one of the most vague and utterly attention-grabbing news pieces I've seen. There are practically no details.
-Mole

This sounds more for legacy apps that aren't multi-threaded - but definately makes sense if they can work in a clustered environment for masive processing power.

This just sounds like a hardware version of IBM's mainframe/cluster OS logic, which hides the processors from the application so a cluster of 1000 CPUs looks like 1 CPU.

My guess is that this is for AMD's move into the big tin market. You guys are thinking 2-4 processor machines, AMD is thinking 100+.

This sounds like bogus with all respect. Since we are all back to all the current issues on why we cant make a 200 issue wide x86 CPU.

You gonna end up having one instruction waiting for another and so on anyway. Even the term reverse hyperthreading makes no sense.

Hell even in the best case, you gonna end up having x amounts of cores doing a speculated instruction on what core0 result will be. So dependent on how good it is to speculate, you can end up with anything from having somewhat bonus on a quadcore with a singlethreaded application, to basicly no gain at all for 64cores.

May be they can try to do predicated execution ala IA-64 in each core? Then they can almost get rid of the branch prediction stuff?

Huh.

So, either you design a chip for ILP with TLP hacked on for when ILP doesn't pan out (Hyperthreading) or you design a chip for TLP with ILP hacked on for when TLP doesn't pan out ("reverse" hyperthreading).

It seems that Intel is implicitly taking the position that it's better to design for ILP and add TLP on top while AMD is taking the opposite view.

It seems to me that in cases where AMD's approach would work, it would also be easy for the developer to just split their app into multiple threads. And in cases where it wouldn't be easy for the developer to do that, then AMD's approach probably wouldn't work.

What's all the confusion?

Currently, for multiple processor systems, the OS has to juggle which thread goes to which processor. A multi-core system operates the same way. To the OS, the second core looks like a second processor.

What this sounds like is that the OS will see only one processor, but the processor will have internal logic to give out tasks to different cores.

To me this reads like they are implementing an on-chip scheduler to load distribute both multi-threaded apps and single-threaded apps (if possible), thereby (potentially) removing that chore from the OS.

Could be wrong though.

The only problem i see with AMDs approach is that even if reverse threading (just fancy for speculative execution) works is that you'll need OS support if not compiler support. OSs right now generally cant deal with dynamically switching 4 virtual processors to 2 in RT. That will have to be updated. Also I figure this kind of support will need EFI or more advanced bare metal firmware. The optimal solution is to present the os or even the application the interface to fuse 2 cores together and run in speculative mode in RT. It also makes Hyper Threading a possibility in the opposite sutuation where several low impact threads can be parallelized across several virtual cores (again in RT). Things are looking bright for intel and amd.. this is some sweet technology. I think in the next few generations performance between AMD and Intel wont matter as much as the features they both provide. GPUs and PPUs and HTX based co-processors are taking away much of the load off CPUs. Only thing left is to make the cpu even more flexible because thats its only strength.

I think I see a lot of upside with this, there are some processes that just aren't SMT friendly without a lot of work.
It may lead to lazier programming, though.

I was actually wondering if Intel has already done this with the Conroe chip.. and thus the big performance gains.

On a dual-core system, the trick would be to make the two cores act like one in same cases (ie when running games that dont take adv. of two very well) and then work like two in most situations.

Sounds kinda like a further evolution of OoO processing....

I thought the scheduler was responsible for splitting the workload?
This sounds like a way to compensate for OS deficiencies.

On the surface this sounds a bit like transforming single threaded into multithreaded code, which as I gather is pretty much impossible to do in a generic fashion.

What this may be instead, though, is that the CPU has X number of execution units, and it can partition them into cores at will; so it could appear as a single core CPU with 6 execution units, or a dual core with 3 each, to take advantage of either instruction- or thread-level parallelism, whichever is in greater abundance at the moment. I'm not sure how theoretically possible this is, but it does seem more so than the other option.

Cool now, much much cooler when we start seeing 4+ core chips! =D

OOoh. I like the sound of this. Even dual cores are underutilized now, at least for the average desktop system.