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

Wild performance tricks

davidlattimore.github.io

Post reply on HN
Print view View original

11–20 of 86 posts

Re: Wild performance tricks

#11

Post by quotemstr »

> Even if it were stable, it only works with slices of primitive types, so we’d have to lose our newtypes (SymbolId etc).

That's weird. I'd expect it to work with _any_ type, primitive or not, newtype or not, with a sufficiently simple memory layout, the rough equivalent of what C++ calls a "standard-layout type" or (formerly) a "POD".

I don't like magical stdlibs and I don't like user types being less powerful than built-in ones.

Clever workaround doing a no-op transformation of the whole vector though! Very nearly zero-cost.

> It would be possible to ensure that the proper Vec was restored for use-cases where that was important, however it would add extra complexity and might be enough to convince me that it’d be better to just use transmute.

Great example of Rust being built such that you have to deal with error returns and think about C++-style exception safety.

> The optimisation in the Rust standard library that allows reuse of the heap allocation will only actually work if the size and alignment of T and U are the same

Shouldn't it work when T and U are the same size and T has stricter alignment requirements than U but not exactly the same alignment? In this situation, any U would be properly aligned because T is even more aligned.

Re: Wild performance tricks

#12

Post by jandrewrogers »

Ar-Curunir wrote: post #5
Strilanc wrote: post #2

Every one of these "performance tricks" is describing how to convince rust's borrow checker that you're allowed to do a thing. It's more like "performance permission slips".

This is an issue that you would face in any language with strong typing. It only rears its head in Rust because Rust tries to give you both low-level control and strong types. For example, in something like Go (which has a weaker type system than Rust), you wouldn't think twice about, paying for the re-allocation in buffer-reuse example. Of course, in something like C or C++ you could do these things via simple point…

> in something like C or C++ you could do these things via simple pointer casts

No you don't. You explicitly start a new object lifetime at the address, either of the same type or a different type. There are standard mechanisms for this.

Developers that can't be bothered to do things correctly is why languages like Rust exist.

Re: Wild performance tricks

#13

Post by maccard »

ManlyBread wrote: post #6
oleganza wrote: post #3

Earlier quoted context omitted.

You don't have to play this game - you can always write within unsafe { ... } like in plain old C or C++. But people do choose to play this game because it helps them to write code that is also correct, where "correct" has an old-school meaning of "actually doing what it is supposed to do and not doing what it's not supposed to".

That just makes it seem like there's no point in using this language in the first place.

Dont let perfect be the enemy of good.

Software is built on abstractions - if all your app code is written without unsafe and you have one low level unsafe block to allow for something, you get the value of rust for all your app logic and you know the actual bug is in the unsafe code

Re: Wild performance tricks

#14

Post by aw1621107 »

quotemstr wrote: post #11

> Even if it were stable, it only works with slices of primitive types, so we’d have to lose our newtypes (SymbolId etc). That's weird. I'd expect it to work with _any_ type, primitive or not, newtype or not, with a sufficiently simple memory layout, the rough equivalent of what C++ calls a "standard-layout type" or (formerly) a "POD". I don't like magical stdlibs and I don't like user types being less powerful than…

> I'd expect it to work with _any_ type, primitive or not, newtype or not, with a sufficiently simple memory layout, the rough equivalent of what C++ calls a "standard-layout type" or (formerly) a "POD".

This might be related in part to the fact that Rust chose to create specific AtomicU8/AtomicU16/etc. types instead of going for Atomic like in C++. The reasoning for forgoing the latter is [0]:

> However the consensus was that having unsupported atomic types either fail at monomorphization time or fall back to lock-based implementations was undesirable.

That doesn't mean that one couldn't hypothetically try to write from_mut_slice where T is a transparent newtype over one of the supported atomics, but I'm not sure whether that function signature is expressible at the moment. Maybe if/when safe transmutes land, since from_mut_slice is basically just doing a transmute?

> Shouldn't it work when T and U are the same size and T has stricter alignment requirements than U but not exactly the same alignment? In this situation, any U would be properly aligned because T is even more aligned.

I think this optimization does what you say? A quick skim of the source code [1] seems to show that the alignments don't have to exactly match:

    //! # Layout constraints
    //! 
    //! Alignments of `T` must be the same or larger than `U`. Since alignments are always a power
    //! of two _larger_ implies _is a multiple of_.
And later:

    const fn in_place_collectible(
        step_merge: Option,
        step_expand: Option,
    ) -> bool {
        if const { SRC::IS_ZST || DEST::IS_ZST || mem::align_of::() () } {
            return false;
        }
        // Other code that deals with non-alignment conditions
    }
[0]: https://github.com/Amanieu/rfcs/blob/more_atomic_types/text/...

