Does anyone know of a good guide to the MSIL JIT compiler?
-
Quote:
For that specific question, "is the JIT compiler smart enough to resolve those repeated Ldarg_0s into register access?", you'll find the answer with magnitudes less effort (compared to learning the inner workings of a JIT compiler) by compiling and linking the code in a tiny test program, load it into VS and display the disassembly.
I must be a dunce, because I can't get it to disassemble in release.
Quote:
Another remark: JITting is essentially code generation - including loophole optimization. Code generation is inherently CPU dependent. x86, x64 and ARM require significantly different code generators.
I would still expect them all to use registers (assuming the architecture supports it) if one does. Or if not, they will eventually. Looking at the x86 code gives me baseline information I can use to determine the code it produces on most machines, and some insight into how their code generation works generally. Yes they are different, but the performance priorities Microsoft assigns to them won't be. If the x86 JITter uses registers, the ARM one does too, and if it doesn't, it will get there.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I put that code snippet of yours into a tiny test program. Here is the disassembly window in VS2022 for x86 code:
class c {
char current;
public void setA(char c) {
this.current = c;
00EF0DF0 push ebp
00EF0DF1 mov ebp,esp
00EF0DF3 mov word ptr [ecx+4],dx
if ((this.current >= 'A' && this.current <= 'Z') ||
(this.current >= 'a' && this.current <= 'z')) {
00EF0DF7 movzx eax,word ptr [ecx+4]
00EF0DFB cmp eax,41h
00EF0DFE jl Test.c.setA(Char)+015h (0EF0E05h)
00EF0E00 cmp eax,5Ah
00EF0E03 jle Test.c.setA(Char)+01Fh (0EF0E0Fh)
00EF0E05 cmp eax,61h
00EF0E08 jl Test.c.setA(Char)+02Ah (0EF0E1Ah)
00EF0E0A cmp eax,7Ah
00EF0E0D jg Test.c.setA(Char)+02Ah (0EF0E1Ah)
Console.WriteLine("Argument is an alphabetic character");
00EF0E0F mov ecx,dword ptr ds:[3BB24A0h]
00EF0E15 call System.Console.WriteLine(System.String) (65A637B8h)
00EF0E1A pop ebp
00EF0E1B retAnd for x64 code:
class c {
char current;
public void setA(char c) {
this.current = c;
00007FFE45A90EE0 sub rsp,28h
00007FFE45A90EE4 mov word ptr [rcx+8],dx
if ((this.current >= 'A' && this.current <= 'Z') ||
(this.current >= 'a' && this.current <= 'z')) {
00007FFE45A90EE8 movzx ecx,word ptr [rcx+8]
00007FFE45A90EEC cmp ecx,41h
00007FFE45A90EEF jl Test.c.setA(Char)+016h (07FFE45A90EF6h)
00007FFE45A90EF1 cmp ecx,5Ah
00007FFE45A90EF4 jle Test.c.setA(Char)+020h (07FFE45A90F00h)
00007FFE45A90EF6 cmp ecx,61h
00007FFE45A90EF9 jl Test.c.setA(Char)+032h (07FFE45A90F12h)
00007FFE45A90EFB cmp ecx,7Ah
00007FFE45A90EFE jg Test.c.setA(Char)+032h (07FFE45A90F12h)
Console.WriteLine("Argument is an alphabetic character");
00007FFE45A90F00 mov rcx,1FE90003938h
00007FFE45A90F0A mov rcx,qword ptr [rcx]
00007FFE45A90F0D call System.Console.WriteLine(System.String) (07FFEA3F80DB0h)
00007FFE45A90F12 nop
00007FFE45A90F13 add rsp,28h
00007FFE45A90F17 retOn both architectures, the code is identical in default settings for Debug and Release configurations. I'd be surprised if it wasn't, and I'd be surprised if - as you seemed to fear - the base register was reloaded for each of the four tests. I do not have a
-
I put that code snippet of yours into a tiny test program. Here is the disassembly window in VS2022 for x86 code:
class c {
char current;
public void setA(char c) {
this.current = c;
00EF0DF0 push ebp
00EF0DF1 mov ebp,esp
00EF0DF3 mov word ptr [ecx+4],dx
if ((this.current >= 'A' && this.current <= 'Z') ||
(this.current >= 'a' && this.current <= 'z')) {
00EF0DF7 movzx eax,word ptr [ecx+4]
00EF0DFB cmp eax,41h
00EF0DFE jl Test.c.setA(Char)+015h (0EF0E05h)
00EF0E00 cmp eax,5Ah
00EF0E03 jle Test.c.setA(Char)+01Fh (0EF0E0Fh)
00EF0E05 cmp eax,61h
00EF0E08 jl Test.c.setA(Char)+02Ah (0EF0E1Ah)
00EF0E0A cmp eax,7Ah
00EF0E0D jg Test.c.setA(Char)+02Ah (0EF0E1Ah)
Console.WriteLine("Argument is an alphabetic character");
00EF0E0F mov ecx,dword ptr ds:[3BB24A0h]
00EF0E15 call System.Console.WriteLine(System.String) (65A637B8h)
00EF0E1A pop ebp
00EF0E1B retAnd for x64 code:
class c {
char current;
public void setA(char c) {
this.current = c;
00007FFE45A90EE0 sub rsp,28h
00007FFE45A90EE4 mov word ptr [rcx+8],dx
if ((this.current >= 'A' && this.current <= 'Z') ||
(this.current >= 'a' && this.current <= 'z')) {
00007FFE45A90EE8 movzx ecx,word ptr [rcx+8]
00007FFE45A90EEC cmp ecx,41h
00007FFE45A90EEF jl Test.c.setA(Char)+016h (07FFE45A90EF6h)
00007FFE45A90EF1 cmp ecx,5Ah
00007FFE45A90EF4 jle Test.c.setA(Char)+020h (07FFE45A90F00h)
00007FFE45A90EF6 cmp ecx,61h
00007FFE45A90EF9 jl Test.c.setA(Char)+032h (07FFE45A90F12h)
00007FFE45A90EFB cmp ecx,7Ah
00007FFE45A90EFE jg Test.c.setA(Char)+032h (07FFE45A90F12h)
Console.WriteLine("Argument is an alphabetic character");
00007FFE45A90F00 mov rcx,1FE90003938h
00007FFE45A90F0A mov rcx,qword ptr [rcx]
00007FFE45A90F0D call System.Console.WriteLine(System.String) (07FFEA3F80DB0h)
00007FFE45A90F12 nop
00007FFE45A90F13 add rsp,28h
00007FFE45A90F17 retOn both architectures, the code is identical in default settings for Debug and Release configurations. I'd be surprised if it wasn't, and I'd be surprised if - as you seemed to fear - the base register was reloaded for each of the four tests. I do not have a
Yeah, the output is what I was hoping for, and sort of expecting. That answers one question, so thank you.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I know how debug information and symbol mapping and such work. What I don't know is if Microsoft does some magic to the JITter in debug to make it produce different code. So I can't rely on that method.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
If I select code generating for 'Any CPU' the main compiler will generate an IL assembly, which is processed by the JITter when the assembly is run for the first time. At the moment, I am running 32 bit CLR, and that jitter generates exactly the same binary code as the 'x86' CPU option. I'd be very surprised if they were different. I'd be very surprised if there were two different x86 code generators. The linkers do completely different jobs, but not the code generators. I do not understand where MS could do some magic that is not visible in the generated code.
Religious freedom is the freedom to say that two plus two make five.
-
Basically I am not sure about a number of things regarding how it works
if((this.current >= 'A' && this.current <= 'Z') ||
(this.current >= 'a' && this.current <= 'z')) {
// do something
}In MSIL you'd have to pepper the IL you drop for that
ifconstruct with a bunch of extraLdarg_0arguments to retrieve thethisreference for *each* comparison. On x86 CPUs (and well, most any CPU with registers, which IL doesn't really have unless you stretch the terminology to include its list of function arguments and locals) you'd load thethispointer into a register and work off that rather than repeatedly loading it onto the stack every time you need to access it as you would in IL. On pretty much any supporting architecture this is much faster than hitting stack. Maybe an order of magnitude. So my question is for example, is the JIT compiler smart enough to resolve those repeatedLdarg_0s into register access? That's just one thing I want to know. Some avenues of research I considered to figure this out: 1. Running the code through a debugger and dropping to assembly. The only way I can do that reliably is with debug info, which may change how the JITter drops native instructions. I can't rely on it. 2. Using ngen and then disassembling the result but again, that's not JITted, but rather precompiled so things like whole program optimization are in play. I can't rely on it. And I can't find any material that will help me figure that out short of the very dry and difficult specs they release, which I'm not even sure tell me that, since the JIT compiler's actual implementation details aren't part of the standard. What I'm hoping for is something some clever Microsoft employee or blogger wrote that describes the behavior of Microsoft's JITter in some detail. There are some real world implications for some C# code that my library generates. I need to make some decisions about it and I feel like I don't have all the information I need.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Could this be a possible workaround to avoid those extra JIT compiler arguments?
var cur = this.current;
if( cur >= 'A' && cur <= 'Z' || cur >= 'a' && cur <= 'z') {
// do something
} -
Could this be a possible workaround to avoid those extra JIT compiler arguments?
var cur = this.current;
if( cur >= 'A' && cur <= 'Z' || cur >= 'a' && cur <= 'z') {
// do something
}Not in the instance I'm using it in without a rework. I'd have to change the structure of the code, which is made more complicated by the fact that it's a CodeDOM tree instead of real code. Before I do that, I want to make sure I'm not (A) doing something for nothing, and more importantly (B) introducing clutter or extra overhead in an attempt to optimize. I've included a chunk of the state machine runner code which should illustrate the issue I hope.
int p;
int l;
int c;
ch = -1;
this.capture.Clear();
if ((this.current == -2)) {
this.Advance();
}
p = this.position;
l = this.line;
c = this.column;
// q0:
// [\t-\n\r ]
if (((((this.current >= 9)
&& (this.current <= 10))
|| (this.current == 13))
|| (this.current == 32))) {
this.Advance();
goto q1;
}
// [A-Z_hj-kmqxz]
if ((((((((((this.current >= 65)
&& (this.current <= 90))
|| (this.current == 95))
|| (this.current == 104))
|| ((this.current >= 106)
&& (this.current <= 107)))
|| (this.current == 109))
|| (this.current == 113))
|| (this.current == 120))
|| (this.current == 122))) {
this.Advance();
goto q2;
}
// [a]
if ((this.current == 97)) {
this.Advance();
goto q3;
}
// [b]
if ((this.current == 98)) {
this.Advance();
goto q22;
}
// ...snip...
q1:
// [\t-\n\r ]
if (((((this.current >= 9)
&& (this.current <= 10))
|| (this.current == 13))
|| (this.current == 32))) {
this.Advance();
goto q1;
}
return FAMatch.Create(2, this.capture.ToString(), p, l, c);
q2:
// [0-9A-Z_a-z]
if ((((((this.current >= 48)
&& (this.current <= 57))
|| ((this.current >= 65)
&& (this.current <= 90)))
|| (this.current == 95))
|| ((this.current >= 97)
&& (this.current <= 122)))) {
this.Advance();
goto q2;
}
return FAMatch.Create(0, this.capture.ToString(), p, l, c);Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Basically I am not sure about a number of things regarding how it works
if((this.current >= 'A' && this.current <= 'Z') ||
(this.current >= 'a' && this.current <= 'z')) {
// do something
}In MSIL you'd have to pepper the IL you drop for that
ifconstruct with a bunch of extraLdarg_0arguments to retrieve thethisreference for *each* comparison. On x86 CPUs (and well, most any CPU with registers, which IL doesn't really have unless you stretch the terminology to include its list of function arguments and locals) you'd load thethispointer into a register and work off that rather than repeatedly loading it onto the stack every time you need to access it as you would in IL. On pretty much any supporting architecture this is much faster than hitting stack. Maybe an order of magnitude. So my question is for example, is the JIT compiler smart enough to resolve those repeatedLdarg_0s into register access? That's just one thing I want to know. Some avenues of research I considered to figure this out: 1. Running the code through a debugger and dropping to assembly. The only way I can do that reliably is with debug info, which may change how the JITter drops native instructions. I can't rely on it. 2. Using ngen and then disassembling the result but again, that's not JITted, but rather precompiled so things like whole program optimization are in play. I can't rely on it. And I can't find any material that will help me figure that out short of the very dry and difficult specs they release, which I'm not even sure tell me that, since the JIT compiler's actual implementation details aren't part of the standard. What I'm hoping for is something some clever Microsoft employee or blogger wrote that describes the behavior of Microsoft's JITter in some detail. There are some real world implications for some C# code that my library generates. I need to make some decisions about it and I feel like I don't have all the information I need.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Don't expect to see any optimizations in MSIL code, even in Release configuration. They are done by JIT-compiler, and may be more effective, since exact CPU type is known at runtime. You may try to see optimized real Assembly code, but this is difficult task, since there is huge distance from the source C# code and MSIL to machine language instructions.
-
Don't expect to see any optimizations in MSIL code, even in Release configuration. They are done by JIT-compiler, and may be more effective, since exact CPU type is known at runtime. You may try to see optimized real Assembly code, but this is difficult task, since there is huge distance from the source C# code and MSIL to machine language instructions.
I'm aware of that. I am generating MSIL instructions using Reflection Emit as part of my project. The other part generates source code. I would like to ensure that this source code generates IL that will be then be optimized appropriately by the JITter. If not, I will generate the source code differently, but my interest is in post-jitted code. Not the IL.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
If I select code generating for 'Any CPU' the main compiler will generate an IL assembly, which is processed by the JITter when the assembly is run for the first time. At the moment, I am running 32 bit CLR, and that jitter generates exactly the same binary code as the 'x86' CPU option. I'd be very surprised if they were different. I'd be very surprised if there were two different x86 code generators. The linkers do completely different jobs, but not the code generators. I do not understand where MS could do some magic that is not visible in the generated code.
Religious freedom is the freedom to say that two plus two make five.
That seems to be assuming more than I am usually comfortable with when it comes to MS. I've worked at Microsoft and with Microsoft code enough to expect the unexpected deep in the bowels of their frameworks. You should have seen me wrestle with the some less oft used typelib generation functions in oleaut32.dll. I was working there at the time, and nobody could answer me about what the heck they were doing. If they made the JITter produce different code for debug builds than release, it would be totally on brand for them, is what I'm saying, no matter if it's not intuitive. You can't put anything past these people. You really can't. And I know those are names, but Debug generates debug symbols and such. Does the jitter for example? do something different if a pdb is present? Or some other magic signaled by the linker dropping some flag in the binary's metadata? Probably not. "Probably" is doing a lot of heavy lifting there.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'm aware of that. I am generating MSIL instructions using Reflection Emit as part of my project. The other part generates source code. I would like to ensure that this source code generates IL that will be then be optimized appropriately by the JITter. If not, I will generate the source code differently, but my interest is in post-jitted code. Not the IL.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
"
Quote:
Running the code through a debugger and dropping to assembly. The only way I can do that reliably is with debug info, which may change how the JITter drops native instructions. I can't rely on it.
Probably, the answer is here: Do PDB Files Affect Performance? Generally, the answer is: No. Debugging information is just additional file, which helps debugger to match the native instructions and source code. Of course, if implemented correctly. The article is written by John Robbins.
-
"
Quote:
Running the code through a debugger and dropping to assembly. The only way I can do that reliably is with debug info, which may change how the JITter drops native instructions. I can't rely on it.
Probably, the answer is here: Do PDB Files Affect Performance? Generally, the answer is: No. Debugging information is just additional file, which helps debugger to match the native instructions and source code. Of course, if implemented correctly. The article is written by John Robbins.
I think that's about unmanaged code, and not the JITter
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I think that's about unmanaged code, and not the JITter
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Well, buzzwords like .NET, VB .NET, C#, JIT compiler, ILDASM are used in this article only by accident. You are right.
-
Well, buzzwords like .NET, VB .NET, C#, JIT compiler, ILDASM are used in this article only by accident. You are right.
I am tired and I read the first bit of it. Sorry. It's 3am here and I shouldn't be awake.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Basically I am not sure about a number of things regarding how it works
if((this.current >= 'A' && this.current <= 'Z') ||
(this.current >= 'a' && this.current <= 'z')) {
// do something
}In MSIL you'd have to pepper the IL you drop for that
ifconstruct with a bunch of extraLdarg_0arguments to retrieve thethisreference for *each* comparison. On x86 CPUs (and well, most any CPU with registers, which IL doesn't really have unless you stretch the terminology to include its list of function arguments and locals) you'd load thethispointer into a register and work off that rather than repeatedly loading it onto the stack every time you need to access it as you would in IL. On pretty much any supporting architecture this is much faster than hitting stack. Maybe an order of magnitude. So my question is for example, is the JIT compiler smart enough to resolve those repeatedLdarg_0s into register access? That's just one thing I want to know. Some avenues of research I considered to figure this out: 1. Running the code through a debugger and dropping to assembly. The only way I can do that reliably is with debug info, which may change how the JITter drops native instructions. I can't rely on it. 2. Using ngen and then disassembling the result but again, that's not JITted, but rather precompiled so things like whole program optimization are in play. I can't rely on it. And I can't find any material that will help me figure that out short of the very dry and difficult specs they release, which I'm not even sure tell me that, since the JIT compiler's actual implementation details aren't part of the standard. What I'm hoping for is something some clever Microsoft employee or blogger wrote that describes the behavior of Microsoft's JITter in some detail. There are some real world implications for some C# code that my library generates. I need to make some decisions about it and I feel like I don't have all the information I need.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Basically I am not sure about a number of things regarding how it works
if((this.current >= 'A' && this.current <= 'Z') ||
(this.current >= 'a' && this.current <= 'z')) {
// do something
}In MSIL you'd have to pepper the IL you drop for that
ifconstruct with a bunch of extraLdarg_0arguments to retrieve thethisreference for *each* comparison. On x86 CPUs (and well, most any CPU with registers, which IL doesn't really have unless you stretch the terminology to include its list of function arguments and locals) you'd load thethispointer into a register and work off that rather than repeatedly loading it onto the stack every time you need to access it as you would in IL. On pretty much any supporting architecture this is much faster than hitting stack. Maybe an order of magnitude. So my question is for example, is the JIT compiler smart enough to resolve those repeatedLdarg_0s into register access? That's just one thing I want to know. Some avenues of research I considered to figure this out: 1. Running the code through a debugger and dropping to assembly. The only way I can do that reliably is with debug info, which may change how the JITter drops native instructions. I can't rely on it. 2. Using ngen and then disassembling the result but again, that's not JITted, but rather precompiled so things like whole program optimization are in play. I can't rely on it. And I can't find any material that will help me figure that out short of the very dry and difficult specs they release, which I'm not even sure tell me that, since the JIT compiler's actual implementation details aren't part of the standard. What I'm hoping for is something some clever Microsoft employee or blogger wrote that describes the behavior of Microsoft's JITter in some detail. There are some real world implications for some C# code that my library generates. I need to make some decisions about it and I feel like I don't have all the information I need.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Even if it did, I wouldn't assume that it always would and would do so on all systems. I would code explicitly and not use behaviour that isn't part of the doco.
Well, I didn't ask you what you would do. And this isn't bizdev
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Probably not, since at best it uses Emit facilities and has nothing to do with the final JITter output
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Probably not, since at best it uses Emit facilities and has nothing to do with the final JITter output
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
The JIT (as well as the rest of the runtime) is also [open source](https://github.com/dotnet/runtime/tree/main/src/coreclr/jit) - there's an `optimizer.cpp` in that directory, which might be of interest. Also in that directory is a file (`viewing-jit-dumps.md`) which talks about looking at disassembly, and also mentions [a Visual Studio plugin, Disasmo](https://marketplace.visualstudio.com/items?itemName=EgorBogatov.Disasmo), that simplifies this process. [Edit]Another option - use Godbolt - [it supports C#](https://godbolt.org/z/vnqvGdqfe)![/Edit]
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Basically I am not sure about a number of things regarding how it works
if((this.current >= 'A' && this.current <= 'Z') ||
(this.current >= 'a' && this.current <= 'z')) {
// do something
}In MSIL you'd have to pepper the IL you drop for that
ifconstruct with a bunch of extraLdarg_0arguments to retrieve thethisreference for *each* comparison. On x86 CPUs (and well, most any CPU with registers, which IL doesn't really have unless you stretch the terminology to include its list of function arguments and locals) you'd load thethispointer into a register and work off that rather than repeatedly loading it onto the stack every time you need to access it as you would in IL. On pretty much any supporting architecture this is much faster than hitting stack. Maybe an order of magnitude. So my question is for example, is the JIT compiler smart enough to resolve those repeatedLdarg_0s into register access? That's just one thing I want to know. Some avenues of research I considered to figure this out: 1. Running the code through a debugger and dropping to assembly. The only way I can do that reliably is with debug info, which may change how the JITter drops native instructions. I can't rely on it. 2. Using ngen and then disassembling the result but again, that's not JITted, but rather precompiled so things like whole program optimization are in play. I can't rely on it. And I can't find any material that will help me figure that out short of the very dry and difficult specs they release, which I'm not even sure tell me that, since the JIT compiler's actual implementation details aren't part of the standard. What I'm hoping for is something some clever Microsoft employee or blogger wrote that describes the behavior of Microsoft's JITter in some detail. There are some real world implications for some C# code that my library generates. I need to make some decisions about it and I feel like I don't have all the information I need.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Why not download ILSpy[^] and nosey at the produced IL code? Just compile your application in release mode and take a look at the produced IL to see whether it's been optimised. I would hazard a guess that it probably doesn't optimise something like that, but I could be wrong!
-
Why not download ILSpy[^] and nosey at the produced IL code? Just compile your application in release mode and take a look at the produced IL to see whether it's been optimised. I would hazard a guess that it probably doesn't optimise something like that, but I could be wrong!
Because I'm not interested in the IL code, but in the post jitted native code.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
The JIT (as well as the rest of the runtime) is also [open source](https://github.com/dotnet/runtime/tree/main/src/coreclr/jit) - there's an `optimizer.cpp` in that directory, which might be of interest. Also in that directory is a file (`viewing-jit-dumps.md`) which talks about looking at disassembly, and also mentions [a Visual Studio plugin, Disasmo](https://marketplace.visualstudio.com/items?itemName=EgorBogatov.Disasmo), that simplifies this process. [Edit]Another option - use Godbolt - [it supports C#](https://godbolt.org/z/vnqvGdqfe)![/Edit]
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Oh wow. I learned two new things from your post. Thanks! Will check that out.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix