Unity DOTS vs Assembly Benchmark - Which is fastest?

[@lingonstudios]

Wishlist my new game Moose Miners on Steam if you want to support the channel: store.steampowered.com/app/2591410/Moose_Miners/?

[@Jonathan-di1pb]

From C# Unity straight to asm is crazy, props for powering through that. I would think you could a similar level of control in C though.

[@treesd]

Vote for C++ vs Assembly showdown

[@lingonstudios]

I made a follow up video testing some improved versions of the Unity DOTS version made by some viewers with more experience in DOTS. I also made a multi-threaded assembly version to test them against. Check it out here: kzbin.info/www/bejne/bmO7nHRop517hLM

[@lufog]

The strongest argument against assembler is not its poor readability, but its non-portability between different architectures. To port your code to arm, for example, you need to rewrite it from scratch.

[@lingonstudios]

Yeah, if portability is important for a project then assembly is not the right tool for the job

[@PixelThorn]

The more performance you want, the more you have to sacrifice, and the more work you have to get done

[@K3rhos]

​@@lingonstudios Tbh assembly is not the right tool for any given job, just go C or C++, you will get the exact same performance or even better with some compiler optimization and you will have all the advantages that assembly doesn't have.

[@sebito6668]

What would be really interesting is seeing how a C version compares to the ASM version. Since C is portable but still very low level it would be interesting to see how much this added abstraction layer would cost and what may differ in the resulting assembly! :D

[@lingonstudios]

Yeah, I'll probably make a video comparing that at some point

[@RamsLiff]

C compilers are so strong that its more powerfull and better in ASM than almost anyone. If you can see a difference probably It wont matter

[@SnowyPup]

@@lingonstudios I'd be really interested in seeing a C version -- maybe comparing a multithreaded ASM version and a multithreaded C version would be cool. While ASM is nice, gaming on ARM seems like it's starting to pick up and I feel like re-writing the app for arm and for x86 separately wouldn't be feasible. Additionally, have you considered making an OpenCL/CUDA version? Might not be practical, but then there's no need to transfer data from the CPU to the GPU, if it's all in vram anyways.

[@alexdesander]

@@RamsLiff Yea, manually handling assembly really only is worth it when you look at small chunks of code and try to optimize that

[@SomeRandomPiggo]

@@SnowyPup I think the only case where rewriting for ARM would really be necessary is on mobile phones, I think it'll be a reeeeeeally long time before we see ARM being used over x86 for performance > power consumption

[@vialomur__vialomur5682]

Just wow! I've written some simple code for assembly and that's not that hard but.. This is amazing that you are capable to write such code!

[@lingonstudios]

Thanks! :)

[@nthnnnnnnnnn]

I really like the flow of the video and the relevancy of the techniques you've used. Also, it's pretty helpful that it covers the whole spectrum from GameObjects to asm. Thanks for making this.

[@lingonstudios]

Glad you enjoyed it! :)

[@UnofficialFoneE]

Thanks for taking the time to put together the video! It's a little frustrating whenever a new DOTS performance comparison video comes out because it is very difficult to capture the speed of DOTS without sinking thousands of hours into it. Which is what I see in a lot of these videos. For instance, using the MathF library instead of the Unity.Mathimatics library -- which is the one built for Burst -- can make those operations incompatible and lead to big optimization misses. Also, since DOTS supports built-in multithreading, developers tend to abuse this leading to slower code. So, in the future, it would be nice to see a challenge between yourself, and someone who has a lot of experience with DOTS! Lastly, although this is unrelated to DOTS, Unity's renderers are not the best. Any custom solution will 100% blow them away. And really, including rendering into the final numbers felt a little disingenuous considering the point of the video was a comparison between DOTS and Assembly. All in all, I appreciate anyone who takes the time to explore DOTS. And in your case, it might be notable to point out that you have access to X86 SIMD instructions through the Unity.Burst.Intrinsics namespace so you can freely mix assembly SIMD and C# in your DOTS code!

[@sumofat4994]

Dude if you need to be super experienced to get the PERF out of dots it violates their promise of perf by default.

[@UnofficialFoneE]

@@sumofat4994 Depends what you mean by "performance." If anything, the video shows that you can get great performance without being very experienced with DOTS. But the benchmark was DOTS versus handwritten assembly... We were not trying to compare performance by default.

[@sumofat4994]

@@UnofficialFoneE I know I'm replying to ur comment

[@UnofficialFoneE]

@@sumofat4994 I am curious on your thoughts about reaching the "performance by default" promise? In my experience, it seems like DOTS achieves this. My comment was not that DOTS fails to give you performance by default, but instead, order to get the maximum performance out of it, like any tool, you need to be experienced with it. Which is important to the video because the goal is really about exploring the peak capabilities of both approaches.

