Mempercepat penggandaan matriks 4x4 dengan SIMD

Bertahun-tahun telah berlalu sejak saya berkenalan dengan instruksi MMX, SSE, dan kemudian AVX pada prosesor Intel. Pada suatu waktu, mereka tampak seperti semacam sihir dengan latar belakang assembler x86, yang telah lama menjadi sesuatu yang biasa. Mereka sangat mengaitkan saya sehingga beberapa tahun yang lalu saya memiliki ide untuk menulis perender perangkat lunak saya sendiri untuk satu permainan terkenal. Hal yang menjanjikan instruksi ini menjanjikan saya hal ini. Pada titik tertentu, saya bahkan berpikir untuk menulisnya. Tetapi menulis teks ternyata jauh lebih rumit daripada kode.

Saat itu, saya ingin menghindari masalah dengan dukungan pada prosesor yang berbeda. Saya ingin dapat memeriksa penyaji saya pada jumlah maksimum yang tersedia. Saya masih punya teman dengan prosesor AMD lama, dan langit-langit mereka adalah SSE3. Oleh karena itu, pada saat itu saya memutuskan untuk membatasi diri hingga maksimum SSE3. Jadi ada perpustakaan matematika vektor, sedikit kurang sepenuhnya diimplementasikan pada SSE, dengan inklusi langka sebelum SSE3. Namun, pada titik tertentu saya bertanya-tanya kinerja maksimum apa yang bisa saya peras dari prosesor untuk sejumlah operasi matematika vektor kritis. Salah satu operasi tersebut adalah dengan mengalikan float 4 matriks dengan 4.


Sebenarnya, saya memutuskan untuk melakukan bisnis ini lebih demi hiburan. Saya sudah menulis dan telah menggunakan perkalian matriks untuk perenderan perangkat lunak saya di SSE dan tampaknya sudah cukup bagi saya. Tetapi kemudian saya memutuskan untuk melihat berapa banyak ukuran yang bisa saya peras pada prinsipnya dengan mengalikan 2 matriks float4x4. Pada SSE saya saat ini, ini adalah 16 siklus clock. Benar, transisi terakhir ke IACA 3 mulai menunjukkan 19, karena saya mulai menulis 1 * untuk beberapa instruksi daripada 0 *. Rupanya sebelumnya itu hanya cacat pada alat analisa.

Secara singkat tentang utilitas yang digunakan

Untuk analisis kode, saya menggunakan utilitas Intel Architecture Code Analyzer yang terkenal. Untuk analisis saya menggunakan arsitektur Haswell (HSW), sebagai minimum dengan dukungan untuk AVX2. Untuk menulis kode juga sangat mudah digunakan: Intel Intrinsics Guide dan manual optimasi Intel .

Untuk perakitan saya menggunakan Komunitas MSVS 2017 dari konsol. Saya menulis kode dalam versi dengan intrinsik. Anda menulis sekali, dan biasanya itu langsung berfungsi pada platform yang berbeda. Selain itu, kompiler x64 VC ++ tidak mendukung inline assembler, tapi saya ingin itu bekerja di bawah x64 juga.

Karena artikel ini sudah agak melampaui level pemula dalam pemrograman SIMD, saya tidak akan menjelaskan register, instruksi, menggambar (atau mencukur) gambar yang indah dan mencoba untuk belajar pemrograman menggunakan instruksi SIMD. Situs web Intel penuh dengan dokumentasi yang luar biasa, jelas, dan terperinci.

Saya ingin membuat segalanya lebih mudah ... Tapi ternyata seperti biasa

Di sinilah saat dimulainya, yang menyulitkan banyak implementasi dan artikel. Karena itu, saya akan sedikit membahasnya. Tidak menarik bagi saya untuk menulis perkalian matriks dengan tata letak baris elemen standar. Siapa yang membutuhkannya, dan mereka belajar di universitas atau sendiri. Tujuan kami adalah produktivitas. Pertama, saya beralih ke tata letak kolom sejak lama. Perender perangkat lunak saya didasarkan pada API OpenGL dan oleh karena itu, untuk menghindari transposisi yang tidak perlu, saya mulai menyimpan elemen dalam kolom. Ini juga penting karena perkalian matriks tidak begitu kritis. Matikan 2-5-10 dikalikan dengan baik. Dan itu dia. Dan kemudian kita mengalikan matriks jadi dengan ribuan atau jutaan titik. Dan operasi ini jauh lebih kritis. Anda tentu saja dapat mengubah posisi setiap waktu. Tapi kenapa, kalau ini bisa dihindari.

