Welcome to Reverse HT for AM2 soon?

brighton said:
ps - not sure if this was posted already
Click to expand...


Well that Inq article is new so "no" it hasn't been posted yet...but the news of AMD'd anti-ht tech is known. But what is new to me is that this anti-ht tech is in ALL of Amd's new AM2 socket cpu's...the general concensus was that it was at least a year off. But this is the Inq and they can post whatever they want.
 
From another thread I just copied it .

$BangforThe$ [H]ard|Gawd

http://www.theinquirer.net/?article=32589

Well if this RH/T is true for older games that are single threaded AMD may have the edge . At least untill Intel does the same thing . Fact is we don't know if Intel has done something in this area already. It is said that Conroe has built in HT. So I suppose that Intel would have given this some thought befor this came up. When I heard about dual core cpu's my first thought was will they work together as one CPU.

Now if Intel ignored this or even worse if they didn't think of it . I would be firing a few people at the top of the food chain. Either way If AMD has implemented this successfully a big thumds up to them.

We also know Intel has a working compiler as they ran it on the Olden benchmark suite

NOW this is meant as a joke so please take it as such.

I hope AMD doesn't use the terms reverse hyper threading or anything like Ant-hyperthreading to describe this tech. Hyper threading would be ok to describe it . Reverse Hyper threading would mean To Little/ Not Enough. If it isn't implemented well enough to beat Conroe . RH/T would be flamed as to little to late. Us forum members don't need any more ammo to feed the flames thats for sure. Intels orginal use of the hyper threading really was a bad choice to describe dual threading. If AMD can pull this off it is more fit to be called H/T than Intels H/T in as far as describing the literal meaning of Hyper.

Just for the record Intels name for RH/T that they have been working on is called Mitosis


http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm


One thing really great about Intel .Even though they haven't announced this TecH . I know more about it on the Intel side . Than I do about it on the AMD side . This is not a good thing if the rumored AMD RH/T thing is true. So all and all I guess we have to wait and see what intel does . and who makes the better compiler.

We do know that Intel has a working compiler as it was tested using the Olden benchmark suite

Mitosis cell division: the process by which a cell divides into two daughter cells,
 
Yeah there are so many new news coming out from AMD side. I will wait and see the real things, when it come out.
 
BigwaveDave said:
Very exciting for us AMD enthusiasts for sure.
Click to expand...
It *will* be exciting when it's released, but that's about 2 years away. Reverse HT is a "post K8" feature. overclockers.ru is getting a lot of mileage out of their rumor to the contrary.
 
"AMD did not comment on the news-story."

'nuff said. Until we get a confirm from AMD, I wouldn 't take this too seriously.
 
I really don't understand how RH/T will work without a new compiler installed in the core.

Intels Mitosis is a hardware designed with a specific compiler to do the work. Unless AMD is some how doing it with the new Memory controller in AM2 in which case its possiable quick fix . Still it seems to me to many misses for this to work correctly.How can they get the predictions correct without a compiler.
 
$BangforThe$ said:
I really don't understand how RH/T will work without a new compiler installed in the core.
Click to expand...

Well there is -for example- a brute force approach to branch prediction: Instead of just predicting, you compute what you think the most likely next instruction would be. Probably not very efficient, not elegant at all, but should work solely in hardware.

In the end, engineers at AMD and Intel are paid to do exactly one thing: solve problems. I am sure that there are people at both Intel and AMD that know an aweful lot more about building a microprocessor than anyone on this forum. So just because you or I cannot come up with a way of how to solve the "2 cores, 1 thread/ process, make it go faster" problem, doesn't mean that someone at either or both companies has come up with a way to do it.
 
Yeah, thread level parallelism done in software (compilers) would work on any dual CPU or dual core. And if future NGMA processors have the hardware modifications described below, Intel might be the first to support accelerated TLP (the current Bad Axe BIOS has a new "Core Multiplexing" option).

TR has an overview here: http://techreport.com/etc/2005q3/idf/index.x?pg=4

