Lambda, FFmpeg, Graviton2 vs Intel: Switch or Stick?
AWS yesterday announced the option to run Lambda functions on their Arm/Graviton2 architecture, offering instant performance boost and cost reduction with almost no code changes. Sounds too good to be true? We put this claim to a test using CPU-intensive video conversion.
The AWS announcement suggested Graviton2 benefits for Lambda as “up to 19 percent better performance at 20 percent lower cost”, effectively behind just a simple configuration switch. Narakeet makes it easy to create narrated videos from markdown scripts, using latest generation text-to-speech neural engines. Under the hood, it uses AWS Lambda for video processing with FFmpeg, so we wanted to jump at the opportunity to speed up user workflows and reduce cost. But I’m sceptical of corporate announcements, so before switching, I decided to try it out. The results surprised me.
The official announcement mentions that duration charges for Graviton2 are 20 percent lower than the current pricing for x86. Lambda is charged in proportion to maximum memory multiplied by the task duration. (Maximum memory also controls the CPU, with 10240 MB correlating to 6 CPU cores). So in practice, more memory = faster CPU. In theory, if the same task runs on both architectures, and Graviton is less than 20% slower than Intel, there is a cost benefit to switch.
For the test, I set up an S3 bucket and two Lambda functions. The functions use the same source code, but run on different architectures and execute a statically built FFmpeg binary for the target processor. Both functions get triggered by any file uploaded to the S3 bucket, resample it using FFmpeg to 720p, and output the duration of the FFmpeg job (ignoring lambda startup and s3 file download time). The file conversion runs on the Lambda temporary file system.
I tested the conversion using two videos, one small and one relatively large. The first was already 720p, roughly 4MB in size, from our Spanish voice test. The second is much larger, 184 MB (3840x2160), sourced from https://www.pexels.com/video/close-up-video-of-a-river-6172942/.
For both the larger and the smaller video, Intel Lambdas were consistently faster. With more memory (more CPU in fact), the difference was larger, and from 2 VCPU onwards the difference in speed was more than 20%.
The tables below have detailed figures, with columns showing maximum memory allowed, and cells listing the time in milliseconds it took for the FFmpeg task to complete (so smaller is better).
|Graviton2 / Intel Percent||121.78%||118.38%||125.54%||120.60%|
|Graviton2 / Intel Percent||118.51%||119.37%||122.53%||123.27%|
Switch or Stick?
For now, we’re staying on Intel for CPU intensive flows. The fact that FFmpeg runs worse on Graviton2 than on Intel is a massive downside, as it would make video production slower for our users. Graviton tasks seem to be roughly 20% slower, negating any financial benefits from cheaper pricing, and our Lambda costs are pretty low anyway.
So what happened here? Why is there such a difference between the official announcement and these results? I can only guess that FFmpeg can benefit from AVX2 instructions in Lambda Intel architectures, so the old platform seems to be better for this use case.
Run your own test
In conclusion, make sure to run tests on your own workflows and tasks, and check if the promised benefits are actually there. I’ve published the code used for this test on GitHub so you can easily modify it for your tasks and run relevant tests.
Cover photo by Fidel Fernando on Unsplash.