Apples new M1 microprocessor

[Cerebus]

I presume in testing HandBrake you're avoiding the hardware accelerated video encoding options (the ones that name "VideoToolbox" in the encoding option)?

[brucehoult]

I don't know anything about Handbrake. I was asked to try it. We used the "Fast 480p30" preset under "General".

[Cerebus]

I don't know anything about Handbrake. I was asked to try it. We used the "Fast 480p30" preset under "General".

That uses a software H.264 compressor so you're good. That gives ~ 86 fps here on a 2018 Macbook Pro (from a 1080p25 source, so a little unfair making it do rate adaption). Switch to hardware assisted encoding, but with otherwise identical settings and it goes at around 100 fps. Both quite disappointing as my usual hardware assisted H.265 encoding to 720p25 from 1080p25 usually flies along close to 200 fps.

[bd139]

I’m waiting for a stable M1 build of Resolve before I even look at this. AFAIK ffmpeg doesn’t support the native codec in the CPU, merely “hardware acceleration”. My iPad is the scary thing. In LumaFusion it can export from a 4K source down to 1080p H265 faster than my ryzen in Resolve. Doesn’t even get warm on a 5 min video.

[DiTBho]

What about FinalCut ARM/M1?

[bd139]

Costs actual money 

[borjam]

I guess the Final Cut test will be distorted by their own Metal optimized GPU anyway.

I mean, substantially improved but it will make comparisons irrelevant.

[bd139]

Well the application specific CPUs are what we're paying for really.

[Mr. Scram]

I expect i could make a pretty good count of the x86 cores in this house. 32 in my Linux PC, 6 in the AMD 4500U laptop, 4 in the 2017 NUC, 4 in the 2011 MacBook Pro, 2 in the 2011 MacBook Air, 4 in the i7 4790K Linux machine I haven't turned on in five years. That's probably all.

ARM .. I wouldn't even know how to make an estimate.

Sure, I maybe know how many cores are in the M1 Mac, iPhone SE, iPhone 7, Apple Watch, Pi4, Pi3, Pi2, Pi1, Pi Zero, Odroid C3, Odroid XU4, Arty Z7 (ARM cores embedded in an FPGA), Blue Pill, Nucleo.

At least I know the main cores. But there can be others doing auxiliary tasks.  I've heard on good authority that x86 chips have an ARM core or two inside.

But what about my multimeter? Oscilliscope? Pulse Oximeter? Amplified speakers? 4K monitor? Ethernet switch? Wifi router? MIcrowave oven? Dishwasher? And I'm sure a host of things I've not thought of right now. They might have ARM cores in them -- or maybe PIC or AVR or MIPS.

I have over 40 RISC-V cores in my house. By mid January it will be over 50 as the Icicle FPGA board and HiFive Unmatched will bring 5 each.


I think it was Horace Dediu who said that in the 1950s people knew exactly how many electric motors they had in their house, but by the late 1970s or 1980s no one had any idea how many they had. And in the 1970s and 1980s people kew exactly how many CPU cores they had in their house.

Don't forget things like HDD and SSD controllers and various other auxiliary and helper chips. Those are ARM chips, generally multiple cores. Just an X86 computer has a zoo of ARM cores on board.

[Mr. Scram]

I’m waiting for a stable M1 build of Resolve before I even look at this. AFAIK ffmpeg doesn’t support the native codec in the CPU, merely “hardware acceleration”. My iPad is the scary thing. In LumaFusion it can export from a 4K source down to 1080p H265 faster than my ryzen in Resolve. Doesn’t even get warm on a 5 min video.

You could argue that hardware acceleration is, in a sense, adding the instructions and complexity which ARM aims to avoid back in. X86 isn't great because it's efficient, it's great because it does many things reasonably well.

Tacking all kinds of auxiliary onto an ARM core only works with tight integration and control over your ecosystem. I'm interested how that pans out when it all becomes old enough to have to deal with legacy compatibility, although it's probably a matter of pushing older hardware out the back and saying "tough shit!" to the owners as Apple tends to do.

[brucehoult]

Don't forget things like HDD and SSD controllers and various other auxiliary and helper chips. Those are ARM chips, generally multiple cores.

Both Western Digital (two years ago) and now this week Seagate have said they are moving to RISC-V for their storage controllers.

[bd139]

