3 ms·

Wow; I really disagree with this viewpoint. I want clever compilers that produce good code from high-level specifications. I fully accept the lack of predictabi

Wow; I really disagree with this viewpoint. I want clever compilers that produce good code from high-level specifications. I fully accept the lack of predictability. Also, your comment that "everyone gets what they deserve" suggests that those who write high-level code (e.g. using pow() to square a number) "deserve" to have slow code. That's a strange moral outlook.

234dd57d2c8dba 10y ago
If your code isn't predictable, you can't write performance sensitive code in it.
galacticpony 10y ago
It really isn't. You want something for free without putting the work. I want to put in some work to get what I need. You, too, believe in the magic compiler that doesn't exist. You don't get good code from a high-level specification. You really have to understand what the compiler actually can do for you and write your code accordingly, either way - except the predictable case is more straightforward (though maybe not as pleasing).
- pcwalton 10y ago
  "Putting in the work" often means not being able to use abstractions, which reduces the maintainability of code. That's what people often miss about optimizations: one of their most important uses is to enable abstractions. As a simple example, take SROA: without that optimization, you can't make a "Point { float x, y, z; }" struct and have that be as efficient as "float x, y, z;", because x, y, and z can live in registers in the latter, while in the former they remain as memory instead of being promoted to SSA values. But being able to use a Point structure like that is extremely helpful, because then I can define useful methods on it and so forth. I shouldn't have to choose between good engineering practice and performance, and thanks to SROA, I don't have to.
  - galacticpony 10y ago
    You've just invited the assumption that your compiler can do SROA as the basis for better performance - how is that an abstraction? If you really care about performance to the point of register occupancy, you need to look at the context. The "abstraction" of having a Point type with methods is almost certainly far from optimal, because it doesn't fit SIMD well. It's then also not "good engineering practice" to use it.
    - pcwalton 10y ago
      > You've just invited the assumption that your compiler can do SROA as the basis for better performance - how is that an abstraction? "Expands to the exact same code everywhere on every imaginable compiler, even toy compilers nobody uses" is not part of the definition of "abstraction". > If you really care about performance to the point of register occupancy, you need to look at the context. The "abstraction" of having a Point type with methods is almost certainly far from optimal, because it doesn't fit SIMD well. What do you think http://www.agner.org/optimize/#vectorclass http://www.agner.org/optimize/#vectorclass is then? > It's then also not "good engineering practice" to use it. Yes, it is! It makes your code more readable, and if you're compiling on any production-quality C compiler anywhere your Point class will have the same performance as the raw version. Lower maintenance cost, fewer bugs, same performance.
      - galacticpony 10y ago
        > "Expands to the exact same code everywhere on every imaginable compiler, even toy compilers nobody uses" is not part of the definition of "abstraction". MSVC compiler doesn't do SROA, as far as I know. > What do you think http://www.agner.org/optimize/#vectorclass http://www.agner.org/optimize/#vectorclass is then? Have you actually looked at that thing? It's not a Point struct, I can tell you that. There's nothing abstract about it. If you want to take advantage of SIMD fully, you need to lay out your data in a very specific way. A Point {x,y,z} struct doesn't naturally fit a SIMD register. Now, if you're willing to make a lot of assumptions on your compiler, you can do something like this: http://www.codersnotes.com/notes/maths-lib-2016/ http://www.codersnotes.com/notes/maths-lib-2016/ Still, you need to put in the work and the research. No magic. > Yes, it is! It makes your code more readable, and if you're compiling on any production-quality C compiler anywhere your Point class will have the same performance as the raw version. Lower maintenance cost, fewer bugs, same performance. If performance really matters then your abstract solution is almost certainly suboptimal and it's not good engineering practice to use it for the sake of readability.
