タスクシステム総合スレ part6

**名前は開発中のものです。** · 2009/04/03(金) 11:25:39

タスクシステムについての議論、相談、質問、雑談などのスレです

part5 http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

・タスクと呼ばれる実装は、非常に多岐に渡ります
　古典タスクシステムについての話題は「>>2」と明示してください
　そうでない場合はカスタム版であることを明示してください

・人を憎んで言語を憎まず

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:20:19

>>55
> メモリアクセスの最適化が要るループの中でインスタンス単品のアドレスをキーにした
> ハッシュテーブルをひくのが「いいけどね」なの？

「メモリアクセスの最適化が要るループの中で」呼び出すだなんて
俺は一言も言ってないんだが。

どうやれば本当に効率が改善されるのか自分の頭を使って考えたらどうだ？

**名前は開発中のものです。** · 2009/04/05(日) 23:21:29

>>56
>俺は、>>45 では、GC環境なら、C/C++のheap allocより高速なnewの実装が可能に
>なることは言ったが、「GC環境を構築したC/C++よりも」だなんて一言も言ってない。
矛盾した返答だなぁ

そのGC環境は比較対照のC/C++とは違うアーキテクチャのマシンで動いているのかい？
同じマシンならその高速とやらのheap allocと同じ原理を、高級アセンブラであるC/C++なら実装可能だろ。逆は無理だけど。

GC環境とやらがネイティブのC/C++(≠ASM)にパフォーマンスで勝負するのは勝ち目が無いんで無い？

**名前は開発中のものです。** · 2009/04/05(日) 23:22:09

>53
C++っぽいけど全然違う脳内言語を使って脳内コンパイルしてるだけなら、その程度の話でいいのかもね。

**名前は開発中のものです。** · 2009/04/05(日) 23:24:28

>>56
>その理屈はおかしい。
>あんたはゲームの仕様が決まるまでnewやdeleteの実装をしないつもりか？

その理屈でいくのなら、自前のcollectionなんて実装せずにnewやdeleteを使ってれば良い話になるだろ。
ところがお前は、newやdeleteはタスクシステムの仕様に無頓着だから、
タスクシステムの仕様にあったアロケータを自前で開発すべきだと主張してる。
それに対して俺は、タスクシステムはゲームの仕様に無頓着だから、
ゲームの仕様にあった方法でデータは確保すべきだ、と返しているわけで。

**名前は開発中のものです。** · 2009/04/05(日) 23:30:02

>>56
> std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
> 全部そこに突っ込む(push_back)するつもりか？

その vector をまっすぐ走査すればキャッシュヒット率の目的は達成できるよね？
何かマズイの？

> あんたはゲームの仕様が決まるまでnewやdeleteの実装をしないつもりか？

いや、しないだろ、当然。コンパイラが一般的な実装は提供してくれるんだから。
ゲームの仕様がなければ自分で実装する目的が無い。

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:31:38

>>58
何か話が噛み合ってない気がする。

俺が想定しているGC環境でのmallocは、次のコードだ。

void* malloc(size_t size)
{
void* adr = (void*)heap; // heapはbyte*
heap += size; // この分、確保した
return adr;
}

これはGC環境下ではないC/C++で書くカスタムアロケータより
十分高速だと思うが、これより速い実装が可能だと言うなら教えてくれ。

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:34:08

>>62
自己レスだが、メモリを上位から下位に確保していくheapなら

void* malloc(size_t size)
{
heap -= size; // この分、確保した
return (void*)heap;
}

こうなる。こっちでもいい。

**名前は開発中のものです。** · 2009/04/05(日) 23:34:12

>>57
collection の要素型がポインタになってるけど、別に派生クラスとか update の詳細が
異なるインスタンスをいっしょに入れるわけじゃなくて、単一クラスのコレクションなの？

それなら、なおさら std::vector に生で入れたほうが速そうだなぁ。

**名前は開発中のものです。** · 2009/04/05(日) 23:36:14

>>62
あのー、これheap allocでなくstackでない？

**名前は開発中のものです。** · 2009/04/05(日) 23:37:09

どう考えてもゲームの仕様依存の問題にここまでしつこいのって馬鹿じゃね？
設計失敗してるのにねばってて馬鹿みたい
プログラマやる前にまず大人になれよｗ

**名前は開発中のものです。** · 2009/04/05(日) 23:38:02

>std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
>全部そこに突っ込む(push_back)するつもりか？

型ごちゃまぜ状態でコンパクションかけるよりは、
同じ型は同じ配列に集めてコンパクションかけた方が、まだましだろう。
同じ型のデータは連続的にアクセスされる可能性が高いからな。
型ごちゃ混ぜ状態でコンパクションかけますっていうのなら、
頭どうかしてますとしか言いようが無い。ゲームでそこまでする必要なし。

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:41:04

>>60
なんか話が噛み合ってない原因がわかった。

> ところがお前は、newやdeleteはタスクシステムの仕様に無頓着だから、
> タスクシステムの仕様にあったアロケータを自前で開発すべきだと主張してる。

俺は最初からそんなことは主張していない。

