Repa (REgular PArallel arrays) Repa provides high performance, regular, multi-dimensional, shape polymorphic parallel arrays. All numeric data is stored unboxed. Functions written with the Repa combinators are automatically parallel provided you supply +RTS -Nwhatever on the command line when running the program. Repa means "turnip" in Russian. If you don't like turnips then this library probably
更新履歴 (2005.11.18) 脚注*2を加筆。 (2005.11.17) 文章を推敲。 (2005.11.14) NMT bit の read barrier について嘘を書いていたので修正。 目次 前置き Pauseless GC Marking Phase Relocation & Remap Phase おしまい 参考文献 Azul Sysmtes (米日) は Java や .NET に特化した専用計算機 Network Attached Processing (NAP) を提唱し、 製品として Azul Compute Appliance を開発した。 Azul Compute Appliance は、 すでに稼動中の Solaris/Linux の J2SE/J2EE システムの Java VM を Azul Systems が提供するスタブ JVM に置き換えるだけで、
大晦日なので，プロセッサを作ってみたい夢を語ってみる． メニーコア向け（100以上） 出来るだけ簡単・小さい できるだけテキスト（バイナリ）も小さい方がいい 同期の仕組みとかどうするかな GPGPU とか，どうなってるのかな？ よくしらない メモリ階層を意識させる設計 ローカルメモリをもつ 外部メモリとの通信はどうしようかな 割り込みとかどうしよう コンテキストの保存，復帰とか 保護とかどうするかな で，スタックマシン再びってのはどうなんだろうなぁ，とずっと考えてる． プロセッサはえらい簡単になる テキスト領域は小さい 「スタック」というローカルメモリがある．自然！ コンパイラは，出来るだけローカルメモリ内に納めるようにがんばる やっぱり，外部メモリとのインターフェースはよくわからん 他のプロセッサとの同期とかどうすんのかね スタックがあふれたらどうすんだろ 関数呼び出しのタイミングで，あ
Linus Torvalds氏は10月20日(米国時間)、Linuxカーネル 2.6.36を公開したことを発表した。64コアCPUのTirelaアーキテクチャのサポート、新しいファイル通知インタフェースのfanotifyのマージ、AppArmorのメインライン採用など、多くの機能追加および変更が実施されている。 2.6.36で実施された主な変更点は以下の通り。 Tirelaアーキテクチャのサポート 新ファイル通知インタフェース「fanotify」 KMSとKDB(カーネルデバッガ)の統合 スレッドプールマネージャによるワークキューの管理 Intel Core i3/5のインテリジェントパワーシェアリングのサポート CIFSにFS-Cache(ローカルキャッシュ)を追加 デスクトップ周りの不具合の改善 (USBストレージへの書き込み速度の向上など) OOM(Out of Memory Kil
米ベンチャーのTileraは、ISSCC 2008にて同社のタイルプロセッサ「TILE64」の詳細を発表した。TILE64の発表は昨年のHotChipsに続いて2回目となる(講演番号4.4:TILE64 Processor: A 64-Core SoC with Mesh Interconnect)。 タイルプロセッサは最近のCPUアーキテクチャ開発の流れの中で新しい視点をもたらしている。コアを沢山実装しているが、その本質はデータフローモデルをベースにしたメッシュネットワーク上のコア間コミュニケーションにあり、この点でマルチコアとは異なるコンセプトのアーキテクチャだ。米国を中心に研究が進められ、MITの「RAWプロセッサ」、テキサス大学の「TRIPS」などが挙げられる。昨年のISSCCでIntelが80タイルプロセッサを発表、その後「Larrabee」というコードネームが与えられて開発が進
The document appears to be a collection of messages and links posted on a forum discussing various programming languages and parallel computing topics, including threads, actors, and memory walls. References are made to languages and technologies like Erlang, Go, Java, Haskell, and Intel's Single-Chip Cloud Computer. The posts also discuss parallelism approaches on different platforms and applicat
この記事の続きになる訳だが、いくらSolaris最強って言っても、大手メーカーがこぞってつつき回して性能改善したり機能追加したりしてるはずのLinuxで何も対策が打たれてない訳が無いよね。じゃあどうなってるんだろう、って話。 例によって、Linuxとか全ッ然知らないので、間違ってたらツッコミ下さい。 ポーリングとパケット処理のパス 殆どここで解説し尽くされてる。 Linuxにも動的ポーリングの実装（Solarisで言ってる動的ポーリングと同じものとは限らないが…）があって、NAPIとか呼ばれてるらしい。 NAPIを実装するドライバでは、こんな手順で受信処理を行ってる。 ハードウェア割り込みを受け、割り込みハンドラを起動 ハードウェア割り込みを禁止、ポーリングをスケジュール ソフトウェア割り込み経由でNAPIのポーリングルーチンを起動 ドライバにポーリングを指示 この時、適切な性能を確保する
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
開発ツールスイート インテル® oneAPI ベース・ツールキット インテル® HPC ツールキット インテル® レンダリング・ツールキット インテルの AI ツール クラウド・プラットフォーム インテル® Tiber™ デベロッパー・クラウド コンパイラー インテル® oneAPI DPC++/C++ コンパイラー インテル® Fortran コンパイラー インテル® Fortran コンパイラー・クラシック NVIDIA*/AMD* GPU 向け Codeplay プラグイン パフォーマンス・ライブラリー インテル® oneMKL インテル® IPP インテル® oneTBB インテル® oneDAL インテル® MPI ライブラリー 分析、解析ツール インテル® VTune™ プロファイラー インテル® Inspector インテル® Advisor インテル® Trace Anal
１．irqbalance概要 FedoraやRHEL,Suseなど多くのLinuxディストリビューションに標準実装されているデーモンで、マルチCPU環境において、IRQ割込み処理を複数のCPU間で負荷分散させることを目的としています。 ２．詳細 Linux Kernelはデフォルトの状態では、CPU0のみでIRQ割込み(ハードウエアからの割込み要求)の処理を行います。しかしそれではIRQ割り込みが頻繁に発生する場合CPU0に負荷が偏りパフォーマンスが劣化する可能性があります。そこでマルチCPU環境でにおいてirqbalanceを導入することで、2nd CPU以降も割り込み処理を行えるようになります。 irqbalanceは、１０秒毎に各CPUのIRQ割込み処理負荷状態状態に応じ、各CPUへのIRQ割込み処理の再配置をおこないます。CPUのIRQ割込み処理負荷状態は"/proc/in
この記事には参考文献や外部リンクの一覧が含まれていますが、脚注による参照が不十分であるため、情報源が依然不明確です。 適切な位置に脚注を追加して、記事の信頼性向上にご協力ください。（2023年1月） ABA問題（英: ABA problem）とは、マルチスレッドプログラミングにおいて同期化の過程で発生する問題であり、ある記憶域を二回読み出し、二回の読み出しが同じ値であることを「変更がない」とみなすことにしたとき、二回の読み出しの間に別のスレッドが値を変更し、他の作業を行った後また元の値に戻すと、最初のスレッドが誤って「変更がなかった」とみなしてしまうというものである。 ABA 問題は、複数のスレッドや(or プロセス)が共有されたメモリにアクセスする場合に生じる。下記のイベントの流れは、ABA 問題を発生させる。 プロセス が共有メモリから値 A を読み出す はプリエンプトされ、プロセス
同期プリミティブ 同期プリミティブで最も重要なことは，実行単位から見て処理がアトミック(不可分)であることである．OS は他のタスクに処理が中断されることがないプリミティブを提供するし，(共有メモリ型)マルチプロセッサを考慮したプロセッサは実行サイクルが不可分である命令を提供する．つまり，クリティカルセクション内では，それぞれ一つのタスク，もしくはプロセッサだけが実行可能になるよう排他制御される． タスク間の同期 セマフォ，ミューテックス，スピンロック，モニタ，select (Unix) など． プロセッサ間の同期 古典的には TAS (Test-and-Set) または TSL (Test-and-Set-Lock)と呼ばれるプリミティブが提供されてきたが，最近のプロセッサではロックフリーなアルゴリズムをサポートするために CAS (Compare-and-Swap) や ll/sc
リード・コピー・アップデート（read-copy-update、RCUと略記）とは、オペレーティングシステムにおいて一種の排他制御[note 1]を実装する同期機構であり、リーダー・ライターロック（英語版）の代替手段として使われることがある。参照において待ち状態が生じず、極めてオーバーヘッドが低い。しかしRCUにおけるデータ更新は、既存の参照者のために古い版のデータ構造を保持しつつ行うため、時間と空間（メモリ）をより多く必要とする。古い版のデータ構造は、既存の参照者が全てアクセスを完了した後で回収される。 RCUでは「参照側クリティカルセクション」という概念があり、通常 rcu_read_lock() と rcu_read_unlock() で挟まれた部分がそれにあたる。参照側クリティカルセクション内にない文は「不活性状態」と呼ばれ、RCUで保護されたデータ構造への参照を保持することは許さ
背景 Omni Graffleなどで作った影の付いた図を、TeXでincludeしたい時がありますよね。 この時、dvipdfmxコマンドを用いてDVI -> PDFの変換をすると、非常に時間がかかることがあります。 図のサイズ等をいじれば多少は処理時間が少なくなりますが、図が汚くなってしまうなんてことも。。。 図の方は変化させずに速く処理を終える方法はないのでしょうか？ dvipdfmxを動かしている時にCPU使用率を見てみましょう。 どうやらdvipdfmxは1コアしか使っていないみたいですね。 ということは、複数のコアで処理を行えば速くできそうです。 （え？1コアしかないCPUを使っている？ うーん、残念ながらそういう人にはこのページの内容は役に立たないかも。。。） ということで、複数のコアに並列にdvipdfmxの処理をさせるシェルスクリプトdvipdfmxpを 作ってみました。
米Microsoft Research、スイスのETH Zurich Systems Groupが共同で「Barrelfish」と呼ばれる分散OSの論文やスナップショットを相次いで公開したことが海外のいくつかのニュースで報じられています。 Microsoft and European researchers deliver a snapshot of multikernel 'Barrelfish' OS | All about Microsoft | ZDNet.com What Windows 8 perhaps should be: Microsoft's multi-kernel OS project | Software News - Betanews Microsoft in a Post-OS World | Blogs | ITBusinessEdge.com Barrel
3.Memory Ordering シングルプロセッサのマルチスレッドでは、volatile変数をフラグにして簡単な同期を書くことができました。 例えば、次のような感じです。（コンパイラはvolatile変数へのアクセスの順序を入れ替えないものとします） volatile int done = 0; volatile struct { int foo; int bar; } foobar; void writer(void) { foobar.foo = fizz(); foobar.bar = bazz(); done = 1; } void reader(void) { int foo, bar; while (!done) sleep(1); foo = foobar.foo; bar = foobar.bar; } これは、マルチプロセッサ環境では上手くいかないことがあります。今時
A parallel implementation of gzip for modern multi-processor, multi-core machines Welcome to the pigz home page. You can download the latest source code right here: pigz source code version 2.8 (19 Aug 2023) in tar.gz format (118K, SHA-256 checksum eb872b4f0e1f0ebe59c9f7bd8c506c4204893ba6a8492de31df416f0d5170fd0, GPG signature) Latest version of pigz and its signature (version-independent links) p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く