It is asonishing to see that the official guides dedicate just a bunch of paragraphs with no pictures to this editor.
If you want to see if Burst is actually doing something, you’ve got the assembly output but if you’re not an assembly guru or you’re not used to these types of low level coding, you’re absolutely lost. In my case, I’ve no idea how to use the editor. I understand the options and filters, but I need an actual guide with an example on how to see what burst is doing with a method.
Is there any resource, video, article, that you know of, that takes the time to explain this tool?
I read your post yesterday, it was awesome, thanks a lot! Well. It’s just a little bit complicated for some of us to read assembly. It takes a lot of time to understand.
Well. I really need to know one little thing: When you open the Assembly generated code in the inspector, how do you know which exact part is the method you want to see if it is improved or not? How do you find the part you’re looking for? Also in the docs it mentions when you select stuff it is highlighted …in the code. Which code? In visual studio? nothing’s happening there. What does it mean?
The effect it’s describing is persistently indicating what assembly line you clicked on by underlining it in the Burst inspector, where you clicked, and also highlighting registers used in that line (one color per unique register). Other occurrences of the same register in the assembly are highlighted the same color, so you can see where a value came from or went to. It’s not anything to do with highlighting source.
You’re right. I read it wrong.
Well. I don’t know how to compare what is improved and how it looks if it’s not.
For example, in my codebase I’ve got a [BurstCompile] method that is just calling a Dispose() to a native array. That sounds like a silly thing to do, since Burst cannot do a thing there, I guess. But I’d like to see the changes in burst. How do I see the comparison easily? Should I directly read the assembly code?
The comments (starts with #) show the C# lines the assembly roughly corresponds to. You can search for that in the bottom bar, first finding the name of the method or sometimes just the file, and then browsing from there. Math computation also tends to stand out a little better in the assembly. So I usually rely on that to pinpoint specific blocks of code.
Hi @Darkgaze, in general I can recommend doing performance profiling as your main way of figuring out if Burst is “actually doing something”. In general when it comes to performance, measuring is key. If you find something surprising then the next step would be to dig into the generated assembly and possibly compare different variation of your code.
As for actually reading the code and understanding what’s going on, that’s a skill that isn’t specific to Burst and there should be a lot of resources out there if you want to learn. If you’re a person who learns by example and by toying with things I can recommend using the Burst inspector or the wonderful website https://godbolt.org/. Try writing simple functions, see and try to understand the code that comes and then building up more complex functions and see what changes in an exploratory fashion.
Godbolt is great because it also gives to a clear source-to-instruction correspondence. It doesn’t have Burst as a target language, but using C or C++ with the Clang compiler will correspond relatively well to what Burst does (Burst is based on the same technology as Clang: LLVM). I can also recommend trying out different optimization levels (-O1 up yo -O3) to see how the compiler optimizes your code.
If you’re not that used to assembly or low-level coding I can really recommend this video: https://www.youtube.com/watch?v=BpwvXkoFcp8. Andreas Fredriksson gives a good “smell test” for the low-level stuff (this smell test can now be more easily spotted in the burst inspector by turning on the ‘Highlight SIMD Scalar vs Pack’ option). Especially the ‘A more complete example’ at 28:15 is very good imo.
One way to make it easier to find your code in the generated assembly is also to ensure it’s not inlined. So using the MethodImpl attribute on your function with MethodImplOptions.NoInlining (just make sure to remove that attribute when you’re finished unless you want the function to not be inlined). This will generate a call instruction to the function, which will then have it’s name close to where it starts in the burst inspector, making it easier to view in isolation. However, not that that might also drop some optimizations etc that are present in an inlined version. I found it to be a valueable thing to do when I first started out with the inspector though.
Also, just toying around with the inspector, and making a habit of opening it and seeing what you get is a good way to slowly but surely get more familiar with assembly (or at least make it less intimidating that what it can be in the beginning)