[@delphicdescant]

So spend thousands of hours getting DOTS to do what it claims to do, or spend a similar amount of time (or less) just writing your own engine code for a better result. Yeah, every time I chance upon a video about Unity, I remain glad that I didn't go down the unity path when I got into game dev. ECS is dead simple. Lots of people used it in their custom engines before unity decided to pretend they invented it. The only question left is: How did Unity manage to botch such a simple concept so badly that it takes that much effort to use it properly?

[@WhiteBoxDev]

Have you considered making assembly tutorials in the context of game development? Your video style would be excellent for that sort of thing.

[@lingonstudios]

I have given it a thought every now and then. It's just that making tutorials take a lot of time, and I'm not sure enough people are interested in actual tutorial about assembly game development. I think videos like this work better since people can be interested in how fast things can be with assembly without being interested in working with assembly themselves.

[@MM-24]

@@lingonstudios one thing, would be a quick overview of how todo it - even a guide. I could see that being a very very popular video overtime. I think most programmers at one time or another have thought about using assembly. If your tutorial could be a guide ... that could be very popular.

[@MM-24]

hate to double post - something like Fireship's 100 sec overview videos (maybe make it 300 sec) would be amazing. And talk about tools and process and where togo for help

[@marcsolis4896]

I would love to see that too (but to be honest, I don't think it will be a very common topic for most game developers, so I'm not sure if it will be worth for a KZbinr perspective )

[@BrentMalice]

@@lingonstudios id never use assembly for anything but im watchin this outta general curiosity. did skip a lot of the dry math stuff that im too dumb to understand. its neat because this is how it used it have to be done right? so seeing even a slice in that context is neat.

[@mlecz]

I would like to see how the multi-threaded assembly version would perform. The problem is that multithreading can impose a considerable overhead which, we recover only after a few threads. In many cases, the multithreaded solution of the problem can be significantly slower even in 2-4 threads than the original single-threaded, but the matter begins to improve significantly with an increase in the number of threads.

[@lingonstudios]

I'm glad to let you know that I actually just completed a multi-threaded assembly version. It did scale quite well actually, so well that it ended up being bottlenecked by the GPU. I'll make a follow up video about it together with some measurements from some improved versions of the DOTS version some more people more experienced with Unity DOTS made. So keep an eye out for that.

[@mlecz]

@@lingonstudios Wow nice, I'm looking forward to the video about it

[@ross9263]

A well designed job system should not cause that much overhead at all. What are you talking about. If locks context switching, deadlocks, etc. are properly designed around

[@chosencode5881]

Thank you i really appreciate this, for the scale and complexity of my games i need to rely on Unity for features (such as VFX, animations, UI, terrain and various level creation tools from the asset store). I would love to see more content of you building with DOTS!

[@lingonstudios]

Thanks :) Yeah there are many benefits with Unity you get for no extra work compared to a custom solution where you would have to make them yourself. And with DOTS there is definitely some good performance to get compared to normal Unity. I'll probably won't be building anything else with DOTS for now though at least. Since for the project I made this comparison for, the performance of huge amounts of entities is the most important things and I don't mind making the other things by myself.

[@voidbinary]

Chris Sawyer would be proud. Always wild to see how much overhead is introduced with other languages and how efficient the same idea could be done in assembly while taking significantly less disk space. I personally miss the old game dev times, in which efficiency was a must and a by-product due to not having go to engine like UE, Unity etc. Really shows how much is possible in a fraction of a size if done on low level

[@nihil75]

Great vid!! I had a similar experience with DOTS.. It's pretty good, but not as good as expected.. especially when I added physics it .. would still use it though :)

[@lingonstudios]

Yeah, it did give a significant performance boost compared to the other Unity versions. So for anyone using Unity, it is definitely worth it.

[@Gapil]

Looking forward for a follow up video with upgrades based on feedbacks received on the reddit thread! :)

[@lingonstudios]

Yeah. Two new versions of the DOTS version have been made by people from the reddit thread which both improved the performance. So I'll probably make an follow up video showcasing the fastest of those versions. "Spoiler alert", it still was not as fast as the assembly version ;)

[@retticle]

Some pretty awesome info! I'm surprised Unity ECS has so much memory overhead. I would love to see a Bevy version as well.

[@lingonstudios]

Thanks! A lot of people have been asking for a bevy version, so maybe I'll have a look at it for a future video

[@empireempire3545]

Big yes for c vs c++ vs assembly showdown :D

[@lingonstudios]

Yeah, many have said they want to see it and I am curious about myself as well, so I guess I have to make that now at some point :)

[@synchaoz]

