Remix.run Logo
BoingBoomTschak 4 hours ago

I think software with a strong focus on SIMD really favours x86 over Apple, since AVX2 support was pretty uniform and AVX-512 (except Intel's fiasco) has been supported for a while, while the post-NEON landscape is strange in ARM country.

From what I've been able to gather, Apple only supports SME and the small "streaming" part of SVE2 required by SME since the M4. Which seems to be mostly useless for video encoding (I only see NEON/SVE in https://gitlab.com/AOMediaCodec/SVT-AV1/-/tree/master/Source... or https://github.com/Multicorewareinc/x265/tree/master/source/...) it's basically a GEMM engine.

So basically, video encoding is a bad show for Apple who seem to be saying "use crappy hardware encoding and buy amd64 if you need more".

Very hard to find benchmark data. Found https://openbenchmarking.org/vs/Processor/Apple+M4+Pro,AMD+R... that shows a good x265 performance at 1080p but not 4K. Guess the wider SIMD units matter more there.

GeekyBear 4 hours ago | parent | next [-]

> So basically, video encoding is bad show for Apple

Apple has dedicated hardware for video decode and encode for several video formats.

That's why the comparisons between PCs and Macs running video editing software favor the Macs so heavily.

BoingBoomTschak 4 hours ago | parent [-]

HW and SW encoding are not comparable with regard to quality (for the same size, obviously) though. That's kinda what I meant with my quip.

GeekyBear 4 hours ago | parent [-]

Nothing prevents a vendor from implementing a high quality hardware encoder, just as nothing prevents the creation of a low quality software encoder.

Video editing is an area that Apple dominates because PCs become a laggy mess on complicated high resolution edits.

AMD has started to copy the same strategy with the recent Ryzen AI chips. They include hardware video encode/decode units as well as unified memory.

BoingBoomTschak 2 hours ago | parent [-]

> Nothing prevents a vendor from implementing a high quality hardware encoder

Uh yes, it's called reality. Advanced video coding techniques are just too complex, full of serial and branch heavy algos to work in decently sized and priced ASIC or even in GPGPU. Which is the reason none exists outside of very expensive special stuff for professional render/streaming farms.

Not even mentioning that few coding tools are shared between codecs, so while you only need 1 CPU to handle all of them, you'd need almost an ASIC per codec...

GeekyBear 24 minutes ago | parent [-]

If your claim is true, you won't have any trouble finding reputable tech publications saying that the video output from Apple M series hardware is substandard in some way.

I'll wait.

I would recommend you find a floor plan for Apple's M series chips and take a look at how big Apple's media engine is.

api 4 hours ago | parent | prev [-]

X64 does have a stronger SIMD story, but this is partly compensated for by the fact that ARM64 is much easier to decode wide. M series has a very wide decoder and a lot of instruction level parallelism. It can turn chunks of those 128-bit SIMD operations into what amounts to wider operations.

AVX still wins though.

M series still wins on performance per watt and now apparently leads on general purpose code.

All these leading edge chips are very good. We have an embarrassment of riches when it comes to blistering fast chips here.

Archit3ch an hour ago | parent [-]

> AVX still wins though.

On what, microbenchmarks? I have realtime audio workloads where the hot loop is essentially linear algebra. Exactly the kind of work that suits AVX2/AVX512. Guess what, Apple Silicon still pulls ahead because real workloads are branchy, cache-hungry, full of dependencies and do not line up in 8 neat f64 operations per cycle.