WebAssembly untuk Pengembang Web (Google I/O ’19). Indonesia

SURMA SURMA: Saya Surma. Saya seorang advokat pengembang
untuk system internet terbuka dan bekerja dengan Chrome
tim untuk Google di London. Dan saya sangat senang
hari ini, membicarakan satu hal gairah yang baru saya temukan,
yaitu WebAssembly. Anda mungkin pernah mendengar
sedikit. Dan Anda dapat menghubungi
saya di Twitter jika kamu punya beberapa
pertanyaan di masa depan. Dan kemudian rekan saya
Deepti dari [TIDAK TERDENGAR] tim teknik akan segera
Saya ingin membawa kita semua ke
halaman yang sama.
Begitu banyak sehingga banyak orang pikir itu semua tentang C ++ kapan sebenarnya, WebAssembly adalah lebih dari itu. Banyak trial yang bisa Anda temukan
online tentang C+ +dan emscriptening. Dan itu masuk akal karena emscripten adalah alat yang luar biasa
. Tapi itu sangat penting untuk pengembang internet untuk menyadari hal itu bukan hanya C++, dan itu WebAssembly dengan sendirinya sebenarnya alat yang sangat berguna untuk dimiliki di saku belakang Anda. Dan itulah yang saya inginkan bicarakan dalam pembicaraan ini. Saya ingin menunjukkan beberapa bahasa lain yang mendukung WebAssembly, bagaimana Anda mungkin bisa menggunakan WebAssembly tanpa mempelajari bahasa baru. Dan kemudian, seperti yang saya katakan, Deepti segera berbicara sedikit tentang apa masa depan WebAssembly tahan.
Jadi untuk memastikan semua orang tahu untuk apa kita di sini ini adalah WebAssembly.org, dimana kami bisa menjelaskan apa itu WebAssembly. Dan itu disebut portabilitas. Dan karena mesin online itu. Tapi itu bukan hal
yang tidak aman.
Misalnya, itu AutoCAD, yang telah bekerja di AutoCAD selama bertahun-tahun dan itu adalah produk terkenal. Tapi sekarang mereka sudah berusaha kompilasinya ke WebAssembly. Dan tiba-tiba itu terjadi berjalan di internet browser, yang sangat mengejutkan ketika Anda memikirkannya.
Dan menurut saya itu luar biasa.
UI yang bagus dan tampak asli menggunakan libqt dan WebAssembly.
Dan saya pikir karena itu berhasil begitu baik dalam skenario ini mengapa itu terkait erat dengan WebAssembly saat ini. Karena aslinya, emscripten adalah kompiler asm.js. Ini adalah ide oleh Mozilla dimana mereka menulis kompiler ini yang mengambil kode C.Dan mengubahnya menjadi JavaScript.
Jadi apa yang Anda lihat haknya adalah asm.js.
Itu hanya JavaScript biasa. Dan setiap internet browser yang dapat menjalankan JavaScript dapat menjalankan asm.js. Tapi rencananya adalah memberikan beberapa internet browser pemahaman
dari asm.js sehingga mereka memiliki jalur cepat khusus untuk membuat semacam program berjalan lebih cepat. Jadi, Anda memiliki banyak memori dan Anda memiliki beberapa variabel. Dan tiba-tiba, kode C+ +Anda bisa dijalankan di
mesin JavaScript Anda.

