Design: pThreads setiap ETA ?

Beberapa waktu dalam beberapa kuartal berikutnya mungkin tepat seperti yang bisa dikatakan siapa pun. Tapi harap pesan pelacak masalah untuk mengajukan masalah.

Proyek ini tidak memiliki milis atau forum lain, sehingga pelacak masalah adalah satu-satunya tempat di mana orang dapat mengajukan pertanyaan tentang proses desain. Sangat berharga untuk memiliki tempat di mana orang dapat mengajukan pertanyaan, jadi saya mendorong orang untuk terus menggunakan pelacak masalah untuk mengajukan pertanyaan.

@sunfishcode , cukup adil, tapi kemudian saya sarankan kita membuat daftar seperti itu. Saya tidak berpikir bahwa pelacak masalah adalah pengganti yang tepat untuk itu.

Ada daftar publik w3 . Itu tidak mengalami lalu lintas yang sangat padat sekalipun. Ada juga IRC yang saya percaya? Saya pikir itu ada di situs web di beberapa titik tetapi alangkah baiknya jika keduanya terhubung langsung ke bagian komunitas situs web. Saya akan membuka masalah tetapi saya tidak yakin jalan mana yang Anda semua lebih suka ~ diekspos~ ditautkan ke publik

Instruksi di sini:

• https://github.com/WebAssembly/design/blob/master/Contributing.md
• http://webassembly.org/community/feedback/

Kami telah membimbing orang-orang untuk menggunakan github. Tidak semua orang menyukainya, tetapi lebih baik memiliki satu tempat daripada banyak.

Hai @rossberg-chromium dan terima kasih atas jawaban tepat waktu Anda.

Tapi harap pesan pelacak masalah untuk mengajukan masalah.

Seperti yang ditunjukkan oleh @jfbastien saya bertanya di sini karena tampaknya tempat terbaik untuk melakukannya dengan cara standar.
Selain itu, dukungan utas adalah fitur desain yang merupakan make or break untuk webAssembly.
Lebih dari konteks logo dan "Mengapa tidak diimplementasikan di Jawa" saya lihat diangkat sebagai masalah.

Jika saya salah, beri tahu saya di mana harus mengikuti implementasi memori/utas bersama.
Ini harus menjadi proses terbuka, jadi saya ingin menyampaikan pendapat saya.

--R

@RobertoMalatesta kami setuju bahwa utas sangat penting, tetapi memperbaikinya lebih penting daripada menjejalkannya ke dalam produk WebAssembly yang minimal layak. Alasan kami sederhana: asm.js telah menikmati kesuksesan tanpa fitur ini.

Utas jelas merupakan fitur make atau break untuk beberapa aplikasi penting, tetapi tidak untuk semua aplikasi. Hal yang sama berlaku untuk GC, penanganan pengecualian tanpa biaya, panggilan ekor yang dijamin, dll.

Memilih untuk melakukan MVP berarti kami tidak membuat semua orang senang pada peluncuran pertama. Ini juga berarti beberapa orang dapat menggunakan WebAssembly sama sekali sebelum kami merancang, menentukan, dan mengimplementasikan semuanya.

Karena itu, kami berharap untuk kurang lebih mengadopsi pendekatan JavaScript SharedArrayBuffer ke dalam WebAssembly. Banyak dari kita telah terlibat dengan spesifikasi itu sejak awal. Itu akan menambah kemampuan tingkat rendah yang mirip dengan apa yang dimiliki C++, ditambah API seperti futex. Ini memiliki ruang untuk tumbuh dengan lebih banyak urutan memori daripada konsistensi berurutan. Ada pekerjaan yang sedang berlangsung untuk membuat model memori formal untuk itu.

SAB berada di "tahap 4" di TC39, yang berarti sudah selesai, siap dikirim, dan siap digunakan. Saya berharap mengadopsinya ke WebAssembly tidak akan terlalu sulit.

@jfbastien terima kasih atas info yang berwawasan luas.

