flume VS rust

I also like flume, it has impressive performance (although not the best). More importantly, it's written only with safe rust. https://github.com/zesterer/flume

The most commonly suggested replacement for mspc is crossbeam-channel; flume is also relatively popular.

It's not officially deprecated, but the alternatives on crates.io are considered better. flume and crossbeam-channel feature less unsafe code and offer better performance. Benchmarks.

it's slow (checkout flume's benchmarks for example)

For concurrency/parallelism, you launch at most 2 * CPU Cores, PIN them and use a fast broker to spread the task (like a ring buffer or an MPSC). But you keep linear scan, tight loops, SIMD friendly data, on each. You are not switching context that much, and instead, bet you will process the batch fast. (CPUs are fast today!)

First, I was becoming more and more confident that the channel library Daxpedda and I fell in love with, flume, was misbehaving, but I couldn't seem to reproduce it outside of the massive PliantDB codebase. I finally called up Daxpedda on Discord and screen shared my debugging session, showing him how the tests succeeded if I retained a channel. If I allowed the sender to drop after successfully sending, sometimes the tests would fail. He agreed, something was odd. It took me a while, but I finally whittled it down to about 30 lines of code and reported the issue. In an amazingly quick fashion, the maintainer fixed the issue and released an update. And for the record, I still fully love and recommend this library if you're mixing async and non-async code using channels. It's a wonderful implementation.

Sort of? Here's the closest thing you'll probably find: https://crates.io/crates/flume

My first try was with flume, which uses a single producer, multi-consumer setup, and while it compiles and runs, it's magnitudes slower than the serial version. Here's a psuedocode rendition:

Easy to compare:

Search the gnat bug tracker for stack overflow: 14 bugs https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=Ada%20s...

Rust: 243 (plus 830 closed) https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...

Choose by yourself which seems safer

He delved into the evolution of AWS Lambda's pricing strategy, transitioning from T2 instances to the innovative Firecracker microVMs for superior resource optimization. Vogels also advocated for exploring energy-efficient programming languages like Rust, showcasing AWS's adoption in Firecracker and a substantial segment of their S3 service, aiming for more efficient and cost-effective solutions. This blog is really helpful about Firecracker – Lightweight Virtualization for Serverless Computing

It's Christmas time and time for Advent of Code 2023 edition. Starting from today I will try to solve puzzles in Rust and publish a post a day in which I tell my solution. My goal is not to climb the leaderboard but to use the problems to practice writing Rust code and improve my language knowledge. Copilot yes or Copilot not? It's for learning so Copilot definitely not. The solutions will be available at the following git repository, as I don't have much time to write a template from scratch, I will use the starter template available here.

> I know it’s easy to change but the arguments for using glibc’s allocator are less clear to me:

You can find them at the original motivation for removing jemalloc, 7 years ago: https://github.com/rust-lang/rust/issues/36963

Also it's not "glibc's allocator", it's the system allocator. If you're unhappy with glibc's, get that replaced.

> 1. Reliability - how is an alternate allocator less reliable?

Jemalloc had to be disabled on various platforms and architectures, there is no reason to think mimalloc or tcmalloc are any different.

The system allocator, while shit, is always there and functional, the project does not have to curate its availability across platforms.

> 2. Compatibility - again sounds like a FUD argument. How is compatibility reduced by swapping out the allocator?

It makes interactions with anything which does use the system allocator worse, and almost certainly fails to interact correctly with some of the more specialised system facilities (e.g. malloc.conf) or tooling (in rust, jemalloc as shipped did not work with valgrind).

> Also, most people aren’t writing hello world applications

Most people aren't writing applications bound on allocation throughput either

> so the default should probably be for a good allocator.

Probably not, no.

> I’d also note that having a dependency of the std runtime on glibc in the first place likely bloats your binary more than the specific allocator selected.

That makes no sense whatsoever. The libc is the system's and dynamically linked. And changing allocator does not magically unlink it.

> 4. Maintenance burden - I don’t really buy this argument.

It doesn't matter that you don't buy it. Having to ship, resync, debug, and curate (cf (1)) an allocator is a maintenance burden. With a system allocator, all the project does is ensure it calls the system allocators correctly, the rest is out of its purview.

Not sure if this is the right place to ask such a question but I am running cargo/rustc et al under an up to date Windows 10 but a recent change (could be upgrading the compiler, could be a Windows change, could be something else entirely because I cannot pinpoint it to an exact point in time) has resulted in the loss of colouring for various compiler outputs, specifically the line number related elements are no longer cyan and error details no longer red (almost exactly the same as was reported more than five years ago: https://github.com/rust-lang/rust/issues/49322).

Not OP, but one thing that surprised me was if you are doing rust Simd in a library, and part of the code is marked #[inline] but others are not you might see catastrophic performance regressions. We saw an issue where the SIMD version was over 10x slower because we missed marking one function as inline. Essentially rustc converted it from an intrinsic to a regular function call.

https://github.com/rust-lang/rust/issues/107617#issuecomment...

I believe it's not stable because it gives std::boxed::Box special treatment in the language. They'd rather find a solution that could work equally well for smart pointers defined outside of std.

Box patterns are likely to be superseded by one of these:

https://github.com/rust-lang/rust/issues/42640

https://github.com/rust-lang/rust/issues/87121

Rust's stdlib's API is completely safe here. On Windows[1], it uses the GetEnvironmentVariable/SetEnvironmentVariable API, which as you noted doesn't have this problem. On Unix[2], it maintains its own RwLock to provide synchronisation. Additionally, Rust's API only gives out copies of the data, it never gives you a pointer to the original.

The problem comes when you do FFI on *nix systems, because those foreign functions may start making unsynchronised calls to getenv/setenv.

[1] https://github.com/rust-lang/rust/blob/master/library/std/sr...

[2] https://github.com/rust-lang/rust/blob/master/library/std/sr...

If you want to learn Svelte or Rust (Tauri) while building this project with us, send me an inbox!