GC環境下のほうが、小さなオブジェクトの生成/解体には有利で、
どうせGCを搭載するなら、コンパクションをやるついでにタスクの再配置も
したほうがCPU cacheの効率があがるということを主張している。

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:42:24

>>65
> あのー、これheap allocでなくstackでない？

それがGC環境下のheap allocだよ。

定期的にGCがメモリのコンパクションを行なうから、heap allocはただひたすら
メモリの上位(or 下位)に向かって確保していくだけでいいんだ。

**名前は開発中のものです。** · 2009/04/05(日) 23:43:40

なんで話がかみ合ってないとか言い出すの？
もう疑いようもなく頭悪いのにｗ
なんでかみ合ってないとかやめてよ
きたねぇなさわんなよ気持ち悪い

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:44:27

>>66,70
馬鹿はお前。話についてこれないなら黙れ。

**名前は開発中のものです。** · 2009/04/05(日) 23:44:39

>>69
これがGC環境のどんな言語のソースかわからんけど、
GCアルゴリズムが使われる以上、allocについてもGCのコストを考えんといけんわけだが…
「コード上」の見た目だけはC/C++で書くカスタムアロケータより速そうだね。見た目だけは。

**名前は開発中のものです。** · 2009/04/05(日) 23:48:22

>>71
だってすっげ頭悪いじゃん
全然意味ないことやってるじゃん

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:50:27

>>72
> allocについてもGCのコストを考えんといけんわけだが…

もちろん、そう。

> 「コード上」の見た目だけはC/C++で書くカスタムアロケータより速そうだね。
> 見た目だけは。

実際速いよ。大量に小さなオブジェクトの生成/解体を繰り返すなら。
Boehm GCでも導入して測定してみなよ。

まあ、もちろん、本当に速度が必要ならなるべくオブジェクトの動的な
生成/解体はせず、poolingするけどな。

GCの話題はスレ違いっぽいから、これ以上は自分の目で確かめてくれ。

**名前は開発中のものです。** · 2009/04/05(日) 23:51:52

>>62
これ、ちゃんと適用範囲限定して、ゲームの仕様にあわせて使えば GC のコストもなしに
使えてもっと速いのに。っていうか、そういう使い方ならわりと実際に使われてるはず。

region allocator ってやつね。

これが「GC環境下のheap alloc」と言い切ってしまうのが、なんとも、ねぇ。

**名前は開発中のものです。** · 2009/04/05(日) 23:53:14

>GC環境下のほうが、小さなオブジェクトの生成/解体には有利で、
>どうせGCを搭載するなら、コンパクションをやるついでにタスクの再配置も
>したほうがCPU cacheの効率があがるということを主張している。

いつからGCが前提になったんだ？

>18 名前：並列さん ◆dPfetnROQg [sage] 投稿日：2009/04/05(日) 03:23:57 ID:KXq+7Jyb
>>>15
>俺は14ではないが、メモリのコンパクションを行なうには、それぞれのオブジェクトに対するstd::listのようなものが
>必要になるので、(典型的な)タスクシステムに搭載されているstd::listのようなものをそのまま流用すれば一石二鳥だから、
>タスクシステムはメモリのコンパクションまで行なうように拡張しておけば、タスクシステムのフレームワークとしての
>利用価値がさらにあがるという風にタスクシステムとメモリのコンパクションとは密接に関係している。

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:54:02

>>67
> 型ごちゃまぜ状態でコンパクションかけるよりは、
> 同じ型は同じ配列に集めてコンパクションかけた方が、まだましだろう。

そうとは限らない。

普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。

**名前は開発中のものです。** · 2009/04/05(日) 23:57:17

Boehm GCを使いながらキャッシュヒットの利点を持ち出すのか…
やはり根本的に矛盾しているというか何というか。

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:58:02

>>75
> これ、ちゃんと適用範囲限定して、ゲームの仕様にあわせて使えば GC のコストもなしに
> 使えてもっと速いのに。

もちろんそうだよ。

**並列さん** ◆dPfetnROQg · 2009/04/05(日) 23:59:48

>>78
> Boehm GCを使いながらキャッシュヒットの利点を持ち出すのか…
> やはり根本的に矛盾しているというか何というか。

Boehm GCは、GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を
含めても)速いということを示すために挙げただけだ。

**名前は開発中のものです。** · 2009/04/06(月) 00:05:36

>>80
>GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を含めても)速いということを示すために挙げただけだ。
この文章だと全てのGC環境が非GC環境に比べてオブジェクトの生成/解体が速いって意味になりそうだけど
ほんとにそー思ってる？
それとも何か自分だけ常識と思ってる前提でもあるのかね。

**名前は開発中のものです。** · 2009/04/06(月) 00:07:16

>普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
メモリ使用量を減らすためだろ。
今は高速化についての話をしているはずでは？

**名前は開発中のものです。** · 2009/04/06(月) 00:13:08

>Boehm GCは、GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を
>含めても)速いということを示すために挙げただけだ。

速かろうが遅かろうが、タスクシステム内でやるべきことでは無いわけで。
タスクをどう確保するかはタスクシステムの利用者に委ねるべき。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 00:13:20

>>81
> この文章だと全てのGC環境が非GC環境に比べてオブジェクトの生成/解体が速いって意味になりそうだけど
> ほんとにそー思ってる？

