Live data from Hacker News

FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

tomshardware.com

31–40 of 138 posts

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#31

[flagged]

It doesn't matter. This is inherently better because the dev knows exactly what is being done. Llms could cripple entire systems with assembly access

You could run it in a loop, asking it to improve the code each time. I know what the ffmpeg devs have done is impressive, but I would be curious to know if something like Claude 4 Opus could make any improvements.

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#32
post #7

Earlier quoted context omitted.

> I wonder how many optimisations like this could be created by LLMs Zero. There's no huge corpus of stackoverflow questions on highly specific assembly optimisations so…

There are literally textbooks on optimization. With tons of examples. I'm sure there are models out there trained on them.

There are literally textbooks on computational theory, with tons of example proofs. I'm sure there are models trained on them. Why hasn't ChatGPT produced a valid P vs. NP proof yet?

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#33
Kind of reminds me of Sound Open Firmware (SOF), which can compile with e8ther unoptimized gcc, or using the proprietary Cadence XCC compiler that can can use the Xtensa HiFi SIMD intrinsics.

https://thesofproject.github.io/latest/introduction/index.ht...

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#35
post #32

Earlier quoted context omitted.

There are literally textbooks on optimization. With tons of examples. I'm sure there are models out there trained on them.

There are literally textbooks on computational theory, with tons of example proofs. I'm sure there are models trained on them. Why hasn't ChatGPT produced a valid P vs. NP proof yet?

I'm just countering their claim that such code is not in the training data.

You're employing a logical fallacy to argue about something else.

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#36

Earlier quoted context omitted.

Pretty much all instructions at the assembly level are sequences of AND/OR/XOR operations. SAT solvers can prove that some (shorter) sequences are equivalent to other (longer) sequences. But it takes a brute force search. IIRC, these super optimizing SAT solvers can see patterns and pick 'Multiply' instructions as part of their search. So it's more than traditional SAT. But it's still... At the end of the day.... A S…

A short look at any compiled code on godbolt will very quickly inform you that pretty much all instructions at the assembly level are, in fact, NOT sequences of AND/OR/XOR operations.

[dead]

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#37
Actually a bit surprised to hear that assembly is faster than optimized C. I figured that compilers are so good nowadays that any gains from hand-written assembly would be infinitesimal.

Clearly I'm wrong on this; I should probably properly learn assembly at some point...

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#38
Article is unclear what will actually be affected. It mentions "rangedetect8_avx512" and calls it an obscure function. So, what situations is it actually used for, and what is the real-time improvement in performance for the entire conversion process?

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#40
post #31

Earlier quoted context omitted.

It doesn't matter. This is inherently better because the dev knows exactly what is being done. Llms could cripple entire systems with assembly access

You could run it in a loop, asking it to improve the code each time. I know what the ffmpeg devs have done is impressive, but I would be curious to know if something like Claude 4 Opus could make any improvements.

That can work with inefficient languages like Python, but not raw Assembly.
Post reply on HN