ARM に存在する JavaScript 専用命令「FJCVTZS」を追う（ついでに V8 をビルドする）
前回の記事では、JavaScript の実行エンジン V8 の JIT 出力コードを読んでみました。記事は M1 Mac 上で動かした結果でしたので、ARM アーキテクチャのアセンブラを読むことになりました。 さてそんな ARM アーキテクチャですが、最近の ARM には FJCVTZS という JavaScript 専用の機械語命令があるのをご存知でしょうか？CPU に、特定の言語（それもコンパイラを持たない JavaScript）専用の命令があると知ったとき、私は大いに驚きました（過去にも Jazelle みたいなものはありましたが） 今回は、この FJCVTZS 命令について、実際にどれだけ効果があるのか、V8 をビルドしながら調べてみましょう。 FJCVTZS 命令とは？ FJCVTZS 命令は、Arm v8.3 から導入された JSCVT 命令の一つで、JavaScript の言
イベントループと TypeScript の型から理解する非同期処理
この本は、ブルーベリー本の 8 章からインスパイアされて、 TS の型が示す情報から Promise というものを理解してみる、というアプローチで書いたJSの非同期処理の解説です。 これらの資料と合わせて読むことを推奨します。 JSのイベントループのイメージを掴む JSでは中々意識することが少ないですが、正しく理解するには OS レベルのスレッドの視点で考え始める必要があります。 ブラウザや Node.js では一つのスクリプト実行単位を1つのスレッドに割り当てます。それをメインスレッドと呼んだり、ブラウザだったら UI スレッドと呼んだりします。 例えばブラウザでは、これは秒間60回、つまり 16.6ms ごとにループを呼び出します。(node だったらこれがもっと短いです) 仮に setTimeout の実装がなかったとして、それ相当の擬似コードを書くのを試みます。 let handl
M1でやってるらしい（Apple用の）最適化｜NJRecalls
Apple M1速いね、ってことで、それはいいとして、それ以外にも色々Appleの用途に最適化している点があるらしいというツイートがあった。ちょっと読んでてマジで？となったのでここにメモしておこう。 私はというとこんなCPUレベルの話が効いてくるようなプログラムは書いたことないので、誤解もあると思う。ゆるして 1/ In case you were wondering: Apple's replacement for Intel processors turns out to work really, really well. Some otherwise skeptical techies are calling it "black magic". It runs Intel code extraordinarily well. — Robᵉʳᵗ Graham😷, provocateu
ArmにあるというJavaScript専用命令とは何か、あるいは浮動小数点数を整数に変換する方法について - Qiita
元の値の絶対値が大きすぎる場合や、無限大、NaNの場合は、 6.3.1.4: 表現できない場合はundefined behavior。 Annex F.4: 表現できない場合はinvalid例外が発生して、値はunspecified。 とされています。 これ以外の浮動小数点数→整数型の変換方法には (l)lrint や (l)lround 関数などがあります。 Java 基本的に0方向への丸め（切り捨て）で計算されますが、コーナーケースについても言語仕様で定めています。 NaN：0を返す 結果が表現できないもしくは無限大の場合：符号に応じて最大値または最小値が返る。 参照： 5.1.3. Narrowing Primitive Conversion - Chapter 5. Conversions and Contexts JavaScript JavaScriptではビット演算やいくつか
長男がプログラム(でゲーム)を作りたいと言い出したので、Javascriptの書き方..
長男がプログラム(でゲーム)を作りたいと言い出したので、Javascriptの書き方とブラウザでの動作確認を軽く教えた 次男も感化されたようで長男の真似をし始め、今は簡易な動作のHTMLファイルであれば作れるようになっている ある日、二人の空気が険悪だった(大喧嘩したあとの空気だった) まずは長男に事情を訊いてみると、とあるプログラムの方針で対立したとのこと それは「じゃんけんゲーム」だった 画面でグーチョキパーのいずれかを選びボタンを押すと、相手(CPU)の「手」と勝敗が表示されるというものだった 次男はまずCPUの「手」を乱数で決定し、画面に入力された「手」と比較して勝敗(と引き分け)を決める、素直な処理だった 長男はそれに飽きたのか、まずは乱数で「勝ち」「負け」「引き分け」を乱数で最初に決めてしまい、その後で結果に応じたCPUの「手」を決定するというロジックだった 次男はこれが気に入
コインハイブ事件、被告人質問 「JavaScriptで同意を取るほうが稀」 - 弁護士ドットコムニュース
自身のウェブサイト上に他人のパソコンのCPU（処理装置）を使って仮想通貨をマイニングする「Coinhive（コインハイブ）」を保管したなどとして、不正指令電磁的記録保管の罪に問われたウェブデザイナーの男性（31）の第3回公判が1月17日、横浜地裁（本間敏広裁判長）であり、被告人質問が行われた。 ●CPU使用率50%「不快感を与えず問題のない設定」 弁護側の質問から開始。男性は自身のサイトにコインハイブを導入した経緯について、2017年9月ごろにウェブメディアの記事でコインハイブを知り「新しい技術として興味深く、試してみたいと思った」と説明。 ローカル環境でCPU使用率0%〜100%までテストした際に、「CPU使用率50%であればユーザーに不快感を与えず問題のない設定」と思い、自身のサイトに設置したコインハイブはCPU使用率50%の設定にしたという。 弁護人の「コインハイブを設置することで、
PHPで動くファミコンエミュレータを作った
TL;DR PHPで動くファミコンエミュレータを作った php-terminal-nes-emulator画面描画は点字を使って文字出力コントローラは標準入力からfread() 経緯 2016年の2月にPHPで動くゲームボーイのエミュレータ、php-terminal-gameboy-emulator に衝撃を受けて、その実装の解説を勉強会やカンファレンスでトークしたりSoftware Design誌に書いたりしました。(*1) カンファレンスでのトークでは時間の都合もあって全体のごく一部しか話が出来ないのですが、Software Design誌では誌面をたっぷり頂いてCPU、メモリアクセス、画面表示とphp-terminal-gameboy-emulator のほぼ全域を解説出来たので満足し、その熱は落ち着いていました。 そんな中、9月に開催されたbuilderscon tokyo 201
JavaScript の並列処理機能を味見してみる
この記事は “A Taste of JavaScript’s New Parallel Primitives” の抄訳です。 まとめ：複数の Worker と共有メモリを利用して、本当の意味で並列アルゴリズムの JavaScript 実装を可能にするために、JavaScript の基本機能を拡張しようとしています。 複数コアを用いた計算 JavaScript (JS) は成熟しました。モダンな Web ページのほとんど全てで、大量の JavaScript が利用され、それらが動作するのは当たり前のことになっています。また JS の適用領域も拡大しています：クライアントサイドでは、Facebook や Lightroom が行っているように画像処理が JavaScript で実装されていますし、Google Docs のようなブラウザで動作するオフィススイートも JS で実装されています。P
Webブラウザを使って電波を出してみた
読者の持っている至って普通のコンピューターは、実は電波時計の時刻合わせを行うために必要な標準電波の発信装置が備わっている。 コードは以下から入手できる。 shogo82148/web-jjy JJYシミュレータWeb版 動かし方 パソコンのイヤホンジャックにアンテナ(普通のイヤホンで十分です)を接続し、電波時計の近くに置きます。 音量を最大にし、「Start」ボタンを押すと信号が送信されます。 電波時計を強制受信モードにし、時刻が設定されるのを待ちましょう。 パソコンの時間を基準にするので、あらかじめntpとかで時刻設定をしておくといいと思います。 原理 標準電波JJYは日本標準時のタイムコードを送信する電波で、 東日本では40kHz、西日本では60kHzの周波数で発信されています。 電波時計はこの信号を使って時刻合わせをしています。 この信号をオーディオデバイスから出力する電波時計用JJ
JSがブラウザを固めてつらいので、新しいAPI「requestIdleCallback」を使うことにした - pixiv inside [archive]
「ピクシブ株式会社 Advent Calendar 2015」の24日目の記事です。こんにちは、今年8月からピクシブに入社した新米の@_furoshikiです。入社直後は、古くなって大変なことになっているJavaScriptのコードを、そーっと触る系エンジニアをやっていました！ 私はピクシブに入る前から、オフィスの一部を借りて「東京Webパフォーマンス」という趣味丸出しなイベントを開催しています。その中で扱ったテーマのひとつである「requestIdleCallback」が、古いJavaScriptのコードにUIをブロックされ、荒んでいた私の心を救ってくれました！ 今回、このrequestIdleCallbackというブラウザの新機能について、pixiv insideのブランド力を信じて、日本に多く広まるよう宣伝してみようかとおもいます！ そもそも、ブラウザのなにが問題なのか？ Windo
![JSがブラウザを固めてつらいので、新しいAPI「requestIdleCallback」を使うことにした - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/9816ce1456c701bc9ca8189c4a1992fe7883d36e/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Fcf5f8e7e9c0572236d914a69de729574796d371d%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fd%252Fdevpixiv%252F20151217%252F20151217010303.jpg)
Webアプリで起きるクライアントサイドの性能劣化パターンとその改善チューニング
本連載は、パフォーマンスを主な対象としてシステム開発・運用の改善や設計を行うNTTデータのコンサルタントチーム「まかせいのう」のメンバーが、業務での体験やそこから得た知見を共有する『週刊まかせいのう』の記事を編集し転載するものです。今回は、クライアントサイド（Webブラウザ）の処理性能を劣化させるパターンと、それを改善し性能を向上させるチューニング方法を紹介します。 遅延原因がクライアント側にある場合の2つのパターン いわゆる「性能が出ない」「画面がもっさりして処理が遅い」という性能問題が発生した場合、必ずどこかに遅延を発生させているコンポーネント、いわゆる「ボトルネック」が存在します。それはWebサーバであったり、DBサーバであったり、はたまたネットワークやストレージであったりします。 一般的に、こうした遅延箇所の多くはサーバサイドに集中しています。サーバサイドでは、多くのユーザリクエス
JavaScript：float32による小数演算最適化 | 月と燃素と、ひと匙の砂糖
また翻訳です！ Efficient float32 arithmetic in JavaScript コンピュータ上で浮動小数点を表現する方法はいくつか存在する。だいたいのアーキテクチャではIEEE754標準を使っている。この標準では、倍精度浮動小数点(a.k.a. double or float64)を64bitで表し、単精度浮動小数点(a.k.a. float or float32)を32bitで表している。名前が示す通り、float64はfloat32よりもっと正確なんだ。だからパフォーマンスがあんまり重要視されないときは大体こっちを使おうねってアドバイスされる。 でもね、float32を使うことにもこんな利点がある： float32は計算操作をするのにfloat64よりCPUサイクルがしばしば少ない。精度が低いからだ。 float64の計算をfloat32に対して行うには、いくらか
なぜ僕は(2015年のフロントエンドで、makeではなく)gulpを選ぶのか - mizchi's blog
http://d.hatena.ne.jp/m-hiyama/20150511/1431306678 の件 最初に 僕もgulpが今後生き残るかというと、かなり懐疑的です。開発パラダイムに合わせて変わっていくで、来年の段階で自分はgulp使えないなといっている可能性は十二分にあります。そのタイミングの一つはES6 import がHTTP2で並列ロードのオーバーヘッド無しで解決されるようになるタイミングでしょう。 根本的な問題として、Web周りは標準化の関係で動きが遅いです。最新の仕様ではままならず、ブラウザ間の実装がまちまちで、また開発上の要求が多様なのでプリプロセッサで解決する文化が根付きました。プリプロセッサがいらなくなるぐらい個々の標準が洗練されればプリプロセッサも不要になりますが、そのような未来は、今の動きをみるに、あと15年は来ないように思えます。 とはいえ、ただひとつ言えるの
中間言語としてのJavaScriptはどうなったのか - .mjtの日記復帰計画
prev: http://d.hatena.ne.jp/mjt/20080904/p2 なぜか３年前の記事が急にブックマークされていたのでフォローする記事。 ↑の記事の1年後、InfoQの記事( http://www.infoq.com/news/2009/09/javascript-compilation-target )でいくつかのJavaScriptにコンパイルする言語が紹介された。もちろん、GoogleのGWT(Google Web Toolkit)もJavaScriptを出力するJava環境と言える。 先の記事で触れたエミュレータでの活用は、見たところDirect-threadingによるものに限られているように見える。つまり、CPU命令をJavaScript的なfunctionとして実装し、CPU命令と１対１対応させる。Google V8のような、Direct-threadin
JavaScriptでVM作って「30日でできる！OS自作入門」をやってみた (2日目) - yukobaのブログ
カーネル／VM Advent Calendar の40日目です。ごめんなさい1日遅れ。他の方のも面白いですよ！左のリンクからどうぞ。 私、JavaScriptでVM(仮装機械)を色々作ってきましたが、いつも、言語処理系のVMばかりで、VMwareのような、マシン自体のVMはやったことがなかったので、トライしてみました。 選んだテーマは、川合秀実さんの5年前の名著、「30日でできる! OS自作入門」。これ、凄くいい本ですね！読んでみてびっくりしました。かなりお勧めです。英訳は出ていないと思いますが、英訳を出すに値する本だと思います。でも、川合さんのOSASKは終了（中断？）しちゃっているみたいですね。 30日でできる! OS自作入門 作者: 川合秀実出版社/メーカー: 毎日コミュニケーションズ発売日: 2006/03/01メディア: 単行本購入: 36人 クリック: 735回この商品を含むブ
embona - ブラウザで動くBonanzaを作ってみた(その1)
今回、ちょっとした縁によりBonanzaをブラウザで動かしてみました。Bonanza 6.0のソースコードをほぼそのまま利用して、EmscriptenでJavaScriptに変換しています。 技術的なことに興味はない、すぐに遊んでみたい！という方はこちらからどうぞ。初回に45Mほどダウンロードが発生します！ご注意ください。 http://tkihira.github.io/embona/index.html 上のURLに行くとCPU vs CPUの戦いが始まります。自分で戦いたい方は新規対局で設定してください UI周りは相当手を抜いて実装したために多数バグがあるかと思います。ご容赦ください ブラウザが固まったりしませんが、CPU思考中に手を入力したり新規対局するのには大変反応が重い（というか思考が終わるまで反応しない）のにご注意ください データダウンロードで43Mbyte、さらに内部で展開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - polygonplanet/chillout: Reduce CPU usage by non-blocking async loop and psychologically speed up in JavaScript