もちろん、GCにしてもピンキリ。

Boehm GCは、オブジェクトの型情報を持っていないから効率の面では
あまり良くない実装だけど、参考に挙げるのはそれくらいでいいかなと思った。

> それとも何か自分だけ常識と思ってる前提でもあるのかね。

.NET FrameworkのGCは結構練られてると思う。

.NET FrameworkのGCに関してはいろんな環境と比較したり
速度を計測したりしたし、俺GCを実装するときの参考にさせてもらった。

**名前は開発中のものです。** · 2009/04/06(月) 00:14:51

GCスレ立てろよw

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 00:20:34

>>82
>>普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
> メモリ使用量を減らすためだろ。

違うね。速度面でもメリットがある。

>>83
> 速かろうが遅かろうが、タスクシステム内でやるべきことでは無いわけで。
> タスクをどう確保するかはタスクシステムの利用者に委ねるべき。

俺は>>78に対して>>80と答えただけで、あんたの突っ込みは適切じゃない。

また、「タスクメモリをどう確保するか」は、タスクシステム側が決めても
構わないと俺は思う。タスク"システム"なんだから、嫌なら、そのシステムを
使わなければいいだけのことじゃん。

**名前は開発中のものです。** · 2009/04/06(月) 00:30:13

>違うね。速度面でもメリットがある。
無いね。ごちゃ混ぜにするより、同じ型を隣に並べた方がゲームの場合キャッシュヒット率が上がる。
同一型は同一ループ内で処理されるのが普通だからな。

**名前は開発中のものです。** · 2009/04/06(月) 00:32:14

つーかいつからGC前提の話になったんだよ。
>>18の発言はどうするつもりだ？
タスクシステム実装するならコンパクションも実装した方が一石二鳥だって話じゃなかったのかよ。

**名前は開発中のものです。** · 2009/04/06(月) 00:40:06

タスク厨はマジでしょうもないなwww
コンパクションやGCが必要になるほどの規模で、モノ作ってるワケでもあるまいにwww

たかがタスクのコレクションを順次処理していくだけなのに、キャッシュ効率だの速度だの気にしてる方が
バカらしいwww

**名前は開発中のものです。** · 2009/04/06(月) 00:40:40

>>87
ごちゃ混ぜコンパクションの速度面のメリットも、同じ型を隣に並べた場合の
キャッシュヒット率向上も、同じぐらいにいいかげんな話だと思うよ。

速度を上げたかったら、まず計測してボトルネックを見つけて、そこを叩かなきゃ。

90 · 2009/04/06(月) 00:42:54

あ、ボトルネックを見つけた後の対処としては、コンパクションを実装するより
オブジェクトを配列にまとめたほうがはるかに簡単で効果的だと思うけどね。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 01:05:15

>>87
> 無いね。ごちゃ混ぜにするより、同じ型を隣に並べた方がゲームの場合キャッシュヒット率が上がる。
> 同一型は同一ループ内で処理されるのが普通だからな。

なんか言葉不足で何がどうなっているのか俺にはわからないのだが、

A. newで確保した時点でvector<T>にpush_backする
B. 動的にオブジェクトを移動させvector<T>に入れる

のA,Bのどちらの話をしているんだ？

Aなら話もわからなくはない。そんな風にコーディングしていいならな。
しかし、その確保された順番にタスクプライオリティが割り振られているわけではないだろうから、
タスクシステムからこれを呼び出したときにcacheのヒット率がいいのかは別問題。

そもそも、メモリイメージは詰められて配置はされるが、Aは普通はコンパクションとは呼ばない
んじゃないかな。これをコンパクションと呼ばれると俺には紛らわしくて仕方がない。

B.なら、上に書いたのと同じ理由に加えて、動的な型を判定してvector<T>に突っ込んだり、
その参照を書き換えたりするコストが必要になるので、あんたが思っているようには速くならない。

**名前は開発中のものです。** · 2009/04/06(月) 01:08:56

並列さん ◆dPfetnROQgは、
キャッシュヒット率が上がるからと、わざわざコンパクションをかけ、さらにはタスクの並べ替えまで行うという。
最適なデータ配置はゲームの仕様によりけりで、
ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は無意味だと言うのに。
しかも、コンパクションの実装もまずい。
型ごとに配列で保持してコンパクションかければ良いだけのものを、
わざわざごちゃ混ぜ状態で保持して折角のキャッシュヒット率を落としてしまうというセンスの無さ。
なにやってんだか。
よくよく聞けば、本職がソフト屋で、さらにゲーム関係に携わってるとか。
ハード屋の俺と争ってる時点で終わってるね。
極めつけは、タスクをどう確保するかはタスクシステム側が決める、嫌なら使わなければ良いだけだ、
などという、ソフト屋独特の独善的な恥ずかしい発想。
まずは大人になってください。

**名前は開発中のものです。** · 2009/04/06(月) 01:13:04

構図が一緒なんだよなw

タスク厨とアンチタスク
GCコンパクション厨と不必要派

**名前は開発中のものです。** · 2009/04/06(月) 01:18:54

結論は意味がないのに話にのるなよ馬鹿だろ？
根本がまずい

