{"id":4801,"date":"2021-08-30T13:57:07","date_gmt":"2021-08-30T18:57:07","guid":{"rendered":"https:\/\/neosmart.net\/blog\/?p=4801"},"modified":"2024-02-09T20:06:35","modified_gmt":"2024-02-10T02:06:35","slug":"using-simd-acceleration-in-rust-to-create-the-worlds-fastest-tac","status":"publish","type":"post","link":"https:\/\/neosmart.net\/blog\/using-simd-acceleration-in-rust-to-create-the-worlds-fastest-tac\/","title":{"rendered":"Using SIMD acceleration in rust to create the world’s fastest tac<\/code>"},"content":{"rendered":"

\"\"<\/a>NeoSmart Technologies’ open source (MIT-licensed), cross-platform tac<\/code> (written in rust) has been updated to version 2.0 (GitHub link<\/a>). This is a major release with enormous performance improvements under-the-hood, primarily featuring handwritten SIMD acceleration of the core logic that allows it to process input up to three times faster than its GNU Coreutils counterpart. (For those that aren’t familiar with it, tac<\/code> is a command-line utility to reverse the contents of a file.)<\/p>\n

This release has been a long time in the making. I had the initial idea of utilizing vectorized instructions to speed up the core line ending search logic during the initial development of tac<\/code> in 2017, but was put off by the complete lack of stabilized SIMD support in rust at the time. In 2019, after attempting to process a few log files – each of which were over 100 GiB – I decided to revisit the subject and implemented a proof-of-concept shortly thereafter… and that’s when things stalled for a number of reasons.<\/p>\n

<\/p>\n

In perfect honesty, the biggest reason a SIMD release was put on hold was that I had what I needed: my local copy of tac<\/code> that used AVX2 acceleration worked just fine to help speed up my processing of reversed server logs, and having completed the challenging part of the puzzle (trying to vectorize every possible operation in the core logic), I was not particularly interested in the remaining 20% that needed to be done – and the state of rust’s support for intrinsics was considerably lacking at the time.<\/p>\n

Apart from requiring compiler intrinsics that were gated behind the rust nightly toolchain, I wasn’t particularly sure how to tackle “graceful degradation” when executing on AVX2-incapable hardware. As mentioned earlier, the vectorization of tac<\/code> was entirely done by hand – as in, by explicitly using the AVX2 assembly instructions to carry out vectorized operations, rather by writing vectorization-friendly high-level rust code and then praying that the compiler would correctly vectorize the logic. Three years ago, the state of rust’s support for dynamic CPU instruction support detection looked very much different than it does today, and I wasn’t looking forward to releasing a tac<\/code> 2.0 that required a nightly build (aka “bleeding edge” or “unstable”) of the rust compiler. For better or for worse, the SIMD-accelerated tac<\/code> builds lay dormant (in a branch of the original code, no less) on GitHub until a couple of months ago when a number of other rust rewrites of common greybeard utilities were making the rounds and I was inspired to revisit the codebase.<\/p>\n

Fortunately, in 2021 it was considerably easier to dynamically enable AVX2 support in tac<\/code>, first by taking advantage of the is_x86_feature_detected!()<\/a><\/code> macro (available since mid-2018) to detect early on whether or not AVX2 intrinsics are supported at runtime, and then converting a few manual invocations<\/a> of nightly-only intrinsics to use SIMD-enabled equivalents exposed by the standard library instead. It helped that I had split off the core search logic into two blackbox functions, one with the original naive search logic, and the other with the AVX2-accelerated search logic, so all I needed to do was call the right function<\/a>. What remained at that point was to verify that the generated dynamic-detection binary actually performed as I expected it to.<\/p>\n

Until this point, I’d been compiling my local tac<\/code> builds with my local environment defaults, in particular with the RUSTFLAGS<\/code> environment variable set to -C target-cpu=native<\/code> which would always result in the rustc<\/code> compiler’s LLVM backend generating AVX2-compatible instructions. In addition to inspecting the generated assembly to ensure the expected AVX2 instructions were present in the AVX2 codepath (and temporarily adding a panic!(\"Wrong codepath!\")<\/code> to the non-AVX2 branch), I compiled a copy with target-cpu=native<\/code> and set it aside, then compiled another copy with RUSTFLAGS<\/code> unset, and proceeded to benchmark the two on some large (~40 GiB) payloads. I also benchmarked against my earlier proof-of-concept code that didn’t use dynamic detection at all.1<\/a><\/sup><\/p>\n

Unfortunately I found that although the AVX2 codepath was being correctly taken, the “dynamically accelerated” version of tac<\/code> compiled without<\/em> target-cpu=native<\/code> was always benchmarking up to 15% slower than the same codebase with that equivalent of -march=native<\/code> enabled (which was indistinguishable in benchmarks from the “always-AVX2” proof-of-concept). Given the non-negligible magnitude of the slowdown, it was fairly obvious that any initial analysis of the problem should focus on the core processing loop rather than any of the startup\/cleanup code, so with the code region isolated the only thing left to do was to diff the generated assembly for the core logic between the two binaries and see where they differed.<\/p>\n

While rustc<\/code> makes it easy to generate the assembly (just set RUSTFLAGS<\/code> to --emit asm -Cllvm-args=--x86-asm-syntax=intel<\/code>), I like to use godbolt.org for a quicker feedback loop, primarily because the highlighting makes it immediately obvious what instructions pertain to which functions and vice-versa – although it makes diffing the results a bit harder.2<\/a><\/sup> It was a bit hard to spot at first, but the line-by-line comparison ultimately made it possible to track down the problem.<\/p>\n

The way dynamically enabling SIMD-accelerated codepaths works in rust is a little “manual” in the sense that the detection of the supported CPU instructions is quite separate from emitting the differently-compiled code in question; i.e. the following doesn’t actually accomplish anything (and you wouldn’t intuitively expect it to):<\/p>\n

fn foo() {\r\n    \/\/ Perform some operation here\r\n}\r\n\r\nfn foo_simd() {\r\n    \/\/ Perform the same operation here\r\n}\r\n\r\npub fn main() {\r\n    if is_x86_feature_detected!(\"avx2\") {\r\n        foo_simd()\r\n    } else {\r\n        foo()\r\n    }\r\n}\r\n<\/code><\/pre>\n
But what this lets you do is apply different compilation options to one branch of code, and then dynamically select\/execute it. So instead of compiling the entire assembly with -C target-cpu=avx2<\/code> or not at all, we can invoke cargo<\/code> or rustc<\/code> with no target-cpu<\/code> specified, but then instruct the compiler to switch to a different target CPU to compile a particular function (but note that if it calls out to any other functions, those calls won’t be duplicated and recompiled w\/ the optimizations enabled):<\/p>\n
fn foo() {\r\n    \/\/ Perform some operation here\r\n}\r\n\r\n#[target_feature(enable = \"avx2\")]\r\nunsafe fn foo_simd() {\r\n    \/\/ Perform the same operation here\r\n}\r\n\r\npub fn main() {\r\n    if is_x86_feature_detected!(\"avx2\") {\r\n        unsafe { foo_simd() }\r\n    } else {\r\n        foo()\r\n    }\r\n}\r\n<\/code><\/pre>\n
Note that we had to specify the avx2<\/code> feature bit twice and that there’s no “type checking” between the two – we could have checked for is_x86_feature_detected!(\"foo\")<\/code> and then called a function decorated with #[target_feature(enable = \"bar\")]<\/code>, so rust forces us to make the target function unsafe<\/code> regardless of whether or not it actually uses any unsafe code. (This is a problem since it can mask inadvertent usage of unsafe code). Anyway, this is all just background to what the problem actually turned out to be, which is in turn a confluence of two issues:<\/p>\n
    \n
  1. rust\/llvm does not correctly recognize “supersets” of instructions,<\/li>\n
  2. rust\/llvm converts direct calls to intrinsics not supported by the specified target_feature(...)<\/code> to non-inlined functions that end up containing just the requisite asm call itself, adding a massive amount of function call overhead.3<\/a><\/sup><\/li>\n<\/ol>\n
    In this case, the AVX2 search function was decorated with #[target_feature(enable = \"avx2\")]<\/code> but in addition to its direct usage of AVX2 functions and types, it also made a call to the BZHI<\/code> and LZCNT<\/code> intrinsics\/asm instructions –\u00a0which rustc\/llvm do not recognize as being supported via the avx2<\/code> feature!<\/em> So although (to the best of this developer’s knowledge) there does not exist a processor on the face of this planet that supports AVX2 but\u00a0doesn’t<\/em> support BZHI<\/code> and LZCNT<\/code>, attempting to use those two in a function that only enabled support for avx2<\/code> resulted in codegen that turned something like this:<\/p>\n
    #[target_feature(enable = \"avx2\")]\r\npub unsafe fn bzhi(num: u32) -> u32 {\r\n    core::arch::x86_64::_bzhi_u32(num, 31)\r\n}\r\n<\/code><\/pre>\n
    into something like this (godbolt link<\/a>):<\/p>\n
    core::core_arch::x86::bmi2::_bzhi_u32:\r\n        sub     rsp, 4\r\n        bzhi    eax, edi, esi\r\n        mov     dword ptr [rsp], eax\r\n        mov     eax, dword ptr [rsp]\r\n        add     rsp, 4\r\n        ret\r\n\r\nexample::bzhi:\r\n        push    rax\r\n        mov     esi, 31\r\n        call    core::core_arch::x86::bmi2::_bzhi_u32\r\n        mov     dword ptr [rsp + 4], eax\r\n        mov     eax, dword ptr [rsp + 4]\r\n        pop     rcx\r\n        ret\r\n<\/code><\/pre>\n
    \u2026which is obviously not what we want.<\/p>\n
    Technically<\/em>, BZHI<\/code> (zero the high bits starting from the specified bit) is not part of the avx2<\/code> instruction set but rather part of the bmi2<\/code> (bit manipulation instructions v2) instruction set. However, AMD introduced support for the BMI2 instructions at the same time as they first introduced support for AVX2 (as part of the Excavator microarchitecture<\/a>, in 2015). Intel likewise introduced BMI2 support (along with BMI1 support, as a matter of fact) as part of the Haswell microarchitecture<\/a> in 2013, also at the same time they debuted support for AVX2. No AVX2 CPU has shipped from either company without BMI2 since then, and it’s pretty unfathomable that any would in the future.<\/p>\n
    Likewise, LZCNT<\/code> (count number of leading zero bits) is not officially part of the AVX2 instruction set but rather part of the bmi1<\/code> instruction set – which, as we saw earlier, was supported by AMD prior to their debuting AVX2 support but only supported by Intel in Haswell alongside avx2<\/code> and bmi2<\/code> support. In other words, you can view avx2<\/code> support as a strict superset of support for both bmi1<\/code> and bmi2<\/code>, and to a lesser extent, support for bmi2<\/code> as being identical to support for avx2<\/code> (because there could be x86-only CPUs out there with bmi2<\/code> but no avx2<\/code>). Long story short, rust’s codegen (here provided by llvm) would certainly be within its rights to expand avx2<\/code> to avx2,bmi1,bmi2<\/code> (and then some).<\/p>\n
    Confusingly, while the poor codegen for lzcnt<\/code> causes the intrinsic to expand to an inlined function call containing the fallback logic for platforms that don’t support the bmi1<\/code> instruction set:<\/p>\n
    #![feature(core_intrinsics)]\r\n\r\n#[target_feature(enable = \"avx2\")]\r\npub unsafe fn ctlz(num: i32) -> i32 {\r\n    core::intrinsics::ctlz(num)\r\n}\r\n<\/code><\/pre>\n
    example::ctlz:\r\n        push    rax\r\n        bsr     eax, edi\r\n        mov     ecx, 63\r\n        cmove   eax, ecx\r\n        xor     eax, 31\r\n        mov     dword ptr [rsp + 4], eax\r\n        mov     eax, dword ptr [rsp + 4]\r\n        mov     dword ptr [rsp], eax\r\n        mov     eax, dword ptr [rsp]\r\n        pop     rcx\r\n        ret\r\n<\/code><\/pre>\n
    \u2026 however, as you can see in the first assembly output from earlier, the bzhi<\/code> intrinsic just generates a non-inlined function call to a new function that just executes bzhi<\/code> directly, meaning you gain virtually nothing but function call overhead. Presumably there is a reason for this (unless it’s just bad codegen), my best guess is that this is an attempt to guard against microarchitectures that will generate a #UD<\/code> exception if that instruction is seen, even if not executed? That seems a bit unlikely, given that we needed to implement W^X<\/code> as its own thing, but I could be wrong.<\/p>\n
    In all cases, decorating the AVX2-enabled method<\/a> with<\/p>\n
    #[target_feature(enable = \"avx2\")]\r\n#[target_feature(enable = \"bmi1\")]\r\n#[target_feature(enable = \"bmi2\")]\r\nunsafe fn search_avx2() {\r\n    \/\/ \u2026\r\n}\r\n<\/code><\/pre>\n
    worked, and the dynamically enabled AVX2 acceleration of the core tac<\/code> logic benchmarked identical to the other two builds (which is to say, extremely fast).<\/p>\n
    What’s the impact of these changes? Our tac<\/code> 2.0 release is up to 3x faster than the GNU Coreutils version of tac<\/code> if benchmarking with speculative execution mitigations disabled. If the mitigations are<\/em> enabled, then our tac<\/code> will be even faster than that as we are using memory-mapped files (with specifically mmap-friendly access patterns) to avoid the repeated syscalls to refill the buffers, which are considerably slower with mitigations enabled.<\/p>\n
    You can explore the source code yourself<\/a> to see how this all comes together or inspect the SIMD instructions used to speed up the search. You can grab pre-compiled binaries for the major platforms from the releases page<\/a>, and I’m working on getting tac<\/code> into the FreeBSD ports repo and into either choco<\/code> or scoop<\/code> for Windows users. As with all our other open source projects, help getting the binaries into platform\/distribution-specific package managers is always welcome.<\/p>\n
    Join the discussion on Hacker News<\/a> or on reddit’s \/r\/rust<\/a>. You can follow me on twitter @mqudsi<\/a> and\/or subscribe below to receive emails when I post specifically about rust (and never anything else):<\/p>\n
    \n
    If you would like to receive a notification the next time we release a rust library, publish a crate, or post some rust-related developer articles, you can subscribe below. Note that you'll only get notifications relevant to rust programming and development by NeoSmart Technologies. If you want to receive email updates for all NeoSmart Technologies posts and releases, please sign up in the sidebar to the right instead.<\/em><\/p>\n