<div dir="ltr"><div>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?</div><div><br></div><div>Anyway, I guess the upshot is that I'm more interested in seeing CCL continue to be supported than I thought.</div><div><br></div><div>-- Scott<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 24, 2023 at 1:34 PM J Klein <<a href="mailto:jetmonk@gmail.com" target="_blank">jetmonk@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
> <br>
> I use CL for computationally challenging processes (see, e.g., <a href="https://github.com/shop-planner/shop3" rel="noreferrer" target="_blank">https://github.com/shop-planner/shop3</a>).  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).<br>
> <br>
> 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.<br>
> <br>
> Of course this is all my personal opinion and YMMV and YUCMV (Your Use Case May Vary).<br>
> <br>
> Best,<br>
> R<br>
<br>
</blockquote></div>