Re: [Maxima-discuss] Trying to accommodate GCL is keeping us from making progress

[Gunter K. <gu...@pe...>]

Gcl is faster than sbcl when running the test bench because sbcl compiles loads of stuff which needs time. I don't remember if sbcl additionally still lacks fast bigint multiplications while gcl supports them.

Memory-wise both sbcl and gcl tend to mysteriously run out of memory in places in which both clisp and ecl only use small amounts of memory. I originally switched from gcl to sbcl since for my tasks sbcl was up to 10 times faster and ran out of memory way less often if many results of if() commands were cached.
What I like about gcl is that it effectively is a lisp-to-c-converter and way faster than ecl, the other lisp-to-c I know.

Would sbcl or ecl speed up if we did the proclaim stuff with them, too?

Am 18. Oktober 2022 19:22:15 MESZ schrieb Robert Dodier <rob...@gm...>:
>On Tue, Oct 18, 2022 at 9:08 AM Leo Butler <Leo...@um...> wrote:
>
>> Developers who don't want to spend time working around gcl's
>> deficiencies shouldn't. I believe that several have already stated that
>> they do not test their work on gcl builds.
>
>> OTOH, I would like to have a minimally functional maxima+gcl. If that
>> means we add a cautionary bannerline about unsupported features, let's
>> do it.
>
>No, we should not do that. Supported has to mean that you get a
>working system. If various features don't work, then we'll get bug
>reports or other complaints from users about it. At that point telling
>people they have to back up and try it again with a different
>implementation, or just live with the defects, are both unsatisfying
>resolutions.
>
>In addition, if Maxima can be built with GCL (producing a
>sort-of-working system), then there is a pretty good chance someone
>packaging Maxima for distribution is going to do that. The way to
>prevent that is to just stop supporting it altogether.
>
>There's all kinds of #+gcl #-gcl all over the code, and frankly it's
>just a lot of dross. We can't get rid of it unless we agree that we're
>just not supporting GCL altogether.
>
>> The problem, as I have experienced repeatedly, is that gcl
>> will finish big computations while others barf (sbcl), take toooo
>> long (clisp) or some combination thereof.
>
>Hmm. My also-anecdotal experience is that GCL runs out of memory in
>cases where other Lisps don't.
>
>I would ask for examples, but to be honest it's secondary to the other
>issues about features lacking in GCL.
>
>FWIW
>
>Robert
>
>
>_______________________________________________
>Maxima-discuss mailing list
>Max...@li...
>https://lists.sourceforge.net/lists/listinfo/maxima-discuss