Why Rust closures are somewhat hard

Post by bschwindHN » Wed, Jan 22, 2020, 11:21 AM UTC

optimuspaul wrote: post #7

capableweb wrote: post #6

Earlier quoted context omitted.

Not sure I agree with "relatively clean code" when one of the examples show "fn compose (f1: impl Fn(T)->T, f2: impl Fn(T)->T) -> impl Fn(T)->T {" which is just a mix-match of keywords and other things, with tons of syntax embedded in just one line. But as always, depends on where you come from. I mostly deal with lisp languages nowadays, so guessing it's just my view that the line quoted above seems complex enough t…

While that may be an extreme example I agree. nothing clean about that code. I've only just begun to dive into rust, but I feel like I'd need a concordance to navigate the meaning of that snippet alone. Bt then again, maybe it depends on where you come from.

Post by vlovich123 » Wed, Jan 22, 2020, 2:07 PM UTC

zelly wrote: post #77

Sean1708 wrote: post #69

Earlier quoted context omitted.

> It is effectively a slow ... raw pointer. In my experience (unless I've misunderstood what you're trying to say) this is the fastest way to write graphs because of how much more cache-friendly it is than having to chase a load of pointers.

True, but you can do the same thing more efficiently with pointers. Suppose the parent maintains an array of children Node* Then each child has a Node** member which points to itself in that array. That's one dereference to get up to the parent context. In the Rust example, to do the same would take an extra few steps and probably miss the cache. I think speculative execution would favor the pointer method.

Post by phibz » Wed, Jan 22, 2020, 7:43 PM UTC

kxyvr wrote: post #18

jimbob45 wrote: post #8

I don't understand the intuition of closures and they turn me off to languages immediately. They feel like a hack from someone who didn't want to store a copy of a parent-scope variable within a function. The idea that I can touch variables that have gone out of scope (and that have ostensibly been GC'd) makes me feel that it is impossible to reason about variable lifetimes when dealing with closures. Is there some p…

In many ways, closures can be more difficult when there is not garbage collection because we precisely do not want to refer to values that have been freed or collected. For example, in C++, we can write code like: #include #include auto foo(double a) -> std::function { return [&a](auto x) { return x + a; }; } int main() { auto f = foo(2.0); std::cout This code is bad because the function returned by `foo` depends on…

Post by zelly » Wed, Jan 22, 2020, 9:53 PM UTC

vlovich123 wrote: post #83

zelly wrote: post #77

Earlier quoted context omitted.

True, but you can do the same thing more efficiently with pointers. Suppose the parent maintains an array of children Node* Then each child has a Node** member which points to itself in that array. That's one dereference to get up to the parent context. In the Rust example, to do the same would take an extra few steps and probably miss the cache. I think speculative execution would favor the pointer method.

Do you have benchmarks? An array offset isn’t speculative and I suspect you’ll have a very hard time showing that vec[i] is slower than *ptr. One challenge is if vec[i] involves a bounds check which it might in native rust.

  #include 
  #include 
  #include 
  
  static constexpr size_t MAX_NODES = 1 & descendant) {
    if (n index_self = n;
     descendant->ptr_self = &ptr_children[n];
     n += 1;
    }
   }
  };
  
  int main(void) {
   TopLevel top_level{};
   for (int i = 0; i ();
    top_level.add(node);
   }
   // access by pointer
   {
    auto t_0 = std::chrono::high_resolution_clock::now();
    Node** it = &top_level.ptr_children[0];
    for (int i = 0; i ptr_self;
     it += 1;
    }
    auto t_1 = std::chrono::high_resolution_clock::now();
    std::cout
        (
        t_1 - t_0)
        .count()
        index_self;
    for (int i = 0; i (
        t_1 - t_0)
        .count()
        

  % clang++ -O3 bench.cc && ./a.out
  Via pointer: 90 ns
  Via index: 41 ns