Hacker News Reader

Comment by samsaga2 | Hacker News Reader

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

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.

Please do!

Also, I'd imagine you can get a lot of mileage with macros here, no?

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.

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!).

> It can sometimes be worth it to declare types for other functions, but that's as much for error checking as performance.

And readability!

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

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.

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.

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

That’s your definition of “too verbose”?

Reply on news.ycombinator.com