Tapi C dan C++ sering digunakan API lain seperti pembukaan file dan mungkin OpenGL. Jadi emscripten dibuat yang bekerja dengan menggunakan WebGL untuk berpura-pura menjadi OpenGL dan meniru data tersebut sistem sehingga bisa berpura-pura untuk mengerjakan file asli. Jadi pada dasarnya mereka meniru seluruh operasi POSIX sistem untuk membuat kode dijalankan di internet itu tidak pernah ditulis untuk web. Jadi mereka sebenarnya membuat itu terjadi.Jadi saat WebAssembly datang, emscripten baru saja menambahkan keluaran style baru tetapi menyimpan semua pekerjaan mereka telah memasukkan membuat emulasi itu.
Kode POSIX berfungsi di internet, dan berlaku untuk WebAssembly.
Dan saya pikir itu sebabnya WebAssembly sangat [TIDAK TERDENGAR] ke C++, karena itu pematangan cepat dari emscripten. Tapi bagaimana dengan pengembang internet? Bagaimana denganmu, siapa mungkin bekerja di agen internet atau mungkin bahkan seorang pengembang lepas? Bagaimana dan WebAssembly berguna bagimu? Apakah Anda harus mempelajari C++? Peringatan looter, tidak. Saat Anda pengembang internet dan Anda berpikir oh, Saya harus belajar C+ +jadi Saya dapat menggunakan WebAssembly, banyak orang berakhir seperti ini karena apa itu C++ kapan Anda tahu JavaScript? Dan fakta menyenangkan, itu berhasil sebaliknya juga.Ketika saya melihatnya pengembang C++. melihat atau menulis JavaScript untuk pertama kalinya, mereka.
membuat wajah yang sama persis. Dan saya tidak mengatakan itu. karena satu bahasa lebih baik dibandingkan yang lain, tetapi hanya karena.
Saya telah menulis keduanya. Dan setiap kali saya beralih,.
Ini membutuhkan waktu. Itu sangat berbeda.
Yang saya katakan adalah. Dan begitu juga jumlah orang yang.
merasa nyaman di kedua dunia cukup kecil. Dan sebagai hasilnya, WebAssembly. sepertinya tempat yang sangat khusus teknologi, padahal
kenyataannya. sebenarnya alat yang sangat berguna untuk dimiliki di saku belakang Anda. Dan jadi apa yang ingin saya bicarakan. tentang dua penggunaan utama
kasus yang biasanya saya lihat kapan. Saya berpikir tentang WebAssembly. Di satu sisi, saya ingin bicara.
tentang penggantian bedah modul kecil di data.
Aplikasi JavaScript, warm pass, kemacetan. Tapi pertama-tama, saya ingin bicara. Ini mungkin terlihat agak aneh.
Ekosistem JavaScript cantik besar. Maksud saya, lihat saja NPM.
Tapi itu hanya fakta. Jadi terkadang Anda begitu.
menghadapi masalah dan Anda sedang mencari perpustakaan. untuk mengatasi masalah ini. Dan Anda akan menemukannya di C atau
. di Corrosion tapi tidak di JavaScript.
Jadi Anda bisa duduk dan. Atau opsi baru Anda adalah mengetuk.
Dan itulah tepatnya. yang kami lakukan dengan Squoosh. Squoosh adalah gambar.
Dan Anda bisa jatuhkan.
codec yang berbeda ini miliki efek yang berbeda pada. kualitas visual gambar Anda.Sekarang, internet browser sudah.
menawarkan itu, jika Anda tahu. Karena dengan Canvas, Anda
bisa. putuskan dalam style gambar apa Anda ingin inscribe gambar.
Dan Anda bahkan mendapatkan kendali. melebihi kualitas.
Tapi ternyata beralih bawah. codec ini oleh web browser dioptimalkan untuk kompresi. kecepatan daripada kompresi kualitas atau kualitas aesthetic.
Jadi itu sedikit. tidak bersemangat, jujur saja.
Dan juga, Anda sedikit. Jadi sampai saat ini,.
dari browser lain. Jadi itu tidak cukup bagi kami. Jadi kami mencari di Google sedikit,
dan. kami menemukan beberapa emcoder codec ditulis dalam JavaScript. Tapi mereka agak aneh.

