I'm seeing a lot of examples that create 'new' variable in ECS inner loops, isn't this bad practice?

Basically in old school optimisation initialising or creating a variable in an inner loop is sub-optimal, every time the loop goes around the program creates a new variable. When an external to the loop variable could be used for better performance e.g:

Code (CSharp):

1. public void Execute(ref Postion pos)
2. {
3.    float3 value = position.Value;
4.  
5.   // do some stuff
6. }

Where ideally you would allocate the "float3 value" outside of the loop or in this case function and then that saves you the creation cost in the loop where it will cost you every loop.

I know I should benchmark this, take my own advice, but thought I would put it out there to see if the old school optimisations still apply to this new Burst ECS system/technology?

 

There's no heap allocation on struct/value variables, it will probably get mapped to a register or some place in the stack.

 

That's why I think structs on C# should not need new keyword, because it can be confusing to many devs when it its allocated on heap vs stack.

As long as you keep using structs, you are good to declare new variables even inside loops.

By the way, this isn't Unity fault, its C#. Just to note.

 

I had this discussion before I don't think it's actually in the spec about where structs are placed.
Maybe something changed in newer versions. But it also seems like most implementations do it this way though.
So in the end maybe the same thing.

 

Specifically, https://blogs.msdn.microsoft.com/er...e-stack-is-an-implementation-detail-part-one/

The JIT compiler will also optimise out most inner-loop recalculations, I'm led to believe, although of course we still try to do them outside anyway. Don't think the Burst compiler affects this specifically, but I may be wrong.

 

So does the Burst Compiler work on IL code or does it work on C# code?

 

Burst compiler compiles C# to IL(? probably, though I know it uses LLVM so maybe it goes straight to machine code (through LLVM's version of IL)), and either LLVM or the Mono JIT will do a lot of optimisations as it compiles to machine code.

 

Burst cannot compile C# to IL:
1.) that's what the C# compiler is for
2.) If they'd generate IL, then how could they possibly make use of SIMD instructions?

Burst compiles IL to C#.
IL is already a thing that can be easily parsed / changed / optimized for different things.
The mono jit (and any jit around nowadays) actually doesn't do all that much optimization as people thought they did.
Look it up on the coreFX repo. Take the major C++ compilers as an example, they are lightyears ahead of the jit compiler even though the jit-compilers were hailed as having so much more chances to do even better optimizations (and its true, but nobody really put the work in to actually make it so)

 

Watch the C# to Machine Code talk to learn how that works.

 

At the moment, Brust compiler doesn't works with C# code, only IL generated code. But they are working on a custom Roslyn C# compiler, to have a smarter and performantic compiler focused on Unity. It's important to note that they aren't improving Roslyn C# compiler, they are specializing it on Unity, it's a important difference. That's why they are encoraging us to use that HPC# subset (no classes, no managed code, etc), because the custom C# Roslyn compiler will be capable of doing better otimizations on those subset, since it will have more context and no aliasing (or at least fewer).

 

How would I benchmark this the ECS system is super fast so how would I tell the difference between something that would probably only make fractions of a ms different over extended time runs?