Diff Detail
- Repository
- rEFL core/efl
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 16935 Build 11258: arc lint + arc unit
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: https://phab.enlightenment.org/w/maintainers_reviewers/
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.
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));vs.
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... :)
@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.
@raster
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 https://godbolt.org/ and you will see a lot of compiler does not have this kind of optimization
@raster multiplication is normally faster than division, So this should enhance the speed