Hacker News Reader

Comment by opnitro | Hacker News Reader

"Optimal" in this context means it never repeats the work of beta reduction when it doesn't have to. Ie, evaluating `(\x -> x + x) (2 * 2)` only evaluates `2 * 2` once.

View on HN

Why is this special? Doesn't that mean GHC is beta optimal since afaik it stores thunks to computations.

GHC is not beta optimal, due to some complications around what happens when a closures are created. (This is `HOW.md` claims)

That's not optimal on real machines; it's often faster to recalculate x*y than to cache it.

In general this "optimal" strategy seems to assume infinite memory that's all accessible at the same speed.

The compiler could have heuristics and profiling data to replace optimal but "small" reductions with cheap recomputation with even less locking where it seems like a good idea; it's an additional level of improvement rather than a competing choice. As the Python documentation says, "practicality beats purity", particularly when the sacrificed purity is only the pride of using an universal solution.

In a similar vein, if typical strategies for unstable sorting of arrays in place use quicksort splitting for long spans and insertion sort for short spans it doesn' mean that either algorithm is "better".

"Beta Optimial" != Fastest Execution strategy for all kinds of code. Just defining the term, not arguing about it's engineering application.

The project certainly says it has "drastically improved efficiency" and "uncharted levels of performance".

I don't think "massively parallel" is all that good for performance either, because battery life is part of that.

Ok well _I_ was just defining the term. I didn't write the project. You will note they provide benchmarks with data showing the efficiency gain. What's left (as a reader) is evaluate the quality of those benchmarks.

Reply on news.ycombinator.com