Tetapi kembali ke matriks secara eksklusif. Kami menentukan penyimpanan dalam kolom. Namun, ini bisa menjadi lebih rumit. Lebih nyaman bagi saya untuk menyimpan elemen senior dari vektor dan baris matriks dalam register SIMD sehingga x berada di float tertinggi (indeks 3), dan w di bawah umur (indeks 0). Di sini, tampaknya, kita harus mundur lagi tentang alasannya.

Faktanya adalah bahwa dalam perender perangkat lunak dalam vektor, Anda harus memanipulasi komponen w lebih sering ( 1 / z disimpan di sana), dan sangat mudah untuk melakukan ini melalui versi _ss operasi (operasi secara eksklusif dengan komponen dalam float yang lebih rendah dari register xmm ), tanpa menyentuh x, y, z . Oleh karena itu, dalam register SSE, vektor disimpan dalam urutan yang dapat dimengerti x, y, z, w , dan dalam memori dalam w, z, y, x terbalik.

Lebih lanjut, semua opsi multiplikasi juga diterapkan oleh fungsi individual. Ini dilakukan karena saya menggunakannya untuk menggantikan opsi yang diinginkan tergantung pada jenis instruksi yang didukung. Dijelaskan dengan baik di sini.

Kami menerapkan fungsionalitas dasar

Perkalian dengan loop, baris dipesan

Semuanya sederhana dan jelas di sini. Untuk setiap elemen kami melakukan 4 perkalian dan 3 tambahan. Secara total, ini adalah 64 perkalian dan 48 tambahan. Dan ini tanpa memperhitungkan pembacaan elemen rekaman.

Singkatnya, semuanya menyedihkan. Untuk opsi ini, untuk siklus internal, IACA mengeluarkan: 3.65 siklus clock untuk rakitan x86 dan 2.97 jam untuk rakitan x64 . Jangan tanya kenapa angka pecahan. Saya tidak tahu. IACA 2.1 tidak menderita dari ini. Bagaimanapun, angka-angka ini harus dikalikan dengan sekitar 4 * 4 * 4 = 64. Bahkan jika Anda mengambil x64, hasilnya adalah sekitar 192 tindakan. Jelas bahwa ini adalah perkiraan kasar. Saya tidak melihat titik mengevaluasi kinerja lebih akurat untuk opsi ini.

Implementasi looping, kolom dipesan

Penggandaan siklus, penyimpanan berorientasi SIMD

Implementasi ini agak menyederhanakan pemahaman tentang apa yang terjadi di dalam, tetapi jelas tidak cukup.

Kelas pembantu

Untuk kenyamanan memahami dan menulis referensi dan kode debug, lebih mudah untuk mengimplementasikan beberapa kelas tambahan. Tidak lebih, semuanya hanya untuk pengertian. Saya perhatikan bahwa implementasi penuh vektor dan matriks kelas adalah pertanyaan sulit yang terpisah, dan tidak termasuk dalam topik artikel ini.

Fungsi referensi untuk tes

Karena urutan elemen yang diterima dalam matriks mempersulit banyak pemahaman, kami juga tidak akan terganggu oleh fungsi referensi yang dapat dimengerti , yang akan menunjukkan dalam implementasi di masa depan bahwa semuanya bekerja dengan benar. Kami akan membandingkan hasil selanjutnya dengan itu.


Algoritma klasik dilukis dengan jelas di sini, sulit untuk membuat kesalahan (tetapi Anda dapat :-)). Di atasnya, IACA mengeluarkan: ukuran x86 - 69,95, ukuran x64 - 64 . Berikut adalah sekitar 64 siklus dan kami akan melihat percepatan operasi ini di masa depan.

Implementasi SSE

Algoritma SSE Klasik

Mengapa klasik? Karena sudah lama dalam implementasi FVec sebagai bagian dari MSVS. Untuk mulai dengan, kami akan menulis bagaimana kami menyajikan elemen matriks dalam register SSE. Ini sudah terlihat lebih sederhana di sini. Hanya matriks transpos.

 //     00, 10, 20, 30 // m[0] -  SIMD /   01, 11, 21, 31 // m[1] 02, 12, 22, 32 // m[2] 03, 13, 23, 33 // m[3] 

