What happened with "Anaphase?"

[MisterMac]

I just remembered intels press pr RSS super stream of anything and everything, sometime last year in the summer - talking bout Reverse Hyperthreading.


The idea was simple to force single threaded code to spread across unused resources in other cores. (That idea should have perhaps been forced down back in 03/04 in itself, but nonetheless).

We know AMD is behind, but i assume if Intel has some prototypes running, so would AMD?


Imagine a bulldozer or piledriver 16 core with the "Anaphase" unit build in - that would certainly make the "MOAR CORES!!" strategy - seem like a golden cow in the long run.


Does anyone know, if we'll be seeing it soon? Haswell ? Broadwell ? Skylake perhaps?

Or are we still talking YEARS of trial/error before mass production?


Of course this tech/idea won't help if Intel finishes it and AMD has nothing :/


EDIT:

Would be a good feature for E series and high-end Xeons to perhaps justify the prices comparing to lowend less threaded/cored counterparts with the same process tech.

 

[BitByBit]

Reverse Hyperthreading was a rumour started by Fudzilla/Inquirer and was supposed to be an AMD technology. It seems someone jumped to their own conclusions after AMD started talking about dynamically partitioning resources, as we see in Bulldozer. 'Clustered multithreading' was another example of people jumping to their own conclusions.

If I remember correctly, Intel looked at speculative threading as part of their Mitosis project, but eventually abandoned it since the performance improvement didn't justify the increase in power.

 

[MisterMac]

Reverse Hyperthreading was a rumour started by Fudzilla/Inquirer and was supposed to be an AMD technology. It seems someone jumped to their own conclusions after AMD started talking about dynamically partitioning resources, as we see in Bulldozer. 'Clustered multithreading' was another example of people jumping to their own conclusions.

If I remember correctly, Intel looked at speculative threading as part of their Mitosis project, but eventually abandoned it since the performance improvement didn't justify the increase in power.

Mitosis was way older.

http://newsroom.intel.com/docs/DOC-1111

There was an official press release, but it could be it just died out since in practical terms it didn't pan out as well as in theory?

 

[Ben90]

I really doubt we will see a reverse HTT type deal for a long time if ever at all. Until we start hitting the limits of Amdahl's law, its a much better to just increase core count.

 

[IntelUser2000]

its a much better to just increase core count.

That won't do anything with lightly threaded applications, which Mitosis was trying to address. Anaphase was yet another idea from Intel.

It might still be under research, but its at least 5 years away from being into production. The demos you see with prototype chips take 3-5 years to get into our hands, you think something that they've only shown in paper will take any less? In this case, decade or more away might be realistic.

 

[sm625]

It doesnt make much sense that a chip maker would forgo reverse-HT because it uses too much power, but then turn right around and implement turbo. Duh? If you have one core active processing one thread, you're pulling about 35 watts above idle. Now if you turn on another core and process a 2nd thread, your power generally only goes up by 60%, or 20 watts in my case. I have exact numbers on an E6600 at 3.2GHz. One prime95 thread pulls 35 watts from the wall (above idle). Adding a second thread only adds 20 watts for a total of 55 watts. So we know the max amount of power reverse hyperthreading could ever use (per thread).

To think that some of us wouldnt want to pay that extra penalty for higher performance is ludicrous. Hell yes I would pay an extra 20 watts for 20% more performance. Especially when its just a single thread. Even in the case of an i5-2500k, you could theoretically reverse-HT two threads and run all four cores. I say fire up those idle cores and use them any way possible. I dont care if it only adds 5% I would at least like the option. Again this is where I am really angry at AMD because ATI is not using those idle cores to *somehow* help with minimum framerates.

 

[NostaSeronx]

Ivy Bridge employs reverse hyperthreading per se

If you are running a 1-threaded app on a hyperthreaded core in Ivy Bridge

Hyperthreading turns off and all the registers/rename and all those jargon words that allow hyperthreading to exist can become dedicated to that 1 thread

On the fly

 

[podspi]

Ivy Bridge employs reverse hyperthreading per se

If you are running a 1-threaded app on a hyperthreaded core in Ivy Bridge

Hyperthreading turns off and all the registers/rename and all those jargon words that allow hyperthreading to exist can become dedicated to that 1 thread

On the fly

If we consider this reverse-HT, then in a way the FX-series implements this too


I think the rub is that speculative multithreading just doesn't actually increase performance as much as just boosting clock speed in most real-world applications, at least yet.

 

[exar333]

Ivy Bridge employs reverse hyperthreading per se

If you are running a 1-threaded app on a hyperthreaded core in Ivy Bridge

Hyperthreading turns off and all the registers/rename and all those jargon words that allow hyperthreading to exist can become dedicated to that 1 thread

On the fly

BD needs this!

 

[veri745]

It doesnt make much sense that a chip maker would forgo reverse-HT because it uses too much power, but then turn right around and implement turbo. Duh? If you have one core active processing one thread, you're pulling about 35 watts above idle. Now if you turn on another core and process a 2nd thread, your power generally only goes up by 60%, or 20 watts in my case. I have exact numbers on an E6600 at 3.2GHz. One prime95 thread pulls 35 watts from the wall (above idle). Adding a second thread only adds 20 watts for a total of 55 watts. So we know the max amount of power reverse hyperthreading could ever use (per thread).

