flume icon indicating copy to clipboard operation
flume copied to clipboard

Published 20 hours ago • verified publisher icon zesterer

File a issue with the standard library?

Open moonheart08 opened this issue 4 years ago • 14 comments

If this is feature equivalent, wouldn't it be a good idea to try and get it merged into std?

moonheart08 avatar Mar 23 '20 03:03 moonheart08

There has been some talk on the T-libs Zulip about this, so it's definitely a goal! Currently we are fixing some bugs and trying to optimize so that we don't perform so poorly compared to crossbeam for low-bound bounded channels, rendezvous channels, and SPSC channels. Here is what the benches currently look like (0.7.1). We are beating std in almost all the benches but we have the aforementioned areas of weakness. image

Restioson avatar Mar 23 '20 12:03 Restioson

Here are the latest numbers from the flavour-refactor branch (Linux, AMD Ryzen 7, 4 cores, 8 threads).

image

zesterer avatar Apr 08 '20 16:04 zesterer

Was there any more progress on this? I am possibly interested in helping out.

Ericson2314 avatar Jun 14 '21 15:06 Ericson2314

I suppose the first challenge is that there isn't an optional std feature for flume (i.e. no-std + alloc or whatever support), and I am not sure how one could make one without breaking up std into more crates first (because of std::thread usage, etc.)

Ericson2314 avatar Jun 14 '21 15:06 Ericson2314

Yea. I think it would probably need to be source copied into std because of this?

Restioson avatar Jun 15 '21 10:06 Restioson

Well then it's liable to stagnate; I prefer approaches were std can just use the crates.io crate to better leverage the good work being done in the ecosytem on an ongoing basis :).

Ericson2314 avatar Jun 15 '21 19:06 Ericson2314

I've an in-progress refactor that builds the channel on top of a no-std, async core. I believe that this could act as the step necessary to facilitate porting to std. However, it's not finished yet.

zesterer avatar Jun 16 '21 08:06 zesterer

So the idea then would be that std would use the core and wrap it (in house) with synchronicity primitives to fit in the mpsc api?

Restioson avatar Jun 16 '21 09:06 Restioson

Yes, I think that's the most reasonable approach.

zesterer avatar Jun 16 '21 22:06 zesterer

Oh, nice! Looking forward to seeing that. Even as a heavily WIP draft PR :).

Ericson2314 avatar Jun 16 '21 23:06 Ericson2314

@zesterer Any luck? Maybe want to open a WIP PR?

Ericson2314 avatar Jul 07 '21 04:07 Ericson2314

I've not done a huge amount of work on the branch and it still has a few subtle issues that need resolving (mostly relating to async usage). However, I can open a PR for discussion about it.

zesterer avatar Jul 07 '21 09:07 zesterer

I've opened a draft PR here.

I don't know how much time I'll get to work on this. If you or someone else wants to work on resolving some of the issues, I'd be very happy to accept PRs!

zesterer avatar Jul 07 '21 09:07 zesterer

Thanks!

Ericson2314 avatar Jul 07 '21 17:07 Ericson2314