Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

chrisebert.net

Post reply on HN
Print view View original

21–30 of 60 posts

Re: Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

#21

Post by ajross »

greatgib wrote: post #17

I would not be surprised that Rust be faster than Python, but looking at the code of his Benchmarks, I'm not sure that it really means anything. For example, the "light" test will do calls to "dynamodb". Maybe you benchmark python, or you benchmark the aws sdk implementation with different versions of python, or just you benchmark average dynamodb latencies at different times of the day, ... And, at least for Python,…

Yeah, having a native binary be only 2x faster than CPython, or CPython showing 4x (!!) advantage vs. V8 seems really suspicious. This benchmark suite is probably good for looking at CPU architecture deltas on identical source code (which seems to be what it was good for), but trying to intuit language/runtime behavior from it seems very dangerous.

Re: Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

#22

Post by anentropic »

ju-st wrote: post #3

Would be interesting to add a cold start + "import boto3" benchmark for Python as importing boto3 takes forever on lambdas with little memory. For this scenario I only know this benchmark but it is from 2021 https://github.com/MauriceBrg/aws-blog.de-projects/tree/mast...

if imports are slow one should probably look into pre-compiling .pyc files into the Lambda bundle

Re: Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

#23

Post by bobmcnamara »

tybit wrote: post #2

It’s interesting that the author chose to use SHA256 hashing for the CPU intensive workload. Given they run on hardware acceleration using AES NI, I wonder how generally applicable it is. Still interesting either way though, especially since there were reports of earlier Graviton (pre v3) instances having mediocre AES NI performance.

Does AES NI imply SHA256 acceleration support?

Re: Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

#24

Post by torginus »

PhilipRoman wrote: post #16
evilmonkey19 wrote: post #5

Can someone tell me why there isn't almost any laptop with Linux and ARM? Is it more efficient than x86 though

How is the bootloader/peripheral compatibility on the non-SBC ARM systems these days? Can you plug in a boot disk on different machine and expect it to just work? My main problem with ARM is that many manufacturers act as if they're special little snowflakes and deserve to have their custom patched kernel/bootloader/whatever.

Afaik a lot of bootloaders are proprietary/wonky, a lot of SOCs run custom bootloaders.

However if you do manage to boot things up, hardware with open-source drivers should just work, for example Jeff Geerling has couple of videos on youtube about running his RPi with external AMD graphics cards connected via PCIe, and it works.

Re: Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

#25

Post by torginus »

greatgib wrote: post #17

I would not be surprised that Rust be faster than Python, but looking at the code of his Benchmarks, I'm not sure that it really means anything. For example, the "light" test will do calls to "dynamodb". Maybe you benchmark python, or you benchmark the aws sdk implementation with different versions of python, or just you benchmark average dynamodb latencies at different times of the day, ... And, at least for Python,…

I think the 'light' workload is the most realistic - most people use lambda as a stateless CRUD backend/REST endpoint, I don't think doing heavy number crunching is that idiomatic inside a lambda.

And for that use case, Python seems almost as good as Rust, which is surprising to me, as is the fact that Node runs so slow - I have a ton of Node-based lambdas in prod, and while they're no speed demons, I'm quite surprised how bad it is compared to even interpreted things like Python.

AWS should really look into this and fix it, or at least tell us why it's so slow.

Re: Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

#27

Post by torginus »

ju-st wrote: post #3

Would be interesting to add a cold start + "import boto3" benchmark for Python as importing boto3 takes forever on lambdas with little memory. For this scenario I only know this benchmark but it is from 2021 https://github.com/MauriceBrg/aws-blog.de-projects/tree/mast...

I don't really use Python, but most AWS SDKs seem to be autogenerated for each language, and they're pretty much just thin wrappers over REST calls to interal AWS endpoints.

I dunno why a Python impl would be particularly heavy.

Re: Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

#28

Post by schmidtleonard »

ZiiS wrote: post #26

This is benchmarking `hashlib.sha256` isn't that normally OpenSSL's heavily hand optimized assembly implementation, certainly isn't something written in Python?

I think that's the CPU benchmark rather than the python benchmark -- and comparing CPU ARM64 vs x86_64 seems worthwhile.

Re: Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

#29

Post by kbolino »

bobmcnamara wrote: post #23
tybit wrote: post #2

It’s interesting that the author chose to use SHA256 hashing for the CPU intensive workload. Given they run on hardware acceleration using AES NI, I wonder how generally applicable it is. Still interesting either way though, especially since there were reports of earlier Graviton (pre v3) instances having mediocre AES NI performance.

Does AES NI imply SHA256 acceleration support?

There are some crossed wires here.

AES-NI is x86-specific terminology. It was proposed in 2008. SHA acceleration came later, announced in 2013. The original version covers only SHA-1 and SHA-256 acceleration, but a later extension adds SHA-512 acceleration. At least for x86, AES-NI does not imply SHA support. For example, Westmere, Sandy Bridge, and Ivy Bridge chips from Intel have AES-NI but not SHA.

The equivalent in Arm land is called "Cryptographic Extensions" and was a non-mandatory part of ARMv8 announced in 2011. Both AES and SHA acceleration were announced at the same time. While part of the same extensions, there are separate feature flags for each of AES, SHA-1, and SHA-256.

Re: Comparing AWS Lambda ARM64 vs. x86_64 Performance Across Runtimes in Late 2025

#30

Post by torginus »

abhashanand1501 wrote: post #8

One of the easiest hack to reduce your AWS bills is to migrate from x86 to arm64 CPU. Performance difference is negligible, and cost can be upto 50% lower for arm machines. This is for both RDS and general compute (EC2, ECS). Would recommend to all.

I'd say the best price/performance hack on AWS if you don't need web scale is just put your stuff on a tiny EC2 instance, like a t3.micro - it'll be likely faster and more flexible than lambda with much more predictable performance.

You can scale up by changing out to a bigger instance - it's surprising how far you can get with this strategy.

Post reply on HN