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

C++20: Building a Thread-Pool with Coroutines

blog.eiler.eu

Post reply on HN
Print view View original

51–60 of 63 posts

Re: C++20: Building a Thread-Pool with Coroutines

#51

Post by hedora »

pjmlp wrote: post #32
PaulDavisThe1st wrote: post #15

Earlier quoted context omitted.

garbage collection is one of the abstractions that can interfere with performance. it's out of the question for real time contexts, for example.

Depends, https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ On the other hand there is real time where even malloc() is forbidden. https://en.m.wikipedia.org/wiki/MISRA_C

The first one targets “sub-millisecond”, which is a eternity in current systems.

According to the third link:

> we observed a negative correlation between MISRA rule violations and observed faults

So, MISRA isn’t really helping with real time at all.

The second link claims pauses are capped at 10us, which (if true) is actually competing with careful use of malloc.

Re: C++20: Building a Thread-Pool with Coroutines

#52

Post by hedora »

sys_64738 wrote: post #7

GO style co-routines and native JSON support would pretty much consign GO to history, IMO.

JSON for modern C++ and this article pretty much cover it.

C++ tends to be the second best language for everything, and this is no exception. Go beats it at Go’s own niche: it has great compilation times and it forces you down a sane asynchronous programming path.

C++ fails on both those criteria. However, once you fall off the happy path in Go, you’re probably completely screwed, where as with C++, you’re already using the second best language for whatever your new problem is.

Re: C++20: Building a Thread-Pool with Coroutines

#53

Post by PaulDavisThe1st »

pjmlp wrote: post #32
PaulDavisThe1st wrote: post #15

Earlier quoted context omitted.

garbage collection is one of the abstractions that can interfere with performance. it's out of the question for real time contexts, for example.

Depends, https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ On the other hand there is real time where even malloc() is forbidden. https://en.m.wikipedia.org/wiki/MISRA_C

The first link covers cases most simply described as "it needs to be fast, as fast as possible, but things won't go wrong if there's a random 8msec delay".

Then there's "things will go wrong if there's a random 8msec delay".

Then there's "people will die and/or property will be destroyed if there's a random 8msec delay".

I was referring only to the last two. And yes, that means no malloc.

Re: C++20: Building a Thread-Pool with Coroutines

#54

Post by pjmlp »

hedora wrote: post #51
pjmlp wrote: post #32

Earlier quoted context omitted.

Depends, https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ On the other hand there is real time where even malloc() is forbidden. https://en.m.wikipedia.org/wiki/MISRA_C

The first one targets “sub-millisecond”, which is a eternity in current systems. According to the third link: > we observed a negative correlation between MISRA rule violations and observed faults So, MISRA isn’t really helping with real time at all. The second link claims pauses are capped at 10us, which (if true) is actually competing with careful use of malloc.

Hence why I stated "Depends".

It is real time enough to drive battleship weapon systems, the kind of apps where the wrong people die when a GC goes wrong.

https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...

Re: C++20: Building a Thread-Pool with Coroutines

#55

Post by pjmlp »

PaulDavisThe1st wrote: post #53
pjmlp wrote: post #32

Earlier quoted context omitted.

Depends, https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ On the other hand there is real time where even malloc() is forbidden. https://en.m.wikipedia.org/wiki/MISRA_C

The first link covers cases most simply described as "it needs to be fast, as fast as possible, but things won't go wrong if there's a random 8msec delay". Then there's "things will go wrong if there's a random 8msec delay". Then there's "people will die and/or property will be destroyed if there's a random 8msec delay". I was referring only to the last two. And yes, that means no malloc.

Depends how relevant 8msec are on a battleship weapon guidance system,

https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...

On any case, that is the reason why I started with depends, just like everyone wants to do big data that fits into a USB floppy, there are those cases where CircuitPython would be more than enough, yet people insist in using Assembly.

In some cases only Ada/SPARK or MISRA will do, others not, yet all of them might fall under real time and embedded deployment.

Re: C++20: Building a Thread-Pool with Coroutines

#56

Post by PaulDavisThe1st »

pjmlp wrote: post #55
PaulDavisThe1st wrote: post #53

Earlier quoted context omitted.

The first link covers cases most simply described as "it needs to be fast, as fast as possible, but things won't go wrong if there's a random 8msec delay". Then there's "things will go wrong if there's a random 8msec delay". Then there's "people will die and/or property will be destroyed if there's a random 8msec delay". I was referring only to the last two. And yes, that means no malloc.

