-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
cv
Rust CV mono-repo. Contains pure-Rust dependencies which attempt to encapsulate the capability of OpenCV, OpenMVG, and vSLAM frameworks in a cohesive set of APIs.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I currently use Symphonia for audio decoding, and they claim to have similar performance as FFmpeg using only safe Rust code. There's not many reasons why safe Rust code should have worse performance than similar C or C++ code, but you have to be careful to compare apples with apples, for example regarding string handling, regex, file handling etc.
How about tiny-skia? Almost the same performance as C, no unsafe, a lot of explicit SIMD.
Or even ttf-parser, which is usually even faster than C alternatives, no unsafe, no explicit SIMD.
According to the rust-secure-code/safety-dance trophy case, their audit left miniz_oxide 100% safe and faster than the C version.
I currently use Symphonia for audio decoding, and they claim to have similar performance as FFmpeg using only safe Rust code. There's not many reasons why safe Rust code should have worse performance than similar C or C++ code, but you have to be careful to compare apples with apples, for example regarding string handling, regex, file handling etc.
RUST: https://github.com/pczarn/gearley
I'd like the mention my own refactoring of fast-float-rust to remove nearly all unsafe code for merging into Rust core library which left the performance identical to the previous implementation.
I'd like the mention my own refactoring of fast-float-rust to remove nearly all unsafe code for merging into Rust core library which left the performance identical to the previous implementation.
miniz_oxide is slightly faster than zlib
gif, png, zune-jpeg are on par with their C counterparts in terms of performance
gif, png, zune-jpeg are on par with their C counterparts in terms of performance
gif, png, zune-jpeg are on par with their C counterparts in terms of performance
resvg is very fast, although the performance depends on the exact SVG you feed it - sometimes faster than librsvg, sometimes slower (although librsvg is also written in Rust now, it does use unsafe while resvg doesn't)
Rust can absolutely be used without unsafe to create some of the fastest code out there, but you need to try and use data-oriented design where possible to make things flow smoothly and avoid runtime checks. The hardest thing to use data-oriented design for, in my opinion, is graphs. I find that actor systems can be used instead of graphs, but it is difficult. Generally I end up using slotmap to make multiple arenas and then putting them into one large object with lots of methods to operate on the graph structure. If you want an example of that, this is probably the most complicated code I have made this way: https://github.com/rust-cv/cv/blob/511024feaa077a9af377cca7b654ad3d57d3bd6a/cv-sfm/src/lib.rs. It may not be entirely helpful to understand the whole codebase, but if you are curious to see how I do graphs in Rust with slotmap, this can be a good reference.
Good point, I don't know the answer to this. What I ended up doing was creating my own "safe" wrappers for the AVX2 instructions (which is basically what you want to use for x86). There are other crates that provides safe interfaces, but they didn't really fit my needs.