Recent

Author Topic: [solved] faster/better (x>1)... or (x in [...]) :)  (Read 824 times)

speter

  • Full Member
  • ***
  • Posts: 183
[solved] faster/better (x>1)... or (x in [...]) :)
« on: February 27, 2021, 01:52:21 am »
G'Day Folks,

I have a range checking function as follows:

Code: Pascal  [Select][+][-]
  1. function rangeOK(x, y : integer) : boolean;
  2. begin
  3.   result := (x >= 1) and (x <= max_cols) and
  4.             (y >= 1) and (y <= max_rows);
  5. end;

would it be more efficient &/or faster to write it as:

Code: Pascal  [Select][+][-]
  1. function rangeOK(x, y : integer) : boolean;
  2. begin
  3.   result := (x in [1..max_cols]) and (y in [1..max_rows]);
  4. end;

I have always assumed that set operations are slower than a "simple" comparison!

cheers
S.
« Last Edit: February 27, 2021, 02:27:21 am by speter »
I climbed mighty mountains, and saw that they were actually tiny foothills. :)

Laz 2.0.10 / FPC 3.2.0 / Windows 10 (64bit)

speter

  • Full Member
  • ***
  • Posts: 183
Re: faster/better (x>1)... or (x in [...]) :)
« Reply #1 on: February 27, 2021, 02:27:02 am »
Well, to answer my own question, the answer is NO. :)

I wrote a program to test the 2 routines and got basically the same speed for each (see attached).

Doing 100 million tests (of the same random numbers); method#1 took 1.98sec and m#2 took 1.95sec; which - I think - totally disproves my old notion that the set comparison version would be slower!

cheers
S.
I climbed mighty mountains, and saw that they were actually tiny foothills. :)

Laz 2.0.10 / FPC 3.2.0 / Windows 10 (64bit)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7021
  • Debugger - SynEdit - and more
    • wiki
Re: faster/better (x>1)... or (x in [...]) :)
« Reply #2 on: February 27, 2021, 02:28:15 am »
First of all: the sets only work for 0..255 (at least in current fpc afaik).

The question of speed can actually not be answered.
That depends on the compiler and options.

It might be that current FPC compiles "Solution A" to faster code, but that the next release will make "Solution A" the slower option.

Same for the speed could go towards either one, depending on compiler options, optimization level, or even for which CPU you compile.

To make it all even better. If you compile the 2 solutions once, with the same fpc, the same settings, for the same cpu, identical....
It could still be that on an Core-I5 computes "Solution A" faster, and a Core-I9 computes "Solution B" faster.



Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7021
  • Debugger - SynEdit - and more
    • wiki
Re: [solved] faster/better (x>1)... or (x in [...]) :)
« Reply #3 on: February 27, 2021, 02:31:56 am »
There is the next thing: Testing in a small loop.

Your CPU will have all and everything cached, near perfect branch prediction.... You need a decent sized code based, that does comparisons like this in plenty of places.

But yes, even then, I would expect the results to be similar.

----
In fact, why don't you compile with -al

And check how much the assembler differs (fpc writes unit1.s for the asm)

circular

  • Hero Member
  • *****
  • Posts: 3679
    • Personal webpage
Re: [solved] faster/better (x>1)... or (x in [...]) :)
« Reply #4 on: March 16, 2021, 08:23:19 am »
This might be faster:
Code: Pascal  [Select][+][-]
  1. function rangeOK(x, y : integer) : boolean;
  2. begin
  3.   {$PUSH}{$R-}
  4.   result := (cardinal(x-1) < max_cols) and (cardinal(y-1) < max_rows);
  5.   {$POP}
  6. end;
:D
Conscience is the debugger of the mind

speter

  • Full Member
  • ***
  • Posts: 183
Re: [solved] faster/better (x>1)... or (x in [...]) :)
« Reply #5 on: March 16, 2021, 08:58:47 am »
@ Circular,

Thanks for sharing that. In the program (from the original post) then expected range is about 0..30 - but sometimes I do a "look around" meaning with a given [x,y] search the board around the position +/-3 (hence the need to do a range check); I believe the cardinal type is a positive integer; so it wouldn't work (in my original context). ;)

cheers
S.
I climbed mighty mountains, and saw that they were actually tiny foothills. :)

Laz 2.0.10 / FPC 3.2.0 / Windows 10 (64bit)

circular

  • Hero Member
  • *****
  • Posts: 3679
    • Personal webpage
Re: [solved] faster/better (x>1)... or (x in [...]) :)
« Reply #6 on: March 16, 2021, 01:19:07 pm »
Cardinal is only for the final comparison. That is part of the trick to check for both minimum and maximum bound. You can check for example the range -3..10 like this:
Code: Pascal  [Select][+][-]
  1. function rangeOK(x, y : integer) : boolean;
  2. begin
  3.   {$PUSH}{$R-}
  4.   result := (cardinal(x+3) <= 13) and (cardinal(y+3) <= 13);
  5.   {$POP}
  6. end;
« Last Edit: March 16, 2021, 01:42:03 pm by circular »
Conscience is the debugger of the mind

jamie

  • Hero Member
  • *****
  • Posts: 4346
Re: [solved] faster/better (x>1)... or (x in [...]) :)
« Reply #7 on: March 16, 2021, 08:53:46 pm »
Inline  will make it even faster.
The only true wisdom is knowing you know nothing

 

TinyPortal © 2005-2018