4 ms·

Unity is a clown engine. I remember some guy benchmarked DOTS, against plain old C++ code with OpenGL, just like your dad used to write, and it was no contest,

Unity is a clown engine. I remember some guy benchmarked DOTS, against plain old C++ code with OpenGL, just like your dad used to write, and it was no contest, DOTS couldn't keep up. You have to remember, Unity usually sets the bar very low for themselves, comparing their ancient Mono implementation (they still use the Boehm GC, written in the 1980s!), and when a shiny new performance 'fix' like Burst/DOTS drops, they proudly proclaim how much faster they managed to make things, never mind a modern .NET implementation, like Microsoft's CoreCLR would achieve the same performance without any proprietary tech, without any code modification.

Varriount 3y ago
Huh, I never knew Unity used its own CLR implementation. Any idea why?
- heywhatupboys 3y ago
  Unity is older than the Core runtime. They had to use Mono as their base.
  - fulafel 3y ago
    Assuming they had C# or .NET as a constraint. I'd wager not, they just wanted something that would work for "scripting".
    - geon 3y ago
      C# and their own custom clr language was the only supported languages, so yes.
      - fulafel 3y ago
        There were lots of other languages with support available. I don't think Unity had anyone mandating they had to use .NET or C#.
        speps 3y ago
        It used to be C# along with JS and Boo (a Python for .NET). All docs had examples in order of preference for JS, C#, Boo.
        geon 3y ago
        They called it javascript, but it was not. Not even very similar.
