Page MenuHomePhabricator

efl: reduce sqrt(2) calculations (division vs multiplication)
Needs ReviewPublic

Authored by ali.alzyod on Jun 8 2020, 9:33 AM.

Diff Detail

rEFL core/efl
No Linters Available
No Unit Test Coverage
Build Status
Buildable 16935
Build 11258: arc lint + arc unit
ali.alzyod created this revision.Jun 8 2020, 9:33 AM

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added:

ali.alzyod requested review of this revision.Jun 8 2020, 9:33 AM

I think you can go ahead and drag the division by 2 into the first sqrt, keeping the 2, which is kind of more readable IMO.

Maybe even dragging it deeper into the formula, resulting in a int operation instead of float operation, maybe resulting in the compiler replacing it with a shift.

@bu5hm4n I am not sure I fully understand your comment, I use M_SQRT1_2 as its faster and readable (IMO).

What i mean is: sqrt(a²+b²) / sqrt(2) can be written as sqrt(a²/2+b²/2).
Additionally if you cast a² and b² to a int, the compiler can reduce this to a shift, eliminating floating point division or mul operations totally, making this even lightweighter than before.
Even more micro optimizing you could write the whole thing as: sqrt((a*a)/2 + (b*b)/2) leaving out a func call, or instruction to floating point pow. This way things stay within none-floating-point op's making it less calc intensive.

raster requested changes to this revision.Jun 9 2020, 2:35 AM
raster added a subscriber: raster.

more important: at normal optimizations (-O2 is pretty normal for production builds or even -O3), does this actually remove a sqrt() function or is the compiler already detecting a sqrt with a constant and pre-calculating it? :) because... looking at the asm output of the compiler.. it figures out that its a constant... even at -O0. it still optimizes it to a constant. compare the asm output of:

printf("hello %1.1f\n", sqrt(2.0));


printf("hello %1.1f\n", M_SQRT1_2);

:) so like the other patch i just said no to... does this make the code easier or harder to read? i could argue its a little harder to read with zero benefits. little literally the same identical asm output... :) sam thing as before - look for things that actually optimize... :)

This revision now requires changes to proceed.Jun 9 2020, 2:35 AM

@raster the problem with sqrt calls is that they do not get replaced in *all* compilers, clang on macos is not capable of doing that (i have no idea why). gcc on my raspi is also not doing it here ...

The reason why i think this has potential is that we can completely get rid of the call, simply by throwing math at it, making it a simple full number op.

First : this is very small impact.
Second : you are talking only about specific compiler(s) , or maybe most of them, but this is not general thing everywhere.

As @bu5hm4n mention, this is dependent on compiler, you can try and you will see a lot of compiler does not have this kind of optimization

ali.alzyod abandoned this revision.Jun 16 2020, 12:11 AM
ali.alzyod reclaimed this revision.Jun 16 2020, 1:04 AM

I think this makes sense in term of division vs multiplication

This revision now requires changes to proceed.Jun 16 2020, 1:04 AM
ali.alzyod requested review of this revision.Jun 17 2020, 7:18 AM

@raster multiplication is normally faster than division, So this should enhance the speed

ali.alzyod retitled this revision from efl: reduce sqrt(2) calculations to efl: reduce sqrt(2) calculations (division vs multiplication).