shurcooL 10y ago
You have to keep in mind that adding support for special cases makes the general case a little bit slower (because it has to always check if it's the special case or not). It's not completely free to make pow work fast on small integers. So, it's a trade-off. I would also prefer less special cases optimized for naive use, but only if it's accompanied by documentation that says "prefer X instead of pow(x, 2), prefer Y instead of pow(-1, k), etc." It shouldn't be guesswork as to what's best to do for common cases.
- TomMarius 10y ago
  Most of the time, you can opt out of these optimizations.
- lomnakkus 10y ago
  That's not necessarily true. I'd wager that most cases where pow(x, 2) is used as a way to square x, the "2" is actually a constant. That's trivially statically optimizable at compile time.
  - dllthomas 10y ago
    In fact, if you are using pow specifically to "square a number" in the sense where you could replace it with x*x, it is guaranteed to be something you can determine statically (and probably pretty easily) - or you're already doing a lot of unnecessary work.
sunfish 10y ago
I think you're both right. The world of software is sufficiently diverse that there is no single answer to this question that works best for everyone in every situation.

234dd57d2c8dba 10y ago

If your code isn't predictable, you can't write performance sensitive code in it.

galacticpony 10y ago

It really isn't. You want something for free without putting the work. I want to put in some work to get what I need. You, too, believe in the magic compiler that doesn't exist. You don't get good code from a high-level specification. You really have to understand what the compiler actually can do for you and write your code accordingly, either way - except the predictable case is more straightforward (though maybe not as pleasing).

pcwalton 10y ago
"Putting in the work" often means not being able to use abstractions, which reduces the maintainability of code. That's what people often miss about optimizations: one of their most important uses is to enable abstractions. As a simple example, take SROA: without that optimization, you can't make a "Point { float x, y, z; }" struct and have that be as efficient as "float x, y, z;", because x, y, and z can live in registers in the latter, while in the former they remain as memory instead of being promoted to SSA values. But being able to use a Point structure like that is extremely helpful, because then I can define useful methods on it and so forth. I shouldn't have to choose between good engineering practice and performance, and thanks to SROA, I don't have to.
- galacticpony 10y ago
  You've just invited the assumption that your compiler can do SROA as the basis for better performance - how is that an abstraction? If you really care about performance to the point of register occupancy, you need to look at the context. The "abstraction" of having a Point type with methods is almost certainly far from optimal, because it doesn't fit SIMD well. It's then also not "good engineering practice" to use it.
  - pcwalton 10y ago
    > You've just invited the assumption that your compiler can do SROA as the basis for better performance - how is that an abstraction? "Expands to the exact same code everywhere on every imaginable compiler, even toy compilers nobody uses" is not part of the definition of "abstraction". > If you really care about performance to the point of register occupancy, you need to look at the context. The "abstraction" of having a Point type with methods is almost certainly far from optimal, because it doesn't fit SIMD well. What do you think http://www.agner.org/optimize/#vectorclass http://www.agner.org/optimize/#vectorclass is then? > It's then also not "good engineering practice" to use it. Yes, it is! It makes your code more readable, and if you're compiling on any production-quality C compiler anywhere your Point class will have the same performance as the raw version. Lower maintenance cost, fewer bugs, same performance.
    - galacticpony 10y ago
      > "Expands to the exact same code everywhere on every imaginable compiler, even toy compilers nobody uses" is not part of the definition of "abstraction". MSVC compiler doesn't do SROA, as far as I know. > What do you think http://www.agner.org/optimize/#vectorclass http://www.agner.org/optimize/#vectorclass is then? Have you actually looked at that thing? It's not a Point struct, I can tell you that. There's nothing abstract about it. If you want to take advantage of SIMD fully, you need to lay out your data in a very specific way. A Point {x,y,z} struct doesn't naturally fit a SIMD register. Now, if you're willing to make a lot of assumptions on your compiler, you can do something like this: http://www.codersnotes.com/notes/maths-lib-2016/ http://www.codersnotes.com/notes/maths-lib-2016/ Still, you need to put in the work and the research. No magic. > Yes, it is! It makes your code more readable, and if you're compiling on any production-quality C compiler anywhere your Point class will have the same performance as the raw version. Lower maintenance cost, fewer bugs, same performance. If performance really matters then your abstract solution is almost certainly suboptimal and it's not good engineering practice to use it for the sake of readability.

shurcooL 10y ago

You have to keep in mind that adding support for special cases makes the general case a little bit slower (because it has to always check if it's the special case or not). It's not completely free to make pow work fast on small integers. So, it's a trade-off. I would also prefer less special cases optimized for naive use, but only if it's accompanied by documentation that says "prefer X instead of pow(x, 2), prefer Y instead of pow(-1, k), etc." It shouldn't be guesswork as to what's best to do for common cases.

TomMarius 10y ago
Most of the time, you can opt out of these optimizations.
lomnakkus 10y ago
That's not necessarily true. I'd wager that most cases where pow(x, 2) is used as a way to square x, the "2" is actually a constant. That's trivially statically optimizable at compile time.
- dllthomas 10y ago
  In fact, if you are using pow specifically to "square a number" in the sense where you could replace it with x*x, it is guaranteed to be something you can determine statically (and probably pretty easily) - or you're already doing a lot of unnecessary work.

sunfish 10y ago

I think you're both right. The world of software is sufficiently diverse that there is no single answer to this question that works best for everyone in every situation.