Because Ubuntu is where I typically test against given its marketshare and enterprise use/support. And what I typically test against for my Windows vs. (Ubuntu) Linux comparisons. If going for CachyOS or Arch Linux because it's "faster" would conceal the fact that Ubuntu Linux is typically faster than Windows 11 but on this system at least is not.
Yes but the headline should reflect that. Generally saying Linux performs worse is a bit of a exaggeration if you only tested one distro. Next time throw in fedora, I wouldn't care about caschy or arch benchmarks because of the reasons you stated but it would give your headline more merit. Especially if the headline is as generalized as it stays at the moment. To be honest it's what I would expect if you see an outlier like we see now.
Unfortunately, I don't have any added insight/hypothesis besides maybe something power managemen beyond what was detailed in the article... Lenovo and Intel believe it's inline with expectations and they used various internal tools and what not but hadn't provided me with any detailed data on everything they checked or any own internal numbers. SO I don't really have anything else to add there.
But it doesn't align with the last 12~20 laptops I've tested between Ubuntu Linux and Windows out-of-the-box where if loading up say V-RAY, IndigoBench, Blender, etc, and using the official binaries on each platform, Linux has typically always dominated in said workloads for both AMD and Intel laptops. So something isn't aligning quite right there with this ThinkPad versus all the other hardware I have tested with Windows vs. Linux.
I don't follow your publications so sorry if this is a dumb question, but do you modify/normalize or at least inspect the hidden power settings at all before running benchmarks? Like "processor performance autonomous mode" or the various efficiency-class-related settings, say? Or the various firmware settings, like cool-and-quiet or whatever they are?
Do you have your test harness published somewhere to replicate, i.e. what settings you use for thermals at the UEFI layer as well as OS layer, any scheduler changes you might make, driver versions installed, etc.?
Right, unfortunately, was limited by the laptops I have on-hand for (re)testing... With routinely re-testing all laptops fresh, in this case on Ubuntu 25.04, not able to compare to prior dGPU-enabled laptops that since had to be returned to vendors, etc.
There is (unofficial) ROCm support for Strix Halo with ROCm 6.4.1. But like Llama.cpp and such were seg faulting but ROCR-based OpenCL was working and other workloads.
I haven't gotten around to trying it but it's on my TODO list if having the time before needing to send the review unit back (likely next week or so I'd expect)
I'll have more integrated graphics tests to come... Unfortunately I am a one-man show and only so much time to juggle everything. Initially focusing on CPU tests since they tend to be most trouble-free and reliable.
I haven't yet tested ECC with any Zen 5 desktop CPU. But yes in general with Zen 4 that ASRock Rack and Supermicro boards have worked out well. With time will try out ECC on Ryzen 9000 series.
Zen5 appears to officially support up to DDR5 5600, but unfortunately all of the ASRock Rack or Supermicro boards I looked at only supported DDR5 5200.
I may wait for new Zen5 boards, or maybe take a gamble on something like the Asus ProArt, where I saw comments online indicating that ECC is (unofficially?) supported.
Or other ASUS mainboards. For now ASUS seems to be the only desktop mainboard manufacturer that officially mentions in the docs support of "ECC and Non-ECC, Un-buffered Memory".
Yeah it was due to the Open Compute Project AFAIK... Though for a little while AMD was telling me they really meant to call it "Radeon Open eCosystem" before then dropping that too with many still using the original name.
