Most active commenters
  • joefourier(4)
  • satysin(4)

←back to thread

1080 points antipaul | 21 comments | | HN request time: 1.473s | source | bottom
Show context
satysin ◴[] No.25069364[source]
This is very interesting and in line with Apple's claims. I am looking forward to some real world numbers for different tasks in the next few weeks and months as native apps become available.

Jonathan Morrison posted a video [0] comparing a 10-core Intel i9 2020 5K iMac with 64GB RAM against an iPhone 12 Mini for 10-bit H.265 HDR video exporting and the iPhone destroyed the iMac exporting the same video, to allegedly the same quality, in ~14 seconds on the iPhone vs 2 minutes on the iMac! And the phone was at ~20% battery without an external power source. Like that is some voodoo and I want to see a lot of real world data but it is pretty damn exciting.

Now whether these extreme speed ups are limited to very specific tasks (such as H.265 acceleration) or are truly general purpose remains to be seen.

If they can be general purpose with some platform specific optimisations that is still freakin' amazing and could easily be a game changer for many types of work providing there is investment into optimising the tools to best utilise Apple Silicon.

Imagine an Apple Silicon specific version of Apple's LLVM/Clang that has 5x or 10x C++ compilation speed up over Intel if there is a way to optimise to similar gains they have been able to get for H.265.

Some very interesting things come to mind and that is before we even get to the supposed battery life benefits as well. Having a laptop that runs faster than my 200+W desktop while getting 15+ hours on battery sounds insane, and perhaps it is, but this is the most excited I have been for general purpose computer performance gains in about a decade.

[0] https://www.youtube.com/watch?v=xUkDku_Qt5c

Edit:

A lot of people seem to just be picking up on my H.265 example which is fine but that was just an example for one type of work.

As this article shows the overall single-core and multi-core speeds are the real story, not just H.265 video encoding. If these numbers hold true in the real world and not just a screenshot of some benchmark numbers that is something special imho.

replies(2): >>25069400 #>>25069658 #
1. joefourier ◴[] No.25069400[source]
Your h265 example is due to the iPhone having a dedicated HW encoder while the iMac was rendering using the CPU. A hardware video encoder is almost always going to be faster and more power efficient than a CPU-based one by definition. However, a CPU encoder offers more flexibility and the possibility of being continually improved to offer better compression ratios.

Generally, HW encoders offer worse quality at smaller fie sizes and are used for real-time streaming, while CPU-based ones are used in offline compression in order to achieve the best possible compression ratios.

replies(3): >>25069422 #>>25069459 #>>25070290 #
2. gjsman-1000 ◴[] No.25069422[source]
OK... but let's say I'm a professional. That's a big sell. Having dedicated HW to do something faster than CPU is a bonus, not cheating.
replies(3): >>25069443 #>>25069451 #>>25069557 #
3. majewsky ◴[] No.25069443[source]
Well yeah, for that one use case. But you cannot go from "X is 20% faster than Y at H265" to "X is 20% faster than Y at doing computer stuff".
4. joefourier ◴[] No.25069451[source]
You already have HW encoder blocks on certain CPUs and most GPUs. See: Intel Quicksync, Nvidia NVENC and AMD Video Core Next. Support for them will of course depend on your platform and the applications you are using. IIRC, video editing software will generally use HW decoding for smooth-real time playback, but use CPU-encoding for the final output.
5. satysin ◴[] No.25069459[source]
Yes but that is kind of the point. Going forward all Apple Silicon machines will have this kind of hardware baked into the SoC at no extra cost whereas no Intel system (be it PC or Mac) will.

That is a big deal as it means Adobe, Sony, BlackMagic, etc. will be able to optimise to levels impossible to do elsewhere. If that 8x speed up scales linearly to large video projects you would have to have a Mount Everest sized reason to stick to PC.

replies(5): >>25069510 #>>25069516 #>>25069531 #>>25069585 #>>25069686 #
6. chungus_khan ◴[] No.25069510[source]
That's not really true. Every modern Intel, AMD, and Nvidia GPU does actually include hardware to accelerate encoding video, it's just that software solutions end up being preferred in a lot of cases because they produce better output and can be continually improved.

A large body of encoding software is however, perfectly capable of taking advantage of them.

The comparison is kind of silly.

replies(1): >>25069605 #
7. fluffything ◴[] No.25069516[source]
> all Apple Silicon machines will have this kind of hardware backed into the SoC at no extra cost whereas no Intel system (be it PC or Mac) will.

First of all, adding this hardware encoder to the Apple Silicon chips definetly has a cost, and you pay it when you buy their products.

Second, there are Intel CPUs available with hardware encoders (google Intel QuickSync). The only difference is that you can choose to not pay for it if you don't need it.

8. joefourier ◴[] No.25069531[source]
As said below, you already have that HW in many Intel CPUs and all AMD/Nvidia GPUs.

Dedicated HW for specific computing applications are nothing new, back in the 90s you had dedicated MJPEG ASICs for video editing. Of course, they became paperweights the moment people decided to switch to other codecs (although the same thing could be said for 90s CPUs given the pace of advancement back then).

Thing is, your encoding block takes up precious space on your die, and is absolutely useless for any other application like video effects, color grading, or even rendering to a non-supported codec.

