Live data from Hacker News

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

nietras.com

91–100 of 176 posts

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

#91
post #15

Earlier quoted context omitted.

Humans generate decisions / text information at rates of ~bytes per second at most. There is barely enough humans around to generate 21GB/s of information even if all they did was make financial decisions! So 21 GB/s would be solely algos talking to algos... Given all the investment in the algos, surely they don't need to be exchanging CSV around?

CSV is a questionable choice for a dataset that size. It's not very efficient in terms of size (real numbers take more bytes to store as text than as binary), it's not the fastest to parse (due to escaping) and a single delimiter or escape out of place corrupts everything afterwards. That not to mention all the issues around encoding, different delimiters etc.

> (real numbers take more bytes to store as text than as binary)

Depends on the distribution of numbeds in the sataset. It's quite common to have small numbers. For these text is a more efficient representation compared to binary, especially compared to 64-bit or larger binary encodings.

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

#92
post #87
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…

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.

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

#93
post #70

Earlier quoted context omitted.

They go out their way to segment their markets, ECC, AVX, Optane support (only specific server class skus). I hate it, I hate as a home pc user, I hate it as an enterprise customer, I hate as a shareholder.

Every company does this. If you're grandma only uses a web browser, word processor, and excel, does she really want to spend an additional $50 on a feature she'll not use? Same with NPUs. Different consumers want different features for different prices.

Three fallacies and you are OUT!

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

#94
post #72
post #39

Earlier quoted context omitted.

Erm, maybe file based? JSON is the king if you count exchanges worldwide a sec. Maybe no 2 is form-data which is basically email multipart, and if course there's email as a format. Very common =)

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.

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

#95

Earlier quoted context omitted.

They claim a 3GB/s improvement versus previous version of sep on equal hardware — and unlike “marketing” benchmarks, include the actual speed achieved and the hardware used.

Do note that this speed even before the 3GB/s improvement exceeds the bandwidth of most disks, so the bottleneck is loading data in memory. I don't know of many applications where CSV is produced and consumed in memory, so I wonder what the use is.

"We can parse at x GB/s" is more or less the reciprocal of "we need y% of your CPU capacity to saturate I/O".

Higher x -> lower y -> more CPU for my actual workload.

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

#96
post #62
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…

Intel is horrible with software. My laptop has a pretty good iGPU, but it's not properly supported by PyTorch or most other software. Vulkan inference with llama.cpp does wonders, and it makes me sad that most software other than llama.cpp does not take advantage of it.

Sounds like something to try. Do I just need to compile Vulkan support to use the igpu?

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

#97
post #15

Earlier quoted context omitted.

lots of folks in Finance, you can share csv with any Finance company and they can process it. It's text.

Humans generate decisions / text information at rates of ~bytes per second at most. There is barely enough humans around to generate 21GB/s of information even if all they did was make financial decisions! So 21 GB/s would be solely algos talking to algos... Given all the investment in the algos, surely they don't need to be exchanging CSV around?

The only real example I can think of is the US options market feed. It is up to something like 50 GiB/s now, and is open 6.5 hours per day. Even a small subset of the feed that someone may be working on for data analysis could be huge. I agree CSV shouldn't even be used here but I am sure it is.

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

#98
post #31
post #4

Earlier quoted context omitted.

Yea wtf is that chart, it literally skips 4 cpu generations where it shows “massive performance gain”. Straight to the trash with this post.

4 generations? 5950x is Zen 3 9950x is Zen 5

Sine Zen 2 (3000) the mobile CPUs are up by a thousand respectively to their desktop counterparts. edit: Or Nx2000 where N is from Zen N.

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

#99
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…

I mean, the most interesting part of the article for me: > A bit surprisingly the AVX2 parser on 9950X hit ~20GB/s! That is, it was better than the AVX-512 based parser by ~10%, which is pretty significant for Sep. They fixed it, that's the whole point, but I think there's evidence that AVX-512 doesn't actually benefit consumers that much. I would be willing to settle for a laptop that can only parse 20GB/s and not 2…

That probably just means it's a memory bandwidth bound problem. It's going to be a different story for tasks that require more computation.

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

#100

Earlier quoted context omitted.

They claim a 3GB/s improvement versus previous version of sep on equal hardware — and unlike “marketing” benchmarks, include the actual speed achieved and the hardware used.

Do note that this speed even before the 3GB/s improvement exceeds the bandwidth of most disks, so the bottleneck is loading data in memory. I don't know of many applications where CSV is produced and consumed in memory, so I wonder what the use is.

Decompression is your friend. Usually CSV compresses really well.

Multiple cores decompressing LZ4 compressed data can achieve crazy bandwidth. More than 5 GB/s per core.

Post reply on HN