<div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 3 Dec 2020 at 15:51, Pascal Costanza <<a href="mailto:pc@p-cos.net">pc@p-cos.net</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">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).<br>
<br>
Pascal<br>
<br>
> On 3 Dec 2020, at 14:47, Manfred Bergmann <<a href="mailto:manfred.bergmann@me.com" target="_blank">manfred.bergmann@me.com</a>> wrote:<br>
> <br>
>> This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations.<br>
> <br>
> ABCL on the JVM works pretty good these days.<br>
> It’s not as fast as SBCL, but much more robust from a runtime (and GC) perspective.<br>
> <br>
> <br>
> Manfred<br>
> <br>
> <br>
>> Am 03.12.2020 um 13:57 schrieb Pascal Costanza <<a href="mailto:pc@p-cos.net" target="_blank">pc@p-cos.net</a>>:<br>
>> <br>
>> 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.<br>
>> <br>
>> 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.<br>
>> <br>
>> 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.<br>
>> <br>
>> Again, we’re still prototyping in Common Lisp, which is a huge win, because this makes us much more productive.<br>
>> <br>
>> Pascal<br>
>> <br>
>>> On 3 Dec 2020, at 12:16, Svante Carl v. Erichsen <<a href="mailto:svante.v.erichsen@web.de" target="_blank">svante.v.erichsen@web.de</a>> wrote:<br>
>>> <br>
>>> Hi!<br>
>>> <br>
>>> I vaguely remember having read that you do that.  I'm still wondering<br>
>>> why, though.  I guess that you wrote about it, but I can't find it right<br>
>>> now.<br>
>>> <br>
>>> So, if it's not because Common Lisp is not seen as “production ready”,<br>
>>> why rewrite instead of just adding the production parts (I guess<br>
>>> hardening, monitoring, logging, documentation etc.)?<br>
>>> <br>
>>> Yours aye<br>
>>> <br>
>>> Svante<br>
>>> <br>
>>> <br>
>>> Pascal Costanza writes:<br>
>>> <br>
>>>> In my opinion, prototyping in Common Lisp, and then translating to a<br>
>>>> different programming language for creating the final product, is a<br>
>>>> perfectly valid professional use of Common Lisp. It’s useful to know<br>
>>>> which programming languages may be good targets for such an approach.<br>
>>>> <br>
>>>> This is, of course, not ideal, because this can easily be<br>
>>>> misunderstood as a statement that Common Lisp is not fit for<br>
>>>> purpose. However, I don’t see it that way, and you cannot control<br>
>>>> people’s perceptions.<br>
>>>> <br>
>>>> In our particular case, our manager is on board with this approach,<br>
>>>> and this allows us to pay for regular licenses for LispWorks. The<br>
>>>> approach works really well for us.<br>
>>>> <br>
>>>> Pascal<br>
>>>> <br>
>>>> Sent from my iPad<br>
>>>> <br>
>>>>> On 3 Dec 2020, at 05:29, Dave Cooper <<a href="mailto:david.cooper@genworks.com" target="_blank">david.cooper@genworks.com</a>> wrote:<br>
>>>>> <br>
>>>>> <br>
>>>>> <br>
>>>>>> Where else do Common Lispers go to talk shop, whether CL or something else?<br>
>>>>> <br>
>>>>> <br>
>>>>> 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? <br>
>>>>> <br>
>>>>> <br>
>>>>>> CL is very good but it is not perfect.  Debating the relative merits of <br>
>>>>>> various languages can lead to cross-pollination of ideas.  It appears that <br>
>>>>>> most innovation is happening elsewhere, and I hope this community can <br>
>>>>>> bring the best of CL into a worthy successor, whatever it may be called.<br>
>>>>>> <br>
>>>>> <br>
>>>>> 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. <br>
>>>>> <br>
>>>>> 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. <br>
>>>>> <br>
>>>>> 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. <br>
>>>>> <br>
>>>>> <br>
>>> <br>
>>> <br>
>> <br>
>> --<br>
>> Pascal Costanza<br>
>> <br>
>> <br>
>> <br>
> <br>
> <br>
<br>
--<br>
Pascal Costanza<br>
<br>
<br>
<br>
</blockquote></div>