Live data from Hacker News

21 GB/s CSV Parsing Using SIMD on AMD 9950X

nietras.com

121–130 of 176 posts

Re: 21 GB/s CSV Parsing Using SIMD on AMD 9950X

#122
post #38

It feels crazy to me that Intel spent years dedicating die space on consumer SKUs to "make fetch happen" with AVX-512, and as more and more libraries are finally using it, as Intel's goal is achieved, they have removed AVX-512 from their consumer SKUs. It isn't that AMD has better AVX-512 support, which would be an impressive upset on it's own. Instead, it is only that AMD has AVX-512 on consumer CPUs, because Intel…

In this article, they saw the following speeds: Original: 18 GB/s AVX2: 20 GB/s AVX512: 21 GB/s This is an AMD CPU, but it's clear that the AVX512 benefits are marginal over the AVX2 version. Note that Intel's consumer chips do support AVX2, even on the E-cores. But there's more to the story: This is a single-threaded benchmark. Intel gave up AVX512 to free up die space for more cores. Intel's top of the line consume…

> We'd have to look at actual Intel benchmarks to see, but if the AVX2 to AVX512 improvements are marginal, a multithreaded AVX2 version across more cores would likely outperform a multithreaded AVX512 version across fewer cores.

Look at any existing heavily multithreaded benchmark like Blender rendering. The E-cores are so weak that it just about takes 2 of them to match the performance of an AMD core. If the only difference was AVX512 support then yeah, 24 AVX2 cores would beat 16 AVX-512 cores. But that's not the only difference, not even close.

That's not to say a 24 core Core 9 Ultra Whatever would be slower than a 16 core 9950X in this workload. Just that the E-cores are kinda shit, especially in the wonky counts Intel is using (too many to just be about power efficiency, too few to really offset how slow they are)

Re: 21 GB/s CSV Parsing Using SIMD on AMD 9950X

#123
post #49
post #38

It feels crazy to me that Intel spent years dedicating die space on consumer SKUs to "make fetch happen" with AVX-512, and as more and more libraries are finally using it, as Intel's goal is achieved, they have removed AVX-512 from their consumer SKUs. It isn't that AMD has better AVX-512 support, which would be an impressive upset on it's own. Instead, it is only that AMD has AVX-512 on consumer CPUs, because Intel…

That is what Intel does, they build up a market (Optane) and then do a rug pull (Depth Cameras). They continue to do this thing where they do a huge push into a new technology, then don't see the uptake and let it die. Instead of building slowly and then at the right time, doing a big push. Optane support was just getting mature in the Linux kernel when they pulled it. And they focused on some weird cost cutting move…

Until this day, I miss Optane — I work for a timeseries database company focused on finance, the amount of use cases I have that screams “faster than NVMe, slower than RAM” is insane. And these companies have money to throw at these problems.

Which begs the question, why isn’t anyone else stepping into this gap? Is the technology heavily patented?

Re: 21 GB/s CSV Parsing Using SIMD on AMD 9950X

#124
post #38

It feels crazy to me that Intel spent years dedicating die space on consumer SKUs to "make fetch happen" with AVX-512, and as more and more libraries are finally using it, as Intel's goal is achieved, they have removed AVX-512 from their consumer SKUs. It isn't that AMD has better AVX-512 support, which would be an impressive upset on it's own. Instead, it is only that AMD has AVX-512 on consumer CPUs, because Intel…

Isn't AVX-10 on the horizon, which will have most of the goodies that AVX-512 had? (I'm actually not even sure what the difference is supposed to be between them.)

AVX-10 used to have a AVX-10/256 version that's AVX-512 but without the 512-bit registers, but that's gone as of recently, so now AVX-10 is just a set of most AVX-512 extensions, and the stated goal is to, for future versions, guarantee each successive one being a superset of the previous (as opposed to AVX-512 with many independent extensions).

Re: 21 GB/s CSV Parsing Using SIMD on AMD 9950X

#125
post #49
post #38

It feels crazy to me that Intel spent years dedicating die space on consumer SKUs to "make fetch happen" with AVX-512, and as more and more libraries are finally using it, as Intel's goal is achieved, they have removed AVX-512 from their consumer SKUs. It isn't that AMD has better AVX-512 support, which would be an impressive upset on it's own. Instead, it is only that AMD has AVX-512 on consumer CPUs, because Intel…