Depends how relevant 8msec are on a battleship weapon guidance system, https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te... On any case, that is the reason why I started with depends, just like everyone wants to do big data that fits into a USB floppy, there are those cases where CircuitPython would be more than enough, yet people insist in using Assembly. In some cases only Ada/SPARK or MISRA will do, oth…

No, it doesn't depend. That fits clearly into the first category, in which things do not go wrong when there's an 8msec delay.

By contrast, using a DAW with typical settings, an 8 msec delay is catastrophic within the scope of the task, even though nobody gets hurt and nothing gets destroyed.

Re: C++20: Building a Thread-Pool with Coroutines

#57

Post by pjmlp »

PaulDavisThe1st wrote: post #56
pjmlp wrote: post #55

Earlier quoted context omitted.

Depends how relevant 8msec are on a battleship weapon guidance system, https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te... On any case, that is the reason why I started with depends, just like everyone wants to do big data that fits into a USB floppy, there are those cases where CircuitPython would be more than enough, yet people insist in using Assembly. In some cases only Ada/SPARK or MISRA will do, oth…

No, it doesn't depend. That fits clearly into the first category, in which things do not go wrong when there's an 8msec delay. By contrast, using a DAW with typical settings, an 8 msec delay is catastrophic within the scope of the task, even though nobody gets hurt and nothing gets destroyed.

I guess we are having a language problem here, because when we have three options to refer to, it is obvious that it depends.

Re: C++20: Building a Thread-Pool with Coroutines

#58

Post by sannysanoff »

einpoklum wrote: post #34
sannysanoff wrote: post #9

I used similar thing, baked on top of cppcoro library (wonderful thing). My application is heavily threaded with hundreds of thousands of short-lived micro-tasks, it's interpreter of highly-parallel expressions, and values are large matrices containing expressions, so it's highly parallelizable. I moved to C++ coroutines from composable futures (CF) library that had few thread pool implementations if memory serves (a…

> chinese libgo I believe you mean this one? : libgo -- a coroutine library and a parallel Programming Library https://github.com/yyzybb537/libgo (no information about the main contributor unfortunately)

yes

Re: C++20: Building a Thread-Pool with Coroutines

#59

Post by sannysanoff »

MichaEiler wrote: post #39
sannysanoff wrote: post #9

I used similar thing, baked on top of cppcoro library (wonderful thing). My application is heavily threaded with hundreds of thousands of short-lived micro-tasks, it's interpreter of highly-parallel expressions, and values are large matrices containing expressions, so it's highly parallelizable. I moved to C++ coroutines from composable futures (CF) library that had few thread pool implementations if memory serves (a…

Having only briefly looked through the code base of libgo. It looks like they use boost::context, which is the only good stackful coroutines implementations I've come across. Not being familiar with your project I'm slightly confused about the statement of "hundreds of thousands of short-lives micro-tasks". This is usually a no-go in case of stackful coroutines, as you would waste too much memory as well as have a lo…

I have an internal scheduler which prevents spawning too many of them. In any case, it's only stack & context allocation (and freeing) which is not that CPU expensive at my rate (does not show in profiler too much). Also, multiple concurrent processes in worst cases use much virt memory, because of stack allocations, not much resident memory in fact.

> once compiler support has improved enough

I give it min 5 years. It's already few year since it was in clang. I don't believe it will be fixed soon in gdb/lldb. You need to introduce many non-generic things: at least new stack chaining debug information for proper call-stacks, which is (and will!) be threadpool-implementation specific, because otherwise it should be part of standard, part of compiler implementation which is even worse. With local vars it's slightly easier however.

Re: C++20: Building a Thread-Pool with Coroutines

#60

Post by sannysanoff »

MichaEiler wrote: post #39
sannysanoff wrote: post #9

I used similar thing, baked on top of cppcoro library (wonderful thing). My application is heavily threaded with hundreds of thousands of short-lived micro-tasks, it's interpreter of highly-parallel expressions, and values are large matrices containing expressions, so it's highly parallelizable. I moved to C++ coroutines from composable futures (CF) library that had few thread pool implementations if memory serves (a…

Having only briefly looked through the code base of libgo. It looks like they use boost::context, which is the only good stackful coroutines implementations I've come across. Not being familiar with your project I'm slightly confused about the statement of "hundreds of thousands of short-lives micro-tasks". This is usually a no-go in case of stackful coroutines, as you would waste too much memory as well as have a lo…

it does not look like it's using boost::context. At least I never saw it in runtime. It's using its own asm routines for save/restore the context.
Post reply on HN