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

Looking at Unity made me understand the point of C++ coroutines

mropert.github.io

Post reply on HN
Print view View original

61–70 of 190 posts

Re: Looking at Unity made me understand the point of C++ coroutines

#61

Post by pjmlp »

pjc50 wrote: post #57
Rohansi wrote: post #41

Earlier quoted context omitted.

One annoying piece of Unity's CoreCLR plan is there is no plan to upgrade IL2CPP (Unity's AOT compiler) to use a better garbage collector. It will continue to use Boehm GC, which is so much worse for games.

Why wouldn't they use the GC that comes with the dotnet AOT runtime?

Probably because the AOT runtime doesn't run on game consoles, straight out of the box.

Capcom has their own fork of .NET for the Playstation, for example.

I don't know what kind of GC they implemented.

Re: Looking at Unity made me understand the point of C++ coroutines

#62

Post by spacechild1 »

cherryteastain wrote: post #3

Not an expert in game development, but I'd say the issue with C++ coroutines (and 'colored' async functions in general) is that the whole call stack must be written to support that. From a practical perspective, that must in turn be backed by a multithreaded event loop to be useful, which is very difficult to write performantly and correctly. Hence, most people end up using coroutines with something like boost::asio,…

> that must in turn be backed by a multithreaded event loop to be useful

Why? You can just as well execute all your coroutines on a single thread. Many networking applications are doing fine with just use a single ASIO thread.

Another example: you could write game behavior in C++ coroutines and schedule them on the thread that handles the game logic. If you want to wait for N seconds inside the coroutine, just yield it as a number. When the scheduler resumes a coroutine, it receives the delta time and then reschedules the coroutine accordingly. This is also a common technique in music programming languages to implement musical sequencing (e.g. SuperCollider)

Re: Looking at Unity made me understand the point of C++ coroutines

#63

Post by bullen »

Coroutines generally imply some sort of magic to me.

I would just go straight to tbb and concurrent_unordered_map!

The challenge of parallelism does not come from how to make things parallel, but how you share memory:

How you avoid cache misses, make sure threads don't trample each other and design the higher level abstraction so that all layers can benefit from the performance without suffering turnaround problems.

My challenge right now is how do I make the JVM fast on native memory:

1) Rewrite my own JVM. 2) Use the buffer and offset structure Oracle still has but has deprecated and is encouraging people to not use.

We need Java/C# (already has it but is terrible to write native/VM code for?) with bottlenecks at native performance and one way or the other somebody is going to have to write it?

Re: Looking at Unity made me understand the point of C++ coroutines

#64

Post by DonHopkins »

mgaunard wrote: post #29

Coroutines is just a way to write continuations in an imperative style and with more overhead. I never understood the value. Just use lambdas/callbacks.

The Unity editor does not let you examine the state hidden in your closures or coroutines. (And the Mono debugger is a steaming pile of shit.)

Just put your state in visible instance variables of your objects, and then you will actually be able to see and even edit what state your program is in. Stop doing things that make debugging difficult and frustratingly opaque.

Re: Looking at Unity made me understand the point of C++ coroutines

#65

Post by Sharlin »

fluoridation wrote: post #58
Sharlin wrote: post #51

Earlier quoted context omitted.

C++ destructors and exception safety will likely wreak havoc with any "simple" assembly/longjmp-based solution, unless severely constraining what types you can use within the coroutines.

Not really. I've done it years ago. The one restriction for code inside the coroutine is that it mustn't catch (...). You solve destruction by distinguishing whether a couroutine is paused in the middle of execution or if it finished running. When the coroutine is about to be destructed you run it one last time and throw a special exception, triggering destruction of all RAII objects, which you catch at the coroutine…

Thanks, that's interesting.

Re: Looking at Unity made me understand the point of C++ coroutines

#66

Post by Arch485 »

DonHopkins wrote: post #39
krajzeg wrote: post #35

Earlier quoted context omitted.

Echoing the thoughts of the only current sibling comment: lots of "serious" developers (way to gatekeep here) definitely use coroutines, when they make sense. As mentioned, it's one of the best ways to have something update each frame for a short period of time, then neatly go away when it's not needed anymore. Very often, the tiny performance hit you take is completely outweighed by the maintanability/convenience.

