Two years ago Prescott wrote about CPU HT task time

"Hi!

I was not able to find an answer so I am posting here to ask!
I know some projects discourage Hyper-threading on CPU's for certain tasks because it makes them slower/produce bad results.
Excluding the issues from heat generation from HT, is there a problem with using HT for this project?

Best,
Prescott"

At the end of discussion Prescott summarise posts: 58% longer time on each task with HT.

My two days small experiment result is 47-100% longer task time with HT and all cores run on r5 3600, i5-10400f, r5 5300u.

Two years ago Prescott wrote about CPU HT task time

"Hi!

I was not able to find an answer so I am posting here to ask!
I know some projects discourage Hyper-threading on CPU's for certain tasks because it makes them slower/produce bad results.
Excluding the issues from heat generation from HT, is there a problem with using HT for this project?

Best,
Prescott"

At the end of discussion Prescott summarise posts: 58% longer time on each task with HT.

My two days small experiment result is 47-100% longer task time with HT and all cores run on r5 3600, i5-10400f, r5 5300u.

Results should be fine. The only real downside is tasks will take longer to run. HT works well with apps that do a lot of file I/O, since a second thread can utilize the CPU while the other thread is waiting on the disk. Numberfields has a very small amount of file I/O (writing the occasional field and checkpointing), so there's not much CPU idle time.

There are other things too. For example, HT may benefit apps that do large amounts of RAM access. But for NumberFields, the larger caches on newer CPUs dramatically reduces RAM access.

So it's really up to the user if they want to use HT. I personally don't like the extra heat it generates, but maybe in the winter months that's not such a bad thing.

While there are some edge case where Hyperthreading off will improve performance, in most case having it on results in better performance. In many cases it actually results in much better performance- how long it takes to process a Task isn't the best way to determine how productive your system is, how many Tasks you can do in 24 hrs is what matters.
Even if it takes longer to process each Task, doing 100 Tasks in 24 hours is way better than only doing 75 in 24hrs.




And as for heat- the increase in power consumption and in heat is generally negligible.





SMT Performance Benchmarks Continue To Show Benefit With AMD Zen 5/5C

---

Grant
Darwin NT, Australia.

I'm not sure what they were testing in those graphs, but every app will be different.

With my AMD Ryzen9 7950X: my CPU temps were about 90C with HT on, and about 80C with it off. I don't like stressing my CPU that much so I leave it off.

I'm not sure what they were testing in those graphs, but every app will be different.

That's the average of dozens of programmes, on a Zen 5 CPU.

eg

With my AMD Ryzen9 7950X: my CPU temps were about 90C with HT on, and about 80C with it off. I don't like stressing my CPU that much so I leave it off.

Yeah, apparently they do tend to run hot- even with very good cooling.
Even though AMD officially say that they are OK with then running 24/7 at 95°c, 80°c the absolute limit for me with a CPU for extended periods.

---

Grant
Darwin NT, Australia.

Two years ago Prescott wrote about CPU HT task time

"Hi!

I was not able to find an answer so I am posting here to ask!
I know some projects discourage Hyper-threading on CPU's for certain tasks because it makes them slower/produce bad results.
Excluding the issues from heat generation from HT, is there a problem with using HT for this project?

Best,
Prescott"

At the end of discussion Prescott summarise posts: 58% longer time on each task with HT.

My two days small experiment result is 47-100% longer task time with HT and all cores run on r5 3600, i5-10400f, r5 5300u.

Results should be fine. The only real downside is tasks will take longer to run. HT works well with apps that do a lot of file I/O, since a second thread can utilize the CPU while the other thread is waiting on the disk. Numberfields has a very small amount of file I/O (writing the occasional field and checkpointing), so there's not much CPU idle time.

There are other things too. For example, HT may benefit apps that do large amounts of RAM access. But for NumberFields, the larger caches on newer CPUs dramatically reduces RAM access.

So it's really up to the user if they want to use HT. I personally don't like the extra heat it generates, but maybe in the winter months that's not such a bad thing.

This is not precise. Hyper-threading was/is not about I/O or caches. Hyper-threading was about using unused execution resources in CPU backend during execution of code of a task. It is mostly about using effectively OOO scheduling and execution units.

For good image examples how it looks see following links from RealWorldTech:
https://www.realworldtech.com/haswell-cpu/3/
https://www.realworldtech.com/haswell-cpu/4/

Now, best case is when one physical core sees one integer and one floating point threads. However as can be seen, backend is very wide so even two integer threads won't be much of problem. Now, Get-decics is bit weird case, but I don't have yet full analysis. In my experience using old Sandy Bridge/Ivy bridge there is at most 25% loss of performance and in my case it was more likely due to frequency. Which would tie nicely with your observation of increased core temperature. Get-decics seems to be far more sensitive to CPU frequency. (i5-2500K was beating i5-5500u by really large margin and almost modern Atoms like Goldmont are really good)

One thing: Because of very wide/extreme variation in runtimes I strongly recommend to use much longer timeframe for avg point score than 24-48hh. IIRC project uses effectively 7-day window, so that is my recommendation.

This is not precise. Hyper-threading was/is not about I/O or caches. Hyper-threading was about using unused execution resources in CPU backend during execution of code of a task. It is mostly about using effectively OOO scheduling and execution units.

For good image examples how it looks see following links from RealWorldTech:
https://www.realworldtech.com/haswell-cpu/3/
https://www.realworldtech.com/haswell-cpu/4/

Now, best case is when one physical core sees one integer and one floating point threads. However as can be seen, backend is very wide so even two integer threads won't be much of problem. Now, Get-decics is bit weird case, but I don't have yet full analysis. In my experience using old Sandy Bridge/Ivy bridge there is at most 25% loss of performance and in my case it was more likely due to frequency. Which would tie nicely with your observation of increased core temperature. Get-decics seems to be far more sensitive to CPU frequency. (i5-2500K was beating i5-5500u by really large margin and almost modern Atoms like Goldmont are really good)

One thing: Because of very wide/extreme variation in runtimes I strongly recommend to use much longer timeframe for avg point score than 24-48hh. IIRC project uses effectively 7-day window, so that is my recommendation.

You're right, I was thinking multi-threading in general, and I'm not as familiar with HT.