|
Wordle 947 6/6
⬜⬜⬜⬜⬜
⬜⬜🟩⬜⬜
⬜⬜🟨🟨🟨
⬜🟨🟨🟩⬜
⬜🟨🟩🟩🟩
🟩🟩🟩🟩🟩
Phew.
|
|
|
|
|
Wordle 947 4/6
🟨⬛⬛⬛🟨
⬛⬛🟩🟩⬛
⬛🟨🟩🟩⬛
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 947 4/6
🟨⬜⬜🟨⬜
⬜⬜🟩🟩🟩
⬜🟨🟩🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 947 3/6
⬛🟨🟨⬛🟨
⬛🟨🟩🟩⬛
🟩🟩🟩🟩🟩
Jeremy Falcon
|
|
|
|
|
Wordle 947 3/6*
🟨🟨⬛⬛🟨
⬛⬛🟩🟩🟨
🟩🟩🟩🟩🟩
|
|
|
|
|
I thought it would have come and gone by now. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
|
seems so
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Wordle 946 3/6
⬛⬛🟨⬛🟨
⬛🟨🟨🟨🟨
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 946 3/6*
⬜🟨🟨⬜⬜
⬜🟩⬜🟨🟨
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 946 4/6
⬜⬜⬜⬜⬜
⬜🟩🟩⬜🟨
⬜🟩🟩🟨⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
⬜🟨⬜🟨⬜
⬜⬜🟨⬜⬜
⬜🟩🟩⬜🟨
🟩🟩🟩🟩🟩
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 946 5/6
⬜⬜⬜⬜🟨
🟨🟨🟨⬜🟨
🟨🟨🟩🟨⬜
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Wordle 946 3/6
⬛⬛🟨🟨⬛
⬛🟩🟨🟩⬛
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 946 4/6
⬜⬜⬜🟩⬜
⬜🟩🟩🟩🟩
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩
All 🟩 towers
|
|
|
|
|
Wordle 946 3/6
⬛🟨⬛⬛⬛
🟨🟨🟨🟨🟨
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 946 2/6*
⬛🟨🟨🟨⬛
🟩🟩🟩🟩🟩
According to stats, my 20th 2 out of 540.
|
|
|
|
|
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')) {
}
In MSIL you'd have to pepper the IL you drop for that if construct with a bunch of extra Ldarg_0 arguments to retrieve the this reference 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 the this pointer 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 repeated Ldarg_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
|
|
|
|
|
I really enjoy reading your posts here and am full of admiration for you.
But surely this belongs in Q/A?
|
|
|
|
|
What's the appropriate section when looking for blog posts? It's not exactly a programming question?
I posted it here because I've seen people ask for book recommends and similar about programming concepts, but I've never seen such a question in Q&A (not saying they don't exist, just that I've never seen them)
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
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.
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. If they are developed by the same team, you can expect them to have similar overall structure, but the actual code generation may be quite different - because the CPUs are different. Significant parts may have been created by different people, each of them expert on one specific CPU. Maybe you'll see one optimization on ARM that you do not see on x86, or even the other way around. Maybe one optimization that you expected to see was omitted because it didn't give a speed increase at all, on that specific processor (remember that jitting is done for one specific CPU, e.g. utilizing instruction set extensions available on that specific chip where the jitter is running).
If I could spare the time, it sure would be fascinating to dig into the entire jitter for ARM, say, to learn how many of all the tricks in the book they have implemented. I guess it would be more or less the entire book, but not necessarily for all the latest instruction set extensions. Learning and fully understanding the entire ARM JITter would be a major task, though, way beyond finding out if one specific peephole optimization is applied on one specific CPU chip in one specific context.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
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
|
|
|
|
|
Your first step is to see the disassembly in VS in the debug version. If a loophole optimization is applied in the debug version, you can be sure that it is applied in the release version as well!
Debugging does not by definition imply that the generated code is different from the release version. Sometimes you 'voluntarily' turn off some optimizations while debugging, because e.g. single stepping can be somewhat messy if code has been moved around. (Then we are talking about more advanced, not peephole, optimization.)
The 'Debug' and 'Release' configuration names are arbitrary names. You can create configurations of any other name, and set configuration options for your project for any of your configurations: Project|<name> Properties|Build|Advanced sets the amount of debug generated. In principle you could set Debug information: None for the Debug configuration, and Debug information: Full for the Release configuration, but most developers would find that rather non-intuitive 
In any case, debug information is external to the executable code. E.g. to insert a breakpoint into release code, the debugger finds (from the debug info) the address where you want the BP, stuffs away the original instruction at that address and inserts a BP instruction, which it catches at run time. When the user commands 'go on', it re-inserts the original, stuffed away instruction, pulls the program counter one instruction back and restarts the target process. If the BP is meant to be persistent (not one of the volatile kind like 'run to cursor'), when continuing, the debugger will first execute a single target instruction (the one inserted), re-insert the BP instruction for the next round, and then set the target process running.
Well, this is one way of doing it. It requires write access to code memory. Many CPUs, typically embedded ones, must handle debugging of read only code (for the sake of this discussion, consider code in flash to be read only). They may have a few registers where the debugger can load code addresses that are continuously compared to the instruction pointer. If equal, a debug interrupt is generated. The CPU may have e.g. 4 such registers, so you can only have 4 BPs active at any one time, but they can be set in any release code.
For both (and other) alternatives: If you do not have debug information for the code, then you will have to know the binary address yourself. Nothing keeps you from generating debug information for release code. If you have debug info available and open the disassembly window (Ctrl-Alt-D or Debug|Windows|Disassembly in VS2022) after starting the program, you see the generated code.
An alternative is to generate a plain .exe file and use an external debugger. Note, however, that this file can be moved to any PC of the same CPU family, but that CPU may be lacking some instruction set extensions. The code generator cannot assume that any extension is available, so the code may be less optimized than JITted code, which is tailor made for the local CPU.
In the pre-JITting days, at least some compilers generated startup code for checking extension availability at run time. Before user code was run, it might be patched by the startup routine to use whatever extension was available. This of course required code and a table of all locations requiring patch-up, and startup was slower (but it made the program faster, once it was running). I do not know if dotNet compilers still do this when generating binary stand-alone executables.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
