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

Thu Dec 3 14:55:43 UTC 2020

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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201203/36bcd681/attachment.htm>