4 ms·

The problem with that type of optimizations is that is too verbose to be useful. You have to type boring extra code.

lokedhs 5y ago
Modern compilers, and in particular SBCL is able to use type inference so that in many cases it is able to deduce these optimisations even without explicit type specifications. Or at least you can add the type specification in one place and then other functions will be able to take advantage of this. I should probably write a followup article that goes into more details on this.
- dunefox 5y ago
  Please do!
- spicybright 5y ago
  Also, I'd imagine you can get a lot of mileage with macros here, no?
- User23 5y ago
  I've had no trouble getting SBCL to infer return types when calling other functions with the appropriate DECLARE or DECLAIM (as displayed with DISASSEMBLE and DESCRIBE), but so far I've not been able to verify that the compiler will infer the argument types in the same case. For example, if F takes two (signed-byte 8) and returns a (signed-byte 8) and I (defun g (a b) (f a b)) DESCRIBE will say that G takes two arguments of type T and returns a (signed-byte 8). Is this something you can please shed some light on? Without argument type inference it's hard to imagine how efficient code is going to be reliably generated without explicit declarations.
remexre 5y ago
Also, the "hot loop hypothesis" still tends to hold in CL; you only end up needing to annotate the crap out of the small number of functions that end up being most of your runtime. (It can sometimes be worth it to declare types for other functions, but that's as much for error checking as performance.) Being able to set the compiler flags on a per-function level is also really helpful for this, since these hot functions can be compiled for run-time speed rather than safety, debuggability, or compile-time speed (once one's sure they're correct, of course!).
- guenthert 5y ago
  > It can sometimes be worth it to declare types for other functions, but that's as much for error checking as performance. And readability!
romero-jk 5y ago
That's a big problem in clojure too, were you have to write lots of javaish clojure to get decent performance.
mpfundstein 5y ago
i maintain two big projects. i only ever annotate code after i know i am really done with it. and also not every code. its a dynamic language after all. its quite nice though that I can do it when I want and omit when not
- lispm 5y ago
  The big difference between SBCL (and related implementations like CMUCL) compared to other Common Lisp implementations is that SBCL uses type declarations and type inference for compile time checks -> thus it can be less dynamic.
jlarocco 5y ago
I don't really agree with that. It's hardly "too verbose to be useful" when a handful of type declarations can result in a significant runtime speed up. In practice only a relatively small amount of code will need type declarations and optimizations enabled, and type declarations double as safety checks when using "(declaim (optimize (speed 0) (safety 3)))" instead of "(declaim (optimize (speed 3) (safety 0)))", so it's a win for more than just performance reasons. It's not an optimization panacea, but it's low hanging fruit to get started.
epolanski 5y ago
That’s your definition of “too verbose”?

Modern compilers, and in particular SBCL is able to use type inference so that in many cases it is able to deduce these optimisations even without explicit type specifications. Or at least you can add the type specification in one place and then other functions will be able to take advantage of this. I should probably write a followup article that goes into more details on this.

dunefox 5y ago
Please do!
spicybright 5y ago
Also, I'd imagine you can get a lot of mileage with macros here, no?
User23 5y ago
I've had no trouble getting SBCL to infer return types when calling other functions with the appropriate DECLARE or DECLAIM (as displayed with DISASSEMBLE and DESCRIBE), but so far I've not been able to verify that the compiler will infer the argument types in the same case. For example, if F takes two (signed-byte 8) and returns a (signed-byte 8) and I (defun g (a b) (f a b)) DESCRIBE will say that G takes two arguments of type T and returns a (signed-byte 8). Is this something you can please shed some light on? Without argument type inference it's hard to imagine how efficient code is going to be reliably generated without explicit declarations.

remexre 5y ago

Also, the "hot loop hypothesis" still tends to hold in CL; you only end up needing to annotate the crap out of the small number of functions that end up being most of your runtime. (It can sometimes be worth it to declare types for other functions, but that's as much for error checking as performance.) Being able to set the compiler flags on a per-function level is also really helpful for this, since these hot functions can be compiled for run-time speed rather than safety, debuggability, or compile-time speed (once one's sure they're correct, of course!).

guenthert 5y ago
> It can sometimes be worth it to declare types for other functions, but that's as much for error checking as performance. And readability!

romero-jk 5y ago

That's a big problem in clojure too, were you have to write lots of javaish clojure to get decent performance.

mpfundstein 5y ago

i maintain two big projects. i only ever annotate code after i know i am really done with it. and also not every code. its a dynamic language after all. its quite nice though that I can do it when I want and omit when not

lispm 5y ago
The big difference between SBCL (and related implementations like CMUCL) compared to other Common Lisp implementations is that SBCL uses type declarations and type inference for compile time checks -> thus it can be less dynamic.

jlarocco 5y ago

I don't really agree with that. It's hardly "too verbose to be useful" when a handful of type declarations can result in a significant runtime speed up. In practice only a relatively small amount of code will need type declarations and optimizations enabled, and type declarations double as safety checks when using "(declaim (optimize (speed 0) (safety 3)))" instead of "(declaim (optimize (speed 3) (safety 0)))", so it's a win for more than just performance reasons. It's not an optimization panacea, but it's low hanging fruit to get started.

epolanski 5y ago

That’s your definition of “too verbose”?