Iterators and Streams in Rust and Haskell
fpcomplete.com
fpcomplete.com
In essence, this is why I love Haskell, and choose it over Rust: it allows me to write my application logic directly, without having to think about it in terms of mutation, and have the generated code be pretty fast. If GHC becomes well-optimized enough it can render Rust obsolete, since "no runtime overhead" becomes pretty meaningless if it's actually slower than Haskell (e.g. using LinearTypes, which removes need for GC). Rust can't render Haskell obsolete, however, since Haskell's goal is basically allowing you to write logic directly, using types as propositions and values as proofs. So Haskell's goal is a qualitative one (execute logic) while Rust's is a quantitative one (performance/no runtime overhead), which results in Haskell being able to take the place of Rust if GHC gains sufficiently in performance.
I can grasp Haskell without major issues, follow C++14 and C++17 meta-programming tricks, yet I still don't understand quite well how to deal with the borrow checker on Rust.
Still haven't given up on it, but it shows the learning curve is a bit high, or then it is me that cannot wrap my head around it.
In the world of Haskell, the -> arrow embeds a GC (with runtime overhead) into the genrated code. A similar interface to Rust's borrow checker in Haskell (no runtime overhead) would be the ⊸ arrow from LinearTypes (in a future where GHC's GC is able to take advantage of this).
It looks, to me, like the arrow (⊸) notation is a lot simpler inteface to a no-runtime-overhead garbage collector -- or the absense of a traditional GC, in other words -- than Rust's borrow checker. But I'm looking forward to seeing how it plays out (it will probably take years before it becomes reality).
Not really : the borrow checker is just a compile-time analysis tool which checks that you respect some conventions with pointers :
- each value has only one owner
- each pointer to a value must leave less time than the target value
- you must only have one mutable pointer to a value
- you can have as many immutable pointer to a value as you want as long as there is no mutable pointer to the same value (think of a statically-checked version of a RW-lock)
The borrow-checker isn't responsible for freeing memory at all. Freeing memory is done by RAII like in C++, but the conventions enforced by the borrow checker ensure that the deallocation of memory is safe.
Again, maybe it is just me and need to spend more time learning it.
I had the exact same experience : after my first reading of the Rust book, I though I understood what's going on but once I tried to actually write something I was totally lost. I stopped using Rust for several months and when I came back, I read the book again and this time I had no troubles writing stuff and the concepts of ownership and lifetime became really clear.
I think the concepts behind the borrow-checker are really straightforward[] once you've internalized them, yet they are really unintuitive to the beginner. It's quite paradoxical.
[] except when the borrowck is not yet smart enough : http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...
I'm not that familiar with Rust
but, as far as I can see,
it makes sense to say that Rust's borrow checker is an
interface to a O(1) garbage collector [...]
[1] https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...
Rust will never be more than an occasional coding exercise for me personally, because doesn't fit the type of work I do (Java/.NET/UWP/Web/Android) where project tooling is dictated by customer IT.
However coding exercises in whatever language X helps to open our mind to new ways of solving problems, that we can eventually use in our daily tools.
When I give these statements my goal isn't to bash the language, rather give another point of view that might help understanding which areas the design team should focus, or not.
After all it is their final call and they need to pay attention to those that are actually using it in production and their real problems, not random dudes like me.
I like rust because it doesn't have much in the way of runtime requirements (almost zero, like C).
There isn't yet, but there will be when, first, the LinearTypes extension arrives (scheduled for GHC 8.4) and, secondly, GHC's garbage collector is modified to take of advantage of the fact that linear types are always consumed exactly once. This will take 1-2 years or so.
After this it should be possible to write no-runtime-overhead Haskell functions by using the "lollipop" arrow after an argument, and then consuming that argument exactly once in your function. So you will have to split your functions into small enough functions, that consume their arguments exactly once, and then compose them into something that will not need a garbage collector at runtime. In theory you could write an entire application this way, although in practice you probably wouldn't bother avoiding the GC for the outermost constructions of your program, since this would offer little in performance gains and be a lot more difficult (remember, a no-GC function must consume its arguments exactly once).
But time will tell how this will compare to something like Rust's borrow checker.
It would allow us to safely allocate things from malloc memory or a “linear heap” separate from the main GC heap, and that should reduce pause times by reducing GC pressure, but I don’t think we’ll ever be able to avoid the GC entirely.
However, we can still expect some nice performance advantages from the fact that linear types can enforce guarantees about inlining & fusion (which are currently somewhat unpredictable) as well as resource lifetimes.
Ah yes, the mythical Sufficiently Smart Compiler (TM), scheduled to arrive any day now. Will it also be able to reliably transform non-trivial functions that are accidentally O(n) in memory consumption due Haskell's laziness, to O(1) versions?
The keyword here is reliably. There are many clever but brittle compiler optimizations that aren't used much in the field, because when performance is crucial, you can't rely on the compiler to detect this transformation opportunity in some cases and not in some other cases, so you code it explicitly.
So while your O(n) code might sometimes unreliably be turned into O(1), if performance is your game you can use these kind of libraries to endure O(1).
What you're describing is called strictness analysis. [0] I believe that attempting to solve it in general runs up against the halting problem. That being said, GHC does perform some strictness analysis when optimization flags are turned on. [1] The language itself also includes strictness annotations on the fields of data constructors. [2] Experienced Haskell programmers know how to use these to avoid allocating unnecessary thunks.
[0] https://en.wikipedia.org/wiki/Strictness_analysis
[1] https://wiki.haskell.org/Performance/Strictness#Strictness_a...
[2] https://wiki.haskell.org/Performance/Data_types#Strict_field...
Downward-counting or not, it is simply impossible for GCC to generate code that executes all 1,000,000 iterations of the loop in 87ns. That would be 87 femtoseconds per iteration, on average.
More likely, GCC figured out how to collapse the entire loop into a closed-form expression that is a function of the loop length.
calls_cheating():
movl $60, %eax
retHowever, from a brief glance, it does not appear to have created a closed form solution. Instead, it contains a single loop:
.L4:
addl $1, %edx
paddd %xmm1, %xmm0
paddd %xmm2, %xmm1
cmpl %edx, %eax
ja .L4
After this loop, it does some "housekeeping" (read, something I don't understand) before proceeding to an unwound version of the last iterations of the loop:
leal 4(%rdx), %ecx
addl %edx, %eax
cmpl %ecx, %edi
jl .L2
addl %ecx, %eax
leal 8(%rdx), %ecx
cmpl %ecx, %edi
...
jl .L2
addl %ecx, %eax
leal 28(%rdx), %ecx
cmpl %ecx, %edi
jl .L2
addl %ecx, %eax
addl $32, %edx
leal (%rax,%rdx), %ecx
cmpl %edx, %edi
cmovge %ecx, %eax
ret
.L2:
rep ret
[0]https://pastebin.com/raw/Y55gQG7p
[1] http://x86.renejeschke.de/html/file_module_x86_id_226.html
Still, unless I'm missing something, the code should be executing 8 adds per clock[2]; at 4ghz, that still above 1us for 500k adds.
GCC doesn't seem to be able to fold the loop given a constant expression, unless the function is explicitly declared constexpr; in which case it will complain about the accumulator overflowing, but gcc doesn't seem to be taking advantage of it.
Clang does not vectorize the loop but will replace it with a constant given a constant parameter.
Bottom line, I'm not sure what's going on with the article's measurements.
[2] potentially 12 for skylake or even 24 with avx.
GHC, in concept, does know that there are no side effects, but that would apply to all of the functions being tested. Further, since it is using a benchmarking library, I assume the authors of said library were aware of the issue, and wrote it in such a way as to force evalutation of the function.
https://gist.github.com/snoyberg/9b1c77b595c4adf90880213fc49...
What does it matter if the "cheating" versions are faster, since they're doing something completely different? (OK, in principle it could be the same with an unrealistically magical optimizer.)
Seems to me the key point is that a bunch of high-level constructs in both Rust and Haskell are very nearly as fast as a tight loop in C. That's great!
The versions that are much slower don't seem very surprising, as they involve boxing the ints. (Edit to add: OK, reading more closely, I guess 'Haskell iterator 5' is interesting to dig into.)
Including an "optimised away" version lets us know when this has happened: the "non-cheating" benchmarks take much longer than the "cheating" ones, so we can assume they've not been optimised away.
I assume the author only went into detail about them because they're independently interesting, regardless of the main topic of the post.
Functions already take their arguments at runtime. Except when they don't, due to optimisation.
For a benchmark to be automated, reproducible, etc. those constants have to be baked in somewhere, even if it's in a Haskell program using FFI (as in the article), or a shell script, etc. Whilst optimisers don't (yet) cross the language/process boundary, it still makes sense to include such sanity checks, rather than assuming we know what the optimiser will/won't do.
After all, the whole point of a benchmark is to gather evidence to question/ground the assumptions of our mental model. The less we assume, the better. The more evidence we gather, the better.