Kenapa AMD Ryzen Jadi 50 Persen Lebih Cepat dalam Dua Tahun

Selama bertahun-tahun narasi yang beredar soal prosesor adalah stagnasi. Setiap generasi hanya naik belasan persen, arsitekturnya tidak berubah banyak, dan peningkatan utamanya datang dari litografi. Daniel Lemire menguji narasi itu dengan membandingkan tiga prosesor AMD Ryzen 7 yang sebanding: 5800X3D dari keluarga Zen 3, 7800X3D dari Zen 4, dan 9800X3D dari Zen 5. Ketiganya delapan inti dengan 3D V-Cache. Rentang waktunya sekitar dua tahun. Pertanyaannya sederhana: ke mana saja transistor tambahan itu pergi, dan apa efeknya.

Jawaban singkatnya: lompatan terbesar bukan di frekuensi, tapi di lebar mesin. Prosesor ini memang jadi sekitar 50 persen lebih cepat, dan penyebabnya bisa dilacak satu per satu ke keputusan desain yang cukup spesifik.

Tiga Keping yang Dibandingkan

Perbandingan ini rapi karena ketiga keping berada di kelas yang sama. Semuanya Ryzen 7 dengan delapan inti dan 3D V-Cache, jadi perbedaan performa tidak bisa dilempar ke jumlah inti atau ke cache tambahan yang eksklusif di satu model. Yang berubah adalah generasi arsitekturnya, dari Zen 3 ke Zen 4 lalu ke Zen 5.

Angka transistor memberi gambaran pertama. Jumlahnya naik sekitar 50 persen, dari kira-kira 11 miliar menjadi 16 miliar. Yang menarik bukan besarnya kenaikan, tapi distribusinya: sebagian besar transistor ekstra itu masuk ke inti, bukan ke cache. Ini keputusan yang berlawanan dengan cara mudah menaikkan angka benchmark, karena menambah cache biasanya lebih murah dan hasilnya lebih mudah diprediksi.

Melebarkan Bagian Depan Prosesor

Perubahan pertama terlihat di lebar dispatch. Prosesor mendispatch maksimum 6 instruksi per siklus di Zen 3, dan naik menjadi 8 di Zen 5. Dispatch adalah gerbang masuk instruksi ke mesin eksekusi, jadi melebarkan bagian ini berarti lebih banyak pekerjaan bisa masuk ke pipeline per siklus.

Melebarkan gerbang masuk tidak ada gunanya kalau tempat penampung di belakangnya tidak ikut besar. Karena itu reorder buffer juga tumbuh, dari 256 entri menjadi 448 entri. Reorder buffer adalah tempat instruksi menunggu sambil menunggu dependensinya selesai. Buffer yang lebih besar berarti prosesor bisa menyimpan lebih banyak instruksi dalam penerbangan dan menjadwalkannya dengan lebih baik, sehingga lebih tahan terhadap stall akibat satu instruksi yang lambat.

Kombinasi dua perubahan ini menjelaskan sebagian besar peningkatan performa per siklus. Ini jenis peningkatan yang tidak muncul di brosur karena tidak ada angka gigahertz yang bisa dipajang, tapi efeknya terasa di beban kerja yang penuh dependensi dan branch.

Cache dan Unit Integer Bertambah

Perubahan berikutnya ada di hierarki memori dan unit eksekusi integer.

• L2 cache per inti naik dua kali lipat, dari 512 KB menjadi 1 MB.
• L1 data cache naik dari 32 KB menjadi 48 KB.
• Unit integer ALU bertambah dari 4 menjadi 6.

Pola yang terlihat konsisten: semua sumber daya yang sering menjadi bottleneck ikut dilebarkan. Menambah L1 data cache dari 32 KB ke 48 KB mengurangi jumlah akses yang harus turun ke L2, dan menambah ALU dari 4 ke 6 menaikkan throughput untuk kode yang kaya operasi integer. Ditambah reorder buffer yang hampir dua kali lebih besar, mesin ini memang dirancang untuk memproses lebih banyak instruksi secara paralel, bukan sekadar berjalan lebih cepat secara sekuensial.

Zen 5 sebagai Mesin yang Berbeda untuk SIMD

