Hacker News Reader

Comment by tbenst | Hacker News Reader

Wish they’d review on Linux. Windows does not seem like the target audience given all the limitations.

I've played with the AMD Daytona Rome Server (two EPYC sockets, 2*64 = 128 cores, 256 threads), with RHEL, and it rocks. However it's quite hard to find workloads that keep all 256 threads busy at once. Most builds aren't nearly parallel enough, most programs can't find work for 256 threads. So as a personal machine 128 or 256 threads aren't really worth it unless money is no object. Likely the best current use for these is as servers for running large numbers of virtual machines or containers.

Making it an ESXi host would be the obvious solution.

Blender's Cycles renderer would also eat those cores for lunch with a detailed enough scene.

And get raked over the coals with vmWare's new per core license update? Only quad channel? Only 256gb of ram supported?

A pair of used 7601s, motherboard, ram, power supply and chassis would still be cheaper for a SOHO setup.

I am craving one of these for my superoptimizer. The level of task parallelism I have is north of 100M independent jobs; my last run took a single-core machine 20 days. It's pretty rare to have a workload like this but as more machines ship with >16 cores, I think more developers will look at the order-of-magnitude improvements of parallelizing their tasks where possible.

Of course, not everything can be parallelised.

In what context are you working with Superoptimizers, if you don't mind me asking?

Can you tell us more about this superoptimizer?

It's an SMT-based solver to make fast "single-lane" SIMD calculations for AVX2 (doing different things in multiple lanes, doing AVX512 or SSE or ARM or general purpose registers, etc. are all on my todo list). Branch free code only. Can handle up to 4 or 5 instruction sequences including things like generating constants like 128-bit tables for PSHUFB (considering PSHUFB as a single-lane operation where every lane looks up a table).

Sounds very cool! I recently wondered about the possibility of superoptimizing vectorized code, so glad to hear about it!

Would you like to chat about opportunities to do analagous work for GPU instruction sets?

I work at a startup making high-performing GPU software and compilers, incidentally including a regex engine! (We can't quite match HyperScan on the CPU, but support capture groups and very high throughput on GPUs.) We also have several other interesting projects, and would like to start a superoptimizer at some point.

P.S. After reading your blog, one of our engineers said: "We see you like PSHUFB. So do we."

Why are you sticking to desktop processors with that kind of workloads?

Because this is a hobby project and I was doing it at home? eventually I will be doing this in the cloud or with a home-based server or both, but you have to start somewhere. Much of the work is currently centered around "being less stupid" rather than "try to parallelize more" as wasting tons of time doing pointless solves is not a good idea - I've already got about 80-100x speed improvements from optimizations (not looking at sequences I can prove won't work, not looking at sequences that I can prove "do the same thing as some other sequence").

Could you run it on the GPU then? Or does it have a lot of branches?

It uses an SMT solver (can use Z3, Yices or Boolector) all of which are very complex and branchy. So no GPGPU - maybe some specialist in SAT solving or SMT could build that one day, but that person would not be me.

What are you superoptimizing?

>However it's quite hard to find workloads that keep all 256 threads busy at once.

Run Crysis only on the CPU.[0]

[0] https://www.youtube.com/watch?v=1LaKH5etJoE&t=10m37s

There CPUs are not great for lots of VMs because the memory bandwidth then becomes limiting. So you don't get the full performance out of your VMs compared to having more boxes with smaller CPUs.

This is the exact same conclusion we've come to also.

I work at a video production company, with a good mix of Linux, FreeBSD, and Windows for the Adobe torture.

Threadripper: incredible. The CPU is so strong, we struggle (NVMe RAID0) to keep up with disk IO.

So I thought some of our more parallel tasks could be moved to Epyc.

In the end 80-90% of the cores sit idle. So it got repurposed to a VMHost, and it does that good well enough.

https://www.phoronix.com/scan.php?page=article&item=3990x-th...

They really should have done both Windows and Linux for these type of non-gaming processors. Expect more from Anandtech.

they already ran the benchmarks three times just for windows. it would be nice to see linux numbers too, but you can't criticize the level of effort they put in.

Exactly. I'd say there's a fair chance that anyone playing about with this type of hardware will want to be tweaking fairly low-level config etc. of the type that's hidden in Windows anyhow.

I've been using my 64-core threadripper on ubuntu without a problem.

How's that htop looking?

on my vertical monitor it's still usable.

I agree. An even bigger problem is that most of the benchmark suite is completely irrelevant to what these CPU's are going to be used for. These are meant for servers. They should keep that in mind when selecting what benchmarks and which operating system to use.

The Threadripper CPUs are meant for workstations / high-end desktops (HEDT), not servers. For servers, you'd want the EPYC line. The benchmark selection is somewhat reasonable, though yes, you'd want some Linux tests in there.

While some platforms are certainly designed with long term always-on use in mind, "meant to" isn't quite right.

We mostly operate sTR4s as HEDTs, but we also have X399 server boards with IPMI and 10GbE in a board configuration designed to be installed racked. To us, there's only a minor functional difference in role.

You just answered the question. It would be interesting to see TR and EPYC head-to-head in server workloads, to confirm or deny the theory that EPYC is better for them.

Depends on the workload, but EPYC's 8 channel memory support would definitely be an advantage.

Well, maybe. I would not be willing to claim it without showing that some practical workload was bound by memory throughput.

Servers can often use more than 256 GB RAM and 4 memory channels, like the EPYC line these are based on. I'd like to see it benchmarked as a workstation for local builds (both Windows and Linux) and for accessing and processing in parallel 100 GB+ data in RAM (for quicker prototyping than GPUs, or verification). Those would be my main uses.

What benchmarks do you think would be relevant? This seems like a part that's designed for AV production, 3D and SFX work. It could be used in a server-like role, but, for 500 more, the EPYC counterpart is a much better deal.

I think compiling, data processing and similar workloads are more relevant here. For the tasks you mention, the GPU would seem more important.

I thought so, but a couple days back someone pointed me to this: https://stackoverflow.com/questions/38029698/why-do-we-use-c...

Reply on news.ycombinator.com