Re: Timing Comparison?

You can look at the NEWS file for sbcl and see when optimizations were done
on bignums.  There have been some.

https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/NEWS

On Sun, Nov 2, 2025 at 5:46 PM David McClain (as dbm at
refined-audiometrics dot com) <[email protected]> wrote:

> I think I read that SBCL uses the GNUMP Bignum code. While, I have Martin
> stating several years ago that their LW does not.
>
> That is what I suspect is the difference being seen here. And there is a
> shift around 2^69000 above which there is a noticeable slowdown in the LW
> code. Just saying… not criticizing. I think both are doing just great for
> my needs.
>
> Probably the breakpoint has to do more with memory management inside the
> Bignum libraries, since they might not be quite tuned into the underlying
> Lisp memory management system. But what do I know? I’m just speculating.
>
>
>
> > On Nov 2, 2025, at 14:17, Yuri Davidovsky <[email protected]> wrote:
> >
> >
> >
> >> On 2 Nov 2025, at 20:04, David McClain <[email protected]>
> wrote:
> >>
> >> I’m willing to bet that the performance difference has very little to
> do with the quality of code generation from either SBCL or LWM compilers.
> >
> > So what does it have to do with?
> >
> >> The numbers involved in the Scheme timing test range from 2^6942 to
> 2^694242 in size. This is entirely in the domain of BIGNUM arithmetic, and
> I really doubt that either Lisp system encoded their BIGNUM arithmetic in
> themselves.
> >
> > Do you mean, the values had to be constantly retrieved from the heap? If
> so, then you would be testing the memory subsystem performance and I doubt
> it would change drastically depending on whether you run your script in
> sbcl or lw. This is the reason why statically typed languages do not
> perform substantially better than php in web server context: the memory is
> the bottleneck as webservers constantly concatenate large strings from all
> over the place, do a lot of hash table lookups in some scenarios,
> traversing DB retrieval results and json objects processing, so on.
> >
> > When you move a lot of data around the computational performance becomes
> secondary as you won’t be saturating the cores.
>
>
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html
>