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.bergm...@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 <p...@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.erich...@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.coo...@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
