I was ready to learn something, and instead I found that the "author" doesn't actually respect their reader's time, because the substance of the piece - the part where they're supposed to be schooling us - is clearly unedited LLM output.
Lorrrrrd but I'm fed up with this particular flavor of submission. I want to see it and its kind die hard every time it hits HN. It's a waste of human energy to produce them, and doubly so to read them.
The people who make these use LLMs enough to understand that they're offering us nothing except the service of writing prompts for us. And it's not even to share their own knowledge, or their unique perspective. The author fails to mention that using SIMD for CSV parsing has been a thing for years. They say that they are "pioneering" these techniques.
Why should serious people entertain this misrepresentation?
It's not to illuminate others, it's to masquerade as someone who knows or has learned better. Not a lot offends me, but this clears the bar easy.
Congrats on publishing.
But I am too lazy, to proof or falsify that.
We are in post-factual age anway, right?
Modern LLVM already does not a bad job with SIMD optimizations, maybe even AVX-512 when targeting supported CPU.
Wonder if we soon see a language employing SIMD/MIMD optimizations without explicit asm/intrinsics from user. I remember @cmuratori said somewhere this is one thing he misses a lot in todays languages.
This snippet of the code shows that it is correctly handled:
// from init_tables()
} else {
// When in a quoted string, a quote char transitions to the escape state.
st[S_QUOTED][q] = S_QUOTE_ESC;
// By default, any character seen after the escape state's quote
// will transition back to the unquoted state (ending the field).
memset(st[S_QUOTE_ESC], S_UNQUOTED, 256);
// CRITICAL OVERRIDE: If the character is another quote, it was an
// escaped quote, so we go back to the quoted state.
st[S_QUOTE_ESC][q] = S_QUOTED;
}