9. rkangel ◴[] No.25069557[source]
Absolutely. But how many of those hardware blocks exist for what you want to do? If you care about H265, great. Let's say you get a dozen specific hardware accelerators, that's still only 12 tasks. That might end up covering the vast majority of web browsing tasks (to pick one example), but particularly as an engineer there is always going to be something else. And not all intensive tasks are amenable to hardware acceleration, e.g. compilation. That's why we care about general purpose CPU performance - at some point you always need it.

Incidentally, this is philosophically the idea behind processors with built in FPGA capability. The hardware acceleration would just be a binary blob that could be loaded in and used when necessary. It could be continually updated, and provided with whatever software needed it.

replies(1): >>25069733 #
10. ◴[] No.25069585[source]
11. satysin ◴[] No.25069605{3}[source]
> The comparison is kind of silly.

I disagree. Sure we have things like NVENC for accelerated H.265 encoding but that is an additional hardware expense and means only the machines you have that hardware in benefits. This will literally be all Macs from a $699 Mini and up.

I don't know enough about Intel QuickSync to compare but it clearly isn't used on the iMac in that video for some reason (perhaps the software does not support it? I don't know)

That is pretty exciting for video professionals IMHO.

I'm not saying it is world changing but being able to pick up a MacBook Air for $999 and get performance similar (or maybe better?) than a PC that costs two or three times that with dedicated hardware is very cool.

edit:

I appear to be missing why this is a ridiculous thing to say?

Could somebody please explain to me why the comparison is "silly"?

replies(4): >>25069651 #>>25069770 #>>25070706 #>>25070899 #
12. ◴[] No.25069651{4}[source]
13. danmaz74 ◴[] No.25069686[source]
Specialised silicon is always going to be more efficient than general purpose silicon, but you lose in flexibility. Don't expect this kind of performance gains across the board.
14. AnthonyMouse ◴[] No.25069733{3}[source]
Not only that, what happens over time? Not long ago the hardware accelerated codec would have been H.264. Soon it could be AV1. We're already at the point that professionals could want to be using AV1.
15. joefourier ◴[] No.25069770{4}[source]
At the risk of going in circles, let me try to explain one last time:

All modern GPUs already have HW-accelerated encoding, including integrated Intel GPUs, and Nvidia and AMD dedicated ones.

Despite that, HW-encoding is not used that much by video professionals because CPU encoders produce better compression given enough time. You only have to do compression once, while the video will be watched who knows many times, therefore there is no real point in making your encoding faster if the file size goes up.

Your HW encoder is absolutely useless for anything else. It does not make your FX rendering faster, and cannot be used for any other codecs.

Even if say, your HW matches CPU-based encoder at first, it is fixed and cannot be updated unless you buy new HW which takes millions to design. Meanwhile any old dev can contribute to x265 and figure out new psychovisual enhancements that will enhance the quality while minimising the file size.

Specialized HW (i.e. ASICs) has been in existence for decades, yet despite that, there are very good reasons as to why we still use general-purpose CPUs (and GPUs) for most computing applications.

replies(2): >>25069864 #>>25071554 #
16. satysin ◴[] No.25069864{5}[source]
Thanks for clarifying. That makes a lot more sense so perhaps not as exciting as Jon makes out in his video.
17. Joeri ◴[] No.25070290[source]
You see the same order of magnitude differences between encoding 8-bit H265 on the 2020 imac vs 2019 imac. The T2 in the 2020 imac has hardware encoding ability for 8-bit H265.

Now, the thing is: intel's AVX512 instructions are supposed to accelerate this sort of work, but in practice they are getting lapped by the T2 chip. That signals that apple's ability to tune hardware designs to the needs of content creators is greater than intel's.

18. Bayart ◴[] No.25070706{4}[source]
The way hardware encoding works is to be focused on a small set of specific presets with little flexibility for the end user. It's fine for hobbyists, streaming etc. but nobody's going to use it for a professional render.
19. CedarMadness ◴[] No.25070899{4}[source]
People (especially video professionals) tend to not use QuickSync because the quality is pretty low and you have very limited ability to tune the results. It's optimized for real time encoding and not high quality or small file sizes. I think on H.264 it's about equivalent to the x264 veryfast preset, no clue how the H.265 quality stacks up, only the more recent Intels even support that. NVENC has better quality, but still a software two-pass encode will give much better results.

It's the same on these phone chips, sure the encode is much quicker, but it's not a fair comparison because you have much more control over the process using software. We'll have to wait and see how the quality and file size on the M1 encoder stacks up.

20. dbspin ◴[] No.25071554{5}[source]
Editor / videographer here. Interested in those claims.

Hardware encoded H.264 and H.265 don't have any visual quality differences when encoded at the same bitrates in the same containers, as far as I'm aware. Could you list a source for this?

Have never heard of any client or production house requesting an encoding method specifically. Although granted I work at the low end of commercial shooting.

replies(1): >>25074336 #
21. chungus_khan ◴[] No.25074336{6}[source]
This is widely known and inherent to how hardware encoders work. They are limited by complexity and cannot be improved after they are manufactured, so most of the focus for them generally goes into real time applications. You can check out the blog for the x265 software encoder if you want some examples of the sort of regular improvements that get made:

http://x265.org/blog/

The reason these sorts of improvements are possible is because most of the power of a video encoder doesn't come from the container format but rather how effectively the encoder selects data to keep and discard in keeping with that container format. There is also a LOT of tuning that can be done depending on the kind of content that is being encoded, etc.

For high end work basically nobody uses hardware encoders on the final product.