- - PR -
C# 整数の数値計算時のパフォーマンス
1
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-07-05 10:01
昔「変数を宣言する場合は、厳密に上限値に見合った型を定義し、
コンパイラに可能な限り多くの情報を引き渡すよう努めなさい。」 と教えられました。 つまり、数値の上限が255以下であればbyte型、6555以下であればshort型を宣言し、 数値の下限が負にならない場合はunsignedを付与することが"行儀が良い" とされていました。処理系が8/16bitの時代の話ですが、確かに省メモリで高速な 処理をする場合に当時としてはある程度有効でした。 最近ある人から「多くのパソコンが32bitマシンなので、通常は32bit長であるint型 で代用したほうがむしろ効率よく処理できる。」と聞きました。 質問１ 整数の数値計算をする場合、メモリが十分用意されているなら、 通常は全てint型で代用したほうがむしろ高速なのでしょうか？ 質問２ 整数型(例 int型)と浮動小数点型(例 float)を混在させた数式を記述するより 全て浮動小数点型(例 floatのみ)に直した数式を記述するほうが高速なのでしょうか？ 質問３ 推奨されるガイドラインのような情報はあるのでしょうか？ あるいは、この種の疑問に答えてくれる情報はあるのでしょうか？ | ||||||||
|
投稿日時: 2006-07-05 10:29
質問１ ,２
簡単な テストを走らせて 検証できます。１００行かからない。 質問３ 一般人はそのような質問をしない。C# 設計の直接目標じゃないから 「整数の数値計算時のパフォーマンス 」 最高パフォーマンス を求める人々には C# 以外の選択がありえる =============== 高性能 商用数値計算ライブラリは C# からも呼び出せます。 その他 検索語 swig yaneurao は C#2.0時代のゲームプログラミング とか Yanesdk.NET [ メッセージ編集済み 編集者: MMX 編集日時 2006-07-05 10:40 ] | ||||||||
|
投稿日時: 2006-07-06 10:06
ご回答ありがとうございます。
大型の行列演算については今でもベクトル演算機が搭載されている非Windows機で Fortran+数値計算ライブラリを用いています。ベクトル化率が稼げる場合、 Windows機よりも数倍は高速です。コンパイラについても最適化についての 詳細な情報が得られます。ただ、オリジナルな解析ソフトを試作する場合や GUIを重視したい場合はC#の生産性の高さに魅力を感じます。 C#コンパイラの最適化および数値計算時の.NET Frameworkの基本的な 振る舞いについてあらかじめ知っておくことができれば、コーディング の段階で最適化できるため有益であると思い質問を試みました。 ご指摘の通り数値計算をメインターゲットにしている処理系では無いので 計算パフォーマンスに関心があるユーザーはごく少数なのかも知れませんね。 | ||||||||
|
投稿日時: 2006-07-06 10:55
＞ ただ、オリジナルな解析ソフトを試作する場合や
GUIを重視したい場合はC#の生産性の高さに魅力を感じます。 「生産性の高さ」には何かの代償を支払うことになる。 ＞ コーディング の段階で最適化できるため有益であると思い質問を試みました。 「生産性の高さ」を求める方向性と少し矛盾。 万能言語は無い。 数値計算なら、 C++の型の魔界にダイビング、C++/CLI（かなり特殊な言語であり、C#では簡単に出来そうにないことが出来たりする。）も アクセスの局所性に注目 JUDY ARRAY asm{ } に習熟、単精度に再注目で Cell や GPU に飛び込む ソフトはもういい、LSIに直接焼く方向(リコンフィギャラブル や GRAPE) など最近はハード化の傾向が強いのでは？ =================＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 「もう負荷分散は必要ない」---1台で同時50万接続のWebサーバーが登場 http://itpro.nikkeibp.co.jp/article/NEWS/20060707/242757/ ソフトを ハード化して 売る時代 に入りました。 U3準拠のUSBメモリ http://pc.watch.impress.co.jp/docs/2006/0707/sandisk.htm [ メッセージ編集済み 編集者: MMX 編集日時 2006-07-11 10:27 ] | ||||||||
|
投稿日時: 2006-07-06 11:00
ということなら、演算部分をライブラリ化して C# で書いた GUI から呼び出せばいいのではないでしょうか。 | ||||||||
|
投稿日時: 2006-07-06 11:10
GPU や PhysiX 等、そういう方向性もみられますね。 ただ、そういう場合でもハードに乗せる演算を試験的にソフトウェアで実装することはあり得る話です。 ですが、そういった場合は「演算手法が正しいこと」を検証するのが第一の目標であり、実用的な時間内に計算が完了するのであれば、必ずしも「計算機の演算能力を最大限に引き出す言語」で実装する必要は無いはずです。 とは言うものの、具体的な演算処理の内容も明らかではなく、どれくらいの計算時間を「実用的」とみなすかの基準も状況によって異なるため、「実際に試してみてください」としか言いようがないのが現実かと。 _________________ // 渋木宏明 (Hiroaki SHIBUKI) // http://hidori.jp/ // Microsoft MVP for Visual C# // // ＠ＩＴ会議室 RSS 配信中: http://hidori.jp/rss/atmarkIT/ | ||||||||
|
投稿日時: 2006-07-06 11:15
こんにちは。
もう解決しているようですが。 MMXさんもおっしゃられていますが、生産性の高さとソフトウェアチューニングでのパフォー マンスは相容れないものがあるように感じます。 カリカリに最適化したコードが見づらい（メンテナンスしにくい）ので、多少パフォーマンスを 犠牲にしても生産性の高いコードを書くような、そして昨今のハードウェアの性能向上で その部分は補填されていると考えています。 あとは
は、ある程度コンパイラの動きを知っているからこそできる技で、現在のコンパイラがどの ような最適化をしているかはあまりわからないのではないかと思います。むしろ余計なこと をしてコンパイラの最適化のジャマをしてしまう可能性もありますし、それならば（コンパイ ルしたコードの）最適化はコンパイラに任せて、人間はメンテナンスしやすいように「人間 向けの最適化｣を行う方が良い、というのが自分の考えです。 （プロファイラを使うなどの人間が出来る最適化?もありますが） 結局のところ、どういう処理が行われているかはコンパイラのみぞ知るような状態だったり するので
が素直かつ効率的なやり方なのではないかと。 # あああなんか書いてたらひどりさんに先を越されてた orz | ||||||||
|
投稿日時: 2006-07-07 11:00
それぞれのCPU命令に何クロック必要かという資料なら、CPUメーカーから公開されていますよ。ただしC#が生成するのはあくまでCLIなので、どのようなCPU命令が実行されるかは想像力で埋める必要がありますが・・・。 質問１ x86の場合、32bitCPUではDWORD境界に変数が配置されていないと、メモリからレジスタに読込むときにペナルティがかかるんですよ。だからコンパイラは可能な限りDWORD(最近はDDWORD？)境界にそろえようとします。BYTE型変数を用いると言うことは、DWORD境界に配置されない可能性も増えるわけで、遅くなる可能性を暗示しています。単純に演算だけを行うベンチマークでは殆ど差は出ないでしょうけど。 質問２ そりゃ整数型から不動小数点型に変換するにも時間がかかるからね(^^; でも本当にぎりぎりのチューニングが必要ならSSE命令使ったり、DSP乗せたり、GPUやPPUに任せたりするでしょ。UIとロジックは分離させるのが普通だし、生産性が欲しいならUIだけをC#で作ればよい。C#で演算処理まで作ってピーキーなチューニングを施す必然性は無いよね。 | ||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。