message
| Name: | unknown |
| Date: | June 17, 2003 at 15:11:17 |
| Subject: | Re: Hyperthreading and 'lock' prefix |
| In Reply To: | Re: Hyperthreading and 'lock' prefix by Stephan Keil on June 10, 2003 at 10:25:22 |
| Text: | || You are sure it doesn't pick and choses from a random stream of microcode instructions to fill all available execution units? I suspect the dispatcher doesn't much care which thread it comes from, at that level it's probably transparent. || | | I am not sure, but for a single processor (at least for the x86-familiy), | each instruction is executed as if it the instruction stream were | sequential and each instruction were atomic, although the instructions | might be executed out of order and each instruction might be executed | in multiple steps. If the dispatcher doesn't care about threads but sees | a single instruction stream: fine, then it guarantees that each instruction | is executed atomically :) Does it see your instruction stream or microcode from the trace cache? I doubt it's as Von Neumann as you paint it. And even if Intel builds it one way today, what's to stop them or AMD changing the architecture in the future? Consider Thread A Thread B OR [mem],imm - > load mem to temp, temp = temp | imm, store temp to mem And that foo is not in the cache, both would stall. Which would proceed once the load occured, both or just one. Which would win the store operation? This kind of code would cause problems on a DP system. The whole point of HT is to increase the execution unit utilization, and to allow the addition of more units which would otherwise go unused because a single code stream has insuffient parallelism. |
post a followup message
(Be nice... or be blocked. Be technical... or be erased.)
currently posted followup messages
(You may have to press the RELOAD button of your browser.)
|
|