[1]: https://github.com/rust-lang/rust/blob/c58a5da7d48ff3887afe4...

Re: Wild performance tricks

#15

Post by kibwen »

Strilanc wrote: post #2

Every one of these "performance tricks" is describing how to convince rust's borrow checker that you're allowed to do a thing. It's more like "performance permission slips".

...Except that Rust is thread-safe, so expressing your algorithm in terms that the borrow checker accepts makes safe parallelism possible, as shown in the example using Rayon to trivially parallelize an operation. This is the whole point of Rust, and to say that C and C++ fail at thread-safety would be the understatement of the century.

Re: Wild performance tricks

#16

Post by kibwen »

jstimpfle wrote: post #9
Ar-Curunir wrote: post #5

Earlier quoted context omitted.

This is an issue that you would face in any language with strong typing. It only rears its head in Rust because Rust tries to give you both low-level control and strong types. For example, in something like Go (which has a weaker type system than Rust), you wouldn't think twice about, paying for the re-allocation in buffer-reuse example. Of course, in something like C or C++ you could do these things via simple point…

In C I wouldn't use such a fluffy high-level approach in the first place. I wouldn't use contiguous unbounded vec-slices. And no, I wouldn't attempt trickery with overwriting input buffers. That's a bad inflexible approach that will bite at the next refactor. Instead, I would first make sure there's a way to cheaply allocate fixed size buffers (like 4 K buffers or whatever) and stream into those. Memory should be use…

> In C I wouldn't use such a fluffy high-level approach in the first place.

Sure, though that's because C has abstraction like Mars has a breathable atmosphere.

> This approach leads to straightforward, efficient architecture and bug-free code. It's also much better for concurrency/parallelism.

This claim is wild considering that Rust code is more bug-free than C code while being just as efficient, while keeping in mind that Rust makes parallelism so much easier than C that it's stops being funny and starts being tragic.

Re: Wild performance tricks

#17

Post by ComputerGuru »

vlovich123 wrote: post #10

> Now that we have a Vec with no non-static lifetimes, we can safely move it to another thread. I liked most of the tricks but this one seems pointless. This is no different than transmute as accessing the borrower requires an assume_init which I believe is technically UB when called on an uninit. Unless the point is that you’re going to be working with Owned but want to just transmute the Vec safely. Overall I like…

You misunderstood the purpose of that trick. The vector is not going to be accessed again, the idea is to move it to another thread so it can be dropped in parallel (never accessed).

Re: Wild performance tricks

#18

Post by ComputerGuru »

I don't like relying on (release-only) llvm optimizations for a number of reasons, but primarily a) they break between releases, more often than you'd think, b) they're part of the reason why debug builds of rust software are so much slower (at runtime) than release builds, c) they're much harder to verify (and very opaque).

For non-performance-sensitive code, sure, go ahead and rely on the rust compiler to compile away the allocation of a whole new vector of a different type to convert from T to AtomicT, but where the performance matters, for my money I would go with the transmute 100% of the time (assuming the underlying type was decorated with #[transparent], though it would be nice if we could statically assert that). It'll perform better in debug mode, it's obvious what you are doing, it's guaranteed not to break in a minor rustc update, and it'll work with &mut [T] instead of an owned Vec (which is a big one).

Re: Wild performance tricks

#19

Post by 0x1ceb00da »

> It’d be reasonable to think that this will have a runtime cost, however it doesn’t. The reason is that the Rust standard library has a nice optimisation in it that when we consume a Vec and collect the result into a new Vec, in many circumstances, the heap allocation of the original Vec can be reused. This applies in this case. But what even with the heap allocation being reused, we’re still looping over all the elements to transform them right? Because the in-memory representation of an AtomicSymbolId is identical to that of a SymbolId, our loop becomes a no-op and is optimised away.

Those optimisations that this code relies on are literally undefined behaviour. The compiler doesn't guarantee it's gonna apply those optimisations. So your code might suddenly become super slow and you'll have to go digging in to see why. Is this undefined behaviour better than just having an unsafe block? I'm not so sure. The unsafe code will be easier to read and you won't need any comments or a blog to explain why we're doing voodoo stuff because the logic of the code will explain its intentions.

Re: Wild performance tricks

#20

Post by stouset »

0x1ceb00da wrote: post #19

> It’d be reasonable to think that this will have a runtime cost, however it doesn’t. The reason is that the Rust standard library has a nice optimisation in it that when we consume a Vec and collect the result into a new Vec, in many circumstances, the heap allocation of the original Vec can be reused. This applies in this case. But what even with the heap allocation being reused, we’re still looping over all the el…

You're misusing the term "undefined behavior". You can certainly say that these kinds of performance optimizations aren't guaranteed.
Post reply on HN