Improve i7 single threaded performance?

[Tom B]

I'm running an old CPU intensive game which doesn't support multi-core systems. The performance on my i7 is pretty poor as it's maxing out 1 of the 8 cores and the rest are idle.

Is there any way to improve this performance? Can't I get the i7 to register as 4 cores instead of 8 and essentially double the performance in this game? the i7 is quad core, not 8 core after all!

Thanks!

 

[drescherjm]

If you are not overclocking do so. This is very very easy on an i7 processor. Start off by raising the BCLK a few MHz. If you have an i7 920 set the BCLK to 150 instead of 133 for 3.0GHz instead of 2.66 GHz.

Well unless you have a premade system that locks the bios down to prevent you from overclocking.

 

[drescherjm]

Can't I get the i7 to register as 4 cores instead of 8 and essentially double the performance in this game? the i7 is quad core, not 8 core after all!

Thanks!

Disable HyperThreading (HT) in your bios. No that will not give you 2 times the performance. You will be luckly to get 10% more performance. The i7 cores are designed (with extra circuitry) so that HT does not cut the performance down like this.

 

[drescherjm]

Also are you sure your GPU is not causing the problem? The lowest i7 processor is still pretty high end at this time (compared to AMD).

 

[Tudz]

Disable HyperThreading (HT) in your bios. No that will not give you 2 times the performance. You will be luckly to get 10% more performance. The i7 cores are designed (with extra circuitry) so that HT does not cut the performance down like this.

I've used a program where it did cut performance by almost half. Instead of using 25% it sat at 12% CPU usage. Dunno if that applies to any sort of games though.

Disable hyperthreading in the BIOS and see how you go.

 

[Tom B]

Well the game (Carmageddon 1!) itself is running through DosBox, so it's not using hardware acceleration and the performance is all down to the CPU. I'm never seeing over 15% total CPU usage, but the core it's using is always maxed. In theory at least, having it max at 25% instead of 12.5% should be a significant performance boost.

I'll also try overclocking. Not sure though my temps seem a bit high already, 35-40Cidle, ~55-60C load. I'm on a 920 using a Corsair H50-1

edit: Also my GPU is a 5870 so it should be fine for a game from 1997 but it's irrelevant as it's all CPU driven.

 

[chinesepiratefood]

Well the game (Carmageddon 1!) itself is running through DosBox, so it's not using hardware acceleration and the performance is all down to the CPU. I'm never seeing over 15% total CPU usage, but the core it's using is always maxed. In theory at least, having it max at 25% instead of 12.5% should be a significant performance boost.

I'll also try overclocking. Not sure though my temps seem a bit high already, 35-40Cidle, ~55-60C load. I'm on a 920 using a Corsair H50-1

edit: Also my GPU is a 5870 so it should be fine for a game from 1997 but it's irrelevant as it's all CPU driven.

Thats not how it works. Yes, if you disable HT it will show 25% instead of 12.5% but they MEAN the exact same thing, that 1 core is utilized to 100%, and the rest are idle. There is absolutely no difference in performance between the two.

 

[drescherjm]

Yes, if you disable HT it will show 25% instead of 12.5% but they MEAN the exact same thing, that 1 core is utilized to 100%, and the rest are idle.

Agreed. 25% of 4 cores is the same as 12.5% of 8 cores.

 

[Tom B]

I don't understand that.

There are 4 physical cores, HT makes it show 8, but if what you suggest were true, then I would be seeing load on 2 logical cores, wouldn't I?

 

[drescherjm]

In windows task manager physical or virtual cores are counted the same.

I would be seeing load on 2 logical cores, wouldn't I?

No. The program only uses 1 thread.

 

[MrWizard6600]

I've used a program where it did cut performance by almost half. Instead of using 25% it sat at 12% CPU usage. Dunno if that applies to any sort of games though.

Disable hyperthreading in the BIOS and see how you go.

No way... I mean from what I know about hyper threading that's simply not possible... Or I mean I guess it is, but I mean that would require that the OS was treating your thread like crap and intel's send-the-HT-provided-extra-thread-to-the-other-core algorithm to be seriously out to lunch.

What program and what CPU?

 

[drescherjm]

Delete.

 

[Tudz]

No way... I mean from what I know about hyper threading that's simply not possible... Or I mean I guess it is, but I mean that would require that the OS was treating your thread like crap and intel's send-the-HT-provided-extra-thread-to-the-other-core algorithm to be seriously out to lunch.

