The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
For some reason, there appears to be no wickedly efficient mechanism to "switch/case" in IL. Whereas in C for example your switches can form little jmp offset tables .NET compilers do not produce code like this (not even sure if it's possible or at least efficient in IL, I'd have to look)
In fact, the C# compiler will take long switches and turn them into hashtable lookups instead of jmp tables.
What this means in the real world is that generating compiled code to do something like lexing or parsing is slower than generating table driven code in the first place.
For example, a state machine can be rendered as a bunch of labeled code sections that goto/jmp around to each other, and that's how you'd typically compile it, but in .NET this creates significantly *slower* code in practice than generating an array/table driven state machine which doesn't goto/jmp around, but rather performs actions based on array lookups
This is really annoying to me, because I feel like there's a faster option involving generating actual jmp tables for switch cases but either the CIL can't efficiently provide it or the .NET compilers won't produce the code for it. This limits the effective performance I can get out of state machine code.
Look at the original open source "P4" Pascal compiler, from before the "open source" concept was invented : Its only implementation technique was a plain jump table of max 256 entries. HTCW has observed (at least she claims in the root entry of this thread) hash tables.
You can handle all swich variants using if/else sequences. If I were to write this part of a compiler, I would start out with if/else as the only and last resort. As I got around to it, I would gradually add other alternatives to take care of those cases suited for e.g. small jump tables, hash tables etc., and only when those alternatives were not applicable would I fall through to the if/else as the default alternative.
IIRC, the original P-Code compiler for Pascal only allowed a range of 64 to create its jump table. I worked on the compiler for my final year project at Uni (a long time ago) but concentrated on the expression evaluator so never got around to seeing what happened in the range exceeded that amount.
The point is, there's no way that I know of for CIL to have the requisite jmp table to do it properly.
The point may be that you are spending more time writing elaborate essays on the structure of labyrinthine conjectures than on keenly analyzing the design, and outcomes, of experiments you can carry out to test what is possible ... to refine the problem space and narrow the scope of what must be accomplished.
You may not believe this, given my cantankerous history with you ... but, mutatis mutandis, I have come to appreciate your obvious technical gifts, and, I hypothesize that you may be a "Neo" who could actually make generating code for complex business rules from "higher level" abstractions possible for mere mortals.
"If not you, who ? If not now, when" attributed in various forms to Hillel the Elder, and often misattributed in distorted forms to others,
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
I'd argue that in this case my experiments are what led to the essay. It was through experimentation that I found the issue I'm writing about.
"Neo" who could actually make generating code for complex business rules from "higher level" abstractions possible for mere mortals.
Years ago, I did this for a company I worked for. It could generate about 2.5 tiers of a 3 tier web application and supported rest/JSONP before most frameworks. The other half a tier would be the web design part, although you could define the UI elements themselves by attributing the business entities with default appearances that could be overridden on the actual design end.
It wasn't quite for non-developers, but you could define all three (2.5 really) tiers through attributed XSD.
Wow.. this level of performance investigation is beyond me...
I couldn't help but wonder though... have you considered what kind of native code Ryujin (native compiler) ultimately produce, eventually?
Other than that I have to admit the C# doesn't produce the ultimate performance than C++ allegedly produce. I say allegedly because it is, apparently, quite hard to produce consistently.. but doable nonetheless.
C++ doesn't support the full range of case statements you find in VB.Net (and now in C#). The limited support in C++ lends itself to jump tables. The full range unfortunately needs to be compiled to a slew of if then elseif then elseif then else endif statements.
In C# I typically use a class to represent a state in a state machine. However, when the code gets generated it either resolves to an array instantiation with the appropriate state machine information (fastest option under .NET) or it can resolve to series of gotos (can't really switch case here unless you were to have goto case all over the place in which case you may as well just use goto). The latter option doesn't perform as well as the array/table driven approach. In C++ however, the latter would be faster - and I'd be using a switch to make sure the compiler was generating jmp tables.
In C# I typically use a class to represent a state in a state machine.
Fair enough. But if you activate anything as complex as a class mechanism to serve for state value (which in most simpler state machines is nothing more than a scalar value), then I do not understand why you are worried about the compiler using hash tables rather than simple jump tables in a small set of cases where it might have saved you some small fraction of a microsecond.