Karena itu, kami berharap untuk kurang lebih mengadopsi pendekatan JavaScript SharedArrayBuffer ke dalam WebAssembly.(...)
SAB berada di "tahap 4" di TC39, yang berarti sudah selesai, siap dikirim, dan siap digunakan. Saya berharap mengadopsinya ke WebAssembly tidak akan terlalu sulit.

Besar. Saya ingin sekali mengatasinya dengan banyak kode C++ yang hanya membutuhkan threading.
Saya secara teratur menggunakan WebWorkers ke dalam aplikasi TS/JS saya dan izinkan saya mengatakan bahwa saya bukan penggemar mereka, tetapi mereka bisa menjadi awal yang pertama.

utas sangat penting, tetapi memperbaikinya lebih penting daripada menjejalkannya ke dalam produk WebAssembly yang minimal layak. Alasan kami sederhana: asm.js telah menikmati kesuksesan tanpa fitur ini.

Sepenuhnya memahami kebutuhan MVP untuk keluar dengan cepat (saya pikir itulah alasan untuk menjatuhkan AST untuk menjadi berbasis tumpukan) dan perawatan yang diperlukan untuk merencanakan langkah lebih lanjut.

Utas jelas merupakan fitur make atau break untuk beberapa aplikasi penting, tetapi tidak untuk semua aplikasi. Hal yang sama berlaku untuk GC, penanganan pengecualian tanpa biaya, panggilan ekor yang dijamin, dll.

Sebagai pengguna lama emscripten, saya ingin melihat WebAssembly lebih dipisahkan dari batas tumpukan aplikasi Javascript:

Wasm seharusnya hanya 1) bertujuan kinerja tertinggi dan 2) menyediakan soket, memori/utas, GDI, fs dengan beberapa standar Posix/Unix/BSD. Dengan begitu, ini akan menjadi lapisan tipis seperti OS yang dapat disematkan ke perangkat seluler sebagai platform target terpadu dan ke server untuk bersaing memperebutkan aplikasi yang dapat diterapkan di cloud.

Apakah ini arah menuju masa depan jangka panjang atau saya benar-benar ketinggalan perahu?

Terima kasih sekali lagi untuk pekerjaan Anda,

Roberto

Wasm jelas dipisahkan dari beberapa batas tumpukan karena cara kami memisahkan lokal dari apa yang perlu dimasukkan oleh kompiler seperti LLVM ke dalam Memori yang dapat diakses pengguna.

Dengan utas, terutama jika tidak berbasis Pekerja, Anda akan mendapatkan lebih banyak kekuatan di sana.

Karena itu, akan lebih baik untuk mendapatkan detail lebih lanjut tentang ide-ide Anda yang tepat. Apa kasus penggunaannya, bagaimana Anda mengatasinya di C++, dan bagaimana implementasi wasm melakukannya?

Saya tidak berharap Anda menemukan semua jawaban! Hanya apa yang terlintas dalam pikiran sekarang. Fwiw C++ memiliki beberapa proposal untuk batas tumpukan. Lihat subgrup SG14.

Maaf untuk detail yang rendah, saya di bawah . Akan menjawab lebih baik nanti!

Maaf untuk detail yang rendah, saya di bawah :baby:: burrito:. Akan menjawab lebih baik nanti!

Anda berada di bawah baby burrito? Tertawa terbahak-bahak

@qwertie

Anda berada di bawah baby burrito? Tertawa terbahak-bahak

Secara harfiah, bayi yang dibungkus.

Hai @jfbastien ,

akan lebih baik untuk mendapatkan detail lebih lanjut tentang ide-ide Anda yang tepat. Apa kasus penggunaannya, bagaimana Anda mengatasinya di C++, dan bagaimana implementasi wasm melakukannya?

Umumnya kasus penggunaan saya adalah membangun perangkat lunak simulasi, pada bagian komputasi batasnya hanya mesin, berkat teknologi C++, C/OpenCL dan GPU.