What program and what CPU?

Ansys 12.1 on 64 bit Windows 7 with a mildly overclocked i7 920.

Some tasks in the program are single threaded, others you specify the number of threads. The ones which are single threaded are painfully slow with HT on.

Agreed. 25% of 4 cores is the same as 12.5% of 8 cores.

Say wha? That doesn't make sense to me. The % is the average over all threads. Either way the HT i7 920 is painfully slow, but maybe its from another cause other than HT (as its also using 6 to 12gb ram, so maybe the problem lies elsewhere).

 

[W.Feather]

Say wha? That doesn't make sense to me. The % is the average over all threads. Either way the HT i7 920 is painfully slow, but maybe its from another cause other than HT (as its also using 6 to 12gb ram, so maybe the problem lies elsewhere).

1/4 = 25% for no ht
1/8 = 12.5% with ht on the i7

regardless one core is being used

 

[drescherjm]

Either way the HT i7 920 is painfully slow, but maybe its from another cause other than HT (as its also using 6 to 12gb ram, so maybe the problem lies elsewhere).

Neither HT or 6/12 GB of ram will make your i7 920 operate slowly. Something else is the cause.

 

[Tom B]

So you're essentially saying that HT doubles the speed of the processor?

Look at it this way: if 8 cores are at 100%, all at 2.66 ghz then the cpu is doing twice as many calculations as it would with HT off?

That seems like a huge--and unlikely--performance boost.

 

[Tudz]

1/4 = 25% for no ht
1/8 = 12.5% with ht on the i7

regardless one core is being used

I'm not saying you're lying because I'll admit I dont know a lot about it... but then what if you're running with HT on and running a 4 threaded program? It'll be running at a displayed 50%... so you're saying it'll be running the same speed as 4 threads with HT off. So then the exact same program you tell it to run 8 threads with HT on, the task manager now tells you you're using 100%... but you're still only using 4 cores (4 real cores and 4 virtual ones).

So if you're running a number crunching program which has the option of running more threads, but scales linearly with number of threads and is fully capable of running each thread at 100%, what you're saying is running 4 threads with HT on will be similar performance to running 8 threads with HT on... because you're still maxing 4 cores at 100% either way...

I'm tempted to go to uni tomorrow (saturday) to do some number crunching and prove you either right or wrong, lol.

 

[Tudz]

So you're essentially saying that HT doubles the speed of the processor?

Look at it this way: if 8 cores are at 100%, all at 2.66 ghz then the cpu is doing twice as many calculations as it would with HT off?

That seems like a huge--and unlikely--performance boost.

I know that's untrue... the i7 920 running 3.3GHz is only a few percent (<10%) faster than my i5 750 at the same speed, and I tend to attribute that to the triple channel memory given the huge memory usage of the programs.

 

[drescherjm]

So you're essentially saying that HT doubles the speed of the processor?

Look at it this way: if 8 cores are at 100%, all at 2.66 ghz then the cpu is doing twice as many calculations as it would with HT off?

That seems like a huge--and unlikely--performance boost.

No. The virtual cores amount to about 35% of a core each maximum. When making use of these virtual cores the real cores may take a 10% hit.

Windows is aware of what cores are real and virtual so if you are using 4 or less threads running they will all be running on real cores and without the virtual cores doing anything the hit will be less than 10%.

 

[Tudz]

No. The virtual cores amount to about 35% of a core each maximum. When making use of these virtual cores the real cores may take a 10% hit.

Windows is aware of what cores are real and virtual so if you are using 4 or less threads running they will all be running on real cores and without the virtual cores doing anything the hit will be less than 10%.

So you're saying if you're using a program where threaded scaling is slightly less than linear, you're better off running 4 threads than 8, but leaving HT on still?

 

[W.Feather]

I'm not saying you're lying because I'll admit I dont know a lot about it... but then what if you're running with HT on and running a 4 threaded program? It'll be running at a displayed 50%... so you're saying it'll be running the same speed as 4 threads with HT off. So then the exact same program you tell it to run 8 threads with HT on, the task manager now tells you you're using 100%... but you're still only using 4 cores (4 real cores and 4 virtual ones).

So if you're running a number crunching program which has the option of running more threads, but scales linearly with number of threads and is fully capable of running each thread at 100%, what you're saying is running 4 threads with HT on will be similar performance to running 8 threads with HT on... because you're still maxing 4 cores at 100% either way...

