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

Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

1f6042.blogspot.com

Post reply on HN
Print view View original

21–30 of 152 posts

Re: Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

#21

Post by jeffbee »

josephg wrote: post #18
jeffbee wrote: post #4

Clang generates the shortest of these if you target sandybridge, or x86-64-v3, or later. The real article that's buried in this article is that compilers target k8-generic unless you tell them otherwise, and the features and cost model of opteron are obsolete. Always specify your target.

Yep. Adding "-C target-cpu=native" to rustc on my desktop computer consistently gets a ~10-15% performance boost compared to the default target. The default target is extremely conservative. As far as I can tell, it doesn't take advantage of any CPU features added in the last 20 years. (The k8 came out in 2003.)

Those Gentoo people were onto something.

Re: Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

#22

Post by lpapez »

svantana wrote: post #6

I'm a heavy std::clamp user, but I'm considering replacing it with min+max because of the uncertainty about what will happen when lo > hi. On windows it triggers an assertion, while other platforms just do a min+max in one or the other order. Of course, this should never happen but can be difficult to guarantee when the limits are derived from user inputs.

> Of course, this should never happen but can be difficult to guarantee when the limits are derived from user inputs.

Sounds to me like you are missing a validation step before calling your logic. When it comes to parsing, trusting user input is a recipe for disaster in the form of buffer overruns and potential exploits.

As they used to say in the Soviet Union: "trust, but verify".

Re: Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

#23

Post by rwmj »

cogman10 wrote: post #16
gumby wrote: post #11

Earlier quoted context omitted.

You (celegans25) probably know this but here is a PSA that -ffast-math is really -finaccurate-math. The knowledgeable developer will know when to use it (almost never) while the naive user will have bugs.

Ehh, not so much inaccurate, more of a "floating point numbers are tricky, let's act like they aren't". Compilers are pretty skittish about changing the order of floating point operations (for good reason) and ffast-math is the thing that lets them transform equations to try and generate faster code. IE, instead of doing "n / 10" doing "n * 0.1". The issue, of course, being that things like 0.1 can't be perfectly rep…

It isn't just that. -ffast-math also allows the compiler to ignore infinites. In fact for GCC with -ffast-math, isinf always returns false. Something similar happens for NaNs/isnan.

Re: Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

#24

Post by PaulDavisThe1st »

lpapez wrote: post #22
svantana wrote: post #6

I'm a heavy std::clamp user, but I'm considering replacing it with min+max because of the uncertainty about what will happen when lo > hi. On windows it triggers an assertion, while other platforms just do a min+max in one or the other order. Of course, this should never happen but can be difficult to guarantee when the limits are derived from user inputs.

> Of course, this should never happen but can be difficult to guarantee when the limits are derived from user inputs. Sounds to me like you are missing a validation step before calling your logic. When it comes to parsing, trusting user input is a recipe for disaster in the form of buffer overruns and potential exploits. As they used to say in the Soviet Union: "trust, but verify".

That was what Reagan said about the Soviet Union, not what was said in the Soviet Union.

Correct me if I'm wrong.

Re: Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

#25

Post by [deleted] »

lpapez wrote: post #22
svantana wrote: post #6

I'm a heavy std::clamp user, but I'm considering replacing it with min+max because of the uncertainty about what will happen when lo > hi. On windows it triggers an assertion, while other platforms just do a min+max in one or the other order. Of course, this should never happen but can be difficult to guarantee when the limits are derived from user inputs.

> Of course, this should never happen but can be difficult to guarantee when the limits are derived from user inputs. Sounds to me like you are missing a validation step before calling your logic. When it comes to parsing, trusting user input is a recipe for disaster in the form of buffer overruns and potential exploits. As they used to say in the Soviet Union: "trust, but verify".

[deleted]

Re: Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

#26

Post by iknowstuff »

lpapez wrote: post #22
svantana wrote: post #6

I'm a heavy std::clamp user, but I'm considering replacing it with min+max because of the uncertainty about what will happen when lo > hi. On windows it triggers an assertion, while other platforms just do a min+max in one or the other order. Of course, this should never happen but can be difficult to guarantee when the limits are derived from user inputs.

> Of course, this should never happen but can be difficult to guarantee when the limits are derived from user inputs. Sounds to me like you are missing a validation step before calling your logic. When it comes to parsing, trusting user input is a recipe for disaster in the form of buffer overruns and potential exploits. As they used to say in the Soviet Union: "trust, but verify".

The answer is of course

    clamp(min(a,b), max(a,b))
classic c++

Re: Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

#27

Post by [deleted] »

PaulDavisThe1st wrote: post #24
lpapez wrote: post #22

Earlier quoted context omitted.

> Of course, this should never happen but can be difficult to guarantee when the limits are derived from user inputs. Sounds to me like you are missing a validation step before calling your logic. When it comes to parsing, trusting user input is a recipe for disaster in the form of buffer overruns and potential exploits. As they used to say in the Soviet Union: "trust, but verify".

That was what Reagan said about the Soviet Union, not what was said in the Soviet Union. Correct me if I'm wrong.

[deleted]

Re: Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

#28

Post by alexey-salmin »

gumby wrote: post #11
celegans25 wrote: post #10

On gcc 13, the difference in assembly between the min(max()) version and std::clamp is eliminated when I add the -ffast-math flag. I suspect that the two implementations handle one of the arguments being NaN a bit differently. https://gcc.godbolt.org/z/fGaP6roe9 I see the same behavior on clang 17 as well https://gcc.godbolt.org/z/6jvnoxWhb

You (celegans25) probably know this but here is a PSA that -ffast-math is really -finaccurate-math. The knowledgeable developer will know when to use it (almost never) while the naive user will have bugs.

If your code ventures into the domain where fast-math matters and you're not a mathematician trying to solve a lyapunov-unstable problem with very tricky numeric methods, then most likely your code is already broken.

Re: Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

#30

Post by wongarsu »

josephg wrote: post #18
jeffbee wrote: post #4

Clang generates the shortest of these if you target sandybridge, or x86-64-v3, or later. The real article that's buried in this article is that compilers target k8-generic unless you tell them otherwise, and the features and cost model of opteron are obsolete. Always specify your target.

Yep. Adding "-C target-cpu=native" to rustc on my desktop computer consistently gets a ~10-15% performance boost compared to the default target. The default target is extremely conservative. As far as I can tell, it doesn't take advantage of any CPU features added in the last 20 years. (The k8 came out in 2003.)

Red Hat Enterprise Linux has upgraded their default target to x86-64-v2 and is considering switching to x86-64-v3 for RHEL 10 (which should release around 2026?). I'd take that as a sign that those might be reasonable choices for newly released software.

Some linux distros also give you the option to either get a version compatible with ancient hardware or the optimized x86-64-v3 version, which seems like a good compromise.

Post reply on HN