Outsmarting the compiler: Short story about optimization • Hacker News Board

Re: Outsmarting the compiler: Short story about optimization

#11

Post by JoachimSchipper » Tue, Jul 04, 2017, 7:40 AM UTC

Dreami wrote: post #10

How does this wrapper and each variant connect together? I supposed he would include a pointer to the actual struct in the wrapper, but I just see payload (that I'm gonna assume needs to be written to that array with padding in the actual struct). For me, a wrapper includes the original thing and just wraps stuff around it. How does this work here? May also be a question to the author, I suppose now...

In this wrapper, the payload[] field holds an instance of either struct A or of struct B - that is, the wrapper is "prepended" to the actual data.

Re: Outsmarting the compiler: Short story about optimization

#12

Post by bloaf » Tue, Jul 04, 2017, 11:41 AM UTC

So why wouldn't you just put c before the arr[padding#] chars?

Re: Outsmarting the compiler: Short story about optimization

#13

Post by FeepingCreature » Tue, Jul 04, 2017, 12:23 PM UTC

frozenport wrote: post #4

taneq wrote: post #3

Outsmarting the compiler: A short story about optimisation: "Don't." The end. (Basically, as the story shows, with this kind of micro-optimization you may or may not beat the compiler but you're almost certainly wasting your time compared with more effective optimization methods, like rethinking the problem.)

This is stupid because it categorically denies the business case for micro-optomization. Yet, a business case might exist when the library is heavily utilized, or often when a compiler isn't able to produce the correct code. There are also cases primarily, in finance, where single threaded low-latency distinguishes competing groups. Some of those guys count every nanosecond. The techniques described here ( and in oth…

In my experience, microoptimization tends to be more a matter of how to organize your code so as to enable the compiler to do the optimizations for you. Cases where the compiler is outright too stupid to find the optimization you want even with repeated prompting tend to be rare nowadays, and probably justify a bug report.

Re: Outsmarting the compiler: Short story about optimization

#14

Post by Veedrac » Tue, Jul 04, 2017, 12:33 PM UTC

> Then, a bit later, we need to very quickly finish populating the structs.

I am finding it extremely hard to envision a circumstance where this is a bottleneck for anything. Care to clarify the context?

I also find the struct layout really odd; why not just move c?

Your benchmarks are also probably broken; branch predictors use global state so will almost certainly predict fine the way you've used things. You need to repopulate a significantly-sized array each time with randomly chosen values. You can't use the same array because it'll be learnt, and you can't use a short array because it'll be predicted globally.

Re: Outsmarting the compiler: Short story about optimization

#15

Post by dpzmick » Tue, Jul 04, 2017, 1:39 PM UTC

Veedrac wrote: post #14

> Then, a bit later, we need to very quickly finish populating the structs. I am finding it extremely hard to envision a circumstance where this is a bottleneck for anything. Care to clarify the context? I also find the struct layout really odd; why not just move c? Your benchmarks are also probably broken; branch predictors use global state so will almost certainly predict fine the way you've used things. You need t…

I'll give that benchmark trick a try. Thanks for the feedback.

For some additional context, these structs are packed wire-line protocol structs. In reality the padding bytes are full of other fun details.

Re: Outsmarting the compiler: Short story about optimization

#16

Post by dpzmick » Tue, Jul 04, 2017, 1:40 PM UTC

BenjiWiebe wrote: post #2

Quick upvote for a well designed mobile friendly site. The last few HN posts I read were awful on mobile.

Thanks! I started with a fork of this Jekyll site: https://github.com/johnotander/pixyll so I can't take much credit for the design

Re: Outsmarting the compiler: Short story about optimization

#17

Post by dpzmick » Tue, Jul 04, 2017, 1:42 PM UTC

bloaf wrote: post #12

So why wouldn't you just put c before the arr[padding#] chars?

In the real world version of this problem the padding bytes contain some real values and the structs are both written straight to a network line (protocol is defined externally)

Re: Outsmarting the compiler: Short story about optimization

#18

Post by dpzmick » Tue, Jul 04, 2017, 1:46 PM UTC

JoachimSchipper wrote: post #6

This is not so much "outsmarting the compiler" as "working with the compiler" - tweaking code to trigger certain optimizations/generate particular output. The missing part, of course, is showing that these optimizations actually help...

In this case I don't think that being clever can actually help us much. I have some microbenchmarks towards the end of the post that are not very indicative of any performance gained by writing this "clever" code.

Re: Outsmarting the compiler: Short story about optimization

#19

Post by dmh2000 » Tue, Jul 04, 2017, 1:51 PM UTC

gcc warning: ISO C++ forbids zero-size array ‘payload’ [-Wpedantic]

clang warning: flexible array members are a C99 feature [-Wc99-extensions]

is this still the case?

Re: Outsmarting the compiler: Short story about optimization

#20

Post by dpzmick » Tue, Jul 04, 2017, 1:53 PM UTC

taneq wrote: post #3

Outsmarting the compiler: A short story about optimisation: "Don't." The end. (Basically, as the story shows, with this kind of micro-optimization you may or may not beat the compiler but you're almost certainly wasting your time compared with more effective optimization methods, like rethinking the problem.)

In this case, yes, optimizations don't appear to be giving me much of a win. Although, I'm very glad I checked! There are certainly some very realistic scenarios in which it would be valuable to save this branch.