to the 1st paragraph-
yes, it is 50% of the available CPU being used(4 of 8 threads), so if you turn off HT your down to 4 threads, and therefor 100% usage of the CPU. your performance with 8 threads will b e higher than that of 4 threads, and yes technically still using 4 cores, it is "seeing" 8 cores, so you would be at 100% for the CPU(with HT on)

2nd paragraph- no, performance will be better with 8 threads(assuming it uses all 8 efficiently), because what its doing is taking the four cores and pushing it farther, each core is being more fully utilized, and so you get quicker work. So no, i'm not saying that performance would be the same with or without HT in a multi threaded program.


my 1st post was quickly written on my tablet with my pen input, so i didnt go into detail, just simple math(i did it during the end of calc)......

this is all based off of my small understanding of how HT works, so please do correct me if i'm wrong.

 

[Tudz]

Ok well I went in to uni today to test this. I ran a small fluids simulation, it consumes about 3gb of ram to run and will max a CPU to 100% (with occasional drop to 90% every few seconds). I couldn't try with turning HT off as I dont have BIOS access, but ran the exact same sim on my i5 750 at home. Both CPUs have a reasonable overclock.

The results...

i5 750
Threads - Time/iteration (seconds)
1 - 210
2 - 123
3 - 103
4 - 96

i7 920
Threads - Speed (seconds) - CPU % in Task manager (HT on for all sims)
1 - 265 - 12%
2 - 231 - 25%
3 - 177 - 38%
4 - 144 - 50%
5 - 104 - 62%
6 - 93 - 75%
7 - 87 - 87%
8 - 85 - 100ish%

So 1 thread on the i7 920 with HT on is no where near as fast as an i5 750. Even 2 threads its not as fast as a single i5 thread (scaling with threads is not linear, the more threads you have the more the ram and QPI speeds start affecting the results).

From what you guys were saying if you ran 4 threads it should be using the 4 real cores for not much performance loss... but its actually running far slower than the same 4 threads on the i5.

Its only using the full 6 or more threads (and CPU usage at 75-100%) that it actually gets any faster than the i5 using only 4 threads.

I would like to see if running with HT off makes a single thread on the i7 920 faster than a single thread on the i5 750, but I dont have BIOS access to the computer. The i7 obviously has an advantage of triple channel ram.

In conclusion if you have a single threaded application and it runs poorly on an i7, try turning HT off

EDIT: Just FYI, the i5 750 was actually running other applications at the same time like listening to music and browsing the web which may have slowed it down a bit, and the OS used in both cases was 64 bit Windows 7. The i7 was running 12gb of 1600MHz ram and the i5 8gb of 1600MHz ram.

 

[cyclone3d]

Ok well I went in to uni today to test this. I ran a small fluids simulation, it consumes about 3gb of ram to run and will max a CPU to 100% (with occasional drop to 90% every few seconds). I couldn't try with turning HT off as I dont have BIOS access, but ran the exact same sim on my i5 750 at home. Both CPUs have a reasonable overclock.

The results...

i5 750
Threads - Time/iteration (seconds)
1 - 210
2 - 123
3 - 103
4 - 96

i7 920
Threads - Speed (seconds) - CPU % in Task manager (HT on for all sims)
1 - 265 - 12%
2 - 231 - 25%
3 - 177 - 38%
4 - 144 - 50%
5 - 104 - 62%
6 - 93 - 75%
7 - 87 - 87%
8 - 85 - 100ish%

So 1 thread on the i7 920 with HT on is no where near as fast as an i5 750. Even 2 threads its not as fast as a single i5 thread (scaling with threads is not linear, the more threads you have the more the ram and QPI speeds start affecting the results).

From what you guys were saying if you ran 4 threads it should be using the 4 real cores for not much performance loss... but its actually running far slower than the same 4 threads on the i5.

Its only using the full 6 or more threads (and CPU usage at 75-100%) that it actually gets any faster than the i5 using only 4 threads.

I would like to see if running with HT off makes a single thread on the i7 920 faster than a single thread on the i5 750, but I dont have BIOS access to the computer. The i7 obviously has an advantage of triple channel ram.

In conclusion if you have a single threaded application and it runs poorly on an i7, try turning HT off

EDIT: Just FYI, the i5 750 was actually running other applications at the same time like listening to music and browsing the web which may have slowed it down a bit, and the OS used in both cases was 64 bit Windows 7. The i7 was running 12gb of 1600MHz ram and the i5 8gb of 1600MHz ram.

