Call for Interest: Clojure (or Lisp?) Code Camp with BLM focus

Thu Dec 3 15:10:47 UTC 2020

I've used ABCL very happily as a high-level way to script the JVM, and 
also as a good way to explore what's going on in a big Java program, 
using the REPL.

But for the AI planner I maintain and develop (GitHub.com/shop-planner), 
ABCL simply won't function: it's wildly too slow compared with SBCL, 
Allegro, and CCL. I can't get it to run the test suite (ECL can't do it, 
either).

Also, I suspect that the inability to do tail call optimization means 
that idiomatic CL code behaves very poorly on ABCL (which is the fault 
of the JVM, not ABCL itself).

I wouldn't recommend ABCL as other than a tool to work with artifacts 
that already live on the JVM.  As a "primary" CL it just does not 
perform well enough.

On 3 Dec 2020, at 8:55, Alessio Stalla wrote:

> Perhaps this will change with a future JVM with Value Types and with a
> future ABCL making use of them, but at the moment, that's the sad 
> story.
>
> On Thu, 3 Dec 2020 at 15:51, Pascal Costanza <pc at p-cos.net> wrote:
>
>> We tested an implementation in Java, and the memory footprint of the 
>> JVM
>> is huge. Where C++, Common Lisp, and Go could comfortably run in 
>> below 256
>> GB RAM, Java needed more like 350-400 GB RAM. That was not a good 
>> tradeoff.
>> I don’t expect an implementation in ABCL to solve this (which is 
>> not ABCL’s
>> problem, but a problem of the JVM).
>>
>> Pascal
>>
>>> On 3 Dec 2020, at 14:47, Manfred Bergmann <manfred.bergmann at me.com>
>> wrote:
>>>
>>>> This was primarily for the lack of good parallel, concurrent 
>>>> garbage
>> collectors in Common Lisp implementations.
>>>
>>> ABCL on the JVM works pretty good these days.
>>> It’s not as fast as SBCL, but much more robust from a runtime (and 
>>> GC)
>> perspective.
>>>
>>>
>>> Manfred
>>>
>>>
>>>> Am 03.12.2020 um 13:57 schrieb Pascal Costanza <pc at p-cos.net>:
>>>>
>>>> This was primarily for the lack of good parallel, concurrent 
>>>> garbage
>> collectors in Common Lisp implementations. The CL version of elPrep 
>> was
>> actually still a tad faster than any of the C++, Go, or Java 
>> versions, but
>> we had to work hard to avoid long GC pauses. elPrep allocates a lot 
>> of
>> memory, and the pause time hurts a lot. We solved this by, basically,
>> disabling the garbage collector, and reusing memory manually as much 
>> as
>> possible, which turned the program into almost a manually 
>> memory-managed
>> affair.
>>>>
>>>> Manual memory management became a huge burden because we wanted to 
>>>> add
>> more and more components to the software, and then it becomes almost
>> impossible to predict object lifetimes.
>>>>
>>>> We evaluated Go and Java for their concurrent, parallel GCs, and 
>>>> C++
>> for its reference counting. Interestingly, reference counting is 
>> often
>> described as more efficient than GC, but in our case that’s not 
>> true:
>> Because there is a huge object graph at some stage that needs to be
>> deallocated, reference counting incurs more or less the same pause 
>> that a
>> non-concurrent GC does. That’s why we don’t expect Rust to fare 
>> better here
>> either.
>>>>
>>>> Again, we’re still prototyping in Common Lisp, which is a huge 
>>>> win,
>> because this makes us much more productive.
>>>>
>>>> Pascal
>>>>
>>>>> On 3 Dec 2020, at 12:16, Svante Carl v. Erichsen <
>> svante.v.erichsen at web.de> wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> I vaguely remember having read that you do that.  I'm still 
>>>>> wondering
>>>>> why, though.  I guess that you wrote about it, but I can't find it
>> right
>>>>> now.
>>>>>
>>>>> So, if it's not because Common Lisp is not seen as “production 
>>>>> ready”,
>>>>> why rewrite instead of just adding the production parts (I guess
>>>>> hardening, monitoring, logging, documentation etc.)?
>>>>>
>>>>> Yours aye
>>>>>
>>>>> Svante
>>>>>
>>>>>
>>>>> Pascal Costanza writes:
>>>>>
>>>>>> In my opinion, prototyping in Common Lisp, and then translating 
>>>>>> to a
>>>>>> different programming language for creating the final product, is 
>>>>>> a
>>>>>> perfectly valid professional use of Common Lisp. It’s useful to 
>>>>>> know
>>>>>> which programming languages may be good targets for such an 
>>>>>> approach.
>>>>>>
>>>>>> This is, of course, not ideal, because this can easily be
>>>>>> misunderstood as a statement that Common Lisp is not fit for
>>>>>> purpose. However, I don’t see it that way, and you cannot 
>>>>>> control
>>>>>> people’s perceptions.
>>>>>>
>>>>>> In our particular case, our manager is on board with this 
>>>>>> approach,
>>>>>> and this allows us to pay for regular licenses for LispWorks. The
>>>>>> approach works really well for us.
>>>>>>
>>>>>> Pascal
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>>> On 3 Dec 2020, at 05:29, Dave Cooper <david.cooper at genworks.com>
>> wrote:
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>>> Where else do Common Lispers go to talk shop, whether CL or
>> something else?
>>>>>>>
>>>>>>>
>>>>>>> To me, Common Lispers "talking shop" by definition means talking
>> about CL or related topics, not an open-ended "something else." I 
>> would
>> turn that question around and ask "where else do Common Lispers go 
>> for
>> unapologetic mutual support for their chosen or imposed computing 
>> platform,
>> which is Common Lisp?"  If groups such as this mailing list become 
>> diluted
>> with hand wringing, naysaying, and negativity, then you tell me Tim, 
>> where
>> do actual Common Lispers go?
>>>>>>>
>>>>>>>
>>>>>>>> CL is very good but it is not perfect.  Debating the relative
>> merits of
>>>>>>>> various languages can lead to cross-pollination of ideas.  It
>> appears that
>>>>>>>> most innovation is happening elsewhere, and I hope this 
>>>>>>>> community
>> can
>>>>>>>> bring the best of CL into a worthy successor, whatever it may 
>>>>>>>> be
>> called.
>>>>>>>>
>>>>>>>
>>>>>>> If "most innovation is happening elsewhere" then those of us who
>> have the propensity to look into other languages can serve the 
>> community
>> here by reporting back the cool things they find and discussing how 
>> we may
>> or may not be able to co-opt such things into CL. If such is the
>> perspective and purpose of "debating the merits of various 
>> languages," then
>> indeed, such debate can result in productive cross-pollination, and 
>> this is
>> needed and wanted.
>>>>>>>
>>>>>>> If the intention and focus is instead to sing the praises of 
>>>>>>> other
>> environments in order to seek fellow converts or validation for 
>> converting,
>> and doing this while specifically targeting a group set up to support
>> "professional common lispers," then I consider such efforts to be 
>> unhelpful
>> in the context of this group and I would invite you to take such
>> discussions into the forums of those other environments or into some
>> general language discussion forums.
>>>>>>>
>>>>>>> Understand that not all of us have the "luxury" on the one hand, 
>>>>>>> nor
>> the desire on the other hand, to chase the dragon of the latest cool 
>> thing,
>> and we look to groups such as this one specifically to support our 
>> crusty
>> old entrenched mentality -- and to improve our environment as best we 
>> can,
>> understanding the inherent limitations that exist. This is the life 
>> we have
>> chosen.
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Pascal Costanza
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Pascal Costanza
>>
>>
>>
>>

Robert P. Goldman
Research Fellow
Smart Information Flow Technologies (d/b/a SIFT, LLC)

319 N. First Ave., Suite 400
Minneapolis, MN 55401

Voice:	(612) 326-3934
Email:    rpgoldman at SIFT.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201203/4f30dbab/attachment-0001.htm>