Dan juga kami tidak menemukan satu word play here. pembuat enkode dalam JavaScript untuk WebP. Jadi kami pikir kami
harus melihat. pada sesuatu yang lain dan kami menemukan banyak pembuat enkode di C. dan C++ jadi WebAssembly.Jadi yang kami lakukan adalah kami. kompile, misalnya, perpustakaan dipanggil. MozJPEG ke WebAssembly, memuatnya di web browser
, dan. mengganti JPEG internet browser enkode dengan milik kita sendiri. Dan apa yang diizinkan. kami adalah kami sebenarnya mendapat gambar yang jauh lebih kecil. pada kualitas visual yang sama pengaturan, yang agak keren.
Tapi tidak hanya itu,. itu juga diperbolehkan kami untuk mengekspos banyak ahli. pilihan yang dimiliki perpustakaan tapi itu browsernya. jelas tidak mengekspos.
Jadi hal-hal seperti itu. Intinya di sini adalah itu.
Itu sudah tertulis dengan pasti. Dan kami menggunakan emscripten.
Jadi dengan emscripten, untuk. menunjukkan cara kerjanya, Saya biasanya menemukan sendiri.
dalam proses 2 langkah. Langkah pertama adalah kompilasi.
perpustakaan, sesuatu yang Anda dapat ditautkan nanti.
Seringkali, codec gambar. memanfaatkan strings dan simd, karena. kompresi gambar tugas yang sangat bisa diparalelkan.
Tapi tidak ada JavaScript. atau WebAssembly memiliki dukungan
untuk utas. atau simd dulu. Deepti akan berbicara sedikit nanti. apa yang akan terjadi di depan itu. Tapi untuk saat ini, kami menonaktifkan.
simd untuk memastikan kami tidak mengalami masalah apa pun. Dan di langkah kedua,.
Ini adalah fungsi yang saya inginkan
.
buffer variety, yang berisi gambar JPEG.
Dan setelah Anda menulis ini. kode jembatan, kami sebut EMCC, emscripten C compiler dengan kami. File C++ dan documents perpustakaan, menghubungkan
semuanya, dan.
Karena emscripten adalah
. Jadi kalau pakai banyak. CAPI, file-file ini bisa menjadi sangat besar,.
Kita telah bekerja. dengan tim emscripten sangat membantu.
mereka menjaganya seminimal mungkin, tapi hanya ada.
sebanyak yang kamu bisa lakukan jika Anda ingin menjadi
. jatuhkan dan penggantian, jadi perhatikan ukuran data Anda.
Contoh existed dari. WebAssembly di squoosh adalah penskalaan gambar,.
karena ternyata membuat gambar. lebih besar atau lebih kecil, ada banyak cara. untuk mencapai itu dengan banyak visual yang berbeda.

efek dan keluaran aesthetic. Jadi dengan browser,. Anda hanya mendapatkan
apa yang Anda dapatkan. Jadi di video clip ini, Anda bisa lihat.
dengan Lanczos3, saya sebenarnya memiliki rgb linier.
konversi ruang warna. Saya sebenarnya punya banyak.
Jadi dalam kasus ini
, sebenarnya. Dan gambar ini.
squoosh, kami sebenarnya diambil dari ekosistem Rust.
Mozilla telah. Tapi komunitas juga.
Salah satu alat ini adalah paket wasm,. yang benar-benar membawamu dengan
tangan dan memutar. Kode Thrill ke WebAssembly modul di modern.
JavaScript dan sangat kecil, dan saya pikir itu benar-benar. menyenangkan untuk dimainkan. Begitu pula dengan Corrosion, dengan.
prinsip yang sama.

Kami memiliki perpustakaan,
dan kami ingin. untuk menulis jembatan kode kecil kami Jadi dalam kasus ini,. fungsi pengubahan ukuran adalah apa yang saya ingin. panggil dari JavaScript. Dibutuhkan gambar dan.
Nah, perbandingan ukuran itu.
tidak adil, karena itu. perpustakaan yang berbeda, dan itu perpustakaan
yang lebih kecil. Jadi jangan dibandingkan. itu bite dengan bite, tapi rata-rata, Rust cenderung. untuk menghasilkan kode lem yang jauh lebih kecil sedikit masuk akal,. karena Corrosion tidak melakukan apa pun dari. Emulasi sistem data POSIX. Anda tidak dapat menggunakan
documents. berfungsi di Corrosion, karena tidak bisa. emulasi sistem file.
Mereka punya beberapa peti. yang bisa Anda tarik jika Anda ingin memiliki. itu, tapi lebih dari itu dari pendekatan keikutsertaan.
Jadi intinya adalah. bahwa dengan squoosh,
kami menggunakan empat perpustakaan.
berbeda setidaknya dari dua bahasa berbeda yang. tidak ada hubungannya dengan internet, tapi kami
tetap melanjutkan. untuk menggunakannya di web. Dan itulah yang sebenarnya.
Aku ingin kamu untuk membawanya pulang dari semua ini
adalah. jika Anda menemukan celah di web system yang
telah diisi.
berkali-kali dalam bahasa lain tapi tidak di web,. atau tidak di JavaScript, WebAssembly mungkin alat Anda.Tapi sekarang mari kita bicarakan.
penggantian bedah jalur panas di. JavaScript anda dan mitos bahwa WebAssembly.
lebih cepat dari JavaScript. Sekarang ini sangat penting. bagiku, dan itu mengapa saya datang dengan ini.
sejak lama aesthetic yang dibuat-buat.
Baik JavaScript dan WebAssembly. memiliki performa puncak yang sama. Mereka sama cepatnya.
Tapi jauh lebih mudah untuk tetap tinggal di. jalur cepat dengan WebAssembly dibandingkan dengan JavaScript. Atau sebaliknya.
Terkadang terlalu mudah untuk melakukannya.
tanpa disadari dan tidak disengaja berakhir di jalur yang lambat pada.
mesin JavaScript Anda daripada di. Mesin WebAssembly.
sekarang yang sedang dikatakan. WebAssembly adalah melihat ke pengiriman. threads dan simd, sesuatu JavaScript itu.
tidak pernah mendapatkan akses.Jadi sekali hal ini dimuat,.
WebAssembly akan memiliki kesempatan untuk. sebenarnya mengungguli