To think that some of us wouldnt want to pay that extra penalty for higher performance is ludicrous. Hell yes I would pay an extra 20 watts for 20% more performance. Especially when its just a single thread. Even in the case of an i5-2500k, you could theoretically reverse-HT two threads and run all four cores. I say fire up those idle cores and use them any way possible. I dont care if it only adds 5% I would at least like the option. Again this is where I am really angry at AMD because ATI is not using those idle cores to *somehow* help with minimum framerates.

I have no idea what you're talking about in your example, but the reason a new feature like this would cause a chip to draw more power is that extra transistors would need to be added to implement the feature. If the power cost of those additional transistors outweighs the performance improvement of the feature, then they scrap the idea.

 

[MisterMac]

I have no idea what you're talking about in your example, but the reason a new feature like this would cause a chip to draw more power is that extra transistors would need to be added to implement the feature. If the power cost of those additional transistors outweighs the performance improvement of the feature, then they scrap the idea.

And thus the more cores/resources per chip they blast out, the more interesting it becomes?


It's kinda debatable now that i've thought about it.


In a future sense, more and more applications written will be multithreaded by default (Assuming people use high level languages and/or a standard LIB for C++/C++0x comes out etc).

Therefor something that can split the resources of several cores into one thread becomes less and less significant.


It seems like instead of CMT/SMT - had one of the chipmakers gone this route and made it work, they'd be winning by insane high margins than from SB to BD.


For legacy/simpler programs - a future 16 core monster would make certain things "stupid fast".

I geuss if Anaphase becomes succesfull it's nearly absolete by the time it's 2015-16 - since very few things will not be multi threaded in some way or another.

Even if the threading is coded badly (4 threads, 1 thread does 80% of the workload in the program) - i geuss a reverse HT function is just too little too late now.

Damn it woulda been nice to have from Conroe and onwards!

 

[Denithor]

Actually, isn't it essentially what Intel did with Turbo Boost? When you only need one core, turn off the others and ramp up the speed on that one to gain better single thread performance. You remain within stated TDP and in many cases conserve energy because you aren't just running all four cores constantly when not needed.

 

[Ferzerp]

If we consider this reverse-HT, then in a way the FX-series implements this too


I think the rub is that speculative multithreading just doesn't actually increase performance as much as just boosting clock speed in most real-world applications, at least yet.

Actually, all performance indicators point to it *not* doing that. You have to actually disable to core to get the better performance.

 

[Ben90]

Ivy Bridge employs reverse hyperthreading per se

If you are running a 1-threaded app on a hyperthreaded core in Ivy Bridge

Hyperthreading turns off and all the registers/rename and all those jargon words that allow hyperthreading to exist can become dedicated to that 1 thread

On the fly

That's actually really cool. Intel is onto great things little steps at a time. This technically would be a true reverse hyperthreading. The topic we are talking about should be called something like reverse multithreading or something lol.

 

[IntelUser2000]

To think that some of us wouldnt want to pay that extra penalty for higher performance is ludicrous. Hell yes I would pay an extra 20 watts for 20% more performance.

Maybe YOU would pay for that, but most of Intel's customers wouldn't. This post keeps reminding me AT forums are strictly formed of Desktop, Enthusiast people. I remember reading a thread with someone wanting 200W processors, which isn't realistic, because:

-You want a 200W processor, vendors want it too
-Vendors complain about cooling
-Complaints come back to Intel

Lot of the research work don't come into reality because the benefits aren't worth it rather than not working at all. Maybe we'll see it in a decade when non-overclocked processor speeds reach 5GHz leaving no room for Turbo.

 

[tatertot]

Ivy Bridge employs reverse hyperthreading per se

If you are running a 1-threaded app on a hyperthreaded core in Ivy Bridge

Hyperthreading turns off and all the registers/rename and all those jargon words that allow hyperthreading to exist can become dedicated to that 1 thread

On the fly

Mmmmm... I wouldn't put it quite that way. The difference from SB --> IB is, per Anand:

Some structures within the chip are now better optimized for single threaded execution. Hyper Threading requires a bunch of partitioning of internal structures (e.g. buffers/queues) to allow instructions from multiple threads to use those structures simultaneously. In Sandy Bridge, many of those structures are statically partitioned. If you have a buffer that can hold 20 entries, each thread gets up to 10 entries in the buffer. In the event of a single threaded workload, half of the buffer goes unused. Ivy Bridge reworks a number of these data structures to dynamically allocate resources to threads. Now if there's only a single thread active, these structures will dedicate all resources to servicing that thread. One such example is the DSB queue that serves the uOp cache mentioned above. There's a lookup mechanism for putting uOps into the cache. Those requests are placed into the DSB queue, which used to be split evenly between threads. In Ivy Bridge the DSB queue is allocated dynamically to one or both threads.

I wonder if there are more choices besides 100% to a single thread and 50%-50% between 2 threads... based on actual thread demand? Say one thread really only wants 25% of some internal structure... can the other use 75%? Might involve too much overhead to work that out on the fly with a fast-enough response time.