Hyperthreading or not? - Page 1
Forum section: electronics / general

author: BeBuLamar
author_rank: Super Contributor
timestamp: September 03, 2024, 12:41:45 am
content: I have an old HP Z600 with 2 Xeon X5675 CPU's. Each CPU has 4 cores and has hyperthreading feature. If I enable hyperthreading Windows 10 will see the computer has 16 cores. If I disable hyperthreading it will see 8 cores. I run Photoshop CC and Autocad. I wonder whether enabling hyperthreading or disable hypethreading would improve performance?

author: I wanted a rude username
author_rank: Frequent Contributor
timestamp: September 03, 2024, 12:56:25 am
content: Hyperthreading generally improves highly threaded workload performance by about 30% (as long as enough threads/processes are spawned of course), and there's usually no downside for single-threaded workloads.The surprising part is that someone had disabled hyperthreading on that server in the first place.

author: ejeffrey
author_rank: Super Contributor
timestamp: September 03, 2024, 01:12:39 am
content: Thehttps://www.intel.com/content/www/us/en/products/sku/52577/intel-xeon-processor-x5675-12m-cache-3-06-ghz-6-40-gts-intel-qpi/specifications.htmlhas 6 cores per socket not 4, are you sure that you have the right part number?These days enabling hyperthreading is almost always better or at least neutral for multi threaded performance. That wasn't always the case but schedulers have improved in this area significantly. So I would say enable it unless you have a specific reason not to.

author: ejeffrey
author_rank: Super Contributor
timestamp: September 03, 2024, 01:23:01 am
content: Quote from: I wanted a rude username on September 03, 2024, 12:56:25 amBack in the days of sandy bridge and early windows 7, hyperthreading would sometimes reduce throughout on multi threaded applications that had large cache footprint and were already effectively using most core resources with instruction level parallelism.Hyperthreading is/was also sometimes disabled for spectre / meltdown mitigation since hyperthreads share so much micro-architectural state.

author: Psi
author_rank: Super Contributor
timestamp: September 03, 2024, 01:25:46 am
content: Quote from: ejeffrey on September 03, 2024, 01:23:01 amThat would be my guess too

author: BeBuLamar
author_rank: Super Contributor
timestamp: September 03, 2024, 01:36:07 am
content: Quote from: ejeffrey on September 03, 2024, 01:12:39 amYou're correct. With hyperthreading disabled resource monitor shows 12 cores. With hyperthreading enabled it shows 24 cores.

author: brucehoult
author_rank: Super Contributor
timestamp: September 03, 2024, 01:40:55 am
content: Quote from: BeBuLamar on September 03, 2024, 12:41:45 am"I have" ... "wonder whether" ...Only you know AND CAN TEST your exact workloads. I'm sure it varies from filter to filter in Photoshop.Intuitively, hyperthreading helps the most -- potentially up to nearly 100% -- on code that does a ton of memory references, especially references than miss in cache, and little computing on values in registers.It's not going to do a single thing for code that is running tight loops in registers. In theory it should never slow anything down, unless a dumb scheduler puts two threads on the same core wheh there are available real cores.It might well be very good on Lisp code.

author: Postal2
author_rank: Frequent Contributor
timestamp: September 03, 2024, 08:09:24 am
content: I've seen slowdowns when hyperthreading is enabled on Atom 230 and N270 processors. It seemed to be related to dropped frames in video, although tests showed the opposite.Quote- Exactly yes.It is important to remember that a processor core with hyperthreading disabled is always faster at context switching than the same core that does not have hyperthreading at all.

author: paulca
author_rank: Super Contributor
timestamp: September 17, 2024, 08:45:24 am
content: As with all concurrency, "it depends".8 core / 16 thread CPUs only usually have 8 sets of most components and 16 of only a few.If depends on what the threads are competing on as to whether you will get more, less or the same performance when running 8 or 16 threads.One blunt test is to compile the Linux kernel. On my 8/16 CPUs it compiles faster with 8 than 16.Generally speaking I would say, ball park, if your workloads are intense (100% consistent utilisation), you would be better without hyper-threading. If your workloads are bursty with lots of idle time, then hyper-threading can lower the latency between context switching.

