As a side note, and I have not attempted that and that would require further investigation, be we could incorporate the concept of sealed domains as presented by Marco Heisig in the library fast-generic-functions. We already have the concept of sealing classes, but FGF allows to partially seal a generic function. That could do wonders for inlining of effective methods specialized on system classes.
-- Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland TurtleWare - Daniel Kochmański | www.turtleware.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ński <dan...@turtleware.eu> wrote: > 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 dispatch > 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 that, > 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 > intermediate representation and experiment with backends. There are also > other motivations 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 in > GCC (so nothing to optimize for us). > > Another problem is FASL loading - when ECL loads a fasl then it replays > necessary side-effects and that is time consuming (you may notice this for > example 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 > dumping 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. We > 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 > pending™) > > Best regards, > Daniel > > 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 unboxed in > that case > > -- > Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland > TurtleWare - Daniel Kochmański | www.turtleware.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 dimpase+...@gmail.com > 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. > > > > Is there an effort to find out bottlenecks, or is it known where these > > bottlenecks are? > > > > Best, > > Dima
