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

Re:Rust: Dropping heavy things in another thread can make yo... by Reelin on Saturday May 30, 2020 @01:42PM (#23363000)

> the ownership system lets you transfer freeing responsibility off-thread safely and cheaply in order to not have it block the critical path

This can also trivially be done in other languages. Atomically append your pointer to a queue of "large things that need to be freed" and move on as though you had actually called free.

Within a particularly time sensitive loop you can even opt to place pointers into a preallocated array locally. Then once per loop iteration swap that array with the thread handling the deallocations for you. It eats up a bit of CPU time but can significantly reduce latency.

[ Parent | on HN ]

Re:Rust: Dropping heavy things in another thread can make yo... by jacobparker on Saturday May 30, 2020 @02:49PM (#23363571)

OP said safely; what you're describing isn't safe in, say, C++ in the same sense that it is in Rust.

[ Parent | on HN ]

Re:Rust: Dropping heavy things in another thread can make yo... by Reelin on Saturday May 30, 2020 @04:16PM (#23364283)

Isn't that essentially a tautology? Manual memory management and threading in such languages lacks safety guarantees to begin with.

[ Parent | on HN ]

Re:Rust: Dropping heavy things in another thread can make yo... by im3w1l on Saturday May 30, 2020 @04:49PM (#23364586)

A lot of C++ code depends on deallocation order for correctness. Like a destructor may want to say bye-bye to a pointed-to-object, and if you reverse order of deallocation, that pointer may be dangling.

Consider this code

    {
        Window a;
        ClickHandler* b = new ClickHandler(&a);
        delete b;
    }

Let's say b tries to deregister itself when it's deleted. This code will work as written. But if you defer the deletion of b, then stack allocated Window a may already be gone.

[ Parent | on HN ]

Re:Rust: Dropping heavy things in another thread can make yo... by Reelin on Saturday May 30, 2020 @08:18PM (#23366052)

I never meant to imply that you could use such tricks without considering the lifetimes of references. Manual memory management already requires being mindful of those though so it's nothing unique to the described situation. Yes Rust offers an advantage here, but it's the same one it offers everywhere else so it doesn't seem relevant to me.

That being said, it seems like most cases where such an approach is worthwhile involve large nested data structures that involve lots of pointer chasing to traverse. All cases I've encountered so far were bulk stores that didn't involve actively interacting with external objects.

[ Parent | on HN ]

Re:Rust: Dropping heavy things in another thread can make yo... by im3w1l on Sunday May 31, 2020 @05:46AM (#23368393)

Replying to myself: I guess you could run the destructors in order, but keep the memory around a bit longer.

[ Parent | on HN ]