Gusar - maybe it was true once upon a time........not necessarily anymore. Compilers have been improving all the time.
Announcement
Collapse
No announcement yet.
RAV1E: The "Fastest & Safest" AV1 Encoder
Collapse
X
-
Decoding speed seems to be good, at least the test video works great in Firefox https://demo.bitmovin.com/public/firefox/av1. Sure, it would be great if AV1 can convert videos on demand for streaming from normal hardware very fast, but for now I'm more interested in the compression efficiency of the videos itself. If I can safe a reasonable amount of disk space then I can safe network bandwidth as well with AV1.
- Likes 2
Comment
-
Compiler optimization focuses on lower level stuff as that's the most of what the compiler "intelligence" can deal with, but if you actually understand the logic, the goals of the software, you can do much more.
Compilers will have to become specialist AI software for this gap to lessen significantly.
For example, some assembler optimizations in a recent software here gave a x2.5 speed improvement over what the compiler can do https://www.phoronix.com/scan.php?pa...-Optimizations
Or hand-written functions for the Glibc giving around 50% performance improvement on hardware supporting newer instructions (instead of assuming that the compiler will do it right if compiled with -march=native for newer hardware, as it won't) https://www.phoronix.com/scan.php?pa...ath-Glibc-2.27
- Likes 2
Comment
-
starshipeleven - But, software for distributions is generally not compiled with march=native (leaving aside Gentoo, and Clear Linux). So, that's why they add such code in glibc, x264, x265 so that the optimized versions can be used where needed, but portability is maintained.
- Likes 1
Comment
-
Originally posted by sandy8925 View Poststarshipeleven - But, software for distributions is generally not compiled with march=native (leaving aside Gentoo, and Clear Linux). So, that's why they add such code in glibc, x264, x265 so that the optimized versions can be used where needed, but portability is maintained.
Assembler optimizations aren't about using instructions the compiler does not know about, but about optimizing the code beyond what the compiler can do.
Comment
-
Originally posted by sandy8925 View PostIt seems stupid to depend on hand written assembly for faster encoding/decoding. Wouldn't compiling with march=native and mtune=native take you atleast part of the way there? (If not all the way)
Anyone who says a compiler will "outsmart" a human when optimizing has absolutely *no* idea what he is talking about (yes, this is one of those myths I truly despise because they're flung around by morons who don't want to learn assembly and use it as an excuse as to why they don't -- they want it to be true, but it doesn't mean it is).
It's not the compiler's fault, necessarily though. It's also the programmer's and (usually) the project manager.
For some reason, a lot of idiots won't accept "hacky" HLL solutions or trying to coerce a compiler into generating optimal code. It takes a lot of "nasty" and "unclear" hand-holding to make the compiler generate proper code (because it just cannot guess what you want to do, no matter how "smart" it is, it has to follow reproducible rules and not guess, compilers are NOT magic).
But you see, those managers accept assembly where it matters, but won't accept "ugly" C code despite the fact it's probably more readable than asm (in some cases). Because they want to keep HLL code "stupidly easy to understand for monkeys". Yuck.
It's rare to see gems like the algos from Hacker's Delight still used. When I see that, I respect that project a lot.
Comment
-
Also note that some GCC devs flat-out refuse patches that would improve optimizations if they take a significant amount of compilation time. So half the reason compilers won't match a human is because they won't give an option for people who want to use all optimizations and expensive compilation for the best possible code. Thinking that compilers "always improve" in terms of code generation is a myth. In some cases they even regress, to "simplify" the compiler internally. Yes, I find it appalling, but w/e.
I'm not bashing GCC, it's still the best compiler, just wish they had a more open attitude for people who don't mind spending hours to compile a small project with maximum optimizations. Meh. LLVM is even worse and clearly optimizations are not their priorities. Sigh.Last edited by Weasel; 16 July 2018, 07:43 AM.
- Likes 1
Comment
-
Originally posted by starshipeleven View PostNo it's not. march=native does not make the compiler optimize better, it only tells the compiler that it can use instructions offered by the actual hardware. This of course improves performance as the compiler can use better instructions, but it's not the point of hand-optimized assembler, and why such optimizations are still better.
This is mostly about low level stuff like the peculiarities of a particular CPU (i.e. pipelining, fusing, branch prediction and whatever). Just instruction scheduling, usually.
- Likes 1
Comment
-
Because somebody has to make the Spongebob reference: "Rav1e-oli, Rav1e-oli, give me the sourcecode-oli."
Originally posted by Grinch View PostI recall reading that Google split up the videos in chunks and encode them in single thread modes across huge clusters, and I would imagine the same holds true for Netflix/Amazon, meaning there's no pressing need for them to improve multi-threaded encoding.
Originally posted by Weasel View PostWah VP9 doesn't cover my niche use cases, must be useless garbage.
All mainstream OSes don't handle some critical but extremely niche use cases. They must be useless garbage also.
Which is why I've stuck to VP8 for that.Last edited by mulenmar; 16 July 2018, 02:13 PM.
- Likes 1
Comment
-
This thread reminds me of doing mp3 encoding overnight for cds in 1995, clearly mp3 is so unusably slow.
At least part of the reason h264/h265 encoding is currently fast is that the hardware has specific accelerated encoding features for them that the encoding software uses.
Comment
Comment