The Lounge - CodeProject

"real world implications for some C# code that my library generates"

I don't think this is a good line of research for that reason.

They will change the JIT in the future. I wouldn't be surprised if there are minor version updates that change how it works.

So how are you going to validate that optimizations that you put into place for one single version will continue to be valid for every version in the future and in the past?

If it's such a significant difference in the generated code then yes.

Especially because in the case I outlined (turns out it does register access after all though) it would require relatively minor adjustments to my generated code to avoid that potential performance pitfall, and do so without significantly impacting readability.

I don't like to wait around and hope that Microsoft will one day do the right thing. I've worked 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 don't know of any developer using the gcc compiler suite who studies one or more of the code generators (quite a bunch is available) to learn how it works, in order to modify their source code to make one specific code generator produce some specific binary code. Not even "minor code adjustments".

The code generator part(s) of gcc is a close parallel to the dotNet jitter. The IL is analogous to the API between the gcc source code parsers (and overall optimizer) and the gcc code generator. When you switch to a newer version of a gcc compiler, you do not adapt your C, C++, Fortran, or whatever, code for making one specific code generator create the very best code. Well, maybe you would do it, but I never met or heard of anyone else who would even consider adapting HLL source code to one specific gcc code generator.

...With one possible exception: Way back in time, when you would go to NetNews (aka. Usenet) for discussions, there was one developer who very intensely claimed that the C compiler for DEC VAX was completely useless! There was this one machine instruction that he wanted the compiler to generate for his C code, but he had found no way to force the compiler to do that. So the compiler was complete garbage!

The discussion involved some very experienced VAX programmers, who could certify that this machine instruction would not at all speed up execution, or reduce the code size. It would have no advantages whatsoever to use that instruction. Yet the insistent developer continued insisting that when he wants that instruction, it is the compiler's d**n responsibility to provide a way to generate it.

I guess that this fellow would go along with you in modifying the source code to fit one specific code generator.

This happened in an age when offline digital storage was limited to (expensive) floppies, and URLs were not yet invented. I found the arguing from this fellow to be so funny that I did preserve it in a printout, where I can also find the specific instruction in question (I have forgotten which one), but that printout is buried deep down in one of my historical IT scrapbooks in the basement. I am not digging up that tonight.

Religious freedom is the freedom to say that two plus two make five.

You're comparing something that involves a total rewrite with a change that makes Advance() take an additional parameter, which it uses instead of current.

So really, you're blowing this out of proportion.

Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix

What I am saying is: Leave peephole optimizing to the compiler/code generator, and trust it at that.

We have been doing that kind of optimizations since the 1960s (starting in the late 1950s!). It is routine work. Any reasonably well trained code generator developer will handle it well using his left hand. If you think you can improve on it, you are most likely wrong. And even if you manage to dig up some special case, for the reduction in time in the execution time of some user level operation, "percent" is likely to be a much too large unit.

Spend your optimizing efforts on considering algorithms, and not the least: data structures. These are way more essential to user perceived execution speed that register allocation. Do timing at user level, not at instruction level.

Religious freedom is the freedom to say that two plus two make five.

The other comment reminded me of what I did long ago.

The C compiler could be configured to emit assembler. I did that, optimized it, then I used that instead of the original C code in the build.

You could certainly do that here.

I could, and indeed I do one small optimization with my Reflect Emit based compiler that isn't possible - at least readily in C#.

C#