Kami mengambil kode membuka gulungan varian di atas. Entah bagaimana dia tidak ramah untuk SSE. Kelompok baris pertama terdiri dari hasil untuk kolom matriks yang dihasilkan: r._00, r._01, r._02, r._03 . Kami memiliki kolom ini, tetapi kami membutuhkan satu baris. Ya, dan m , n terlihat tidak nyaman untuk perhitungan. Oleh karena itu, kami mengatur ulang garis-garis algoritma sehingga hasilnya r adalah baris-bijaksana.

 //  ,     r[0] r00 = m00*n00 + m01*n10 + m02*n20 + m03*n30; r10 = m10*n00 + m11*n10 + m12*n20 + m13*n30; r20 = m20*n00 + m21*n10 + m22*n20 + m23*n30; r30 = m30*n00 + m31*n10 + m32*n20 + m33*n30; //  ,     r[1] r01 = m00*n01 + m01*n11 + m02*n21 + m03*n31; r11 = m10*n01 + m11*n11 + m12*n21 + m13*n31; r21 = m20*n01 + m21*n11 + m22*n21 + m23*n31; r31 = m30*n01 + m31*n11 + m32*n21 + m33*n31; //  ,     r[2] r02 = m00*n02 + m01*n12 + m02*n22 + m03*n32; r12 = m10*n02 + m11*n12 + m12*n22 + m13*n32; r22 = m20*n02 + m21*n12 + m22*n22 + m23*n32; r32 = m30*n02 + m31*n12 + m32*n22 + m33*n32; //  ,     r[3] r03 = m00*n03 + m01*n13 + m02*n23 + m03*n33; r13 = m10*n03 + m11*n13 + m12*n23 + m13*n33; r23 = m20*n03 + m21*n13 + m22*n23 + m23*n33; r33 = m30*n03 + m31*n13 + m32*n23 + m33*n33; 

Tapi ini sudah jauh lebih baik. Sebenarnya, apa yang kita lihat? Menurut kolom algoritma di setiap kelompok, kami memiliki baris matriks m yang terlibat:

 m [0] = {00,10,20,30}, m [1] = {01,11,21,31}, m [2] = {02,12,22,32}, m [3] = {03,13,23,33},

yang dikalikan dengan elemen yang sama dari matriks n . Misalnya, untuk grup pertama adalah: n._00, n._10, n._20, n._30 . Dan elemen-elemen dari matriks n untuk setiap kelompok baris dari algoritma lagi terletak pada satu baris dari matriks.

Kemudian semuanya sederhana: kita cukup mengambil baris matriks m berdasarkan indeks, tetapi untuk elemen n , kita mengambil barisnya dan mengocoknya melalui keempat elemen register melalui instruksi shuffle , untuk dikalikan dengan baris matriks m dalam register. Misalnya, untuk elemen n._00 (ingat bahwa perubahannya dalam register memiliki indeks 3), itu akan menjadi:

  _mm_shuffle_ps (n [0], n [0], _MM_SHUFFLE (3,3,3,3)) 

Dalam bentuk yang disederhanakan, algoritmenya terlihat seperti ini:

 //   n[0]={00,10,20,30} r[0] = m[0] * n00 + m[1] * n10 + m[2] * n20 + m[3] * n30; //   n[1]={01,11,21,31} r[1] = m[0] * n01 + m[1] * n11 + m[2] * n21 + m[3] * n31; //   n[2]={02,12,22,32} r[2] = m[0] * n02 + m[1] * n12 + m[2] * n22 + m[3] * n32; //   n[3]={03,13,23,33} r[3] = m[0] * n03 + m[1] * n13 + m[2] * n23 + m[3] * n33; 

Sekarang kita mengubah elemen n dalam algoritma ke shuffle yang sesuai, perkalian dengan _mm_mul_ps , jumlah dengan _mm_add_ps , dan Anda selesai. Itu bekerja. Akan tetapi, kode tersebut terlihat jauh lebih buruk daripada algoritma yang terlihat. Untuk kode ini, IACA mengeluarkan: x86 - 18.89, x64 - 16 siklus . Ini 4 kali lebih cepat dari yang sebelumnya. Dalam daftar SSE float ke-4. Hubungannya hampir linier.

Hiasi implementasi SSE

Namun, dalam kode itu terlihat mengerikan. Kami akan mencoba memperbaikinya dengan menulis sedikit gula sintaksis.


Kompiler dapat dengan sempurna menyejajarkan fungsi-fungsi ini (meskipun kadang-kadang tanpa __forceinline dengan cara apa pun).