I'm always amazed and fascinated about performance comparisons like these. What irks me is that I don't comprehend it well enough to understand how to actually make a game out of it that isn't just simple quads moving around.

[@gryasl6231]

wow, the subject of the video is just so interesting

[@ozanyasindogan]

Wow, that's impressing! You really made a big benchmark project, thank you for your effort and sharing this. I didn't even know that you could link Assembly or C binaries with Unity, that's a big finding for me. Although that will work only on Windows and x86 based CPU's as it is now, I mean the Assembly code was crafted that way, that's a great way of optimization. I've seen Zig compiler results on Dave's Garage. I wonder if Zig could produce even more optimized code for this task and can be linked to Unity. Respect! :)

[@lingonstudios]

I think you misunderstood the assembly version. The assembly version is completely standalone and custom built linked directly with DirectX 11. So there is no connection between it and Unity. I just compared it against Unity DOTS since I wanted to see how it would stand against a pure assembly version.

[@Yamyatos]

While initially surprised, i guess it makes sense. The thing is DOTS has to work with everything, while any custom solution (especially to rather small problems such as this) can take even more shortcuts. I wouldnt have thought it was this drastic a comparison. Still, i think when complexity scales up, it would be less of a difference. I also wouldnt be keen on making an actual game in assembly lol.

[@bluzenkk]

would love to see how c++ perform versus asembly under the same parameters

[@lingonstudios]

Yeah, me too. So I'll probably make a video about that as well at some point

[@DonC876]

Would be really cool if someone or a group of people with more experience of developing high performance unity apps with DOTS would try improve the code and then let you bench again. Not using the Mathematics Library is a big one i think and just in general i would be really reall interested in a follow up and finding out how much there's still to gain on these DOTS performance numbers. Great video

[@lingonstudios]

A few people took a look at it and made improved versions of the DOTS version so a follow-up video about that is coming. A lot of people have kept repeating the mathf library ruining performance, but I looked at the assembly generated from it and it was completely reasonable assembly, no function calls or anything that would ruin the performance. And not surprisingly, when they replaced the mathf calls with Unity.Mathematics there were no difference at all in performance

[@DonC876]

@@lingonstudios I thought the point of Mathematics was to enable the use of SIMD instructions, but i mostly work with shader and not very well versed with optimizing cpu side code. I am excited to see the follow up video though :)

[@joakimgille9677]

Cool video. /Edit: Asked about the multi-threaded sync-points in DOTS and its effect on the result; but i was just recommended a follow-up vid you did that addressed it. :)

[@lingonstudios]

Thanks :)

[@cunikmaxiumus755]

Great work, interesting comparison. One thing i miss is just doing multi-threading and seeing the difference between dots, and c# multi-threaded, since dots is like the only one with multi-threading in there, and it would be nice to see if how much all the dots work that has been done, actually gives you back in performance. For game objects you could extrapolate logic to thread tasks using structs or just c# classes, and just move game objects into correct positions and rotations when tasks are done so unity renders it. And non game object is even simpler i suppose..

[@timothy0098]

I must say, I really think it is amazing what the DOTS team have managed to gain in performance with unity. That it is so close to asembly in performance is insane, as you need to remember this is cross platform code. Just incredible. What they have achieved is really next level.

[@assemblyrtsdev]

I had no idea that IL2CPP could rival Burst's performance. Thanks a lot for this thorough comparison!

[@lingonstudios]

Yeah I was a bit surprised as well. There are probably ways of making the Burst version faster, but given how much trouble it was using Burst outside of DOTS I don't see the point in bothering. Better to just go straight to DOTS in that case since Burst fit much better in that context.

[@assemblyrtsdev]

Update: I discovered that in my own tests, Mono is almost as fast as IL2CPP, even for data-oriented code.

[@lingonstudios]

@@assemblyrtsdev That is interesting. Since in the test I made in the video as you can see in the results there was a really big difference between il2cpp, especially for the data oriented code. Could it be that you had a bottleneck that was not in the C# code perhaps?

[@assemblyrtsdev]

@@lingonstudios I just build combat-bees-improved myself, and for me IL2CPP is also a lot faster than Mono in this case. But for some reason there is no meaningful difference in my own EcsPerformanceComparisons repo.

[@ruslansmirnov9006]

brilliant benchmark

[@not_herobrine3752]

now this is what i call real programming; subscribed

[@simoncowell1029]

Cool video ! Yes please, I would like to see a showdown between Assembly, C and C++ !

[@xaviervitor]

Really liked this video. Can you make the same comparison with Raylib? Would be really cool to see how it stacks up. Thanks and good luck with your project!

[@nihil75]

ha! just working on raylib project and would love to know.

[@lingonstudios]

