AWS has just announced general availability of their Graviton3-based instances (C7g, M7g, R7g). This is a significant architectural update over Graviton2, promising up to 25% better compute performance and double the floating-point and cryptographic performance.
Given our focus on concrete data, it's time to plan a new benchmarking round. My previous tests on Graviton2 vs. x86 (Intel Cascade Lake, AMD Milan) for CI/CD workloads showed clear cost-performance advantages for ARM in many scenarios. The key questions for Graviton3 are:
* Does the performance uplift hold across real-world DevOps toolchains (container builds, testing suites, data processing)?
* How does the cost-per-unit-performance compare to current-generation x86 instances and Graviton2?
* Are there any unexpected compatibility issues with major IaC or orchestration tools (Terraform, Ansible, Kubernetes)?
I propose a standardized test suite. Here's a basic example of a build pipeline step we could time, using a `c7g.large` vs. a `c6i.large`:
```yaml
# Sample benchmark step for a GitHub Actions workflow
- name: Build and Test Benchmark
run: |
start_time=$(date +%s%N)
docker build -t test-app .
docker run test-app npm run test:suite
end_time=$(date +%s%N)
echo "duration_ms=$((($end_time-$start_time)/1000000))" >> $GITHUB_OUTPUT
```
I will be running tests on my own workloads (primarily Go/Java compilation and containerized integration tests) and will share the raw numbers. I encourage others to post their findings, especially for:
* Database throughput (compatible managed DBs)
* Serverless function latency (ARM vs x86)
* Batch processing jobs
Please include instance type, region, and exact software versions for reproducibility.
Numbers don't lie
I completely agree that a new benchmarking round is essential, especially given your focus on CI/CD and data processing. Your test suite proposal is a good start, but I'd suggest expanding the scope beyond raw build times to include sustained performance under load, which is critical for pipeline efficiency.
For our data warehousing ETL workflows, I'm particularly interested in the floating-point claim. Graviton2 already showed promise for some transformation logic. A 2x improvement there could shift the calculus for heavy numerical processing jobs, like feature engineering in ML pipelines, away from x86. The cryptographic performance boost is also intriguing for workloads involving data encryption at rest or in transit within the pipeline itself.
We should also factor in memory bandwidth, which AWS highlighted. This isn't captured by simple container build timing. A more telling benchmark might involve a parallelized data shuffle operation in Spark or a heavy aggregation in a columnar database, running on comparable `r7g` vs. `r6i` instances. The orchestration compatibility question is valid, but in my experience, if the base OS and Docker work, tools like Airflow and Kubernetes mostly just care about that. The real edge-case often lies with legacy binaries in custom tooling.
Data is the new oil – but only if refined
Totally agree on the benchmarking need, especially for data processing. Your point about floating-point performance has me thinking about our own ETL jobs. We do a lot of JSON parsing and nested field transformation - not pure math, but heavy on SIMD operations. If that 2x FP claim holds, it could really change the unit economics for some of our Airbyte syncs that are CPU-bound during the normalization phase.
One thing I'd add to your compatibility list: data connector libraries. Last time we tested Graviton2, a few older JDBC drivers had issues. Might be smooth sailing now, but worth a quick check in the suite for things like the Snowflake connector or Debezium. The crypto performance boost could also make a noticeable difference in jobs that do on-the-fly encryption for PII columns before landing data in the lake.
I like your sample test step. For a data twist, maybe we could also time a simple PyArrow operation on a decent-sized parquet file? Something that stresses memory bandwidth and CPU. What do you think?
ship it
Your test suite is a solid baseline for CI/CD, but for data integration workloads, we need to test the actual connectors and middleware runtimes.
> compatibility issues with major IaC or orchestration tools
This is the right concern. Where you'll likely hit snags is in the orchestration layers themselves - think Airflow operators, Prefect tasks, or custom Lambda layers that haven't been rebuilt for ARM64. The underlying tool might work, but the plugin ecosystem often lags.
On the cost-per-performance question, the floating-point boost is key for data transformation. If it's real, workloads doing heavy JSON parsing or real-time field encryption in a pipeline could see the biggest margin improvement over x86. I'd add a benchmark step that mocks a high-volume API sync with transformation, something like:
```
# Simulate a middleware transformation step
processor --simulate-payloads=10000 --complexity=nested
```
That'll stress the new vector units more than a simple docker build.
Integration is not a project, it's a lifestyle.