• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

AMD Reverse Hyper-Threading...

Soldato
Joined
28 Mar 2006
Posts
4,379
Location
Jarrow, Tyne And Wear
right, i was reading something about conroe on another thread and someone mentioned a 'reverse' version of hyper-threading, so i did some looking around on google and came up with a few results, im shocked that nobody has given this any welcome or thought at all, someone even said its pointless, that its a step backwards? i think this reverse HT could be one of the best ideas AMD has had, and im sorry but its far far from a step backwards, example. you and a friend are in class trying to solve a complicated physics calculation do you A) work together as a team and do it much faster and proberbly more accurately or B) one of you do it and the other sit and be a dunce? reverse HT basically intends to do this in a CPU (dual cores to be specific) that a dual core processor (where one core basically does sod all most of the time) could use both cores to run the same processes. sorry folks but thats gonna give an utterly staggering increase in dual-core processor performance in single threaded applications, and theres no reason this applies only to dual-core if you think about it, four processor cores running dual threaded application, two cores doing all the work, not with reverse HT. am i the only person in this entire forum who is interested by this, someone please tell me im not alone?
 
Its already been posted (a few weeks ago) and it got gunned down. Its just smart marketting. The general gist was, with the way operating systems work, its impossible for one thread to be split and then shared. It just wouldnt work - for example, think about a maths problem... often numbers are calculated and then fed into another equation. There is no way something like this can be split up, as the 2nd equation needs to wait for the first.... so whats the benefit of splitting them up?
NathanE, iirc, was the man person slagging it off... his arguements seem to make sense!
 
Hmm interesting - a step towards parallel execution rather than parallel thread execution.

All code can be broken down into code that could be executed in parallel. The crunch comes with register/cache/memory coherience and integrity.

Normally threading is created by either developer design, or by compiler code analysis. On the fly code analysis and execution my not offer as much performance increases as you may think..
 
That quote of being pointless and a step back was probably from me and I still stand by it. I feel there's no real use in this technology except as a proof of concept. Desktop (read: Home) users - 90% don't need that kind of technology. The fact is we are starting to see many new applications which are SMP aware, and those older applications which may be single-threaded or dual-thread aware (HT aware) don't need the performance increase offered by this system. There are always other applications running in the background which can use CPU time and the O/S itself. Due to this, the tech would only ever be any good in a Quad proc/core system where the likely hood of an idle core is greater (e.g in a dual core system, if you run one large application, it's likely the scheduler will move O/S threads and background threads onto the 'free' core hence balance the load. That's a very simple example but is a possible situation). And I dunno how many average users would *need* a quad setup. It would be the workstation users and those users tend to use applications which have been multi-threaded. A bit of a generalisation but I feel a safe one to make.

Also how does the CPU switch between modes? BIOS switch? On the Fly? On the fly would be very difficult indeed and could mean that SMP aware applications become slower due to the overheads of re-arranging of registers and threads when switching from one to the other. BIOS switch would be inconvenient for most users and in that case it would be use one or the other. Hence performance of multi-threaded apps would decrease (although not substantially) which by the time this would be available would account for a large number or even the majority of applications.

It's a good idea, but it's not new and nor would it have a great impact on any desktop users. It does have it's uses but the desktop market isn't one of them.
 
Firstly, Hyperthreading doesn't have anything to do with dual core technology. Hyperthreading was a technology where you had one physical core and one virtual core (at least to the OS). It was created by Intel to solve the problem that at any given time a large amount of the execution hardware in a P4 chip was idle. The 2nd, virtual cpu could then use the idle execution hardware that would otherwise have been sat there doing nothing. For hyperthreading to be used, the OS had to be SMP capable, and it would either be used for load balancing by the OS, or if the program being run was multithreaded, could be used in part as a 2nd cpu as if it was a true SMP system.

Yep, it's time for another one of my links for a much better explaination than I could give...

http://arstechnica.com/articles/paedia/cpu/hyperthreading.ars