JavaScript sedikit. Tapi saat ini.
keadaan, kinerja puncak.
adalah sama. Untuk memahami bagaimana keseluruhan ini. jatuh dari jalur cepat terjadi, mari kita bicara sedikit.
tentang V8, JavaScript Chrome dan mesin WebAssembly. File JavaScript dan WebAssembly. data memiliki dua entri berbeda menunjuk ke mesin. Submit JavaScript melewati. ke Pengapian, yang merupakan penerjemah V8. Jadi itu membaca.
File JavaScript sebagai teks dan menafsirkannya serta menjalankannya. Saat menjalankannya, itu.
WebAssembly, di sisi lain
. Dan sekali kompiler itu.
mengoptimalkan kode. Sekarang, ada beberapa.
perbedaan di sini. Perbedaan pertama yang jelas. adalah itu tahap pertama memiliki nama yang berbeda. dan logo design yang berbeda.Tapi ada juga. perbedaan konseptual.
Pengapian adalah. penerjemah, dan lepas landas adalah kompiler itu. menghasilkan kode mesin. Jadi itu akan menjadi.
generalisasi yang berlebihan untuk mengatakan bahwa kode mesin. selalu lebih cepat dari yang ditafsirkan kode, tetapi rata-rata,.
itu mungkin benar. Jadi ini sudah. perbedaan pertama dalam hal persepsi kecepatan. Tapi yang lebih penting.
apakah perbedaan ini. Untuk JavaScript,. mengoptimalkan kompiler hanya berlaku pada akhirnya. Jadi kode ini harus.
berjalan dan diamati sebelum dapat dioptimalkan,. karena asumsi tertentu dibuat dari observasi. Kode mesin dibuat,. dan kemudian kode mesin sedang berlari.
Tapi begitu asumsi tersebut. jangan tahan lagi, kamu harus mundur. kepada penerjemah, karena
kami tidak bisa menjamin. yang dilakukan oleh kode mesin hal yang benar lagi. Dan itu disebut a.
de-opt, de-optimasi.

