3 ms·

A quick google finds https://github.com/ffenix113/fastxml https://github.com/ffenix113/fastxml which seems to be doing the 'tips and tricks' of arena parsing an

A quick google finds https://github.com/ffenix113/fastxml https://github.com/ffenix113/fastxml which seems to be doing the 'tips and tricks' of arena parsing and things. Any idea how fast it compares when you get away from memory allocations and things and end up just seeing how the compiler does basic byte manipulation?

neonsunset 2y ago
The description indicates it is not production ready, and is archived at the same time. If you pull all stops in each respective language, C# will always end up winning at parsing text as it offers C structs, pointers, zero-cost interop, Rust-style struct generics, cross-platform SIMD API and simply has better compiler. You can win back some performance in Go by writing hot parts in Go's ASM dialect at much greater effort for a specific platform. For example, Go has to resort to this https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4fc51495a7620ce2/src/internal/bytealg/index_amd64.s https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4f... in order to efficiently scan memory, while in C# you write the following once and it compiles to all supported ISAs with their respective SIMD instructions for a given vector width: https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8b1e3db9e55c3eccb755/src/libraries/System.Private.CoreLib/src/System/SpanHelpers.T.cs#L1627-L1638 https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8... (there is a lot of code because C# covers much wider range of scenarios and does not accept sacrificing performance in odd lengths and edge cases, which Go does). Another example is computing CRC32: you have to write ASM for Go https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4fc51495a7620ce2/src/hash/crc32/crc32_amd64.s https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4f..., in C# you simply write standard vectorized routine once https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8b1e3db9e55c3eccb755/src/libraries/System.IO.Hashing/src/System/IO/Hashing/Crc32.Vectorized.cs#L32-L123 https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8... (its codegen is competitive with hand-intrinsified C++ code). There is a lot more of this. Performance and low-level primitives to achieve it have been an area of focus of .NET for a long time, so it is disheartening to see one tenth of effort in Go to receive so much more spotlight.

neonsunset 2y ago

The description indicates it is not production ready, and is archived at the same time. If you pull all stops in each respective language, C# will always end up winning at parsing text as it offers C structs, pointers, zero-cost interop, Rust-style struct generics, cross-platform SIMD API and simply has better compiler. You can win back some performance in Go by writing hot parts in Go's ASM dialect at much greater effort for a specific platform. For example, Go has to resort to this https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4fc51495a7620ce2/src/internal/bytealg/index_amd64.s https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4f... in order to efficiently scan memory, while in C# you write the following once and it compiles to all supported ISAs with their respective SIMD instructions for a given vector width: https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8b1e3db9e55c3eccb755/src/libraries/System.Private.CoreLib/src/System/SpanHelpers.T.cs#L1627-L1638 https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8... (there is a lot of code because C# covers much wider range of scenarios and does not accept sacrificing performance in odd lengths and edge cases, which Go does). Another example is computing CRC32: you have to write ASM for Go https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4fc51495a7620ce2/src/hash/crc32/crc32_amd64.s https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4f..., in C# you simply write standard vectorized routine once https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8b1e3db9e55c3eccb755/src/libraries/System.IO.Hashing/src/System/IO/Hashing/Crc32.Vectorized.cs#L32-L123 https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8... (its codegen is competitive with hand-intrinsified C++ code). There is a lot more of this. Performance and low-level primitives to achieve it have been an area of focus of .NET for a long time, so it is disheartening to see one tenth of effort in Go to receive so much more spotlight.