4 ms·

So it achieves the speed gains by using simd CPU instructions. Do most architectures support simd (including arm)? Also, iirc the biggest negative of this libr

by umvi 7y ago

So it achieves the speed gains by using simd CPU instructions. Do most architectures support simd (including arm)? Also, iirc the biggest negative of this library last time was that the API was super unintuitive (compared to, say, nlohmann). Glad to see progress has been made here. Would love to see a quality python wrapper for this library.

saagarjha 7y ago
Most modern machines have some sort of SIMD or vector instructions.
deleted 7y ago
[deleted]
jchw 7y ago
Yes, ARM has the NEON extensions for SIMD. Definitely most modern machines have some SIMD extensions/instructions.
code_biologist 7y ago
Not sure if it's quality, but I found this: https://github.com/TkTech/pysimdjson https://github.com/TkTech/pysimdjson
- TkTech 7y ago
  It's a bit out of date, give me a bit to update to 0.3.0.
  - codetrotter 7y ago
    The tables of time taken, at the bottom of the README, do not include units that I could tell. Would personally prefer if it did. For example, if it’s in second you could change the column titles in each of the two tables to add the word “seconds” in parentheses for the columns that have the times taken listed.
  - Twirrim 7y ago
    Oh awesome. I was hoping for a python library leveraging it, and that brings in some useful features to boot.
glangdale 7y ago
We have ARM support. I wrote the original ARM code. I'm also, sadly, responsible for some of the not-too-ergonomic API code from the original release - it was always more intended to be a quickie research code at first so the API was a bit of an afterthought. Glad to see that it's been improved by other folks.
jkeiser 7y ago
Worth pointing out: I thought it was just the SIMD that made it fast when I first got involved. It turns out that while it helps, it's just a tool that helps to achieve the real gain: eliminating branches (if statements) that make the processor stumble and fall in its attempts to sprint ahead (speculative execution). simdjson's first stage pushes this capability really far towards its limit, achieving 4 instructions per cycle by not branching. And yes, 1 cycle is the smallest amount of time a single instruction can take. Turns out a single thread is running multiple instructions in parallel at any given time, as long as you don't trip it up! Parsing is notoriously serial and branchy, which is what makes simdjson so out of the ordinary. It's using a sort of "microparallel algorithm," running a small parallel parse on a SIMD-sized chunk of JSON (16-32 bytes depending on architecture), and then moving to the next. And yeah, you have to go back over a decade to find CPUs that don't have SIMD. simdjson runs on those too, just obviously doesn't use SIMD instructions :)
- glangdale 7y ago
  This is a good explanation of why it's fast. An interesting point with the design of simdjson loses its branchlessness in "stage 2". I originally had a bunch of very elaborate plans to try to stay branchless far further into the parsing process. It proved just too hard to make it work. There were some promising things that ultra-modern Intel chips - meaning Icelake - and future iterations of ARM (SVE/SVE2) - are adding to their SIMD abilities, so it might be worth revisiting this in a few years (there aren't too many Icelake boxes out there and SVE barely exists).
  - jkeiser 7y ago
    Yep. Most of stage 2's branchiness essentially comes from "is the next thing an array? object? string? number? Handle it differently if so." Making it so you can handle all the brackets at once, all the strings at once, all the numbers at once, would make a big difference, and we're thinking about that. Another thing that could help is making the if statement more predictable using type information from the user. get<int>() could mean "I expect this next thing to be an integer, so parse it that way and just yell if it's not, please." It's difficult. But it's why I'm still so fascinated! Solving JSON thoroughly and completely will give us a lot of information on how to quickly parse XML, YAML, and other file formats. We've clearly been collectively doing parsing wrong (including me) if there's this much of a gap. It's exciting to see something innovative and new in this domain and even being able to contribute to it :) @lemire deserves a ton of credit for making an actual project out of his work and promoting it; I likely wouldn't have heard of it otherwise.

by umvi 7y ago

saagarjha 7y ago

Most modern machines have some sort of SIMD or vector instructions.

deleted 7y ago

[deleted]

jchw 7y ago

Yes, ARM has the NEON extensions for SIMD. Definitely most modern machines have some SIMD extensions/instructions.

code_biologist 7y ago

Not sure if it's quality, but I found this: https://github.com/TkTech/pysimdjson https://github.com/TkTech/pysimdjson

TkTech 7y ago
It's a bit out of date, give me a bit to update to 0.3.0.
- codetrotter 7y ago
  The tables of time taken, at the bottom of the README, do not include units that I could tell. Would personally prefer if it did. For example, if it’s in second you could change the column titles in each of the two tables to add the word “seconds” in parentheses for the columns that have the times taken listed.
- Twirrim 7y ago
  Oh awesome. I was hoping for a python library leveraging it, and that brings in some useful features to boot.

glangdale 7y ago

We have ARM support. I wrote the original ARM code. I'm also, sadly, responsible for some of the not-too-ergonomic API code from the original release - it was always more intended to be a quickie research code at first so the API was a bit of an afterthought. Glad to see that it's been improved by other folks.

jkeiser 7y ago

Worth pointing out: I thought it was just the SIMD that made it fast when I first got involved. It turns out that while it helps, it's just a tool that helps to achieve the real gain: eliminating branches (if statements) that make the processor stumble and fall in its attempts to sprint ahead (speculative execution). simdjson's first stage pushes this capability really far towards its limit, achieving 4 instructions per cycle by not branching. And yes, 1 cycle is the smallest amount of time a single instruction can take. Turns out a single thread is running multiple instructions in parallel at any given time, as long as you don't trip it up! Parsing is notoriously serial and branchy, which is what makes simdjson so out of the ordinary. It's using a sort of "microparallel algorithm," running a small parallel parse on a SIMD-sized chunk of JSON (16-32 bytes depending on architecture), and then moving to the next. And yeah, you have to go back over a decade to find CPUs that don't have SIMD. simdjson runs on those too, just obviously doesn't use SIMD instructions :)

glangdale 7y ago
This is a good explanation of why it's fast. An interesting point with the design of simdjson loses its branchlessness in "stage 2". I originally had a bunch of very elaborate plans to try to stay branchless far further into the parsing process. It proved just too hard to make it work. There were some promising things that ultra-modern Intel chips - meaning Icelake - and future iterations of ARM (SVE/SVE2) - are adding to their SIMD abilities, so it might be worth revisiting this in a few years (there aren't too many Icelake boxes out there and SVE barely exists).
- jkeiser 7y ago
  Yep. Most of stage 2's branchiness essentially comes from "is the next thing an array? object? string? number? Handle it differently if so." Making it so you can handle all the brackets at once, all the strings at once, all the numbers at once, would make a big difference, and we're thinking about that. Another thing that could help is making the if statement more predictable using type information from the user. get<int>() could mean "I expect this next thing to be an integer, so parse it that way and just yell if it's not, please." It's difficult. But it's why I'm still so fascinated! Solving JSON thoroughly and completely will give us a lot of information on how to quickly parse XML, YAML, and other file formats. We've clearly been collectively doing parsing wrong (including me) if there's this much of a gap. It's exciting to see something innovative and new in this domain and even being able to contribute to it :) @lemire deserves a ton of credit for making an actual project out of his work and promoting it; I likely wouldn't have heard of it otherwise.