Dengan WebAssembly, TurboFan. selalu tepat setelah lepas landas. kompiler, dan Anda selalu tetap pada keluaran TurboFan. Jadi kamu selalu tinggal
. di jalan cepat, dan Anda tidak akan pernah bisa membatalkan pilihan. Dan saya pikir di situlah. kesalahpahaman datang dari itu WebAssembly lebih cepat.
Anda bisa dengan mudah mendapatkannya. tidak disertakan dalam JavaScript, dan Anda tidak bisa di WebAssembly.Dan Nick Fitzgerald
dari. tim Corrosion WebAssembly sebenarnya melakukan. benchmark yang bagus,
bahwa dia menulis benchmark. di kedua JavaScript dan WebAssembly. JavaScript berwarna merah,. WebAssembly berwarna
biru. Dan menjalankannya pada. web browser yang berbeda.
Dan yang bisa Anda lihat di sini adalah.
ya, OK, WebAssembly lebih cepat.
Tapi yang utama. takeaway terjadi di sini adalah JavaScript itu.
harus menyebar. Ini tidak bisa diprediksi.
Selalu di waktu yang sama,.
Dan saya pikir itu benar. WebAssembly memberi Anda lebih banyak. Ini memberikan lebih dapat diprediksi.
Jadi kami pikir, oke,. ayo gunakan Canvas.
Tapi kami tidak bisa, karena. Kanvas ada di string utama.
Kanvas di luar layar hampir tidak ada. di Chrome pada saat itu, jadi kami akhirnya menulis. sepotong JavaScript dengan tangan
untuk memutar atau hanya menyusun ulang.
piksel untuk memutar gambar.Dan itu bekerja dengan sangat baik.
Itu sangat cepat,. tapi ternyata semakin banyak
kami menguji. di web browser lain, semakin aneh.
Jadi dalam kasus uji ini, kami.
memutar gambar 4K kali 4K. Dan ini bukan tentang.
Ini tentang. Web browser tercepat.
Browser paling lambat. Bahkan dari utas utama,
. Dan jadi apa dirimu.
Dan browsernya tidak. biasanya web browser yang cepat, hanya beberapa browser. dioptimalkan secara berbeda. Jadi kami menulis rotasi kami.
kode di WebAssembly, atau dalam

beberapa bahasa. yang dikompilasi ke WebAssembly untuk membandingkan bagaimana kinerjanya.
Dan apa yang bisa Anda lihat di sini. cukup banyak bahasa WebAssembly membawa. kami di suatu tempat di sekitar 500 tanda milidetik.
Saya akan menyebutnya dapat diprediksi.
Maksudku, masih ada. sedikit perbedaan, tapi
tidak ada apa-apanya dibandingkan.
varian JavaScript. Dan itu skala logaritmik.
Dan juga apa yang Anda bisa. lihat di sini, saya baru saja memperhatikan, apakah itu head to head. kinerja WebAssembly, pada kinerja puncak. WebAssembly dan JavaScript hampir sama.Jadi jika Anda melihat grafiknya,. Anda mungkin bertanya-tanya apa itu AssemblyScript. Dan jika belum, aku.
sangat bersemangat tentang ini, karena AssemblyScript.
AssemblyScript adalah TypeScript.
Nah, itu mungkin menyesatkan.
Anda, karena Anda tidak bisa begitu saja membuang TypeScript. anda sekarang pada kompiler ini dan dapatkan WebAssembly darinya,.
karena di WebAssembly, Anda tidak memiliki API Dom, jadi Anda.
tidak bisa hanya menggunakan kode yang sama. Tapi apa yang mereka gunakan. adalah sintaks TypeScript dengan jenis perpustakaan yang berbeda.
Jadi itu artinya kamu. WebAssembly, yang Menurut

saya ini luar biasa. Dan kemudian ada.
fungsi bawaan seperti memuat dan menyimpannya. masukkan nilai ke dalam memori atau membacanya dari memory. Dan WebAssembly.
kompiler mengubahnya ke dalam modul WebAssembly. Jadi sekarang Anda bisa. untuk menulis WebAssembly tanpa mempelajari bahasa baru.
Sesuatu yang perlu diingat.
tidak seperti TypeScript, WebAssembly tidak memiliki. pengumpul sampah.
Setidaknya belum. Dan Dipthi akan membicarakannya. ini nanti. Jadi setidaknya untuk saat ini, Anda harus melakukan. manajemen memori sendiri.
Jadi AssemblyScript menawarkan. beberapa manajemen memori modul yang bisa Anda tarik. Dan kemudian Anda
harus melakukannya. alokasi gaya C ini.
Itu sesuatu untuk. biasakan sedikit.
Tapi itu sangat banyak. Jadi saya hanya ingin. AssemblyScript cukup.
Ini memiliki kelompok yang sangat.
bersemangat di belakangnya.

