Feedback Burst inspector suggestions

So, I've been using burst for a while now, and I'm really enjoying the absurd performance increase I get from using it, and how convenient it is to use (particularly after burstable functions in 1.5). The documentation and presentations are also great, answering essentially all my questions and teaching me a bunch of new cool stuff. Though, one place I feel is falling a bit behind is the burst inspector. For me, its main convenience is how easy it is to access the generated assembly code, but I think it could be used for more. So, I wrote down some ideas that I think could make it more convenient to interact with, while potentially also lowering the barrier for people who find assembly a bit intimidating or aren't great at reading it.

* Jump Arrows
For me, it's easy to lose track of where I'm jumping from and to, particularly with branchy/jumpy code where I'm also trying to keep the context in my head. Having 'jump arrows' or some other indicator similar to what Cutter and Tracy do (see pictures) might make it easier to keep track of where I'm going and where I was. A "go-to label" option that takes you to the specified label, or alternatively a search function within the assembly would also be great, though it doesn't give the overview that jump arrows would give.

Spoiler: Jump Arrows

* Assembly instruction documentation
Godbolt Compiler Explorer has this really neat feature where you can hover over an assembly instruction and get a brief description (or more in-depth documentation) about that instruction. This is great when you don't have a complete overview of what every assembly instruction does, and saves you having to look it up all the time. The documentation on the burst SIMD intrinsics helped me a lot, mainly due to how easy it was to access, a feature like this would probably be just as helpful.

Spoiler: Godbolt Assembly Documentation

* More information through syntax highlighting
From my understanding of the burst inspector so far, all "regular" assembly instructions are highlighted in teal, and all "SIMD instructions" are highlighted in purple. Having different syntax highlighting on different "categories" of instructions is kinda neat, and perhaps that's something that could be pushed further?
For example, maybe scalar SIMD instructions, wide/proper SIMD instructions, and "infrastructure" instructions could be colored in three different colors. This would turn the smell test presented by Andreas Fredriksson into something you could do with even less effort. Just open up the assembly in burst inspector and check: "do I have a mix of colors in my hot loop?"
This should probably be something that's toggleable, as it might make stuff a bit more chaotic and hard on the eyes. Maybe there are other types of information that could be shown through syntax highlighting?

* Cost Indication
Maybe the assembly instruction documentation could also contain information about the cost of the operation, like numbers from uops.info to give you a feel for how costly something is? An idea that's probably completely unrealistic could be to list the cost next to the instruction in the assembly code, so you could get the cost feeling without having to hover over each instruction in an area you're interested in.
(disclaimer, I'm not great at how CPU's work, particularly in relation to Out of Order execution, but instruction cost should still give "some" indication right?)

I was originally just writing this post to suggest jump arrows, but then I kinda got into thinking about what I would like to see in the burst inspector. So, I don't know if all of this is possible, or if it's more trouble than it's worth, but hopefully, it highlights some of the information I wish was available in the inspector.

 

One huge thing that would make me really happy would be if when you have the Burst Inspector open to a certain area that you are trying to optimize, when your code reloads, it doesn't reset the scroll to the top of page. Makes it a pain every time I reload to see how the assembly has changed.

I believe you need to store the Vector2 scroll value somewhere that won't be reloaded when you recompile everything.

 

This is a great thread!

One thing that I find quite painful when tweaking Burst code for optimisation is the iteration time. This is a problem in all of Unity, but particularly when all I want to do is see how my code change altered the assembly output.

I make one small change, hit save, alt-tab back to Unity to trigger a recompile, wait for it to compile, wait for it to do a domain reload, find and select the Job that I'm working on in the Burst inspector, untick "safety checks" again because it reset when it reloaded for some reason, then scroll back down through it and try to find what changed. Maybe I'm spoiled by Compiler Explorer, but this is a real slog!

My ideal workflow would allow me to stay in the IDE for this. Imagine if we could have a Burst disassembly pane in the IDE that recompiles and updates individual jobs in near real time. At least the domain reload time could be skipped when all we want is to read the assembly output.

Another thing that I'd love is seamless version diffing of the assembly. I quite often copy/paste assembly into VSCode, make a change, go through the whole recompile process, then copy/paste the new assembly into a second VSCode document, then use the VSCode diffing plugin to compare. That's very clunky, and I lose the benefit of syntax highlighting while comparing. The ability to view a diff between recent versions of the same Job would be amazing. If Unity remembered the assembly output of the last N compilations of the Job, a simple "compare to previous" feature would be amazing for those rapid iteration scenarios where we're experimenting. A more complex semantic diff would be the dream, but that's a bigger ask.

 

I haven't looked, but is the Burst Compile editor code exposed? I may be able to hack to to keep the same spot upon code reload.

 

Music to my ears!