Python 3.12で増えた並列処理と、これまでの並列処理の挙動を比べてみる - Qiita
この記事ですることを3行で Pythonの標準ライブラリでできる並列実行を、あらためて総当たりで速度比較しよう ウォーターフォールチャートで、それぞれの並列処理の処理時間の特徴を可視化しよう boto3の実行をモデルケースにして、どの並列処理が一番早いのかを調べよう この記事の結論を先に Python 3.12から本格的に使えるようになったサブインタープリターは、CPUで実行する処理について言えば、従来のサブプロセスよりも高速 boto3の実行は、サブインタープリターよりも署名付きURLの非同期実行のほうが速い → S3からの10ファイルの取得であれば、実行時間を90%削減できます → Bedrockの3回実行であれば、実行時間を60%削減できます 今回使ったソースコードはこちらに置いています。 お手持ちの環境で再実行できるようにしていますので、気になる方はぜひ。 どうしてこの記事を書くの
Qemuのしくみ (の一部) - VA Linux エンジニアブログ
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はコンピ
CPUとGPUのマルチスレッディングの違いについて - arutema47's blog
"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
非同期と並列 / morrita - Message Passing
karino2 が 並列プログラムから見たFuture というビデオを作って公開していたので、引っ越しの荷造りをしながら眺めた。 長いのでここにざっくりとした主張をまとめると: Future/Promise (およびその後釜の async/await) は非同期プログラミングで callback hell にならない発明という見方をされているが、 そもそもなぜ callback hell が必要だったかの時代背景が十分に理解されていない。 背景の一つはブラウザ JavaScript のプログラミングモデルにシングルスレッド・ノンブロッキング(イベントループ)という制限があったから。 これは(特にフロントエンド開発者の間では)よく理解されている。 もう一つの視点は SEDA みたいなマルチスレッド・ノンブロッキング環境の必要性で、 こっちはいまいち広く理解されていないように思える。 結果とし
メモリアクセスのセマンティクスとApple siliconの裏技(?)について - yamasaのネタ帳
アウト・オブ・オーダー実行について補足 前回の記事で「アウト・オブ・オーダー実行」について特に説明せずに話を進めてしまったことに気づいたので、まずはそれについて簡単に補足しておこう。 コンピューターの性能向上の歴史はレイテンシーとの戦いの歴史でもある。 colin-scott.github.io 上のサイトは年代毎にコンピューターシステムでの各種レイテンシーがどのように変化していったかを紹介している。1990年代前半はキャッシュメモリとメインメモリとの間のレイテンシー差はそれほど大きくなかったが、その後の技術革新によって現在はL1キャッシュとメインメモリとの間に100倍くらいのレイテンシー差があるようになってしまった。これはつまり、プログラム実行中にメインメモリへのアクセスが発生してしまうと、それだけ長いレイテンシーの間CPUの処理を進めることができなくなってしまうことを意味する。そのため
「強いメモリモデル」と「弱いメモリモデル」 - yamasaのネタ帳
Apple M1についての面白い記事を見かけて、久しぶりにメモリモデル屋(?)の血が騒いだのでブログを書く。 note.com 強いメモリモデル 現代のCPUアーキテクチャでは、x86(64bit, 32bitどちらも)が「強いメモリモデル」を採用しており、それ以外のメジャーなCPUが「弱いメモリモデル」を採用している。この「強いメモリモデル」「弱いメモリモデル」について、まずおさらいしておこう。 以下のように、2つの変数a, bに対して異なるCPUコアが同時にアクセスしたとする。 int a = 0; int b = 0; CPU1: a = 1; b = 1; CPU2: int r1 = b; int r2 = a; (上記はC言語に似た疑似コードを用いているが、実際は機械語命令になっていると考えてほしい。つまり、CPU1は変数a, bの示すメモリアドレスに対するストア命令を実行して
#76: XPC: Architectural Support for Secure and Efficient Cross Process Call
Huawei の新発表 OS がどんなものか森田が論文を読みつつ想像します。感想などはハッシュタグ #misreading か hello@misreading.chat にお寄せください。iTunes のレビューや星も歓迎です。暇な時はノートもみてね。 XPC: Architectural Support for Secure and Efficient Cross Process Call Huawei Launches New Distributed Operating System, HarmonyOS How Huawei’s Ark Compiler May Improve Android App Performance chipsalliance/rocket-chip: Rocket Chip Generator #05: Agile CPU / Versioned Gol
IntelのCPUで新たな脆弱性「Portsmash」が発見される、ハイパースレッディングに関する2つ目の脆弱性 - GIGAZINE
2018年初めにIntelのCPUで発見された脆弱性の「Spectre」「Meltdown」や、同年8月に見つかった脆弱性「Foreshadow」などを悪意のあるアタッカーが利用すると、PCや一部のスマートフォンのプロセッサにアクセスし、パスワードや秘密鍵といった情報を盗み出すことが可能です。また、この攻撃は従来のセキュリティでは検出または防御することができないということで、大きな問題となりました。「Spectre」や「Meltdown」、「Foreshadow」と同様に、既に流通しているIntel製CPU上に存在する新しい脆弱性「Portsmash(CVE-2018-5407)」の存在をセキュリティ研究者が公表しており、Intel以外のチップメーカーにも影響を及ぼす可能性があるとしています。 GitHub - bbbrumley/portsmash https://github.com/
ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
C++11のスレッド、アフィニティ、ハイパースレッディング | POSTD
背景と導入 何十年もの間、CやC++の標準規格は、マルチスレッディングや並行処理を「その標準の範囲を超えたもの」として扱ってきました。標準規格の目的である”抽象機械”の力が及ばない、”対象依存”という影の世界においてです。メーリングリストやニュースグループの質問には並行処理に関するものが山ほど寄せられましたが、それらにすぐに突き返された回答は「C++はスレッドには関知しません」という何とも冷淡なものでした。この件によって当時のことを思い出す人々は、今後も絶えないでしょう。 しかしC++11の登場で、そんな状況に終止符が打たれたのです。C++標準化委員会は、時代の流れに乗らないと、この先C言語が取り残されてしまうと悟ったのでしょう。彼らはスレッドや同期メカニズム、アトミック操作、メモリモデルなどの存在に、ようやく気付いたわけです。そして標準規格として、C++コンパイラやライブラリのベンダーに
非同期処理の基礎
MPAなWebフレームワーク、Astroの紹介 (その1) 2024/05/17の勉強会で発表されたものです。
Python3 Advent Calender 3日目 - New GIL を理解する - methaneのブログ
2011 Pythonアドベントカレンダー(Python3) - connpass の3日目を担当します。 Python 3 がリリースされてから、 Python の進化は主に Python 3 で行われ、そこから Python 2 にバックポートできるものがバックポートされています（例: GCのチューニング、辞書の内包表記など）。 しかし、 Python 2 は 2.7 で新規開発を終了しており、 2.7 にバックポートされなかった機能はもう Python 3 に移行しないと利用することができません。今日は、そんな機能のひとつである New GIL を紹介します。 なお、今日紹介する内容のほとんどは UnderstaindingGIL で紹介されている内容を僕なりに要約したものです。（ただし、翻訳ではありません） 著作権の扱いがわからなかったのと、代わりに自分で図を書き起こすのが面倒だっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
近未来的並列 LL