)
ゲームのタイミングとマルチコア プロセッサ
XNA デベロッパー コネクション (XDC)、ソフトウェア デザイン エンジニア Chuck Walbourn 著 2005 年 12 月 はじめに 最近のコンピューターで電源管理技術の普及が進んでいることにより、高精度の CPU タイミングを取得するための一般的な方法であった RDTSC 命令が、予期したとおりに機能しない場合があります。ここでは、Windows API の QueryPerformanceCounter と QueryPerformanceFrequency を使用した、より正確で確実な解決策を示します。 背景 x86 P5 命令セットの導入以降、多くのゲーム開発者が高精度タイミングを実行するために Read Time Stamp Counter (タイム スタンプ カウンターの読み取り) つまり RDTSC 命令を使用してきました。Windows マルチメディア タ
AMD Dual-Core Optimizer - NyaRuRuが地球にいたころ
未だに RDTSD 使ってるゲームって，結構あるんですかね？ AMDは，本社が運営する英語版Webサイトで，Athlon 64 X2をはじめとする同社製デュアルコアCPU用ユーティリティ「AMD Dual-Core Optimizer」を公開した。同サイトのサポート用ページ「AMD Athlon 64/FX Processor Utilities and Updates」からダウンロード可能になっている。 AMDによると，AMD Dual-Core Optimizerは「RDTSC命令を用いるいくつかのゲームにおいて，パフォーマンスを向上させる」ものだそうだ。 そう言われても多くの読者はさっぱりだと思うので，簡単に説明しておこう。最近のCPU（正確にはx86互換CPU）には，クロックごとに数が増える独自のカウンタ「TSC」（Time Stamp Counter）が用意されている。そして，「
Windows 7/Windows Server 2008 R2 が 256 プロセッサまでしか "対応" しない理由を予想する - NyaRuRuが地球にいたころ
最大CPU数が4096、最大ノード数が512まで拡大されました。 Windows7 の 256 プロセッサ対応は全然負けてるねw x86の最大CPU数、最大ノード数が拡大 最大CPU数が4096、最大ノード数が512まで拡大されました。当面はSGIのx86_64スパコンくらいでしか意味がなさそうですが、カーネルデベロッパーから見ると、事実上、cpumask_t変数をスタックに置くことが全面禁止になってしまったことを意味します（スタックが4Kbytesしかないのに、1変数あたり512bytesの変数を置くなんて……） そういえば，昨晩の WinHEC 2008 2日目のキーノートで，Windows Server 2008 R2 を使った 256 CPUs デモが行われていた． http://wm.istreamplanet.com/customers/ms/750_ms_winhec_081
Game Timing and Multicore Processors - Win32 apps
With power management technologies becoming more commonplace in today's computers, a commonly-used method to obtain high-resolution CPU timings, the RDTSC instruction, may no longer work as expected. This article suggests a more accurate, reliable solution to obtain high-resolution CPU timings by using the Windows APIs QueryPerformanceCounter and QueryPerformanceFrequency. Background Recommendatio
Develop/Timer - SyncHack
Windows の Timer について † 結論：正確な時間計測には QueryPerformanceCounter(), QueryPerformanceFrequency() を使いなさいってこった。 High Performance Timing under Windows (http://www.devsource.com/ ) 元ネタ。 GetTickCount()、SetTimer() + WM_TIMER † Windows はリアルタイム性を強く求めていないので、Timer としての精度は悪い。 WM_TIMER の優先順位はかなり低く、他のプロセスに CPU パワーの優先順位が高く割り当てられている等の場合、100ms 程度の制度しか期待できない。システム全体のパフォーマンスの均一化によるパフォーマンスの向上を考えると一概に悪い仕様とは言えないだろう。 逆に 100ms
Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X
See also my blog Contents Optimization manuals Vector class library Object file converter and disassembler Subroutine library ForwardCom: An open standard instruction set for high performance microprocessors Test programs for measuring clock cycles in C++ and assembly code Floating point exception tracking through NAN propagation CPUID manipulation program Links Optimization manuals This series of
K10 vs CoreMA
という感じで、「k10 < Nehalem << Sandy」ぽい雰囲気を感じられるかと。(あと-mtune=nativeはあまり変わらんというか、若干悪くなってるというのも) メモリの影響少なそうなblackshcoles、raytraceでもSandy、NehalemのほうがIPCよい。 なので、たまに見かける「コアは互角だが、キャッシュ良いからIntel勝ってる説」は、あまり信憑性無いのではないかと思う。 fluidanimate 一番差の大きいfluidanimateから見ていく。粒子法の流体シミュレーション。 perf annotate -l した結果が、 === a8 === Sorted summary for file /home/w0/src/parsec-2.1/pkgs/apps/fluidanimate/inst/amd64-linux.gcc/bin/fluid
gccにおけるatomic操作命令の個別関数
gccとVC x86/x64環境で開発する上で, gccとVCはどちらも非常に優れたC/C++コンパイラです. ただLinuxとWindowsのどちらの環境でも動作するようなC/C++コードを書くためには, gccとVC, およびそれらが動作するOSの違いが問題になることがあります. ここではそれらの違いについてまとめていきたいと思います. なお説明を簡単にするためにマクロを多用していますが実際には可能なら別の手段をとるか, 名前がぶつからないような命名規則に則ったマクロ名をつけることをお薦めします. 対象 定義済みマクロ 有用なマクロ コンパイルオプション 演算子の代替表現の抑制 日本語のコメント 型 pragma attributeとdeclspec ファイル入出力 テキストとバイナリ 巨大なファイル static変数の初期化 snprintf 例外ハンドラ intrinsic関数
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