What about using the task manager to set the affinity for uni(what is uni anyway?).

Your findings are very interesting to say the least.

Could part of the reason what is happening be because HT is sharing the cache on the processor? Maybe it is causing a whole bunch of cache misses and having to go to main memory to fetch data more often?

It could also be a problem with how Windows 7 has certain thread handling issues. You can always try turning off core parking if you have access on the i7 system... You may want to try it on the i5 as well to see if it makes any difference.

http://forum.cakewalk.com/tm.aspx?m=1861804

edit: you may especially want to look at the bottom of that thread where the person says how to unhide all the settings. I just did.. and WOW.. there are a ton of settings having to do with the processor that aren't there by default.

 

[drescherjm]

Ok well I went in to uni today to test this. I ran a small fluids simulation, it consumes about 3gb of ram to run and will max a CPU to 100% (with occasional drop to 90% every few seconds). I couldn't try with turning HT off as I dont have BIOS access, but ran the exact same sim on my i5 750 at home. Both CPUs have a reasonable overclock.

The results...

i5 750
Threads - Time/iteration (seconds)
1 - 210
2 - 123
3 - 103
4 - 96

i7 920
Threads - Speed (seconds) - CPU % in Task manager (HT on for all sims)
1 - 265 - 12%
2 - 231 - 25%
3 - 177 - 38%
4 - 144 - 50%
5 - 104 - 62%
6 - 93 - 75%
7 - 87 - 87%
8 - 85 - 100ish%

So 1 thread on the i7 920 with HT on is no where near as fast as an i5 750. Even 2 threads its not as fast as a single i5 thread (scaling with threads is not linear, the more threads you have the more the ram and QPI speeds start affecting the results).

From what you guys were saying if you ran 4 threads it should be using the 4 real cores for not much performance loss... but its actually running far slower than the same 4 threads on the i5.

Its only using the full 6 or more threads (and CPU usage at 75-100%) that it actually gets any faster than the i5 using only 4 threads.

I would like to see if running with HT off makes a single thread on the i7 920 faster than a single thread on the i5 750, but I dont have BIOS access to the computer. The i7 obviously has an advantage of triple channel ram.

In conclusion if you have a single threaded application and it runs poorly on an i7, try turning HT off

EDIT: Just FYI, the i5 750 was actually running other applications at the same time like listening to music and browsing the web which may have slowed it down a bit, and the OS used in both cases was 64 bit Windows 7. The i7 was running 12gb of 1600MHz ram and the i5 8gb of 1600MHz ram.

Not that this explains everything but the i7 920 has a lesser turbo boost than the i5. 22 instead of 24 in the 2 or less threads case.

 

[Tudz]

Not that this explains everything but the i7 920 has a lesser turbo boost than the i5. 22 instead of 24 in the 2 or less threads case.

Both CPUs are overclocked to a similar frequency and the i5 has turbo boost turned off.

Either way I think its worth at least testing with HT off if you're getting poor single threaded performance

 

[devil22]

HTT just uses idle execution units (for instance if the cpu is stalled waiting on a RAM access) for the virtual cores (vs. physical cores), it may improve performance slightly on single threaded or programs that use no more threads than there are physical cores if you disable it but the difference would probably not even be 10% (and that much only in extreme cases), and it gives a much larger boost when using more threads than physical cores. But go ahead and benchmark with and without HTT, in Win 7 I doubt you'll see any difference on single threaded apps/games, but you should benchmark the same system to remove the effect of non-relevant differences between the system configurations.

You should not go by Windows task manager, which shows virtual cores as equal to physical cores, to say things like HTT cuts single core performance in half, or doubles multithreaded performance because that is not how it works.

 

[Tudz]

You should not go by Windows task manager, which shows virtual cores as equal to physical cores, to say things like HTT cuts single core performance in half, or doubles multithreaded performance because that is not how it works.

Actually, task manager gave a surprisingly accurate judge of speed for the HT CPU. If you plot the speed of the simulation (in iterations per second, rather than seconds per iteration) you get something that doesn't have a terrible curve fit with what task manager's CPU % was. Not a brilliant curve fit, but close enough for me to call it representative.

When I get access to the BIOS of a reasonably fast HT CPU I'll run the benchmarks again, but that might not be for a while.

 

[TheSpoon]

These findings are actually consistent with published results: http://www.anandtech.com/bench/Product/47?vs=109

