optimize sqrt$Complex(DoubleFloat)

[Qian Yun]

I found this from github issue #55.

In ComplexCategory, there is

if R is DoubleFloat then
stoc ==> s_to_c$Lisp
ctos ==> c_to_s$Lisp

exp x == ctos EXP(stoc x)$Lisp
log x == ctos LOG(stoc x)$Lisp
...... etc

I think "sqrt" should also be optimized by using Lisp call here.

- Qian

[Qian Yun]

[Waldek Hebisch]

Maybe. AFAICS main point was that we need some implementation
and this was the easiest one. OTOH in some other cases we
use our own implementation to avoid bugs in some Lisp.

--
Waldek Hebisch

[Qian Yun]

Preliminary benchmark shows 70% speedup for SBCL. (0.7s vs 1.2s).

The improvement was smaller that I originally thought.

I also thought it is a burden for us to maintain the (double)float
computation algorithm.

- Qian

[Waldek Hebisch]

On Sat, Apr 17, 2021 at 10:18:31PM +0800, Qian Yun wrote:
> Preliminary benchmark shows 70% speedup for SBCL. (0.7s vs 1.2s).
>
> The improvement was smaller that I originally thought.
>
> I also thought it is a burden for us to maintain the (double)float
> computation algorithm.

double sqrt may be a single hardware instruction or use some
short optimized sequence of instructions, so it make sense
to send it to Lisp to get good code. Complex(DoubleFloat)
sqrt in all machines that I know is done via software.
Spad can easily express this. ATM there is issue with
Complex(DoubleFloat), namely operations on Complex(DoubleFloat)
are not inlined and thery are allocating memory. Better
compiler would handle separately real and imaginary part
and avoid memory allocation for intermediate values.
So using Lisp may give some advantage: presumably Lisp
compiler knows about Lisp complex type and can optimize
it. OTOH Lisp is dynamically typed and in confusing
situation at Lisp level there may be need for dynamic
dispatch. So, while currently Lisp have some speed
advatage for complex, this may change with improvement
to Spad compiler. Let me remark that this optimization
is implemented in Aldor, so I speed of Complex is
critical for your code compiling it with Aldor may
give large gain.

Having said the above, let me repeat principles that
I am trying to follow:
- I look at actual speed bottlnecks, that is operations
that users are likely to use and info from profiling
- I do not bother much about infrequent operations.
I do not like to write code that simply wastes CPU
cycles, so if there is obvious linear versions I use
it intead of quadratic one. But there is always
compromise between speed and complexity of code,
and increased complexity should be compensated by
sufficiently important speed gain.
- There is also balance between short term and long
term. Some optimizaton will become useless with
better compiler, some code which is slow now will
become much faster. So, if we can live with slower
code for some time, I prefer to wait for improvements
to compiler.
- Related to above, fixing bugs in our code is normally
easier than finding problems in libraries we use, in
particular keeping all code as Spad helps. So simple
implementation in Spad is normally better than external
call.

--
Waldek Hebisch