Design: SIMD santai

Terima kasih @ngzhian @Maratyszcza. Ini sangat berguna.

Akan sangat membantu jika instruksi sebagai bagian dari ekstensi ini tidak terbatas pada 5 teratas ini. Kami telah mengevaluasi Float min/max, konversi float-int, dll untuk dapat menawarkan peningkatan kinerja yang signifikan tergantung pada platform. Memiliki ini sebagai varian instruksi baru daripada ekstensi mode simd santai (disebutkan di atas) akan membantu meminimalkan potensi non-determinisme yang diperkenalkan oleh mesin.
Di luar propagasi nan, ada beberapa skenario lain yang mungkin mendapat manfaat dari semantik santai, terutama ketika mode kepatuhan FP IEEE digunakan oleh pengembang (misalnya no-honor-inf, no-signed-zeros, no-trapping-math.. ) Akan berguna jika kita dapat mempertimbangkan mereka yang berada di bawah payung ini juga.

Akan sangat membantu jika instruksi sebagai bagian dari ekstensi ini tidak terbatas pada 5 teratas ini.

Ya, daftar itu tidak lengkap, saya harap kami dapat menghasilkan lebih banyak ketika kami akhirnya memiliki repo (mirip dengan bagaimana kami mengusulkan dan menggabungkan instruksi untuk SIMD).

Di luar propagasi nan, ada beberapa skenario lain yang mungkin mendapat manfaat dari semantik santai, terutama ketika mode kepatuhan FP IEEE digunakan oleh pengembang (misalnya no-honor-inf, no-signed-zeros, no-trapping-math.. ) Akan berguna jika kita dapat mempertimbangkan mereka yang berada di bawah payung ini juga.

Ide bagus, saya akan menambahkan cuplikan ini ke deskripsi, terima kasih.

Terima kasih. Terkait: https://github.com/WebAssembly/design/issues/1393#issuecomment -788196826

Saya harap kami dapat menghasilkan lebih banyak ketika kami akhirnya memiliki repo

Apakah ada rencana jangka pendek untuk mengadakan polling CG fase 0/1?

Apakah ada rencana jangka pendek untuk mengadakan polling CG fase 0/1?
Ya, setelah kami mendapatkan lebih banyak komentar, mungkin kami dapat melakukan polling pada pertemuan CG 16 Maret.

Hal yang rumit tentang Relaxed SIMD dan operator terkait adalah arti dari "konsisten lintas operasi". Jelas berharga bagi "program" untuk dapat mengasumsikan bahwa pembulatan konsisten di seluruh "lari", untuk menghindari diskontinuitas dll., tetapi secara umum, tidak selalu jelas apa ruang lingkup "lari", untuk contoh untuk instans yang ditangguhkan dan dilanjutkan yang berumur panjang, atau grafik instans yang didistribusikan di beberapa host yang mendasarinya. Saya punya ide bagaimana menghindari ini, dan saya ingin tahu apa yang dipikirkan orang lain:

Perkenalkan jenis buram baru, fpenv , yang mewakili informasi tentang lingkungan titik-mengambang host, yang akan diteruskan ke operator seperti qfma sebagai operan. Ini bisa berkembang dengan berbagai cara di masa depan, tetapi untuk saat ini, itu hanya akan menyertakan tanda seperti "apakah fma cepat?".

Awalnya, satu-satunya cara untuk mendapatkan nilai fpenv adalah dengan mengimpor variabel global dengan tipe fpenv :

   (global $fp (import "host.fp" "default") fpenv)

   (func $foo (param f32) (param f32) (param f32) (result f32)
     local.get 0
     local.get 1
     local.get 2
     global.get $fp
     f32.qfma
   )

(Nama "host.fp" dan "default" di sini hanya untuk ilustrasi; ini adalah sesuatu yang perlu kita cari tahu.)

Alih-alih mengatakan qfma itu sendiri nondeterministik, kami akan mengatakan nilai dari fpenv Anda impor adalah nondeterministik. Itu akan membuat properti "sama di seluruh proses" eksplisit dalam kode. Jika seseorang ingin menjamin bahwa dua instance memiliki nilai yang sama (misalnya instance program utama dan instance perpustakaan), satu modul dapat mengimpornya dan kemudian mengekspornya kembali, dan modul lainnya dapat mengimpornya dari yang pertama (rantai alat dapat mengatur ini secara otomatis).

Dalam implementasi umum, fpenv tidak akan menjadi nilai dinamis. Banyak host yang hanya memiliki satu kemungkinan nilai fpenv , jadi semua instruksi yang berinteraksi dengan nilai fpenv bisa saja tanpa operasi.

