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

Building a self-contained game in C# under 2 kilobytes

migeel.sk

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Building a self-contained game in C# under 2 kilobytes

#31

Post by soulbadguy »

delta_p_delta_x wrote: post #29
orthoxerox wrote: post #24

Earlier quoted context omitted.

You don't want these optimisations to be on by default. Trimming can cause bugs when your program or one of its libraries relies on reflection and Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications.

> when your program or one of its libraries relies on reflection Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted. > Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications This is intriguing; could you elaborate on the latter? Would tiered JIT perhaps have more runtime information which would be…

> Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted.

In language/platform with dynamic loading, it's hard for the compiler to "perfectly" predict which piece of code will ending up being executed at compile time. I think would result in a lot of false positives.

Re: Building a self-contained game in C# under 2 kilobytes

#32

Post by orthoxerox »

delta_p_delta_x wrote: post #29
orthoxerox wrote: post #24

Earlier quoted context omitted.

You don't want these optimisations to be on by default. Trimming can cause bugs when your program or one of its libraries relies on reflection and Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications.

> when your program or one of its libraries relies on reflection Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted. > Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications This is intriguing; could you elaborate on the latter? Would tiered JIT perhaps have more runtime information which would be…

> This is intriguing; could you elaborate on the latter? Would tiered JIT perhaps have more runtime information which would be more useful when optimising frequently-accessed code paths or tight loops?

Exactly. In addition to that, it's hard for the compiler to guess which branch is the frequent one in code. Or if it's the only one, if, for example, you link against implementations of some interface but only use one at runtime.

Re: Building a self-contained game in C# under 2 kilobytes

#33

Post by MStrehovsky »

delta_p_delta_x wrote: post #29
orthoxerox wrote: post #24

Earlier quoted context omitted.

You don't want these optimisations to be on by default. Trimming can cause bugs when your program or one of its libraries relies on reflection and Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications.

> when your program or one of its libraries relies on reflection Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted. > Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications This is intriguing; could you elaborate on the latter? Would tiered JIT perhaps have more runtime information which would be…

> Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted.

The tooling already generates warnings for any spot in the program that uses reflection _in a way that cannot be statically analyzed_. Fixing code to make it work with trimming is equivalent to fixing warnings. Here are a couple case studies: https://devblogs.microsoft.com/dotnet/creating-aot-compatibl...

Re: Building a self-contained game in C# under 2 kilobytes

#34

Post by dgellow »

flohofwoe wrote: post #14
Genbox wrote: post #6

I love the low level .NET stuff Michael Strehovsky makes. Microsoft has built a feature-rich and easy-to-use environment, but it makes .NET developers think there is only one way to use it: create csproj and call dotnet build. But underneath the covers, there is an extremely powerful compiler (Roslyn) and build-system (msbuild). Combine that with the flexibility of C# and you can develop pretty much anything.

Don't forget the Win32 API which allows to create a window and run an event loop with a handful of simple function calls (even in C# apparently). Then compare that to the APIs that came after (like UWP and WinUI) and shudder in horror.

Win32 and WinUI serve different purposes, they aren’t meant to replace one another. Win32 is simple but also really low level. It’s great to get a window handler and handle low level events but building a modern graphical UI requires at minimum a layout system, that’s where WinUI comes handy.

Also you can now mix Win32 with WinUI via the concept of XAML island. It’s not perfect but you don’t have to be blocked in one world or the other.

Though I personally prefer dealing with WPF via AvaloniaUI, styling with winUI is often too frustrating…

https://www.avaloniaui.net/

Re: Building a self-contained game in C# under 2 kilobytes

#35

Post by Snow_Falls »

flohofwoe wrote: post #15
nwellinghoff wrote: post #11

Very cool. What are the practical implications for this? Would it ever be wise to deploy these techniques for a commercial program? Is the end result more memory efficient during execution?

A small binary size is at least useful when running code in web browsers via WASM. Granted, 2 KByte would be way below diminishing returns, but even a couple of hundred KBytes is rare with high level languages like C# which usually require a big runtime. Even "we care about binary size at all" would be a major step forward for most "professional" applications.

The problem with video games and binary sizes is that the assets (3d models, audio, etc) take far more space than the binaries. And its much harder to compress then while still getting good loading times and high quality.

Re: Building a self-contained game in C# under 2 kilobytes

#36

Post by flohofwoe »

Snow_Falls wrote: post #35
flohofwoe wrote: post #15

Earlier quoted context omitted.

