Ancestors

Toot

Written by Sebastian Schöner on 2024-12-13 at 11:58

Why do I have to wait so long for Burst to compile things? Or, "Unity Burst and the Kernel Theory of Video Game Performance":

https://blog.s-schoener.com/2024-12-12-burst-kernel-theory-game-performance/

=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place

Descendants

Written by Aras Pranckevičius on 2024-12-13 at 12:24

@sschoener at least one lesson might be: not all games code is that of boids simulation. glue code is the game code.

=> More informations about this toot | More toots from aras@mastodon.gamedev.place

Written by Sebastian Schöner on 2024-12-13 at 12:27

@aras yes, exactly: Game code is sticky and you want your fingers off it as much as possible because it creates a huge mess, like hot glue.

=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place

Written by Jean-Sébastien Guay on 2024-12-13 at 12:31

@aras @sschoener Also I hear someone whispering in the back of my mind... SPUs... SPUs...

=> More informations about this toot | More toots from skylark13@mastodon.gamedev.place

Written by Josh Simmons on 2024-12-13 at 13:08

@aras @sschoener I would say though, the kernelization approach does work quite well at AAA scale when it's used pervasively, but we can be far more heavy handed with "this is how you do this" than an engine like unity which needs to cater to a wide variety of project scopes. I always read it that the plan would be that burst would take over everything one day, in which case it makes more sense imo, just exceedingly difficult to actually achieve that in a shipping engine.

=> More informations about this toot | More toots from dotstdy@mastodon.social

Written by Sebastian Schöner on 2024-12-13 at 14:13

@dotstdy @aras Yeah, I don't think it is necessarily wrong or misguided to shoot for kernelization. That's the ideal code you want. But I bet that most games that end up doing this also have glue code that is already 10x to 100x faster than the glue code in Unity :( A lot of problems hide within those two orders of magnitude.

=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place

Written by Josh Simmons on 2024-12-13 at 14:14

@sschoener @aras yeah plus a lot of unity customers just flat out don't need it, so whatever you do it's probably going to look like pointless churn for a significant part of the userbase.

=> More informations about this toot | More toots from dotstdy@mastodon.social

Written by Sebastian Schöner on 2024-12-13 at 14:20

@dotstdy @aras Exactly, fully agreed. Those users would be way better off if their glue code got 10x or 100x faster instead (= compile it natively), yet if you repurpose a solution for Kernels for that, then pain awaits :(

=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place

Written by Arseny Kapoulkine on 2024-12-13 at 19:21

@sschoener @dotstdy @aras My understanding was that Unity does already have the native compilation path through IL2CPP?

=> More informations about this toot | More toots from zeux@mastodon.gamedev.place

Written by Aras Pranckevičius on 2024-12-13 at 19:32

@zeux @sschoener @dotstdy yes but… while it is faster than Mono, it is not close in perf how it “could be”

=> More informations about this toot | More toots from aras@mastodon.gamedev.place

Written by Stefan Reinalter on 2024-12-13 at 19:40

@aras @zeux @sschoener @dotstdy Is there a thorough explanation somewhere how Unity's IL2CPP works in general?

With all the "behind the scenes" stuff?

=> More informations about this toot | More toots from molecularmusing@mastodon.gamedev.place

Written by Sebastian Schöner on 2024-12-13 at 20:07

@aras @zeux @dotstdy Additionally, IL2CPP doesn't help you in the editor :(

=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place

Written by Josh Simmons on 2024-12-13 at 12:46

@sschoener "this is better when you make a build, where Burst does not run on Mono, but that is irrelevant since we need Burst in the editor" to be honest this is one of my biggest pet peeves these days. When you end up creating (usually for good reason at the time) two or more paths with very different performance profiles, and get stuck forever maintaining them both.

=> More informations about this toot | More toots from dotstdy@mastodon.social

Written by Josh Simmons on 2024-12-13 at 13:03

@sschoener mostly because what you end up with is a runtime version that's quite limited for no particularly good reason, and then a separate editor version that's slow for no particularly good reason. But lots of gamedev happens in the editor and tools! I think these days "just make the full featured thing fast" is actually reasonable much of the time.

=> More informations about this toot | More toots from dotstdy@mastodon.social

Written by Alexandre Mutel on 2024-12-14 at 10:55

@sschoener Thanks for your article. I posted a response here https://discussions.unity.com/t/coreclr-and-net-modernization-unite-2024/1519272/346 so that folks on our forum also benefit from it, hope you don't mind! 🤗

=> More informations about this toot | More toots from xoofx@mastodon.social

Written by Sebastian Schöner on 2024-12-14 at 11:13

@xoofx ohh great! Thank you very much! I should link to that in the article as recommended follow-up reading. I think we're in violent agreement here: the clear solution to this conundrum in the long run is exactly what you are doing, and the solution in the short run is to maybe strategically have Burst users insert some function pointers in selected places.

=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place

Written by Alexandre Mutel on 2024-12-14 at 13:09

@sschoener hehe, I remember that when you were still at Unity, slightly before leaving, we had similar discussions during our 1-1. I was actually looking for allies on such topic, in order to push within the company, but I had to be careful to probe who could be in the camp of "let's find a better balance" vs "Burst Always, Everywhere, No managed" 😅

=> More informations about this toot | More toots from xoofx@mastodon.social

Written by Alexandre Mutel on 2024-12-14 at 13:12

@sschoener And keep it up! Your articles are great to challenge ourselves, bring external awareness and see if we are that off in our direction 😉

=> More informations about this toot | More toots from xoofx@mastodon.social

Written by Sebastian Schöner on 2024-12-14 at 14:43

@xoofx I have no intention of stopping, haha :)

=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place

Written by Sebastian Schöner on 2024-12-14 at 14:38

@xoofx on the point of "Burst always, everywhere": I think the crucial difference is between "what do we do, now?" and "how do we dig ourselves out of this hole?" Right now, "Burst always, everywhere" is often the only option for users (even internal ones) to get acceptable performance right now, short of writing native code. Which they maybe should be doing at least in the short term, but that makes it hard to interface with large parts of Unity etc. So that leads to using Burst more and more

=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place