Kelemahannya adalah ukuran kode wasm; impor dan instruksi global.get membutuhkan ruang. Namun, dampaknya harus relatif kecil, karena instruksi yang membutuhkan nilai fpenv cenderung relatif jarang terjadi di seluruh modul.

Jelas berharga bagi "program" untuk dapat mengasumsikan bahwa pembulatan konsisten di seluruh "lari", untuk menghindari diskontinuitas, dll.

Saya setuju dengan ini, tetapi saya tidak yakin itu layak menjamin konsistensi internal yang kuat seperti ini dalam spesifikasi. Kami dapat menyerahkannya kepada mesin yang didistribusikan dan bermigrasi untuk memilih sendiri apakah akan memberikan jaminan ini, dan mesin yang tidak didistribusikan atau bermigrasi akan dapat menyediakannya tanpa melakukan sesuatu yang ekstra. Tujuan dari instruksi ini adalah untuk meningkatkan kinerja secara dramatis, tetapi mesin dengan persyaratan determinisme yang kuat tidak akan dapat mewujudkan peningkatan kinerja apa pun darinya. Dalam praktiknya, saya berharap mesin dengan persyaratan determinisme seperti itu tidak ingin mengimplementasikan instruksi ini sejak awal, jadi memperkenalkan kompleksitas ekstra untuk menjadikannya deterministik tidak akan sepadan.

Tujuan dari instruksi ini adalah untuk meningkatkan kinerja secara dramatis, tetapi mesin dengan persyaratan determinisme yang kuat tidak akan dapat mewujudkan peningkatan kinerja apa pun darinya. Dalam praktiknya, saya berharap mesin dengan persyaratan determinisme seperti itu tidak ingin mengimplementasikan instruksi ini sejak awal, jadi memperkenalkan kompleksitas ekstra untuk menjadikannya deterministik tidak akan sepadan.

FMA tampaknya menjadi contoh tandingan untuk ini; itu tersedia di banyak CPU hari ini (dan tautan itu sudah usang; ada banyak lagi sekarang), jadi misalnya, banyak lingkungan server saat ini dapat dengan nyaman bergantung pada FMA. Ini memiliki penerapan yang luas, termasuk dalam domain di mana determinisme dan komputasi terdistribusi adalah penting (aljabar linier di atas kumpulan data ubin). Dan itu memberikan percepatan besar (angka ~ 30% yang disebutkan di atas).

Jelas berharga bagi "program" untuk dapat mengasumsikan bahwa pembulatan konsisten di seluruh ...

Non-determinisme dalam proposal ini terbatas pada hasil instruksi individu dan dan konsisten di seluruh proses...

Apakah ada kasus di mana, jika instruksi tidak "konsisten di seluruh proses" (untuk beberapa definisi), itu akan tetap berguna, dan tidak membingungkan?

Saya berpikir untuk mendefinisikannya seperti:

fma(x, y, z) = oneof { round(x + y * z), round(round(x+y) * z) }

Determinisme bersifat lokal, dan untuk contoh khusus ini selalu hanya ada 2 kemungkinan kasus. Tapi itu tidak konsisten, jika Anda memiliki eksekusi terdistribusi, satu host dapat memilih untuk melakukan satu pembulatan dan host lain dapat memilih untuk melakukan dua pembulatan.

Jika aplikasi kuat untuk perbedaan seperti itu, maka mereka mendapatkan kinerja maksimal dari ini.

Apakah ada kasus di mana, jika instruksi tidak "konsisten di seluruh proses" (untuk beberapa definisi), itu akan tetap berguna, dan tidak membingungkan?

Pasti ada aplikasi yang kuat untuk pembulatan FMA secara berbeda setiap kali dipanggil. Tetapi ada juga aplikasi di mana presisi mutlak tidak penting, tetapi menghindari diskontinuitas adalah penting. Misalnya, di banyak program grafik, mungkin tidak terlihat jika posisi atau warna objek tertentu sedikit berbeda dari apa yang mungkin ditunjukkan oleh perhitungan yang sepenuhnya tepat, tetapi mungkin terlihat jika ada tonjolan pada garis atau batas di sebuah gradien.

Saya telah melihat driver GPU membagi FMA menjadi perkalian dan penambahan diskrit di tempat-tempat di mana mereka hanya dapat memasukkan perkalian atau penambahan ke dalam pipa perangkat keras di tempat tertentu dalam kode, dan sebagai hasilnya saya telah melihat aplikasi yang sebenarnya rusak. Jika kita ingin konsistensi, kita harus mengatakannya di spec.

