Would be interesting to see a benchmark with the rust binary with successively more “bloat” in the binary to separate out how much of the cold start is app start time vs app transfer time. It would also be useful to have the c++ lambda runtime there too; I expect it probably performs similarly to rust.
Tangent: when you have a lambda returning binary data, it’s pretty painful to have to encode it as base64 just so it can be serialized to json for the runtime. To add insult to injury, the base64 encoding is much more likely put you over the response size limits (6MB normally, 1MB via ALB). The c++ lambda runtime (and maybe rust?) lets you return non-JSON and do whatever you want, as it’s just POSTing to an endpoint within the lambda. So you can return a binary payload and just have your client handle the blob.
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...
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.
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.
If you don’t mind me asking, what do you think of that laptop? What kind of workloads do you run and how is battery life? What OS? Would you choose it again?
> Node.js: Node.js 22 on arm64 was consistently faster than Node.js 20 on x86_64. There's essentially a “free” ~15-20% speedup just by switching architectures!
Not sure why this is phrased like that in the TL;DR, when ARM64 is just strictly faster when running the same nodejs workload and version.
Would be interesting to see a benchmark with the rust binary with successively more “bloat” in the binary to separate out how much of the cold start is app start time vs app transfer time. It would also be useful to have the c++ lambda runtime there too; I expect it probably performs similarly to rust.
Tangent: when you have a lambda returning binary data, it’s pretty painful to have to encode it as base64 just so it can be serialized to json for the runtime. To add insult to injury, the base64 encoding is much more likely put you over the response size limits (6MB normally, 1MB via ALB). The c++ lambda runtime (and maybe rust?) lets you return non-JSON and do whatever you want, as it’s just POSTing to an endpoint within the lambda. So you can return a binary payload and just have your client handle the blob.
What I don't get is why is it that Node is dog slow. Seriously it seems borderline unusable.
In terms of perf, Node has a pretty snappy JIT, and seems to perform OK in the browser, but this seems like something's not right here.
~200ms requests even in the light case are on the very brink of barely acceptable.
On the other hand, Python performs very well, but it's alarming to see it gets slower in every release by a significant margin.
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...
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.
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.
Can someone tell me why there isn't almost any laptop with Linux and ARM? Is it more efficient than x86 though
Software/driver compatibility and rational fear of change from users.
(My work laptop is one of the few ARM laptops: Thinkpad T14s with Quallcomm Snapdragon Elite)
If you don’t mind me asking, what do you think of that laptop? What kind of workloads do you run and how is battery life? What OS? Would you choose it again?
Was trying to install Linux on it, though its not working like a standard x86 laptop (for the installer on debian for example).
Battery is good, hardware is really rock solid (though I dislike the new plastic for the keyboard).
Really can’t complain, it’s nearly as good as my Macbook.
It runs Windows 11 today, and everything I need runs fine (jetbrains, rustc, clang, msvc, terraform and of course python).
I’m a technical CTO with infrastructure background, most of my time is spent in spreadsheets these days unfortunately.
Chromebooks are essentially this, but not that great for local development.
Depends on which one, and what you want to locally develop.
Is there one that even has a full keyboard?
> Node.js: Node.js 22 on arm64 was consistently faster than Node.js 20 on x86_64. There's essentially a “free” ~15-20% speedup just by switching architectures!
Not sure why this is phrased like that in the TL;DR, when ARM64 is just strictly faster when running the same nodejs workload and version.