if((codepoint>='A' && codepoint<='Z') || codepoint=='_' || (codepoint>='a' && codepoint<='a')

The comparison ranges are in sorted order left to right. So rather than run through all of the || conditions, I short circuit if the minimum of the next range in the series is greater than the codepoint. It's easy to do in IL since all of this is already resolved to a series of jumps. Not so easy in C#.

But I did it there because it was a minor change, and didn't really impact anything. I'd be far more hesitant to create a total fork in my compiler vs. source generator. The performance benefits would have to be compelling.

Fortunately, I didn't need to do that here, because my fears were not realized in the end. The JITter was smart enough to optimize that code. But if it wasn't, I could have reorganized my generated source code to produce more efficient IL, in that it would translate to more efficient native code on most platforms.

I'd have preferred that approach as it keeps things from being black boxed.

Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix

jschell wrote:
The C compiler could be configured to emit assembler. I did that, optimized it, then I used that instead of the original C code in the build.

Did you do much timing to verify the speed gain at the user level? (E.g. from the moment the user supplies some input up to the next request for input from the user. For some applications, you must use other criteria, such as the time from startup to the first screenful has been drawn.)

There are certainly compilers out there that are build by people not very experienced or knowledgeable about compiler optimization. On the other hand, I guess that the true experts keep some tricks up their sleeves. But I'd guess that 98% of all optimizing tricks that have a measurable effect has been documented in publicly available sources. If the compiler writer reads the proper sources and do what they tell him to, there is so little left for "even better" hand optimizing that it certainly isn't worth the effort.

Usually, the compiler knows a lot more than you do about the instruction set, cache, virtual memory etc. It has a lot more background for making the ideal code than you. If you change its proposed code, you will often just be doing it in a different way, but not measurably faster. In the worst case, your 'optimization' may even slow down the code. In the very best case, you may be able to prove a nanosecond or two faster execution - but you need a bag of tricks (not all of them very clean) to 'prove' a speedup at user level.

I have experience with all three of these alternatives. Back in history, you might get a real speedup. First, because on old CPUs the total execution time could be calculated by adding together the cycle counts for every instruction executed. Second, The Book of Well Known Standard Optimizing Tricks was a lot thinner then. The closer we get to the CPUs of today, with a long list of hardware speedup techniques (all sorts of prefetch and lookahead, caches, execution pipelines, speculative execution, ...), the more blurry the 'Add together the timing of all instructions executed' becomes. And The Book is quite thick.

Implement the tricks in the book, and there is not much left to do. But that implementation is the responsibility of the compiler writer.

If you must dig up a really bad compiler written by someone who has never hear of optimization, in order to prove that you can do hand optimizing that has some effect, then you should rather find a better compiler.

Religious freedom is the freedom to say that two plus two make five.

trønderen wrote:
Did you do much timing to verify the speed gain at the user level

Not sure why I did it in the case I remember. Doubt it was speed based though.

trønderen wrote:
Back in history, you might get a real speedup.

One I can recall specifically would have been in the 80s.

Lo and behold, todays newsletter has an article about extracting the assembly that the jit compiler generates, if that's any use ; here[^] if you haven't already seen it.

Super! Yeah I saw that, but after you posted. Thanks!

Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix

Alister Morton wrote:
has an article about extracting the assembly that the jit compiler generates,

Which obviously proves that aliens, spirits and bigfoot all exist.

(And you beat me to posting about that.)

Inventor of NTP protocol that keeps time on billions of devices dies at age 85 | Ars Technica[^]

Sadly, his time has come Rose | [Rose]

Mircea

Someone had to do it first. Dave was that guy.

"A little time, a little trouble, your better day"
Badfinger

IMHO
Time is the most objective thing we have. It doesn't give a crap on your origin, race, social status, money, color of the skin, religion, political believes, ideology... whatever.

It it the same for all, it has the same value for all and everyone of us will regret to have wasted it with less important crap in one way or another...

EDIT: after 3 answers...
One tries to say something "nice" or "deep" and you take it apart with logic...
Seriously people... WT Elephant | [mastadon]

?

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.

modified 20-Jan-24 16:03pm.

Except that subjectively, time is very different for all of us, at various 'times' of our lives. If you are waiting for something important, time can seem to go very slowly. When I was a child, time seemed to run very slow. Now the years just fly by... Looking back, the difference seems stark.

Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver

That's the perception of it in your brain. That's a different story.

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.

I suspect you would view that differently while waiting for the results of significant medical operation on a child.

Why? on the clock the time would be the same for everyone. The perception of it while waiting for the results would be bigger / slower for me, yeah, I give you that, but still the perception of it, not the time itself.

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.

Time is the most objective thing we have.
Not since Einstein's Theory of Relativity was published. Every frame of reference has a different time, and these times cannot, in general, be synchronised (Only frameworks stationary relative to each other can be synchronised.).

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.

Nitpicky... D'Oh! | :doh:

On the other hand... time might be different long in case of the relativity, but the effect to people will still be the same under their own perspective / reality / timeframe / however it is called. So what I told before continue applying, only under a different "speed"

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.

It may be objective, but it's not the same for everyone. General Relativity says otherwise. GR is correct, because if it weren't GPS and other satellite navigation systems wouldn't work.

I didn't say it is the same (phisically). I only said that it doesn't care about anything regarding us while doing its job, that it has the same value for all and that most will end regreting having wasted it.

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.

Well, I mean... space doesn't care either. :shrug:

True.

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.

Welcome to the Lounge