optimizer misses flonum opportunities in `(apply + ...)` and `foldl`

[mbutterick]

The optimizer will use unsafe-fl+ for direct uses of + with flonums. Very nice. Even better, it even works variadically (which unsafe-fl+ ordinarily does not).

But when you change to (apply + ...) or foldl, you lose the optimization:

#lang typed/racket
(require math)

(+ 1.0 2.0) ; optimized
(+ 1.0 2.0 3.0) ; optimized
(apply + '(1.0 2.0 3.0)) ; not optimized
(foldl + 0.0 '(1.0 2.0 3.0)) ; not optimized
(foldl fl+ 0.0 '(1.0 2.0 3.0)) ; not optimized

The lower three lines could be better expanded to either

(unsafe-fl+ (unsafe-fl+ 1.0 2.0) 3.0)

or

(foldl unsafe-fl+ 0.0 '(1.0 2.0 3.0))

Though I think the apply form is the worthiest one to optimize, because it’s the more common idiom, and would subsume the foldl versions.

[stamourv]

Since, in general, the optimizer can't know what apply, foldl, etc. will do with its function arguments, this is not really possible.

It would be possible to add some special cases for functions we know will use them safely. I would be surprised if that made a big performance difference, though, since values would need to be boxed immediately after the call to unsafe-fl+. Does it make a big difference in your program?

Also, special-casing apply would essentially invove re-implementing it, as unsafe-fl+ and friends are not variadic, and so could not be passed in directly.

[samth]

I don't see why this isn't possible. We don't optimize function application in general, but specific operations. We're already doing most of this work to optimize + to fl+, handling the non-variadic nature of the latter.

[mbutterick]

Sorry, I wasn’t suggesting optimizing all uses of apply and foldl, but rather those uses that correspond to existing optimization patterns (e.g., + used in front of flonums). IOW, if (proc arg ...) and (apply proc (list arg ...)) mean the same thing, then by the principle of least astonishment, the optimizer should expand them the same way.

[stamourv]

@samth: First, we don't optimize the operations directly, we optimize applications of them. To find uses of these functions to optimize, we'd need to start optimizing applications in general and look for them. Second, the problem is that without knowing what foldl and co do with their function argument, we can't tell whether the call site is safe to optimize.

@mbutterick: The difference between (proc arg ...) and (apply proc (list arg ...)) is that in the former case, the argument list is known statically, whereas in the latter it is dynamic. So in the former, the optimizer just needs to flatten, whereas in the latter it would need to emit a loop, so it's not just expansion. But optimizing these specific cases would definitely be doable. Adding this to my to-do list for after my defense.

[samth]

We already optimize apply some, we'd need to extend this code: https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/optimizer/apply.rkt to handle some more cases.

[mbutterick]

@stamourv

“Does it make a big difference in your program?”

I’ve typically found the difference between + and fl+ to be small, but the difference between safe and unsafe ops to be large. Getting access to unsafe ops, plus reducing my use of contracts, were my original reasons for investigating TR.