<div dir="auto">I ran the test several times to give the JIT compiler a chance to do its thing, and the improvement was very slight.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">-- Scott</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 26, 2023, 8:11 AM Robert Goldman <<a href="mailto:rpgoldman@sift.info">rpgoldman@sift.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div><div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">On 26 Nov 2023, at 1:03, Scott L. Burson wrote:</p>
</div><blockquote style="margin:0 0 5px;padding-left:5px;border-left:2px solid #777777;color:#777777"><div id="m_60580219624356005089126B1F0-0BB8-4B30-9E7F-2C1AA5467D5E">

<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" rel="noreferrer">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 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></div></blockquote>
<div style="white-space:normal">
</div>

</div>
</div>


</blockquote></div>