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

171–180 of 285 posts

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

#171

Post by rcxdude »

kd5bjo wrote: post #157
estebank wrote: post #101

Earlier quoted context omitted.

In Rust you could just call `mem::forget` on whatever heavy thing that you're no longer using is before it would get dropped, but then the programmer is effectively responsible for that memory leak not becoming a problematic leak during refactors. Edit: this will also break any code that relies on Drop being called for clean up, but that is already a "suspect"/incorrect pattern because there are no assurances that it…

> There are no assurances that it will ever run. Yes and no. Whenever control leaves a code block, Rust automatically calls the drop() method of all values still owned by that block. There is no guarantee that control will exit every block (cf. Turing), but a moderately exceptional circumstance needs to occur for this not to happen, like an infinite loop.

There's also no guarantee the object won't be moved elsewhere, including into a context which never gets freed (for example, you can construct mem::forget using entirely safe code by forming a cycle of reference-counted boxes). That said, Rust has support for such a concept through the Pin trait (which essentially guarantees an object will not get moved until it is 'Unpinned').

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

#172

Post by pdimitar »

rcxdude wrote: post #170
pdimitar wrote: post #166

Earlier quoted context omitted.

I am suggesting they apply good practices. I'd never imagine that compilers were actually doing what was stated -- sounds awful. I understand it's tradeoffs and we all have real-world limitations to contend with -- but again, of all the corners that could be cut that's exactly the one I didn't imagine they would. Nasty.

Deallocation at the end of a program's execution can substantially add to its runtime, and it's entirely waste. It's a much more common strategy than you might think.

You are right, I indeed didn't know it was that common.

But still, in a world where languages and runtimes are also judged by their ability to run in lambda/serverless setups, I'd think this practice will start being obsolete, wouldn't you think?

(What I mean is that I imagine that any serverless function that runs in severely constrained and measured environments like the AWS Lambda would gain a significant edge over the competition if it did an eager cleanup. Should allow more of them to work in parallel?)

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

#173

Post by wizzwizz4 »

dirtydroog wrote: post #4

Oh my good god. I'm hoping this is down to developer naivety rather than being a feature of rust.

It's not a feature of Rust; it's a "feature" of the way we design operating systems and processors. This is the same in C.

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

#174

Post by winstonewert »

Reelin wrote: post #158
winstonewert wrote: post #131

Earlier quoted context omitted.

It avoids it if your type has no-op drop implementation. So if you use typed-arena for objects which don't own resources, they all get dropped in one massive deallocation and don't have to be traversed. EDIT: and then I noticed that you mentioned RAII... Right, if the object own some sort of resources that doesn't apply.

No worries. And to clarify, in context the point is that traversal fundamentally can't be avoided in the case of RAII. This defeats (what I see as) the primary use case of an arena allocator - deallocating an arbitrarily large chunk of contiguous memory in O(1) time regardless of object count. Of course this is all somewhat tangential to the original topic of generational GCs, where the RAII idiom also has significan…

I'm not sure its fair to say it defeats that use case. It only defeats that use case if you need RAII. Furthermore, in my experience, an arena is most useful when you allocate lots of small objects which is the least likely to case to need RAII.

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

#176

Post by jkoudys »

It'd be interesting to implement this on a type that would defer all of these drop threads (or one big drop threads built off a bunch of futures) until the end of some major action, like sending the http response on an actix-web thread. Could be a great way to get the fastest possible response time, since then the client has their response before any delay on cleanup.

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

#177

Post by all-fakes »

rubber_duck wrote: post #143
ycombobreaker wrote: post #139

Earlier quoted context omitted.

In a world where processes can fork-and-exec, nothing about "as a service" changes that. The compiler would just be reinvoked as needed. Converting it into a persistent process breaks a lot more than just allocation optimizations.

But you want to share state and only update state incrementally on edit to get any reasonable level of performance for stuff like language server code analysis.

I'm not sure what the performance overhead would be, but that state can easily be stored on disk.

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

#178

Post by thebean11 »

pdimitar wrote: post #166
qzw wrote: post #132

Earlier quoted context omitted.

Well, then that’s not the original use case anymore, and it’ll have to be re-engineered. In the meantime it may have been used for years and the perf difference may have saved many developer-years collectively across its user base. Surely you’re not suggesting that the compiler developers should be prematurely optimizing for future use cases that they may not even have envisioned.

I am suggesting they apply good practices. I'd never imagine that compilers were actually doing what was stated -- sounds awful. I understand it's tradeoffs and we all have real-world limitations to contend with -- but again, of all the corners that could be cut that's exactly the one I didn't imagine they would. Nasty.

Can you articulate why it's a bad practice? If it works better than alternatives and it's documented, not really sure what the issue is.

I don't think it's even that uncommon. I believe some HFT firms run Java with a huge amount of RAM and GC disabled, and get around it by just rebooting the software occasionally.

To me writing software like that is fair game, I don't see the point in being dogmatic about "how things should be done".

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

#179

Post by jomohke »

papaf wrote: post #79
fpgaminer wrote: post #61

Some important things I think people should note before blindly commenting: * The example code is obviously contrived. The real gist is that massive deallocations in the UI thread cause lag, which the example code proves. That very thing can easily happen in the real world. * I didn't see any difference on my machine between a debug build and a release build. * The example is preforming 1 _million_ deallocations. Tha…

This deallocation trick is neat but in C and C++ you could use a memory pool to do this. In theory, you could also use a memory pool in Rust but I think the standard library uses malloc without some way of overriding this behaviour.

You can easily use a custom global allocator in Rust:

    #[global_allocator]
    static GLOBAL: MyAllocator = MyAllocator;

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

#180

Post by projektfu »

saurik wrote: post #117
projektfu wrote: post #109

Earlier quoted context omitted.

Yeah, I like Apple’s (Next’s) approach of pool allocation for each run through the event loop. Defer dealloc, drop pool at the end.

Apple's pools are for helping manage reference counts of returned objects (via autorelease) but aren't doing pool allocation (as any of those objects could escape, so you can't do the fast thing of just deallocating the pool). The normal memory allocator is used while in the scope of an autorelease pool.

True, I was thinking the same after I posted. Maybe I’m thinking more of Apache’s approach and how it gets some of the benefits of a fork-per-request server without the overhead.
Post reply on HN