ゲームの仕様によって変わるものをその下の層に
無理やりねじ込もうとしてる時点でもうダメなんだよ

話を受けるほうも根幹で間違ってる問題でそれが解決できないまま話を進めるな
無意味だろ

こんな議論何時間したって無駄じゃん
すればするほど馬鹿になってくだけ

**名前は開発中のものです。** · 2009/04/06(月) 01:19:40

ああ、それと

>並列さん ◆dPfetnROQg
そんなに馬鹿ならＰＧやめちゃえよ

**名前は開発中のものです。** · 2009/04/06(月) 01:31:57

>>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 >();

お前本当にソフト屋か？

**名前は開発中のものです。** · 2009/04/06(月) 01:51:15

>>93
> 最適なデータ配置はゲームの仕様によりけりで、
> ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は
> 無意味だと言うのに。

全くその通りなんだけど、ほぼ
タスクシステムを実装する人＝それを使う人
なんじゃないのかな。
少なくとも仕様について直接話ができる関係でないと
タスクシステム自体を使えないと思う。
つまりありえない仮定を置いて否定するのはフェアじゃないし
技術の話としても意味が無いと言いたい。

**名前は開発中のものです。** · 2009/04/06(月) 01:53:56

並列さん ◆dPfetnROQg よ・・・
現実逃避目的にプログラム書くのなら、もうプロ辞めろ。
タスクシステムでキャッシュヒット率を上げようという目的も不味ければ、
その実装手段も不味い。
普通、どちらかぐらい真っ当なものなのだが。
これからは農業の時代だと聞くぞ。

98 · 2009/04/06(月) 01:59:15

一応書いとくと並列さんの味方したいわけじゃなくて
並列さんの主張は独善的で視野が狭いと思う。
# 技術的な話を盛り上げるためにつっこみどころ満載の
# ネタを意図的に投下してるのかもしれんけど

**名前は開発中のものです。** · 2009/04/06(月) 02:07:50

>>98
>タスクシステムを実装する人＝それを使う人

だったとしても、

>ゲームの仕様を知れないタスクシステム側

であることには変わりないわけで。

どうであれ、キャッシュヒット率まで考えたデータの配置を考えると言うのなら、
(タスクシステムを実装する人＝それを使う人、で有ろうが無かろうが)
タスクシステムの外から行う方が話が早い。

98 · 2009/04/06(月) 02:44:56

>>101
ごめん。ゲームの仕様に合わせて毎回設計するという仮定をしてることに
101で気がついた。書かなきゃわからないのに話があうわけないよね。
話に参加できるほど賢くないとわかったので観客に戻ります。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 02:57:00

>>93
> 最適なデータ配置はゲームの仕様によりけりで、
> ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は無意味だ> と言うのに。

違うね。タスクシステムであるからには、タスクプライオリティに従って
タスクが呼び出されることは保証されるわけで、呼び出し順がわかっているので
それに従ってGCするときに配置換えすることは出来る。

> 型ごとに配列で保持してコンパクションかければ良いだけのものを、

これも違うね。型ごとに集めればworking setは小さくなるが、
その集合に対してメモリの先頭から逐次的にアクセスしていく
保証はされない。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 03:00:20

>>95
> ゲームの仕様によって変わるものをその下の層に
> 無理やりねじ込もうとしてる時点でもうダメなんだよ

これも違うね。

GCはどんなゲームを作る場合でもあって困るということはあまりない。

GC環境下(例えばXNAでも.NET Framework + WPFでも)で
プログラムをすればその便利さがわかると思うのだが。

GCを否定する馬鹿がこんなにいるんだな。このスレ阿呆の集まりか？

>>96

馬鹿はあんただろろ。ろくにプログラミング経験もないなら
口出ししてくるなよ。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 03:10:23

>>97
> プライオリティーの変更があれば、
> その都度vector<T>内の該当要素を挿入しなおす実装で問題ない。

「挿入しなおす」って、removeしてinsertするって意味？

プライオリティが変わるごとにstd::vectorに対してそんなことしたら
重くて仕方ないんだけど。

何がどう問題ないと思えるの？頭大丈夫？

> hoge_task *p = New< hoge_task >();
> お前本当にソフト屋か？

それnewしたときに型がわかっていて、その型のvectorに
突っ込んでるだけじゃん。>>92のBじゃなく、Aでしょうに。

あと「その参照を書き換えたりする」必要があると俺は書いてるが、
それはどうやって解決するつもり？

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 03:13:17

>>99
> 現実逃避目的にプログラム書くのなら、もうプロ辞めろ。

あんたが俺が言ってる内容を何も理解してないだけじゃん。

あんたは日本語の勉強しなおしてきたほうがいいよ。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 03:14:58

>>101
> どうであれ、キャッシュヒット率まで考えたデータの配置を考えると言うのなら、
> タスクシステムの外から行う方が話が早い。

わかっちゃいると思うが、俺の言っている
GCは実際はタスクシステムの"外"に実装されているよ。

GCにタスクの呼び出し順というヒントを与えて、それを利用して
うまくオブジェクトをアレンジメントできるかということを
問題にしているだけなんだが。

