No no, is not that will block the threads dedicated for running the coroutines?

Not if your CPU bound tasks is split in smaller segments of known execution duration

Coroutines run on a scheduler, and your tasks can too

I mean if you let your coroutine thread execute long running computation, it will make it unable to pick new coroutine

I mean if you let your coroutine thread execute long running computation, it will make it unable to pick new coroutine

Which is why you split your long cpu bound task in smaller segments

And since in C++ you write the scheduler yourself, you hence have control whether tasks are executed according to which priorities

Not if your CPU bound tasks is split in smaller segments of known execution duration

It still blocks for as long as that segment takes to run. Now imagine it has to handle 100 connections, each doing a long running CPU task, how much total time would that block before it can pick up a new coroutine network connection?

It still blocks for as long as that segment takes to run. Now imagine it has to handle 100 connections, each doing a long running CPU task, how much total time would that block before it can pick up a new coroutine network connection?

It also blocks if your thread is thrown out because your CPU bound task is running, but then you have no control over it

Cooperative multithreading vs preemptive multithreading and all that

It also blocks if your thread is thrown out because your CPU bound task is running, but then you have no control over it

No, it won’t sir, because the OS will handle the context switch. With the approach you mentioned, For example, say you’re parsing a 5 MB JSON file, you’d split it up so the coroutine runs for a second, then pauses, then continues like it or not, it is my understanding until now :) Has that really been proven to give better performance?

But why I have never know of coroutines are heavy used in CPU bound task, in AI library they mostly use OS thread directly

No, it won’t sir, because the OS will handle the context switch. With the approach you mentioned, For example, say you’re parsing a 5 MB JSON file, you’d split it up so the coroutine runs for a second, then pauses, then continues like it or not, it is my understanding until now :) Has that really been proven to give better performance?

And context switch from the OS is uncontrollable, and has worse performance than a user space function call which is the cost of a coroutine resuming

But why I have never know of coroutines are heavy used in CPU bound task, in AI library they mostly use OS thread directly

Because AI libraries have very little concern for concurrency or real-time

Concurrent performance is of very little concern

And context switch from the OS is uncontrollable, and has worse performance than a user space function call which is the cost of a coroutine resuming

