Re: speeding ECL up

Hello Dima,

some bottlenecks are known and I'm working on these. The worst offenders:

- the generic function dispatch is slow

  I have implemented the computation part of the fast generic function disp=
atch as proposed by Robert Strandh, but it needs to be integrated with the =
C compiler

- there is no type inference (only the type propagation)

  ECL can go really fast when it knows about its types. I have plans for th=
at, but some extra work needs to be done first

Both things hang on refactoring the compiler (that task is pending, you may=
 see cmpc-separation branch), so it will be easier to work with the interme=
diate representation and experiment with backends. There are also other mot=
ivations for this refactor.

There is also the fact that ECL /compilation/ time is very slow. Currently =
there is not much we can do about this, because most of the time is spend i=
n GCC (so nothing to optimize for us).

Another problem is FASL loading - when ECL loads a fasl then it replays nec=
essary side-effects and that is time consuming (you may notice this for exa=
mple when you REQUIRE ASDF). This is not much of the problem in itself, but=
 said side-effects need to be replayed even when we build an executable, so=
 the startup suffers. Other implementations hide that startup time by dumpi=
ng images, where all side effects are already present.

Also, if you are not using the C compiler (i.e only the bytecode), then the=
 result is not optimized at all - the bytecodes compiler performs only the =
minimal compilation.

All that said, when both fast gf and type inference are implemented, I will=
 try to identify further bottlenecks if things still doesn't look good.

None of these possible improvements will be part of the upcoming release. W=
e are currently in the testing phase (not thanks to me, I'm disappointingly=
 not very active on this front at the moment - sorry Marius!).

Here are a few hints that will help you to produce better optimized code:
- avoid generic functions
- declare types wherever feasible
- lower safety to 1, raise speed to 3 (don't use safety 0, there are known =
bugs)

There are also more mundane ways to improve the performance:
- inline partial dispatch tables for arithmetic operators
- work harder on IR to optimize it (using SSA and adding more passes is pen=
ding=E2=84=A2)

Best regards,
Daniel

p.s we should also introduce more immediate types on 64bit platforms - we a=
re currently using only two available bits for tagging while we could use t=
hree, but I'm not working on that at the moment - single-float could be unb=
oxed in that case

--
Daniel Kochma=C5=84ski ;; aka jackdaniel | Przemy=C5=9Bl, Poland
TurtleWare - Daniel Kochma=C5=84ski=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | www.tur=
tleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi



------- Original Message -------
On Friday, July 14th, 2023 at 2:19 PM, Dima Pasechnik <[email protected]=
m> wrote:


> It's well-known that ECL-compiled CL projects are considerably slower
> than ones where SBCL is used. Examples are e.g. Maxima, FriCAS - there
> speed might be few times (sic!) slower.
>=20
> Is there an effort to find out bottlenecks, or is it known where these
> bottlenecks are?
>=20
> Best,
> Dima