It then needs someone to do a big parameter tuning to select optimal settings.
Too many decent algorithms don't make it into the kernel because there are too many tunables, and the ones that do typically arent well tuned for anyone's use case.
Even big projects like Ubuntu typically don't change many tunables in the kernel.
Have you seen phoronix framework + benchmarks? They use common tools, but did some good work on making the tests repeatable and accessible to anyone else.
https://apastyle.apa.org/style-grammar-guidelines/grammar/si...).
Not all will agree with those guidelines, they are far from universally acceptable.
The poster I replied to stated (I remember) that some use of language is made legitimate by some group laying out some guidelines. That some pretty random group («not philologists») lays out guidelines is maybe an "affiliation pass" for their group, but not universally valid.
You need grounds, good grounds. Check those guidelines...
Some people: "let's use, of already-established pronouns, the one that doesn't make any assumptions about people" You: "no, fuck you, other people's interpretation of what I say is strictly their problem, I'm gonna stick with 'he' no matter what other people feel or request, because I can"
The only ideology I can see here is the absolutist sort of "nobody can even suggest to me that I change a thing" or "I can't possibly cause offense if I don't mean to, so I don't need to think about word usage."
I don’t know what Michael’s preferred pronouns are, but isn’t the original poster in this chain assuming it’s they/them and aren’t they more likely, statistically speaking, to be he/him?
Why does it somehow not count as misgendering when you they/them someone that prefers he/him or she/her?
Because one appears to make an assumption about gender, whether or not you intended it to be taken as a generic, while the other objectively is generic.
As far as options go, they/them minimises assumptions. Yes, some people might still take offence, but given that most of the people who take offence at that takes offence because they oppose inclusiveness of others, I'm perfectly fine with not respecting their choice in the matter.
You have some evidence of this or just the unshakable certainty of the self righteous?
If you are an exception and have a good reason for taking offence that doesn't involve excluding others, do tell.
(I'm not a native English speaker)
Now “you” is shifting again: in formal English it is still singular or plural, but in colloquial American English — at least where I’m from — it can only be singular. The plural form is “you guys” or “y’all”, depending on dialect. (The “guys” in this pronoun shouldn’t be confused with the noun “guys”, which is usually only used for boys and men; “you guys” is used to refer to groups of any gender).
For a completely different example, "on" in formal French means something like "one" in English: a pronoun for a general, unspecified person; as such, it takes singular conjugations. However, in colloquial speech, it means "we" and has almost completely replaced "nous" as a subject pronoun.
Thus: "il est" (he is); "on est" (we are, colloquial language); "nous sommes" (we are, standard language)
If you're using a few optimized libraries and designed your code for high-speed parallel execution, the compiled thing becomes almost impossible to trace in a practical manner.
Some of the Matrix and solver code coming from Eigen is heavily optimized for SIMD operations and using it with -O0 is just painful.
Moreover, I had to verify its memory sanity and used Valgrind for that. Using a full size problem meant it had to churn for days to finish execution.
Having deadlines doesn't always help in this stuff.
I also think Perf is phenomenal for its scope. It's showing performance metrics of the code without any processor dependency and instrumentation.
I suspect your broader point stands - certainly "performance is multivarious and means different things in different contexts" has sunk in for me. But I suspect the actual difficulty of reasoning about performance deters most people from doing it beyond big O notation. The fact that I'm aware that performance is complicated doesn't drive me to understand the complexity, I mostly just say "good enough" and move on.
Nothing can hit 200fps at 4K, which you'd need to reach low enough latencies to be imperceptible.
And that's just the phone. I could come up with many more questions regarding desktop and server usage as I'm more familiar with those.
I'm afraid, there is no one optimal set of configuration options. Not even two or three.
Of course on the scale of you or I, such optimisations may be little more than a curiosity most of the time. A process that normally takes 100 minutes (a video transcode, perhaps) now taking 95 followed by the machine being idle while it waits for us to look back and see the result, is not really benefiting from the benefit.
> without actually needing to learn how to change it
This is certainly a problem sometimes, but not an argument for tuning bring overrated in general. It usually comes down to tuning the wrong thing, like someone playing with mysql engine & kernel IO parameters to eek out a fraction of a of % bonus when they could improve index structures, or fix queries with no sargable predicates, or both in unison, to get benefits measured in orders of magnitude.
It can be overrated in the case of average gamers tweaking their hardware to get a few extra FPS on top of the many tens they already get, but again this not being worth the time for some, even many, doesn't mean it can make a huge difference to a pro-gamer or someone using old kit where "a few extra" is a relatively large gain.
But a more modern language would benefit from defining some optimizations like inlining as mandatory, the same way tail calls are (and of course GCC has this.) Then there isn't a chance of deploying a build with extra-slow behavior.
That would average out into a few percentage points of performance improvement in every application across the globe which runs on linux / android. Merging a patch like that in linux would be like quietly reaching into every device across the planet and giving them a small, free CPU improvement and drop in power usage. Not game changing for any individual user, but huge in aggregate.
I heard a story - years ago Google hired an engineer who happened to be an expert from a previous life in video codecs. He wasn’t working on YouTube at Google, but out of interest he pulled up the YouTube source code to see what it did. They were just using the defaults for some of the encoding parameters. He tweaked a few of the encoding parameters and in doing so saved Google millions of dollars per year in compute/storage/network traffic. A few hours of his work was probably more beneficial for Google than years spent in his primary role.
And if tuning opportunities like this abound at Google, you know they’re everywhere. It’d be much better if Linux distributions simply shipped kernels which are already compiled with PGO, with a reasonable profile based on normalish use.
The correct answer would've been for ffmpeg to not ship that way.
Anyway, I am an expert on video codecs just like that guy is, and I said what I said ;)
Running your DB with the default parameters.
Not running Linux kernel parameters depending on your workload. (+10Gbit NICs, lots of connections...)
There are reasons, why those knobs are there, as there are always trade-off, and having them automatically adjust is very hard.
But maybe that was what you're referring to.
I use it to encode my DVD and Blu Ray TV/movies to HEVC. Doing so reduces the filesize on DVD's by roughly 80% and Blu Rays by 60%
The downside is the encoding is an incredibly CPU intensive process. Hardware encoders like Nvidia's Nvenc or Intel's QuicSync look absolutely terrible and are a non-starter for archival storage
On a stock Fedora XFCE install, I would get roughly 0.5 FPS for a 1080p Blu Ray file (29.97 FPS at 1920x1080)
A Gentoo Linux installation with a global -O3 -march=native as well as LTO, PGO and Graphite enabled globally boosts it from 0.5 to roughly 1.3 FPS. Still slower than realtime, but an absolutely massive improvement
When I was using Eigen on my code, the biggest performance boost came from -O3. -march and -mtune did minimal improvements on the systems which I've ran benchmarks on.
OTOH, I'd like to underline that heavily optimized scientific code and libraries are neither naive (in terms of algorithmic complexity/implementation) nor straightforward :D
E.g.: This is how Eigen configures its internal vectorization parameters: https://gitlab.com/libeigen/eigen/-/blob/master/Eigen/src/Co...
I do a probably overkill CRF of 20 just to be safe. But everything looks absolutely perfect, even blown up on my 65 inch (1080p) TV
No hard feelings if you don't want to though :)
Linux future seems bright with regard to performance.
[0] https://lkml.org/lkml/2021/1/11/98
[1] https://lore.kernel.org/lkml/20210608115254.11930-1-sj38.par...
[2] https://lkml.org/lkml/2021/4/27/1208