I do not think we need to controll the context switch sir, because our goal is to execute the CPU bound task as soon as possible without any delay. It is unsure which one will be slower, combination of 8 threads running coroutines + thread pool for long running CPU task or 8 threads running coroutines + pure xontext switch onless benchmarking it directly too :(

Maybe writing little code demonstrating it?

Maybe writing little code demonstrating it?

I demonstrated it at work. On windows you can have a starvation of the coroutine thread for up to 100ms, on Linux it is better, with no starvations being longer than 40ms. Performance wise I have little to no pessimisation when doing chunked processing via C++ ranges and coroutines together

I used trantor to run the coroutines and Poco thread pool for the separate thread pool

I used trantor to run the coroutines and Poco thread pool for the separate thread pool

Nevermind I used drogon for the coroutines

Do you have a simple backend that use that approach, like just returning hardcoded JSON. I will try to compare it with other approach

Do you have a simple backend that use that approach, like just returning hardcoded JSON. I will try to compare it with other approach

I just used drogon on both client and server side and plotted all the connection times. 64 cores on the server and 16 on the client on a different machine

The work load was a bunch of large data sha1

I just used drogon on both client and server side and plotted all the connection times. 64 cores on the server and 16 on the client on a different machine

If it is Drogon, then the performance is like Java Vertx and Rust backend as my own experience that both are using event loop + thread pool for long running blocking task

If it is Drogon, then the performance is like Java Vertx and Rust backend as my own experience that both are using event loop + thread pool for long running blocking task

I only ever use the thread pool for postgres

And for the given example, I did not use the thread pool from drogon

Just the multithreaded event loop

I only ever use the thread pool for postgres

Why you use thread pool for postgres? Is not there C++ async Postgres driver?

Because Java and other can have async Postgres driver, C++ should can too

Just the multithreaded event loop

Do you use work stealing or do not share task queues?

Using thread pool for Postgres will not scale well :( it reminds me of old Java 😅

Why you use thread pool for postgres? Is not there C++ async Postgres driver?

Drogon doesn't use it, it uses the synchronous driver with its thread pool.

I could make an async Postgres thunk for drogon but that's above my current paygrade

Do you use work stealing or do not share task queues?

Drogon does workstealing

My current project is not in C++ at all, it is all in Elixir so I have no external database

My current project is not in C++ at all, it is all in Elixir so I have no external database

I curious to know, what is the reason to pick elixir? Instead of Java or C#?

Because in my experience, the 2 performance is far above Elixir

I curious to know, what is the reason to pick elixir? Instead of Java or C#?

The application is not performance sensitive but the data is and Elixir allows to have very easy data replication in complex database queries without external database server. Also 80% of the software is telecoms so it is a very suitable tool, and the software has a GPU side part and managing resources across a cluster is easy in Elixir

Oh and if anything becomes a performance bottleneck I can just write a module in C or C++ or Rust

The application is not performance sensitive but the data is and Elixir allows to have very easy data replication in complex database queries without external database server. Also 80% of the software is telecoms so it is a very suitable tool, and the software has a GPU side part and managing resources across a cluster is easy in Elixir

Honestly I never use Elixir seriously, but here mostly uses Java, C#, some uses Go and Rust with Kubernetes that manages the cluster and high availability

Mostly uses managed Kubernetes provided by cloud service for horizontal scalling

And Redis

Honestly I never use Elixir seriously, but here mostly uses Java, C#, some uses Go and Rust with Kubernetes that manages the cluster and high availability

Yeah, I don't need kubernetes and all as Elixir does it all

And we don't do cloud because it is overpriced crappy service

are you going to?

does it matter? if i am not reading in here, i am not disrupting nor causing issues. if i am reading, i am here to learn and get feedback (eventually) about C++ and nothing else. does it harm anything if i am often behind?

i literally have learned at least the minimal basics of C++ language but i'd say only maybe 10% of the entire knowledgebase. i am still a super newb and have a long way to go. To quantify, i have watched most but not all of CB's instructional videos on the topic. and i have a ton of books (real hardcopy and e-book) i am still going thru .... slowly. i like to take my time when learning and not rush nor be rushed. i get negative and even backwards effects from being rushed.

in fact i doubt i am at any skill level above C++ 98 ... let alone 2011 or beyond. i am barely starting out.

i cannot wait to get into GUI and async / concurrency ..... and MPP ...

but i am waiting or going slow, anyway lol

i have also been learning Perl 5 and some Scala as well. but those are on back-burner .... C++ has been my main focus for at least a year now.

Cause I don't do backend in C++, if I had I would have

i love the idea of UI design and UX UI etc etc .... but back-end is where i was best at, when i mastered BASIC at a young age of about 16 (started at age 13). 40 years ago now. :D

Pcs before 2005 had one single core and they run thousands of programs at a time

task-switching is not the same as parallel or concurrency. that was a trick of the OS only.

Have you heard of interrupts?

interrupts are hardware feature using sys calls and IRQ or NMIRQ...

After some time has passed it reallocates where does the execution goes next

that is only task-switching via OS. not concurrency by design of devs

i am a hardware guy... but i did master BASIC before i mastered hardware.

Damn this is a 3 year old msg. Feels like a time travel

my fault..... see above

I mean did not say you can not. It just the same as running goroutines on top of multiple OS threads instead of single thread, the same apply to any simolar approach in other languages. But it does not make it more performant than using OS thread directly, instead it adds unnecerery overhead, note : CPU bound task like AI

when we get AI-only ASICS or SOCs .... will that change? or if isolated to only running on a quiet GPU, will that be any different?

we are entering that era of hardware AI already. barely.

we also have NPUs now. tiny amount. and DPUs as well.... interesting times.

the old Commodore Amiga did a lot of tasks in hardware parallel and it seems ( i hope i am not wrong but i may be ignorant to an extent) that we soon see advances in PC architecture where every kind of task can all execute in parallel on their own chips that are independent.

i want to learn RISC-V someday and i am already reading about Quantum computing ... just to stay informed on new hardware paradigms and how programming in C and C++ and even with scripts .... may all change.

No not, that is moving the long CPU computation to decicated thread pool to achieve true paralel. Because if you run it in coroutine, the OS thread that is meant to handlr accepting new request will be blocked

why, instead of this debate, one of you doesnt just go to the ANSI or ISO standard and just cite how they operate, definitively????

why, instead of this debate, one of you doesnt just go to the ANSI or ISO standard and just cite how they operate, definitively????

He wants to believe that OS thread is forever blocked by the high CPU operation until it releases

He wants to believe that OS thread is forever blocked by the high CPU operation until it releases

i am a newbie and learning all these things fresh and new right in here. i dont care what people want to believe. i want to know specs and limitations of the actual compiler and the extent of the language of what allows what. so ..... i just see the debate as kinda silly.

if that is what he wants to believe, then it sounds like he is talking only about code that operates on hardware sys calls and does not use an OS AT ALL .... ?

embedded code is something i will have to learn eventually though

i mean, coroutines in C++ are new since what, C++21 or 23????

idk...

You implement the scheduler yourself in C++, it is parallel if you will it to be

i thought schedulers were implemented raw in the OS by the kernel developers????

i mean, coroutines in C++ are new since what, C++21 or 23????

C++20

C++20

aha i do know some things then

i thought schedulers were implemented raw in the OS by the kernel developers????

You can execute pieces of code at a time for a "seeming" concurrency too

You can execute pieces of code at a time for a "seeming" concurrency too

i know. task switching in the OS.

And coroutines have support for suspention and resume

One might thought that you may use it for something I dunno

i first learned about task switching the way most newbs did, in windows 3.x .... i never started using *nix until 1998

i know. task switching in the OS.

There are timers and things like that even if you don't wanna use threads

You set up a timer and give it your callback and kernel calls that for you

wow..,.. is that raw in hardware or part of most OS design?

oh you said kernel .... so OS :D

wow..,.. is that raw in hardware or part of most OS design?

It uses interrupts under the hood, but it what os provides you

Cause you can't handle interrupts in usermode

It uses interrupts under the hood, but it what os provides you

i think i understand now. not bad for a newbie like me