Glad you liked it! Yeah, I already have the start of the Raylib version in repo on Github, so I might turn this whole thing into a series and one with Raylib would be one of the first to come next

[@xaviervitor]

@@lingonstudios cool! looking forward to it.

[@yannmassard3970]

didnt imagine I would see pure ASM coding in GameDev since the end of the Amiga. Tks

[@SoaringSimulator]

There is a Unity tech call Project Tiny. And is a set of workflow features and a specialized build pipeline that allows you to create small, lightweight games.

[@ITR]

For burst compiled code you can use "in" and "ref" to send in structs like arrays and float3 without having to use unsafe

[@developerdeveloper67]

You are a f-ing genius, man. Let's go! ASM games for the win! 💪

[@jokersterritory]

Super cool video and I would love to see a comparison between the Assembly and C/C++ versions!

[@nemikuuro]

Very cool video, thanks!

[@ThePoke151]

Can you do a comparison with bevy? Its a rust based ECS-based game engine and I think it would nicely fit in there! :)

[@TheSast]

Would love to see that!

[@AlexanderBukh]

awesome experiment and demonstration!

[@bolloxim1]

in assembler you have another control option which can be a drastic performance gain , this is the ability to prefetch data before you need it, this requires a complete understanding of your hardware for effectively setting up prefetch. This actually was important on older hardware like ps3 where a memory fetch of 54 cycles from l2 to l1 .. modern intel/amd we are looking at about 12 cycles, but l3 loads are really slow still can be in the 80 cycle range... so prefetching lines before you need them is still a good idea when dealing with high volume of data throughput. I've managed to optimize C code by 20x in assembler with good lookahead cache architecture and cacheline friendly data organization

[@lingonstudios]

Yeah the data is oriented in a way to allow for good cache usage, they are just plain arrays and I was careful to not include more data than needed so as much as possible should fit in the caches. However there is no manual prefetching of data on the x86_64 platform, you just get a 64 byte cache line every time you access memory. But yeah, being cache friendly is of great importance for performance. I think that is the main reason for the performance difference between the Unity DOTS version and the assembly version. Unity DOTS seems to introduce quite a bit of overhead data for each entity which I suspect leads to a lot more cache evictions and need to fetch data more often from l3 or even ram, while in the assembly version should be able to operate mostly from l2 on my cpu

[@mrcrackerist]

Currently trying to write a game engine in C and Vulkan and this blows my mind :)

[@lingonstudios]

I haven't dove properly into the "new" graphics apis yet, but from what I've seen using Vulkan/DX12 compared to OpenGL/DX11 seems to be about the same amount of extra work as using assembly compared to using C. Maybe I'll go all the way and use DX12 with assembly at some point in the future if DX11 ends up being too much of a bottleneck

[@mrcrackerist]

@@lingonstudios I am a bit more familiar with C then Assembly so I went for it, but it seems to be a lot of repetition in Assembly so I was thinking of using C with Assembly modules. Anyways vulkan is fun but lot of boiler plate, I haven't touched DX11 or DX12 do.

[@TminusDoom]

I'm curious what the profiler was saying during the Unity tests.

[@Ketpain]

You sir, are a wizard in my eyes. Hope one day I can be there.

[@hosseinanisi224]

You should definitely compare the performance with unreal c++, btw great video

[@PirateDave83]

Great job LS !! You're one of the best programmer on youtube but for this project I think you try to shoot a fly with a bazooka when you need a fly swatter. For this I suggest to use instead C or C++. They are optimized to machine level and the code are not impossible to understand (even for those who follow you). For the rest I congratulate you. I think it won't be long before some big software house contacts you ( if they haven't already... ) !!

[@nathanfranck5822]

I really did think the Dots version would slap the custom asm version around, since you'd expect the compiler to find all sorts of crazy obscure optimizations. Definitely was surprised!

[@thygrrr]

Unity DOTS actually lets you write to the array ("AsParralelWriter") but random access and aliasing can be a problem. The easiest way is to have 1 fresh array, Allocator Temp or TempJob, write to that, and in another dependent job, simply copy the written array back once all threads are done.

[@ViaConDias]

Love it. You should make this an ASM channel. You are great at both writing and explaining it so I think you should do that and leave all these other (scripting) languages to the wannabe coding channels 😉😅 2 ideas off the top of my head: - Push this bees example to the very limit in efficiency and performance - If you really want to work with a scripting language then integrate one into a game written in ASM (like Lua in C/C++)

[@lingonstudios]

I am thinking of making this benchmark a series and comparing assembly to different programming languages/frameworks and game engines. The next video will be a follow up to this one with an improved version of the Unity DOTS and a multithreaded assembly version. There are still some (perhaps significant )improvements that can be done to even this multithreaded assembly version. But now it ended up being bottlenecked on the GPU for this benchmark. So I'll have to do some adjustments to the test in case I want to push it even further

[@ViaConDias]

@@lingonstudios Nice. I'm really looking forward to that video. I don't know your setup, but if the GPU is the bottleneck maybe do the calculations and don't push it to the GPU? When you got it all optimized find a kid in the neighborhood with a crazy setup to run it. Would that be an option? I'm running a 3080 so you can always hit me up if I could be of any help. ASM is more important today than ever. Not because we need to write it but because too many developers are so abstracted from the hardware that they write very bad code because they just do not understand. They think ASM is just a really old and bad language like Fortran or Cobol they do not know that ASM is "touching metal". For many, they don't even really understand that there is "metal" underneath it all. They don't look lower than the interpreter running their code and for many even that is magic.

[@benceszeplaki7712]

Great video! Not really sure why you picked ASM over C, but I guess it can be just preference. Since you are benchmarking data oriented ECS approaches here, it would be nice to see a Bevy implementation as well.

[@me_owe_ski]

Amazing video. One thing to add would be using custom Renderer for Entities that uses Indirect Instancing. Could help optimizing scene a bit further.

[@onerimeuse]

Forget the Cs, let's see assembly vs rust! (I mean, don't forget c, honestly, I love all of these comparison kinds of videos)