Ini memiliki beberapa enroller,. tapi tidak ada apa-apanya dibandingkan dengan Mozilla di belakang Corrosion atau MScript.
Dan itu semua dikatakan,. Dan jika Anda. JavaScript dan WebAssembly.
bukan lawan. Ada sinergi diantara keduanya. Gunakan bersama.
Yang satu tidak menggantikan yang lain. Seperti debugging.
akan menjadi lebih sulit, dan pemecahan kode itu.
lebih keras dengan WebAssembly saat ini daripada.
dengan JavaScript, dan kamu harus. memanggil bolak-balik. Itu tidak akan. menjadi pengalaman yang luar biasa.
Saya meminta beberapa orang men-tweet saya. bahwa mereka ingin menulis internet komponen di C++.
Saya tidak tahu mengapa mereka menginginkannya. untuk melakukan
itu, tapi ternyata mereka ingin melakukan itu, tapi aku.
tidak akan merekomendasikannya.Yang ingin saya katakan adalah.
WebAssembly hal yang benar. Lakukan beberapa performa.
audit, lakukan pengukuran.
Dimana kemacetan Anda? Dan lihat apakah WebAssembly.
bisa membantumu. Apakah Anda menemukan celah di file. platform dan Anda dapat mengisinya dari bahasa lain? Sekali lagi, WebAssembly adalah alat Anda. Tapi, sekarang untuk membicarakan sedikit. masa depan WebAssembly dan yang akan datang. masa depan, saya ingin untuk menyambut Deepti ke atas panggung.
[TEPUK TANGAN] DEEPTI GANDLURI: Terima kasih, Surma.Halo semuanya.
Saya Deepti. Saya seorang insinyur perangkat lunak. di tim Chrome, dan saya bekerja pada standardisasi.
Fitur WebAssembly serta menerapkan. mereka di V8. Jadi sebagian besar dari apa
yang pernah Anda lihat.

dalam presentasi sejauh ini telah mendarat dan dikirim. di semua web browser utama, yang merupakan MVP atau Minimum. Produk WebAssembly yang Layak. Dan kami telah bekerja. keras menambahkan kemampuan untuk memastikan bahwa kami. semakin dekat untuk kinerja asli. MVP itu sendiri. membuka seluruh rangkaian aplikasi baru di web.

UI yang bagus dan tampak asli menggunakan libqt dan WebAssembly. Dan jadi apa yang ingin saya bicarakan. File C++ dan data perpustakaan, menghubungkan
semuanya, dan.
JavaScript dan sangat kecil, dan saya pikir itu benar-benar. Dan apa yang bisa Anda lihat di sini.Tapi ini bukan
tujuan akhir, dan di sana banyak yang baru,
fitur menarik bahwa kelompok komunitas
dan pelaksana sedang bekerja untuk mengaktifkan.Yang pertama adalah