**名前は開発中のものです。** · 2009/04/06(月) 03:20:24

>違うね。タスクシステムであるからには、タスクプライオリティに従って
>タスクが呼び出されることは保証されるわけで、

>>42　を見る限り、型ごとにcollectionを持っているようだが。
どの型のcollectionのupdateから実行していくかは、for_eachを記述した順に決定されるわけで、
プライオリティーによらないと考えるが。

>その集合に対してメモリの先頭から逐次的にアクセスしていく
>保証はされない。

だったら並べ替えればよい。要は最適化する順番が逆。
まず型ごとに集めることを考えて、それから並べ替えることを考える。
まぁそれすら意味がないどころか余計なことだと思うがな。
どうせやるならということで。

>GCはどんなゲームを作る場合でもあって困るということはあまりない。

だから、いつからGCの話になったんだ？

**名前は開発中のものです。** · 2009/04/06(月) 03:33:51

>プライオリティが変わるごとにstd::vectorに対してそんなことしたら
>重くて仕方ないんだけど。

プライオリティーなんて滅多に変わらないだろうし、現実問題として、それで問題ないだろう。
付け加えて、俺はそもそもコンパクションなんて要らないといってるわけで。
それにはコンパクションが重い処理だからという理由も含まれている。

>それnewしたときに型がわかっていて、その型のvectorに
>突っ込んでるだけじゃん。>>92のBじゃなく、Aでしょうに。

お前の日本語が分かりにくいんだよ。自分の世界の定義で言葉使うから。
>B. 動的にオブジェクトを移動させvector<T>に入れる
の意味が謎。型なんて生まれてから死ぬまで変わらないんだから動的に管理する意味なんてないだろ。

>あと「その参照を書き換えたりする」必要があると俺は書いてるが、
>それはどうやって解決するつもり？

好きな方法でやれば？これはお前の言うところのコンパクションでも同じ問題が発生するでしょ。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 03:36:49

>>108
> >>42　を見る限り、型ごとにcollectionを持っているようだが。
> どの型のcollectionのupdateから実行していくかは、for_eachを記述した順に決定され> るわけで、

それは、俺がGC側でcompactionを行なうときにタスクを並び替えて、
並び変わったあとのcollectionを返しているからそうなっている。

あんたが、自前でcompactionを行なうなら、自分でタスクプライオリティに
従って並び替えをしないといけないし、並び替えをした上で同じ型のcollection同士を
集めたものを用意してからupdate(vector<T>)のような関数を呼び出す必要がある。

> まず型ごとに集めることを考えて、それから並べ替えることを考える。

「型ごとに集めることを考えて、それから並べ替える」ほうが、
「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは限らないんだが。

そんな自分のやりやすい方法を言われても。

**名前は開発中のものです。** · 2009/04/06(月) 03:38:52

>>107
タスクシステムの外と言う言葉を使ったが、下位層は含まず、上位層という意味で使った。
ごめんね、そこまで細かく言ってあげなきゃ分からないよね。
それとも、下位とか上位という概念がなく、内か外でしか物事を考えられないのかな？
まぁ、GCにタスクの呼び出し順を食わせようとしている時点で既にアレなのだが。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 03:41:43

>>109
>>B. 動的にオブジェクトを移動させvector<T>に入れる
>の意味が謎。型なんて生まれてから死ぬまで変わらないんだから動的に管理する意味なんてないだろ。

確かに上の(俺の)日本語、わかりにくいな。それはすまんかった。

生成時にいったんvector<T>に入れてオブジェクトが死ぬまで
アドレスの変更などが発生しないのがA。

それに対して、描画フレーム毎に、オブジェクトを移動させ
compactionを行なうという意味がB。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 03:45:41

>>109
>>プライオリティが変わるごとにstd::vectorに対してそんなことしたら
> プライオリティーなんて滅多に変わらないだろうし、現実問題として、
> それで問題ないだろう。

あんたの実装、vector<T*>ではなく、vector<T>だよな？

オブジェクトが死ぬごとにremoveが発生してそこ以降のオブジェクト全部
コピーすることになるんだが、これ、いつ後始末するつもりだ？

また死んだオブジェクト(タスク)はどうやって判定するつもりだ？

オブジェクトひとつずつにデリートマークがあって、foreachのときに
デリートマークをチェックしながらiterationを行なうのか？

それともどこかで死んだオブジェクトを詰める(removeする)作業をするのか？
そのときにそこ以降のオブジェクトのアドレスが書き換わるから、
それを参照しているポインタ全部書き換えなきゃならんのだが。

本当にそんな実装が速いと思うのか？

**名前は開発中のものです。** · 2009/04/06(月) 03:53:18

>あんたが、自前でcompactionを行なうなら、自分でタスクプライオリティに
>従って並び替えをしないといけないし、並び替えをした上で同じ型のcollection同士を
>集めたものを用意してからupdate(vector<T>)のような関数を呼び出す必要がある。

型ごとにheapを持つようにすれば同じ型同士を集める必要はないし、
タスクプライオリティーも、変更されるその都度挿入し直せば、並べ替えを行う必要もなくなる。
当たり前だが、挿入と並べ替えだと、並べ替えの方が重い。

