5 ms·

> They're not as robust as full boat CLOS classes Structures support single inheritance, CLOS classes support multiple inheritance. The main reason for structu

by lispm 3y ago

> They're not as robust as full boat CLOS classes Structures support single inheritance, CLOS classes support multiple inheritance. The main reason for structures is that they are faster to use by default - but they are less flexible. For example: CLOS classes support updates of existing objects when the class definition changes, structures don't support updates.

pfdietz 3y ago
My feeling on this is that Common Lisp implementations should support classes in a way that idiomatic usage is just about as fast as structures. This is nontrivial, but I think it could be done.
- dreamcompiler 3y ago
  There was a time (the early 1990s) when structures were dependably and significantly faster than classes, and you had to use structures for any application that was even remotely speed-sensitive. I haven't metered CLOS in a while, but since modern hardware is around 100x faster now and modern Common Lisp compilers are a lot better, I suspect structures are no longer faster than classes or if they are, classes are fast enough that their extra flexibility is more important except in a very small set of apps where raw speed is paramount. I would encourage CL programmers who stick to structures for speed reasons to try rewriting some of your code with classes and meter it. You might be pleasantly surprised.
  - pfdietz 3y ago
    The problem comes from dynamism. Accessors to class slots are generic functions, and in current implementations cannot be inlined in general, as new methods can be added to them, even if the class of the argument is known statically. Even direct access to slots suffers from the effects of dynamism, since classes can be redefined at any time and the slots moved around. So, what's needed is a general way to get efficient code for such things even in the face of dynamic redefinition. This is possible, using generated code snippets that are relinked into code when definitions change, but I don't know of any Common Lisp compiler that currently does this.
    - dreamcompiler 3y ago
      AFAIK most of the current CL compilers memoize dynamic dispatch as well as slot vector lookup. They clear these caches if a relevant class or method gets redefined. Of course this precludes the use of some MOP functions like slot-value-using-class; if you use those the system won't cache the slot lookup mechanism.
      - pfdietz 3y ago
        Yes, implementations will do what they can, but none of that can be as fast as a simple structure field access when the type of the structure is known at compile time. That compiles to a single instruction.
  - Jach 3y ago
    CLOS is more than fast enough for games (see e.g. Kandria, there are comments on HN about it, though it's easy enough to do one's own benchmark and see how easy it is to get hundreds of frames per second even with thousands of objects updated and drawn through methods every frame), and if you do have some numerical generic functions in a tight loop you can optimize them further with libraries like https://github.com/alex-gutev/static-dispatch https://github.com/alex-gutev/static-dispatch The book Object-Oriented Programming: The CLOS Perspective (1993) even includes as its final chapter/paper "Efficient Method Dispatch in PCL" which is essentially a memoization technique, so it's been a concern (or because of such techniques, not the biggest concern) for a long time. The dev experience of using defstruct is bad enough when I want to change something about it that I just default to defclass. I can see some people not liking the somewhat more verbose syntax (I don't mind myself) but of course that's a barrier trivially removed...
- aidenn0 3y ago
  Someone was looking into doing this on Robert Strandh's lisp implementation. The existence of first-class global environments on it allows for saving off the entire environment on a defmethod and recompiling all methods for static dispatch every time a new defmethod occurs. This was being talked about at least 5 years ago; not sure if any work has been done on it in the interim.
  - pfdietz 3y ago
    Strandh also has his Call Site Optimization idea, which allows dynamic redefinition of things without having to recompile everything (just replace jumps to small code snippets at the call sites.)

by lispm 3y ago

pfdietz 3y ago

My feeling on this is that Common Lisp implementations should support classes in a way that idiomatic usage is just about as fast as structures. This is nontrivial, but I think it could be done.

dreamcompiler 3y ago
There was a time (the early 1990s) when structures were dependably and significantly faster than classes, and you had to use structures for any application that was even remotely speed-sensitive. I haven't metered CLOS in a while, but since modern hardware is around 100x faster now and modern Common Lisp compilers are a lot better, I suspect structures are no longer faster than classes or if they are, classes are fast enough that their extra flexibility is more important except in a very small set of apps where raw speed is paramount. I would encourage CL programmers who stick to structures for speed reasons to try rewriting some of your code with classes and meter it. You might be pleasantly surprised.
- pfdietz 3y ago
  The problem comes from dynamism. Accessors to class slots are generic functions, and in current implementations cannot be inlined in general, as new methods can be added to them, even if the class of the argument is known statically. Even direct access to slots suffers from the effects of dynamism, since classes can be redefined at any time and the slots moved around. So, what's needed is a general way to get efficient code for such things even in the face of dynamic redefinition. This is possible, using generated code snippets that are relinked into code when definitions change, but I don't know of any Common Lisp compiler that currently does this.
  - dreamcompiler 3y ago
    AFAIK most of the current CL compilers memoize dynamic dispatch as well as slot vector lookup. They clear these caches if a relevant class or method gets redefined. Of course this precludes the use of some MOP functions like slot-value-using-class; if you use those the system won't cache the slot lookup mechanism.
    - pfdietz 3y ago
      Yes, implementations will do what they can, but none of that can be as fast as a simple structure field access when the type of the structure is known at compile time. That compiles to a single instruction.
- Jach 3y ago
  CLOS is more than fast enough for games (see e.g. Kandria, there are comments on HN about it, though it's easy enough to do one's own benchmark and see how easy it is to get hundreds of frames per second even with thousands of objects updated and drawn through methods every frame), and if you do have some numerical generic functions in a tight loop you can optimize them further with libraries like https://github.com/alex-gutev/static-dispatch https://github.com/alex-gutev/static-dispatch The book Object-Oriented Programming: The CLOS Perspective (1993) even includes as its final chapter/paper "Efficient Method Dispatch in PCL" which is essentially a memoization technique, so it's been a concern (or because of such techniques, not the biggest concern) for a long time. The dev experience of using defstruct is bad enough when I want to change something about it that I just default to defclass. I can see some people not liking the somewhat more verbose syntax (I don't mind myself) but of course that's a barrier trivially removed...
aidenn0 3y ago
Someone was looking into doing this on Robert Strandh's lisp implementation. The existence of first-class global environments on it allows for saving off the entire environment on a defmethod and recompiling all methods for static dispatch every time a new defmethod occurs. This was being talked about at least 5 years ago; not sure if any work has been done on it in the interim.
- pfdietz 3y ago
  Strandh also has his Call Site Optimization idea, which allows dynamic redefinition of things without having to recompile everything (just replace jumps to small code snippets at the call sites.)