Re: The M1 port and the future of CCL

I ran the test several times to give the JIT compiler a chance to do its
thing, and the improvement was very slight.

No, the JVM still doesn't have general TCO, though I found a blog post
showing how to get self-tail-calls to work by transforming the bytecode.  I
don't think ABCL is doing this, though.

-- Scott




On Sun, Nov 26, 2023, 8:11 AM Robert Goldman <[email protected]> wrote:

> 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
>>
>>