The hardware component of Mitosis is a CPU microarchitecture modified with the addition of a global register file, a register versioning table, and some version control logic to manage the execution of parallel threads that wish to modify the same registers.
Click to expand...
 
Actually I read about intels Mitosis and it looks very promising with exspected 2x performance. and if you read the link a compiler is needed in order to hit or miss the Branch prediction. Its to bad that AMD doesn't keep the public informed . The fact they have no comments on the rumors is also a bit disheartening as it could mean its all rumors or they are not very good at marketing. It is being stated that all present AM2 cores have this function they should be advertizing it NOW. Instead of waiting. Or are they afraid the Intels rumored H/T on Conroe is really Mitosis.
 
I might be incorrect but didn't p4 with netburst has this? I mean their pipeline is so deep that they can just go ahead and start execution of the next instructions. Acutally I think it does start the next instruction and the instruction can be stalled in pipeline waiting for data to be available. AMD can take this further by having two or more dependent instructions executing in both cores and an instruction can stall in one core waiting for data available from either the other core or from its own pipeline.

What I see AMD doing is to use the integrated memory controller as a pre-prefatch, but that would require something simuliar to L2 or L3 cashe for prefatch cashe on die. Or a more feasible solution is to use it as a L1 or L2 data controller between the two or more cores.
 
It seems AMD solution doesn´t need compiler at all. It would work with any single thread app existing right now.
Perhaps it is some pacifica virtualization feature
 
scout007 said:
I might be incorrect but didn't p4 with netburst has this? I mean their pipeline is so deep that they can just go ahead and start execution of the next instructions. Acutally I think it does start the next instruction and the instruction can be stalled in pipeline waiting for data to be available. AMD can take this further by having two or more dependent instructions executing in both cores and an instruction can stall in one core waiting for data available from either the other core or from its own pipeline.

What I see AMD doing is to use the integrated memory controller as a pre-prefatch, but that would require something simuliar to L2 or L3 cashe for prefatch cashe on die.
Click to expand...

Even the ATI memory controller requires a compiler. I am guessing but I believe this is what all the Huff N Puff was about the AMD buy out of ATI. Either way this all leads back to Rambus . As ATI AMD and Intel are Rambus licensed
 
scout007 said:
I might be incorrect but didn't p4 with netburst has this? I mean their pipeline is so deep that they can just go ahead and start execution of the next instructions. Acutally I think it does start the next instruction and the instruction can be stalled in pipeline waiting for data to be available..
Click to expand...
Yeah, lots of x86 CPUs since the Pentium II have supported speculative execution. Branch prediction was in the Pentium I. Pipelining allows instructions to started at each clock and executed at different pipeline stages before the first is retired and that's from the 386 era I believe (the 286 had address pipelining).

But there's still a limit on parallelization since the code is still running on the same core.

IMO, AMD will have a software assisted TLP similar to Mitosis before a transparent hardware implementation. And neither is coming out next month. :p
 
$BangforThe$ said:
If that were the case there would be to many prediction misses for it to work effectively.
Click to expand...

actually it would improve on missed prediction prefetch, but would increase the clock penality for missed prediction.
 
drizzt81 said:
Well there is -for example- a brute force approach to branch prediction: Instead of just predicting, you compute what you think the most likely next instruction would be. Probably not very efficient, not elegant at all, but should work solely in hardware.
Click to expand...

That is predication :rolleyes:

Anyway , I think this whole reverse HT thing is a big pile of BS until the arrivel of more tightly coupled cores.Havind 2 cores on a die which talk to each other over a crossbar would be a syncronization nightmare for a single thread.But , hey , like another guy said , I wish AMD to spend all their money and time with "brilliant" ideas like this one.
 
I think the smartest thing would be to wait about 4 weeks and see what AMD is really going to do, before throwing out the usual high-and-mighty "I predict that their company only has crap and that my company will blow them out of the water" garbage that has been spewn all over these forums recently.

The point of the thread was to make known that the Inq posted a story about AMD's possible launch of "something" to enable what most people are currently calling reverse hyperthreading. Now I see arguments about Rambust, what Intel does or does not have implemented and how AMD could never in 5 million years pull this off. What ever happend to the basic "I'll believe it when I see it" posts that used to be commonplace before f-boys came up and needed to prove their point based on spotty information and google?



