Docker DesktopがWebAssemblyランタイムを統合。コンテナと同様にWebAssemblyイメージを実行可能に
Docker DesktopがWebAssemblyランタイムを統合。コンテナと同様にWebAssemblyイメージを実行可能に Docker Desktopを提供するDocker社は、Docker DesktopにWebAssemblyランタイムを統合することによる、Docker DesktopのWebAssembly対応版のテクニカルプレビューを発表しました。 またDocker社はこれに合わせて、WebAssemblyをあらゆるプラットフォームでセキュアに実行できるようにするための仕様策定と実装を進めている団体「Bytecode Alliance」への加盟も発表しました。 DockerにWASMランタイムのWasmEdgeを統合 下記の図がDocker DesktopにWebAssemblyを統合した仕組みを示しています。 左側と中央は通常のDockerコンテナを利用する場合の仕組みで
Using WebAssembly threads from C, C++ and Rust
Learn how to bring multithreaded applications written in other languages to WebAssembly. WebAssembly threads support is one of the most important performance additions to WebAssembly. It allows you to either run parts of your code in parallel on separate cores, or the same code over independent parts of the input data, scaling it to as many cores as the user has and significantly reducing the over
WebAssemblyとは
こんにちは、HashHubエンジニアの白井です。 本日のTech Blogは「WebAssemblyについてゆーるく調べてみた」です！ ブロックチェーン業界にいる方であれば、Ethereum 2.0ではWebAssembly（WASM）でコントラクトが書けるということを聞いたことがあるかと思います。 今回はブロックチェーンのことは少なめで、そもそもWebAssemblyって何ってことを説明しようと思います。 WebAssemblyとはプログラミング言語やライブラリの名前ではなく、ブラウザでプログラムを高速実行するための、「ブラウザ上で動くバイナリコードの新しいフォーマット(仕様)」です。 Google, Microsoft, Mozzila, Appleによって仕様が策定され開発が進められています。 WebAssembly (abbreviated Wasm) is a binary in
2016/05/11時点でWebAssembly関連の情報を整理してみた - Qiita
フロントエンドとしては絶対に避けて通れないWASM、そろそろエッジ環境なら試せるツールが揃ってきたということで、手を出してみた。 自分がどうしてもローレベルに弱いので、たぶん色々間違ってるんだけど、識者各位は指摘お願いします。 現在の仕様はここ https://github.com/WebAssembly/spec Chrome Canary と Firefox Beta で動作可能 WASMのゴール asm.jsに比べてサイズが小さく高速にデコード可能なバイナリフォーマット 将来的な目標として、DOMアクセスとそのGCインテグレーション これが達成されれば、ブラウザにおいて JS がファーストプライオリティな言語という状態ではなくなる とはいえ既存の資産が多いのでなくなることはないだろうが wasmのスペック自体は小さいのでおそらくブレようがないが、DOMの実装とGCは各ベンダごとに別々
WebAssemblyが50マイクロ秒以下で起動する「Lucet」。コンパイラとランタイムをFastlyがオープンソースで公開
WebAssemblyが50マイクロ秒以下で起動する「Lucet」。コンパイラとランタイムをFastlyがオープンソースで公開 WebAssemblyとは、Webブラウザ上でネイティブコードに近い実行速度で高速に実行できるバイナリフォーマットです。 マイクロソフト、Google、Mozilla、AppleなどのWebブラウザベンダがW3CのWebAssembly Community Groupなどを通じて共同で開発に取り組んでおり、すでに主要ブラウザで実行環境が整っています。 Lucetは50マイクロ秒でWebAssemblyモジュールが起動 LucetはこのWebAssemblyをWebブラウザではなく、Fastlyのエッジクラウドで高速かつ安全に実行する目的で開発されたもの。 しかも50マイクロ秒（1マイクロ秒は100万分の1秒）以下でWebAssemblyモジュールが起動し、メモリオ
Go言語がWebAssemblyをサポートへ。GOARCHは「wasm」、GOOSは「js」に
Googleが中心となってオープンソースで開発されているGo言語は、WindowsやmacOS、Linux、FreeBSD、iOS、Androidなど、さまざまなOSやCPUに対応したバイナリを生成できることが特長の1つとなっています。 そのGo言語のコンパイラが生成するバイナリにWebAssemblyが追加されました。WebAssemblyは、Webブラウザ上でネイティブコードに近い実行速度で高速に実行できるバイナリフォーマットです。 WebAssemblyのサポートは昨年2月から検討がはじまり、先月末に最初のコードがコミットされた状態で、現在も開発が進んでいます。 GOの今後のバージョンアップで正式にWebAssemblyがサポートされる見通しです。 Go言語はサポートするOSやCPUの種類をそれぞれ「GOOS」と「GOARCH」の値で示しています。例えばWindowsのGOOS値は「
WebAssemblyはなぜ速いのか | POSTD
本記事はWebAssemblyに関するシリーズの第5回目で、今回のテーマはWebAssemblyが高速な理由です。前の記事をお読みでない方は、 初めから目を通される (訳注:原文リンク)ことをお勧めします。 前回の記事 (訳注:原文リンク)では、プログラミングに WebAssembly あるいはJavaScriptを使うかは二者択一の選択ではないことを説明しました。私たちは、WebAssemblyのみのコードベースを書く開発者が膨大な数になるとは思っていません。 ですので、アプリケーションにWebAssemblyとJavaScriptのどちらを使うか選ぶ必要はありません。しかし私たちとしては、開発者がJavaScriptコードの一部をWebAssemblyに置き換えることを期待しています。 例えば、Reactで開発しているチームは、リコンサイラコード（言い換えれば仮想DOM）をWebAss
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
