Here are some numbers for my 10th to 11th z590 upgrade
To recap, i9-11900K at 5.1 GHz multicore
NOTES
I've been mystified by a long-term problem on my build that
kernel_task will eat from 35–75% of a core.
A 35% wasted CPU had reduced my 10900 single core benchmarks by 12% and multi-core proportionally, about 1.5%. On this 11900, kernel_task was constantly burning 75% of a core! I felt I had to get to the bottom of this before benchmark results would have real meaning.
Tl;dr background:
On my 10900 build, I discovered by accident that the system would properly idle if OpenCore is loaded from from a thumb drive instead of the OS NVMe. As I recalled copyng the thumb drive EFI from the same source as the NVMe, I didn't exhaustively search for differences. After installing the 11900, kernel_task is using even more CPU.
A huge aside — kernel_task is an odd program, because it's a kernel process that schedules a ton of what's called "bottom-half" driver code in old Unix (e.g., BSD / Sun Solaris parlance). Top-half kernel code gets called from user-space when a program wants a device to do something for it, while bottom-half kernel code gets called (pushed) by devices (interrupts) as those devices get work done. MacOS is based on CMU's Mach microkernel which has a much richer kernel structure for device schedluling and inter-processor communication than typical Unix derivatives. The Mach microkernel is a gangly collection of SW threads which implement messaging — and therefore interlocks — that let a lot of device activity run concurrently, which is good for system performance and stability. (I don't actually know how Linux has evolved in this regard but MacOS is mosdef not Linux kernel, nor is it BSD, in spite of strong associations with the latter.)
So one of the many, many device-level chores that kernel_task performs is the efficient wasting of time when a mac mobile CPU starts to overheat or a it looks like it's overheating because temperature sensor is broke, which led o forums full of Macbook users complaining that kernel_task is hogging their CPU and slowing down their Mac, which it in fact does. But it also does a million other device-related chores, and any sort of device pathology might lead to kernel_task wasting time.
A SOLUTION APPEARS
By searching for info on Mac SW performance profiling I learned about spindump in Activity Monitor. It collects code usage statistics on the running system.
I ran spindump on my otherwise idle system, then searched the output for threads using a lot of CPU time. What stood out was a digital-audio related threads with lots of activity
On a pure hunch, I thought "AppleALC — I've never understood my own audio layout choice for boards Realtek ALC4080." It's not even mentioned in the AppleALC notes, but some reading told me that its an upgraded ALC1220, which has about 20 layout ID possibilities. I just guessed at one when originally creating this build and it worked.
As I mentioned in previous msg, trying to solve a GPU blank-screen bugaboo I found by that WhateverGreen actually isn't essential for my build. Actually, WEG figures out most configs by itself these days, so DeviceProperties for graphics is often no more than a hint to WEG that it should do a default something, which OpenCore users mistake for having made an intelligent config choice.
I have just gone through a process of elimination of various OpenCore elements to learn more about what my system really needs versus pure boilerplate.
So, once I discovered that kernel_task was busy wasting time futzing with audio, I thought maybe I should just remove my layout choice and let AppleALC decide what's best. Voila! System idle CPU is now truly idle.
OK, SO HERE ARE MY RESULTS
Asus Hero XIII z590
i9-11900K, 5.1 GHz, DDR4-3600
Samsung 980 Pro in PCIe 4.0 slot:
View attachment 548899
View attachment 548900
View attachment 548901View attachment 548902View attachment 548903View attachment 548904View attachment 548905View attachment 548906
Just for reference...
Western Digital SN750 (PCIe 3)
View attachment 548907
LAST THOUGHTS
- Best 10900K GB5 single core was 1460.
The 11900K provides a solid 25% single core bump.
- 11900K needs 5.1 GHz to multicore at same score as i9-10900K. This translates into 4C higher full-load temp of 96-98C in 78F room. The system is stable overnight though.
- PCIe 3.0 vs 4.0 makes no difference on GB5 Metal score.
- After I sorted out the CPU waste, my W5700 GPU metal score went down 10% !! Lord giveth and taketh.
- PCIe 4.0 NVMe shows a strong 75% throughput gain. 980 Pro is regarded as top-performers in IOPs.
This system makes no sense. It costs a fortune, is hot as hell, and just holds its own with a Studio M1 Max.
But it's been fun and challenging learning experience.
Thank you community!