Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Principles for Fast Tokio Applications

dial9-rs.github.io

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Principles for Fast Tokio Applications

#41

Post by saghm »

rusbus wrote: post #32
saghm wrote: post #27

"Be careful with mutexes" is good advice, but I'm surprised it doesn't explicitly call out the various channels that tokio provides as alternatives (detailed here: https://docs.rs/tokio/latest/tokio/sync/index.html ). There are a variety of options that fit different use cases, and you don't even need to enable the runtime feature to use them (e.g. if you want to do a single check for completion rather than await). I…

(I am OP) Both good call outs. Will update the article to include them

Awesome! I was pretty confident you already were aware of both of those based on the level of knowledge needed for everything else in there, so I mostly was mentioning them here in case some people here might find them useful. Adding them in for others is even better though!

Re: Principles for Fast Tokio Applications

#42

Post by mahboi »

VorpalWay wrote: post #26
5ersi wrote: post #19

For a true high performance you should use thread busy-spinning, CPU pinning and SPSC/MPSC ring buffers.

It all depends on what you are doing. I do embedded with strict realtime requirements. CPU pinning would not be an option. I have also done software that should use as little resources as possible (but still be quick) to coexist with other software on the same hardware. All of these are different, valid, meanings of high performance. You need context. An interactive IDE is yet another thing that needs to be high perf…

Also, using 100% CPU without a good reason can cause thermal throttling that makes it slower for the sections that actually need 100% CPU

Re: Principles for Fast Tokio Applications

#43

Post by duped »

ablob wrote: post #35
duped wrote: post #29

Earlier quoted context omitted.

The "C++ community", if it even exists, barely believes in sharing code let alone any library being "dominant." They'd have to agree on a build system first, after all. But honestly that's a mischaracterization of the situation in Rust. Tokio is popular for networked service backends. If that's the wheelhouse you're in then yea it might look "dominant."

You don't need a build system to share code. You can share with header files and respective (shared) object files regardless of the build system you're using. Likewise you could just share the source. None of this needs a build system.

I was just being a bit sardonic because the C++ ecosystem is so fragmented that something like tokio couldn't really exist. It would be one of three executors in boost, abseil, or folly, and you would never see the kind of downstream ecosystem build on top of them because C++ shops are allergic to external dependencies.

Re: Principles for Fast Tokio Applications

#44

Post by loeg »

jeffbee wrote: post #25
foota wrote: post #11

Earlier quoted context omitted.

Just curious, why? Is this true even if you did something like a per-CPU histogram that uses atomic ops to increment?

If you have a per-cpu metric there would not be a reason to use atomic instructions to mutate it.

In general your unpinned userspace threads will hit the same CPU 99.99% of the time, but not 100%.

Re: Principles for Fast Tokio Applications

#46

Post by jimbob45 »

saghm wrote: post #27

"Be careful with mutexes" is good advice, but I'm surprised it doesn't explicitly call out the various channels that tokio provides as alternatives (detailed here: https://docs.rs/tokio/latest/tokio/sync/index.html ). There are a variety of options that fit different use cases, and you don't even need to enable the runtime feature to use them (e.g. if you want to do a single check for completion rather than await). I…

Why use mutexes (mutices?) over semaphores?

Re: Principles for Fast Tokio Applications

#47

Post by LoganDark »

jimbob45 wrote: post #46
saghm wrote: post #27

"Be careful with mutexes" is good advice, but I'm surprised it doesn't explicitly call out the various channels that tokio provides as alternatives (detailed here: https://docs.rs/tokio/latest/tokio/sync/index.html ). There are a variety of options that fit different use cases, and you don't even need to enable the runtime feature to use them (e.g. if you want to do a single check for completion rather than await). I…

Why use mutexes (mutices?) over semaphores?

Aren't semaphores a more fundamental primitive that is trickier to get right? Otherwise, the mutex guards in Rust are very ergonomic.

Re: Principles for Fast Tokio Applications

#48

Post by jeffbee »

loeg wrote: post #44
jeffbee wrote: post #25

Earlier quoted context omitted.

If you have a per-cpu metric there would not be a reason to use atomic instructions to mutate it.

In general your unpinned userspace threads will hit the same CPU 99.99% of the time, but not 100%.

Sure. You get the pointer, you lock the mutex, 99.99% of the time that is uncontended, then you set all the metrics and release it.

Re: Principles for Fast Tokio Applications

#49

Post by [deleted] »

mahboi wrote: post #42
VorpalWay wrote: post #26

Earlier quoted context omitted.

It all depends on what you are doing. I do embedded with strict realtime requirements. CPU pinning would not be an option. I have also done software that should use as little resources as possible (but still be quick) to coexist with other software on the same hardware. All of these are different, valid, meanings of high performance. You need context. An interactive IDE is yet another thing that needs to be high perf…

Also, using 100% CPU without a good reason can cause thermal throttling that makes it slower for the sections that actually need 100% CPU

[deleted]

Re: Principles for Fast Tokio Applications

#50

Post by lkirkwood »

LoganDark wrote: post #47
jimbob45 wrote: post #46

Earlier quoted context omitted.

Why use mutexes (mutices?) over semaphores?

Aren't semaphores a more fundamental primitive that is trickier to get right? Otherwise, the mutex guards in Rust are very ergonomic.

Semaphores are more general for sure. The common semaphore is just a counter, when you lock it you decrement the counter by one atomically. Therefore a mutex is just a semaphore with a limit of 1. I wouldn't say they're much trickier to get right, maybe just less frequently applicable in e.g. general web io tasks.
Post reply on HN