[@lingonstudios]

Yeah, I'll probably make some more comparisons with other languages and engines/frameworks. Maybe rust will be one of them

[@turun_ambartanen]

Nice comparison. I very much prefer the linux way of counting CPU usage: 100% = 1 core. This makes it independent from the core count and much easier to read.

[@delphicdescant]

"Things do what you tell them to do and nothing else." That's my kind of programming. If you haven't checked out Zig before, I think it would fit in nicely with your preferences. I know I've had a blast with it.

[@lingonstudios]

Yeah Zig has caught my interest a bit, it seems quite cool. Maybe I'll try it out against assembly in a future video in this series

[@myelinsheathxd]

Amazing review thx for sharing

[@simpson6700]

Now I'm curious if there are any modern assembly games and how they perform.

[@gutzimmumdo4910]

0

[@JeanLescure]

Assembly vs C vs C++ please

[@gamebuster800]

I've decided to write some core loops of my game that leans heavily on simulating something to C. I haven't been able to benchmark the difference yet (since i'm not done yet) but looking at your results... i'm expecting a pretty decent difference. Writing the core loop in C also allows me to test and benchmark the simulations outside of unity, which also helps since my simulation logic is quite complex. My current simulation is running inside a single GameObject, like your data oriented example. I feel like my development speed with Unity is only high at start. At the moment things start become complicated, any time saved earlier is nullified by time spend debugging. Even the code > compile > run loop is incredibly slow for unity compared to writing it in plain C. Like you said, writing in assembly (or C in my case) is the most enjoyable. It seems that your assembly version runs outside unity. I intent to write my performance sensitive stuff in C and load that into unity. I can then do more high-level stuff in plain C# GameObjects while the performance critical parts are thorougly tested on performance and correctness in C. While I was writing stuff in C, I realised I can just run my C code in a browser using emscripten, which has been a terrible distraction as well.

[@Kevroa1]

Fantastic video

[@xacesraskey5155]

IenableableComponent is prefer -> alive/dead with structure changes?

[@mehmet2247]

Awesome comparision

[@Luxalpa]

If you write to a register, you'll want to give the CPU some time before you go and read from it. So the reads and writes should be more separate. It would be interesting to compare your asm version with one written in C!

[@cloudsquall88]

Since you are clearly very knowledgeable about ECS, could you possibly make a comparison with Bevy also? This was a great video!

[@KingdomTerrahearts]

Honestly, the biggest draw of unity for me is the ease of switching target platforms, the asset store and the ease of making animations and all that (also tools for assisting my workflow). I know there are better optimized and less resource intensive ways of making games, but my motivation would take a big hit if I had to work on visual studio for mostly everything, idk never tried assembly

[@KingdomTerrahearts]

What I was trying to say was that for what I do unity is better, but for your case performance is themost important, meaning I understand your decision

[@lingonstudios]

Yeah, I completely agree. There are a lot of good things included in the Unity package that helps a lot while making games. And with that in mind, the performance increase you can get by using DOTS is just a really nice bonus. But yea for me the performance part was extra important since making a simulation with a really large number of entities is how I am planning to make my future game stand out. And looking at the numbers it seems that it will likely be able to stand out quite a bit even against games made in DOTS.

[@KonradGM]

Wait a seconf im little confused, GameObjects Mono and ILCCP is regular Monobehaviour workflow right? But the other Unity Mono vs UnityIlCCP? Is it only data oriented stack or ecs / dots?

[@lingonstudios]

The Unity Mono and Unity il2cpp are just normal C# written in a data oriented way. So no classes for the data, the data for the bees are just a bunch of arrays. No special Unity features are used in these versions, so no ECS or anything else from DOTS.

[@sirdorius361]

"Switch to Twitter time" haha, I'm borrowing this one

[@kiririn39m8]

Thanks for the vid. By the way, what do you thinks about Unreal's Actor-component approach? As an ex-unity developer i find it quite.. odd and anything i write in it seems much worse than even unity in terms of performance and code clarity. I have a feeling that unreal, at least actors-component is super outdated design. Couldnt fiind any other person whom had also moved from unity to unreal to ask their opinion so far

[@lingonstudios]

I have not worked with Unreal so I don't know the exact details around the Actors. But I have heard that Unreal is quite object oriented which seems weird to me that they would make it like that. I think if I ever were to use Unreal I would probably mostly just use the renderer part of the engine, since that is what is impressive in it anyways, and then build my own engine around it almost. Maybe I'll check out Unreal for a follow-up to this video and put it against assembly in this benchmark. Could be interesting

[@GonziHere]

@@lingonstudios Unreal has recently introduced Mass, which is their own DOTS and it's in cpp, so comparison would certainly be interesting. That being said, I've moved from that engine because of its OOP madhouse. I'm tinkering with Godot, because it's FOSS, it's c++ and doesn't get in the way of data oriented design. I honestly wouldn't expect you to enjoy anything about Unreal, but you might actually somewhat enjoy Godot.

[@gandev5285]

@@lingonstudios A follow up video using Unreal Engine would be very interesting to me. I use Unreal Engine professionally and the Actor / Component system is sort of a nightmare IMO (yes it is very OOP). Mass Entity has got me very interested and I'm wondering how it stacks up to Unity DOTS, as I haven't seen a comparison of those two yet. Also a comparison to a custom solution would be very interesting as well. I don't think Mass is as far along as Unity DOTS however. It would also be interesting to hear your perspective on Unreal in general (although I think I may already know the answer to that for the most part). Just found your channel today and subscribed :)

[@bdennyw1]

I would love to see Zig benchmarked

[@dexterman6361]

Is it possible to use C++ for your processing and see how that goes? I want to try something, but am not skilled enough! Thank you for this video! I'll take a look at the code! A lot to learn! Quick edit, I think the memory usage also includes DLL and other shared bits. It could be the unity runtime itself, the "engine" bits and all other runtime dll being loaded. But not sure.

[@pablomirandaandrade3712]

Great video!

[@lingonstudios]

Thanks!

[@Volker-Dirr]

Nice Video. Question about 19:48 "Disk space usage". Is that the disk space of the binary or of the source? Can you also add the results of the missing one (So source or binary; just the missing one)?

[@lingonstudios]

It is the size of the build, so the runnable binary and any additional data needed. The size of the source depends on what you measure so it would be hard to select something that seems reasonable to compare. The code files of the assembly version are going to be larger than the Unity C# files since there is more code in the assembly version, but still so small sizes it won't be very noticeable. If we include other files than raw code files then we need to decide if we want to treat the whole Unity engine installation as part of it or not, or if we want to look at the size of the cache files generated by Unity (which can be rather large, the Library folder in the Unity project is almost 4gb).

[@Holy_Cannon]

This is a amazing video, you helped explain the registers very well. Are you planning on doing DirectX12 video or tutorial anytime soon?

[@lingonstudios]

No plans on any videos with DirectX12 at the moment, I still have not dove into those "new" apis. I'm still using DirectX11 and opengl for my games and projects. Maybe I'll get into DirectX12 if I find DirectX11 becoming a bottleneck in multithreaded workloads, but I don't think that will be the case in practise for my projects. Since they are mostly about rendering a lot of the same type of mesh rather than a lot of different meshes. And for that DirectX should work fine.

[@jasonwylie1445]

great video, I would have like to see it compared to a compute shader also

[@HyperDev00]

Can the assembly code be portable to different devices? And can you please make tutorials on assembly!!

[@lingonstudios]

Since this is x86_64 assembly it will only run on x86_64 cpus. That means PCs and you could probably make it run on PS5 or the latest Xbox, since both those are using that platform as well. However this particular code base is built with Microsoft's assembler and uses DirectX which means it will only run on windows PCs. You could run it on Linux with something like proton though. For assembly tutorials I would recommend www.youtube.com/@WhatsACreel/ he already has a bunch of good tutorials on the subject.

[@Kazyek]

23:17 the Rust language would like a word with you on that! ;)

