Also, the C# unmanaged memory access in Unity is a bit nuanced (and different), based on the underlying compilation used. For example, Burst-marked code with unmanaged memory access compiles to CIL bytecode which then directly compiles to native/machine code. That way, it completely bypasses the default relatively slower Unity C/C++ engine (if the same unmanaged memory access wasn’t bursted, it would’ve compiled via the IL2CPP route n sent to Unity C/C++ core engine, I presume). Since Burst is part of HPC#, do you think that the performance of such bursted code with unmanaged memory access might be at par with .NET managed heap allocation ?
@Dmitrii: Nice article. I recently found it while studying unmanaged memory usage in Unity. I was particularly interested in the unmanaged memory access that Unity now provides via its custom native memory allocators, n infrastructure to write custom allocators. Do you think that despite the good policies around using these allocators, unmanaged memory access could also be subject to external memory fragmentation? Since there’s not “master” CLR dividing the unmanaged memory to multiple heaps with trackable allocator-collector models, wouldn’t it eventually face same issues that modern day .NET CoreCLR solves in managed memory access? Would that mean that some kind of compaction methodology would need to be implemented in conjunction with native memory allocators (default or custom) for preventing fragmentation? And since compaction algorithms are slow, would it help game devs to time the compaction calls (during non-critical parts of gameplay)? Have you seen this kind of need in games with 2hrs+ long gaming sessions?
Comments about Memory Mastery: Comparing Unity and .NET Garbage Collection
Also, the C# unmanaged memory access in Unity is a bit nuanced (and different), based on the underlying compilation used. For example, Burst-marked code with unmanaged memory access compiles to CIL bytecode which then directly compiles to native/machine code. That way, it completely bypasses the default relatively slower Unity C/C++ engine (if the same unmanaged memory access wasn’t bursted, it would’ve compiled via the IL2CPP route n sent to Unity C/C++ core engine, I presume). Since Burst is part of HPC#, do you think that the performance of such bursted code with unmanaged memory access might be at par with .NET managed heap allocation ?
😊+
@Dmitrii: Nice article. I recently found it while studying unmanaged memory usage in Unity. I was particularly interested in the unmanaged memory access that Unity now provides via its custom native memory allocators, n infrastructure to write custom allocators. Do you think that despite the good policies around using these allocators, unmanaged memory access could also be subject to external memory fragmentation? Since there’s not “master” CLR dividing the unmanaged memory to multiple heaps with trackable allocator-collector models, wouldn’t it eventually face same issues that modern day .NET CoreCLR solves in managed memory access? Would that mean that some kind of compaction methodology would need to be implemented in conjunction with native memory allocators (default or custom) for preventing fragmentation? And since compaction algorithms are slow, would it help game devs to time the compaction calls (during non-critical parts of gameplay)? Have you seen this kind of need in games with 2hrs+ long gaming sessions?
😊+