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

71–80 of 190 posts

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

#71

Post by abcde666777 »

repelsteeltje wrote: post #6
abcde666777 wrote: post #2

More broadly the dimension of time is always a problem in gamedev, where you're partially inching everything forward each frame and having to keep it all coherent across them. It can easily and often does lead to messy rube goldberg machines. There was a game AI talk a while back, I forget the name unfortunately, but as I recall the guy was pointing out this friction and suggesting additions we could make at the prog…

> There was a game AI talk a while back, I forget the name unfortunately, but as I recall the guy was pointing out this friction and suggesting additions we could make at the programming language level to better support that kind of time spanning logic. Sounds interesting. If it's not too much of an effort, could you dig up a reference?

You're in luck - it's the first talk at this link, "The Polling Problem": https://www.gdcvault.com/play/1018040/Architecture-Tricks-Ma...

Mind you my memory may have distorted it a little beyond what it was, but it's loosely on the topic!

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

#72

Post by pjc50 »

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…

> Passing uncaught exceptions from the coroutine up to the caller is also pretty easy, because it's all synchronous. You just need to wrap it so it can safely travel across the gap

This is also how dotnet handles it, and you can choose whether to rethrow at the caller site, inspect the exception manually, or run a continuation on exception.

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

#73

Post by pjc50 »

bullen wrote: post #63

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.…

> C# (already has it but is terrible to write native/VM code for?)

What do you mean here? Do you mean hand-writing MSIL or native interop (pinvoke) or something else?

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

#74

Post by DonHopkins »

voidUpdate wrote: post #38
momocowcow wrote: post #31

No serious devs even uses Unity coroutines. Terrible control flow and perf. Fine for small projects on PC.

Just out of interest, how many serious unity devs have you talked to?

I've talked to some non-serious unity devs, like Peter Molyneux...

https://news.ycombinator.com/item?id=47110605

>1h 48m 06s, with arms spread out like Jesus H Christ on a crucifix: "Because we can dynamically put on ANY surface of the cube ANY image we like. So THAT's how we're going to surprise the world, is by giving clues about what's in the middle later on."

https://youtu.be/24AY4fJ66xA?t=6486

Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Click. Moo!

https://www.gamedeveloper.com/design/the-i-curiosity-i-exper...

>"I'm jealous that [Molyneux] made a more boring clicking game than I did." -Ian Bogost

>"I also think Curiosity was brilliant and inspired. But that doesn't make it any less selfish or brazen. Curiosity was not an experiment. 'Experiment' is a rhetorical ruse meant to distract you from the fact that it's promotional." -Ian Bogost

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

#75

Post by kdheiwns »

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…

Never had a crash from that. When the GameObject is destroyed, the coroutine is gone. If you're using a coroutine to manage something outside the scope of the GameObject itself, that's a problem with your own design, not the coroutine itself.

It'd be like complaining about arrays being bad because if you pass a pointer to another object, nuke the original array, then try to access the data, it'll cause an error. That's kind of... your own fault? Got to manage your data better.

Unity's own developers use them for engine code. To claim it's just something for noobs is a bit of an interesting take, since, well, the engine developers are clearly using them and I doubt they're Unity noobs. They made the engine.

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

#76

Post by jayd16 »

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.

You can structure coroutines with a context so the runtime has an idea when it can drop them or cancel them. Really nice if you have things like game objects with their own lifecycles.

For simple callback hell, not so much.

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

#77

Post by Deukhoofd »

pjmlp wrote: post #60
Deukhoofd wrote: post #28

Earlier quoted context omitted.

Thankfully they are actively working towards upgrading, Unity 6.8 (they're currently on 6.4) is supposed to move fully towards CoreCLR, and removing Mono. We'll then finally be able to move to C# 14 (from C# 9, which came out in 2020), as well as use newer .NET functionality. https://discussions.unity.com/t/coreclr-scripting-and-ecs-st...

For several years now, I wonder if it will ever happen.

Well, this is at least an update from earlier this month with a clear roadmap of how they're going to get there. There's hope!

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

#79

Post by jayd16 »

DonHopkins wrote: post #64
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.

Use Rider or Visual Studio. Debugging coroutines should be easy. You just can't step over any yield points so you need to break after execution is resumed. It's mildly tedious but far from impossible.

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

#80

Post by blacklion »

pjc50 wrote: post #15
nananana9 wrote: post #12

You can roll stackful coroutines in C++ (or C) with 50-ish lines of Assembly. It's a matter of saving a few registers and switching the stack pointer, minicoro [1] is a pretty good C library that does it. I like this model a lot more than C++20 coroutines: 1. C++20 coros are stackless, in the general case every async "function call" heap allocates. 2. If you do your own stackful coroutines, every function can suspend…

> You can roll stackful coroutines in C++ (or C) with 50-ish lines of Assembly I'm not normally keen to "well actually" people with the C standard, but .. if you're writing in assembly, you're not writing in C. And the obvious consequence is that it stops being portable. Minicoro only supports three architectures. Granted, those are the three most popular ones, but other architectures exist. (just double checked and…

There is no "Linux/ARM[64]". But there are "Raspberry Pi" and "RISC-V". I don't know such OSes, to be honest :-)

This support table is complete mess. And saying "most platforms are supported" is too optimistic or even cocky.

Post reply on HN