Anybody who uses a pow call to square a number must believe compilers are magic. Worse yet, some compilers might actually optimize for that case, reinforcing that belief.
Compilers should be dumb, fast and predictable instead. That way, everyone gets what they deserve.
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.
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).
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.
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.
"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 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.
MSVC compiler doesn't do SROA, as far as I know.
> What do you think 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/
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.
Yes, it has since at least 2010 (and probably earlier). See "scalar replacement": https://blogs.msdn.microsoft.com/vcblog/2009/11/02/visual-c-...
> Have you actually looked at that thing? It's not a Point struct, I can tell you that. There's nothing abstract about it.
The Vec classes can be used as Point structs.
> 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.
So pad it out to 4 fields, using homogeneous coordinates.
> 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/
That's not making a lot of assumptions about your compiler. The x87 floating point stack, for example, has been obsolete for a long time.
> 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.
I disagree. Let's look at actual examples. "Almost certainly" suboptimal abstractions are not what we've seen in Rust, for example, which leans on abstractions heavily.
See my reply to whitequark_, this seems to be loop-specific.
> The Vec classes can be used as Point structs.
Oh, sure. Which one though? How do I abstract this, again?
> So pad it out to 4 fields, using homogeneous coordinates.
In other words, "do something else than what I originally did" and "potentially leave 25% throughput on the table".
I think you're trying to pull a fast one on me.
> That's not making a lot of assumptions about your compiler. The x87 floating point stack, for example, has been obsolete for a long time.
Did you even read beyond the first paragraphs? There's five compiler-specific flags you'll have to get right for any of this to work.
Again, there's no free lunch...
> I disagree. Let's look at actual examples. "Almost certainly" suboptimal abstractions are not what we've seen in Rust, for example, which leans on abstractions heavily.
Could you just scroll up for a moment? We are talking about this because someone wrote the "abstract" version of squaring a number and some optimization didn't kick in, resulting in significantly degraded performance. And that's a trivial example! In a real codebase, you'll have to carefully audit compiler output to see if it does the right thing, potentially requiring you to rewrite code. For Rust, you also have the blessing that there is only one compiler...
In the future, consider verifying your extraordinary claims. Of course it does, and it took me about two minutes to demonstrate that: https://godbolt.org/g/9kT1NP
You haven't actually verified SROA. The scalar replacement didn't kick in for the non-inlined method, so this could be a result of loop-specific optimizations. The code is also far from optimal, but that's besides your point of course.
Also note that you're testing an RC of the latest version. There's a feature request for SROA from 2013, so it may be implemented by now: https://connect.microsoft.com/VisualStudio/feedback/details/...
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.
With dumb compilers we are putting the need to understand every machine on every developer. Isolating what knowledge is required in different locations is exactly why we have abstractions. The compiler is just one more abstraction to help this kind of specialization and basic division of labor.
Regarding the second statement: These "smart" optimizations happen before architecture specialization, so that's wrong too. But even if it was true, you now shift the burden to understanding every compiler in order to get the optimization you need.
If people expect that pow(x,2) transforms to x * x, then every compiler would have to implement that. This is a trivial example, but you in reality you always have to structure your code appropriately for some optimization to kick in, what if one of your target compilers needs a different structure?
Do you get your copy of Hacker's Delight off the bookshelf to look up the magic number instead of writing "x / 3"?
Everyone relies on optimizations to some extent. It's simply infeasible to do otherwise.
Clearly that is not what you mean and is not a good thing. Perhaps optimizing compilers put you outside of your comfort zone because you think they force you to learn and keep up to date.
You can do that or you can stick to writing idiomatic code that uses the std library for a given compiler. Doing just this tends to produce extremely good results. I often outdo others near just with this when they are dropping to assembly or doing silly workarounds because they know something is slow. Profiling and timing are required to pick up the rest of the performance, and presuming otherwise is silly. No special knowledge of the machine or compiler is required, just a knowledge of when and how to optimize and when and how to write idiomatically.
The abstraction is fundamentally leaky. As someone who worked on a compiler for years, cost models are important, and benchmarks and perceptions are very important -- but they are often non-intuitive and not totally "free", as TINSTAAFL says.
That said, optimizing something like a self-pow call to a square is probably not overreaching as an optimization or whatever. But there is certainly something to be said about over doing it and before you know it, you've kicked the can down to <person in the hallway who's really good at optimizing on platform X> because they had to do it anyway because only they know why the JVM or whatever behaves that way on a Friday with 17 inner class methods or something and you're really sure it can be faster but you've got a deadline in like a week and holy shit you have 3 other things to do.
As an aside, I think if any compiler gets the "most sane cost model award", it would probably be Chez Scheme, since it is both unbelievably fast, and based entirely around a practical metric: basically no optimization is added if it cannot speed up the compiler itself. Performance should be predictable both in terms of runtime and compile time. Since the compiler is a rather general purpose application -- if the optimization isn't worth it there, it's probably too overly specific, and likely isn't carrying its own weight. After 30 years of following this rule -- Chez is very, very fast.
If you presume this, we would still need that knowledge for simple compilers too and the hardware.
Regardless, I disagree with this. Even though the abstractions are leaky, not everything is leaked. For example: Algorithms that have tight loops to do things that fit in cache will do better than those that loop over massive sets. This only leaks the cache size and little else.
You claim to develop compilers, so maybe I am out of my depth. When I read blog posts or watch videos, like those from the latest cppcon. They all boil down to the simple advice "write idiomatic code and don't try to be more clever than the problem requires". Then when that performance isn't good enough profile and optimize. This is working well for me in 3d games. When I see fit to look at my assembly all of it makes good direct sense, and when it doesn't it is extremely fast.
So looking at the previous example leaking the cache size; A slightly smart compiler might insert extra instructions to tell some CPUs how to prefetch whatever is next. A very smart compiler will detect data dependency and rework the loop to operate on a data set that fits in cache (maybe even querying the size of the cache). The alternative is for the dev to know the cache szie at the time the algorithm is written and take it into account there. This is a simple example but shows the problem, why should the dev care about the cache size, when it can be automatically accounted for?
Are there some more nuanced examples where the simple pattern of write idiomatically then profile fails?
I happen to have of those videos[1] running in the background right now about abstractions that cost nothing. I will start it over and pay more attention with your added details in mind. I will also look into Chez Scheme this is the first I have ever heard of it.
[1] CppCon 2016: Serge Guelton “C++ Costless Abstractions: the compiler view" - https://www.youtube.com/watch?v=q0N9Tvf7Bz0&index=108&list=P...
However, for a compiler writer, it isn't sufficient. They're in the business of being the bottleneck! As such, they quickly enter a space where they have to set down their own principles for what idiomatic code looks like and how much they allow abstractions to leak upwards, negotiating those principles against the ecosystem of real-world code.
A consequence of this is that a compiler that only has to operate on a single codebase has it easy, because all its optimizations can be customized to the problem domain and target devices, while more generalized compilers have a dynamic optimization problem, where some features help some of the time, and not others. And their clients are all going to be programmers who get themselves into big trouble and then want the compiler to solve the problem.
This is what gave us C, while the rest of the mainframe world was busy using Algol, PL/I, Fortran and Lisp dialects. Where many of the compilers already were capable of doing bounds checking elision.
I'm guessing he thought using a temporary variable would look less pretty, and had no idea of the relative costs of imul and ipow.
> Compilers should be dumb, fast and predictable instead.
I don't care too much about dumb or fast, but they definitely need to be predictable. Even with something as low-level as C++ or Fortran, you often have to profile and disassemble to see if the compiler is doing the optimizations you want (e.g. unrolling loops, inlining functions, propagating constants, using SSE), or if you have to hold its hand. Trying to predict whether something as high-level as GHC will do what you want, or to figure out how to make it do so, is an absolute nightmare.
GHC also happens to be one of the slowest compilers you could possibly use. It all goes together.
One cannot realistic expect that any compiler for a given language behaves the same way.
This doesn't matter when any correct program is "good enough," but it matters a whole lot when failure to perform specific optimizations makes a program unacceptably slow.
That's a good way to get pummeled in benchmarks. Benchmark scores matter a lot to perception: just look at any HN thread about programming language or browser performance, or any review of browsers in the tech press.
We may not like it, but the benchmark-dominated world is the world we live in.