Perubahan paling besar justru ada di jalur data paralel atau SIMD, dan di sini Zen 5 layak disebut mesin yang berbeda, bukan sekadar penyempurnaan.

Zen 3 dan Zen 4 memiliki empat unit aritmetika SIMD berukuran 256 bit. Zen 5 memiliki empat unit berukuran 512 bit. Jalur load dan store melebar dengan cara yang sama: dua load 512 bit per siklus dan satu store 512 bit.

Perbedaan ini penting untuk beban kerja tertentu. Kode yang memproses array besar, kompresi, penyandian, operasi matriks, atau pemrosesan sinyal bisa memanfaatkan lebar 512 bit secara langsung. Untuk kode yang sifatnya skalar dan penuh percabangan, tambahan lebar itu tidak banyak membantu. Artinya, keuntungan generasi ini tidak terdistribusi rata, dan itu penjelasan yang lebih jujur daripada mengklaim semua beban kerja naik 50 persen.

Kesimpulan praktisnya untuk pengembang: kalau pekerjaan kamu berisi loop atas data besar, peningkatan dari Zen 3 ke Zen 5 akan terasa jauh lebih besar daripada yang dijanjikan angka benchmark rata-rata. Sebaliknya, kalau pekerjaan kamu didominasi kode dengan banyak branch dan dependensi berantai, keuntungannya lebih banyak datang dari reorder buffer dan lebar dispatch yang lebih besar, bukan dari SIMD 512 bit.

Kenapa Ini Penting untuk Keputusan Teknis

Ada dua pelajaran yang bisa diambil dari perbandingan ini, dan keduanya berguna di luar konteks memilih CPU.

Pertama, stagnasi sering disimpulkan dari metrik yang salah. Kalau yang dilihat hanya frekuensi clock, prosesor memang terlihat jalan di tempat selama bertahun-tahun. Begitu yang diperiksa adalah lebar dispatch, ukuran reorder buffer, jumlah ALU, dan lebar unit SIMD, gambarannya berubah total. Ini contoh klasik dari masalah metrik proxy: angka yang mudah diukur bergerak lambat, sementara kapabilitas yang sebenarnya berubah cepat. Pelajaran yang sama berlaku di banyak bidang lain, termasuk saat menilai performa perangkat lunak. Waktu eksekusi total bukan satu-satunya sinyal; yang perlu diperiksa adalah di bagian mana waktu itu habis.

Kedua, keuntungan performa hampir selalu bergantung pada beban kerja. Klaim bahwa satu generasi 50 persen lebih cepat hanya bermakna kalau beban kerjanya disebutkan. Untuk kode SIMD dan array besar, keuntungannya bisa besar. Untuk kode yang terikat latensi memori atau I/O, perbedaannya bisa nyaris tidak terasa. Karena itu, sebelum memutuskan upgrade berdasarkan benchmark publik, jalankan beban kerja sendiri dan ukur bagian yang benar-benar menjadi bottleneck. Ini sejalan dengan prinsip yang sama di dunia perangkat lunak: diagnosis dulu di mana batasannya, baru pilih solusinya.

Yang Sedang Datang

Lemire menutup tulisannya dengan catatan bahwa Zen 6 sedang menuju pasaran. AMD membicarakan bagian Epyc bernama Venice dengan 256 inti dan L3 cache sebesar satu gigabyte. Untuk keping desktop, bentuk intinya belum diketahui, dan Lemire menyebutnya bisa jadi liar.

Angka 256 inti dan satu gigabyte L3 cache itu bukan sekadar latihan pemasaran. Kalau tren dua generasi terakhir berlanjut, penambahan besar akan kembali terjadi di sisi lebar mesin dan hierarki cache, bukan hanya di jumlah inti. Untuk tim yang mengelola beban kerja server, ini alasan untuk tidak mengunci keputusan kapasitas jangka panjang berdasarkan asumsi bahwa performa per inti akan tumbuh perlahan.

Bagaimana Perubahan Ini Terasa di Beban Kerja Nyata

Angka spesifikasi tidak otomatis berarti lebih cepat di setiap kasus. Yang menentukan adalah bagian mana dari prosesor yang menjadi bottleneck pada beban kerja tersebut.