[@nah82201]

Great video! Thanks for sharing. Do you have the graphs posted anywhere? Really hard to read on KZbin without being able to zoom in like on a picture (on a phone).

[@lingonstudios]

Sure, here is the google sheets document with the graphs and the measurement data docs.google.com/spreadsheets/d/1BHHkyL6oRTCZ2RkaBtGdHv3rwbANc7zqRNYade0e5Bg/edit?usp=sharing Hopefully that should be somewhat useable on mobile as well

[@nah82201]

@@lingonstudios that’s awesome! Thanks for sharing. 🙏🏻

[@ohfor4523]

I think the real answer is mix and match. You don't need to write the entire thing in ASM or the entire thing in C#. There are pros and cons to each as you rightfully point out; exploring a hybrid approach would be worth a watch.

[@shApYT]

thanks. My next game will be an asic.

[@oswoya]

wich ressources did you use to learn assembly for game programing?

[@hayobouma]

I don’t how this is a thing, like eventually every programming language compiles to asm right?! So I that case it would be more like can I write better asm than the c compiler or the c++ compiler??

[@pikkoblank7123]

Not really programmer here so i don't really get a lot of this, but how hard is to optimize in assembly?

[@ruwe1962]

Maybe you could enable SIMD calculaions in Burst/Dots variants, eg. by using float4 instead of float3 and precalculated vectors for multiplications instead of multiplying componentwise with scalar constants