Dan itu sudah jauh lebih baik dan lebih mudah dibaca. Untuk ini, IACA menghasilkan sekitar hasil yang diharapkan: x86 - 19 (dan mengapa tidak fraksional?), X64 - 16 . Sebenarnya, kinerjanya tidak berubah, tetapi kodenya jauh lebih indah dan dapat dimengerti.

Kontribusi kecil untuk optimasi di masa depan

Mari kita perkenalkan satu peningkatan lagi di tingkat fungsi yang baru-baru ini muncul di versi besi. Operasi multiple-add (fma) . fma (a, b, c) = a * b + c .


Mengapa ini perlu? Pertama-tama, untuk optimasi di masa depan. Misalnya, Anda cukup mengganti mad dengan fma dalam kode selesai melalui makro yang sama seperti yang Anda inginkan. Tapi kami akan meletakkan dasar untuk optimasi sekarang:


IACA: x86 - 18,89, x64 - 16 . Lagi pecahan. Meski begitu, IACA terkadang menghasilkan hasil yang aneh. Kode tidak banyak berubah. Mungkin bahkan sedikit lebih buruk. Tetapi optimasi terkadang membutuhkan pengorbanan seperti itu.

Kami beralih ke menabung melalui _mm_stream

Berbagai panduan pengoptimalan merekomendasikan sekali lagi untuk tidak menarik cache untuk operasi penyimpanan massal. Ini biasanya dibenarkan ketika Anda memproses simpul yang ribuan atau lebih. Tetapi untuk matriks, ini mungkin tidak begitu penting. Namun, saya tetap akan menambahkannya.


Tidak ada yang berubah waktu di sini, dari kata sama sekali. Tetapi, menurut rekomendasi, kita sekarang tidak menyentuh cache sekali lagi.

Implementasi AVX

Opsi AVX dasar

Selanjutnya, kita beralih ke tahap optimasi berikutnya. Pelampung ke-4 termasuk dalam register SSE, dan dalam AVX sudah 8. Artinya, ada peluang teoritis untuk mengurangi jumlah operasi yang dilakukan, dan meningkatkan produktivitas jika tidak setengahnya, maka setidaknya 1,5 kali. Tetapi ada sesuatu yang memberitahu saya bahwa tidak semuanya akan menjadi sangat sederhana dengan transisi ke AVX. Bisakah kita mendapatkan data yang diperlukan dari register ganda?

Mari kita coba mencari tahu. Sekali lagi, kami menuliskan algoritma multiplikasi yang digunakan di atas. Anda tidak bisa melakukan ini, tetapi lebih mudah untuk menangani kode ketika semuanya ada di dekat Anda dan Anda tidak perlu menggulir ke atas setengah halaman.

 //    : 00, 10, 20, 30, 01, 11, 21, 31, 02, 12, 22, 32, 03, 13, 23, 33 //   SSE: r0 = m0*n00 + m1*n10 + m2*n20 + m3*n30 r1 = m0*n01 + m1*n11 + m2*n21 + m3*n31 r2 = m0*n02 + m1*n12 + m2*n22 + m3*n32 r3 = m0*n03 + m1*n13 + m2*n23 + m3*n33 

Pada output, kami berharap mendapatkan hasilnya dalam ymm = {r0: r1} dan ymm = {r2: r3} . Jika dalam versi SSE, algoritma kami digeneralisasikan ke kolom, sekarang kami perlu menggeneralisasinya menjadi baris. Jadi untuk bertindak seperti dalam kasus opsi SSE tidak akan berfungsi.

Jika kita mempertimbangkan matriks m dalam register ymm , kita mendapatkan ymm = {m0: m1} dan ymm = {m2: m3}, masing-masing. Sebelumnya, kami hanya memiliki kolom matriks dalam register, dan sekarang kolom dan baris.

Jika Anda mencoba bertindak seperti sebelumnya, maka Anda harus mengalikan ymm = {m0: m1} dengan register ymm = {n00, n00, n00, n00}: {n10, n10, n10, n10, n10} . Karena n00 dan n01 berada di baris yang sama dari matriks n , menilai dengan set instruksi AVX yang tersedia, menyebarkannya dengan ymm akan mahal. Acak dan permutasi bekerja secara terpisah untuk masing-masing dari dua merangkak (tinggi dan rendah xmm ) di dalam register ymm .

