Hi,

One other thing that is missing with switch, little combination, which is
possible and could also be used to improve reduce code is inside the switch
statement is a before-cases: block, which will run if default case is not
being executed
and already know its going to be one of the other cases, then I can add
section of common code before any cases run, which just logic next step,
where code could be insert at zero cost, inline of the execution sequence
.
So basically before-cases: block

Switch(switchValue, SwitchConstraintModifiersHints) {
before-cases:, when case 0,1,2 are to be execute this will run, but not for
the default case.
case 0:break;
case 1: break;
case 2: break;
default: break;
}

Kind Regards,

Wesley Oliver



On Fri, Feb 5, 2021 at 2:11 PM Wesley Oliver <wesley.olis_at_[hidden]> wrote:

> Hi,
>
> I have been looking to optimize an algorithm execution, with some
> adaptations and improved logic.
> One of the things I can across is that I could improve performance by
> handling a few special end condition cases differently and further again by
> adding upper bounder range check,
> The upper bound range check along for default gave me 5-6% performance
> increase, giving me a total of like 10-14% overall, by combination of a if
> upper range check and switch.
> I am sure with this suggested improvement, the compiler will be able to
> improve this even further with a single compound statement switch
> statement as I proposed below.
> So for example:
> case - 2: at times.
> case -1: continue/runout/run-on with instructions.
> case 0: the same thing.
> for these case just run out.
> case 1: optimize section of handling .
> break or goto
> case 2: optimize section of handling.
> break or goto
> case 3: optimize section of handling.
> break or goto
> default: complex logic.
> break or goto
>
> What I have found is that since switch typically gets compiled down to if
> statements or range checks for default. There is a nice optimization here,
> which I implemented manual, which speeds things save about 5-6% off, but
> may have room for more assemble optimization.
> At moment I see sub, he, sub, jne optimization for the switch, but feel
> could be more if one included the boundaries checking of default in switch
> statement. As there is still another default boundaries checking of cmp,
> jle, to the switch.
>
> What I would like to propose is SwitchLower and SwitchUpper, which
> determines,
> how upper bound can be checked, this saving a bounds check statement and
> then
> with this new statement it enforcing a constraint that all case have
> sequential identifier, no gaps.
> The code can still be re-ordered for optimization.
>
> With knowledge of this, typically translate the switch to a jump
> switchValue that is already in register that just got ranged checked for
> the default case, subtract the sequentialOffset, then jump by the
> switchValue or relative memory offset or instruction offset, depending on
> instruction set. Then jump one more time to the correct address to continue
> executing from for that case.
> Essentially this is a const stack array of positional jump offset encoding
> directly into the instructions, which should never be exicuted, unless
> random mistake jump to this data.
>
> ASSEMBLE.
> if(switchValue < Upper | Lower | Both range check)
> default code
> else
> {
> switchValue -= SequentialOffset;
> Jump SwitchValue;
> Jump currentcaseinstructionvalue.
> }
>
>
> I would like to recommend/propose
> *switch(SwitchValue, SwitchConstrainsModifierHint) *, where *SwitchConstrainsModifierHint
> = NoCheck | Both | Upper | Lower | NoDefault | Seqeuenced.*
>
> With this additional switchcontrainsModifierHint to a language, the
> compilers can easily understand range and sequence intention, in unsafe
> range check type language,
> which would allow it to further optimize this code much more easily, than
> a massive crazy analysis of the whole program to determine and ensure these
> contrains.
>
> This simple would allow everyone to communicate there intentional uses of
> the switch statement, based the large scope of the program they are
> writing, which would
> allow for it to further optimize the low level code generation and
> increase performance.
>
> I typically I feel that this would be a minor change, because I am not
> awhere of an additional parameter that can be supplied to Switch, the
> SwitchConstraints modified would
> naturally be backwards compatible with all languages and would be a
> progressive improvement. The reason for naturally backwards compatible, is
> that #define could define the sequence false, to be non-op, so in old
> compilers, SwitchConstraintsModiferHints, would be valid and compile, also
> due to
> the fact in C/C++ you can specify multiple commands separated by a comma.
> switch(switchValue, false) already compiles and the compiler
> will optimize away the false value I should hope.
>
> Compilers can progressively take advantage of the hint and improve the
> low-level code generation, eventually leading to faster and more precise
> and consise code
> being written communicate its range behaviours more clearly.
>
> Look forward to hearing what one you guys think.
>
> Kind Regards,
>
> Wesley Oliver
>
> --
> ----
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.olis_at_[hidden]
>

-- 
----
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.olis_at_[hidden]