Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust: Dropping heavy things in another thread can make your code 10000x faster

abramov.io

Post reply on HN
Print view View original

41–50 of 285 posts

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#41

Post by Jasper_ »

chowells wrote: post #31

This is the standard problem with tracing data structures to free them. You frequently run into it with systems based on malloc/free or reference counting. The underlying problem is that freeing the structure takes time proportional to the number of pointers in the structure it has to chase. Generational/compacting GC has the opposite problem. Garbage collection takes time proportional to the live set, and the amount…

One of my favorite papers by Bacon et al expands on this intuition that garbage collection and reference counting are opposite tradeoffs in many respects, and gives a formal theory for it. My views on gc/rc haven't been the same since.

http://researcher.watson.ibm.com/researcher/files/us-bacon/B...

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#42

Post by saagarjha »

arcticbull wrote: post #40
chowells wrote: post #31

This is the standard problem with tracing data structures to free them. You frequently run into it with systems based on malloc/free or reference counting. The underlying problem is that freeing the structure takes time proportional to the number of pointers in the structure it has to chase. Generational/compacting GC has the opposite problem. Garbage collection takes time proportional to the live set, and the amount…

> This is the standard problem with tracing data structures to free them. You frequently run into it with systems based on malloc/free or reference counting. The underlying problem is that freeing the structure takes time proportional to the number of pointers in the structure it has to chase. That doesn't seem to make intuitive sense. A GC has the same problem. A garbage collector has to traverse the data structure…

Usually in a background thread ;)

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#43

Post by firethief »

Ididntdothis wrote: post #34
saagarjha wrote: post #27

Earlier quoted context omitted.

Rust basically gives the compiler understanding of unique_ptr and prevents you from using it after you’ve moved it.

Would you have to keep track of these threads in Rust? I have done a lot of desktop development where you have to be aware of what happens during shutdown. Seems a lot of server guys write their code under the assumption that it will never shut down.

The answer to this question is the same for any language without a heavy runtime. You can choose to join the worker thread, detach it, or kill it.

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#44

Post by [deleted] »

saagarjha wrote: post #27
Ididntdothis wrote: post #24

I used to do this sometimes with C++ when I realized that clearing out a vector with lots of objects was slow. Is Rust basically based on unique_ptr? One problem with this approach was that you still had to wait for these threads when the application would shut down.

Rust basically gives the compiler understanding of unique_ptr and prevents you from using it after you’ve moved it.

[deleted]

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#45

Post by firethief »

saagarjha wrote: post #15
cperciva wrote: post #9

If freeing the data structure in question takes this long, how much time are you wasting duplicating the data structure?

I’m actually very curious why it takes this long; is Rust memseting the buffer when dropping it? Edit: it seems like turning on optimizations seems to improve the situation quite a bit. Not sure why they were profiling the debug build.

> Edit: it seems like turning on optimizations seems to improve the situation quite a bit. Not sure why they were profiling the debug build.

This is the most important point in the thread, since it invalidates the results for most purposes.

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#46

Post by qcoh »

Ididntdothis wrote: post #24

I used to do this sometimes with C++ when I realized that clearing out a vector with lots of objects was slow. Is Rust basically based on unique_ptr? One problem with this approach was that you still had to wait for these threads when the application would shut down.

Out of curiosity, how did you do that in C++?

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#47

Post by tedunangst »

Reelin wrote: post #21
saagarjha wrote: post #2

Why would you ever write a get_size function that drops the object you call it on? Surely in an actual, non-contrived usecase spawning another thread and letting the drop occur there would just be plain worse?

I think the contrived use case is just for illustrative purposes? If I'm understanding correctly, the combination of cleanup code and deallocation can sometimes consume enough time that it's worth dispatching it on another thread. That's hardly specific to Rust though. As you note that will certainly add some overhead, although that could be minimized by not spawning a fresh thread each time. It could easily reduce l…

It would be helpful to see an example from a real application, too.

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#48

Post by arcticbull »

saagarjha wrote: post #42
arcticbull wrote: post #40

Earlier quoted context omitted.

> This is the standard problem with tracing data structures to free them. You frequently run into it with systems based on malloc/free or reference counting. The underlying problem is that freeing the structure takes time proportional to the number of pointers in the structure it has to chase. That doesn't seem to make intuitive sense. A GC has the same problem. A garbage collector has to traverse the data structure…

Usually in a background thread ;)

Indeed. The difference is this is happening deterministically, in place (with an optional deferral). A garbage collector has all sorts of different trade-offs.

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#49

Post by fpgaminer »

staticfloat wrote: post #29

It seems that this would be a great reason to not pass the entire heavy object through your function, and to instead pass it as a reference. When passing an object (rather than a reference to an object) there's a lot more work going on both in function setup, and in object dropping. I'm not a rust guru, so I don't know the precise wording, but it's simple enough to realize that if this function, as claimed, must drop…

Rust isn't copying anything; everything in the original code would be a move.

Re: Rust: Dropping heavy things in another thread can make your code 10000x faster

#50

Post by Reelin »

saagarjha wrote: post #15
cperciva wrote: post #9

If freeing the data structure in question takes this long, how much time are you wasting duplicating the data structure?

I’m actually very curious why it takes this long; is Rust memseting the buffer when dropping it? Edit: it seems like turning on optimizations seems to improve the situation quite a bit. Not sure why they were profiling the debug build.

> I’m actually very curious why it takes this long; is Rust memseting the buffer when dropping it?

Regardless of memset and optimizations, consider a particularly complicated object which lives on the heap and contains hundreds of other nested objects (which themselves contain nested objects, etc). Now imagine that a significant fraction of them make use of RAII. That cleanup code can't be elided.

That being said, it's a pretty bad example if they were actually profiling the debug build ...

Post reply on HN