Bagaimana jika kita memecahkan masalah ke arah yang berbeda dengan mengklarifikasi apa yang kita maksud dengan "lari" dalam spesifikasi? Kita dapat menambahkan bahasa ke efek "FMA mungkin memiliki perilaku ini atau itu, tetapi sebuah instance mungkin tidak mengamati kedua perilaku tersebut dan semua instance di toko harus mengamati perilaku yang sama." Sekali lagi, untuk mesin yang tidak terdistribusi dan tidak bermigrasi, hal ini tidak menimbulkan beban tambahan. Mesin terdistribusi/migrasi masih harus melakukan apa pun yang akan mereka lakukan dengan fpenv eksplisit, tetapi dari perspektif produsen dan spesifikasi, ini akan lebih sederhana.

Bagaimana jika kita memecahkan masalah ke arah yang berbeda dengan mengklarifikasi apa yang kita maksud dengan "lari" dalam spesifikasi? Kita dapat menambahkan bahasa ke efek "FMA mungkin memiliki perilaku ini atau itu, tetapi sebuah instance mungkin tidak mengamati kedua perilaku tersebut dan semua instance di toko harus mengamati perilaku yang sama." Sekali lagi, untuk mesin yang tidak terdistribusi dan tidak bermigrasi, hal ini tidak menimbulkan beban tambahan. Mesin terdistribusi/migrasi masih harus melakukan apa pun yang akan mereka lakukan dengan fpenv eksplisit, tetapi dari perspektif produsen dan spesifikasi, ini akan lebih sederhana.

Toko itu abstrak, hanya cara bagi spesifikasi untuk berbicara tentang entitas yang dapat ditautkan. Bisakah rentang toko menangguhkan/melanjutkan siklus? Bisakah itu menjangkau jaringan? Spesifikasi hanya mengatakan jika Anda dapat menautkan ekspor ke impor, itu adalah toko, yang memberikan banyak fleksibilitas pada penyemat. Jika kita mulai menggunakan toko untuk menyimpan informasi konfigurasi lain-lain, itu akan memberikan identitas toko, membuat pertanyaan ini lebih kompleks.

Maksud dari fpenv adalah bahwa mesin tidak dapat menyimpulkannya sendiri. Produser mengetahui maksud mereka, seperti "library ini memerlukan konfigurasi titik-mengambang yang sama dengan program yang ditautkannya", dan fpenv memungkinkan menyatakan maksud mereka.

Saya mengerti maksud Anda tentang toko sebagai abstraksi yang tidak sempurna untuk kasus penggunaan ini. Jika mesin memotret memori instance dan mengaktifkan kembali modul dengan memori yang di-snapshot pada mesin yang berbeda, tampaknya Anda dapat memanggil penyimpanan yang berbeda tetapi tetap merusak program jika semantik FMA berubah.

Saya kira saya tidak yakin bahwa membiarkan produsen mengekspresikan niat halus di sini cukup berguna untuk sepadan dengan kompleksitas ekstra ini. Saya dapat melihat bahwa use case dapat dibuat, tetapi saya juga tahu bahwa pengguna yang bekerja dengan saya yang benar-benar ingin menggunakan FMA tidak memerlukan ini. Saya tentu saja bias, karena saya hanya bekerja sama dengan pengguna Web, yang ini tidak akan membuat perbedaan. Apakah Anda mengenal pengguna yang menginginkan kontrol yang halus ini? Jika tidak ada sekarang, mungkin kita bisa membuat tidak ada jaminan atau menemukan cara untuk menentukan jaminan kasar tentang konsistensi semantik dalam proposal ini. Dengan asumsi tidak ada pengguna sekarang, saya akan dengan senang hati mengunjungi kembali ini dan melakukan versi lain dengan kontrol yang lebih halus di masa mendatang ketika ada pengguna yang siap memanfaatkannya.

Salah satu sifat yang menarik dari wasm adalah kemampuan virtualnya. Semua interaksi dengan dunia luar melalui impor dan ekspor, jadi mudah untuk memiliki instance WebAssembly tanpa konsep "mesin yang saya gunakan" sebagai identitas berbeda yang dapat berinteraksi dengan mereka. Dengan WASI, kami bekerja pada ekosistem di mana program tidak tahu tentang "ruang nama sistem file dari mesin yang saya gunakan" atau "konfigurasi jaringan lokal dari mesin yang saya gunakan" (pengganti dalam "wadah I 'm in" atau "VM I'm in" sesuai kebutuhan ;-)).

Ini berarti "mesin yang saya gunakan" dapat berubah seiring waktu, dan "mesin yang saya gunakan" dapat berbeda dari "mesin tempat saya terhubung dengan mesin lainnya". Kita dapat melakukan ini, tanpa konfigurasi yang telah diatur sebelumnya, karena hubungan antara instance sepenuhnya dijelaskan dalam impor dan ekspornya. Saya sendiri dan orang lain sedang membangun sistem yang akan memanfaatkan properti ini secara umum.

