u/InfinitesimaInfinity

Why are people so quick to dismiss optimization as "premature" without knowing the use case or bottlenecks?

Why are people so quick to dismiss optimization as "premature" without knowing the use case or bottlenecks?

I have seen several people online say that using C, C++, Zig, or Rust in the modern day for anything other than embedded programming is "premature optimization".

I know that choosing a horrible algorithm can impact performance much more than choice of language, and I also know that most high performance libraries for "high-level" languages like Python are written in faster languages like Fortran. However, when looking at the frequently viewed Wikipedia pages with the "Programming Languages" template, I noticed that the article claims that an idiomatic Python program being interpreted with CPython is "typically" worse than an equivalent C program by a large margin. The article claims 75.88 time more energy usage, 71.9 times slower, and 2.4 times more average RAM usage. Looking at the cited source, which is a paper from the "Proceedings of the 10th ACM SIGPLAN International Conference on Software Language Engineering", it seems like they used GCC to compile the C, and the computer was running "Linux Ubuntu Server 16.10 on a computer with 16GB of RAM and a Haswel Intel i5-4660 CPU at 3.2 GHz".

I know that we need to take anything that we read from people in academia with a grain of salt. However, the paper has already undergone peer-review, and if it is even anywhere close to the truth, then that would seem to imply that there is a massive difference between Python with CPython and C with GCC. Also, I know that alternative implementations of Python exist, several of which are more than ten times as fast as CPython. (like Codon, Cython, etc). However, surely there are some people who have use cases other than embedded yet have a reason to favor "system-level" languages like C, C++, Zig, and Rust over "high-level" languages like Python, Javascript, PHP, Perl, etc.

Also, the dismissal of optimization goes beyond just choice of language. I saw a Stack Overflow question asking about optimization, and it had a response of someone giving an anecdotal about how they sped something up from originally taking 48 seconds to taking 1.1 seconds. (without even changing the language). Out of the 46.9 seconds that he sped it up by, diagnostic printing accounted for 3 seconds and unnecessary memory allocations accounted for 1.4 seconds. 3 seconds might not seem like a lot for a program that takes 48 seconds. However, in a program that takes 7 seconds total, it seems like a lot.

The pages that I am directly referencing are the following.

https://en.wikipedia.org/wiki/Python_(programming_language)

https://stackoverflow.com/questions/926266/performance-optimization-strategies-of-last-resort

u/InfinitesimaInfinity — 2 days ago
▲ 453 r/linux

PREEMPT_NONE has previously existed to provide a way to gain more throughput on almost all workloads at the expense of also gaining some more latency, and it was better for most server workloads, which value throughput more than latency.

For workloads that spend most of their time in spinlocks, it was actually able to have significantly lower latency than the other preemption options, as well.

According to Salvatore Dipietro, some PostgreSQL workloads have approximately half the performance when using PREEMPT_LAZY instead of PREEMPT_NONE.

The Linux kernel maintainers have responded that PostgreSQL should add the use of the "RSEQ timeslice extension", which enables a process to ask the kernel to delay preemption for a short period of time. (The default delay is 5 millionths of a second.)

However, this solution is not perfect. First of all, it would require PostgreSQL to make changes that would make PostgreSQL unable to work on any machines that do not have an up to date kernel, dropping support for all kernels below version 7. Second of all, it would still reduce throughput and latency on such workloads. It would merely reduce them less.

Edit: I suppose that PostgreSQL could check whether the kernel is past version 7 and have two separate versions of each spinlock, one for kernels below 7 and one for kernels above 7, in which case it could still work on kernels below 7.

lkml.org
u/InfinitesimaInfinity — 2 months ago