Di front-end tumpukan HTML5+CSS+Javascript+Typescript telah terbukti menjadi cara yang valid, terbukti, dan portabel untuk mengembangkan aplikasi kompleks menengah-besar.

_ JS Web Stack (dengan tambahan bahasa terstruktur seperti TypeScript ) sangat bagus akhir-akhir ini sehingga saya tidak merasa perlu menggunakan emscripten atau mencoba wasm untuk sebagian besar aplikasi._

Saya hampir sepenuhnya setuju dengan Sasaran Tingkat Tinggi dan Kasus Penggunaan Webassembly dan bahkan lebih banyak lagi pada Dokumen Penyematan Non-Web .

_ WebAssembly akan menjadi teknologi yang relevan (setidaknya bagi saya) jika memungkinkan untuk menjadi lebih cepat (ke tulang aplikasi C asli plus, katakanlah 5% overhead) menggunakan lebih banyak memori dan lebih bebas, memiliki port/soket yang sepenuhnya diimplementasikan dan izinkan untuk menjalankan utas seperti halnya OS normal lainnya._

Mesin Wasm harus sangat licin dalam ukuran, cepat dan prediktif, jadi tolong jangan terpaku padanya GC: GC adalah Skema Ponzi TI: Anda membuat hutang dan tidak peduli dengan alokasi sampai terlambat dan Anda kehilangan siklus . Selain itu, jika kita memiliki mesin inti wasm berkinerja tinggi maka GC dapat dibangun di atasnya.

Demi kelancaran, saya akan semakin melepaskannya dari Javascript. Jika saya memiliki kompiler asli dalam bahasa apa pun maka saya tidak perlu skrip dan, bagaimanapun, saya dapat menyematkan Duktape/Lua/apa pun hanya dengan mengkompilasi di sumber C.

