3 ms·

> developers have to have intimate knowledge about the implementation details in order to work around infelicities If you presume this, we would still need th

by sqeaky 10y ago

> developers have to have intimate knowledge about the implementation details in order to work around infelicities 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=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH https://www.youtube.com/watch?v=q0N9Tvf7Bz0&index=108&list=P...

buzzybee 10y ago
Idiomatic coding is ultimately premised on "following the grain of the compiler", with the language as a front-end abstraction to the compiler's various technologies(type checks, optimizations, etc.) - it can be seen as a way of minimizing bottlenecks that would occur when doing something that the compiler can't optimize well or the language can't express well. And for a lot of application code, that's sufficient. You write simple constructs, they get optimized away, everyone's happy. 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.

by sqeaky 10y ago

buzzybee 10y ago

Idiomatic coding is ultimately premised on "following the grain of the compiler", with the language as a front-end abstraction to the compiler's various technologies(type checks, optimizations, etc.) - it can be seen as a way of minimizing bottlenecks that would occur when doing something that the compiler can't optimize well or the language can't express well. And for a lot of application code, that's sufficient. You write simple constructs, they get optimized away, everyone's happy. 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.