Proposal WebAssembly Threads. Proposal penguliran memperkenalkan primitif untuk komputasi paralel. Secara konkret, itu artinya yang diperkenalkannya konsep bersama memori linier antar utas dan semantik untuk instruksi atom. Sekarang, mengapa ini perlu? Ada banyak perpustakaan ada yang ditulis dalam C atau C++ yang menggunakan Pthreads, dan itu dapat dikompilasi menjadi wasm dan berjalan dalam mode multi-utas, memungkinkan utas yang berbeda untuk mengerjakan hal yang sama information secara paralel. Selain hanya mengaktifkan kemampuan baru untuk aplikasi yang menguntungkan dari eksekusi multi-utas, Anda akan melihat skala kinerja dengan jumlah utas.Jadi proposal penguliran dibuat pada primitif yang sudah ada di system internet. Internet memiliki dukungan untuk eksekusi multi-threaded menggunakan Pekerja Web, dan itulah tepatnya digunakan untuk memperkenalkan multi-threaded eksekusi ke WebAssembly
. Sisi negatif dari Internet Workers adalah bahwa mereka tidak berbagi data yang bisa berubah di antara mereka. Sebaliknya, mereka mengandalkan pesan menyampaikan komunikasi melalui pesan pos.
Jadi proposal itu punya contoh implementasi mutex, dan saya mengeluarkan bagaimana Anda akan gunakan ini di host JavaScript.Jika Anda melihatnya dekat, disana perbedaan halus antara apa yang kamu akan dilakukan pada seorang pekerja versus apa yang Anda akan dilakukan di utas utama. Jadi di utas utama, metode mutex trilock disebut, yang mencoba mengunci mutex di alamat yang diberikan. Instruksi Beberapa Data.
Jadi proposal ini mencoba memanfaatkan kemampuan yang sudah ada di perangkat
keras Anda gunakan setiap hari. Tantangannya di sini adalah untuk menemukan
bagian itu didukung dengan baik pada kebanyakan arsitektur tetapi juga masih tampil. Saat ini, subset ini terbatas pada 128 bits simd. Ada beberapa perbedaan cara menggunakan proposition simd. Dengan menggunakan vehicle vektorisasi, Anda bisa berikan bendera untuk mengaktifkan simd saat menyusun, dan kompilator akan otomatis mengenali program Anda untuk Anda.Di samping itu, banyak kasus penggunaan simd khusus dan sangat cocok kinerja dan penggunaan kode tangan perakitan, jadi ini akan menggunakan dentang bawaan atau intrinsik yang menghasilkan kode mesin itu disetel untuk performa. Sekarang, simd dapat digunakan untuk berbagai macam aplikasi.
Jadi di sisi kiri adalah apa operasi skalar akan terlihat seperti, di mana Anda menambahkan setiap nomor satu sama existed dan simpan hasilnya. Versi vektor ini hanya akan mendidih ke satu instruksi perangkat keras. Misalnya, p atau vp pada beberapa arsitektur intel. Jadi operasi simd bekerja dengan mengizinkan beberapa bagian data dikemas dalam satu dunia data,
dan mengaktifkan instruksi untuk menindaklanjuti
setiap bagian data.Ini berguna untuk kasus dimana operasi yang sama harus dilakukan pada data dalam jumlah besar. Misalnya, ambil pengolahan gambar. proposition pengikatan IDL internet. Internet IDL adalah sebuah antarmuka bahasa definisi, dan itu bisa digunakan untuk tentukan antarmuka itu diimplementasikan di web. Kami sedikit menyinggung dengan jenis referensi. Ide dasarnya di sini adalah proposition ini menjelaskan menambahkan mekanisme baru ke WebAssembly untuk menghindari expenses yang tidak perlu saat menelepon atau dipanggil melalui antarmuka IDL web.Binding IDL internet
WebAssembly dan internet API.
Artinya lebih cepat eksekusi, modul yang lebih kecil, dan di luar C, C++, ini benar-benar
persyaratan untuk menjadi mampu mendukung sangat luas mayoritas bahasa modern. Ini juga besar dan masalah terbuka, tapi kami telah membuatnya maju dengan mengukir proposition yang lebih kecil dan mengasah dalam desain yang tepat kendala. Jadi saat ini, wasm dirancang secara eksplisit untuk bits tail phone call pengoptimalan. Ke depan, kami ingin mengaktifkan panggilan ekor yang benar dan efisien implementasi bahasa yang membutuhkan kal ekor emulasi, jadi ini akan menjadi bahasa fungsional seperti Haskell.V8 sudah memiliki documents implementasi untuk ini, dan ini sebenarnya bergerak dengan cukup baik. Jadi uploading MVP, WebAssembly
akan mendapatkan dukungan

tanpa biaya penanganan pengecualian, dan ini adalah sesuatu yang sedang juga aktif dikerjakan Kami juga sedang mengerjakan jumlah proposition lainnya, jadi jangan ragu untuk melihat dokumentasi fitur masa depan di halaman GitHub WebAssembly. Hal lain yang saya ingin tekankan banyak dari ini berada dalam fase desain, dan jika Anda tertarik dalam keinginan untuk berpartisipasi, semua pengembangan selesai dalam kelompok komunitas terbuka
, jadi kontribusi selalu diterima. Kami juga berbicara tentang kinerja. Jadi, jika Anda punya hambatan kinerja dan Anda telah menggunakan wasm meningkatkan beberapa kekhawatiran, kami ingin sekali mendengar dari Anda. Terima kasih.
TEPUK TANGAN] [MUSIK BERMAIN]

Proposal WebAssembly Threads. Sekarang, mengapa ini perlu? Instruksi Beberapa Data.
WebAssembly dan internet API.
Jadi publishing MVP, WebAssembly

Belajar Dapat Duit Dari Facebook Klik Di sini