Ada kasus di mana kita bisa bertahan tanpa properti ini. Misalnya dengan FMA, jika kita baik-baik saja membatasi ruang lingkup kita hanya pada server, maka kita mungkin bisa bergantung pada FMA yang tersedia di mana-mana. Namun, di satu sisi, saya tidak dapat menjamin bahwa kami akan selalu membatasi cakupan kami hanya untuk server. Dan di sisi lain, proposal di sini sudah memiliki lebih dari sekedar FMA, dan lebih banyak hal dapat ditambahkan di masa depan.

Saya mengerti ini menambah kerumitan di depan, tetapi kekhawatiran saya adalah jika kita tidak melestarikan properti wasm ini, akan sulit untuk memperkenalkan kembali. Dan sepertinya tidak terlalu rumit untuk diproduksi oleh produsen atau diabaikan oleh konsumen minimal.

Bagaimana ini ditujukan untuk NaN dalam operasi f32 / f64 ?

Bit-bit NaN yang dihasilkan oleh operasi f32 / f64 hanyalah nondeterministik, dalam beberapa batasan , sehingga tidak menyiratkan status apa pun. Dan dalam praktiknya, jarang ada program yang peduli dengan bit NaN dengan cara yang tidak tercakup oleh batasan.

@sunfishcode , jika kami menambahkan mekanisme fpenv untuk menjamin determinisme, saya tidak berpikir itu akan membuat set instruksi yang diusulkan ini lebih menarik bagi produsen yang menargetkan runtime yang heterogen. Untuk kode yang bekerja dengan adanya ~nondeterministic~ FMA yang tidak konsisten, tidak masalah apakah kita memiliki mekanisme fpenv. Kode yang membutuhkan konsistensi ~determinisme~ dalam proses, di sisi lain, tidak akan pernah ingin menggunakan FMA di lingkungan yang mungkin tidak secara konsisten mendukungnya secara asli karena biaya untuk menirunya. Kode tersebut akan memiliki kinerja yang lebih dapat diprediksi dengan menggunakan perkalian dan penambahan yang tidak digabungkan, yang sudah dapat diekspresikan tanpa proposal ini.

Anda benar bahwa Wasm umumnya dimaksudkan untuk menjadi deterministik dalam semua hal yang penting dan harus mudah divirtualisasikan. Namun proposal ini secara eksplisit dimaksudkan sebagai pengecualian terhadap aturan tersebut, oleh karena itu proposal ini dipisahkan dari proposal SIMD. Saya tidak mengharapkan runtime heterogen yang ingin memberikan determinisme untuk mengimplementasikan proposal ini sama sekali. Kode yang ingin berjalan pada runtime yang menyediakan proposal ini serta runtime yang tidak menyediakan proposal ini harus menggunakan proposal deteksi fitur untuk mencapainya.

Nah, bit NaN diformalkan menjadi non-deterministik, tetapi dalam praktiknya mereka khusus platform. Saya setuju bahwa jarang ada program yang peduli dengan bit NaN di luar apa yang ditentukan, tetapi saya tidak akan terkejut jika beberapa program secara implisit mengandalkan fakta bahwa bit-bit itu setidaknya berperilaku sama "di seluruh proses".

Ini bukan untuk mengabaikan kekhawatiran yang meningkat dari @sunfishcode . Saya hanya ingin tahu apakah cakupan perhatiannya lebih luas dari proposal ini. Jika ya, maka untuk mesin virtualisasi, saya bertanya-tanya apakah yang masuk akal adalah, ketika mengkompilasi modul, melacak perilaku spesifik platform apa pun yang dimilikinya dan kemudian, ketika membuat instance modul, merekam spesifik platform saat ini dan pastikan untuk hanya memindahkan instance ke platform dengan spesifikasi yang sama. (Atau untuk membatasi kode ke subset wasm platform-independen.)

@tlively saya menguraikan kasus penggunaan di atas yang ok dengan FMA menjadi nondeterministik, tetapi yang membutuhkan FMA untuk konsisten dalam menjalankan. Diskontinuitas merusak aplikasi nyata, bahkan ketika presisi penuh dan determinisme penuh tidak diperlukan.

Apakah fpenv benar-benar memberatkan? Itu harus mekanis untuk banyak skenario produsen, dan harus diabaikan di banyak konsumen.