A small binary size is at least useful when running code in web browsers via WASM. Granted, 2 KByte would be way below diminishing returns, but even a couple of hundred KBytes is rare with high level languages like C# which usually require a big runtime. Even "we care about binary size at all" would be a major step forward for most "professional" applications.

The problem with video games and binary sizes is that the assets (3d models, audio, etc) take far more space than the binaries. And its much harder to compress then while still getting good loading times and high quality.

That's a bit of a separate problem since assets can be downloaded as needed in the background while the game is already running, but to even start the game, the first thing that's required is the WASM asset blob so that should be small.

Re: Building a self-contained game in C# under 2 kilobytes

#37

Post by pjmlp »

dgellow wrote: post #34
flohofwoe wrote: post #14

Earlier quoted context omitted.

Don't forget the Win32 API which allows to create a window and run an event loop with a handful of simple function calls (even in C# apparently). Then compare that to the APIs that came after (like UWP and WinUI) and shudder in horror.

Win32 and WinUI serve different purposes, they aren’t meant to replace one another. Win32 is simple but also really low level. It’s great to get a window handler and handle low level events but building a modern graphical UI requires at minimum a layout system, that’s where WinUI comes handy. Also you can now mix Win32 with WinUI via the concept of XAML island. It’s not perfect but you don’t have to be blocked in one…

They were in the days of WinRT/UAP/UWP, but that backfired, and with the mismanagemt no one cares about WinUI 3.0 anyway.

Hence why there is even documentation on how to migrate, now legacy.

https://blogs.windows.com/windowsdeveloper/2014/07/24/introd...

"Roadmap for Windows Runtime apps using C++"

https://learn.microsoft.com/en-us/previous-versions/windows/...

"Win32 and COM APIs for UWP apps"

https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-an...

Specially the subsection "Alternatives to Win32 and COM API".

Re: Building a self-contained game in C# under 2 kilobytes

#38

Post by Snow_Falls »

flohofwoe wrote: post #36
Snow_Falls wrote: post #35

Earlier quoted context omitted.

The problem with video games and binary sizes is that the assets (3d models, audio, etc) take far more space than the binaries. And its much harder to compress then while still getting good loading times and high quality.

That's a bit of a separate problem since assets can be downloaded as needed in the background while the game is already running, but to even start the game, the first thing that's required is the WASM asset blob so that should be small.

Ah that is true, I forgot that you could stream assets via web in a browser. But, surely if you can stream the large assets quickly enough for a decent experience (even with caching) then the initial blob size isn't going to take too long to download in the first place?

Re: Building a self-contained game in C# under 2 kilobytes

#39

Post by dgellow »

pjmlp wrote: post #37
dgellow wrote: post #34

Earlier quoted context omitted.

Win32 and WinUI serve different purposes, they aren’t meant to replace one another. Win32 is simple but also really low level. It’s great to get a window handler and handle low level events but building a modern graphical UI requires at minimum a layout system, that’s where WinUI comes handy. Also you can now mix Win32 with WinUI via the concept of XAML island. It’s not perfect but you don’t have to be blocked in one…

They were in the days of WinRT/UAP/UWP, but that backfired, and with the mismanagemt no one cares about WinUI 3.0 anyway. Hence why there is even documentation on how to migrate, now legacy. https://blogs.windows.com/windowsdeveloper/2014/07/24/introd... "Roadmap for Windows Runtime apps using C++" https://learn.microsoft.com/en-us/previous-versions/windows/... "Win32 and COM APIs for UWP apps" https://learn.microsof…

Thanks pjmlp, you’re always adding great context to windows related discussion. I appreciate!

Re: Building a self-contained game in C# under 2 kilobytes

#40

Post by pjmlp »

dgellow wrote: post #39
pjmlp wrote: post #37

Earlier quoted context omitted.

They were in the days of WinRT/UAP/UWP, but that backfired, and with the mismanagemt no one cares about WinUI 3.0 anyway. Hence why there is even documentation on how to migrate, now legacy. https://blogs.windows.com/windowsdeveloper/2014/07/24/introd... "Roadmap for Windows Runtime apps using C++" https://learn.microsoft.com/en-us/previous-versions/windows/... "Win32 and COM APIs for UWP apps" https://learn.microsof…

Thanks pjmlp, you’re always adding great context to windows related discussion. I appreciate!

You're welcome, it helps that the documentation is still around.

There is stuff from SGI and HP-UX that I can no longer back my comments, as those pages are no longer available on the Web.

Post reply on HN