Re: The M1 port and the future of CCL

To be honest, I haven't worked with this enough to know if running a 
system for a long time would let the JIT compiler speed things up.  But 
that doesn't fit my use case, anyway: I am generally not writing 
long-duration server systems, so JIT optimization doesn't help me.

It's quite possible that ABCL still doesn't have tail-call optimization, 
either: I don't track Java well enough to know if they have made that 
possible yet.

On 26 Nov 2023, at 1:03, Scott L. Burson wrote:

> 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 <[email protected]> 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
>>
>>