@RossTate Re: NaNs: Dengan NaNs kami setidaknya dapat memberi tahu pengembang "jangan lakukan itu", sedangkan situasi FMA yang dibahas di sini terjadi dalam penggunaan umum. Dan dalam beberapa kasus penggunaan, kita dapat melewati masalah NaN menggunakan flag wasm engine untuk mengkanonikalisasi NaN. Secara keseluruhan, ceritanya memang tidak sepenuhnya kedap air, tetapi ini adalah masalah yang cukup kecil dalam praktiknya.

Re: Melacak perilaku khusus platform: Ya, kami dapat menghindari pemutusan instans menggunakan pelacakan khusus dan mempertahankan status ekstra, tetapi itu tidak mengatasi masalah penautan, di mana kami ingin mengetahui sebelumnya jika dua instans perlu melihat perilaku yang sama .

@sunfishcode , maaf, dalam komentar sebelumnya saya menggunakan "nondeterministik" dan "deterministik" di mana saya benar-benar bermaksud "tidak konsisten dalam lari" dan "konsisten dalam lari." Saya memperbaruinya, jadi sekarang semoga lebih masuk akal. Bukannya fpenv sangat memberatkan, tetapi dalam pandangan saya memecahkan masalah yang dipecahkan adalah bukan tujuan untuk proposal ini dan saya tidak melihat bagaimana hal itu akan menambah nilai bagi populasi pengguna/program yang saya berharap untuk menggunakan proposal ini. Karena akar ketidaksepakatan kita tampaknya adalah ekspektasi yang berbeda untuk tujuan proposal, bagaimana jika kita melanjutkan diskusi ini pada pertemuan CG berikutnya di mana kita dapat melakukan percakapan yang lebih mendalam tentang tujuan dan non-tujuan. Saya ingin memberikan ruang pada masalah ini bagi orang-orang untuk mengangkat topik lain juga :)

Sebagai latihan pemikiran, jika kita ingin mengambil rute memasukkan mekanisme fpenv , saya mencoba mencari cara lain apa yang akan berguna. Saya tertarik dengan gagasan untuk mengabstraksi variabel lingkungan Host menjadi global - selain dari flag is fma fast , informasi berguna apa lagi yang dapat kami enkode? Ketika kami pertama kali berbicara tentang fitur pasca-MVP Simd, sebuah ide yang menarik bagi saya adalah bendera yang kompatibel ke belakang untuk melonggarkan beberapa semantik dari operasi MVP yang ada untuk kinerja, dan saya dapat melihat fpenv berguna untuk itu tujuan.

Yang mengatakan, apa artinya untuk Perkiraan instruksi sqrt timbal balik / timbal balik? Kecuali saya melewatkan sesuatu, ini akan memberikan hasil yang sedikit berbeda pada arsitektur yang berbeda dan tampaknya tidak dapat dicegah dengan fpenv ?

@dtig Kita mungkin menganggap fpenv sebagai semacam referensi ke co-prosesor floating-point. Operand fpenv dalam instruksi floating-point akan menjadi co-processor untuk menghitung hasilnya. Algoritma mana yang digunakan oleh co-prosesor tidak dapat ditentukan, dalam beberapa batasan yang akan kami rancang, tetapi co-prosesor yang diberikan akan selalu konsisten dengan dirinya sendiri.

Saya ingin menunjukkan bahwa kami tidak dapat sepenuhnya merangkum non-determinisme di dalam variabel fpenv : beberapa instruksi sedang dipertimbangkan untuk SIMD yang santai (mis. RSQRTPS / RCPPS pada x86 SSE). Namun, kami dapat menentukan fallback deterministik untuk setiap instruksi SIMD Santai, yang dinyatakan melalui instruksi SIMD MVP. Kemudian implementasi di mana non-determinisme menjadi perhatian besar dapat menggunakan penurunan deterministik, dengan mengorbankan beberapa kinerja.

fpenv hanya tentang memberikan hasil aplikasi yang konsisten dalam proses, jadi tidak masalah jika RCPPS , RSQRTPS , dll. kurang ditentukan.

Jika suatu proses melibatkan pemindahan eksekusi ke mesin yang berbeda, instruksi resiprokal aproksimasi akan menghasilkan hasil yang berbeda jika diturunkan ke RCPPS / RSQRTPS

Saya masih tidak yakin fpenv perlu menjadi impor eksplisit untuk memenuhi kebutuhan @sunfishcode, tetapi jika ya, saya akan menyarankan agar itu tidak direpresentasikan sebagai nilai kelas satu.

@Maratyszcza Ini bukan tentang menjamin bahwa kami selalu dapat bermigrasi, tetapi tentang membuat persyaratan aplikasi eksplisit.