so let me get all of your started:

"I will believe it, when I see it. If the benchmarks make it look valuable, it will affect my purchasing decision at that point"
 
savantu said:
That is predication :rolleyes:
Click to expand...
when you put a word in boldface, you should really, really make sure that it's spelled correctly, otherwise you make yourself look like a fool.
now for branch prediction:

http://www.x86.org/articles/branch/branchprediction.htm

What is branch prediction?

Imagine a simple microprocessor where all instructions are handled in two steps: decoding and execution. The microprocessor can save time by decoding one instruction while the preceding instruction is executing. This assembly line-principle is called pipelining. In advanced microprocessors, the pipeline may have many steps so that many consecutive instructions are underway in the assembly line at the same time, one at each stage in the pipeline.

The problem now occurs when we meet a branch instruction. A branch instruction is the implementation of an if-then-else construct. If a condition is true then jump to some other location; if false then continue with the next instruction. This gives a break in the flow of instructions through the pipeline because the processor doesn't know which instruction comes next until it has finished executing the branch instruction. The longer the pipeline, the longer time it will have to wait until it knows which instruction to feed next into the pipeline. As modern microprocessors tend to have longer and longer pipelines, there has been a growing need for doing something about this problem.

The solution is branch prediction. The microprocessor tries to predict whether the branch instruction will jump or not, based on a record of what this branch has done previously. If it has jumped the last four times then chances are high that it will also jump this time. The microprocessor decides which instruction to load next into the pipeline based on this prediction, before it knows for sure. This is called speculative execution. If the prediction turns out to be wrong, then it has to flush the pipeline and discard all calculations that were based on this prediction. But if the prediction was correct, then it has saved a lot of time.
Click to expand...
If you read that article carefully, you note that there is the possiblity of a pipeline stall. My point was that instead of "predicting a branch" core 1 loads option "jump" core 2 loads option "no jump" and both execute these at the same time. One of them will be wrong, one of them will be true, depending on how well this is implemented, the penalty may decrease from an incorrect prediction.

Now it's possibly that ILP already takes care of that. However, I never said that this was the way that AMD is doing things, I just showed an option of what could be done; Whether or not it has been done is a different story. The main point of my post was: Just because $Bft$, you or I cannot image how it's done, doesn't mean that it cannot be done. Then again I may be expecting too much in terms of common sense from people.
 
Well, here's another prediction: AMD waits until the week for July 24th, then releases the drivers necessary to enable the so called "reverse HT". With the new feature, AMD then trails Conroe by only a small margin but is still not able to make-up the gap. And then the price cut hits on July 24th. At that point AMD may be slower than Conroe by 5-10% clock for clock, but then has a significant price advantage.

All of that was in theory of course. It'd be interesting if something like that actually happened. :D
 
drizzt81 said:
when you put a word in boldface, you should really, really make sure that it's spelled correctly, otherwise you make yourself look like a fool.
Click to expand...

A bigger fool is one who jumps on grammar stuff instead of attacking the argument when it is blatantly obvious what the original poster meant. ;)

PS : what is actually wrong with the word "predication" ? As a non-nativ E speaker , I've come across the term dozens of times in technical pdfs.

Addendum : now that you explained your position , you can easily see that I wasn't wrong...;)

You've said " you compute what you think the most likely next instruction would be." which is actually different than branch prediction.It borders predication and speculation in the HW.

Take a look : predication
 
maverick777 said:
Well, here's another prediction: AMD waits until the week for July 24th, then releases the drivers necessary to enable the so called "reverse HT". With the new feature, AMD then trails Conroe by only a small margin but is still not able to make-up the gap. And then the price cut hits on July 24th. At that point AMD may be slower than Conroe by 5-10% clock for clock, but then has a significant price advantage.

All of that was in theory of course. It'd be interesting if something like that actually happened. :D
Click to expand...


Lol what drivers? There is nothing of this sort even planned or created.
 
