-
> RISC-V
The work is underway: https://github.com/dotnet/runtime/pulls?q=label%3Aarch-riscv
> PTX
https://ilgpu.net/ and even https://github.com/m4rs-mt/ILGPU/blob/c3af8f368445d8e6443f36...
While not PTX, there's also this project: https://github.com/Sergio0694/ComputeSharp which partially overlaps with what ILGPU offers
Arguably, even C++ itself - you are not using "full" C++ but a special subset that works on top of specific abstraction to compile to GPUs, and I was told that CUDA C++ is considered legacy.
The original context of discussion is performance and perceived issue of "having runtime", which is what my reply is targeted at. In that context, C# provides you the tools and a solution other languages in the class of Java, Go, TS and anything else interpreted just don't have. So you could reasonably replace a project written in C++ with C#, and possibly re-apply all the freed-up developer productivity into further optimizations, but you wouldn't be able to do so with the same degree of confidence with most other originally high-level languages. Another upcoming contender is Swift.
-
Stream
Stream - Scalable APIs for Chat, Feeds, Moderation, & Video. Stream helps developers build engaging apps that scale to millions with performant and flexible Chat, Feeds, Moderation, and Video APIs and SDKs powered by a global edge network and enterprise-grade infrastructure.
-
If you heavily rely on the Python standard library, then you’re using a lot of Python code that doesn’t call out to C extensions. Peruse the standard library code, if you want to get a sense of it: https://github.com/python/cpython/tree/main/Lib
So you can expect any code that heavily relies on the standard library to be slower than the Rust equivalent.
A purely interpreted language implementation (not JIT’d) like CPython is almost always going to have a 10x-100x slowdown compared to equivalent code in C/C++/Rust/Go or most other compiled/JIT’d languages. So unless your program spends the vast majority of time in C extensions, it will be much slower.
-
This is an old example, but - date/time parsing.
A coworker of mine years ago was trying to parse out some large logfiles and it was running incredibly slowly (because the log file was huge).
Just for fun he profiled the code and found that 90% of the time was spent taking the timestamp ("2019-04-22 15:24:41") into a Python datetime. It was a slow morning, so we went back and forth trying to come up with new methods of optimizing this parsing, including (among other things) creating a dict to map date strings to datetime objects (since there were a lot of repeats).
After some even more profiling, I found that most of the slowdown happened because most of Python's strptime() implementation is written in Python so that it can handle timezones correctly; this prevented them from just calling out to the C library's strptime() implementation.
Since our timestamps didn't have a timezone specified anyway, I wrote my first ever C module[0] for Python, which simply takes two strings (the format and the timestamp) and runs them through strptime and returns a python datetime of the result.
I lost the actual benchmark data before I had a chance to record it somewhere to reproduce, and the Python 3 version in my repo doesn't have as much of a speedup compared to the default Python code, but the initial code that I wrote provided a 47x performance boost to the parsing compared to the built-in Python strptime().
Anyone who had a similar Python script and converted it wholesale to Rust (or C or Golang, probably) would have seen a similarly massive increase in performance.
[0] https://github.com/danudey/pystrptime/
-
Vrmac
Vrmac Graphics, a cross-platform graphics library for .NET. Supports 3D, 2D, and accelerated video playback. Works on Windows 10 and Raspberry Pi4.
> Those languages don't come with mechanisms to let you to make system calls directly or handle the precise memory structure of the data
Here’s a C# library for Linux where I’m doing all these things https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Rea... As you see from that readme, the performance is pretty good too.
-
> Isn't this obviously true?
To an extent sure, but we’re talking about low level micro-optimizations. Games don’t animate individual pixels. I don’t think animating 1000 things per frame gonna saturate a CPU core doing these computations, which means the code doing that is not actually performance critical.
> Got a bit lost here: games?
I searched the internets for “Bevy Engine” and found this web site https://bevyengine.org/ which says “game engine”. I wonder is there another Bevy unrelated to games?
> 3.84 GB/second
In modern games none of that bandwidth is processed on CPU. Games use GPU for that, which don’t run Rust.
> there's a weak claim that all performant data structures in Rust must use unsafe code
Weak claim? Look at the source code of data structures implemented by Rust standard library. You will find unsafe code everywhere. When you need custom data structures instead of merely using the standard ones you will have to do the same, because safe Rust is fundamentally limited in that regard.
-
I jumped to CTRE because it's another way that you can get the better results. The programmer need have no idea why this works, just like with caches.
I agree that there are trade-offs, but nevertheless compile time regex compilation is on my want list, even if a long way down it. I would take compile time arithmetic compilation† much sooner, but since that's an unsolved problem I don't get that choice.
† What I mean here is, you type in the real arithmetic you want, the compiler analyses what you wrote and it spits out an approximation in machine code which delivers an accuracy and performance trade off you're OK with, without you needing to be an expert in IEEE floating point and how your target CPU works. Herbie https://herbie.uwplse.org/ but as part of the compiler.
-
> RISC-V
The work is underway: https://github.com/dotnet/runtime/pulls?q=label%3Aarch-riscv
> PTX
https://ilgpu.net/ and even https://github.com/m4rs-mt/ILGPU/blob/c3af8f368445d8e6443f36...
While not PTX, there's also this project: https://github.com/Sergio0694/ComputeSharp which partially overlaps with what ILGPU offers
Arguably, even C++ itself - you are not using "full" C++ but a special subset that works on top of specific abstraction to compile to GPUs, and I was told that CUDA C++ is considered legacy.
The original context of discussion is performance and perceived issue of "having runtime", which is what my reply is targeted at. In that context, C# provides you the tools and a solution other languages in the class of Java, Go, TS and anything else interpreted just don't have. So you could reasonably replace a project written in C++ with C#, and possibly re-apply all the freed-up developer productivity into further optimizations, but you wouldn't be able to do so with the same degree of confidence with most other originally high-level languages. Another upcoming contender is Swift.
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
ComputeSharp
A .NET library to run C# code in parallel on the GPU through DX12, D2D1, and dynamically generated HLSL compute and pixel shaders, with the goal of making GPU computing easy to use for all .NET developers! 🚀
> RISC-V
The work is underway: https://github.com/dotnet/runtime/pulls?q=label%3Aarch-riscv
> PTX
https://ilgpu.net/ and even https://github.com/m4rs-mt/ILGPU/blob/c3af8f368445d8e6443f36...
While not PTX, there's also this project: https://github.com/Sergio0694/ComputeSharp which partially overlaps with what ILGPU offers
Arguably, even C++ itself - you are not using "full" C++ but a special subset that works on top of specific abstraction to compile to GPUs, and I was told that CUDA C++ is considered legacy.
The original context of discussion is performance and perceived issue of "having runtime", which is what my reply is targeted at. In that context, C# provides you the tools and a solution other languages in the class of Java, Go, TS and anything else interpreted just don't have. So you could reasonably replace a project written in C++ with C#, and possibly re-apply all the freed-up developer productivity into further optimizations, but you wouldn't be able to do so with the same degree of confidence with most other originally high-level languages. Another upcoming contender is Swift.
-
I saw some time back that a productionalized attempt came out: https://github.com/magic-wormhole/magic-wormhole.rs
The one I mentioned was much more primitive, meant as a demo (you can look at the branches for different approaches): https://github.com/estebank/rusticwormhole
-
I saw some time back that a productionalized attempt came out: https://github.com/magic-wormhole/magic-wormhole.rs
The one I mentioned was much more primitive, meant as a demo (you can look at the branches for different approaches): https://github.com/estebank/rusticwormhole