@RossTate Setiap ide yang Anda miliki untuk cara lain untuk memecahkan masalah dipersilakan.

@sunfishcode paling ekstrem, kami dapat mendokumentasikan sesuatu yang setara dengan fpenv dalam definisi semantik dari setiap operasi SIMD yang santai, tanpa mengharuskannya direpresentasikan dalam kode program. Secara abstrak, itu mungkin termasuk dalam contoh, tapi saya yakin kita bisa bersepeda. Tuan rumah bertanggung jawab untuk menentukan bagaimana fpenv dikonfigurasi (yang masih bisa dengan cara terprogram pada waktu pembuatan, jika perlu).

Saya pikir menggunakan impor juga mengalami masalah yang sama dengan mencoba menentukan konsistensi dalam hal toko; konsistensi identitas nilai yang diimpor bergantung pada gagasan dasar yang sama tentang masa pakai "lari". Dalam kasus terburuk, mesin yang memenuhi spesifikasi dapat dibuat yang memiliki nilai berbeda untuk impor setiap kali fungsi host memanggil ke dalam instance. Pada setiap panggilan host-to-wasm, mesin ini sebenarnya akan mengaktifkan kembali modul dengan nilai impor yang berbeda dan memutar ulang jejak eksekusi pada instance baru sebelum melakukan panggilan. Jelas ini akan menjadi hal yang aneh untuk dilakukan, tetapi ini menunjukkan bahwa menggunakan impor sendiri tidak memberikan jaminan formal yang kuat tentang konsistensi internal dari sudut pandang program.

Yang terbaik yang bisa kita lakukan adalah mengikat jaminan konsistensi internal dengan masa pakai sesuatu yang sudah ada dalam spesifikasi, yang mungkin akan menjadi contoh. Maka terserah kepada mesin untuk mengklarifikasi apa yang mereka anggap sebagai masa pakai sebuah instance. Mesin aneh di atas akan mendokumentasikan bahwa instans hanya hidup selama dibutuhkan modul untuk kembali dari panggilan host-to-wasm, dan mesin yang lebih realistis akan mendokumentasikan bahwa identitas instans tidak berubah ketika sebuah instans dimigrasikan ke mesin yang berbeda.

Jika kita ingin program dapat memilih atau keluar dari konsistensi internal, akan lebih sederhana untuk menyediakan dua versi dari setiap instruksi (atau diskriminasi langsung) untuk memungkinkan produsen mengekspresikannya secara langsung. Tidak perlu impor atau apa pun. (Kita masih harus mendiskusikan nanti apakah itu harus menjadi tujuan proposal ini.)

Ini masalah yang menarik. Saya rasa saya tahu berbagai teknik semantik untuk memformalkan kemungkinan semantik, jadi saya lebih tertarik pada pragmatik. Untuk itu, akan sangat membantu untuk memahami skenario secara lebih mendalam. @sunfishcode , dapatkah Anda memberikan contoh yang lebih rinci tentang sesuatu yang ingin Anda izinkan dan sesuatu yang ingin Anda cegah, dan kemudian dapatkah Anda menjelaskan bagaimana Anda melihat jenis impor membantu membedakan kedua kasus tersebut? Itu akan memberi saya lebih banyak untuk bekerja dengan dan menawarkan saran untuk (minggu depan, ketika saya memiliki akses ke komputer lagi).

@tlively Instansiasi adalah peristiwa yang dapat diamati, dari perspektif sebuah program. Secara umum, host tidak dapat secara sewenang-wenang merobohkan dan membuat instance ulang tanpa konsekuensi, termasuk kemungkinan kehilangan data. Saya baik-baik saja jika program tidak dapat mengandalkan nondeterminisme floating-point yang konsisten di seluruh instance mereka yang sedang down dan di-instantiated.

@RossTate Berikut ringkasannya: Beberapa aplikasi boleh saja jika operator floating-point tertentu nondeterministik, tetapi mereka mungkin mengandalkan operator yang deterministik "saat runtime", sehingga mereka tidak melihat diskontinuitas yang tiba-tiba. Kami ingin cara untuk mengatakan bahwa semua instance yang membentuk "run of a program" melihat perilaku yang sama satu sama lain. Impor adalah cara untuk mengekspresikan ini: kita dapat meminta satu instance mengimpor fpenv dari lingkungan dan mengekspornya kembali, dan instance lain kemudian dapat mengimpornya dari instance pertama, sehingga mereka semua mendapatkan perilaku yang sama (tanpa memengaruhi instance lain yang tidak terkait dengannya).

