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

281–285 of 285 posts

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

#281

Post by ahupp »

pjmlp wrote: post #278
ahupp wrote: post #160

Earlier quoted context omitted.

That's not exactly true. In C++ terms, the example code is moving a value: std::map foo; someFunction(std::move(foo)); And not moving a pointer like: std::unique_ptr > foo = ...; someFunction(std::move(foo)); So it copies sizeof(std::map ), not a pointer.

Not necessary, std::map::map(&&) is free to move just the internal pointers and bookkeeping data, only dumb implementations would move the memory blocks where the map data is actually stored, as per ISO C++ requirements.

The comment originally said it was the cost of a pointer copy, and I was pointing out it's not a pointer. eg., sizeof(std::map) is 48, which is the "pointers and bookeeping" you mention.

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

#282

Post by mcguire »

Avi-D-coder wrote: post #214
mcguire wrote: post #124

Earlier quoted context omitted.

Maintain a collection of objects with finalizers associated with the generation; when an object is moved out of the generation, move the finalizer record with it. Then, just before the generation is discarded, run the finalizers. If the finalizers do something stupid like resurrect the object, have the runtime system notify someone with the authority to go beat the programmer with a stick.

Interestingly for the Rust GC I'm working both Drop and finalizers will be supported. Do you happen to offer beat the programmer with a stick as a service?

Unfortunately, no, but you are going to need it.

I was fooling with a cycle-collected reference counter for Rust for a while, but eventually gave up because of the difficulty in handling finalizers.

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

#283

Post by projektfu »

MaxBarraclough wrote: post #271
ShroudedNight wrote: post #207

Earlier quoted context omitted.

Not Rust, C++, but in case anybody wants an example: https://github.com/eclipse/omr/commit/fd99ca42fdbed76cc00e68... TR::Region is the slab allocator used by the JIT in OpenJ9/OMR. The linked commit adds functionality for calling destructors of arbitrary types allocated in the Region.

Interesting, thanks. Seems to require use of a common base class though, i.e. to use a class with this pool, you have to inherit from Destructable, or else create a subclass that does. Seems ugly. Perhaps that's the only way it can be done in C++ though.

It does create an object with that base class for the allocator but returns an object of the type you want from the allocator, using a template (Region::Instance). So the API user only sees the types it's interested in.

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

#284

Post by pjmlp »

ahupp wrote: post #281
pjmlp wrote: post #278

Earlier quoted context omitted.

Not necessary, std::map::map(&&) is free to move just the internal pointers and bookkeeping data, only dumb implementations would move the memory blocks where the map data is actually stored, as per ISO C++ requirements.

The comment originally said it was the cost of a pointer copy, and I was pointing out it's not a pointer. eg., sizeof(std::map ) is 48, which is the "pointers and bookeeping" you mention.

Ah sorry for the misinterpretation. Should have payed more attention.

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

#285

Post by nitrogen »

thebean11 wrote: post #178
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.

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…

This thread has a lot of branches, so I am just picking one for this general reply:

I recall reading somewhere, years ago, that some OSes couldn't be relied upon to release unfreed memory when a process terminated. In those contexts, fastidious freeing would be important even in short-lived processes.

In my own C code I tend to free everything so that I get a clean trace from Valgrind and don't risk masking legitimate bugs, but I typically write long-running daemons.

Post reply on HN