[@developerdeveloper67]

Can you make a video on how you open a Window's window with assembly? Maybe also how you use OpenGL?

[@developerdeveloper67]

Okay I noticed now you have a tutorial on doing DX on ASM, so I guess you don't do OpenGL.

[@alicivrilify]

Thanks and congratulation for the work! A question: Have you heard of Entitas for Unity? Do you know how it compares to DOTS?

[@lingonstudios]

Yeah I did hear about that a long time ago, before Unity DOTS was announced. Did not know it still existed. I don't know how it compares against DOTS, but my guess would be that it is not as fast. If comparing to the versions I made in the video, my guess is that it would be faster than the gameobject version, but slower than the dataoriented non-DOTS version.

[@AtomicBl453]

it'd be interesting to see how this would perform in higher level languages like Ruby

[@nickgennady]

This probably be a lot to ask but it be cool to see a C version vs Unity and assembly. Also isn't their multiple versions of assembly for different architectures. If so you need to write game multiple times in assembly?

[@lingonstudios]

I will probably do a video comparing a C version to these in the future. Yeah there are a different assembly language for each architecture. This is x86_64 assembly which is what is used for most desktop computers and laptops as well as the last two generations of Xbox and PlayStation. If you wanted a version to run on mobile, Nintendo Switch or Apples new computers you would have to rewrite it completely in arm assembly.

[@Leonard_MT]

​@@lingonstudios Exciting, if the the comparison with C becomes a reality what compiler and optimization flags do you plan to use?

[@tudorelRo]

Great video, very insightful, I do have a question tho. I saw that you made separate builds and measurements for mono and il2cpp for Unity using game objects and Unity using data-oriented design, but you didn't do the same for Burst and DOTS, why is that so? (I am assuming that in the comparison both Unity Burst and Unity Dots are built using mono since it is not specified)

[@lingonstudios]

The Burst and DOTS versions are built with il2cpp. I did not bother doing mono vs il2cpp in those since pretty much all the code is compiled with Burst in those versions anyway, so there is no code that would affect the performance that would be changing.

[@holthuizenoemoet591]

Why not for example go with normal C instead of assembly, like 2011 or something?

[@dan2800]

the dots version considering that if running with 2400MT/s memory that's 1200MHz inf fabric and it's rated for 1800MHz due to it utilizing all threads possible the cross CCD communication could have impact on performace for CPU usage we are talking whole cpu better representation would be to use 100% per thread so dots would be 1500% and ASM like 160% also cpu boost freq and other programs could affect the scheduling and for GPU core and mem freq can be diff from build to build

[@rafa_br34]

It's impressive that you got to that point at creating a game in assembly, however, wouldn't it be easier/smarter to use C++? Assembly isn't usually used anymore because most C++ compilers have tons of optimizing tricks (or that's what I've heard)

[@nicolaastanghe475]

Can't wait to ask ai to write my Code directly in assembly.

[@jonpon-r6w]

I guess the idea won't be making a game in asm but if it's done in c/c++ there's an option to use inline asm for optimization.

[@everythingcouldbesimplify818]

Insane

[@LowLevelLemmy]

if unity is faster then asm then I'm gonna throw away my computer cuz everything i know is a lie

[@loiloe77]

I'll simply get MINDBLOWED if that was the result, lol

[@lingonstudios]

