2025-12-11 01:00 UTC
@jonocarroll@fosstodon.org sorry if this has been said before, but this is only fast in haskell because you're not actually evaluating the result ^^. running length x takes around a minute before running out of memory on my machine (with 108 it finishes after around 20s).
that's to be expected though for two reasons:
1) you're running this in ghci, which is an interpreter that is optimized for fast interactive use and performs no optimizations at all (although even compiled with -O2, this runs out of memory for me)
2) you're comparing singly linked lists of boxed integers (just about the least cache and memory efficient representation you could use here) to unboxed (probably?), vectorized arrays.
using unboxed arrays from vector instead takes ~12s (compared to ~10s for R on my machine)
i don't doubt that optimizations can give haskell an advantage but they won't make a difference here since you're only running two presumably already well-optimized functions
Replies (1)
-
@jonocarroll@fosstodon.org 2025-12-11 01:07
@prophet@functional.cafe ah, that makes sense - I was originally worried that I was shortcutting the result by assigning it to _ but now I see the same is true of an assigned but not-yet-evaluated value. Thank you! I'll update the post. I couldn't get a clear answer elsewhere but it sounds like you may know - are the rewrite rules like rev/rev/id and map/filter fusion generally implemented or are these purely up to the user to write/activate?