Beban kerja yang kaya data dan sedikit percabangan, misalnya pemrosesan array besar, kompresi, penyandian, atau operasi matriks, paling diuntungkan oleh unit SIMD 512 bit dan dua load per siklus. Pada jenis beban ini, peningkatan dari Zen 3 ke Zen 5 bisa terasa jauh lebih besar daripada rata-rata.

Beban kerja yang penuh percabangan dan dependensi berantai lebih banyak mengambil manfaat dari reorder buffer 448 entri dan lebar dispatch 8 instruksi. Bagian ini justru paling sulit diprediksi dari spesifikasi, karena efeknya muncul sebagai pengurangan stall, bukan penambahan throughput mentah.

Beban kerja yang terikat latensi memori dan I/O, misalnya layanan yang menghabiskan sebagian besar waktu menunggu basis data atau jaringan, hampir tidak merasakan perbedaan generasi. Dalam kasus ini, mengganti prosesor bukan solusi untuk masalah yang sebenarnya ada di tempat lain.

Cara Mengukur Sendiri Tanpa Menebak

Langkah paling murah sebelum memutuskan upgrade berdasarkan benchmark publik adalah mengukur beban kerja sendiri. Benchmark publik dirancang untuk menghasilkan angka yang bisa dibandingkan antarprosesor, dan justru karena itu sering tidak mewakili pola akses memori serta percabangan kode nyata.

• Tentukan dulu satu atau dua beban kerja representatif, bukan campuran semuanya.
• Ukur waktu eksekusi dan sekaligus utilisasi CPU, supaya terlihat apakah prosesornya sibuk atau justru menunggu.
• Jalankan beberapa kali dan lihat sebarannya, bukan hanya hasil terbaik.
• Catat penggunaan memori juga, karena keputusan menambah cache bisa memindahkan bottleneck ke kapasitas memori.

Kalau tersedia, profiler bawaan sistem operasi lebih berguna daripada waktu total, karena menunjukkan fungsi mana yang menghabiskan siklus. Tanpa itu, waktu total hanya memberi tahu bahwa sesuatu berubah, bukan apa yang berubah. Pendekatan ini terasa lebih lambat daripada langsung membeli keping termahal, tetapi jauh lebih murah daripada membeli keping yang salah untuk beban kerja yang salah. Kesimpulan yang sama berlaku untuk memilih bentuk instance di penyedia cloud: ukur dulu, baru pilih.

Catatan soal Cache L1 48 KB

Satu detail yang mudah dilewatkan adalah kenaikan L1 data cache dari 32 KB menjadi 48 KB. Ukuran ini bukan angka bulat hasil pemasaran, melainkan kompromi antara kapasitas dan latensi akses. Cache yang lebih besar mengurangi jumlah akses yang harus turun ke L2, tetapi juga memperbesar biaya pencarian di dalamnya.

Praktisnya, kode yang bekerja pada struktur data berukuran sedang, kira-kira di kisaran puluhan kilobyte, paling merasakan manfaatnya. Struktur data yang jauh lebih besar dari kapasitas cache tetap akan sering meleset, dan di situ tambahan 16 KB tidak mengubah banyak. Ini alasan lain mengapa pengukuran sendiri tetap diperlukan sebelum menarik kesimpulan dari daftar spesifikasi.

Kenaikan kapasitas cache juga bukan angka yang berdiri sendiri. Cache yang lebih besar membutuhkan lebih banyak transistor dan area die, dan area itu harus dibayar dengan sesuatu. Dalam kasus ini yang dikorbankan bukan fitur inti, melainkan ruang yang seharusnya bisa dipakai untuk cache tambahan di tingkat lain. Pilihan itu masuk akal untuk beban kerja umum, tetapi tidak selalu optimal untuk beban kerja yang pola aksesnya sangat spesifik.

Sumber

• Daniel Lemire, "How did AMD Ryzen get 50% faster in two years?", Daniel Lemire's blog, 18 September 2026: https://lemire.me/blog/2026/09/18/how-did-amd-ryzen-get-50-faster-in-two-years/
• Tulisan rujukan sebelumnya oleh penulis yang sama, "How stagnant is CPU technology?", sebagaimana disebutkan dalam artikel di atas.

Untuk konteks lain soal performa perangkat keras, ada juga catatan benchmark filesystem yang bisa jadi pembanding metodologi: benchmark Btrfs, ZFS, dan Bcachefs.