Re: MOP question for language lawyers: can you specialize on standard-class
"Tim Bradshaw (as tfb at cley dot com)" <[email protected]> Sun, 17 May 2026 20:31:27 +0100
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
On 17 May 2026, at 02:02, Pascal Costanza <[email protected]> wrote: > > Why? Because I think that it would be reasonable for a compiler to be able to assume that for, say (locally (declare (type x a)) ... no assignment to a ...) that a was in fact an x throughout. I mean, I realise that's very old-fashioned and boring of me to think that type inference should be possible. Really I should assume that at any point, any object in my program should be likely to become cheese. Also, pragmatically, the existence of change-class is one of (at least) two reasons why things like slot access is so horribly slow I am almost certain. And finally there are no programs which use change-class which would not be immeasurably better if they did not, as defined by any sensible metric of taste. > Julia already solved it. It uses a combination of type parameters, just-in-time compilation and inlining to optimize methods, and gets extremely good results. Hello, is anyone there? Did I say that Julia's object system was slow? I think I did not say that. Does Julia's object system have a MOP? Does it allow the class of an object to be changed? What happens when you redefine a composite type (hint: instances remain instances of the old type, in the old world). Gosh, not very like CLOS, is it? Here's a challenge for anyone interested. Currently, in two different CL's, slot access to objects defined with defclass (with no special metaclass) is about two orders of magnitude slower than struct field access. CLOS is about 40 years old, but obviously nobody very clever has worked on it in all that time[1]. CL implementations can currently get within a factor of well under 2 of C for floating point code. Write a conformant[2] CLOS for either SBCL or LW in which slot access performance for classes defined with defclass is within a factor of two of those defined with defstruct, using agreed benchmarks. The prize will be a drive up zig-zag hill in a vintage sports car (you arrange transport to & from Gillingham). For additional credit: that CLOS implementation should have a MOP which conforms to AMOP[2]. The prize for this is that, assuming you're licensed to drive in the UK, and if you can convince me you are safe in the car, I'll let you drive it up the same hill. Here are some current figures (the r values are the ratios) LW - Fixnum slot access....... slot-value (slot declared fixnum) 1.32E-8s r=73.8 slot-value (no type) 1.34E-8s r=74.4 slot-value pessimized (LW) 2.39E-8s r=133. slot-value with svuc method 5.52E-8s r=307. struct (slot declared fixnum) 1.97E-10s r= 1.1 struct (no type) 1.80E-10s r= 1.0 cons (car) 1.93E-10s r=1.07 SBCL - Fixnum slot access....... slot-value (slot declared fixnum) 1.21e-8s r=74.4 slot-value (no type) 1.24e-8s r=76.5 slot-value with svuc method 1.76e-8s r=108. standard-instance-access 1.01e-9s r=6.25 struct (slot declared fixnum) 1.62e-10s r= 1.0 struct (no type) 1.68e-10s r=1.03 cons (car) 1.63e-10s r= 1.0 I can explain some of the entries but I can't be bothered right now. --tim [1] This is obviously a lie. At least one of the very smart people who has worked on CLOS implementations is on this mailing list. [2] Up to package names: the implementation may provide a package which is like CL but has its symbols for the CLOS bits. _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html