>「型ごとに集めることを考えて、それから並べ替える」ほうが、
>「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは限らないんだが。
>そんな自分のやりやすい方法を言われても。

後者よりも前者の方が常に速い。
前者だと、
１．型ごとに集める処理を端折れる。
２．型ごとに並べ替えた方が速い。なぜなら並べ替えの計算量はO(n*logn)だから。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 04:00:55

>>114
> タスクプライオリティーも、変更されるその都度挿入し直せば、
> 並べ替えを行う必要もなくなる。
> 当たり前だが、挿入と並べ替えだと、並べ替えの方が重い。

並べ替えは毎フレームしなくとも良いが(GCが走るのはときどきなわけだし)、
タスクプライオリティは変更と同時に挿入しなおさなければならないから
その比較はおかしい。

まあ、タスクプライオリティを頻繁に変更するかと言われれば
確かに普通はノーだと思うんだが、生成は頻繁に行なうわけで、生成時にタスク
プライオリティが与えられていてその適切なところにinsertする
コストはとても無視できない。

**ID:B8zjnpJZ** · 2009/04/06(月) 04:01:06

>>113
それは好きにすればよいと思うが。

>それを参照しているポインタ全部書き換えなきゃならんのだが。

オブジェクトに不変なハンドルつけて間接参照にしたり、
ポインタをラップしてリストアップしたり。

>本当にそんな実装が速いと思うのか？

コンパクションを行うということはそういうことだろうに。(だから要らないと言ってるのだが)
つーか、並列さん ◆dPfetnROQg　はコンパクションを何だと思ってるんだ？

**名前は開発中のものです。** · 2009/04/06(月) 04:09:51

>生成は頻繁に行なうわけで、生成時にタスク
>プライオリティが与えられていてその適切なところにinsertする
>コストはとても無視できない。

型ごとにheapを持ってればそんなむちゃくちゃな事にはならないし、
どちらかというと、不定期にGCが発動して、そのフレームだけ局所的に負荷が高くなる方が困る。
ゲームでGC使うのが嫌われる理由と同じだな。

**名前は開発中のものです。** · 2009/04/06(月) 04:13:47

>並べ替えは毎フレームしなくとも良いが(GCが走るのはときどきなわけだし)、
>タスクプライオリティは変更と同時に挿入しなおさなければならないから
>その比較はおかしい。

リアルタイム処理では一番負荷の高い瞬間で比較しなければならないので、
その比較であってる。いわゆるボトルネックという奴。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 04:19:36

>>114
>>「型ごとに集めることを考えて、それから並べ替える」ほうが、
>>「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは
>> 限らないんだが。
>> そんな自分のやりやすい方法を言われても。
>後者よりも前者の方が常に速い。
>前者だと、
>１．型ごとに集める処理を端折れる。
>２．型ごとに並べ替えた方が速い。なぜなら並べ替えの計算量はO(n*logn)だから。

1.は、意味不明。「型ごとに集めることを考えて」なのだから、端折れてないと
思うんだが。

2.は、どうもあんたはまだ話がわかっちゃいないと思う。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 04:22:45

>>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のような実装は不可だ。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 04:32:06

>>116
> オブジェクトに不変なハンドルつけて間接参照にしたり、
> ポインタをラップしてリストアップしたり。

だから、そんなプログラムが速いわけないだろ。

ハンドルに対する実アドレスのテーブルをcompactionのときに
更新しないといけないぞ。

他のタスクオブジェクトを参照するごとに
TaskA taskA= dynamic_cast<TaskA*>HandleToPtr(taskA_handle);
みたいに書く必要が出てくる。

プログラムが汚い上にハンドルだから型が不明になってしまう。

これひどくないか？

> コンパクションを行うということはそういうことだろうに。

それは、全然違うと思うぞ…。
少なくとも俺のシステムにあんたの実装のような欠陥はないな。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 04:33:07

>>116
> 型ごとにheapを持ってればそんなむちゃくちゃな事にはならないし、

(一般的には)型ごとにheapを持てない。理由 >>120。

**名前は開発中のものです。** · 2009/04/06(月) 04:35:38

>>119
型ごとに既に集まってるんだから、型ごとに集め直す必要はないだろ。

例えば、林檎と蜜柑と梨が何個かずつ有って、それぞれ種類別に箱に入ってるとする。
それぞれの果物には賞味期限があり、売れ残りを防ぐため、古いもが手前に来るように陳列したい。

A：林檎と蜜柑と梨をごちゃまぜにして、賞味期限順に並べ替えてから、改めて種類別に分け直す。
B：単にそれぞれの種類内で賞味期限順に並べ替える。

どっちが早いか。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 04:38:38

>>117
> どちらかというと、不定期にGCが発動して、そのフレームだけ局所的に負荷が高くなる方が困る。

さすがにそんなことは普通はない。
いや、あるにはあるが、そうならないように気をつけてコーディングする。

それすら出来ないなら、そもそもXNAでゲームプログラムなんて出来ないわけで…。

>>118
> リアルタイム処理では一番負荷の高い瞬間で比較しなければならないので、
> その比較であってる。いわゆるボトルネックという奴。

