- 1 名前：名前は開発中のものです。 mailto:sage [2009/04/03(金) 11:25:39 ID:aSgRO8Wl]
- タスクシステムについての議論、相談、質問、雑談などのスレです
part5 pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 pc11.2ch.net/test/read.cgi/gamedev/1173708588/
・タスクと呼ばれる実装は、非常に多岐に渡ります
古典タスクシステムについての話題は「>>2」と明示してください
そうでない場合はカスタム版であることを明示してください
・人を憎んで言語を憎まず
- 30 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 05:50:57 ID:SofMJMSf]
- どうせタスクの中で他のタスクにアクセスするだろうし、
そんなところをちまちま最適化しても意味無いって。
どうせ他のところが重いから。
- 31 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 06:04:17 ID:SofMJMSf]
- だいたい、市販ゲームでも、メモリコンパクションしているゲームってそんなに無いだろ。
やってる奴あっても、メモリ制限が厳しいから仕方なく導入しているってだけで、
速度向上を狙ったものは聞いたことが無い。
- 32 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 06:14:40 ID:KXq+7Jyb]
- >>30
> そんなところをちまちま最適化しても意味無いって。
そんなことないよ。
最近のプロセッサになればなるほどDRAMが(CPUに較べて)相対的に遅く、
扱うオブジェクトの数が多いとプリフェッチ出来ているのと出来てないのとでは大違いなんだが。
「他のタスクにアクセスする」部分にしても、シューティングで自機と弾との衝突判定をするなら
弾オブジェクトはメモリ上でリニアに並んでいるほうがアクセス効率が良いのは自明。
- 33 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 06:19:31 ID:KXq+7Jyb]
- >>31
> やってる奴あっても、メモリ制限が厳しいから仕方なく導入しているってだけで、
あんた何もわかってないね。
近代的な言語が、GCを搭載するのはメモリ制限を回避するためだけかい？違うだろ。
- 34 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 06:35:18 ID:SofMJMSf]
- 何も分かってないのはお前だって。
タスクシステムのタスクのコンパクションによるキャッシュヒット率の向上が有効になるのは、
小さなタスクが何万も有る場合だが、
タスクシステムの特性から、updateが仮想関数になる以上、
やってる事がチグハグなんだよ。
ストーブつけながらクーラーつけてるみたいなものだな。
- 35 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 06:36:15 ID:XP6NPTaD]
- DRAMメモリアクセス速度みたいなハード寄りな理由で近代的なGC搭載言語の話をするのは何かずれてるような…
- 36 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 06:59:38 ID:KXq+7Jyb]
- >>34
> タスクシステムの特性から、updateが仮想関数になる以上、
そうとは限らない。
>>35
ずれてない。あんたもGCが何のためにあるのか理解してなさそう。
- 37 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 09:37:40 ID:w7j54ekv]
- 並列さん黙れよ
あんた自分がなにやってるかさっぱりわかってないじゃん
- 38 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 11:11:35 ID:3oSTBu7p]
- ＞タスクシステムの特性から、updateが仮想関数になる以上、
･･･ﾊｧ????
- 39 名前：名前は開発中のものです。 [2009/04/05(日) 14:46:01 ID:ZnQmmsrk]
- 並列さんは、updateのなかで型を見ながらswitchするつもりなんじゃね？
- 40 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 15:41:58 ID:MilQiQIm]
- 久しぶりに来たら次スレ建ってて笑った。
相変わらずタスクじゃない話題で賑わっているね。
メモリコンパクション実装する前に他にやることあるんじゃねぇの〜
- 41 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 18:18:06 ID:KXq+7Jyb]
- >>37
あんたがわかってないだけ。内容についてこれないなら、黙れ。
>>39
そんなへたれなコードはさすがに書かない。
template typename<T> update(T& actor);
こういうtemplateを用意して、これが呼び出される。(以下略)
>>40
> メモリコンパクション実装する前に他にやることあるんじゃねぇの〜
他にやることはやってあるという前提で話している。
また>18で書いたようにこれはタスクと関係ない話題ではない。
- 42 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 18:25:43 ID:KXq+7Jyb]
- 戻り値の型を書き忘れた。こう。
template typename<T> void update(T& actor);
で、型ごとに特殊化されたupdateを用意する。
言うまでもなく、updateはcollectionに対しても定義されてて
template typename<T> void update(const collection<T*>& actors)
{
foreach(var t in actors)
update(*t);
}
collectionはstd::vector/listを汎化したもの。foreachはマクロとでも思ってもらえれば良い。
上のようになっているので、最適化によってinliningされる。
もちろん、関数呼び出しのオーバーヘッドは存在しない。
- 43 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 18:25:46 ID:MilQiQIm]
- >>41
1点だけ知りたいのだが、並列さんはタスクシステムをメモリコンパクション仕様で書いて実装し、実際に運用したことがあるのかい？
必然的に粒度の大きくてしかもタスク切り替えの少ない場合のみのタスクしか適用できないとおもうのだが。正気の沙汰とは思えない。
- 44 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 19:25:11 ID:ZnQmmsrk]
- >42
> もちろん、関数呼び出しのオーバーヘッドは存在しない。
全てのTに対して同じupdateが呼び出されるけどな。
- 45 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 20:48:32 ID:KXq+7Jyb]
- >>43
> 1点だけ知りたいのだが、並列さんはタスクシステムをメモリコンパクション仕様で書いて実装し、実際に運用したことがあるのかい？
もちろんだよ。ある大手の商用ゲームで使ってるよ。
> 必然的に粒度の大きくて
逆だよ。GC環境は粒度の小さいオブジェクトを大量に
newしたりdeleteしたりするのに適している。
それは、GC環境下ならnewの実装が単純化されるので
通常のheap allocとは比べものにならないほど高速だから。
>>44
もちろん。update(const collection<T*>& actors)の呼び出し側で
もうひと工夫してある。あんたなら、みなまで言わずともわかるだろ。
- 46 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 22:29:45 ID:qdg6blW7]
- テクスチャとか、でかい連続領域が欲しいときにメモリコンパクションしたくなるのは
まぁわからんでもないんだけど、 new/delete する C++ オブジェクトの話だったの？
そうなるとまるで必要性がわからん。
だれか並列さんの話についていけてる人がいるのか？
- 47 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 22:43:11 ID:ZnQmmsrk]
- >45
あぁ、switch〜caseじゃダメっぽいから、関数テーブルにでも変更してみたか？
- 48 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 22:44:01 ID:KXq+7Jyb]
- >>46
> そうなるとまるで必要性がわからん。
"必要"なのではない。誰もそんなことは言っていない。
GCがあったほうが設計が楽になるというのと、
メモリのコンパクション(とオブジェクトの並び替え)を行なったほうが
メモリアクセスの効率が上がる(>>26 >>29 >>32)と俺は言っている。
- 49 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 22:45:59 ID:XP6NPTaD]
- >>45
>それは、GC環境下ならnewの実装が単純化されるので
”GC環境”ってひとくちにいっても”タスクシステム”並に千差万別だけど…
どんな前提のGC環境なら、GC環境を構築したC/C++よりもheap allocが高速になるのか、教えて欲しいなぁ
スレッドを使わないスクリプト系言語で、同期処理が不要だから、とかheap独自管理だから、とかか？
それならスレッド使わない、heap独自管理したC/C++系の方が高速になりそうだが。
- 50 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 22:48:37 ID:SofMJMSf]
- >>42
それだったら、ただのstd::vectorと同じじゃん。
自分でも書いてるけど、本当ただのcollectionでしかなく、どのあたりを工夫しているのかも不明。
そのレベルのコンパクションでよいのなら、std::vectorでもしてくれる。
個人的には、タスクシステムにメモリ管理までさせている時点で糞だな。
タスクを何処にどういう風に確保するかは、タスクシステムの利用者が決めれるようにしておいた方が良い。
どういうメモリ配置にすべきかはケースバイケースで、
ベストな配置はゲームの仕様を知ってるであろうタスクシステムの利用者にしか分からない。
逆に言えば、タスクシステム内で、変なメモリ管理なんてしようとするから、
メモリコンパクションなんていう、どうでも良いことを考えなきゃいけなくなる。
ゲームの仕様も分からないのに、適切なデータ配置が出来るわけが無い。
まぁ、そうやって自分の権力の範囲を伸ばすことで、食いっぱぐれないようにしてるんだろうけどな。
老害というやつだな。
- 51 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 22:51:31 ID:SofMJMSf]
- もう一度いうが、キャッシュヒット率まで考えてデータの配置をするというのなら、
タスクシステムに勝手にデータを並べ替えられるのは迷惑だ。
タスクシステムはゲームの仕様を知らないからな。
- 52 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 22:54:56 ID:qdg6blW7]
- "Premature optimization is the root of all evil" ってやつだな。
こういう話してると、また「言うまでもなく、この最適化を行うかどうかはユーザーが
選択できるようになっている」とか返ってきそうだけど。
- 53 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 22:55:09 ID:KXq+7Jyb]
- >>47
> 関数テーブルにでも変更してみたか？
関数テーブルがどういうコードを指してるのか意味不明なんだが。
もしかして
var function_table = [ update<collection<TekiTask*> > , update<collection<TamaTask*> > , update<collection<JikiTask*> > ];
みたいなものを用意する話か？それなら、テーブルではなしに、
TekiTask* → update<collection<TekiTask*> >
のようなhashこそが必要だろう。
「タスクの型Tからupdate<collection<T*> >へのhashを用意してあるのか？」と尋ねるのなら、
「そういう実装でもいいけどね」と答えるが、「update<collection<T*> >の関数テーブルを用意するのか？」と
いう質問なら、「そんな馬鹿な実装にはするはずがない」と答えるよ。
- 54 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 22:57:12 ID:SofMJMSf]
- >template typename<T> void update(T& actor);
はインライン関数で書いても同じなのに、いちいちテンプレート使うのはコンパイラへの嫌がらせか。
わざわざテンプレートでかく意図が分からない。
コンパイラによるのかもしれんが。
- 55 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:04:40 ID:qdg6blW7]
- >>53
メモリアクセスの最適化が要るループの中でインスタンス単品のアドレスをキーにした
ハッシュテーブルをひくのが「いいけどね」なの？もうわけわからん。
- 56 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:07:06 ID:KXq+7Jyb]
- >>49
> どんな前提のGC環境なら、GC環境を構築したC/C++よりもheap allocが
> 高速になるのか、教えて欲しいなぁ
日本語が意味不明。
俺は、>>45 では、GC環境なら、C/C++のheap allocより高速なnewの実装が可能に
なることは言ったが、「GC環境を構築したC/C++よりも」だなんて一言も言ってない。
>>50
> そのレベルのコンパクションでよいのなら、std::vectorでもしてくれる。
これも意味不明。
std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
全部そこに突っ込む(push_back)するつもりか？
> ゲームの仕様も分からないのに、適切なデータ配置が出来るわけが無い。
その理屈はおかしい。
あんたはゲームの仕様が決まるまでnewやdeleteの実装をしないつもりか？
- 57 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:20:19 ID:KXq+7Jyb]
- >>55
> メモリアクセスの最適化が要るループの中でインスタンス単品のアドレスをキーにした
> ハッシュテーブルをひくのが「いいけどね」なの？
「メモリアクセスの最適化が要るループの中で」呼び出すだなんて
俺は一言も言ってないんだが。
どうやれば本当に効率が改善されるのか自分の頭を使って考えたらどうだ？
- 58 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:21:29 ID:XP6NPTaD]
- >>56
>俺は、>>45 では、GC環境なら、C/C++のheap allocより高速なnewの実装が可能に
>なることは言ったが、「GC環境を構築したC/C++よりも」だなんて一言も言ってない。
矛盾した返答だなぁ
そのGC環境は比較対照のC/C++とは違うアーキテクチャのマシンで動いているのかい？
同じマシンならその高速とやらのheap allocと同じ原理を、高級アセンブラであるC/C++なら実装可能だろ。逆は無理だけど。
GC環境とやらがネイティブのC/C++(≠ASM)にパフォーマンスで勝負するのは勝ち目が無いんで無い？
- 59 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:22:09 ID:ZnQmmsrk]
- >53
C++っぽいけど全然違う脳内言語を使って脳内コンパイルしてるだけなら、その程度の話でいいのかもね。
- 60 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:24:28 ID:SofMJMSf]
- >>56
>その理屈はおかしい。
>あんたはゲームの仕様が決まるまでnewやdeleteの実装をしないつもりか？
その理屈でいくのなら、自前のcollectionなんて実装せずにnewやdeleteを使ってれば良い話になるだろ。
ところがお前は、newやdeleteはタスクシステムの仕様に無頓着だから、
タスクシステムの仕様にあったアロケータを自前で開発すべきだと主張してる。
それに対して俺は、タスクシステムはゲームの仕様に無頓着だから、
ゲームの仕様にあった方法でデータは確保すべきだ、と返しているわけで。
- 61 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:30:02 ID:qdg6blW7]
- >>56
> std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
> 全部そこに突っ込む(push_back)するつもりか？
その vector をまっすぐ走査すればキャッシュヒット率の目的は達成できるよね？
何かマズイの？
> あんたはゲームの仕様が決まるまでnewやdeleteの実装をしないつもりか？
いや、しないだろ、当然。コンパイラが一般的な実装は提供してくれるんだから。
ゲームの仕様がなければ自分で実装する目的が無い。
- 62 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:31:38 ID:KXq+7Jyb]
- >>58
何か話が噛み合ってない気がする。
俺が想定しているGC環境でのmallocは、次のコードだ。
void* malloc(size_t size)
{
void* adr = (void*)heap; // heapはbyte*
heap += size; // この分、確保した
return adr;
}
これはGC環境下ではないC/C++で書くカスタムアロケータより
十分高速だと思うが、これより速い実装が可能だと言うなら教えてくれ。
- 63 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:34:08 ID:KXq+7Jyb]
- >>62
自己レスだが、メモリを上位から下位に確保していくheapなら
void* malloc(size_t size)
{
heap -= size; // この分、確保した
return (void*)heap;
}
こうなる。こっちでもいい。
- 64 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:34:12 ID:qdg6blW7]
- >>57
collection の要素型がポインタになってるけど、別に派生クラスとか update の詳細が
異なるインスタンスをいっしょに入れるわけじゃなくて、単一クラスのコレクションなの？
それなら、なおさら std::vector に生で入れたほうが速そうだなぁ。
- 65 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:36:14 ID:XP6NPTaD]
- >>62
あのー、これheap allocでなくstackでない？
- 66 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:37:09 ID:w7j54ekv]
- どう考えてもゲームの仕様依存の問題にここまでしつこいのって馬鹿じゃね？
設計失敗してるのにねばってて馬鹿みたい
プログラマやる前にまず大人になれよｗ
- 67 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:38:02 ID:SofMJMSf]
- >std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
>全部そこに突っ込む(push_back)するつもりか？
型ごちゃまぜ状態でコンパクションかけるよりは、
同じ型は同じ配列に集めてコンパクションかけた方が、まだましだろう。
同じ型のデータは連続的にアクセスされる可能性が高いからな。
型ごちゃ混ぜ状態でコンパクションかけますっていうのなら、
頭どうかしてますとしか言いようが無い。ゲームでそこまでする必要なし。
- 68 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:41:04 ID:KXq+7Jyb]
- >>60
なんか話が噛み合ってない原因がわかった。
> ところがお前は、newやdeleteはタスクシステムの仕様に無頓着だから、
> タスクシステムの仕様にあったアロケータを自前で開発すべきだと主張してる。
俺は最初からそんなことは主張していない。
GC環境下のほうが、小さなオブジェクトの生成/解体には有利で、
どうせGCを搭載するなら、コンパクションをやるついでにタスクの再配置も
したほうがCPU cacheの効率があがるということを主張している。
- 69 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:42:24 ID:KXq+7Jyb]
- >>65
> あのー、これheap allocでなくstackでない？
それがGC環境下のheap allocだよ。
定期的にGCがメモリのコンパクションを行なうから、heap allocはただひたすら
メモリの上位(or 下位)に向かって確保していくだけでいいんだ。
- 70 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:43:40 ID:w7j54ekv]
- なんで話がかみ合ってないとか言い出すの？
もう疑いようもなく頭悪いのにｗ
なんでかみ合ってないとかやめてよ
きたねぇなさわんなよ気持ち悪い
- 71 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:44:27 ID:KXq+7Jyb]
- >>66,70
馬鹿はお前。話についてこれないなら黙れ。
- 72 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:44:39 ID:XP6NPTaD]
- >>69
これがGC環境のどんな言語のソースかわからんけど、
GCアルゴリズムが使われる以上、allocについてもGCのコストを考えんといけんわけだが…
「コード上」の見た目だけはC/C++で書くカスタムアロケータより速そうだね。見た目だけは。
- 73 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:48:22 ID:w7j54ekv]
- >>71
だってすっげ頭悪いじゃん
全然意味ないことやってるじゃん
- 74 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:50:27 ID:KXq+7Jyb]
- >>72
> allocについてもGCのコストを考えんといけんわけだが…
もちろん、そう。
> 「コード上」の見た目だけはC/C++で書くカスタムアロケータより速そうだね。
> 見た目だけは。
実際速いよ。大量に小さなオブジェクトの生成/解体を繰り返すなら。
Boehm GCでも導入して測定してみなよ。
まあ、もちろん、本当に速度が必要ならなるべくオブジェクトの動的な
生成/解体はせず、poolingするけどな。
GCの話題はスレ違いっぽいから、これ以上は自分の目で確かめてくれ。
- 75 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:51:52 ID:qdg6blW7]
- >>62
これ、ちゃんと適用範囲限定して、ゲームの仕様にあわせて使えば GC のコストもなしに
使えてもっと速いのに。っていうか、そういう使い方ならわりと実際に使われてるはず。
region allocator ってやつね。
これが「GC環境下のheap alloc」と言い切ってしまうのが、なんとも、ねぇ。
- 76 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:53:14 ID:SofMJMSf]
- >GC環境下のほうが、小さなオブジェクトの生成/解体には有利で、
>どうせGCを搭載するなら、コンパクションをやるついでにタスクの再配置も
>したほうがCPU cacheの効率があがるということを主張している。
いつからGCが前提になったんだ？
>18 名前：並列さん ◆dPfetnROQg [sage] 投稿日：2009/04/05(日) 03:23:57 ID:KXq+7Jyb
>>>15
>俺は14ではないが、メモリのコンパクションを行なうには、それぞれのオブジェクトに対するstd::listのようなものが
>必要になるので、(典型的な)タスクシステムに搭載されているstd::listのようなものをそのまま流用すれば一石二鳥だから、
>タスクシステムはメモリのコンパクションまで行なうように拡張しておけば、タスクシステムのフレームワークとしての
>利用価値がさらにあがるという風にタスクシステムとメモリのコンパクションとは密接に関係している。
- 77 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:54:02 ID:KXq+7Jyb]
- >>67
> 型ごちゃまぜ状態でコンパクションかけるよりは、
> 同じ型は同じ配列に集めてコンパクションかけた方が、まだましだろう。
そうとは限らない。
普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
- 78 名前：名前は開発中のものです。 mailto:sage [2009/04/05(日) 23:57:17 ID:XP6NPTaD]
- Boehm GCを使いながらキャッシュヒットの利点を持ち出すのか…
やはり根本的に矛盾しているというか何というか。
- 79 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:58:02 ID:KXq+7Jyb]
- >>75
> これ、ちゃんと適用範囲限定して、ゲームの仕様にあわせて使えば GC のコストもなしに
> 使えてもっと速いのに。
もちろんそうだよ。
- 80 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/05(日) 23:59:48 ID:KXq+7Jyb]
- >>78
> Boehm GCを使いながらキャッシュヒットの利点を持ち出すのか…
> やはり根本的に矛盾しているというか何というか。
Boehm GCは、GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を
含めても)速いということを示すために挙げただけだ。
- 81 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 00:05:36 ID:kRCgeJ2q]
- >>80
>GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を含めても)速いということを示すために挙げただけだ。
この文章だと全てのGC環境が非GC環境に比べてオブジェクトの生成/解体が速いって意味になりそうだけど
ほんとにそー思ってる？
それとも何か自分だけ常識と思ってる前提でもあるのかね。
- 82 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 00:07:16 ID:SofMJMSf]
- >普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
メモリ使用量を減らすためだろ。
今は高速化についての話をしているはずでは？
- 83 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 00:13:08 ID:B8zjnpJZ]
- >Boehm GCは、GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を
>含めても)速いということを示すために挙げただけだ。
速かろうが遅かろうが、タスクシステム内でやるべきことでは無いわけで。
タスクをどう確保するかはタスクシステムの利用者に委ねるべき。
- 84 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 00:13:20 ID:yXbkibtb]
- >>81
> この文章だと全てのGC環境が非GC環境に比べてオブジェクトの生成/解体が速いって意味になりそうだけど
> ほんとにそー思ってる？
もちろん、GCにしてもピンキリ。
Boehm GCは、オブジェクトの型情報を持っていないから効率の面では
あまり良くない実装だけど、参考に挙げるのはそれくらいでいいかなと思った。
> それとも何か自分だけ常識と思ってる前提でもあるのかね。
.NET FrameworkのGCは結構練られてると思う。
.NET FrameworkのGCに関してはいろんな環境と比較したり
速度を計測したりしたし、俺GCを実装するときの参考にさせてもらった。
- 85 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 00:14:51 ID:QqdC07mx]
- GCスレ立てろよw
- 86 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 00:20:34 ID:yXbkibtb]
- >>82
>>普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
> メモリ使用量を減らすためだろ。
違うね。速度面でもメリットがある。
>>83
> 速かろうが遅かろうが、タスクシステム内でやるべきことでは無いわけで。
> タスクをどう確保するかはタスクシステムの利用者に委ねるべき。
俺は>>78に対して>>80と答えただけで、あんたの突っ込みは適切じゃない。
また、「タスクメモリをどう確保するか」は、タスクシステム側が決めても
構わないと俺は思う。タスク"システム"なんだから、嫌なら、そのシステムを
使わなければいいだけのことじゃん。
- 87 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 00:30:13 ID:B8zjnpJZ]
- >違うね。速度面でもメリットがある。
無いね。ごちゃ混ぜにするより、同じ型を隣に並べた方がゲームの場合キャッシュヒット率が上がる。
同一型は同一ループ内で処理されるのが普通だからな。
- 88 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 00:32:14 ID:B8zjnpJZ]
- つーかいつからGC前提の話になったんだよ。
>>18の発言はどうするつもりだ？
タスクシステム実装するならコンパクションも実装した方が一石二鳥だって話じゃなかったのかよ。
- 89 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 00:40:06 ID:QqdC07mx]
- タスク厨はマジでしょうもないなwww
コンパクションやGCが必要になるほどの規模で、モノ作ってるワケでもあるまいにwww
たかがタスクのコレクションを順次処理していくだけなのに、キャッシュ効率だの速度だの気にしてる方が
バカらしいwww
- 90 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 00:40:40 ID:gHjH+Kkr]
- >>87
ごちゃ混ぜコンパクションの速度面のメリットも、同じ型を隣に並べた場合の
キャッシュヒット率向上も、同じぐらいにいいかげんな話だと思うよ。
速度を上げたかったら、まず計測してボトルネックを見つけて、そこを叩かなきゃ。
- 91 名前：90 mailto:sage [2009/04/06(月) 00:42:54 ID:gHjH+Kkr]
- あ、ボトルネックを見つけた後の対処としては、コンパクションを実装するより
オブジェクトを配列にまとめたほうがはるかに簡単で効果的だと思うけどね。
- 92 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 01:05:15 ID:yXbkibtb]
- >>87
> 無いね。ごちゃ混ぜにするより、同じ型を隣に並べた方がゲームの場合キャッシュヒット率が上がる。
> 同一型は同一ループ内で処理されるのが普通だからな。
なんか言葉不足で何がどうなっているのか俺にはわからないのだが、
A. newで確保した時点でvector<T>にpush_backする
B. 動的にオブジェクトを移動させvector<T>に入れる
のA,Bのどちらの話をしているんだ？
Aなら話もわからなくはない。そんな風にコーディングしていいならな。
しかし、その確保された順番にタスクプライオリティが割り振られているわけではないだろうから、
タスクシステムからこれを呼び出したときにcacheのヒット率がいいのかは別問題。
そもそも、メモリイメージは詰められて配置はされるが、Aは普通はコンパクションとは呼ばない
んじゃないかな。これをコンパクションと呼ばれると俺には紛らわしくて仕方がない。
B.なら、上に書いたのと同じ理由に加えて、動的な型を判定してvector<T>に突っ込んだり、
その参照を書き換えたりするコストが必要になるので、あんたが思っているようには速くならない。
- 93 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:08:56 ID:B8zjnpJZ]
- 並列さん ◆dPfetnROQgは、
キャッシュヒット率が上がるからと、わざわざコンパクションをかけ、さらにはタスクの並べ替えまで行うという。
最適なデータ配置はゲームの仕様によりけりで、
ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は無意味だと言うのに。
しかも、コンパクションの実装もまずい。
型ごとに配列で保持してコンパクションかければ良いだけのものを、
わざわざごちゃ混ぜ状態で保持して折角のキャッシュヒット率を落としてしまうというセンスの無さ。
なにやってんだか。
よくよく聞けば、本職がソフト屋で、さらにゲーム関係に携わってるとか。
ハード屋の俺と争ってる時点で終わってるね。
極めつけは、タスクをどう確保するかはタスクシステム側が決める、嫌なら使わなければ良いだけだ、
などという、ソフト屋独特の独善的な恥ずかしい発想。
まずは大人になってください。
- 94 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:13:04 ID:QqdC07mx]
- 構図が一緒なんだよなw
タスク厨とアンチタスク
GCコンパクション厨と不必要派
- 95 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:18:54 ID:/+Me6qfs]
- 結論は意味がないのに話にのるなよ馬鹿だろ？
根本がまずい
ゲームの仕様によって変わるものをその下の層に
無理やりねじ込もうとしてる時点でもうダメなんだよ
話を受けるほうも根幹で間違ってる問題でそれが解決できないまま話を進めるな
無意味だろ
こんな議論何時間したって無駄じゃん
すればするほど馬鹿になってくだけ
- 96 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:19:40 ID:/+Me6qfs]
- ああ、それと
>並列さん ◆dPfetnROQg
そんなに馬鹿ならＰＧやめちゃえよ
- 97 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:31:57 ID:B8zjnpJZ]
- >>92
Bだな。
ところで、お前が>>42で示した実装だと、型ごとにポインタをcollectionしてるから、
型を飛び越えて処理順序のプライオリティーをつけることは出来ない。
だから、>>92で言うプライオリティーとは、同一型内での処理順序のプライオリティーだと考える。
だからvector<T>（のようなもの）に実態を持っておいて、プライオリティーの変更があれば、
その都度vector<T>内の該当要素を挿入しなおす実装で問題ない。
>B.なら、上に書いたのと同じ理由に加えて、動的な型を判定してvector<T>に突っ込んだり、
>その参照を書き換えたりするコストが必要になるので、あんたが思っているようには速くならない。
テンプレートを使えばよい。
template < class _T >
std::vector< _T > *get_heap(){ static std::vector< _T > heap; return &heap; }
template < class _T >
_T *New()
{
get_heap<_T>()->resize( get_heap<_T>()->size()+1 );
return &get_heap<_T>()->back();
}
hoge_task *p = New< hoge_task >();
お前本当にソフト屋か？
- 98 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:51:15 ID:y7ZcPLoJ]
- >>93
> 最適なデータ配置はゲームの仕様によりけりで、
> ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は
> 無意味だと言うのに。
全くその通りなんだけど、ほぼ
タスクシステムを実装する人＝それを使う人
なんじゃないのかな。
少なくとも仕様について直接話ができる関係でないと
タスクシステム自体を使えないと思う。
つまりありえない仮定を置いて否定するのはフェアじゃないし
技術の話としても意味が無いと言いたい。
- 99 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:53:56 ID:B8zjnpJZ]
- 並列さん ◆dPfetnROQg よ・・・
現実逃避目的にプログラム書くのなら、もうプロ辞めろ。
タスクシステムでキャッシュヒット率を上げようという目的も不味ければ、
その実装手段も不味い。
普通、どちらかぐらい真っ当なものなのだが。
これからは農業の時代だと聞くぞ。
- 100 名前：98 mailto:sage [2009/04/06(月) 01:59:15 ID:iTEC611J]
- 一応書いとくと並列さんの味方したいわけじゃなくて
並列さんの主張は独善的で視野が狭いと思う。
# 技術的な話を盛り上げるためにつっこみどころ満載の
# ネタを意図的に投下してるのかもしれんけど
- 101 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 02:07:50 ID:B8zjnpJZ]
- >>98
>タスクシステムを実装する人＝それを使う人
だったとしても、
>ゲームの仕様を知れないタスクシステム側
であることには変わりないわけで。
どうであれ、キャッシュヒット率まで考えたデータの配置を考えると言うのなら、
(タスクシステムを実装する人＝それを使う人、で有ろうが無かろうが)
タスクシステムの外から行う方が話が早い。
- 102 名前：98 mailto:sage [2009/04/06(月) 02:44:56 ID:H9N6h/U7]
- >>101
ごめん。ゲームの仕様に合わせて毎回設計するという仮定をしてることに
101で気がついた。書かなきゃわからないのに話があうわけないよね。
話に参加できるほど賢くないとわかったので観客に戻ります。
- 103 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 02:57:00 ID:yXbkibtb]
- >>93
> 最適なデータ配置はゲームの仕様によりけりで、
> ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は無意味だ> と言うのに。
違うね。タスクシステムであるからには、タスクプライオリティに従って
タスクが呼び出されることは保証されるわけで、呼び出し順がわかっているので
それに従ってGCするときに配置換えすることは出来る。
> 型ごとに配列で保持してコンパクションかければ良いだけのものを、
これも違うね。型ごとに集めればworking setは小さくなるが、
その集合に対してメモリの先頭から逐次的にアクセスしていく
保証はされない。
- 104 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:00:20 ID:yXbkibtb]
- >>95
> ゲームの仕様によって変わるものをその下の層に
> 無理やりねじ込もうとしてる時点でもうダメなんだよ
これも違うね。
GCはどんなゲームを作る場合でもあって困るということはあまりない。
GC環境下(例えばXNAでも.NET Framework + WPFでも)で
プログラムをすればその便利さがわかると思うのだが。
GCを否定する馬鹿がこんなにいるんだな。このスレ阿呆の集まりか？
>>96
馬鹿はあんただろろ。ろくにプログラミング経験もないなら
口出ししてくるなよ。
- 105 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:10:23 ID:yXbkibtb]
- >>97
> プライオリティーの変更があれば、
> その都度vector<T>内の該当要素を挿入しなおす実装で問題ない。
「挿入しなおす」って、removeしてinsertするって意味？
プライオリティが変わるごとにstd::vectorに対してそんなことしたら
重くて仕方ないんだけど。
何がどう問題ないと思えるの？頭大丈夫？
> hoge_task *p = New< hoge_task >();
> お前本当にソフト屋か？
それnewしたときに型がわかっていて、その型のvectorに
突っ込んでるだけじゃん。>>92のBじゃなく、Aでしょうに。
あと「その参照を書き換えたりする」必要があると俺は書いてるが、
それはどうやって解決するつもり？
- 106 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:13:17 ID:yXbkibtb]
- >>99
> 現実逃避目的にプログラム書くのなら、もうプロ辞めろ。
あんたが俺が言ってる内容を何も理解してないだけじゃん。
あんたは日本語の勉強しなおしてきたほうがいいよ。
- 107 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:14:58 ID:yXbkibtb]
- >>101
> どうであれ、キャッシュヒット率まで考えたデータの配置を考えると言うのなら、
> タスクシステムの外から行う方が話が早い。
わかっちゃいると思うが、俺の言っている
GCは実際はタスクシステムの"外"に実装されているよ。
GCにタスクの呼び出し順というヒントを与えて、それを利用して
うまくオブジェクトをアレンジメントできるかということを
問題にしているだけなんだが。
- 108 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:20:24 ID:B8zjnpJZ]
- >違うね。タスクシステムであるからには、タスクプライオリティに従って
>タスクが呼び出されることは保証されるわけで、
>>42 を見る限り、型ごとにcollectionを持っているようだが。
どの型のcollectionのupdateから実行していくかは、for_eachを記述した順に決定されるわけで、
プライオリティーによらないと考えるが。
>その集合に対してメモリの先頭から逐次的にアクセスしていく
>保証はされない。
だったら並べ替えればよい。要は最適化する順番が逆。
まず型ごとに集めることを考えて、それから並べ替えることを考える。
まぁそれすら意味がないどころか余計なことだと思うがな。
どうせやるならということで。
>GCはどんなゲームを作る場合でもあって困るということはあまりない。
だから、いつからGCの話になったんだ？
- 109 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:33:51 ID:B8zjnpJZ]
- >プライオリティが変わるごとにstd::vectorに対してそんなことしたら
>重くて仕方ないんだけど。
プライオリティーなんて滅多に変わらないだろうし、現実問題として、それで問題ないだろう。
付け加えて、俺はそもそもコンパクションなんて要らないといってるわけで。
それにはコンパクションが重い処理だからという理由も含まれている。
>それnewしたときに型がわかっていて、その型のvectorに
>突っ込んでるだけじゃん。>>92のBじゃなく、Aでしょうに。
お前の日本語が分かりにくいんだよ。自分の世界の定義で言葉使うから。
>B. 動的にオブジェクトを移動させvector<T>に入れる
の意味が謎。型なんて生まれてから死ぬまで変わらないんだから動的に管理する意味なんてないだろ。
>あと「その参照を書き換えたりする」必要があると俺は書いてるが、
>それはどうやって解決するつもり？
好きな方法でやれば？これはお前の言うところのコンパクションでも同じ問題が発生するでしょ。
- 110 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:36:49 ID:yXbkibtb]
- >>108
> >>42 を見る限り、型ごとにcollectionを持っているようだが。
> どの型のcollectionのupdateから実行していくかは、for_eachを記述した順に決定され> るわけで、
それは、俺がGC側でcompactionを行なうときにタスクを並び替えて、
並び変わったあとのcollectionを返しているからそうなっている。
あんたが、自前でcompactionを行なうなら、自分でタスクプライオリティに
従って並び替えをしないといけないし、並び替えをした上で同じ型のcollection同士を
集めたものを用意してからupdate(vector<T>)のような関数を呼び出す必要がある。
> まず型ごとに集めることを考えて、それから並べ替えることを考える。
「型ごとに集めることを考えて、それから並べ替える」ほうが、
「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは限らないんだが。
そんな自分のやりやすい方法を言われても。
- 111 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:38:52 ID:B8zjnpJZ]
- >>107
タスクシステムの外と言う言葉を使ったが、下位層は含まず、上位層という意味で使った。
ごめんね、そこまで細かく言ってあげなきゃ分からないよね。
それとも、下位とか上位という概念がなく、内か外でしか物事を考えられないのかな？
まぁ、GCにタスクの呼び出し順を食わせようとしている時点で既にアレなのだが。
- 112 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:41:43 ID:yXbkibtb]
- >>109
>>B. 動的にオブジェクトを移動させvector<T>に入れる
>の意味が謎。型なんて生まれてから死ぬまで変わらないんだから動的に管理する意味なんてないだろ。
確かに上の(俺の)日本語、わかりにくいな。それはすまんかった。
生成時にいったんvector<T>に入れてオブジェクトが死ぬまで
アドレスの変更などが発生しないのがA。
それに対して、描画フレーム毎に、オブジェクトを移動させ
compactionを行なうという意味がB。
- 113 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:45:41 ID:yXbkibtb]
- >>109
>>プライオリティが変わるごとにstd::vectorに対してそんなことしたら
> プライオリティーなんて滅多に変わらないだろうし、現実問題として、
> それで問題ないだろう。
あんたの実装、vector<T*>ではなく、vector<T>だよな？
オブジェクトが死ぬごとにremoveが発生してそこ以降のオブジェクト全部
コピーすることになるんだが、これ、いつ後始末するつもりだ？
また死んだオブジェクト(タスク)はどうやって判定するつもりだ？
オブジェクトひとつずつにデリートマークがあって、foreachのときに
デリートマークをチェックしながらiterationを行なうのか？
それともどこかで死んだオブジェクトを詰める(removeする)作業をするのか？
そのときにそこ以降のオブジェクトのアドレスが書き換わるから、
それを参照しているポインタ全部書き換えなきゃならんのだが。
本当にそんな実装が速いと思うのか？
- 114 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:53:18 ID:B8zjnpJZ]
- >あんたが、自前でcompactionを行なうなら、自分でタスクプライオリティに
>従って並び替えをしないといけないし、並び替えをした上で同じ型のcollection同士を
>集めたものを用意してからupdate(vector<T>)のような関数を呼び出す必要がある。
型ごとにheapを持つようにすれば同じ型同士を集める必要はないし、
タスクプライオリティーも、変更されるその都度挿入し直せば、並べ替えを行う必要もなくなる。
当たり前だが、挿入と並べ替えだと、並べ替えの方が重い。
>「型ごとに集めることを考えて、それから並べ替える」ほうが、
>「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは限らないんだが。
>そんな自分のやりやすい方法を言われても。
後者よりも前者の方が常に速い。
前者だと、
１．型ごとに集める処理を端折れる。
２．型ごとに並べ替えた方が速い。なぜなら並べ替えの計算量はO(n*logn)だから。
- 115 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:00:55 ID:yXbkibtb]
- >>114
> タスクプライオリティーも、変更されるその都度挿入し直せば、
> 並べ替えを行う必要もなくなる。
> 当たり前だが、挿入と並べ替えだと、並べ替えの方が重い。
並べ替えは毎フレームしなくとも良いが(GCが走るのはときどきなわけだし)、
タスクプライオリティは変更と同時に挿入しなおさなければならないから
その比較はおかしい。
まあ、タスクプライオリティを頻繁に変更するかと言われれば
確かに普通はノーだと思うんだが、生成は頻繁に行なうわけで、生成時にタスク
プライオリティが与えられていてその適切なところにinsertする
コストはとても無視できない。
- 116 名前：ID:B8zjnpJZ mailto:sage [2009/04/06(月) 04:01:06 ID:RuQXDnG2]
- >>113
それは好きにすればよいと思うが。
>それを参照しているポインタ全部書き換えなきゃならんのだが。
オブジェクトに不変なハンドルつけて間接参照にしたり、
ポインタをラップしてリストアップしたり。
>本当にそんな実装が速いと思うのか？
コンパクションを行うということはそういうことだろうに。(だから要らないと言ってるのだが)
つーか、並列さん ◆dPfetnROQg はコンパクションを何だと思ってるんだ？
- 117 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:09:51 ID:RuQXDnG2]
- >生成は頻繁に行なうわけで、生成時にタスク
>プライオリティが与えられていてその適切なところにinsertする
>コストはとても無視できない。
型ごとにheapを持ってればそんなむちゃくちゃな事にはならないし、
どちらかというと、不定期にGCが発動して、そのフレームだけ局所的に負荷が高くなる方が困る。
ゲームでGC使うのが嫌われる理由と同じだな。
- 118 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:13:47 ID:RuQXDnG2]
- >並べ替えは毎フレームしなくとも良いが(GCが走るのはときどきなわけだし)、
>タスクプライオリティは変更と同時に挿入しなおさなければならないから
>その比較はおかしい。
リアルタイム処理では一番負荷の高い瞬間で比較しなければならないので、
その比較であってる。いわゆるボトルネックという奴。
- 119 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:19:36 ID:yXbkibtb]
- >>114
>>「型ごとに集めることを考えて、それから並べ替える」ほうが、
>>「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは
>> 限らないんだが。
>> そんな自分のやりやすい方法を言われても。
>後者よりも前者の方が常に速い。
>前者だと、
>１．型ごとに集める処理を端折れる。
>２．型ごとに並べ替えた方が速い。なぜなら並べ替えの計算量はO(n*logn)だから。
1.は、意味不明。「型ごとに集めることを考えて」なのだから、端折れてないと
思うんだが。
2.は、どうもあんたはまだ話がわかっちゃいないと思う。
- 120 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:22:45 ID:yXbkibtb]
- >>114
次の4つのインスタンスがあるとしよう。
Task A : プライオリティ = 1
Task A : プライオリティ = 4
Task B : プライオリティ = 2
Task B : プライオリティ = 3
Task A,BはTaskという基底クラスの派生型でvector<Task*>にぶち込まれていて
これをいま呼び出し順を考慮しながら型ごとに分類しないといけないとしよう。
collection I.
Task A : プライオリティ = 1
collection II.
Task B : プライオリティ = 2
Task B : プライオリティ = 3
collection III.
Task A : プライオリティ = 4
呼び出し順を考慮して、上のように分類されてcollectionが
生成されなければならない。
「型ごとに集めることを考えて、それから並べ替える」ほうが速いか？
それに同じ型に対するcollectionは上のように複数いるぞ。
この意味で、>>97のような実装は不可だ。
- 121 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:32:06 ID:yXbkibtb]
- >>116
> オブジェクトに不変なハンドルつけて間接参照にしたり、
> ポインタをラップしてリストアップしたり。
だから、そんなプログラムが速いわけないだろ。
ハンドルに対する実アドレスのテーブルをcompactionのときに
更新しないといけないぞ。
他のタスクオブジェクトを参照するごとに
TaskA taskA= dynamic_cast<TaskA*>HandleToPtr(taskA_handle);
みたいに書く必要が出てくる。
プログラムが汚い上にハンドルだから型が不明になってしまう。
これひどくないか？
> コンパクションを行うということはそういうことだろうに。
それは、全然違うと思うぞ…。
少なくとも俺のシステムにあんたの実装のような欠陥はないな。
- 122 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:33:07 ID:yXbkibtb]
- >>116
> 型ごとにheapを持ってればそんなむちゃくちゃな事にはならないし、
(一般的には)型ごとにheapを持てない。理由 >>120。
- 123 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:35:38 ID:RuQXDnG2]
- >>119
型ごとに既に集まってるんだから、型ごとに集め直す必要はないだろ。
例えば、林檎と蜜柑と梨が何個かずつ有って、それぞれ種類別に箱に入ってるとする。
それぞれの果物には賞味期限があり、売れ残りを防ぐため、古いもが手前に来るように陳列したい。
A：林檎と蜜柑と梨をごちゃまぜにして、賞味期限順に並べ替えてから、改めて種類別に分け直す。
B：単にそれぞれの種類内で賞味期限順に並べ替える。
どっちが早いか。
- 124 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:38:38 ID:yXbkibtb]
- >>117
> どちらかというと、不定期にGCが発動して、そのフレームだけ局所的に負荷が高くなる方が困る。
さすがにそんなことは普通はない。
いや、あるにはあるが、そうならないように気をつけてコーディングする。
それすら出来ないなら、そもそもXNAでゲームプログラムなんて出来ないわけで…。
>>118
> リアルタイム処理では一番負荷の高い瞬間で比較しなければならないので、
> その比較であってる。いわゆるボトルネックという奴。
ボトルネックがコマ落ちしたりするほど大きくないなら、全体的なスループットのほうが大切。
- 125 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:39:51 ID:yXbkibtb]
- >>123は>>120を読む前に書かれたものだと思うので無視する。
- 126 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:46:06 ID:gHjH+Kkr]
- もうね、
タスクシステムありきでいろんな問題（コンパクション・キャッシュヒット）に対処していくと、
最終的にはこんなことになってしまうかもしれないという悲劇の具体例にしか見えない。
- 127 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:50:53 ID:yXbkibtb]
- このスレではなんかメモリのコンパクション不要論を唱えてる
馬鹿ばっかりなんだが実際「ワンダと巨像」でもメモリの
コンパクションは、行なっている。
しかも「ワンダと巨像」ではテクスチャ、地形データのみならず、
プログラムコード自体も再配置の対象となっている。
ある程度の規模のゲームなら、やらざるを得ないと思うんだが。
お前たちは、本当にゲームを作っているのか？
夢のなかで作ってるだけなんじゃね？
プログラミング見習いとか、同人ゲー作ってますとか
サブプログラマーとしてスプライト処理手伝いましたとか
そんなゴミクズみたいな奴ばっかり出てくんなよ。
俺はもう寝るぞ。明日も早いからな。おやすみ。
- 128 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:55:46 ID:RuQXDnG2]
- >>120
後出しじゃんけんのごとく次から次へと変な実装例を出してくるなよ。
プライオリティーも型として扱えば？まぁプライオリティー固定になるが。
template < class t, int priority > とかして。
>>121
>プログラムが汚い上にハンドルだから型が不明になってしまう。
>これひどくないか？
そう思うのならラップすればよいだろ。本質的には同じこと。
- 129 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 05:18:01 ID:WGJzP9Yk]
- ＞プログラミング見習いとか、同人ゲー作ってますとか
いや、そもそもここはそういう人のための場だろ。
メイン張ってるプロ中のプロがこんな場所に出てくるんだったら、
そういう人たちに分かるように説明すべきじゃないのか？
つか、場当たり的に情報小出しにするより、ちゃんとまとめて本でも書いてくれ。
次のやねう本より先に出せば結構売れるんじゃないか。
- 130 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 05:24:15 ID:B8zjnpJZ]
- >>124
>そうならないように気をつけてコーディングする。
だったら、普通にメモリプールで十分なわけで。
>ボトルネックがコマ落ちしたりするほど大きくないなら、全体的なスループットのほうが大切。
意味不明。コマ落ちしないなら、既に仕様を満たしているわけで、スループットも糞もないだろ。
>>127
ほとんどのゲームでは行ってないだろ。でもちゃんと動いている。それが現実。
一部の例外だけ取り上げて、さも当たり前かのように言うな。
|
 |
