Kembali pada bulan Oktober AMD mengirimkan pengaktifan Zen 4 "znver4" awal mereka untuk kompiler GCC. Dukungan Zen 4 awal itu sejak digabungkan untuk GCC 13 tetapi pengaktifan awal itu membawa tabel biaya dari Zen 3 dan tidak melakukan banyak hal dalam cara penyetelan melainkan hanya membalik instruksi baru yang didukung oleh seri Ryzen 7000 dan EPYC prosesor seri 9004. Hari ini akhirnya ada beberapa tambalan menarik yang dikirim untuk GCC. Dikirim hari ini adalah satu set tambalan penyetelan awal untuk dukungan Zen 4 dengan GCC, termasuk tabel biaya untuk mencerminkan biaya instruksi pada prosesor Zen 4 daripada hanya meneruskan biaya lama dari Zen 3. Sementara para insinyur AMD mengirimkan tambalan Znver4 awal pada bulan Oktober, pekerjaan penyetelan GNU Compiler Collection ini dilakukan oleh para insinyur SUSE. Di masa lalu, para insinyur SUSE telah mengambil beberapa pekerjaan dan penyetelan pemberdayaan Zen, yang lagi-lagi menjadi kasusnya. AMD dan SUSE telah lama bermitra sejak mengerjakan kompiler GCC hingga hari-hari driver RadeonHD ketika mereka memulai upaya driver open-source AMD hingga berbagai kolaborasi open-source lainnya selama bertahun-tahun. pengembang kompiler GCC

Longtime Jan Hubicka dari SUSE mengirimkan bagian 1 dengan pembaruan tabel biaya untuk Zen 4. Jan mengomentari pekerjaan itu: tambalan ini memperbarui biaya znver4 sebagian besar berdasarkan data yang diukur oleh Agner Fog. Dibandingkan dengan generasi sebelumnya x87 menjadi sedikit lebih lambat yang mungkin bukan masalah besar (dan kami memiliki cakupan pembandingan minimal untuk itu). Salah satu peningkatan yang menarik adalah pengurangan biaya FMA. Saya juga memperbarui biaya pemuatan/penyimpanan AVX256 berdasarkan latensi (bukan throughput yang dua kali lipat dari avx256). Keseluruhan vektorisasi AVX512 tampaknya meningkatkan secara nyata beberapa tolok ukur TSVC tetapi karena secara internal 512 vektor dibagi menjadi 256 vektor, ini agak berisiko dan tidak menang dalam skor SPEC (kebanyakan dengan meregresi tolok ukur dengan loop yang memiliki jumlah perjalanan kecil seperti x264 dan pertukaran), jadi untuk saat ini saya akan menyetel tune AVX256_OPTIMAL tetapi saya masih memainkannya. Kami meningkatkan sejak ZNVER1 dalam memilih ukuran vektorisasi dan juga memiliki prolog/epilog yang divektorisasi sehingga dimungkinkan untuk membuat kemenangan kecil avx512 secara keseluruhan. Secara umum saya ingin menjaga latensi tabel biaya berdasarkan kecuali kami memiliki alasan kuat untuk tidak melakukannya. Ada beberapa perbedaan menarik dalam tabel znver3 yang juga saya tambal dan tampaknya kinerjanya netral. Saya akan mengirimkannya secara terpisah. Bootstrap/regtested x86_64-linux, juga mengacu pada SPEC2017 bersama dengan tuning AVX512. Saya berencana untuk melakukannya besok kecuali ada beberapa komentar.Jan menindaklanjuti beberapa saat setelah itu dengan tambalan bagian dua untuk bendera penyetelan baru: tambalan ini menambahkan nada yang diperlukan untuk mikroarsitektur zen4. Saya menambahkan dua kenop baru. TARGET_AVX512_SPLIT_REGS yang digunakan untuk menentukan bahwa secara internal 512 vektor dibagi menjadi 256 vektor. Ini memengaruhi biaya vektorisasi dan lebar reasosiasi. Ini mungkin juga mempengaruhi biaya RTX namun saya ragu ini sangat berguna karena pengoptimal RTL biasanya tidak menilai antara 256 dan 512 vektor. Saya juga menambahkan X86_TUNE_AVOID_256FMA_CHAINS. Karena fma telah meningkat di zen4, bendera ini mungkin bukan kemenangan kecuali untuk tolok ukur yang sangat spesifik. Saya masih melakukan beberapa pengujian yang lebih rinci di sini. Sebaliknya saya menonaktifkan pengumpulan di zen4 untuk 2 bagian dan 4 bagian. Kami dapat membuka kodenya dan karena latensi hanya meningkat sejak opencoding zen3 lebih baik daripada instruksi sebenarnya. Ini menunjukkan pada 4 tolok ukur tsvc. Saya akhirnya mengatur AVX256_OPTIMAL. Ini adalah kompromi. Ada beberapa tolok ukur tsvc yang meningkat secara nyata (hingga 250%) namun ada juga sedikit regresi. Sebagian besar dapat diselesaikan dengan meningkatkan biaya vec_perm di vektorizer. Namun ini tidak menyembuhkan regresi sekitar 14% pada x264 yang cukup penting. Di sini kami menghasilkan loop vektor untuk avx512 yang mungkin akan lebih cepat jika loop tersebut memiliki jumlah iterasi yang cukup tinggi. Kami menemukan masalah ini dengan avx256 juga: karena perulangan berulang beberapa kali, hanya prolog/epilog yang digunakan. Menambahkan putaran kode prolog/epilog lagi tidak membuatnya lebih baik. Akhirnya saya mengaktifkan penyimpanan avx untuk memcpy dan memset berukuran konstan. Saya tidak yakin mengapa ini adalah fitur keikutsertaan. Saya pikir untuk sebagian besar perangkat keras ini adalah kemenangan. Dia melihat untuk mendapatkan patch tuning Znver4 ini segera digabungkan untuk GCC 13. Rilis stabil GCC 13.1 akan keluar pada bulan Maret ~ April dengan dukungan Zen 4 awal ini - versi yang sama di mana Intel dengan tambalan pengaktifan kompiler mereka yang lebih tepat waktu memperkenalkan Grand Ridge dan Granite Rapids, Meteor Lake, dan CPU baru lainnya serta ekstensi set instruksi jauh sebelum peluncuran CPU daripada setelah fakta. Bagi mereka yang menginginkan dukungan kompiler yang dioptimalkan saat ini untuk prosesor seri Ryzen 7000 dan EPYC 9004 "Genoa", kompiler AMD AOCC 4.0 tersedia dalam bentuk biner dengan dukungan kompiler Zen 4 yang dioptimalkan.

Itulah berita seputar Tabel Biaya AMD Zen 4 & Tambalan Tuning Diposting Untuk Kompiler GCC, semoga bermanfaat. Disadur dari Phoronix.com.