[Openmcl-devel] The M1 port and the future of CCL

[Scott L. Burson]

Ouch — I see what people mean about ABCL.  I obviously haven't done any
serious work with it yet, but I thought I was going to.  I don't need
absolute maximum computational performance, and I do expect to be running
some very large heaps, possibly a few hundred GB, which I know the JVM can
handle.  So ABCL seemed like a reasonable choice.  But I just tried a small
benchmark that I happened to have handy, and ABCL came out three orders of
magnitude slower than SBCL.  Yikes!  I don't even know where that kind of
overhead would come from.  I did compile the code, and no, I'm not running
an x86_64 JVM under Rosetta :-)  Well, come to think of it, the code is
heavy on two things that might be poorly implemented in ABCL: generic
function calls and multiple values.  Still, three orders of magnitude — a
simple interpreter that worked directly off list structure should do better
than that, no?

Anyway, I guess the upshot is that I'm more interested in seeing CCL
continue to be supported than I thought.

-- Scott



On Fri, Nov 24, 2023 at 1:34 PM J Klein <jetmonk at gmail.com> wrote:

>
> I agree with Robert that ECL and ABCL are too sluggish to be practical
> replacements for CCL or SBCL.   I had to port a scheduling program from
> ABCL to SBCL for this reason.
>
> I think that CCL is the ideal Lisp for small platforms like the Raspberry
> Pi (and maybe phones and tablets, if the ecosystem owners permit it), given
> its mix of speed and light weight.   I formerly used it on the RPi until
> the failure of threading on multiple cores drove me to 64 bit Raspian and
> SBCL, which is a tad too heavyweight.    ECL was just too slow to run and
> compile, and broke too many packages.
>
> Given that arm64 is likely to be the dominant platform for small-device
> computing, it seems that porting CCL to it would be a huge benefit, whether
> or not the Macintosh IDE is supported.
>
> I'd certainly be willing to contribute a modest amount of money, enough to
> pay for a day or two of work, to achieve a stable arm64 port.  Some
> documentation of the internals would be great too, as I learned from my
> efforts to tackle the thread bug in arm32.
>
>
>
>
>
>
>
>
>
> >
> > I use CL for computationally challenging processes (see, e.g.,
> https://github.com/shop-planner/shop3).  ECL's compiler generates code
> that is simply too sluggish to be usable for such problems.  I would warn
> you away from that. TBH, I think pushing CL code through a C compiler is a
> losing proposition -- the development environment is also unpleasant and
> sluggish to work with.  For that matter, although I have used ABCL to
> script Java applications happily, its code is also way too sluggish for
> practical use as a "main" programming language (as opposed to a scripting
> shell).
> >
> > If CCL goes away (I hope it does not, but I agree it will be very
> challenging to keep it alive), then unless you are willing to pay for
> LispWorks or Allegro, SBCL is the only game in town.
> >
> > Of course this is all my personal opinion and YMMV and YUCMV (Your Use
> Case May Vary).
> >
> > Best,
> > R
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20231125/3689d16f/attachment.htm>