i5 750 > i7 920 when only one thread is involved (look for the two Cinebench R10 scores).

 

[Cali3350]

Is it worth using 4.2 ghz HT off as opposed to my current 4.0 Ghz HT on...

 

[devil22]

Actually, task manager gave a surprisingly accurate judge of speed for the HT CPU. If you plot the speed of the simulation (in iterations per second, rather than seconds per iteration) you get something that doesn't have a terrible curve fit with what task manager's CPU % was. Not a brilliant curve fit, but close enough for me to call it representative.

When I get access to the BIOS of a reasonably fast HT CPU I'll run the benchmarks again, but that might not be for a while.

Sure, task manager tells you how much of the virtual core(s) you are using, what I was saying is that task manager showing 8 cpus instead of 4, does not mean each of your 4 physical cpus was cut in half, or that performance is doubled, like some others seem to think. A virtual core is merely unused resources in a physical core, so performance will vary depending on the work load on the physical and virtual core, but it is not in any way like an extra physical core or cutting a physical core in half.

Is it worth using 4.2 ghz HT off as opposed to my current 4.0 Ghz HT on...

Depends entirely on your workload. If you do serious work or hardcore gaming, then you need to do benchmarks with each setting (HTT on and HTT off) in the program/game you care about, other than that it's probably a toss up, but mostly better if your active thread count exceeds your physical core count. For instance if your main thing is to do video conversion, and you have software that can convert video with 8 threads but only have a 4 core cpu, then HTT set to on with 8 threads will probably be somewhat to significantly better than HTT set to off with just 4 threads doing the conversion.

 

[chinesepiratefood]

The difference in the numbers you are seeing is NOT related to hyperthreading.

 

[MrWizard6600]

Windows is aware of what cores are real and virtual so if you are using 4 or less threads running they will all be running on real cores and without the virtual cores doing anything the hit will be less than 10%.

Is it? Can you cite that for us?

The difference in the numbers you are seeing is NOT related to hyperthreading.

care to elaborate? Tudz is comparing a Lynnfield to a Bloomfield, which gives us a big uncertainty, but his results seem pretty conclusive, and as TheSpoon says, Anand seems to agree.

To my knowledge, hyper-threading really isn't all that complicated.

A good model for how a CPU works (or worked, at least) is fetch -> decode -> execute.... infact I'm not going to bother rewording this, I learned it first from a guy by the name of Steve Gibson, and then later my prof repeated it in a substantially more convoluted way...

