Intel AVX-512 A Big Win For... JSON Parsing Performance

[phoronix]

Phoronix: Intel AVX-512 A Big Win For... JSON Parsing Performance

In addition to the many HPC workloads and other scientific computing tasks where Intel's AVX-512 performance on their latest processor proves very beneficial, it also turns out AVX-512 can provide significant benefit to a much more mundane web server task: JSON parsing. The simdjson project that is focused on "parsing gigabytes of JSON per second" this week issued simdjson 2.0 and is headlined by an Intel-led contribution of AVX-512 support.

https://www.phoronix.com/vr.php?view=31150

[marios]

Well, if JSON parsing performance affects your use case, you shouldn't be using JSON in the first place...

[Chugworth]

But if my processor doesn't support AVX-512 then I won't be able to parse gigabytes of JSON per second.

[Michael]

But if my processor doesn't support AVX-512 then I won't be able to parse gigabytes of JSON per second.

Even with AVX2 it can do GB/s.

[uid313]

JSON is great and is already fast, but if you've got gigabytes of data then JSON isn't the right format for you, then there are other better alternatives available such as BSON, UBJSON, CBOR, MessagePack, Protocol Buffers, etc.

[ddriver]

AVX 512 appears to be the point of rapidly diminishing returns. Where avx 512 sees the most uplift is dedicated purpose specific instructions that are simply absent from avx2. When you are simply porting old core from 256 to 512 bits, improvements aren't that stellar as in those niche micro benchmarks.

And sure, 30% is good, but if you care about performance that much, please use a binary format. Anyway, nice contributions from intel, just in time for zen 4.

Keep in mind, that while you are offloading stuff to avx 512, and improving the particular workload performance, in practice, that may not be the only workload the system is running. Using avx 512 puts a strain on the cpu that impacts its overall pipeline performance. So technically, going all out on a particular workload for the sake of a synthetic score may not always be the interest of overall optimal system performance and efficiency.

Also, this may actually be quite slow for small json documents, you really need a certain amount of bulk in order to be worth going through the high throughput code path. For small files, the scalar pipeline may perform a bit better.

[ssokolow]

This all assumes that you have control of the input format you're consuming. Far too often IRL, you're just dealing with whatever was thrown at you. (eg. Parsing an archive of data that seemed good when they designed it, but that was before data accumulated over the years.)

[F.Ultra]

JSON is great and is already fast, but if you've got gigabytes of data then JSON isn't the right format for you, then there are other better alternatives available such as BSON, UBJSON, CBOR, MessagePack, Protocol Buffers, etc.

I think we need to see raw numbers before we can make this a certainty. E.g the existing benchmarks for Protocol Buffers does not show that great performance for parsing, now they are done on older Xeons so it would be interesting to see a comparable benchmark.

[schmidtbag]

I get what makes JSON useful, but in my experience, I've overall found it more annoying to work with than useful. For basic data, it's a bit bloated and difficult to read (as a human) compared to XML. With some added complexity, most JSON parsing tools just can't seem to figure out what they're reading.
It isn't that hard to write code to parse it yourself but it involves a bit of trial and error when you don't fully know the data that you're working with, which is just really tedious. It's even more tedious when the structure of the file you're reading in dynamically changes.

When you consider that it takes something like AVX-512 to accelerate JSON parsing, that tells me perhaps it wasn't a good implementation.

[krzyzowiec]

For basic data, it's a bit bloated and difficult to read (as a human) compared to XML.

I feel like XML fits that description better than JSON, which is very readable to me.