- torginus 3y ago
  I think its implementation is a fork of a 2006-era Mono (a clean room reverse engineered .NET implementation). After a few releases, they had a falling out with the Mono team over licensing, meaning they got stuck on an old release. Besides that, they made a bunch of proprietary changes to Mono to make it run on their engine, and to be able to export to literally any platform under the sun. A lot of platforms, like iOS and consoles have (or had) a strict no-JIT policy, so they needed to come up with statically compiling code to said platforms. One of the methods they used was IL2CCP, which turned .NET bytecode, into horrible looking C++, full of goto-s, weird labels and structs getting passed around. Considering some platforms had limitations like you had to compile the game solely with the C++ compiler the platform supplied, not sure if they had a better solution, but it's still horribly hacky. They've been manually syncing up changes from the more recent versions, but I can't really tell, at what pace. But the thing is, even the official Mono has never really kept pace with MS's implementation, and recently, after the acquisition, Mono was dropped by MS in favor of the CoreCLR.
  - neonsunset 3y ago
    At the moment, Unity is in the middle of the move to "vanilla" flavour of .NET aka CLR. Once they do, it should dramatically improve GC performance in Unity and enable an easier route for targeting AOT-requiring platforms like iOS (it is officially supported as a fully-fledged target for NAOT starting with .NET 8, and there's even rich interop directly with Swift in the plans).
  - nvm0n2 3y ago
    Which platforms require you use a single C++ compiler?
maeln 3y ago
> Unity is a clown engine. I remember some guy benchmarked DOTS, against plain old C++ code with OpenGL, just like your dad used to write, and it was no contest, DOTS couldn't keep up. I don't think it is necessarily a fair or useful comparison. I also wrote several toy 3d engine a few years back, and some where performing better than some "commercial" engine, but it is not hard to do when you don't have to handle cross-platform, and a large number of feature. What is a fairer criticism is that Unity has been unable for the last decade to actually stick to a few features and make them actually mature and production ready. DOTS has been introduced like 4-5 years ago ? And it still feels like a polished tech-demo, not a production ready-system, properly integrated with the rest of the stack. And the same could be said about so many Unity feature. The "legacy" systems are just plain simply more reliable than almost any new feature they started for their replacement.
- torginus 3y ago
  I don't think we disagree on much. Unity has failed to stick the landing on most features developed in the past decade. If you make small to medium sized games, and treat it like 2015-era Unity, it still works decently, but progress since then has been slow going. All the new-ish features since then, like Scriptable Render Pipelines, Networking and DOTS had a rough development path, with constant bugs, breakages and stillborn features, sometimes packages got deprecated before reaching production status. As for the C++/OpenGL comparison, I could've just recommended any common sense approach using industry standard tools, like Unreal. I'm just saying, in terms of code performance, DOTS promised a paradigm shift, this cool new way of structuring code and writing a dialect of C# promised heretofore unseen heights of performance. The reality was that Unity Burst code is barely faster than CoreCLR .NET code, and is slower than straightforward no-frills C++ (but at least you get Unity vendor lock-in). This performance matters when you're trying to code a core game system, like procedural shattering, CSG, or inverse kinematics, doing it in regular C# will bite you in the butt. I'd rather do C++ for the few things where performance matters (not to mention, I'm 99% sure that well-tested high performance open-source C++ implementations of the above problems exist), than let Unity take me for a ride with DOTS. Just take a look at Unreal. I'm pretty sure most of the stuff Unity's still working on wasn't a problem circa UE4 release@2014, and most of their 2014 demos would work in a modern version of Unreal (not sure how much of a breaking change UE5 is, but definitely in the latter UE4 releases).
deleted 3y ago
[deleted]

Varriount 3y ago

Huh, I never knew Unity used its own CLR implementation. Any idea why?

heywhatupboys 3y ago
Unity is older than the Core runtime. They had to use Mono as their base.
- fulafel 3y ago
  Assuming they had C# or .NET as a constraint. I'd wager not, they just wanted something that would work for "scripting".
  - geon 3y ago
    C# and their own custom clr language was the only supported languages, so yes.
    - fulafel 3y ago
      There were lots of other languages with support available. I don't think Unity had anyone mandating they had to use .NET or C#.
      - speps 3y ago
        It used to be C# along with JS and Boo (a Python for .NET). All docs had examples in order of preference for JS, C#, Boo.
        geon 3y ago
        They called it javascript, but it was not. Not even very similar.
torginus 3y ago
I think its implementation is a fork of a 2006-era Mono (a clean room reverse engineered .NET implementation). After a few releases, they had a falling out with the Mono team over licensing, meaning they got stuck on an old release. Besides that, they made a bunch of proprietary changes to Mono to make it run on their engine, and to be able to export to literally any platform under the sun. A lot of platforms, like iOS and consoles have (or had) a strict no-JIT policy, so they needed to come up with statically compiling code to said platforms. One of the methods they used was IL2CCP, which turned .NET bytecode, into horrible looking C++, full of goto-s, weird labels and structs getting passed around. Considering some platforms had limitations like you had to compile the game solely with the C++ compiler the platform supplied, not sure if they had a better solution, but it's still horribly hacky. They've been manually syncing up changes from the more recent versions, but I can't really tell, at what pace. But the thing is, even the official Mono has never really kept pace with MS's implementation, and recently, after the acquisition, Mono was dropped by MS in favor of the CoreCLR.
- neonsunset 3y ago
  At the moment, Unity is in the middle of the move to "vanilla" flavour of .NET aka CLR. Once they do, it should dramatically improve GC performance in Unity and enable an easier route for targeting AOT-requiring platforms like iOS (it is officially supported as a fully-fledged target for NAOT starting with .NET 8, and there's even rich interop directly with Swift in the plans).
- nvm0n2 3y ago
  Which platforms require you use a single C++ compiler?

maeln 3y ago

> Unity is a clown engine. I remember some guy benchmarked DOTS, against plain old C++ code with OpenGL, just like your dad used to write, and it was no contest, DOTS couldn't keep up. I don't think it is necessarily a fair or useful comparison. I also wrote several toy 3d engine a few years back, and some where performing better than some "commercial" engine, but it is not hard to do when you don't have to handle cross-platform, and a large number of feature. What is a fairer criticism is that Unity has been unable for the last decade to actually stick to a few features and make them actually mature and production ready. DOTS has been introduced like 4-5 years ago ? And it still feels like a polished tech-demo, not a production ready-system, properly integrated with the rest of the stack. And the same could be said about so many Unity feature. The "legacy" systems are just plain simply more reliable than almost any new feature they started for their replacement.

torginus 3y ago
I don't think we disagree on much. Unity has failed to stick the landing on most features developed in the past decade. If you make small to medium sized games, and treat it like 2015-era Unity, it still works decently, but progress since then has been slow going. All the new-ish features since then, like Scriptable Render Pipelines, Networking and DOTS had a rough development path, with constant bugs, breakages and stillborn features, sometimes packages got deprecated before reaching production status. As for the C++/OpenGL comparison, I could've just recommended any common sense approach using industry standard tools, like Unreal. I'm just saying, in terms of code performance, DOTS promised a paradigm shift, this cool new way of structuring code and writing a dialect of C# promised heretofore unseen heights of performance. The reality was that Unity Burst code is barely faster than CoreCLR .NET code, and is slower than straightforward no-frills C++ (but at least you get Unity vendor lock-in). This performance matters when you're trying to code a core game system, like procedural shattering, CSG, or inverse kinematics, doing it in regular C# will bite you in the butt. I'd rather do C++ for the few things where performance matters (not to mention, I'm 99% sure that well-tested high performance open-source C++ implementations of the above problems exist), than let Unity take me for a ride with DOTS. Just take a look at Unreal. I'm pretty sure most of the stuff Unity's still working on wasn't a problem circa UE4 release@2014, and most of their 2014 demos would work in a modern version of Unreal (not sure how much of a breaking change UE5 is, but definitely in the latter UE4 releases).

deleted 3y ago

[deleted]