23 comments

[ 3.8 ms ] story [ 63.4 ms ] thread
Too bad that these AMD CPU's also contain convenient capabilities through PSP to add a hardware backdoor to a computer which one cannot detect from the OS.

@Phoronix: RISC-V-based and other open processors and computers are much more interesting. Could you test and report about compatbility of open and consumer-friendly computers with linux?

You say 'also' but aren't elaborating sufficiently.

It's too bad modern high-performance consumer CPUs are all paired with non-free platform services (Intel ME, AMD PSP) that provide attack vectors for organized crime and governments.

Do you know of a RISC-V CPU suitable for desktop use? As far as I know, no one yet produced any silicon for that market.
Seriously, I don't know of any publicly available RISC-V silicon with even an MMU, say nothing of 'desktop' class.
SiFive announced that at Hot Chips 2017 (last week): their quad+1 core is coming out early next year.

In addition to that, I expect to see some interesting announcements at the RISC-V workshop in Nov.

Patience, patience. It's likely that RISC-V adoption will happen bottom up, first deeply embedded space (like NVIDIA, who is using it internally in the GPU for managements). Next, bigger cores will also happen especially where there's no (perceived) advantage to using ARM. A standalone chip will probably come late and will likely come from China from someone looking for a way to stand out from the myriad of ARM vendors out there.

Just the idle musings of an ARM-chair analyst.

"RISC-V-based" does not automatically mean "open". Vendors who put RISC-V in an SoC are free to add their own PSP or ME equivalents. Also, the processor itself is a small portion of a fully functioning computer. Things like GPU, wifi, bluetooth etc are most likely going to be proprietary.
Nobody cares about ME/PSP/etc. You might, but nobody will stop buying these chips just because of that.
I care, and I'm not alone. The problem and it's consequences aren't widely known outside of the tech community.
Does anybody know how long it takes for a 1950X to compile the latest Linux kernel? I know that for 2xEPYC it is circa 15 seconds.
In the article he says he gets it down to ~36 seconds.
How things have improved. I remember my 386DX/33 with 4MB RAM + 16MB swap that took a little over 24 hours to compile a Linux kernel back in the mid-nineties ;-) Now get off my lawn kids..
Compiled gentoo for a week a few years ago - a kid!
Ah Phoronix tests. Run a lot of things, show a lot of numbers, but never worry about meaning (or correctness).

So, can someone explain the Scitkit-Learn 0.17.1 results?

At least the good thing is you can run the same benchmark locally and figure out what went wrong. Anandtech posted similarly wonky results for Chromium compiles on Threadripper, but that one isn't reproducible.
I think they "explained" afterwards that they use an older version of Chromium that predates the switch to clang and spends all of it's time in the single-threaded MSVC linker. (Which immediately explains much of their results...)
> Run a lot of things, show a lot of numbers, but never worry about meaning (or correctness).

You've just described every single benchmark article that was ever published.

Yet, Phoronix stands out among their peers as their tests are actually scientific, objective and reproducible.

No, in fact many review sites delve in deeper when benchmark results don't match expectations, and those moments are usually very informative.

The result I quoted makes no real sense. It may be scientific, objective and reproducible, it's also a sign something is seriously wrong.

Love to see the benchmark on clean build of Android Platform (AOSP) code base.

I remember it took somewhere between 40 -minutes - 2 hours depend on system and which AOSP version to build.

Is this with Threadripper in NUMA mode or in UMA mode? I don't think the article says.

I think UMA might be the default.

Is Threadripper a decent buy for a workstation setup? Or is Xeon still king?
Read the benchmarks. Then judge for yourself for your specific workload.