The opposite of hyperthreading

[DanceswithUnix]

You really think that's the situation? I bet AMD would secretly love to be able to do it, but can't for either technological or IP reasons.

Can't imagine there is an IP reason. IBM have similar tech to Intel, modern graphics chips are a threaded design too and Sun's recent CPU efforts are sort of a half way house with loads of threads and rubbish single threaded performance.

This stuff was made a popular buzz (amoung CPU designers at least) by the Tera MTA something like 15 years ago. I think the idea originates from the barrel CPU from the mainframe era. Amazing how many "recent" cpu features actually appeared in the CDC series in the late 60's.

Perhaps AMD just don't have the l33t skillz

[kalniel]

Can't imagine there is an IP reason. IBM have similar tech to Intel
, modern graphics chips are a threaded design too and Sun's recent CPU efforts are sort of a half way house with loads of threads and rubbish single threaded performance.

But none of them are using x86.

[Funkstar]

But none of them are using x86.

Plus there are closs licensing of patents between a lot of these companies

[DanceswithUnix]

But none of them are using x86.

At the point the Hyperthreading kicks in, Intel aren't either. The opcodes will have been translated into their internal micro-ops.

[kalniel]

At the point the Hyperthreading kicks in, Intel aren't either. The opcodes will have been translated into their internal micro-ops.

My point wasn't anything to do with the technical details, but the fact that those companies that use HT in their own solutions aren't bent over a barrel by their x86 license agreement. Some unbending might have occured with the things Intel are now cross-licensing back from AMD, but there are probably still many restrictions.

[DanceswithUnix]

My point wasn't anything to do with the technical details, but the fact that those companies that use HT in their own solutions aren't bent over a barrel by their x86 license agreement. Some unbending might have occured with the things Intel are now cross-licensing back from AMD, but there are probably still many restrictions.

You really think patents will mention x86 instructions for something like this? It would have to be far more general than that to generate any protection or income. Hence my point that others are doing it, and I believe IBM Power beat Intel to it by some margin (and with a better implementation too, I think Intel are only just catching up).

[aidanjt]

I've wondered for some time (10 years?!) if this was possible. Putting a layer over the CPU's which takes requests from a single threaded app and splits it across multiple cores. I'd guess the overhead in doing that would far outweigh any gains.......even if it were technically possible.

It still amazes me how many apps are still single threaded. Nothing pleases me more than seeing all 4/8/16 cores (at work) running between 80 and 100%

It's still a matter of how do you distribute instructions. How do you know when to push instructions across cores, when do you halt, when do you jump, how does one instruction 'know' it depends on the result of another?.. And so on. If you go down that path, CPU microcodes suddenly become macrocodes and consume more CPU time figuring out execution branches than doing actual execution. It's better just to write threaded code at the application level, which knows best how to approach a given problem.

[kalniel]

You really think patents will mention x86 instructions for something like this?

Not at all, the license could simply say that AMD are allowed to manufacture x86 instruction chips running no more than one thread per <core definition>.

[Kumagoro]

recent chips being able to use each others cache is in a way accelerating a single thread.

I wonder what else has the potential to be shared

[switchmode]

recent chips being able to use each others cache is in a way accelerating a single thread.

I wonder what else has the potential to be shared

It shares a single Cache area to allow faster memory access for the
ALU of the CPUs which is only of use if the next instruction or data is there

CPUs can shift numbers around but they have no idea what they mean. So any multi threading is only at a very basic level when done on the CPU. "speculative" out of order instruction processing. The really cleaver separation of tasks has to be in the hands of the programer/software that is running at an application / OS level (just another program really), and then only if the task can be broken up to run in parallel. I appologise if this sounds obvious. The CPU does not know how to process information that is beyond its ability.

A digital processor makes things look magical sometimes, but it just shifts bits.

At a very basic level in the CPU Arithmetic and Logic Units on the CPU die, it takes more than one clock cycle to decode and execute just one "X86" instruction. Thats not FSB cycles but the faster internal clock of the CPU. People keep talking about operations per clock but its a bit false unless you are talking about the FSB clock speed which is a lot slower than the actual logic on the CPU.

[Kumagoro]

So by having a cache which is usable by all will in some cases speed up single threaded programs.

[Fraz]

It still amazes me how many apps are still single threaded.

Probably because you don't appreciate quite how nails it is to make certain things multi-threaded. It's cost/benefit - and frankly, most applications don't need to be using more than one core. I've certainly never programmed anything requires more than one core, except maybe a cyclic redundancy checking algorithm in a hardware driver I wrote. Also, I guess there is a lot of programmer inertia, as people are having to re-train themselves to think/work in a different way.

[Funkstar]

Probably because you don't appreciate quite how nails it is to make certain things multi-threaded. It's cost/benefit - and frankly, most applications don't need to be using more than one core. I've certainly never programmed anything requires more than one core, except maybe a cyclic redundancy checking algorithm in a hardware driver I wrote. Also, I guess there is a lot of programmer inertia, as people are having to re-train themselves to think/work in a different way.

Following on from this, some apps just don't benefit from being in more than one thread, or even if they were multi-threaded, there just wouldn't be a performance benefit from it. Then you are just adding needless complexity to your app, increasing the risk of instability and bugs.

Most of the time I'm using my Quad desktop, the other three cores are wasted, but when I do something that does benefit from 4 cores, it's well worth the money I spent on it. Same goes for the 8GB of RAM I have in there

[switchmode]

So by having a cache which is usable by all will in some cases speed up single threaded programs.

Only if a chunk of address was in cache that they both need but thats unlikely. A shared cache area can help if the app is multithreaded and can use the ram cached if it has addresses needed by both processes. Two seperate cache areas would work almost as well (Twice the read to ram to load it) or better for single threads as both could load what they need rather than finding the cache in use by the other process thread. But this all depends on the task. Cache will have no use at all if the program/thread jumps to data that is in RAM and hits the cache data only now and then. (RAM is very slow compaired to cache.)