Groups | Search | Server Info | Login | Register
Groups > comp.os.linux.misc > #86634
| Message-ID | <6a0510b6@news.ausics.net> (permalink) |
|---|---|
| From | not@telling.you.invalid (Computer Nerd Kev) |
| Subject | Re: The Stupidification Of systemd Haters |
| Newsgroups | comp.os.linux.misc |
| References | (4 earlier) <10tvbbj$1vrb3$1@dont-email.me> <wwvtsscd14a.fsf@LkoBDZeT.terraraq.uk> <10u07tq$29ejq$1@dont-email.me> <502edmx1hk.ln2@Telcontar.valinor> <10u22vt$2odeg$4@dont-email.me> |
| Date | 2026-05-14 10:00 +1000 |
| Organization | Ausics - https://newsgroups.ausics.net |
Rich <rich@example.invalid> wrote:
> Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 2026-05-13 00:00, Rich wrote:
>> If you do some task that is heavy on cpu, say, recoding a video with
>> ffmpeg, then it would be ffmpeg that would need rebuilding, not the
>> kernel. I can not think now of a task that puts the kernel CPU load at 100%.
>
> Yes, apply the "careful optimizing" to the programs that actually
> benefit. But, as pointed out by R.K., ffmpeg is one of the
> applications that compiles with the "include the various optimizations,
> select the appropriate code path at runtime based upon CPU executing
> the process" so it is already mostly ready to take advantage of what it
> finds in the CPU it is using at the time.
Huh, I didn't know that. I couldn't find documentation about it,
but indeed the assembly functions like in
libavfilter/x86/af_anlmdn.asm are called conditional on a macro
that seems to check CPU capabilities set by functions in
libavutil/cpu.c at run-time.
eg. libavfilter/x86/af_anlmdn_init.c
30 int cpu_flags = av_get_cpu_flags();
31
32 if (EXTERNAL_SSE(cpu_flags)) {
33 s->compute_distance_ssd = ff_compute_distance_ssd_sse;
34 }
With related files:
libavutil/cpu.h
libavutil/cpu.c
libavutil/cpu_internal.h
libavutil/x86/cpu.h
libavutil/x86/cpu.c
Most specifically ff_get_cpu_flags_x86() in libavutil/x86/cpu.c
does the actual capabilities checking for that.
Is that "fairly straightforward today" like RK said? I'd say
writing optimised code in assembly and decoding CPU-specific
capabilities identifiers to decide at run-time whether it can be
used is really pretty full-on compared to just letting the compiler
build pure C code optimised for one specific CPU. Also not much
easier today than any time since the CPUID instruction was
introduced for x86 with the Pentium 1. Did he mean some programming
languages or libraries have a better way than that now?
Heck it looks like it's actually got very complicated over the
years, FFmpeg have had to deal with stuff like this:
libavutil/x86/cpu.c
186 if (!strncmp(vendor.c, "AuthenticAMD", 12)) {
187 /* Allow for selectively disabling SSE2 functions on AMD processors
188 with SSE2 support but not SSE4a. This includes Athlon64, some
189 Opteron, and some Sempron processors. MMX, SSE, or 3DNow! are faster
190 than SSE2 often enough to utilize this special-case flag.
191 AV_CPU_FLAG_SSE2 and AV_CPU_FLAG_SSE2SLOW are both set in this case
192 so that SSE2 is used unless explicitly disabled by checking
193 AV_CPU_FLAG_SSE2SLOW. */
194 if (rval & AV_CPU_FLAG_SSE2 && !(ecx & 0x00000040))
195 rval |= AV_CPU_FLAG_SSE2SLOW;
Eight confusing special-cases like that just for x86.
But anyway, good to see someone bothered to do that work for
FFmpeg. I'd have assumed I would benefit significantly from
compiling FFmpeg myself if I had fancy hardware and needed the
performance (shouldn't they mention this in INSTALL.md?). That
might still depend on whether most of the possible manual
optimisation work has indeed been done for the architecture you're
using (impossible to tell without benchmarking?).
> The benefits of "custom optimized compiles for your specific setup",
> while still technically present, have narrowed vs. the "generic distro
> version" that there is often not enough actual gain to be had to
> justify the effort of "recompiling a specific version" anymore.
Yet many distros themselves are choosing to drop support for eg.
x86_64-v1 (and later) so they can compile software better optimised
for newer CPUs.
--
__ __
#_ < |\| |< _#
Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar
The Stupidification of GNU/Linux Users Leroy H <lh@somewhere.net> - 2026-05-11 19:00 +0000
Re: The Stupidification of GNU/Linux Users The Natural Philosopher <tnp@invalid.invalid> - 2026-05-11 20:10 +0100
Re: The Stupidification of GNU/Linux Users "s|b" <me@privacy.invalid> - 2026-05-12 18:11 +0200
Re: The Stupidification of GNU/Linux Users The Natural Philosopher <tnp@invalid.invalid> - 2026-05-13 12:38 +0100
Re: The Stupidification of GNU/Linux Users Andy Burns <usenet@andyburns.uk> - 2026-05-11 20:12 +0100
Re: The Stupidification Of systemd Haters Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-11 22:47 +0000
Re: The Stupidification Of systemd Haters c186282 <c186282@nnada.net> - 2026-05-11 22:42 -0400
Re: The Stupidification Of systemd Haters Rich <rich@example.invalid> - 2026-05-12 13:52 +0000
Re: The Stupidification Of systemd Haters Richard Kettlewell <invalid@invalid.invalid> - 2026-05-12 17:49 +0100
Re: The Stupidification Of systemd Haters Rich <rich@example.invalid> - 2026-05-12 22:00 +0000
Re: The Stupidification Of systemd Haters rbowman <bowman@montana.com> - 2026-05-13 04:47 +0000
Re: The Stupidification Of systemd Haters The Natural Philosopher <tnp@invalid.invalid> - 2026-05-13 12:43 +0100
Re: The Stupidification Of systemd Haters rbowman <bowman@montana.com> - 2026-05-13 17:40 +0000
Re: The Stupidification Of systemd Haters Rich <rich@example.invalid> - 2026-05-13 14:41 +0000
Re: The Stupidification Of systemd Haters "Carlos E.R." <robin_listas@es.invalid> - 2026-05-13 12:56 +0200
Re: The Stupidification Of systemd Haters The Natural Philosopher <tnp@invalid.invalid> - 2026-05-13 12:56 +0100
Re: The Stupidification Of systemd Haters Rich <rich@example.invalid> - 2026-05-13 14:52 +0000
Re: The Stupidification Of systemd Haters "Carlos E.R." <robin_listas@es.invalid> - 2026-05-13 22:24 +0200
Re: The Stupidification Of systemd Haters The Natural Philosopher <tnp@invalid.invalid> - 2026-05-14 10:34 +0100
Re: The Stupidification Of systemd Haters Rich <rich@example.invalid> - 2026-05-13 14:48 +0000
Re: The Stupidification Of systemd Haters "Carlos E.R." <robin_listas@es.invalid> - 2026-05-13 22:25 +0200
Re: The Stupidification Of systemd Haters not@telling.you.invalid (Computer Nerd Kev) - 2026-05-14 10:00 +1000
Re: The Stupidification Of systemd Haters Richard Kettlewell <invalid@invalid.invalid> - 2026-05-14 10:00 +0100
Re: The Stupidification Of systemd Haters The Natural Philosopher <tnp@invalid.invalid> - 2026-05-14 10:45 +0100
Re: The Stupidification Of systemd Haters Richard Kettlewell <invalid@invalid.invalid> - 2026-05-14 11:25 +0100
Re: The Stupidification Of systemd Haters The Natural Philosopher <tnp@invalid.invalid> - 2026-05-14 11:38 +0100
Re: The Stupidification Of systemd Haters Richard Kettlewell <invalid@invalid.invalid> - 2026-05-14 12:28 +0100
Re: The Stupidification Of systemd Haters The Natural Philosopher <tnp@invalid.invalid> - 2026-05-14 12:40 +0100
Re: The Stupidification Of systemd Haters Richard Kettlewell <invalid@invalid.invalid> - 2026-05-14 11:16 +0100
Re: The Stupidification Of systemd Haters The Natural Philosopher <tnp@invalid.invalid> - 2026-05-14 10:42 +0100
Re: The Stupidification Of systemd Haters Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-14 01:12 +0000
Re: The Stupidification Of systemd Haters Richard Kettlewell <invalid@invalid.invalid> - 2026-05-14 10:09 +0100
Re: The Stupidification Of systemd Haters "Carlos E.R." <robin_listas@es.invalid> - 2026-05-14 12:54 +0200
Re: The Stupidification Of systemd Haters "Carlos E.R." <robin_listas@es.invalid> - 2026-05-12 18:55 +0200
Re: The Stupidification Of systemd Haters rbowman <bowman@montana.com> - 2026-05-12 22:19 +0000
Re: The Stupidification Of systemd Haters Rich <rich@example.invalid> - 2026-05-13 14:56 +0000
Re: The Stupidification Of systemd Haters rbowman <bowman@montana.com> - 2026-05-13 17:45 +0000
Re: The Stupidification Of systemd Haters The Natural Philosopher <tnp@invalid.invalid> - 2026-05-13 18:50 +0100
Re: The Stupidification Of systemd Haters Rich <rich@example.invalid> - 2026-05-13 19:09 +0000
Re: The Stupidification Of systemd Haters "Carlos E.R." <robin_listas@es.invalid> - 2026-05-13 22:34 +0200
Re: The Stupidification Of systemd Haters Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-13 21:34 +0000
Re: The Stupidification Of systemd Haters Rich <rich@example.invalid> - 2026-05-13 19:06 +0000
Re: The Stupidification of GNU/Linux Users Rich <rich@example.invalid> - 2026-05-11 21:41 +0000
Re: The Stupidification of GNU/Linux Users Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2026-05-11 14:59 -0700
Re: The Stupidification of GNU/Linux Users rbowman <bowman@montana.com> - 2026-05-12 03:53 +0000
Re: The Stupidification of GNU/Linux Users c186282 <c186282@nnada.net> - 2026-05-12 00:39 -0400
Re: The Stupidification of GNU/Linux Users rbowman <bowman@montana.com> - 2026-05-12 23:02 +0000
Re: The Stupidification of GNU/Linux Users c186282 <c186282@nnada.net> - 2026-05-12 20:49 -0400
Re: The Stupidification of GNU/Linux Users makendo <makendo@makendo.invalid> - 2026-05-12 12:47 +0800
Re: The Stupidification of GNU/Linux Users c186282 <c186282@nnada.net> - 2026-05-12 01:26 -0400
csiph-web