That is what Intel does, they build up a market (Optane) and then do a rug pull (Depth Cameras). They continue to do this thing where they do a huge push into a new technology, then don't see the uptake and let it die. Instead of building slowly and then at the right time, doing a big push. Optane support was just getting mature in the Linux kernel when they pulled it. And they focused on some weird cost cutting move…

I made the mistake early in our startup of spending several months and quite a bit of cash building our first iot product on the Intel Edison platform, only to get zero support on the bugs in the SPI chip and the non-existent (but advertised) microcontroller. We finally gave up and made our own boards based on another SOM (and eventually stopped building boards entirely) and they rather unceremoniously cancelled the Edison in 2017. I guess nobody else was surprised, but I had naively thought the platform did have potential and a huge company like Intel would support the things they sold.

Re: 21 GB/s CSV Parsing Using SIMD on AMD 9950X

#127
post #72

Earlier quoted context omitted.

I honestly wonder if JSON is king. I used to think so until I started working in fintech. XML is unfortunately everywhere.

JSON isn't great for tabular data. And an awful lot of data is tabular.

Yeah, I don’t like parsing XML, but I’d rather do that than deal with the Lovecraftian API design that comes with complex JSON representations.

Re: 21 GB/s CSV Parsing Using SIMD on AMD 9950X

#128
post #82

Earlier quoted context omitted.

> What the VLIW of Itanium needed and never really got was proper compiler support. This is kinda under-selling it. The fundamental problem with statically-scheduled VLIW machines like Itanium is it puts all of the complexity in the compiler. Unfortunately it turns out it's just really hard to make a good static scheduler! In contrast, dynamically-scheduled out-of-order superscalar machines work great but put all the…

>What happened was that static scheduling stayed really hard while the transistor overhead for dynamic scheduling became irrelevantly cheap Is the latter part true? AFAIK most of modern CPU die area and power consumption goes towards overhead as opposed to the actual ALU operations.

If it's pure TFLOPs you're after, you do want a more or less statically scheduled GPU. But for CPU workloads, even the low-power efficiency cores in phones these days are out of order, and the size of reorder buffers in high-performance CPU cores keeps growing. If you try to run a CPU workload on GPU-like hardware, you'll just get pitifully low utilization.

So it's clearly true that the transistor overhead of dynamic scheduling is cheap compared to the (as-yet unsurmounted) cost of doing static scheduling for software that doesn't lend itself to that approach. But it's probably also true that dynamic scheduling is expensive compared to ALUs, or else we'd see more GPU-like architectures using dynamic scheduling to broaden the range of workloads they can run with competitive performance. Instead, it appears the most successful GPU company largely just keeps throwing ALUs at the problem.

Re: 21 GB/s CSV Parsing Using SIMD on AMD 9950X

#129
post #92
post #87

Earlier quoted context omitted.

No, VLIW is even worse than this. Describing it as a compiler problem undersells the issue. VLIW is not tractable for a multitasking / multi tenant system due to cache residency issues. The compiler cannot efficiently schedule instructions without knowing what is in cache. But, it can’t know what’s going to be in cache if it doesn’t know what’s occupying the adjacent task time slices. Add virtualization and it’s a di…

It only works for fixed workloads, like accelerators, with no dynamic sharing.

Yeah, VLIW is still used for stuff like DSP and GPUs, but it doesn't make sense for general computing.

Re: 21 GB/s CSV Parsing Using SIMD on AMD 9950X

#130
post #124

Earlier quoted context omitted.

Isn't AVX-10 on the horizon, which will have most of the goodies that AVX-512 had? (I'm actually not even sure what the difference is supposed to be between them.)

AVX-10 used to have a AVX-10/256 version that's AVX-512 but without the 512-bit registers, but that's gone as of recently, so now AVX-10 is just a set of most AVX-512 extensions, and the stated goal is to, for future versions, guarantee each successive one being a superset of the previous (as opposed to AVX-512 with many independent extensions).

AVX-10 was mostly just a way for Intel to provide an excuse for why they're still a few years out from having AVX-512 in their E cores: they're targeting a standard that's not here yet. But the excuse doesn't really work now that AVX-10 requires doing a full AVX-512 implementation. We're back to Intel just dragging their heels on implementing the AVX-512 support that they were obviously going to need all along.
Post reply on HN