Jika kita mengambil ymm dari matriks n , maka kita mendapatkan kedua elemen n00 dan n10 di tertinggi 2 xmm di dalam register ymm . {n00, n10, n20, n30}: {n01, n11, n21, n31} . Biasanya, indeks untuk instruksi yang ada adalah dari 0 hingga 3. Dan itu hanya alamat float dalam satu register xmm dari dua di dalam register ymm . Tidak mungkin mentransfer n10 dari xmm yang lebih lama ke yang lebih muda dengan murah . Dan kemudian fokus ini harus diulang beberapa kali. Kami tidak tahan dengan kehilangan langkah-langkah tersebut. Perlu untuk datang dengan sesuatu yang lain.

Kami dulu menggeneralisasi kolom, tetapi sekarang baris. Karena itu, kami akan mencoba untuk pergi dengan cara yang sedikit berbeda. Kita perlu mendapatkan hasilnya di {r0: r1} . Ini berarti bahwa algoritme harus ditingkatkan bukan dalam garis algoritma yang terpisah, tetapi dalam dua sekaligus. Dan di sini, apa yang minus dalam karya shuffle dan permutasi , akan menjadi nilai tambah bagi kita. Kita melihat apa yang akan kita miliki di register ymm ketika kita mempertimbangkan matriks n .

 n0n1 = {00, 10, 20, 30} : {01, 11, 21, 31} n2n3 = {02, 12, 22, 32} : {03, 13, 23, 33} 

Ya, kami perhatikan bahwa di bagian xmm berbeda dari register ymm kami memiliki elemen 00 dan 01 . Mereka dapat dikalikan case dengan mendaftar melalui perintah permute di {_00, _00, _00, _00}: {_ 01, _01, _01, _01} , menunjukkan hanya satu indeks 3 untuk kedua bagian xmm . Inilah yang kita butuhkan. Memang, koefisien juga digunakan pada garis yang berbeda. Hanya sekarang di register ymm yang sesuai untuk perkalian, perlu untuk menjaga {m0: m0} , yaitu baris pertama yang diduplikasi dari matriks m .

Jadi, kami mengecat algoritme lebih detail. Kita membaca baris ganda dari matriks m dalam register ymm :

 mm[0] = {m0:m0} mm[1] = {m1:m1} mm[2] = {m2:m2} mm[3] = {m3:m3} 

Dan kemudian kita akan menghitung perkaliannya sebagai:

 r0r1 = mm[0] * {n00,n00,n00,n00:n01,n01,n01,n01} + // permute<3,3,3,3>(n0n1) mm[1] * {n10,n10,n10,n10:n11,n11,n11,n11} + // permute<2,2,2,2>(n0n1) mm[2] * {n20,n20,n20,n20:n21,n21,n21,n21} + // permute<1,1,1,1>(n0n1) mm[3] * {n30,n30,n30,n30:n31,n31,n31,n31} // permute<0,0,0,0>(n0n1) r2r3 = mm[0] * {n02,n02,n02,n02:n03,n03,n03,n03} + // permute<3,3,3,3>(n2n3) mm[1] * {n12,n12,n12,n12:n13,n13,n13,n13} + // permute<2,2,2,2>(n2n3) mm[2] * {n22,n22,n22,n22:n23,n23,n23,n23} + // permute<1,1,1,1>(n2n3) mm[3] * {n32,n32,n32,n32:n33,n33,n33,n33} // permute<0,0,0,0>(n2n3) 

Kami menulis ulang dengan lebih jelas:

 r0r1 = mm[0]*n0n1<3,3,3,3>+mm[1]*n0n1<2,2,2,2>+mm[2]*n0n1<1,1,1,1>+mm[3]*n0n1<0,0,0,0> r2r3 = mm[0]*n2n3<3,3,3,3>+mm[1]*n2n3<2,2,2,2>+mm[2]*n2n3<1,1,1,1>+mm[3]*n2n3<0,0,0,0> 

Atau dalam bentuk yang disederhanakan:

 r0r1 = mm[0]*n0n1<3> + mm[1]*n0n1<2> + mm[2]*n0n1<1> + mm[3]*n0n1<0> r2r3 = mm[0]*n2n3<3> + mm[1]*n2n3<2> + mm[2]*n2n3<1> + mm[3]*n2n3<0> 

Segalanya tampak jelas.


Berikut adalah angka menarik dari IACA: x86 - 12.53, x64 - 12 . Meskipun, tentu saja, saya ingin yang lebih baik. Melewatkan sesuatu.

