Daniel Lemire

@anonrig That's a great idea. I wonder if we couldn't do something better: validate and return the exact size of the inputs (minus white spaces). Do you have an application...

@anonrig Oh! So you actually want to decode base64 data that has been percent encoded? So spaces are likely not relevant in this context because you'd probably not do percent...

> I think improving Ada's performance might be a better place than adding it to simdutf Granted. This being said, transcoding with replacement might be even more critical. 🚤

@ronag How large are you thinking about? It takes thousands on nanoseconds to start a thread. Up to, say, 200,000 ns on some systems (it varies greatly). And you haven't...

@ronag > I'm thinking this might make sense if the overhead is negligible at sizes of ~128k. I agree and it answers my question (*How large are you thinking about?*)....

@arouel I definitively think that it is worth following up... especially as new Java releases come around.

We do not currently target BMI2, see this line... https://github.com/simdjson/simdjson/blob/e341c8b43861b43de29c48ab65f292d997096953/include/simdjson/haswell/begin.h#L7 We do not do so because we don't use BMI2 in the haswell kernel. Note that if we are going...

> Why not target BMI2 for Haswell? Even if you want to avoid PDEP/PEXT because of AMD, don't you still think the other instructions are nice? Does this mean that...

Note that the initial versions of simdjson used BMI2 (pdep/pext). At least the way we were using it was not clearly beneficial on Intel processors, and, at the time, quite...

(We do use BMI2 in the icelake kernel.)