ボトルネックがコマ落ちしたりするほど大きくないなら、全体的なスループットのほうが大切。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 04:39:51

>>123は>>120を読む前に書かれたものだと思うので無視する。

**名前は開発中のものです。** · 2009/04/06(月) 04:46:06

もうね、
タスクシステムありきでいろんな問題（コンパクション・キャッシュヒット）に対処していくと、
最終的にはこんなことになってしまうかもしれないという悲劇の具体例にしか見えない。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 04:50:53

このスレではなんかメモリのコンパクション不要論を唱えてる
馬鹿ばっかりなんだが実際「ワンダと巨像」でもメモリの
コンパクションは、行なっている。

しかも「ワンダと巨像」ではテクスチャ、地形データのみならず、
プログラムコード自体も再配置の対象となっている。

ある程度の規模のゲームなら、やらざるを得ないと思うんだが。

お前たちは、本当にゲームを作っているのか？
夢のなかで作ってるだけなんじゃね？

プログラミング見習いとか、同人ゲー作ってますとか
サブプログラマーとしてスプライト処理手伝いましたとか
そんなゴミクズみたいな奴ばっかり出てくんなよ。

俺はもう寝るぞ。明日も早いからな。おやすみ。

**名前は開発中のものです。** · 2009/04/06(月) 04:55:46

>>120
後出しじゃんけんのごとく次から次へと変な実装例を出してくるなよ。
プライオリティーも型として扱えば？まぁプライオリティー固定になるが。
template < class t, int priority > とかして。

>>121
>プログラムが汚い上にハンドルだから型が不明になってしまう。

>これひどくないか？

そう思うのならラップすればよいだろ。本質的には同じこと。

**名前は開発中のものです。** · 2009/04/06(月) 05:18:01

＞プログラミング見習いとか、同人ゲー作ってますとか
いや、そもそもここはそういう人のための場だろ。
メイン張ってるプロ中のプロがこんな場所に出てくるんだったら、
そういう人たちに分かるように説明すべきじゃないのか？

つか、場当たり的に情報小出しにするより、ちゃんとまとめて本でも書いてくれ。
次のやねう本より先に出せば結構売れるんじゃないか。

**名前は開発中のものです。** · 2009/04/06(月) 05:24:15

>>124
>そうならないように気をつけてコーディングする。

だったら、普通にメモリプールで十分なわけで。

>ボトルネックがコマ落ちしたりするほど大きくないなら、全体的なスループットのほうが大切。

意味不明。コマ落ちしないなら、既に仕様を満たしているわけで、スループットも糞もないだろ。

>>127
ほとんどのゲームでは行ってないだろ。でもちゃんと動いている。それが現実。
一部の例外だけ取り上げて、さも当たり前かのように言うな。

**名前は開発中のものです。** · 2009/04/06(月) 05:40:29

横からだけど、ID:B8zjnpJZさんはちょっと素人っぽいよね。
私から見てても、なんか言ってることのレベルが低いというか。

実際に商用である程度の規模のゲームを作った経験のある人が
もっと並列さんに質問してほしいな。

**名前は開発中のものです。** · 2009/04/06(月) 06:20:06

まだ、やってんの？
あったまわるい
話受けるほうも相手にするなよ

**名前は開発中のものです。** · 2009/04/06(月) 06:43:47

夜を徹して生産性を下げる工作が成功してるようだな

しかしまともな議論をするなら情報後出しと言われないように議論命題に関する
クラス図なり、シーケンス図（サンプルシナリオ）なりを先に明示すべきだと思う
土台が無い状態で前提の違う俺言語同士の闘いをしてて不毛すぎる

**名前は開発中のものです。** · 2009/04/06(月) 07:10:15

>103
> これも違うね。型ごとに集めればworking setは小さくなるが、
> その集合に対してメモリの先頭から逐次的にアクセスしていく
> 保証はされない。

アクセスループに入る前にキャッシュの先読みくらいしとけよ。

**名前は開発中のものです。** · 2009/04/06(月) 07:24:50

>127
> ある程度の規模のゲームなら、やらざるを得ないと思うんだが。

フリーラン系でも無い限り、プレイ中にコンパクションなんてやらない。
シーン切り替えのタイミングでコンパクションすることはあるけどもね。

それよりも、シーンごとに破棄できるデータと常駐データを幾つかのレベルに分けて管理したほうが
楽だよ。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 09:03:31

>>128
> そう思うのならラップすればよいだろ。本質的には同じこと。

全然同じじゃない。

>>133
> しかしまともな議論をするなら情報後出しと言われないように議論命題に関する

そんなもん誰が読むんだ？悪いけど俺はそんなもの作成するのは嫌だ。

>>134
> アクセスループに入る前にキャッシュの先読みくらいしとけよ。

そんなことで解決する問題じゃない。

一般的に言って、L1に相当するメモリは極端に小さいからループに入る前に読み込んでも無駄だし、
指定しなくともどこか1バイトを読み込んだら、次のalignmentまで自動的に読み込む設計になってるのが
普通だから、いまどきのCPUアーキテクチャはランダムアクセスに対してはすこぶる弱い。

だから、先読みでは解決しない。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 09:06:56

