Hyperthreading Hype predates Intel

[lmader]

Actually, with regard to hyperthreading providing an increase in computing speed as compared to a single non SMT core, it should be noted that most multi-threaded chess engines, crafty included, exhibit a speed increase in terms of total work being done by the CPU with hyperthreading enabled. The NPS increases. The only reason that this does not net an overall faster time to solution is due to the inefficiency of the multithreaded tree search implementation, which causes the total amount of tree nodes to be searched to increase even more than the speedup of the hyperthreading. Thus the software implementation (chess engine) imposes a much greater workload by creating a larger tree to search in multithreaded scenarios, and each core is therefore searching many nodes in a redundant fashion. This is not hyperthreading's fault. The hyperthreading is still happily doing its job and actually crunching more NPS than without. The CPU is in fact faster and doing more work/time. I.e just because multithreaded chess engines, as currently implemented, don't benefit doesn't mean the technology is useless.

[govert]

First, get a better O/S. Linux _never_ "freezes".

Oh yah, it does. Try the ATI closed source display dirivers

[bob]

However, for those that are talking about "responsiveness" this does make a big difference. If you take a 2.8ghz xeon and run with SMT on, it is like two 1.5ghz xeons or so, depending on the programs. But now you have two physical processors as far as the O/S is concerned and with two compute-bound processes, each will be running at a much slower speed than normal. And when playing chess tournaments on such a box, you are simply using significantly slower hardware than you think...

[bob]

First, get a better O/S. Linux _never_ "freezes".

Oh yah, it does. Try the ATI closed source display dirivers

I have two ATI boxes and one has been running for over a year without rebooting. I've never seen any of my linux boxes hang at all, unless I have a hardware problem which is pretty rare...

[govert]

Mine is an Acer Laptop with a Mobility Radeon 9600 M10.
I suspect it's not the prime target for those drivers, and also maybe not too extensively tested by the ubuntu test team.

Anyway, (getting OT) I'm still sticking to linux.

[sje]

First, get a better O/S. Linux _never_ "freezes".

Ah, were but that to be true. Alas, the Linux developer forums say otherwise.

I've seen it from time to time. In older kernels at least, a process with runaway memory allocation that eats up all of virtual memory will force a reboot. Also, on some hardware (usually the cheap stuff) even the latest Ubuntu distribution will occasionally freeze on system shutdown/restart after a software upgrade.

[lmader]

However, for those that are talking about "responsiveness" this does make a big difference. If you take a 2.8ghz xeon and run with SMT on, it is like two 1.5ghz xeons or so, depending on the programs. But now you have two physical processors as far as the O/S is concerned and with two compute-bound processes, each will be running at a much slower speed than normal. And when playing chess tournaments on such a box, you are simply using significantly slower hardware than you think...

All due respect, Dr. Hyatt, this is nonsense. It's not as though the clock speed of the P4 is throttled down to half speed because hyperthreading is enabled. The hyperthreaded CPU simply has extra execution units that can operate when the primary executing thread is stalled. Most applications are executing at full clock speed, and getting nearly all of the CPU resources expected.

...you are simply using significantly slower hardware than you think...

Bluntly, horse pucky. The hardware is indeed running quite fast. I'll repeat my post from above:

With regard to hyperthreading providing an increase in computing speed as compared to a single non SMT core, it should be noted that most multi-threaded chess engines, crafty included, exhibit a speed increase in terms of total work being done by the CPU with hyperthreading enabled. The NPS increases. The only reason that this does not net an overall faster time to solution is due to the inefficiency of the multithreaded tree search implementation, which causes the total amount of tree nodes to be searched to increase even more than the speedup of the hyperthreading. Thus the software implementation (chess engine) imposes a much greater workload by creating a larger tree to search in multithreaded scenarios, and each core is therefore searching many nodes in a redundant fashion. This is not hyperthreading's fault. The hyperthreading is still happily doing its job and actually crunching more NPS than without. The CPU is in fact faster and doing more work/time. I.e just because multithreaded chess engines, as currently implemented, don't benefit doesn't mean the technology is useless.

[bob]

However, for those that are talking about "responsiveness" this does make a big difference. If you take a 2.8ghz xeon and run with SMT on, it is like two 1.5ghz xeons or so, depending on the programs. But now you have two physical processors as far as the O/S is concerned and with two compute-bound processes, each will be running at a much slower speed than normal. And when playing chess tournaments on such a box, you are simply using significantly slower hardware than you think...

All due respect, Dr. Hyatt, this is nonsense. It's not as though the clock speed of the P4 is throttled down to half speed because hyperthreading is enabled. The hyperthreaded CPU simply has extra execution units that can operate when the primary executing thread is stalled. Most applications are executing at full clock speed, and getting nearly all of the CPU resources expected.

Did you read what I wrote. The clock speed of the "logical processors" is "throttled down". And that is simple to measure, just turn on SMT on one cpu, then run two copies of something to see what happens. They will run (in the case of Crafty) at about 55% of the normal speed of using just one CPU.

Is that effectively "throttled down"? Of course it is. The "hyperthreaded cpu" does _not_ have "extra execution units". What it has is two program counters, two sets of registers, etc. But they _share_ the pipelines. That is the whole point. Two instructions running down a shared pipeline = about 1/2 the speed, except for those cases where one of the threads is memory bound and the other is not...

This has been discussed at length previously...

...you are simply using significantly slower hardware than you think...

Bluntly, horse pucky. The hardware is indeed running quite fast. I'll repeat my post from above:

With regard to hyperthreading providing an increase in computing speed as compared to a single non SMT core, it should be noted that most multi-threaded chess engines, crafty included, exhibit a speed increase in terms of total work being done by the CPU with hyperthreading enabled. The NPS increases. The only reason that this does not net an overall faster time to solution is due to the inefficiency of the multithreaded tree search implementation, which causes the total amount of tree nodes to be searched to increase even more than the speedup of the hyperthreading. Thus the software implementation (chess engine) imposes a much greater workload by creating a larger tree to search in multithreaded scenarios, and each core is therefore searching many nodes in a redundant fashion. This is not hyperthreading's fault. The hyperthreading is still happily doing its job and actually crunching more NPS than without. The CPU is in fact faster and doing more work/time. I.e just because multithreaded chess engines, as currently implemented, don't benefit doesn't mean the technology is useless.

"don't benefit" sounds like a perfect definition of "useless" IMHO.

This is about computer chess you know???

[hgm]

You mean: you are talking about computer Chess, and had not noticed others were not...

It is very simple: hyperthreading increases throughput, and thus can increase performance when properly applied.

[bob]

You mean: you are talking about computer Chess, and had not noticed others were not...

It is very simple: hyperthreading increases throughput, and thus can increase performance when properly applied.

Wrong statement. It can increase performance, not when properly applied, but when the applications happen to have certain uncommon characteristics that allow hyper-threading to improve performance. But it is _not_ riskless and can, on lots of occasions, _hurt_ performance.

This has been documented since this first came out. Most applications see no improvement. A small group see minor improvements. An even smaller group produces significant improvement. And a group at least that same size sees a performance degradation.

99.9% of the programmers on the planet do not understand what it takes in an application to make SMT work. Those that do also know how to make the application faster without SMT, which eliminates any advantage SMT might offer...

SMT _never_ helps a single application that does not use multiple processes/threads, which just happens to cover 99%+ of the applications available. It does not speed up very many when they are run in parallel with other applications and quite often runs worse. You can find old discussions that contain all sorts of benchmarks on various web sites like TomsHardware and the like. It is _not_ a "big winner". In the "general case" it is essentially worthless.