...and then crash when any object it was using gets deleted while it's still running, like when the game changes scenes, but it becomes a manual, error-prone process to track down and stop all the coroutines holding on to references, that costs much more effort than it saves. I've been a serious Unity developer for 16 years, and I avoid coroutines like the plague, just like other architectural mistakes like stringly…

I dunno, I've worked on some pretty big projects that have used lots of coroutines, and it's pretty easy to avoid all of the footguns.

I'm not advocating for the ubiquitous use of coroutines (there's a time and place), but they're like anything else: if you don't know what you're doing, you'll misuse them and cause problems. If you RTFM and understand how they work, you won't have any issues.

Re: Looking at Unity made me understand the point of C++ coroutines

#67

Post by kccqzy »

Sharlin wrote: post #52
mgaunard wrote: post #29

Coroutines is just a way to write continuations in an imperative style and with more overhead. I never understood the value. Just use lambdas/callbacks.

Did you read the article? As the author says, it becomes a state machine hell very quickly beyond very simple examples.

I just don’t agree that it always becomes a state machine hell. I even did this in C++03 code before lambdas. And honestly, because it was easy to write careless spaghetti code, it required a lot more upfront thought into code organization than just creating lambdas willy-nilly. The resulting code is verbose, but then again C++ itself is a fairly verbose language.

Re: Looking at Unity made me understand the point of C++ coroutines

#68

Post by DonHopkins »

Arch485 wrote: post #66
DonHopkins wrote: post #39

Earlier quoted context omitted.

...and then crash when any object it was using gets deleted while it's still running, like when the game changes scenes, but it becomes a manual, error-prone process to track down and stop all the coroutines holding on to references, that costs much more effort than it saves. I've been a serious Unity developer for 16 years, and I avoid coroutines like the plague, just like other architectural mistakes like stringly…

I dunno, I've worked on some pretty big projects that have used lots of coroutines, and it's pretty easy to avoid all of the footguns. I'm not advocating for the ubiquitous use of coroutines (there's a time and place), but they're like anything else: if you don't know what you're doing, you'll misuse them and cause problems. If you RTFM and understand how they work, you won't have any issues.

They're a crutch for people who don't know what they're doing, so of course they invite a whole host of problems that are harder to solve than doing it right in the first place.

If you strictly require people to know exactly what they're doing and always RTFM and perfectly understand how everything works, then they already know well enough to avoid coroutines and SendMessage and UnityEvents and other footguns in the first place.

It's much easier and more efficient to avoid all of the footguns when you simply don't use any of the footguns.

Re: Looking at Unity made me understand the point of C++ coroutines

#69

Post by spacechild1 »

mgaunard wrote: post #29

Coroutines is just a way to write continuations in an imperative style and with more overhead. I never understood the value. Just use lambdas/callbacks.

> Just use lambdas/callbacks.

Lol, no thanks. People are using coroutines exactly to avoid callback hell. I have rewritten my own C++ ASIO networking code from callback to coroutines (asio::awaitable) and the difference is night and day!

Re: Looking at Unity made me understand the point of C++ coroutines

#70

Post by inetknght »

cherryteastain wrote: post #3

Not an expert in game development, but I'd say the issue with C++ coroutines (and 'colored' async functions in general) is that the whole call stack must be written to support that. From a practical perspective, that must in turn be backed by a multithreaded event loop to be useful, which is very difficult to write performantly and correctly. Hence, most people end up using coroutines with something like boost::asio,…

> From a practical perspective, that must in turn be backed by a multithreaded event loop to be useful

Multithreaded? Nope. You can do C++ coroutines just fine in a single-threaded context.

Event loop? Only if you're wanting to do IO in your coroutines and not block other coroutines while waiting for that IO to finish.

> most people end up using coroutines with something like boost::asio

Sure. But you don't have to. Asio is available without the kitchen sink: https://think-async.com/Asio/

Coroutines are actually really approachable. You don't need boost::asio, but it certainly makes it a lot easier.

I recommend watching Daniela Engert's 2022 presentation, Contemporary C++ in Action: https://www.youtube.com/watch?v=yUIFdL3D0Vk

Post reply on HN