1. 細々とした予備知識 1.1 Qemuのデバイスエミュレーション 1.2 QemuのCPUエミュレーション 1.3 Qemuのスレッド 2. 追加のI/OスレッドとAioContext 2.1 追加のI/Oスレッド 2.2 AioContext 2.3 Big Qemu Lock 3. AioContextの各種イベント処理 3.1 AioHandler 3.2 event_notifier 3.3 タイマー、Bottom half 3.5 スレッドプール 執筆者 : 箕浦 真 こういう 仕事をしていると、ときどきQemuの仕組みや内部動作をお客様に説明する必要があることがあるが、そういう時に「Qemuの〜についてはここを見てね」と言えるような文書があるといいなぁと思って自分で作ってみることにした。 1. 細々とした予備知識 1.1 Qemuのデバイスエミュレーション Qemuはコンピ
"Locality is efficiency, Efficiency is power, Power is performance, Performance is King", Bill Dally マルチスレッディングとは？ CPUとGPUのマルチスレッディングの違いをブログにまとめていたけど例によって誰も興味なさそう— arutema47 (@arutema47) 2021年8月16日 つぶやいたら読みたい方が多そうだったので完成させました。 マルチスレッディングとはメモリ遅延を隠蔽しスループットを上げるハードウェアのテクニックです。 ただCPUとGPUで使われ方がかなり異なるため、その違いについて考えてみる記事です。 （SIMDについて並列プログラミングの観点から触れるべきでしたが、時間無いマルチスレッディングに注目するため初版では省きました。） 本記事について 本記事はCPUとG
Arm入門勉強会とは、macOSがArmに移行したこの機にArmアーキテクチャでのプログラミングについて入門するソフトウェアエンジニアのための会です。今回主催の@nullpo_head 氏が、Armの仮想化支援機構について、その仕組みから深く説明します。前半は「現代のハードウェア仮想化支援機構」について。全２回。 ハードウェア仮想化支援とは何か 佐伯 学哉氏：入門セッション3つ目は『Armの仮想化支援機構』についての入門セッションです。どうぞよろしくお願いします。 本発表のスタートとゴールです。VMwareとかQemuとか使ったことあるけど仮想マシンの仕組みなんも知らんというところがまずスタートになっています。 1個目のゴールは、最近のVMのざっくりした仕組みとハードウェア仮想化支援とは何かということがわかること。そしてその話のあとに実際にArmの仮想化支援機構の概要を説明し、Armの仮想
Node.js Performance 改善ガイド Memory の場合 メモリリークかどうかを特定する メモリリークではない場合 CPU の場合 どこの処理に時間がかかっているのかを確認する v8 simple profiler flame graph を取得する File の場合 大きなサイズのファイルをどうしても扱う時 Network の場合 keepalive を on にする その他: 全体的にパフォーマンスを改善するためにやること JIT が効いているかを確認する clusterが使えないか検討する C++ addons vs JavaScript libraries まとめ 参考資料 Node.js Performance 改善ガイド この記事は Node.js 2 Advent Calender の 5日目の記事です。 qiita.com Node.js のパフォーマンスに
9. 9 最適化について 「細かい効率のことは忘れて、時間の 97% について考え よう。時期尚早な最適化は諸悪の根源だ。それでも残り 3% についても機会を逃すべきではない」 - Donald E. Knuth 「プログラム最適化の第一法則 : 最適化するな。 プログラム最適化の第二法則 ( 上級者限定 ): まだするな。 」 - Michael A. Jackson 11. 11 最適化の対象 主に Intel の Haswell マイクロアーキテクチャ以降を対象 多くのテクニックは他のプロセッサにも応用できます ベース マイクロアーキテクチャ プロセスルール 登場年 Nehalem Nehalem 45nm 2008 〃 Westmere 32nm 2010 Sandy Bridge Sandy Bridge 32nm 2011 〃 Ivy Bridge 22nm 2012 Hasw
iOS8のリリースにより、A7を搭載したiOS端末からはOpenGLESに代わる新グラフィックスAPIであるMetalが動くようになりました。 iOS8発表時のAppleのKeynoteで紹介されたとおり、MetalはOpenGLとくらべてAPIの層が薄くて最適化されているので高速に動作するようで、他の多くの記事でもこの事が書かれています。 しかし実際にMetalに触れてみると、単にAppleのハードウェアに最適化されていてオーバーヘッドが低く速いということに留まらず、ある一つの特長に気付きます。 それは「shared CPU/GPU memory buffer」つまりCPU/GPU間でメモリが共有されているというものです。 ここでは今までiOSの３Dアプリケーション開発に利用されていたOpenGLESでのメモリの扱い方と比較しつつ、CPU/GPU間でメモリが共有されることのメリットについ
4. ThreadよりもTask for (int i = 0; i < num; i++) { var t = new Thread(_ => b[i] = F(a[i]) ); } for (int i = 0; i < num; i++) { Task.Run(() => b[i] = F(a[i]) ); } ×悪い例 ○良い(まだマシ※な)例 データの数だけ スレッド作成 Threadでなく Task利用 ※ この場合、ParallelクラスやParallel.Enumerableクラスが使いやすい 5. ThreadよりもTask for (int i = 0; i < num; i++) { var t = new Thread(_ => b[i] = F(a[i]) ); } for (int i = 0; i < num; i++) { Task.Run(() => b[
カメラが好きなオヤジのブログ。最近は、Androidアプリ開発もやってます。OpenGLやWebGLもありー＞ 本日は、VBOの話をしようと思う。 VBOはVertex Buffer Object。頂点データをバッファオブジェクトでGPU側で管理する方法。Android端末には、CPUとGPUが搭載されており、どちらも計算を行うのだが、GPUはグラフィックス周りの計算に特化している。 OpenGLによる3Dグラフィックスは、GPUを使って計算処理されることが多い。 GPUはグラフィックスの計算に特化しているので、グラフィックス処理ならCPUより高速に実行できる。ハードウェア回路で必要な計算ができるようになっている。 CPUとGPUの違いは、グラフィックス処理に特化しているかどうかだけ。基本的なしくみは変わらない。CPU、GPUの内部には計算のためにレジスタが存在しているが、レジスタの数は多
この脆弱性は2012年5月7日にリリースされた MySQL バージョン 5.1.63 と 5.5.24 において修正されました。認証時に指定するパスワードは何でもよく、認証要求を繰り返すと一定確率でログインが可能というかなり奇妙な脆弱性です。すべての環境において発生するわけではありませんが、攻撃成立時には深刻な影響を受けます。 該当するバグチケットは以下です。リリースバージョンも同様の修正でした。 MySQL Bugs: #64884: logins with incorrect password are allowed Rapid7 により PoC や影響が確認された環境等が纏められています。 CVE-2012-2122: A Tragically Comedic Security Flaw in MySQL アプリケーションに対するコード修正は1行のみ、発生する環境が限られている、非常
別にグラフィックスに限ったことじゃないし、そもそも論文とか全然関係ないけど。GPU 周りでもたまに話題になるし、自分でもたまにわけわからんくなるから整理しとく。 メインメモリは遅い CPU からメインメモリにデータを読みに行く場合、これはとにかく遅い。例えばレジスタにあるデータを読みに行く場合と比べると、だいたい数倍から数100倍の遅さ。ヤバいからなんとかしよう。もっと早くアクセスできる場所にデータおいとこう。 キャッシュライン CPU がメインメモリからデータを読み出すとき、必ず小さなメモリチャンクをキャッシュ上にロードする。ロード単位はプロセッサによるけど、だいたい 8 ～ 512 バイト。このロード単位をキャッシュラインと呼ぶ。 アクセス対象のデータが既にキャッシュに載ってる場合は、メインメモリじゃなくてキャッシュを読みに行く。ない場合はメインメモリにアクセスするけど、そのデータはも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
