Re: speeding ECL up

As a side note, and I have not attempted that and that would require furthe=
r investigation, be we could incorporate the concept of sealed domains as p=
resented by Marco Heisig in the library fast-generic-functions. We already =
have the concept of sealing classes, but FGF allows to partially seal a gen=
eric function. That could do wonders for inlining of effective methods spec=
ialized on system classes.

--
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:37 PM, Daniel Kochma=C5=84ski <daniel@turtl=
eware.eu> wrote:


> Hello Dima,
>=20
> some bottlenecks are known and I'm working on these. The worst offenders:
>=20
> - the generic function dispatch is slow
>=20
> 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
>=20
> - there is no type inference (only the type propagation)
>=20
> 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
>=20
> Both things hang on refactoring the compiler (that task is pending, you m=
ay see cmpc-separation branch), so it will be easier to work with the inter=
mediate representation and experiment with backends. There are also other m=
otivations for this refactor.
>=20
> There is also the fact that ECL /compilation/ time is very slow. Currentl=
y there is not much we can do about this, because most of the time is spend=
 in GCC (so nothing to optimize for us).
>=20
> Another problem is FASL loading - when ECL loads a fasl then it replays n=
ecessary side-effects and that is time consuming (you may notice this for e=
xample when you REQUIRE ASDF). This is not much of the problem in itself, b=
ut said side-effects need to be replayed even when we build an executable, =
so the startup suffers. Other implementations hide that startup time by dum=
ping images, where all side effects are already present.
>=20
> Also, if you are not using the C compiler (i.e only the bytecode), then t=
he result is not optimized at all - the bytecodes compiler performs only th=
e minimal compilation.
>=20
> All that said, when both fast gf and type inference are implemented, I wi=
ll try to identify further bottlenecks if things still doesn't look good.
>=20
> None of these possible improvements will be part of the upcoming release.=
 We are currently in the testing phase (not thanks to me, I'm disappointing=
ly not very active on this front at the moment - sorry Marius!).
>=20
> 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 know=
n bugs)
>=20
> 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 p=
ending=E2=84=A2)
>=20
> Best regards,
> Daniel
>=20
> p.s we should also introduce more immediate types on 64bit platforms - we=
 are currently using only two available bits for tagging while we could use=
 three, but I'm not working on that at the moment - single-float could be u=
nboxed in that case
>=20
> --
> Daniel Kochma=C5=84ski ;; aka jackdaniel | Przemy=C5=9Bl, Poland
> TurtleWare - Daniel Kochma=C5=84ski | www.turtleware.eu
>=20
> "Be the change that you wish to see in the world." - Mahatma Gandhi
>=20
>=20
>=20
> ------- Original Message -------
> On Friday, July 14th, 2023 at 2:19 PM, Dima Pasechnik [email protected]=
om wrote:
>=20
>=20
>=20
> > 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