Memikirkan ini lebih jauh, saya sekarang juga memikirkan cara untuk melakukan ini tanpa nilai kelas satu. Gagasan "fungsi intrinsik" untuk wasm telah muncul beberapa kali, tetapi tidak pernah jelas apa perbedaan antara "instruksi" dan "fungsi intrinsik". Mungkin nondeterminisme sekarang berbeda. Jika kami membuat qfma , qrcp , qrsqrt diimpor fungsi intrinsik, dengan nama yang dicadangkan sehingga mesin dapat mengenali dan menyelaraskannya, dan mengharuskan mereka memiliki perilaku deterministik saat runtime, kami juga dapat mengekspor ulang dan mengimpornya di instance lain untuk memastikan instance lain melihat fungsi yang sama.

Terima kasih atas infonya, @sunfishcode!

Jika seseorang mencoba menerapkan ini secara statis, saya rasa impor tidak akan cukup. Pertimbangkan bahwa sebuah modul dapat mengimpor beberapa fpenv s (setelah Anda dapat mengimpor satu, komposisi modul mengharuskan Anda untuk dapat mengimpor beberapa). Modul mungkin hanya menggunakan salah satu dari fpenv s ini dalam kodenya, tetapi dari tanda tangan modul Anda tidak memiliki cara untuk mengetahui impor mana yang digunakannya.

Untuk apa yang Anda gambarkan, saya pikir Anda memerlukan ekstensi seperti sistem efek. Efek instruksi khusus platform akan menunjukkan fpenv spesifik yang digunakan instruksi. Agar ini tetap dapat dikendalikan, fpenv s harus kelas dua (jika tidak, Anda akan masuk ke sistem efek yang diketik secara dependen). Jenis tanda tangan fungsi juga akan diperluas untuk mengatakan fpenv mereka gunakan (dan, untuk membuat hal-hal dapat dikendalikan oleh mesin, Anda dapat membuat batasan bahwa paling banyak satu fpenv hadir pada satu waktu). Kemudian pemeriksaan tipe akan memastikan bahwa fpenv -fungsi sensitif hanya memanggil fungsi fpenv -sensitif lainnya yang menggunakan fpenv sama, dan juga instance yang mengimpor/mengekspor fpenv -fungsi sensitif hanya ditautkan ke instance menggunakan fpenv .

Apakah itu masuk akal?

@RossTate saya meninggalkan terlalu banyak detail dalam ringkasan saya :-}. Kami tidak memerlukan mekanisme yang gagal memeriksa jenis jika program menggunakan beberapa nilai fpenv , dalam modul atau bahkan dalam satu fungsi. Sebuah fungsi yang menggunakan dua nilai fpenv secara konseptual hanya berarti bahwa ia dapat melakukan dua badan independen dari pekerjaan floating-point yang tidak perlu konsisten satu sama lain. Dalam praktiknya, ini mungkin sangat jarang, tetapi kita tidak perlu melarangnya.

Yang kita butuhkan hanyalah cara agar satu bagian kode meminta agar konsisten dengan bagian kode lainnya. Baik kita mengimpor global atau fungsi, impor memberi kita bahwa: cara sepotong kode meminta agar konsisten dengan potongan kode lain adalah dengan menggunakan nilai impor yang sama. Impor juga dapat diekspor kembali ke modul lain untuk memberikan nilai yang sama melintasi batas modul.

@sunfishcode , bagaimana Anda menangani poin yang diangkat @Maratyszcza ini ?

Saya ingin menunjukkan bahwa kami tidak dapat sepenuhnya merangkum non-determinisme di dalam variabel fpenv: beberapa instruksi sedang dipertimbangkan untuk SIMD santai (mis. Perkiraan sqrt timbal balik) ke instruksi yang tidak ditentukan secara arsitektur (mis. RSQRTPS/RCPPS pada x86 SS).

@tlively Ini bukan tentang menjamin bahwa kita selalu dapat bermigrasi, tetapi tentang memberi kode cara untuk menyatakan kebutuhannya.

Jika modul A mengimpor, menggunakan, dan mengekspor ulang fpenv , dan modul B mengimpornya dari A dan menggunakannya, ini mengatakan bahwa apa pun yang didapat fpenv A, B akan mendapatkan yang sama. Itu mungkin berarti bahwa saya sebagai tuan rumah memiliki lebih sedikit opsi daripada jika B tidak memiliki impor itu, tetapi tidak apa-apa. Kuncinya adalah saya sebagai tuan rumah tahu bahwa mereka harus sama, jadi saya bisa menghindari melanggarnya.

