> Many variations [he's talking about Rust] that seemed like they ought to run the same speed or faster turned out slower, often much slower. By contrast, in C++ it was surprisingly difficult to discover a way to express the same operations differently and get a different run time.
This is an insidious pitfall that may earn Rust the "slow" label, akin to what happened to Common Lisp.
This doesn't match my experience at all with Rust, for what it's worth. Not having copy constructors makes up for any difference in that regard: in C++ it's way too easy to accidentally deep copy a vector and the entire object graph underneath it--all it takes is "auto a = b" as opposed to "auto& a = b"--with very bad performance consequences. Rust, on the other hand, doesn't let you deep copy unless you explicitly ask it to.
C(const C &) = delete;
C &operator=(const C &) = delete;
C(C &&) noexcept = default;
C &operator=(C &&) noexcept = default;
struct MakeCopy {
const C &src;
MakeCopy(const C &src) : src(src) { }
};
MakeCopy make_copy() const { return *this; }
C(MakeCopy src) : field1(src.src.field1), (blah blah) { }
This isn't really clean, because it's too easy to add a field to C and then forget to add it to the "manual copy constructor", but so far I found it good enough for me.
Edit: I should point out that deep copies can only be explicit in Rust -- there's no implicit deep copy AFAIK.
Qt even takes it further by providing automatic copy-on-write. Methods that read data operate on the shared copy. Methods that change data cause the object to deep copy and detach first. This allows writing programs using values rather than references, while retaining the performance of references.
Could it just be that the language is still young and all the edge cases in the optimizer haven't been implemented yet?
I suspect what the author was seeing was random performance differentials between iterators and loops, which often boils down to little missed optimizations in LLVM. If you find them, please file them in the Rust bug tracker--we've fixed many of them and will continue to do so in the future!
Note that when MIR lands, progress on which is well underway, we'll have the ability to do optimizations at the Rust IR level in addition to the LLVM level. This should make it easier to do these kinds of things.
It's impressive that the filter and map methods produced such good performance. The lazy evaluation scheme must be well setup, shout out to the Rust team!
Are the lazy iterators are combined and effectively stripped out at compile time?
In my experience profiling and optimization is usually sort of like a victory lap - low hanging fruit for substantial differences.
foldl (+) 0 [1..1000000]
Then the obvious way to do it is to simply keep a running total, but haskell doesn't do that, it constructs the expression:
(...((1+2)+3)+4)+5)+...)+1000000)
foldl' (+) 0 [1..1000000]
for example: https://news.ycombinator.com/item?id=11060566