3 ms·
I feel like, ideally, one should never have to face the conundrum of choosing an integer width for general-purpose use. I really like that the "normal" integer
by reikonomusha 5y ago
I feel like, ideally, one should never have to face the conundrum of choosing an integer width for general-purpose use.
I really like that the "normal" integers in Common Lisp are arbitrary length, but they're represented automatically as register-sized quantities when small enough (which, for typical code, is most of the time). That way, at least in terms of space efficiency, and for the most part in terms of time efficiency, you can have your cake and eat it too.
If I really need performance, I can always declare that a variable will never contain a non-machine-sized integer:
(defun f (x)
(declare (type (unsigned-byte 64) x))
...)
This is me promising to Lisp that x will always be bound to an unsigned 64-bit integer. If I dial the optimization settings with high speed and low safety (which I can scope to just that file, or even just that function):
(declaim (optimize (speed 3) (safety 0)))
then Lisp will eliminate bounds checks, bignum-promotions, etc. and produce the native assembly you expect.
My point is that I really appreciate the "safe and general by default" philosophy, while still being able to opt-in to practical efficiency considerations when I absolutely need it.
(If I'm pedantic: The above optimization behavior, while encouraged in various ways by the Common Lisp standard, is technically not de jure required. But any general purpose Lisp compiler from the past 30 years will do these things, like SBCL.)
- cpeterso 5y agoHere’s Rob Pike’s proposal to change Go’s int to be arbitrary precision in Go 2.0. But after five years of debate about “performance”, the proposal has stalled. https://github.com/golang/go/issues/19623 https://github.com/golang/go/issues/19623