3 ms·
The problem is that application performance doesn't only depend on the thing you want to do, but also depends on the low level implementation details and worklo
by pca006132 4y ago
The problem is that application performance doesn't only depend on the thing you want to do, but also depends on the low level implementation details and workload, which the programmer may not fully understand or in control of. Some operation may be optimal when executed alone but exists better alternative for batch processing. Some programs may be optimized for throughput but is really bad for low latency application. The designer have to consider these when designing their system, and compilers/library writers can't help much except write a more comprehensive documentation which the programmer will probably not read :).
I think abstraction guides implementation, so it is very beneficial to think about what will be the bottleneck in the application, and if a certain abstraction will hinder the performance or prohibit future optimization. And although a low level abstraction can in theory allow for better performance if the programmer spend enough time to optimize for it, they often won't and a simpler interface (with sane implementation and perhaps escape hatches for performance tuning) may allow for better performance with much less effort.
- AnimalMuppet 4y ago> I think abstraction guides implementation, so it is very beneficial to think about what will be the bottleneck in the application I think this way, but in terms of the "performance" of writing the application. What makes it hard to write this program? For example, in high-performance computing, you may need to control memory alignment (for SIMD and cache reasons). That makes it harder to write a program that just implements an algorithm. So I think you should identify what it is that makes the program hard to write, and pick abstractions that help with that, that give you easier ways of controlling or managing that hard part.