Hacker News Reader

Comment by keeperofdakeys | Hacker News Reader

You should be careful trying to apply these micro benchmarks to modern optimising compiles, behaviour may be different depending on the exact code being compiled. Rust especially has immutability and known types in generics at compile time, so the compiler can do a lot of pointer and inlining magic that C and other languages can't.

In the below example Rust switches to using a pointer when you might think it's doing pass by copy/move. This works because in Rust the moved value can never be referenced after calling the function, so the compiler can just pass a pointer and clean up the value after the function has returned.

https://www.reddit.com/r/rust/comments/3g30fw/how_efficient_...

View on HN

> so the compiler can do a lot of pointer and inlining magic that C and other languages can't.

Isn't this a negative for Rust for when you actually do care about such micro-optimizations? It feels as if you not only need to know the language itself but also how the particular version of the compiler you are using has decided to interpret the language and apply optimizations - essentially having to know how the magic trick is performed.

AFAIK this is why Free Pascal added constref in addition to const (which existed since the 90s in Delphi) - the latter doesn't guarantee pass-by-reference (even if in most cases it will do that) so if you care about that you need to know how the compiler you are using will treat it (thus needing to know more than just the language) but constref does exactly that. Now granted this was mainly done for interfacing with external code written in other langauges than micro-optimizations, but it still applies that if you cared about what the compiler will produce you had to rely on "magic knowledge" before constref was introduced.

In general Rust emphasises semantics over implementation side-effects. For example you use a pass-by-value because you're semantically moving ownership of the value to the function, not because the implementation may be faster/slower at the assembly level. Not nailing down the implementation is what allows the compiler to make so many optimisations.

If you need concise pointer control, use the unsafe trapdoor built into rust (like Rust's Vec). If you need very specialised code use assembly, not by abusing language side-effects like Duff's Device. If you need fast number crunching use the specialised library for it, not by writing a magic for loop with just the right amount of statements in it.

I admit that sometimes you need to micro-optimise, but I haven't come across this case much in my Rust code. When I do I usually hinder more then help it.

>If you need fast number crunching use the specialised library for it, not by writing a magic for loop with just the right amount of statements in it.

There is always that group of people who are trying to do something for which no specialized library exists.

As a member of that group, Hacker News is not where I come for answers to my questions. I think it's perfectly reasonable for comments here to assume that the readers of the comment aren't in that group. Either you know what you're doing enough that 99.9% of the internet is not helpful to you, or you're probably up shit creek without a paddle anyway until you figure out enough to move into the first group.

Then they'll use ASM, manual SIMD or pointers arithmetic like they would do in C and that would work. All of theses are part of the unsafe Rust (inline ASM is nightly only though, but you can still link to a ASM file even in stable).

> It feels as if you not only need to know the language itself but also how the particular version of the compiler you are using has decided to interpret the language and apply optimizations - essentially having to know how the magic trick is performed.

That's also true with C/C++, isn't it? Optimizations should be different if you compile a C program with GCC or CLANG, or even with GCC x or y versions (but I'm not a compiled language programmer, I could be wrong)

You're absolutely right. It's not even just optimization. If you exercise your C++ compiler hard enough, you will find bugs. You have to know what the compiler is doing.

I have the misfortune of working somewhere where I generally have to use older versions of compilers for production. I've found two compiler bugs just in the last two years since I started my current project. I'm usually the last person to blame the compiler, but in this case I can be pretty confident because the bugs I found were fixed in later versions of the compiler.

Just like Ada has in, out and inout.

The actual generated code depends on the optimizer, while preserving semantics.

C++ also has some copy elision: https://en.cppreference.com/w/cpp/language/copy_elision

This is a very obscure topic in general, and almost requires reading the C++ standard to understand it.

0. Generously use black_box

1. a large sample size

2. a single thread

3. high-precision monotonic timestamps on an unloaded system

4. mean/std dev from more than several runs

5. run them long enough to stabilize thermally so you don't have bursts of performance (potentially minutes), and/or use something like perflock to lock down your cpu speed: https://github.com/aclements/perflock (general tactic, this is just the last tool I heard of)

6. for similar reasons, run them in a random order each time

Or frameworks helping you do so - like "benchmark" for C++ (though I wonder if there is a cross-language one - that does the same amount of "pre"-warming, same counters, etc.)

Probably not... and too much to ask.

Reply on news.ycombinator.com