>>135
> それよりも、シーンごとに破棄できるデータと常駐データを幾つかのレベルに分けて管理したほうが楽だよ。

そりゃ、仕様が事前にわかっていればそりゃそうしたほうが楽だろう。

しかし、いまどきのゲーム、シーン切り替えなんてほとんどなくてシームレスにつながっていることが多いから、
そういうケースに備えて、ライブラリ的なものを準備するのが俺の仕事。

**並列さん** ◆dPfetnROQg · 2009/04/06(月) 09:14:12

>>129
> メイン張ってるプロ中のプロがこんな場所に出てくるんだったら、
> そういう人たちに分かるように説明すべきじゃないのか？

そんな面倒な説明、俺は嫌だ。

少なくとも商用ゲーム開発してるプログラマだけ俺に質問してくれ。
それ未満の見習い君は黙ってROMってて欲しい。

>>131
確かにID:B8zjnpJZは素人っぽいではある。>128,130とかひどすぎて答える気にもならん。もうスルーしとく。

そもそもGC環境下でゲームプログラムを書くメリットとか、俺がこのスレで説明するこっちゃないと思うんだ。
実際に自分でXNAとかで開発して理解するか、もっとお偉方に聞いて欲しいなぁ。

**名前は開発中のものです。** · 2009/04/06(月) 09:49:19

アンチの中に配列好きの厨が混じってて吹いたw

**名前は開発中のものです。** · 2009/04/06(月) 09:58:39

つーかこの分量になると流し読みすらせずに流しちゃうな

**名前は開発中のものです。** · 2009/04/06(月) 12:07:22

アンチかつプロの人はステージとかシーンでゲームをくぎって、その場面に必要な物だけをハードコーディングするような昭和ゲームつくってるんだろ
now loadingとかやめろよwww

**名前は開発中のものです。** · 2009/04/06(月) 12:13:20

本当に叩きたい人に当たるようにブーメラン投げてるんですね。
わかります。よくある手ですから。

**名前は開発中のものです。** · 2009/04/06(月) 18:50:33

速度の話に区切り付けてから次の話題振れよ

**名前は開発中のものです。** · 2009/04/06(月) 19:12:19

>並列さん
根幹がズレてるのに
まだ、長々と話してるの？
自分のはじめた話のケツぐらいふけるようになってから議論しろよ

理論的にはじめの一歩目ですでにダメなのにそこには目を瞑って
オレオレシステムのいいとこ探しなんてはじめた時点で
お前はもう技術者でもなんでもねぇ
ただのクズだ

**名前は開発中のものです。** · 2009/04/06(月) 19:25:58

まだ続けるつもりか
いいぞもっとやれ

**名前は開発中のものです。** · 2009/04/06(月) 19:30:18

古典タスクシステムとそうでないのとの違いを教えてください。
比較があるHPが有りましたら教えてください。

**名前は開発中のものです。** · 2009/04/06(月) 19:36:40

>>146
そんな受身で技術なんか見に付くわけない
やめちゃえ

**名前は開発中のものです。** · 2009/04/06(月) 19:39:57

つかえない子が頑張ってるのがたのしいな
まともに説明できてない時点で自分の脳内でしか認められないものだと気付かないの？

**名前は開発中のものです。** · 2009/04/06(月) 19:52:04

ワンだと虚像って前評判ほど面白くなかったな。
見た目が派手なだけでパターン憶えゲーの中でも平凡なゲーム。

**名前は開発中のものです。** · 2009/04/06(月) 20:15:34

面白さがタスクシステムと関係あるの？

**名前は開発中のものです。** · 2009/04/06(月) 21:21:10

ゲーム業界VSアマチュアという構図が出来つつなるな。
ゲーム業界でがんばって来た人には、それなりにプライドもあるだろうし、触れられたくないこともあるのだろうな。
すべてが無駄だと薄々感づいてはいるのだろうが、気づかないふりをして毎日がんばってるのだろう。

**名前は開発中のものです。** · 2009/04/06(月) 21:23:11

>136
> そんなことで解決する問題じゃない。
> 一般的に言って、L1に相当するメモリは極端に小さいからループに入る前に読み込んでも無駄だし、
> 指定しなくともどこか1バイトを読み込んだら、次のalignmentまで自動的に読み込む設計になってるのが
> 普通だから、いまどきのCPUアーキテクチャはランダムアクセスに対してはすこぶる弱い。
> だから、先読みでは解決しない。

コンシューマ触ったこと無いのバレバレだな。

**名前は開発中のものです。** · 2009/04/06(月) 22:20:23

XNAで開発された商用ゲームってあるのかなぁ？今のところ国内メーカーはネイティブで作ってるみたいだけど。
カンファレンスでもXNAはホビーユース向けって感じだったし。

まぁそもそもMSと心中するつもりがなきゃMS縛りのXNAで開発なんてしたくないけどな。

**名前は開発中のものです。** · 2009/04/06(月) 23:13:38

>>153
黙ってろ

**名前は開発中のものです。** · 2009/04/06(月) 23:17:12

>>154
ＭＳ社員m9（＾Д＾）プギャー

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/04/07(火) 00:14:39

ガキの直感だけど
並列君ってやねうらおさんの臭いがする