Secondly, what you are actually trying to describe is CPU level OOE (out of order execution). It's hard enough to manage at core level, let alone between two cores with any meaningful success. From what I understand it, the basic idea is that AMD think they can run a single thread across the two cores, rather than the current model of multi-threaded programs (the difference between an SMP aware system and one that isn't). There is a reason why single threaded programs can't be spread across two cores, and it's primarily dependancy, but also latancy between the two cores (although hypertransport links between the two do go a little way to eliminating this). In-core communication is much, much quicker than cross-core communication, even when both cores are on the same piece of silicon.

I can't see this providing much benefit for the desktop market (as Dunky said), and I also (sadly) haven't seen much information about it on good technical sites to try and see how they could do it. The only way I could think would be to effectively raise the scheduling hardware up a level, and have Re-order buffers on the entry and exit from both cores, in addition to having them internally to each core....
 
I cannot see how this will properly come off but if they succeed it would be a good thing IMO

If it does not adversly affect multi-threaded performance but improves single threaded performance then this will help to overcome one of the disadvantages of dual core processors
 
ajgoodfellow said:
I cannot see how this will properly come off but if they succeed it would be a good thing IMO

If it does not adversly affect multi-threaded performance but improves single threaded performance then this will help to overcome one of the disadvantages of dual core processors
I agree :D
 
thats totally what i was thinking, running single threaded applications through two cores would (in a perfect world) divide the workload evenly between the two cores, meaning you could get 100% increase in single threaded performance. that only works if you can successfully split the thread into two equal parts and process them and combine what comes out the other end, without harming the ability to do the exact same with multi-threaded apps. another thing is such technology might be able to work for more than just two cores, imagine how fast a quad core processor would run a single threaded app if the load could be shared equally amongst the four cores, this for me is the single thing making me personally not bother with a dual core processor at this time, since most apps are still single threaded, a single core processor runs things just as well as a dual. only because the other core is being wasted running background applications, AMD have this reverse HT, and intel have something called 'mitosis' i believe, i don't see hows its impossible, tricky but plausable IMO. i really hope intel or AMD can pull this off sooner rather than later and get it out to the market, the performance increase would be staggering if it worked as intended
 
Where's NathanE when you need him.....

NathanE said:
Register to register, definately no.

You can however have a "multi-core aware" pipeline. So instead of a pipeline job only being limited to the core it was started on, it can also wait for a pipeline slot on the other core(s). This is what AMD is talking about when they say "inverse of Hyperthreading".

The Hyperthreading present on P4's simply exposes a virtual core to the operating system. The operating then schedules threads to this virtual core and the P4 can then better keep its large pipeline filled with the work of two threads.

It certainly is a promising technology. But it is being way overexaggerated by news sites and discussion forums, for the simple reason that only a limited selection of instructions can be parallelised. I would also not be surprised at all if Conroe has this inside it already. Intel let it slip a while ago that NGMA does actually have a "form of Hyperthreading" but that it was disabled for the time being. Hyperthreading technologies (especially those that span multiple cores such as AMD's) are notoriously difficult to test and validate which is why Intel disables the functionality in the first revisions of its chips.

I really hate the wording "anti-Hyperthreading", it makes no sense. If anything this is simply Hyperthreading Version 2.0, for a multi-core world.
 
#I am not doubting the technical know how of people around here, I am sure some of you are very clever indeed - but IF the report is correct and AMD are actually working on something along these lines ( the report could be fundamentally wrong, or AMD want to keep a new development secret so they publish something to lead away from it....?) but IF AMD are working on this, and IF its been worked on long enough to report on then I wouldnt be surprised if it works better on some level, after all the actual technical abilities of AMD and Intel in the relatively few reallly top CPU designers you can probably count on two hands in the whole world - maybe not that different from gpu design or motorsport design like Adrian Newey or Mike Gascoigne

Maybe its complete hogwash I have no idea, but AMD have to pull out something major pretty soon, and they probably know it as well as we do
 
Back
Top Bottom