3 ms·

> On paper yes but does anyone really rely on it? Zeroing and copying, all string operations, comparisons like here in the article or inlined, selecting atomic

> On paper yes but does anyone really rely on it? Zeroing and copying, all string operations, comparisons like here in the article or inlined, selecting atomics on ARM64, fusing FP conversions and narrow SSE/AVX operations into masked or vpternlog when AVX512VL is available, selecting text search algorithms inside SearchValues<T>, which is what .NET's Regex engine (which is faster than PCRE2-JIT) builds upon, and quite a few places in CoreLib which use the primitive directly. Base64 encoding/decoding, UTF-8 transcoding. The list goes on. The criticism here is unsubstantiated. > that mean that common patterns in the language can't actually be expressed statically so one ends up with all kinds of quasi-dynamically typed runtime patterns This has zero relationship with the underlying compilation model. NativeAOT works just fine and is subject to limitations you've come to expect when using a language based on LLVM (although .NET, save for NativeAOT-LLVM WASM target, does not use it because LLVM is not as good for a language which takes advantage of top-to-bottom GC and type system integration). I think it is worth understanding what limitations .NET is subject to and what limitations it is not. This sounds a lot like very standard misconceptions you hear from C++ crowd.

mhh__ 2y ago
> Zeroing and copying, all string operations, Some of this is isel, some of this is fairly heavy autovec - does it actually do the latter on the fly? I would've thought that for memcpy and so on you'd drag around a hand tuned implementation like everyone else (or do what chrome does and jit a hand-written IR implementation) since its going to be so hot. Does dotnet have loop autovec now? I can get it to unroll a loop but it seems to fall back to a loop past where N is in simd-heaven territory.
- neonsunset 2y ago
  > Some of this is isel Yes, and it's not constrained by whatever lowest common denominator was chosen at the moment of publishing the application or library. Anyway https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Url/Base64UrlEncoder.cs https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/SearchValues/ProbabilisticMap.cs https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/SpanHelpers.Byte.cs#L759-L961 https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/System/HexConverter.cs#L241-L333 https://github.com/dotnet/runtime/blob/main/src/libraries/Co... https://godbolt.org/z/MfnWd19n8 https://godbolt.org/z/MfnWd19n8 (sometimes you get AVX2 cores on Godbolt, sometimes AVX512 so I'm forcing it via NativeAOT for a better example) Having the runtime pick the optimal instruction set for all the paths above requires exactly zero steps from the user, much like with using DynamicPGO (which is why forms of static PGO are not comparable for the common case). > autovec Most performance critical paths which are not explicitly vectorized in C++ or Rust are either very fragile and not autovectorized at all. If you care about performance, it is way better to have good SIMD abstractions. Which is what .NET heavily invests into over (very expensive) loop autovectorization phase. Although at this point it does almost everything else, but there are way more impactful areas of investment. If you care about SIMD - use Vector128/256/512 and/or platform intrinsics instead for much better results. Although I can't shake off the impression that you are looking for gotchas here and details aren't of particular interest.
  - mhh__ 2y ago
    With those flags I still can't seem to get it to do anything particularly interesting to a fixed length memset (e.g. at small N I would expect to see SSE instructions at least)
    - neonsunset 2y ago
      It looks like you haven't read my messages nor looked at the links.
  - mhh__ 2y ago
    And I'm inclined to agree re autovec (fragile or not the code usually isn't that good) but that's to me at least why the JIT aspect isn't particularly attractive i.e. you'd have to do the work anyway, no?

mhh__ 2y ago

> Zeroing and copying, all string operations, Some of this is isel, some of this is fairly heavy autovec - does it actually do the latter on the fly? I would've thought that for memcpy and so on you'd drag around a hand tuned implementation like everyone else (or do what chrome does and jit a hand-written IR implementation) since its going to be so hot. Does dotnet have loop autovec now? I can get it to unroll a loop but it seems to fall back to a loop past where N is in simd-heaven territory.

neonsunset 2y ago
> Some of this is isel Yes, and it's not constrained by whatever lowest common denominator was chosen at the moment of publishing the application or library. Anyway https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Url/Base64UrlEncoder.cs https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/SearchValues/ProbabilisticMap.cs https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/SpanHelpers.Byte.cs#L759-L961 https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/System/HexConverter.cs#L241-L333 https://github.com/dotnet/runtime/blob/main/src/libraries/Co... https://godbolt.org/z/MfnWd19n8 https://godbolt.org/z/MfnWd19n8 (sometimes you get AVX2 cores on Godbolt, sometimes AVX512 so I'm forcing it via NativeAOT for a better example) Having the runtime pick the optimal instruction set for all the paths above requires exactly zero steps from the user, much like with using DynamicPGO (which is why forms of static PGO are not comparable for the common case). > autovec Most performance critical paths which are not explicitly vectorized in C++ or Rust are either very fragile and not autovectorized at all. If you care about performance, it is way better to have good SIMD abstractions. Which is what .NET heavily invests into over (very expensive) loop autovectorization phase. Although at this point it does almost everything else, but there are way more impactful areas of investment. If you care about SIMD - use Vector128/256/512 and/or platform intrinsics instead for much better results. Although I can't shake off the impression that you are looking for gotchas here and details aren't of particular interest.
- mhh__ 2y ago
  With those flags I still can't seem to get it to do anything particularly interesting to a fixed length memset (e.g. at small N I would expect to see SSE instructions at least)
  - neonsunset 2y ago
    It looks like you haven't read my messages nor looked at the links.
- mhh__ 2y ago
  And I'm inclined to agree re autovec (fragile or not the code usually isn't that good) but that's to me at least why the JIT aspect isn't particularly attractive i.e. you'd have to do the work anyway, no?