Yeah 7000-series Ryzen benefits from the avx512 code paths in ffmpeg. I've benchmarked a 5900x vs a 7900x specifically for software H.265 decoding and there was a sizeable difference.
chellomere
For example, maybe branching is something you'd like to be able to do without it being a nightmare?
I think if they just filled the alt= attribute with the emoji this would copy fine.
European here, I suggest Bosch or Electrolux, if that's available in your part of the world.
Jeans in the dryer? They'll definitely shrink that way.
I think you commented on the wrong post Edit: nevermind, these are spam links that they bypass the spam filter by starting with some random text.
separate processor with hundreds of cores
Well, graphics rendering is very suited for parallelism. That's why GPUs were invented.
Most other tasks are not. Most of the cores in a 128-core JPU would end up being unused. Also why JPU? It's not like it's significantly different from a normal CPU task.
They meant the command dtrx, the combination of dtrx as parameters to tar make no sense. Extract AND append?
Then comes a .tar.bz2 file along and you're screwed. xtract je vucking file?
Pro tip: -z, -j are not needed by tar anymore since many years, tar will autodetect what compression was used if your distro is anything remotely modern.
They actually call the android releases "cookies" because of this tradition for the code names. You can read phrases like "This will be fixed in the next cookie"
This is great, but the context is that this is for specific inner loops, and it is compared to the C version of that specific inner loop. Typically what was used before this on a computer with avx512 was the avx2 version of the inner loop, and the speedup compared to that version appears to be up to 60%: https://x.com/FFmpeg/status/1852542388851601913 . Then as not a specific inner loop isn't run all the time, the speedup is probably much less than 60%. This is still sizeable, but the actual speedup in practice with this implementation is far far from 94x.