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.
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.
I'm not a python dev. I have written exactly zero bits of software in it.
That said, even I know you can do practically anything with it, and a lot of complicated things can be shockingly easy to do in python.
I'm guessing that's probably why it's so popular with the AI crowd.
The thing that keeps me away from it is the significant whitespace in the grammar** and my general distaste for scripting. I know both of those things are just me being nit picky but we all have our preferences.
**I'm deeply concerned about this as it raises a lot of questions. Is 4 spaces read the same way as a tab? Is my editor going to destroy my sourcecode if it reformats the document? etc. I really don't like this.
Another problem with whitespace is which definition of whitespace. Python scopes by a subset of whitespace characters. I guess this subset is defined in a language spec, but there is only one way to be reasonably sure to avoid problems: Whenever anyone says "whitespace", read it as "a space character".
I agree though I'll say I've written enough parsers and grammars that I guess I expect it to be a language specific subset of whitespace (the JSON standard grammar has a similar issue) but that's me. It's rare that I've found languages that accept literally any whitespace you can throw at it. I think C# is an exception in that it can handle it (but I'd have to look to be certain)