Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nietras.com

Post reply on HN
Print view View original

51–60 of 176 posts

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

#51

Post by tetha »

freeone3000 wrote: post #40
stabbles wrote: post #36

Earlier quoted context omitted.

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.

Slower than network! In-memory processing of OLAP tables, streaming splitters, large data set division… but also the faster the parser, the less time you spend parsing and the more you spend doing actual work

This is honestly something that caught me off-guard a bit. If you have good internal network connectivity, small queries and your relational database has the data in memory, it can be faster to fetch data from the DB via the network than reading it from disk.

Like, sure, I can give you an application server with faster disks and more memory and you or me are certainly capable of implementing an application server that could load the data from disk faster than all of that. And then we build caching to keep the hot data in memory, because that's faster.

But then we've spent very advanced development resources to build a relational database with some application code at the edge.

This can make sense in some high frequency trading situations, but in many more mundane web-backends, a chunky database and someone capable of optimizing stupid queries enable and simplify the work of a much bigger number of developers.

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

#52

Post by wat10000 »

zzbn00 wrote: post #15
segmondy wrote: post #11

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?

Standards (whether official or de facto) often aren't the best in isolation, but they're the best in reality because they're widely used.

Imagine you want to replace CSV for this purpose. From a purely technical view, this makes total sense. So you investigate, come up with a better standard, make sure it has all the capabilities everyone needs from the existing stuff, write a reference implementation, and go off to get it adopted.

First place you talk to asks you two questions: "Which of my partner institutions accept this?" "What are the practical benefits of switching to this?"

Your answer to the first is going to be "none of them" and the answer to the second is going to be vague hand-wavey stuff around maintainability and making programmers happier, with maybe a little bit of "this properly handles it when your clients' names have accent marks."

Next place asks the same questions, and since the first place wasn't interested, you have the same answers....

Replacing existing standards that are Good Enough is really, really hard.

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

#53

Post by bee_rider »

tetha wrote: post #51
freeone3000 wrote: post #40

Earlier quoted context omitted.

Slower than network! In-memory processing of OLAP tables, streaming splitters, large data set division… but also the faster the parser, the less time you spend parsing and the more you spend doing actual work

This is honestly something that caught me off-guard a bit. If you have good internal network connectivity, small queries and your relational database has the data in memory, it can be faster to fetch data from the DB via the network than reading it from disk. Like, sure, I can give you an application server with faster disks and more memory and you or me are certainly capable of implementing an application server tha…

You can also get this with Infiniband, although it is less surprising, and basically what you’d expect to see.

I did once use a system where the network bandwidth was in the same ballpark as the memory bandwidth, which might not be surprising for some of the real HPC-heads here but it surprised me!

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

#54

Post by perching_aix »

winterbloom wrote: post #2

This is a staggering ~3x improvement in just under 2 years since Sep was introduced June, 2023. You can't claim this when you also do a huge hardware jump

> You can't claim this when you also do a huge hardware jump

Well, they did. Personally, I find it an interesting way of looking at it, it's a lens for the "real performance" one could get using this software year over year. (Not saying it isn't a misleading or fallacious claim though.)

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

#55

Post by tadfisher »

Aardwolf wrote: post #13

Take that, Intel and your "let's remove AVX-512 from every consumer CPU because we want to put slow cores on every single one of them and also not consider multi-pumping it"

A lot of this stems from the 10nm hole they had to dig themselves out from. Yields are bad, so costs are high, so let's cut the die as much as possible, ship Atom-derived cores and market it as an energy-saving measure. The expensive parts can be bigger and we'll cut the margins on those to retain the server/cloud sector. Also our earnings go into the shitter and we lose market share anyway, but at least we tried.

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

#56

Post by hermitcrab »

adra wrote: post #39
hermitcrab wrote: post #17

Earlier quoted context omitted.

For all its many weaknesses, I believe CSV is still the most common data interchange format.

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 meant file-based.

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

#57

Post by hermitcrab »

speed_spread wrote: post #50
mcraiha wrote: post #27

Earlier quoted context omitted.

Excel does not output Parquet.

True. But also Excel probably collapses into a black hole going straight to hell trying to handle 21GB of data.

Excel .xlsx files are limited to 1,048,576 rows and 16,384 columns.

Excel .xls files are limited to 65,536 rows and 256 columns.

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

#58

Post by wtallis »

tadfisher wrote: post #55
Aardwolf wrote: post #13

Take that, Intel and your "let's remove AVX-512 from every consumer CPU because we want to put slow cores on every single one of them and also not consider multi-pumping it"

A lot of this stems from the 10nm hole they had to dig themselves out from. Yields are bad, so costs are high, so let's cut the die as much as possible, ship Atom-derived cores and market it as an energy-saving measure. The expensive parts can be bigger and we'll cut the margins on those to retain the server/cloud sector. Also our earnings go into the shitter and we lose market share anyway, but at least we tried.

This issue is less about Intel's fab failures and more about their inability to decouple their architecture update cadence from their fab progress. They stopped iterating on their CPU designs while waiting for 10nm to get fixed. That left them with an oversized P core and an outdated E core, and all they could do for Alder Lake was slap them onto one die and ship it, with no ability to produce a well-matched pair of core designs in any reasonable time frame. We're still seeing weird consequences of their inability to port CPU designs between processes and fabs: this year's laptop processors have HyperThreading only in the lowest-cost parts—those that still have the CPU chiplet fabbed at Intel while the higher core count parts are made by TSMC.

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

#59

Post by raron »

bombela wrote: post #48
trollbridge wrote: post #19

Earlier quoted context omitted.

It's become a very common interchange format, even internally; it's also easy to deflate. I have had to work on codebases where CSV was being pumped out at basically the speed of a NIC card (its origin was Netflow, and then aggregated and otherwise processed, and the results sent via CSV to a master for further aggregation and analysis). I really don't get, though, why people can't just use protocol buffers instead.…

protobuf is more friction, and actually slow to write and read. For better or worse, CSV is easy to produce via printf. Easy to read by breaking lines and splitting by the delimiter. Escaping delimiters part of the content is not hard, though often added as an afterthought. Protobuf requires to install a library. Understand how it works. Write a schema file. Share the shema to others. The API is cumbersome. Finally t…

> For better or worse, CSV is easy to produce via printf. Easy to read by breaking lines and splitting by the delimiter. Escaping delimiters part of the content is not hard, though often added as an afterthought.

Based on the amount of software I seen producing broken CSV or can't parse (more-or-less) valid CSV, I don't think that is true.

It seems to be easy, because just printf("%s,%d,%d\n", ...) but it is full of edge cases most programmers don't think about.

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

#60

Post by jajko »

zzbn00 wrote: post #26
internetter wrote: post #18

Earlier quoted context omitted.

> Humans generate decisions / text information at rates of ~bytes per second at most Yes, but the consequences of these decisions are worth much more. You attach an ID to the user, and an ID to the transaction. You store the location and time where it was made. Ect.

I think these would add only small amount of information (and in a DB would be modelled as joins). Only adds lots of data if done very inefficiently.

Why are you theoretising? I can tell you from out there its used massively, and its not going away in contrary. Even rather small banks can end up generating various reports etc. which can easily become huge.

The speed of human decision has basically 0 role here, as it doesn't with messaging generally, there is way more to companies than just direct keyboard-to-output link.

Post reply on HN