[this material was grabbed from a transcript of a podcast with Leo Laporte and Steve Gibson called Security now.
The transcript is here:
http://www.grc.com/sn/sn-254.htm
and the audio can be found here:
http://www.twit.tv/sn254]


You would fetch the instruction from main memory into the Instruction Register, where the machine would then look at the [bits] to determine what this instruction was telling it to do. So there was a fetch of the instruction. Then there was a decode, where you'd decode what it is that you fetched.

Then comes to execute the instruction, whether it's incrementing the accumulator or adding a register to another, maybe jumping to somewhere else. And then in some cases you would be writing the results back, maybe writing the result of incrementing the accumulator back into the accumulator, or writing it back into main memory, if you were storing.

And what the engineers saw was that, well, you know, we fetched an instruction. Then we're decoding it, and we're executing it. But while we're doing those things we're not using main memory. That is, it's waiting for the next fetch. And so the concept dawned on them, and this actually happened on the mainframe level in the late '60s, this notion of sort of overlapping things. And the best example, sort of I think the model that's clearest is, because we've all seen examples of it, is the automobile assembly line - which, as I understand it, Ford invented to create his cars.

So the idea with an assembly line is that, at every stage of assembly, you do a little bit of work towards producing a finished car. The time required to produce one car is the time it takes to go the length of the assembly line. But once the assembly line is full of partial cars being assembled, the rate at which cars come out is much faster than the total time it takes for a car to move through the assembly line.

So say that you had an assembly line of 10 stages. And that each stage took a minute. Well, when you start making a car Well, when you start making a car it's going to take 10 minutes for that car to go all the way through the assembly line, such that 1 care is going to come out the other end every [one] minute - Once the assembly line is full, then they come out every single minute.

And so in processor technology we call this a "pipeline." And virtually every machine now being made, and actually made for the last two decades, has been "pipelined" to one degree or another. So let's first apply that to the very simple model of this machine which fetches the codes, [decodes, and] executes, and writes back. The idea with a pipeline there would be that you fetch an instruction, then you start decoding it. Well, while you're doing that, memory is free. So for most instructions, most code is sequential. That is, we know that after normal instructions are executed, the [instruction pointer, or rather, where the next instruction is in memory --meaning "incrimenting" this causes it the pointer to be pointing at the next instruction] is incremented by one for the next instruction, which is then fetched. And the one after that and so forth.

That changes in the case of jump instructions, which jump us to somewhere else; or branch instructions, which may or may not branch to somewhere else.

So if, while we're decoding an instruction we just fetched, we assume that we're going to be executing the next one here in a while, well, go ahead and fetch it. Get it read from memory. And similarly, after that first instruction's been decoded, then it's time to execute it. Well, meanwhile, at that point the decoder is not busy because it just did its work on the first instruction. Well, now we've got the second instruction that we fetched while the first one was being decoded. It can now be decoded.

And so the analogy is exactly similar to the assembly line where instructions move through several stages. And once they get going, rather than an instruction having to go all the way through before you even start on the next one, you're able to make some assumptions that allow you to basically create an assembly line for computer instructions, just like you do for cars.

[...]

Now, what happens if you hit a branch? Because branching, any change of linear flow is the worst possible thing that can happen. Think about it. We've got all this happening. We've got 20 instructions maybe that have been taken apart, all under the assumption, remember we made one fundamental assumption at the beginning, which was we're going to go linear. All of this sucking in things ahead of where we are assumes we're going to use them. All of this work says that we know where we're going.

Except when we come to a conditional branch, or even a jump that's going to go somewhere, suddenly everything changes. We now don't know whether we're going to keep going or go somewhere else until later in that instruction's phasing. Remember, now instructions are being cracked apart. They're being decoded. They're being executed. There's, like, all this work being done before the outcome of the instruction is known.

The problem is, if it's a branch instruction that might change the sequence, if it does change, if it's branching us to somewhere else, well, everything behind that instruction has to be scrapped. So the entire pipeline has to be dumped. And we stall until we are able to then load a series of instructions from the new location and sort of get all this going again.

[keeping with the car assembly line analogy, a pipeline dump scenario would be like realizing that the car that just came off the assembly line was the last automatic transmission car you were supposed to manufacture, even though all the other cars behind it already have automatic transmissions in them. What you have to do, is dump all those cars as quickly as you can, and re-start the assembly line using manual transmissions, which you haven't got in your factory, so you have to go to your main-memory warehouse.]

Well, the way they've come up with doing this, there was a first level. You can imagine a simple-minded way which says, okay, let's assume that the branch that we encounter, if we've ever encountered it before, is going to do the same thing. So that sort of makes an assumption that branches generally do whatever they're going to do. In fact, microprocessor designers realized that many branches that are branching backwards are at the bottom of a loop, sort of a loop of code which tends to get executed a lot, and then finally isn't executed. So the branch, a branch backwards tends to be taken, as opposed to a branch forward. So there was some simple-minded sort of branch guessing that way.

[...branch guessing hardware got better...]

And what we end up with is literally pattern recognition, where over time the CPU acquires a knowledge of any sequence of up to four long of branches and not branches being taken. That will be recorded in the two-bit predictor which will tell the computer with very good probability whether the branch will be taken again or not. And these predictors have grown in length and in size. And so remember that there's one of these whole predictors for each of a number of different locations in memory where these branches could fall.

So now what we've done is we've got this pipeline sucking in instructions, cracking them down, looking at their interdependencies, reorganizing them on the fly, taking it - we've decoupled the Arithmetic Logical Units and the floating point processors and the instruction decoding and all of this so that those are all now separate resources which are being assigned and used as soon as they can. As soon as we're able to see that we know enough to allow one of these micro operations to proceed, we do.

At the same time, the system is filling up the pipeline at the top using the results, assuming we're going linearly, unless we hit a branch or a jump, and then recording the history and literally learning the pattern of the past sequence of branches in the code and sort of heuristically developing an awareness of pattern recognition of whether - I mean, so that it's able to guess with as much as, it turns out, 93 percent probability whether a given branch will be taken or not, only missing about 7 percent of the time. And when it's wrong... making a mistake is expensive in prediction because we have to flush all the work we were doing, and then go somewhere else. But 93 percent of the time we're able to get it right.

Now, once all of this was finished, and this was maybe, oh, about a decade ago we had this level of technology, there was still some unhappiness with the contention for resources. That is, there was still not what's called "instruction-level parallelism." There still was, like, the ALUs and the Floating Point Units [ALU's and FPU's are the Execution portion of a CPU]... they were sitting around not being used all the time. The engineers weren't able to get them busier because there was still too much interdependence among these micro operations that they were just - they couldn't get enough, they weren't able to use the resources fully.

Well, this is when this notion of simultaneous thread execution occurred to them, which Intel calls "hyper-threading." What hyper-threading is, is the recognition that there is what's called "register pressure." There is not enough freedom of value assignment among registers. There's just too much interdependency [that is, soo many instructions depend on the outcomes of other instructions, too many different types of transmissions, changing too frequently]. But if we had a whole second set of registers, if we duplicated everything, then where some microinstructions are fighting with each other, too interdependent, where they're having to wait for results to finish before the later ones can start, therefore assets like the Arithmetic Logic Unit and Floating Point Unit are sitting around being unused, if we have another physical thread, that is, we have another whole set of registers, well, there, because it's a different thread, they're logically disconnected from the first thread's registers. There is no conflict at all possible between these separate banks of registers [because neither instruction from one thread will ever have anything to say or do to another threads instructions, by the very definition of "thread"].

So what hyper-threading does is, I mean, and this - talk about it being confusing already. This literally pours instructions from two entirely different threads of execution down into the same pipeline, breaking them all up, keeping them all straight, realizing that these micro ops and these registers are actually different from those micro ops and those registers. So now we have - we've doubled the opportunity for exploiting these fixed assets, the Arithmetic Logical Unit and the Floating Point Unit, being able to keep them busy much more of the time, which is what hyper-threading does. Essentially, it doesn't duplicate the entire system, but it allows us to pour two different threads of execution into the same pipeline and get a tremendous boost, I mean, it's not like doubling. We don't get double because the resources weren't that underutilized. Typically it's about a 25 percent gain [-OR, as this very thread would lead us to believe, maybe not?], which in this quest for performance is better than a kick in the head.

To my knowledge the OS scheduler does not know which thread being used in this "if we have the spare resources we'll fit you in" mode [which I'm calling "supplemental mode"] and which thread is getting full-on normal execution mode. This could well be the root cause of performance degradation from HT, as, if the OS doesn't know that sometimes a thread is going to see much less execution from one thread (the virtual thread), than it is from another (the main on-core thread), then it would be problematic if it scheduled a high-value thread on the virtual core.

For example, if in the above example, one of the CPU cores was working on something supid, like JVM running its garbage collection, and HT had decided to supplement that with the partial execution of the app you really care about, like a game or Prime 95 or whatever, then, even though the OS scheduler believes the app you really care about is getting time executed, its only getting the scrap resources left over from JVM garbage collection.

Even if that's not the case, and the OS can somehow know which thread is supplemental and which thread isn't (which I just cant see being the case, since that would require a dramatic re-engineering of the OS scheduler), that fundamental problem still exists, and it is absolutely the case that you cannot send one thread to be on both the supplemental portion of one core, and the main portion of another, so in effect, whenever you queue anything up for the supplemental portion of a core, and then another core on the other side of the die goes into system idle thread, you've just lost performance.

So yeah, in programs that have been written such that they have very few and highly predictable branch/if-else/switch/etc statements, then when that thread is loaded onto a CPU, and that CPU is then handed another thread B to be run in supplemental mode, B is simply never going to see any execution time --a problem coined "thread starvation" by the UNIX guys in the 80's when OS scheduler algorithms weren't as sophisticated as they are now. In this particular instance --which intel is hoping is an instance that isn't very often occuring-- the program that instantiated Thread B will run faster with HT turned off.

What can I say? With billion transistors CPUs, you have to get creative to get the big performance bumps.

It will be interesting to see how AMD's first implementation of an HT-like system in Bulldozer and Bobcat will perform.

 

[CamaroZ28]

Is it? Can you cite that for us?

This is pretty much common knowledge, but here you go...
http://www.tomshardware.com/news/windows-hyperthreading-intel-nehalem-atom,7831.html


As for my 2 cents, whoever did the analysis between the i5 750 and the 920 did not take into account that there are a ton more differences between these cores besides HT. One of the major things is that lynnfield has a much higher uncore speed so comparing these two, even at the same freq. with no turbo, is not going to be apples to apples.

As for the original topic, HT on or off will likely make little to no difference in the performace of your DOS game, I'd be willing to bet that you would see <5% difference. Your best bet is to overclock as high as possible on stock voltage and rely on turbo mode to boost your single threaded performance. This would keep your temperature from increasing noticably.

 

[Tudz]

This is pretty much common knowledge, but here you go...
http://www.tomshardware.com/news/windows-hyperthreading-intel-nehalem-atom,7831.html


As for my 2 cents, whoever did the analysis between the i5 750 and the 920 did not take into account that there are a ton more differences between these cores besides HT. One of the major things is that lynnfield has a much higher uncore speed so comparing these two, even at the same freq. with no turbo, is not going to be apples to apples.

As for the original topic, HT on or off will likely make little to no difference in the performace of your DOS game, I'd be willing to bet that you would see <5% difference. Your best bet is to overclock as high as possible on stock voltage and rely on turbo mode to boost your single threaded performance. This would keep your temperature from increasing noticably.

I dont read anywhere in that article where it says single thread can take advantage of HT or HT wont slow down a single threaded task, simply that Windows 7 can "take advantage" of HT, which really doesn't mean anything more than a couple of tasks can be offloaded onto virtual cores.

I still stand by my statement that if you're getting poor single thread performance at least TRY turning off HT. If I ever get a chance to benchmark an i7 with HT off I'll be sure to post the results, I posted the i5 vs i7 results purely because I dont have BIOS access to disable HT on the i7 machine.

 

[CamaroZ28]

Of course it doesn't say anything about a single thread taking advantage of HT or HT now slowing down a single threaded task. I was refuting MrWizard6600's post that says that the scheduler isn't optimized for Hyper-Threading and isn't aware what is a virtual core and what is a real core. If that article isn't solid enough proof for that then I can just paste a screenshot of my computer that shows my 4 virtual cores being parked when 4 or less threads are in use.

 

[dandragonrage]

I don't understand that.

There are 4 physical cores, HT makes it show 8, but if what you suggest were true, then I would be seeing load on 2 logical cores, wouldn't I?

LOL

 

[CamaroZ28]

LOL

+1 lol

 

[aaronearles]

This thread is full of fail lol, there's a point where you really just need to give it up.

 

[asyork]

I felt like I was reading a thread from years ago when Hyperthreading new. At first I was going to correct a few things and offer some examples, but by the end I don't know what to say.

All I can offer is this experiment, either try it yourself or make a thought experiment of it if you can.
Example system for this case, but anything would work:
4 core CPU, no HT
4 GB ram
1 TB HDD
Set up a VM on your system that can access 2 cores, 2 GB ram, and 500 GB of HDD space. Leave that running and continue.
Set up another VM with the exact same settings, and leave that running.

Now, open up the system info for all 3 systems (host and both guests). If you add it all up, you have 8 cores, 8 GB of ram, and 2 TB of storage existing on a system with half that. All 3 systems have access to those resources so long as they don't all try to use it at the same time, if they do, the host will have priority (more or less, it will at least have the option for priority). If you are running resource intensive calculations on all of these, the VMs will basically fill in the processing gaps, like the times when Tudz pointed out that his CPU wasn't quite at 100%.

Hyperthreading works more or less like that, but with a lot less overhead. It is a way to squeeze more performance out of the same hardware by making use of CPU time that would otherwise have been impossible to use. It is very easy to test your specific situation with and without, so there really isn't any reason not to, but general computer usage is improved by Hyperthreading.

Windows does know which cores are which, but I do not know how well it makes use of that information. I would assume that it at least moves lower priority threads to the virtual cores. Possibly even moving threads from programs the user is actively using to the first physical core (to make use of speedboost), but that's probably asking for too much. This isn't only up to windows though, programmers have to be responsible. My computer feels a little more sluggish with Hyperthreading off, but I multitask to a serious degree.

As best as I can tell, and I don't know why this is the case, on my 920 the physical cores are 0, 2, 4, and 7.

 

[devil22]

...
As best as I can tell, and I don't know why this is the case, on my 920 the physical cores are 0, 2, 4, and 7.

The 'physical' core is not fixed I believe, for instance core 0 or core 1 could be treated like the 'physical ' core and get priority, leaving the other core empty during light usage or usable as a 'virtual' core during heavy multitasking. If you watch task manager for any length of time while executing light/medium tasks, you'll see a pattern where the first two cores follow a 1 core used-1 core empty usage pattern but possibly alternating which does which, the 2nd two cores follow this pattern, and so on. Just fyi.