The problem with Intel zealots is that this comes from AMD, and for this reason it is impossible, BS and so on
bah
 
VanFanel89 said:
Lol what drivers? There is nothing of this sort even planned or created.
Click to expand...

Umm...they are.You need a driver for it to work and an Windows patch. ( if the thing really exists )

Arvidas said:
The problem with Intel zealots is that this comes from AMD, and for this reason it is impossible, BS and so on
bah
Click to expand...

Really ? Because compared to bashing Conroe , this is truly worth questioning.
 
savantu said:
Take a look : predication
Click to expand...
point taken. I am so used to guessing what a certain poster is trying to say that I was unaware of what predication is. Yes, what I described is predication. And since Intel has considered doing it, it must not be a bad idea, right? :p
 
Yes its is the inquirer. It may be true it may not be. I however found most of this thread really interesting . PXC had some good comments and a great link . It was also good to learn a little more about AMD's RH/T and many I am sure heard about Mitosis for the first time. So all and All I would say the OP got a good deal of information from his Inquirer link.
 
Arvidas said:
The problem with Intel zealots is that this comes from AMD, and for this reason it is impossible, BS and so on
bah
Click to expand...
No, it's fairly certain that both AMD and Intel will have TLP support in future chips. Intel presented it at IDF last August and AMD's "reverse HyperThreading" was first leaked in April this year at x86-secret (as a K10 feature). Since then, it's been rumored into a 4x4 and AM2 "fact", and even more silly into a "driver and windows patch" coming next month.

The fact is AMD has never announced it, shown it, presented it or even casually mentioned it. There's not even a name for it yet.

Will we see it? Very likely yes. This year? Not from AMD and probably not from Intel either.
 
pxc said:
No, it's fairly certain that both AMD and Intel will have TLP support in future chips.
Click to expand...

Umhh...TLP is the whole reason behind SMT (or HT) .Intel has HT since November 2002. ;)
 
drizzt81 said:
when you put a word in boldface, you should really, really make sure that it's spelled correctly, otherwise you make yourself look like a fool.
now for branch prediction:

http://www.x86.org/articles/branch/branchprediction.htm


If you read that article carefully, you note that there is the possiblity of a pipeline stall. My point was that instead of "predicting a branch" core 1 loads option "jump" core 2 loads option "no jump" and both execute these at the same time. One of them will be wrong, one of them will be true, depending on how well this is implemented, the penalty may decrease from an incorrect prediction.

Now it's possibly that ILP already takes care of that. However, I never said that this was the way that AMD is doing things, I just showed an option of what could be done; Whether or not it has been done is a different story. The main point of my post was: Just because $Bft$, you or I cannot image how it's done, doesn't mean that it cannot be done. Then again I may be expecting too much in terms of common sense from people.
Click to expand...

Why do you see the need to add things like your last sentence in a thread . Come on this was all interesting stuff. I personally thought it was time both sides of the forum new about Mitosis. Its not like the sleeping giant to wake up than take a snooze.
 
There are no drivers planned or planned to be released for this anti-hyper threading BS.
 
savantu said:
Umhh...TLP is the whole reason behind SMT (or HT) .Intel has HT since November 2002. ;)
Click to expand...
I should have used "TLP/ST." :p I meant it within the context of this sub-discussion (Intel Mitosis since nothing is known about AMD's RHT).

A single thread is not split between 2 logical cores with HT. A single thread only runs on one logical core. With TLP/ST and the appropriate communication/coherency between the cores, execution of a single thread can be split between more than 1 core. The benchmarks Intel showed for certain code was impressive (pointer intensive Olden benchmarks), up to a 3x improvement.
 
drizzt81 said:
point taken. I am so used to guessing what a certain poster is trying to say that I was unaware of what predication is. Yes, what I described is predication. And since Intel has considered doing it, it must not be a bad idea, right? :p
Click to expand...

I would guess I am that certain poster. HAY I resemble that remark ! LOL Rabbits resemble hares but are smaller. LOL
 
You must log in or register to reply here.
Back
Top