Speed Optimisation

1
2
Page 1 of 2

Poll

Would you like to see any of the following options
{$OPTI SPEED}		8 (44.44%)
{$OPTI SPEED_ALL}		4 (22.22%)
{$OPTI SHORT_CIRCUIT_TESTS}		6 (33.33%)
Total votes:		18

This poll ended. You can't vote anymore

Merlin

Administrator

Gender:
Age: 24
Posts: 1409
Registered: 03 / 2005

Subject:

Speed Optimisation

· Posted: 20.08.2018 - 12:15 · #1

Generally there is no conflict between optimising for size or optimising for speed, but there are some exceptions to this.

On occasions speed is more important than size, particularly in interrupts.

I am considering adding a flag

{$OPTI SPEED}

which would apply on a per routine basis, and a

{$OPTI SPEED_ALL}

which would apply globally.

This would disable those (few) optimisations which sacrifice speed for gains in size.

A related optimisation that I am considering is

{$OPTI SHORT_CIRCUIT_TESTS} which would force a short circuit of tests. As an example

if A and B and C(x) then

if A were false then B and C would not be tested. Similarly if B were FALSE then the function C would not be executed.

I would like to know if there is any desire for these features.

Please complete the poll to let me know.

If you do not want any of these, please let me know in comments

pvs-deck

PowerUser

Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1341
Registered: 02 / 2009

Subject:

Re: Speed Optimisation

· Posted: 21.08.2018 - 06:16 · #2

Hallo Merlin,
ich finde einige Flags hier sehr interessant, gerade eine Optimierung auf

Code

{$ OPTI SHORT_CIRCUIT_TESTS}

würde die Geschwindigkeit erhöhen, das wahrscheinlich auf kosten des Speichers, aber gerade bei einer längeren Abfrage könnte man dort die Abfrage sofort beenden, ohne die anderen abzufragen.

-----------------------------
Hello Merlin,
I find some flags very interesting here, just an optimization on

Code

{$ OPTI SHORT_CIRCUIT_TESTS}

would increase the speed, probably at the expense of the memory, but just for a longer query, one could quit the query there immediately, without interrogating the others.

Thorsten

Merlin

Administrator

Gender:
Age: 24
Posts: 1409
Registered: 03 / 2005

Subject:

Re: Speed Optimisation

· Posted: 21.08.2018 - 09:59 · #3

Hi Thorsten.

Thanks for the feed back. I doubt that size would be affected much, but, unusually for the optimiser, program functionality would potentially be affected. In my example above, if A were FALSE, function C would not be called and so any side effects would be lost. That is my only concern.

DavidG

Benutzer

Gender: n/a
Location: Kurrajong (Sydney) NSW
Posts: 22
Registered: 10 / 2005

Subject:

Re: Speed Optimisation

· Posted: 21.08.2018 - 14:41 · #4

Hi Merlin,
I think I was assuming that short circuit evaluation was already happening because I was used to that in Borland Pascal. Definitely a good thing.

DG

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: Speed Optimisation

· Posted: 21.08.2018 - 15:17 · #5

@Merlin, David,

no boolean short circuit is not implemented with AVRco.
Maybe then there are always boolean consts concerned
this could be possible. But at compile time the state of
boolean Vars can not be defined. So at compile time this
operation is simply impossible.

The Merlin optimiser of course also can't see the contents
of such vars or much more the result of a boolean function.
So I think it also will be very very difficult for the Optimiser
to make a short circuit in all cases.

Maybe it is possible to insert a code that does this functionality.
But then it maybe dangereous to not execute boolean functions.

rolf

Merlin

Administrator

Gender:
Age: 24
Posts: 1409
Registered: 03 / 2005

Subject:

Re: Speed Optimisation

· Posted: 21.08.2018 - 17:09 · #6

@Rolf.

Quote

The Merlin optimiser of course also can't see the contents
of such vars or much more the result of a boolean function.
So I think it also will be very very difficult for the Optimiser
to make a short circuit in all cases.

No, the optimiser can't see the result of boolean functions, but I don't think that it needs to. What it can see is when there is an and/or operation followed by (optionally) a TST and conditional jump, and I think that is sufficient in all cases.

Quote

Maybe it is possible to insert a code that does this functionality.
But then it maybe dangereous to not execute boolean functions.

That I agree with, but at the end of the day the programmer would have to make an active choice to implement short circuit, so it is then his responsiblity to ensure that the possible non-execution of such functions is acceptable.

I absolutely would not make it the default, as this would make programs not backwards compatible.

This is not idle speculation. I have looked at real code and how this could be implemented. Of course, there may be obstacles that I have not thought of; that I will not know until I try to implement it. Which is why I want to know if there is support for the idea before I put the effort into implementing it.

mc-electronic

Benutzer

Gender: n/a
Location: Sauerland NRW
Posts: 372
Registered: 03 / 2008

Subject:

Re: Speed Optimisation

· Posted: 22.08.2018 - 09:48 · #7

Hi Merlin,

I agree with DavidG. The Short_Circuit Test would be helpful. I also had assumed it was already in place.
A selective Switch for certain procedures would be useful sometimes.

Generally my main concern is rather with code size and stability. So I appreciate the possibility of selective switches instead of an overall change in the optimizer.

Great tool, the Optimizer!

Michael

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: Speed Optimisation

· Posted: 22.08.2018 - 14:07 · #8

@all,

the words "Delphi has it" are given here several times.
This is true. But Delphi has an "incremental" compiler
which analyses the code while editing it.
I think it will try to execute the code at editing time.
So it will be possible to build an efficient short circuit.

rolf

1
2
Page 1 of 2

Speed Optimisation

Poll

Registered users in this topic