author: radiolistener
author_rank: Super Contributor
timestamp: September 17, 2024, 01:32:10 pm
content: Software which is optimized for multi-threading can get advantage, but it depends on exact software. Software which was designed for single threaded CPU may have some performance issues with enabled multi-threading. It don't means that all signle-thread software will have issue, but some software may have it. Needs to test exact software with exact OS version, exact settings. Because even different versions of the same OS may show different results.

author: brucehoult
author_rank: Super Contributor
timestamp: September 17, 2024, 03:48:00 pm
content: Quote from: paulca on September 17, 2024, 08:45:24 amHmm ... I'm not so sure about that on the machine I use.I tried on my i9-13900HX laptop, which has 8 P cores with hyperthreading (16 logical processors) plus 16 E cores that don't have hyperthreading, in "performance" mode. Brand new checkout of Linux HEAD, Ubuntu 24.04 liveCD (because I normally use WSL2, which doesn't honour taskset).Code:1m27.58s make -j322m15.43s taskset -c 0-15 make -j16 (only P cores, with hyperthreading)2m26.83s taskset -c 0-15:2 make -j8 (only P cores, no hyperthreading)2m13.81s taskset -c 16-31 make -j16 (only E cores)1m31.81s taskset -c 0-15:2,16-31 make -j24 (P cores, no hyperthreading, plus E cores)So, it's better to enable hyperthreading than not -- though not by a huge amount, just 8.5% faster, and just 4.8% faster overall if the E cores are also enabled.The big surprise is the E cores, in aggregate, are faster than the P cores.Overall, the fastest is just to allow the machine to use everything it has.

author: paulca
author_rank: Super Contributor
timestamp: September 18, 2024, 08:13:25 am
content: Interesting. However the last time I did this was ages ago. I think it was the Ryzen 2700X I tried last. Which is what? 6 years old now?

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 18, 2024, 08:41:59 pm
content: It so much depends on the exact CPU, the OS and the exact load that it doesn't make sense to answer that other than giving very general statements.Bruce gave tests results (on a given CPU, a given OS and a given load), and that's really all you can do in any particular case to make a choice.As he mentioned, in the most general case though, HT is usually beneficial, even if it's not by a huge margin. Keep in mind that (at least in the cases I know) HT doesn't duplicate the FPU in a core, so that if you run heavily multi-threaded FP calculations, it won't make a difference and may even hinder performance a tad.As I remember, HT initially got this "bad rep" when it was first introduced on the P4 (which I had) and people had very mixed results with that enabled, on Windows, knowing that at the time, most apps were still very much single-threaded and so multi-threading was really across different apps/processes (and interrupt handling), and HT implementation on this CPU wasn't the best, so the end result wasn't always all that great with it enabled. That said, I never disabled it myself and it was perfectly fine for my use cases at the time.Looks like ever since then, the bad rep lingered and some of that may still be in the discussions now even if disabling it is very rarely beneficial with recent CPUs. Now of course, it's all in the test results you'll get in a particular use case. But claims without tests and based on "I heard that..." are a bit pointless.

author: brucehoult
author_rank: Super Contributor
timestamp: September 18, 2024, 10:38:25 pm
content: Quote from: SiliconWizard on September 18, 2024, 08:41:59 pmI don't think it duplicates anything in the CPU pipeline except the architectural registers (and CSRs) -- which in an OoO design means just doubling the size of the rename tables.The idea of hyperthreading is that when the CPU is stalled because of a cache miss, branch mispredict, or dependency on a long-latency instruction such as multiply/divide or FP, there are independent instructions from another thread that it can run while waiting.Barrel processors and GPUs take this to an extreme with maybe one or two tens of threads on a single physical CPU.Note that while HT gives the CPU something to do while waiting for a cache miss, because two (or more) threads are sharing the same L1/L2 cache and TLB it can cause more misses in the first place.

author: paulca
author_rank: Super Contributor
timestamp: September 20, 2024, 11:34:35 am
content: Quote from: brucehoult on September 18, 2024, 10:38:25 pmIt's very, very architecture dependant. Intel and AMD CPUs behave differently. The instruction pipe-line does not need multiple threads to parallelize.The Intel architecture (and AMD for the same reasons) is more than capable of executing "many" instructions "per clock cycle".... from a single thread.... on a single core with no hyperthreading since about the early 2000s. The "micro-code" and "instruction decoding" portion of the architecture takes up a sizable chunk of the die. The same components in an ARM CPU are tiny. ARM has other advantages around consistent, latency.EDIT: I recall as an exercise in Uni were asked, given a very, very basic CPU and instruction set, to produce an "Interopability analysis" between the operations. Then using that paralellise a series of instructions in a pipeline. It was very basic though. The real architecture is 1000s of times more complex (x86)The most simple example and probably the first example of "in thread" parallel execution was the so called "pre-fetch execute cycle."While decoding the "current" instruction the previous instruction is already decoded in the pipeline and the next one can be read from memory, all simultaneously.

author: mfro
author_rank: Regular Contributor
timestamp: September 20, 2024, 04:18:34 pm
content: Quote from: paulca on September 20, 2024, 11:34:35 amYou seem to mix up concepts here - huge micro code size in Intel/AMD CPUs is due to the fact that these are basically RISC CPUs in CISC fur which is for the sake of the holy cow of backwards compatibility. ARM CPUs don't have that legacy ballast.Intel btw. tries to get rid of hyperthreading with newer CPUs as they consider real multithreading more energy efficient.

author: brucehoult
author_rank: Super Contributor
timestamp: September 21, 2024, 12:17:36 am
content: Quote from: mfro on September 20, 2024, 04:18:34 pmThere is no "try". Do, or do not.

author: coppice
author_rank: Super Contributor
timestamp: September 21, 2024, 12:30:50 am
content: Quote from: brucehoult on September 21, 2024, 12:17:36 amWell Intel tried, and now they are not trying.... Unless you have some of their degrading CPUs, which you might find very trying.I'm surprised people are moving away from hyperthreading. As caches have become larger, it feels like more threads sharing the same space should be working out better than it used to. Maybe the seemingly endless stream of corner cases that lead to security issues is the deterrent here. More complexity generally leads to more quirks.

author: brucehoult
author_rank: Super Contributor
timestamp: September 21, 2024, 12:41:59 am
content: What "try"? Intel design their own CPU cores. Just design cores without Hyperthreading (like e.g. the Intel-designed "E" cores in my i9-13900HX), or delete the hyperthreading part of the HDL from other cores.Not that I can see a reason to do that. Hyperthreading helps some use-cases, and doesn't seem to hurt (total) performance on anything so I don't object to it being there. Whether it's worth +10% or +30% performance -- for very little extra hardware -- it's not easy to come by that kind of increment these days.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 21, 2024, 12:56:31 am
content: Quote from: brucehoult on September 18, 2024, 10:38:25 pmYes. That required a bit more elaboration. HT on CPUs that have multiple "execution units", so, superscalar, in itself doesn't imply duplicating anything further (except registers), but it has an impact that can be much harder to predict than if there were only one execution unit. For silicon costs reason, ALUs (so integer operations) are what's usually duplicated (often entirely). For FPUs, they are rarely duplicated, they are merely optimized as to enable several categories of FP instructions to execute in parallel, but that's not as effective as, obviously, duplicating the FPU entirely. How ALUs and FPUs are designed and potentially duplicated (for making them superscalar) of course all depends on a given architecture, and how OoO plays well with HT is also another difficult point.While this will also affect the number of instructions per clock in non-HT mode for integer vs FP instructions, since HT is made to increase the use of execution units at any given time, the performance increase is often more visible for integer instructions and a lot less so for FP ones, for which the probabilty of maximizing the use of "execution units" is much lower (and can make things worse depending on the exact sequence of FP instructions). All this can be shown with some benchmarking.As to Intel "getting rid of HT", uh yeah. They have introduced it, then removed it, then later re-introduced it. It's kind of a moving target which again heavily depends on a given architecture. And marketing factors. Of course, unless they can come up with a very significant performance gap without HT, if they release a new generation without HT and AMD still has CPUs with HT, for instance, they'll lose. Marketing.

author: brucehoult
author_rank: Super Contributor
timestamp: September 21, 2024, 01:38:12 am
content: Quote from: SiliconWizard on September 21, 2024, 12:56:31 amLooking at ...https://upload.wikimedia.org/wikipedia/commons/a/a4/Intel_Core_i9-13900K_Labelled_Die_Shot.jpg... the 16 E cores take up about 3/4 of the die space of the 8 P cores.As my Linux kernel build prompted by paulca showed, the E cores alone resulted in a slightly faster (by 1.5 seconds) build than the P cores alone with HT, and 13 seconds faster than the P cores without HT.It's valuable to have at least a couple of cores that can spin up to 5.4 (my laptop chip) or 6 GHz (i9-14900k desktop chip) for those single-threaded tasks. But it seems very likely that they could have made at least Linux kernel builds faster with the same chip area by deleting 6 of the P cores and replacing them with 16 more E cores, for a total of 2 P cores (4 threads if they keep HT) plus 32 E cores. Faster, and I'd imagine less total energy consumption too.On the other hand, the current design is reasonably well done in that if all 8 P cores are fully utilised then the clock speed has already throttled back to the maximum turbo speed of the E cores, so there is actually no point in having more P cores than that. There does however remain the question of lower IPC on the E cores, not only the lower MHz.

author: Someone
author_rank: Super Contributor
timestamp: September 21, 2024, 02:05:36 am
content: Quote from: brucehoult on September 21, 2024, 01:38:12 amHopefully some benchmarks will tease that out as it scales out:https://en.wikipedia.org/wiki/Sierra_Forest

author: mfro
author_rank: Regular Contributor
timestamp: September 21, 2024, 03:57:49 pm
content: Quote from: coppice on September 21, 2024, 12:30:50 amMy understanding is that is about energy efficiency/laptop battery life. An extra hyperthread apparently draws nearly the same power than a real thread on an additional core, but only adds a maximum of 30% of its computing power.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: November 18, 2024, 04:09:33 pm
content: I have a Ryzen 5600G (6 cores 12 threads) and I installed a utility that constantly and quietly shows CPU usage on my desktop. There are some applications that make brief usage of more then one thread but for me those are quite rare. It is nice if a "make -j12" finishes in a few minutes instead of half an hour, but that sort of usage is rare for me. Benchmarks show large speed increases for multi core processors, but (unfortunately) the single thread performance is still very much the driving factor. And of course other limitations such as Disk (SSD) I/O and internet bandwidth.Even with applications that do support multi threading, it's rare to see CPU usage above 30% (which suggests only 4 of the 12 threads are actually used). Hyperthreading started in 2002:https://en.wikipedia.org/wiki/Hyper-threadingand now, 22 years later we still have a long way to go before "mainstream" software developers start taking it seriously. I have for example a FreeCAD drawing, that takes several minutes to load, and during that time, CPU usage is a steady 8 percent (i.e 100/12 = 1 thread). It seems that programs are designed as a single thread, and then some limited multithreading is being attempted only after it is discovered that the application gets slow and sluggish.This is of course a generalization. There are also programs that can make good use of all the threads you have. And that makes the usefulness of hyperthreading highly dependent on the software you use. Therefore, I suggest you do some (simple) benchmarks yourself, and do some tests with and without enabling hyperthreading.

author: kjr18
author_rank: Regular Contributor
timestamp: December 21, 2024, 08:59:53 am
content: Quote from: Doctorandus_P on November 18, 2024, 04:09:33 pmWhat is the name of this utility? Seems very useful.

author: brucehoult
author_rank: Super Contributor
timestamp: December 21, 2024, 09:37:30 am
content: Quote from: Doctorandus_P on November 18, 2024, 04:09:33 pmI believe you that is true for you, and it's probably true for most people.However it's not true of developers. Yeah, you might spend an hour editing code using a fraction of one CPU core, but then the difference between a few seconds and a few minutes to build and run your code is the difference between losing your train of thought -- your "flow" -- and not. Also CI (continuous integration) can use a whole bunch of cores. And running thousands of independent unit tests.And especially developers who are helping design an ISA. You think of a new instruction. You add it to the simulator and the compiler. You recompile the compiler to be able to generate code using the new instruction. Then you build all the libraries. Then the Linux kernel. Then all the basic packages for a distro (typically Buildroot or Yocto for speed if you're doing this). It's a LOT of stuff to build to test how your new instruction works, how much difference it makes to code size, how much difference it makes to speed (if your emulator is cycle-accurate, or if you build a hardware core for an FPGA)Many of Apple's core customers are doing things that can use all the cores they can get. Photoshop. Video and audio editing and compressors.QuoteRight, which is why we have CPUs that might drop down close to 2 GHz with all 24 or 32 or 64 cores running flat out, and then burst to 6 GHz when just one or two cores are being used.QuoteDepends on the OS.Apple introduced "Grand Central Dispatch" into Mac OS and iOS and compilers in 2009 -- and incidentally it was added to FreeBSD the same year. Apple quite strongly encourages developers to use GCD.GCD consists of breaking your program into individual processing steps, with inputs, outputs, and dependencies between them. The library then organises the processing steps and decides which ones can be run in parallel based on their dependencies and the number of CPU cores you have.It is not unlike "make", but within a program.At the time GCD was introduced most people had just 2 CPU cores (Core 2 Duo), but of course now 4, 8, 10, 12, 16 are common.This FreeBSD page has a simple explanation and example:https://wiki.freebsd.org/GrandCentralDispatch

author: brucehoult
author_rank: Super Contributor
timestamp: December 21, 2024, 09:47:28 am
content: Quote from: kjr18 on December 21, 2024, 08:59:53 amhtop? nmon? System Monitor? (Task Manager in Windows, Activity Monitor on Mac)Or if you prefer something in the menu bar, System Load Indicator (apt install indicator-multiload) or gnome-system-monitor or TopHat

author: garrettm
author_rank: Frequent Contributor
timestamp: December 22, 2024, 02:13:02 am
content: On modern AMD hardware, disabling SMT lowers performance and does NOT lower power draw. So, for some architectures, there is no tangible benefit of disabling SMT/HT:https://www.phoronix.com/review/amd-epyc-9755-smthttps://www.phoronix.com/review/amd-ryzen-zen5-smt

author: BeBuLamar
author_rank: Super Contributor
timestamp: December 24, 2024, 10:32:37 pm
content: My computer has 6 cores each CPU and each CPU has 12 threads. As someone mentioned it rarely uses a lot of thread but when I tried DxO Photolab 8 it seemed to use all the available cores.

author: 5U4GB
author_rank: Super Contributor
timestamp: December 25, 2024, 03:58:06 am
content: As others have sort of pointed out, it depends on the workload. With an embarassingly parallel benchmark which several people have posted, hyperthreading helps. OTOH if you've got an aggressively single-threaded application (MS Office immediately springs to mind) you want one core in turbo mode and the rest idle as much as possible to allocate the thermal budget to the turbo-mode core.

author: NiHaoMike
author_rank: Super Contributor
timestamp: December 25, 2024, 12:42:02 pm
content: On modern kernels, you can use /sys/devices/system/cpu/smt/control to turn hyperthreading on or off without a reboot, so you can set it to whichever one is better for the particular task you're using it for at the moment.

author: brucehoult
author_rank: Super Contributor
timestamp: December 27, 2024, 01:43:55 am
content: Quote from: NiHaoMike on December 25, 2024, 12:42:02 pmOn Linux you can just directly tell each program which CPU cores it (and it's children) are allowed to use.e.g. on my i9-13900HX laptop,taskset -c 0-15uses only the P cores, with hyperthreading,0-15:2uses only one thread on each P core (or1-15:2uses the other one).16-31uses the E cores.0-15:2,16-31uses the E cores and one hyperthread on each P core.No need to reboot, and you can partition cores between tasks however you wish. e.g. usetasksetto runbashand then everything you run from thatbashwill use only those cores.

author: NiHaoMike
author_rank: Super Contributor
timestamp: December 27, 2024, 04:06:44 am
content: My understanding is that although you can use taskset to block a process from using both threads of a core at once (it's unaware of hyperthreading, mostly the case for old multithreaded software), it will not stop other processes from using the other thread of a core and degrading performance. Ideally, the solution would be some process manager that would allow certain processes to reserve cores so that they would not have other processes contending for resources on those cores.

author: brucehoult
author_rank: Super Contributor
timestamp: December 27, 2024, 07:13:03 am
content: Quote from: NiHaoMike on December 27, 2024, 04:06:44 amYou can do all your other things from a complementary taskset, with neither once including the 2nd hyperthread "core"(s) that you want to go unused.Sure, the OS might still occasionally schedule one of its brief housekeeping tasks onto that hyperthread core, but that's unlikely to make any measurable difference to throughput -- just a little jitter from time to time. If you want real-time tasks or something then you want one or more cores that the OS doesn't manage at all, and that don't share caches or any other resources with OS-managed cores -- preferably with a dedicated ITIM and DTIM. I'm assuming we're doing this on a "close enough is good enough" probabilistic basis.

author: paulca
author_rank: Super Contributor
timestamp: December 27, 2024, 10:02:24 am
content: AMD consumer chips have a load sensing "single thread boost" mechanism. When a heavy single thread load is detected, the CPU schedules it across the 2 fastest cores. This allows the thread to produce more heat but spread it across a wider area and therefore facilitate higher boost clocks for single thread loads.So it's kinda like negative hyperthreading. Instead of running multiple threads per core they are using multiple cores to run one thread.

author: brucehoult
author_rank: Super Contributor
timestamp: December 27, 2024, 10:55:18 am
content: Quote from: paulca on December 27, 2024, 10:02:24 amHow does a CPU (hardware) schedule an OS construct (thread)?Does it dynamically renumber the cores behind the OSes back?

author: ejeffrey
author_rank: Super Contributor
timestamp: December 28, 2024, 02:55:08 am
content: The cpu doesn't actually do that. The scheduler does.Rather, the CPU provides data tables to the scheduler on which cores are preferred. On a multi core system, each CPU can have a different max boost frequency, and in AMD CPUs especially the cost to migrate between different core complexes is high because they don't share L3 cache.

author: brucehoult
author_rank: Super Contributor
timestamp: December 28, 2024, 03:22:32 am
content: Quote from: ejeffrey on December 28, 2024, 02:55:08 amThat is what I would expect.QuoteOn, say, the 9950X, each cluster of 8 cores on a CCD shares 32 MB of L3 cache. As there is an inter-CCD bandwidth of 64 GB/s, the time to transfer the entire L3 from one CCD to the other is 0.5 ms.So if you move a single active thread from one CCD to the idle CCD once every 50 ms that's a 1% overhead.That sounds better than down-clocking by even 100 MHz (1.75%) from 5.7 GHz to me.

author: coppice
author_rank: Super Contributor
timestamp: December 28, 2024, 03:59:54 pm
content: Quote from: ejeffrey on December 28, 2024, 02:55:08 amThis is always the case for any non-homogenous multi-core system. The CPU can't independently do what is needed. The OS can't independently do what is needed. There needs to be cooperation. The horrible early results with hyper-threading were mostly due to the OS being inadequately aware of the nature of the CPUs it was scheduling for, so it would often run 4 threads on 2 CPUs, leaving 2 CPUs idle in a quad CPU package. As the OSes added hyper-thread awareness performance improved. Whatever you do to make cores and memory less symmetric in their behaviour requires the hardware to tell the OS what it looks like, and the OS to understand that information and behave sensibly.

author: paulca
author_rank: Super Contributor
timestamp: December 30, 2024, 01:07:53 am
content: If it is a BIOS option and works in both linux and windows without specific loads.... it's not the OS.The CPU hardware is well aware of what threads are.... an incrementing program counter. Nothing more.

author: coppice
author_rank: Super Contributor
timestamp: December 30, 2024, 02:12:43 pm
content: Quote from: paulca on December 30, 2024, 01:07:53 amThat makes no sense at all. The BIOS turns off the hyperthreading capability in the hardware, so the OS doesn't even see a hyperthread capable environment. x86 CPUs which are hyperthread capable present the virtual CPUs to the OS, and also lets the OS know their nature. If the OS ignores their nature it just sees a lot of cores, and uses them, often very poorly. If the OS is smart enough to use the extra information it can achieve better performance.

author: paulca
author_rank: Super Contributor
timestamp: January 08, 2025, 01:29:49 pm
content: Quote from: coppice on December 30, 2024, 02:12:43 pmIf you run a single thread of, say, Pi32 or some artificial single threaded CPU focused load and look at the AMD CPU core performance graphs you will find it running on 2 cores, not 1. This is handled, as I understand it, at the CPU level, the OS is not involved.I don't know how it's done. I assume the CPU is able to gaurantee the result will be exactly the same as it running on teh single core. Completely transparent to the OS/Application.It's similar to how a single threaded load which it can't do this with will automatically migrate around the cores to spread heat. It will run one core at 100% until it gets to it's de-boost temp and migrate it to the other end of the silicon to another core.My assumption is that the "cores" identified by the CPU-ID and hardware ident are not in fact the actual cores, but abstractions of them, allowing the AMD "fabric" to manage the CPU better than the OS.... of course you can influence that "fabric" in many ways from runtime via driver APIs etc. You can disable the features entirely. I believe you can even disable all core migrations and dynamic thread boosts. This would, of course, not be portable between CPUs.https://www.tomshardware.com/news/amd-introduces-precision-boost-overdrive-2-boosts-single-thread-tremendously

author: ejeffrey
author_rank: Super Contributor
timestamp: January 08, 2025, 04:22:50 pm
content: That's not what PBO2 is. PBO2 is a dynamic overclocking system that allows individual cores to boost to higher than normal frequency dependig on the voltage, current, temperature, and activity across the chip. It also comes with processor data tables on which cores have the highest potential boost frequency that allows the scheduler to prioritize the cores with the highest overclocking potential for single threaded workloads.

author: coppice
author_rank: Super Contributor
timestamp: January 08, 2025, 04:28:57 pm
content: Quote from: paulca on January 08, 2025, 01:29:49 pmIf you run any single thread task on a multi CPU machine you will usually see at least 2 cores working, one running the application, and at least one running the system activities.

author: brucehoult
author_rank: Super Contributor
timestamp: January 08, 2025, 04:37:16 pm
content: Quote from: coppice on January 08, 2025, 04:28:57 pmSystem tasks shouldn't be using a whole core!Here's my laptop right now. The biggest user is htop itself, at 0.7% of one core.

author: brucehoult
author_rank: Super Contributor
timestamp: January 08, 2025, 04:40:07 pm
content: Running a CPU-bound task (perl -e 'while(1){}'). Now TWO other cores are at 0.7%.

author: coppice
author_rank: Super Contributor
timestamp: January 08, 2025, 04:41:34 pm
content: Quote from: brucehoult on January 08, 2025, 04:37:16 pmHe didn't say it was using the whole of 2 cores. He said 2 cores were working. How much of a second core a single threaded task uses will depend on its nature. One that is number crunching may use very little. One doing I/O can often cause a lot of activity on a second core.

author: paulca
author_rank: Super Contributor
timestamp: January 10, 2025, 11:50:48 am
content: AMD chips (I don't know about their Intel cousins) are far more complicated these days than people seem to understand.The thread will split 50/50 plus or minus the factor by which each core is rated, it's temperature and the power limits for it's VRMs.So instead of 1 core running at 100% producing 100% of heat and ending up being clocked at, say 4Ghz when the die heats up. It runs the thread on 2 cores at 50% each. Those two cores at 50% can sustain maybe 4.6Ghz as they are cooler.The end2end result is that your single threaded load ran at 4.6Ghz and not 4.0Ghz. By using 2 cores to share the load.The AMD CPU management systems, including PBO and others are extremely complicated. They are basically automated overclocking systems which monitor and alter the cores and loads at 1000Hz. Always aiming to move load to where it's cool and power is available. Cool cores are boosted higher so they can heat up and the load be moved to another cooler core and repeat.In some circles you will still fine people disabling all of this and running everything with a single fixed clock rate across the board. They then soak test it with a 100% all core load for 24 hours and call it the fastest overclock possible.They are correct, for an all core load for 24 hours. However if you are using the PC as a normal person would and your loads a bursty desktop loads, then boosting the cores 1 or even 2 Ghz higher and then clocking them back just before they overheat actually increases your performance significantly. While at the same time, if you DO run a 100% all core load, say rending a video or compiling a kernel, it will probably be a bit slower than the "All core overclock" was.This a more complete guideIt has got more complicated in the 7 and 9 series though.