2 ms·

I suspect the need to reallocate in simdjson is a factor in performance but that is really part of the benchmark. When using a parser it would be a very rare ca

I suspect the need to reallocate in simdjson is a factor in performance but that is really part of the benchmark. When using a parser it would be a very rare case to have the luxury of embedding the string to be parsed in the code. Usually a string comes in through some other means such as over HTTP or maybe a simple socket. Then again it could be passed from some other part of an application. If the parser has a requirement to expand the string to modify it in some fashion then a realloc or really a malloc and copy is part of the parsing process.

gliptic 6y ago
You don't have to embed the string in the code, obviously. If you want to use a certain lib, I'm sure you can arrange for the buffer to be slightly bigger.
jkeiser 6y ago
simdjson doesn't care what is in the padding and won't modify it; it just needs the buffer the string lives in to have 32 extra addressable (allocated) bytes. It doesn't ever use the bytes to make decisions, but it may read them as certain critical algorithms run faster when you overshoot a tiny bit and correct after. Most real world applications like sockets read into a buffer, and can easily meet this requirement. If you are interested to know what it's for, the place where it parses/unescapes a string is a good example. Instead of copying byte by byte, it generally copies 16-32 raw bytes at a time, and just sort of caps it off at the end quote, even though it might have copied a little extra. Here's some pseudocode (note this isn't the full algorithm, I left a out some error conditions and escape parsing for clarity): // Check the quote if (in[i] == '"') { i++; len = 0; while (true) { // Use simd to copy 32 bytes from input to output chunk = in[i..i+32]; out[len..len+32] = chunk; // Note we already wrote 32 bytes, and NOW check if there was a quote in there if (int quote = chunk.find('"')) { len += quote; break; } len += 32; // No quote, so keep parsing the string i += 32; } }
- glangdale 6y ago
  Yes, this is exactly why simdjson wants padding. It certainly doesn't need the string to be embedded in source or any such nonsense. I wish there was a standardized attribute that C++ knew about that pretty much just said "hey, we're not right next to some memory-managed disaster, and if you read off this buffer, you promise not to use the results". It is awful practice to read off the end of a buffer and let those bytes affect your behavior, but it is almost always harmless to read extra bytes (and mask them off or ignore them) unless you're next to a page boundary or in some dangerous region of memory that's mappped to some device. This attribute would also need to be understood by tools like Valgrind (to the extent that valgrind can/can't track whether you're feeding this nonsense into a computation, which it handles pretty well).

gliptic 6y ago

You don't have to embed the string in the code, obviously. If you want to use a certain lib, I'm sure you can arrange for the buffer to be slightly bigger.

jkeiser 6y ago

simdjson doesn't care what is in the padding and won't modify it; it just needs the buffer the string lives in to have 32 extra addressable (allocated) bytes. It doesn't ever use the bytes to make decisions, but it may read them as certain critical algorithms run faster when you overshoot a tiny bit and correct after. Most real world applications like sockets read into a buffer, and can easily meet this requirement. If you are interested to know what it's for, the place where it parses/unescapes a string is a good example. Instead of copying byte by byte, it generally copies 16-32 raw bytes at a time, and just sort of caps it off at the end quote, even though it might have copied a little extra. Here's some pseudocode (note this isn't the full algorithm, I left a out some error conditions and escape parsing for clarity): // Check the quote if (in[i] == '"') { i++; len = 0; while (true) { // Use simd to copy 32 bytes from input to output chunk = in[i..i+32]; out[len..len+32] = chunk; // Note we already wrote 32 bytes, and NOW check if there was a quote in there if (int quote = chunk.find('"')) { len += quote; break; } len += 32; // No quote, so keep parsing the string i += 32; } }

glangdale 6y ago
Yes, this is exactly why simdjson wants padding. It certainly doesn't need the string to be embedded in source or any such nonsense. I wish there was a standardized attribute that C++ knew about that pretty much just said "hey, we're not right next to some memory-managed disaster, and if you read off this buffer, you promise not to use the results". It is awful practice to read off the end of a buffer and let those bytes affect your behavior, but it is almost always harmless to read extra bytes (and mask them off or ignore them) unless you're next to a page boundary or in some dangerous region of memory that's mappped to some device. This attribute would also need to be understood by tools like Valgrind (to the extent that valgrind can/can't track whether you're feeding this nonsense into a computation, which it handles pretty well).