@sunfishcode Saya khawatir Anda mengharapkan impor/ekspor dapat mengekspresikan lebih dari yang mereka bisa (atau setidaknya daripada yang bisa mereka ekspresikan dengan mudah). Bisakah Anda memberikan contoh program multi-instance yang harus divalidasi (karena penggunaan konsisten fpenv ) dan contoh program multi-instance yang seharusnya tidak memvalidasi (karena penggunaan fpenv tidak konsisten

@RossTate , saya tidak berpikir bahwa menggunakan fpenv "salah" seharusnya menjadi kesalahan validasi, tetapi itu mungkin memungkinkan program untuk mengamati semantik yang tidak konsisten yang tidak diharapkan atau mungkin membatasi Host yang didistribusikan.

@RossTate Tidak ada contoh program yang seharusnya tidak memvalidasi :-). Ini bukan tentang menangkap program menggunakan nilai fpenv tidak sengaja tidak konsisten. Ini tentang membiarkan program yang membutuhkan komputasi yang konsisten memintanya.

Bayangkan menetapkan setiap kemungkinan algoritma timbal balik floating-point nilai integer yang unik. Dengan itu, fpenv hanyalah bilangan bulat yang mengidentifikasi algoritma tertentu. Mengimpor dan mengekspor fpenv hanya berbagi nilai integer yang tersedia di seluruh batas modul. Pendekatan timbal balik kemudian hanya akan menjadi fungsi murni dari operan-operannya, yang kebetulan merupakan 1 nilai floating-point dan satu nilai "bilangan bulat". Jika Anda menghitung pendekatan timbal balik dua kali, dengan nilai operan yang sama, Anda mendapatkan hasil yang sama.

Jadi tidak ada keajaiban di sini dan tidak ada pembatalan. Ia bekerja seperti nilai-nilai biasa.

Oh baiklah. Maaf, Anda telah mengatakan bahwa Anda perlu mengetahui kompatibilitas yang diperlukan "di depan", yang membuat saya kecewa.

Apa yang Anda gambarkan kemudian tampaknya perlu dapat memengaruhi kompilasi (kecuali jika Anda ingin ini benar-benar dikompilasi ke panggilan fungsi), jadi apakah fpenv akan "pra"-diimpor?

Bayangkan menetapkan setiap kemungkinan algoritma timbal balik floating-point nilai integer yang unik. Dengan itu, fpenv hanyalah bilangan bulat yang mengidentifikasi algoritma tertentu. Mengimpor dan mengekspor fpenv hanya berbagi nilai integer yang tersedia di seluruh batas modul. Pendekatan timbal balik kemudian hanya akan menjadi fungsi murni dari operan-operannya, yang kebetulan merupakan 1 nilai floating-point dan satu nilai "bilangan bulat". Jika Anda menghitung pendekatan timbal balik dua kali, dengan nilai operan yang sama, Anda mendapatkan hasil yang sama.

Algoritme timbal balik yang diimplementasikan dalam perangkat keras memiliki batasan yang sangat kecil yang dikenakan padanya (hanya kesalahan relatif maksimum pada x86). Mereka adalah tabel pencarian yang dikodekan dalam implementasi prosesor. Tidak ada API untuk mendapatkan parameter tabel ini, jadi satu-satunya cara untuk menirunya adalah dengan membuang 16GB yang mewakili output 4-byte untuk setiap input 4-byte.

@Maratyszcza Ya, itu benar. Untungnya, saya tidak ingin meniru apa pun di sini. Saya terutama ingin memberikan aplikasi cara untuk menyatakan kebutuhan mereka sehingga saya dapat menghindari melakukan hal-hal yang akan merusaknya.

@RossTate Dalam sebagian besar implementasi, idenya adalah bahwa hanya ada satu kemungkinan fpenv nilai, sehingga pengetahuan yang fpenv di gunakan tidak pernah mempengaruhi keputusan mesin seperti itu akan membuat. Jadi saya pikir impor reguler akan cukup untuk masa mendatang.

Jika wasm menambahkan mekanisme pra-impor, kita dapat beralih menggunakannya untuk fpenv , dan mungkin ada beberapa keuntungan teoretis, tetapi saya rasa kita tidak memerlukannya untuk kasus penggunaan utama di sini.

SIMD santai pindah ke fase 1 pada pertemuan CG sebelumnya hari ini, kami memiliki repositori kami sendiri di https://github.com/WebAssembly/relaxed-simd , silakan ajukan masalah dan lanjutkan diskusi di sana.

Saya mengajukan https://github.com/WebAssembly/relaxed-simd/issues/1 untuk menangkap apa yang menurut saya merupakan diskusi utama di sini, seputar "konsistensi" dan berbagai saran tentang cara menentukannya.

Terima kasih semuanya untuk semua diskusinya, dan saya menantikan lebih banyak lagi!