Optimasi AVX plus gula sintaksis

Tampaknya dalam kode di atas, AVX tidak digunakan secara maksimal. Kami menemukan bahwa alih-alih menetapkan dua garis identik dalam register ymm , kita dapat menggunakan siaran , yang dapat mengisi register ymm dengan dua nilai xmm identik. Juga, di sepanjang jalan, tambahkan beberapa "gula sintaksis" untuk fungsi AVX.


Dan di sini hasilnya sudah lebih menarik. IACA menghasilkan angka: x86 - 10, x64 - 8.58 , yang terlihat jauh lebih baik, tetapi masih belum 2 kali.

Opsi AVX + FMA (final)

Mari kita coba satu lagi. Sekarang akan logis untuk mengingat set instruksi FMA lagi, karena itu ditambahkan ke prosesor setelah AVX. Cukup ubah mul + individual tambahkan untuk satu operasi. Meskipun kami masih menggunakan instruksi perkalian untuk memberi kompiler lebih banyak peluang untuk optimisasi, dan prosesor untuk eksekusi paralel perkalian. Biasanya saya melihat kode yang dihasilkan di assembler untuk memastikan opsi mana yang lebih baik.

Dalam hal ini, kita perlu menghitung a * b + c * d + e * f + g * h . Anda dapat melakukan ini dahi: fma (a, b, fma (c, d, fma (e, f, g * h)))) . Tapi, seperti yang kita lihat, tidak mungkin untuk melakukan satu operasi di sini tanpa menyelesaikan yang sebelumnya. Dan ini berarti bahwa kita tidak akan dapat menggunakan kemampuan untuk melakukan penggandaan berpasangan, seperti yang dimungkinkan oleh pipa SIMD. Jika kita sedikit mengubah perhitungan fma (a, b, c * d) + fma (e, f, g * h) , kita akan melihat bahwa kita dapat memparalelkan perhitungan. Pertama lakukan dua perkalian independen, dan kemudian dua operasi fma independen.


IACA: x86 - 9.21, x64 - 8 . Sekarang sangat bagus. Seseorang mungkin akan mengatakan apa yang bisa dilakukan dengan lebih baik, tetapi saya tidak tahu caranya.

Tingkatan yang dicapai

Saya segera mencatat bahwa angka-angka ini tidak boleh dianggap sebagai kebenaran tertinggi. Bahkan dengan tes tetap, mereka berenang dalam batas-batas tertentu.Dan terlebih lagi mereka berperilaku berbeda pada platform yang berbeda. Dengan optimasi apa pun, lakukan pengukuran khusus untuk kasus Anda.

Daftar isi

• Fungsi: nama fungsi. Berakhir pada s - fungsi dengan streaming, bergerak normal berbeda (tanpa streaming). Ditambahkan untuk kejelasan, karena ini cukup penting.
• Siklus IACA: jumlah kutu per fungsi yang dihitung oleh IACA
• Siklus terukur: jumlah langkah yang diukur (lebih sedikit lebih banyak)
• IACA speedup: jumlah tindakan dalam garis nol / jumlah tindakan dalam satu garis
• Speedup terukur: jumlah pengukuran di garis nol / jumlah pengukuran di garis (semakin banyak semakin baik)

Untuk loop_m, kutu dari artikel dikalikan dengan 64. Artinya, ini adalah nilai yang sangat perkiraan. Bahkan, ternyata seperti itu.

i3-3770:

i7-8700K:

Kode uji dalam sumber. Jika ada saran yang masuk akal tentang cara memperbaikinya, tulis di komentar.

BONUS dari ranah fiksi

Sebenarnya, ini dari ranah fiksi karena jika saya melihat prosesor dengan dukungan untuk AVX512, maka mungkin dalam gambar. Namun, saya mencoba mengimplementasikan algoritma. Di sini saya tidak akan menjelaskan apa pun, analogi lengkap dengan AVX + FMA. Algoritmanya sama, hanya operasi yang lebih sedikit.


Jumlahnya fantastis: x86 - 4,79, x64 - 5,42 (IACA dengan arsitektur SKX). Ini terlepas dari kenyataan bahwa algoritma ini memiliki 64 perkalian dan 48 tambahan.

Kode PS dari artikel

Ini adalah pengalaman pertama saya menulis artikel. Terima kasih atas komentar Anda. Mereka membantu membuat kode dan artikel menjadi lebih baik.