viirya commented on issue #12045: URL: https://github.com/apache/arrow-rs/issues/12045#issuecomment-6664951166
Thanks! It's indeed close to a small-size `memcpy` specialized for this loop: what it saves is the call and the length dispatch for short values, and anything over 64 bytes still goes to `memcpy`. The benchmark bot run on the PR (Neoverse-V2, Linux/glibc) shows a much smaller gain there: 4-9% for the no-NULL cases instead of ~50% on my M4 Max (macOS). To separate the CPU from the OS, I ran the same benchmark in a Linux (glibc 2.36) container on the same M4. `main` itself is much faster there (~180 µs vs ~300 µs on macOS for `StringArray, mandatory, no NULLs`), and a standalone loop of `Vec::extend_from_slice` into a presized `Vec` takes 1.35-1.84 ns per value on Linux vs 2.0-3.2 ns on macOS for 8-48 byte values. So short `memcpy` calls are what's expensive on macOS, and that's most of the gain I measured there. On Linux the change is ~30% faster for 8 byte values and roughly neutral for 18-64 bytes, within the noise of the container. I've updated the PR description with these nu mbers. I don't have an x86 machine with FSRM at hand to try `--x86-use-fsrm-for-memcpy`. It would be interesting to compare, though it needs a non-default `target-cpu`, so default builds wouldn't get it. Tracking the min/max value length of the dictionary is a nice idea. The dictionary page is decoded once per column chunk, so collecting the lengths is cheap, and for a fixed width dictionary the offsets become `key * len` and the copy a constant size one. I'd rather try that as a follow-up than grow this PR, if that's OK. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