I’m waiting for a stable M1 build of Resolve before I even look at this. AFAIK ffmpeg doesn’t support the native codec in the CPU, merely “hardware acceleration”. My iPad is the scary thing. In LumaFusion it can export from a 4K source down to 1080p H265 faster than my ryzen in Resolve. Doesn’t even get warm on a 5 min video.

You could argue that hardware acceleration is, in a sense, adding the instructions and complexity which ARM aims to avoid back in. X86 isn't great because it's efficient, it's great because it does many things reasonably well.

Tacking all kinds of auxiliary onto an ARM core only works with tight integration and control over your ecosystem. I'm interested how that pans out when it all becomes old enough to have to deal with legacy compatibility, although it's probably a matter of pushing older hardware out the back and saying "tough shit!" to the owners as Apple tends to do.

Well the beauty of operating systems and programming interfaces should make that issue moot. The machine’s objective is to fill that higher level API and provide utility to the end user. Whether that uses a generic processor or an application specific processor or how it implements that should be part of the device trade off of cost, die size, power usage etc.

If you use that API and they release new hardware then you get instant advantage.

As for longevity and support I expect 5 years out of a piece of hardware but usually sell it after 2. As for support it has some costs. I recently helped sort out an 8 year old core 2 duo machine running windows 10. Yuck not living in that world ever again. I’d be in a care home by the time it got anything done. Old macs are just as bad but that’s mostly because 2013ish stuff had rust disks.  In six years things should be interesting as I reckon current generation kit is still going to be pretty excellent (until we start getting webassembly shit to deal with  )

[bd139]

Another article with benchmarks: https://tech.ssut.me/apple-m1-chip-benchmarks-focused-on-the-real-world-programming/

Incidentally I'm not upgrading my Ryzen now. It's going now I've finished GTA V and Watchdogs Legion . This is by far the most pleasant computer I've used for years. I am mostly using Go, Visual Studio Code, terraform, Lens and doing a bunch of AWS admin. No Windows any more.

[bd139]

Noticed the Rosetta translation on startup here which was interesting. Not much lag on a 4 meg go binary (this is just returning in the entrypoint)

Still no complaints!

[brucehoult]

If the first run is slow because of Rosetta translation then why does it use only 2% CPU?

It's loading the binary from disk to disk cache, not Rosetta.

[bd139]

It’s a good question. However it literally just compiled that in a separate terminal window so I’d expect it to already have the blocks from the disk in memory after writing through a few seconds before. 300ms is fairly slow to pull 4 meg off an SSD as well.

I’ll have Go 1.16 (beta) with native Darwin/arm64 tomorrow so will compare.  Need to work out how to grab it without breaking my existing install first.

[brucehoult]

OK, dynamic linking then.

Or ... ::black hat on:: ... checking the app signature against a blacklist on the internet.

[bd139]

It’s static linked.

Your second point may be on the mark though. Will test tomorrow.

[magic]

You mean, tin foil hat?

[olkipukki]

Well I bought an ass end M1 mac mini. Arriving Thursday from Amazon. Have someone lined up to buy it off me for £650 if I'm not happy with it already

Sorry to say but looks like overpaid a lot   

https://youtu.be/eACEHVceYl0?t=61

[bd139]

That’s $628 now. Pretty close to reality. 

Ironically in 1994, the same year as that video, I blew every penny I had on an actual ARM desktop machine. It was an Acorn RiscPC 600. 32Mhz 4MB RAM and 210Mb hard disk.

[Marco]

AFAIK ffmpeg doesn’t support the native codec in the CPU, merely “hardware acceleration”.

On the other hand, the hardware encoder is almost certainly significantly inferior to libx265.

[AntiProtonBoy]

False equivalency. You are essentially comparing hardware accelerated H.264 (QSV) with H.265. Of course it's going to be significantly inferior in every respect. This is also true if you compare high quality H.264 encoding schemes with H.265. It's more constructive to draw comparisons between H.264 QSV and non-hardware accelerated H.264 codecs.

[tooki]

Apple’s SOCs have supported hardware H.265 encoding since 2014.

[Marco]

False equivalency. You are essentially comparing hardware accelerated H.264 (QSV) with H.265. Of course it's going to be significantly inferior in every respect. This is also true if you compare high quality H.264 encoding schemes with H.265. It's more constructive to draw comparisons between H.264 QSV and non-hardware accelerated H.264 codecs.

It has H.265 hardware encoding too and the post I responded to was talking about H.265.

That said, I'm sure the hardware H.264 encoding is significantly inferior to libx264 too.