Before making this I actually did think that DOTS would be able to beat the assembly version since it is only single threaded while DOTS is multithreaded. And the assembly version is a somewhat simple implementation, it could be improved by quite a bit probably by better utilising the SIMD instructions

[@KanykaAiM]

Good luck with support of assembly version of a games and porting it on different platforms👍

[@Hazzel31337]

i am using unity and this is verry interessting to see, i didnt even knew about il2cpp! high quality comparision video! i would be interessted to see how unreal with c++ compares and i heared they build their own ECS , no clue how far and usable this one is and how it compares, would be interessting to know

[@lingonstudios]

Thanks! il2cpp is a good boost in performance if you have written performance oriented C# code so definitely recommend using it if you have use for some better cpu performance and don't worry that much about mod support. I'm not familiar with any ECS in Unreal, but then I have not really used Unreal yet. Maybe I'll give it a try for a future entry in this benchmarking series.

[@wilykary]

Just a question, why did you make your game in assembly? It's not cross platform and using something like C is order of magnitudes easier, plus the compiler does optimizations and would probably be just as fast as pure assembly.

[@lingonstudios]

The games I have released so far has not been made in assembly. The first one was in Java (never again), and the second one was made in C with Raylib. I did work on a traffic sim game for a while on my free time in assembly, which has been put on hold for now since that project was a little bit too big to do right now. I plan on making a game in assembly that I will release that I'll probably start this Autumn. The reason for that is partly that I find assembly very enjoyable to write in, but also due to performance. The thing is that if you want really good performance you need to make proper use of the SIMD instructions for the performance critical parts of the game. And you can't really trust the compiler to do that automatically, it works sometimes and sometimes not. So you'd have to babysit the compiler and always check what assembly it generates and to make sure you get the code you want you'd use intrinsics which is basically writing assembly inside C/C++. I personally find just writing pure assembly to be more pleasant than writing C/C++ code with instrinsics. Cross platform is of course a downside of pure assembly, but since I am focusing on PC games, it is really not that important.

[@wilykary]

@@lingonstudios Damn, you really are a freak for enjoying writing assembly over C/C++. I guess the time to performance tradeoff is worth it if you're enjoying the process 🙂.

[@SNkael]

Hello, I have a question please, I dont know Unity Dots and Burst, but I have heard that Burst associated with unity Dots is the most powerful way. But in this comparison, Burst is slower. Why ? It seems to use more precise technique than Dots but waste more performance. Thanks and nice work !

[@lingonstudios]

The version called Burst in the benchmark is Burst without DOTS. It was just a simple port of the normal Unity version to use Burst. That version is still single threaded since it does not use the job system. The DOTS version also uses the Burst compiler, but it also uses the Entities framework and the jobs system for multithreading.

[@SNkael]

@@lingonstudios ok thank you :)

[@NickEnchev]

Memory usage isn't that important, what's more important is seeing how effectively the application is utilizing the cache. Its well known that data-oriented approaches minimize cache misses at the expense of using a lot more memory. I'd be curious to see how well your data-oriented approach utilizes the cache. I know the Data class is static, and the array references are static, but my C++ brain imagines allocating them with "new" would put them on the heap, correct? Since you've split up the data quite a bit, could you be ending up with too much indirection in systems that utilize multiple arrays in their update methods?

[@lingonstudios]

Well they go hand in hand. Since the less memory you need to read, the higher percentage of it can be present in the cache. So it is usually a win to reduce the data you need to store so more entities fit into the cache. In C# if I recall correctly there is no use of static memory. So static is just heap allocated memory that exists the whole runtime of the program. But even in C/C++ where static memory allocations actually exists it would not make that much difference compared to heap allocating them with malloc or new. You might be able to get one fewer pointer deref with a statically allocated array if you use it directly and not passing the array pointer as a parameter to a function, but in this case it would not matter, since that is not where time cpu time is spent anyways. The data is structured so the cache should be used rather well. The Movement struct for example bundles the position and the velocity together since they were mostly used together. Usage of the rest of the data was more spread around in the different systems so I opted to have them as their own arrays. If I were to make an improved version of the assembly version (could be possible with the Unity versions as well with Burst and intrinsics), I would split out the data even more and not use a Vector3 struct, but instead have an array each for x, y and z of the positions and velocity. That would enable using all 8 SIMD lanes available in 256 bit SIMD instead of the 3 being used in the assembly version right now. The cache usage would still be fine as well. Since even though you would access more arrays, that data needs to be read anyways and all the data you get in each cache line while reading from memory will be used in the next iterations of the loop

[@PMX]

Assembler also means you tie yourself to a processor architecture and would need to rewrite a lot to port your game from say x86 to arm

[@neolynxer]

Burst is meant to be used with DOTS or at least Jobs.