Di suatu tempat di situs Mozilla saya melihat dokumen tentang penerapan manipulasi DOM asli wasm: Saya tidak berpikir itu akan sangat berguna karena manipulasi DOM secara inheren berurutan dan itu adalah salah satu aspek yang paling memakan waktu dari tumpukan HTML5/CSS/JS: jika Saya menulis wasm multithreaded super cepat hanya untuk membuat DOM saya berubah serial menunggu dalam antrian kemudian semua kinerja hilang dan lebih baik mentranspile beberapa TypeScript daripada menggunakan C/C++. Dalam hal ini saya lebih suka akses OpenGL langsung (pada awalnya dengan beberapa implementasi WebGL kemudian OpenGL asli). Mengakses Kartu Grafis akan terbukti berguna untuk menawarkan kemampuan GPU/CUDA dengan overhead kecil atau tanpa biaya.
(Baru saja memeriksa ini dan mendapat masalah #273 menangani ini)

Memiliki mesin wasm kecil yang dibagikan oleh setiap vendor dan independen juga dapat memecahkan mimpi buruk pengembangan seluler, di mana Anda memiliki setidaknya 4 rantai alat untuk OS dan versi serta arsitektur yang berbeda.
Fasilitas grafis dan input dapat bervariasi tetapi kami dapat mengembangkan ke satu wasm dan kemudian menanyakan API fasilitas , atau bahkan menerapkan aplikasi yang sama di toko aplikasi yang berbeda.
Dalam jangka panjang: sama dengan aplikasi server, mencapai semacam konsensus tentang fasilitas (Protokol dan Kumpulan Koneksi DB, Sistem Halaman Kuning, Protokol dan Sistem Pesan, dll.) dan mengemasnya ke dalam beberapa spesifikasi standar seperti yang dilakukan platform JEE. (Banyak pekerjaan konseptual telah dilakukan dalam 20 tahun terakhir).

Saya tidak berharap Anda menemukan semua jawaban! Hanya apa yang terlintas dalam pikiran sekarang. Fwiw C++ memiliki beberapa proposal untuk batas tumpukan. Lihat subgrup SG14.

Tentu saya akan melakukannya.

Terima kasih atas kesabaran dan waktu Anda.

rampok

Sebagai tambahan kecil, ketika utas diimplementasikan, akan sangat bagus jika ukuran tumpukan dapat dibuat besar secara sewenang-wenang, atau sebagai gantinya, jika dapat diatur ke setidaknya 64MB. Ini karena use case saya adalah aplikasi yang menggunakan 2 utas, dan utas non-utama membutuhkan tumpukan yang cukup besar.

@jjpe itu akan menjadi permintaan untuk rantai alat tertentu (seperti emscripten) yang menargetkan wasm, bukan untuk repo ini, karena ini adalah masalah pilihan implementasi rantai alat atau ABI daripada sesuatu tentang platform wasm itu sendiri. (jadi misalnya Anda bisa membuka masalah di https://github.com/kripken/emscripten/)

Beberapa hal yang saya usulkan dalam pesan saya sebelumnya sepertinya masuk dalam proposal WASI terbaru.
Melihat:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Menyilangkan jari.

--R

FWIW Status saat ini adalah Chrome mengirimkan dukungan utas wasm di versi 74, Firefox memiliki implementasi yang belum dikirimkan, dan Emscripten memiliki dukungan pthreads (https://emscripten.org/docs/porting/pthreads.html) dengan tersedia sekarang.

(Juga WASI adalah API panggilan sistem, yang sebagian besar ortogonal terhadap apakah penyematan wasm atau rantai alat yang diberikan mendukung utas/atom atau tidak).

Apakah ada dokumen tentang cara menggunakan API utas Chrome dan Firefox?

Ini semacam kombinasi dari hal-hal. Mesin wasm browser mengimplementasikan ekstensi threads/atomics ke spesifikasi wasm (https://github.com/WebAssembly/threads/tree/master/proposals/threads) yang memungkinkan memori wasm bersama untuk dipakai. Di web Anda dapat membuat pekerja web, dan mengirim memori (dan modul wasm terkait) ke pekerja melalui postMessage. Kemudian Anda membuat instance modul dengan memori bersama pada pekerja (dan pada utas utama, atau pekerja lain) dan instance membagikan memorinya. Ikhtisar proposal spesifikasi (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) memiliki contoh kecil, tetapi saya tidak mengetahui yang lain.

Hai @dschuff dan terima kasih atas jawaban di atas.
Dalam pesan saya sebelumnya, saya merujuk ke pesan sebelumnya, yang tidak hanya melibatkan pthreads tetapi juga evolusi yang diinginkan dari wasm menjadi sesuatu yang lebih mirip kernel yang sebagian dari kita mengikuti dan menggunakan emscripten sejak 2010 melihatnya sebagai teknologi terobosan nyata.
Lihat: https://github.com/WebAssembly/design/issues/992#issuecomment -285055578 .

Sembilan tahun setelah emscripten keluar, dan hampir lima setelah pengumuman wasm, sedikit kemajuan yang telah dilakukan dalam mengubah wasm menjadi teknologi server yang layak.

Sayangnya, karena kami memerlukan standar untuk aplikasi portabel, dan cara terbaik untuk melakukannya IMHO adalah dengan mengimplementasikan kernel kecil (seperti BSD/Linux) dengan POSIX Threads dan Berkeley Sockets + sistem file virtual aman mandiri (dengan pengguna dan kelompok sudah cukup). Saya berpegang teguh pada pepatah lama H.Spencer: "Mereka yang tidak mengerti UNIX dikutuk untuk menciptakannya kembali".

Saya masih ingin menjaga iman, jadi WASI adalah langkah ke arah yang benar.

--R

PS: 2010 emscripten masih rock, karena bekerja di browser abadi, unkillable yang tidak dapat disebutkan yang digunakan di sebagian besar perusahaan dan yang akan melihat tubuh Firefox dan Safari mengapung (setidaknya mesin mereka).