5 ms·
C#/.NET in my opinion. Extremely extensive and high quality standard library and it keeps getting faster every release. Though it's kind of a difficult questio
by Guid_NewGuid 3y ago
C#/.NET in my opinion. Extremely extensive and high quality standard library and it keeps getting faster every release.
Though it's kind of a difficult question to answer, what do you need the standard library to actually do?
- neonsunset 3y agoAgree, no other standard library has comparable degree of code vectorization either.
- idontwantthis 3y agoWhat does that mean?
- neonsunset 3y ago.NET's standard library is very heavily vectorized, vectorization is considered in all scenarios where it is applicable, the compiler will also apply it to copies of known length and string comparisons fully eliding and unrolling Memmove and SequenceEqual calls. The gives languages that run on top of .NET massive performance advantage in a variety of scenarios versus any other language - C++ and Rust stdlibs are far more conservatively vectorized because neither language has stable SIMD vector API and even then out of modularity constraints a lot of routines have to either rely on autovectorization which is fragile or manually vectorized with intrisics for each individual platform. A short non-exhaustive list of examples is - Shared SIMD helper for Aho-Corasick, Rabin-Karp and other text search algorithms https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/SearchValues/Strings/Helpers/StringSearchValuesHelper.cs https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... - Bloom filter 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... - Base64 encoding and decoding https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... - Element search (memchr and the like) https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/SpanHelpers.T.cs#L1496 https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... - UTF-8 transcoding https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Text/Unicode/Utf8Utility.Transcoding.cs#L838 https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... The above are examples of 1% code that ends up used by 99% of other codebase in one way or another. Regex engine, JSON serialization and parsing, substringing and etc. all use these.
- burntsushi 3y agoRust has had a stable SIMD vector API[1] for a long time. But, it's architecture specific. The portable API[2] isn't stable yet, but you probably can't use the portable API for some of the more exotic uses of SIMD anyway. Indeed, that's true in .NET's case too[3]. So .NET has to rely on "manually vectorized with intrisics for each individual platform" as well. Rust does all this SIMD too. It just isn't in the standard library. But the regex crate does it. Indeed, this is where .NET got its SIMD approach for multiple substring search from in the first place[4]. ;-) You're right that Rust's standard library is conservatively vectorized though[5]. The main thing blocking this isn't the lack of SIMD availability. It's more about how the standard library is internally structured, and the fact that things like substring search are not actually defined in `std` directly, but rather, in `core`. There are plans to fix this[6]. With all that said, I wouldn't necessarily disagree with the broader point in this thread. .NET's regex engine performance is quite impressive[7]. (And I still have to merge the PR updating to .NET 8.) I'm really only replying here to correct more narrow points. [1]: https://doc.rust-lang.org/std/arch/index.html https://doc.rust-lang.org/std/arch/index.html [2]: https://doc.rust-lang.org/std/simd/index.html https://doc.rust-lang.org/std/simd/index.html [3]: https://github.com/dotnet/runtime/blob/72fae0073b35a404f03c3b60224fc13a775ef364/src/libraries/System.Private.CoreLib/src/System/SearchValues/Strings/Helpers/TeddyHelper.cs https://github.com/dotnet/runtime/blob/72fae0073b35a404f03c3... [4]: https://github.com/dotnet/runtime/pull/88394#issuecomment-1621703161 https://github.com/dotnet/runtime/pull/88394#issuecomment-16... [5]: https://github.com/BurntSushi/memchr#why-is-the-standard-librarys-substring-search-so-much-slower https://github.com/BurntSushi/memchr#why-is-the-standard-lib... [6]: https://github.com/rust-lang/rfcs/pull/3469 https://github.com/rust-lang/rfcs/pull/3469 [7]: https://github.com/BurntSushi/rebar#summary https://github.com/BurntSushi/rebar#summary
- neonsunset 3y agoGetting clarifications from the OG himself! :) Indeed, I meant to say "portable SIMD API" but it got lost somewhere in the stream of consciousness - sorry. As for limitations of using such APIs in the standard library - in case of .NET platform-specific paths mainly exist for the following reasons: - To achieve optimal codegen with more specific instructions - To account for platform differences that are not expressible through crossplat vectors (vpternlog on x86, tbl/tbx on Aarch64) - The code was written before crossplat API was available and has not been updated yet Another aspect of such API is that all intrinsics still consume the same unified group of Vector128/256/512<T> so that writing scenario-specific helper is still relatively easy, which is what bits of standard library often opt into.
- Encyclopediadev 3y agoDoesn't it have an ide problem on Linux?
- Guid_NewGuid 3y agoNot with Rider anymore as far as I know. I'm still on Visual Studio but colleagues report Rider is as-good or better.
- KomoD 3y agoI use Rider on Linux, it's great.