トップページ⇒gamedev
1001コメント416KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001名前は開発中のものです。2009/04/03(金) 11:25:39ID:aSgRO8Wl
タスクシステムについての議論、相談、質問、雑談などのスレです

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」と明示してください
　そうでない場合はカスタム版であることを明示してください

・人を憎んで言語を憎まず
0002名前は開発中のものです。2009/04/03(金) 11:26:57ID:aSgRO8Wl
古典タスクシステム（このスレでは「>>2」と呼ぶ）

White Paper - Programming
http://homepage3.nifty.com/moha/programming.html

タスクシステム
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html

CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
http://codezine.jp/a/article.aspx?aid=297

Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html
0003名前は開発中のものです。2009/04/03(金) 21:08:48ID:4ENq10VK
習作だったりサンプルだったりするものをみて、それが全てだと思うヤツは無能。
0004＼＿＿＿＿＿＿＿＿＿＿＿＿＿／2009/04/04(土) 01:15:38ID:Xw/qJicY
　　　　　　　　　　　　　　 ∨
　　　　ビシッ　　／￣￣￣￣＼
　　　 ／￣＼（　　人＿＿＿＿）
　 ,　┤　　　 ト|ミ/　 ー◎-◎-）
　|　　＼＿／　 ヽ　　　　(_　_)　）
　|　　　＿_（￣　｜∴ノ　　３　ノ
　|　　　 ＿_）＿ノ ヽ　　　　　ノ
　ヽ＿＿＿） ノ 　　　））　　　ヽ.
0005名前は開発中のものです。2009/04/04(土) 01:36:51ID:DtrzgWRJ
∧∧
(,,ﾟДﾟ)＜　で？タスクシステムのメリットは説明できたの？ん？
0006名前は開発中のものです。2009/04/04(土) 13:33:22ID:2djxF09a
∧∧
(,,ﾟДﾟ)＜　で？『いわゆるタスクシステム』の仕組みは理解できたの？ん？

00075102009/04/04(土) 16:56:02ID:MhD49aWD
あーくそ。
前スレのID:EEKBitmg ◆HSP4mee/SU祭りに参加できなかった。
仕事していると辛いね。
0008名前は開発中のものです。2009/04/04(土) 18:12:06ID:DtrzgWRJ
>>6
それはすでに>>2にある
0009名前は開発中のものです。2009/04/04(土) 18:50:27ID:CWfOh7lL
>>8
これを要求していると読んだ。

http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/264
> タスクと書くだけで君のように異常な反応を示す人を釣ることができて
> 生産性を幾分かでも削ることができる。ライバルからすればいい武器だな。
> そのライバルは他の国や民族かもしれん。
>
> こんなスレを見てしまった段階で踊る阿呆に見る阿呆だが。
0010名前は開発中のものです。2009/04/04(土) 20:01:28ID:9125l3rK
前スレ>>988のメモリコンパクションについて聞きたい

一括解放するタイミングは存在せず、仕様切りなおしもできないとして、
ID:EEKBitmgは使用期間不定の大量のサイズ不定テクスチャを
コンパクションを使わずにどう管理する？
普通にやると、だんだんメモリがフラグメントしてきて
最後にはメモリに乗るはずのテクスチャが乗らなくなるよな

俺もコンパクションは嫌いだしムダに複雑になるだけで費用対効果が薄いと思うが
仕様によっては必要悪だと思うんだが・・・別の解決策があるのなら知りたいマジで
0011名前は開発中のものです。2009/04/04(土) 20:16:31ID:MhD49aWD
PCの場合だけで考えると、MMUついてるし、そもそもテクスチャ管理するのはDirectXだし。
0012名前は開発中のものです。2009/04/04(土) 21:27:31ID:2djxF09a
そんな下層のことまで気にしてゲーム作らないよ。
そういう部分を気にするのはR&D部署だから、開発のウチらにはカンケー無い。
0013名前は開発中のものです。2009/04/04(土) 22:06:58ID:MhD49aWD
というか、MMU付いていないハードで
>　一括解放するタイミングは存在せず、仕様切りなおしもできない
するな。
0014名前は開発中のものです。2009/04/04(土) 22:21:25ID:9125l3rK
おれはID:EEKBitmgに聞いてるんだが・・・

偉そうに回答してくれんのは別にいいけど、せめて「コンパクション要・不要」の立場を明確にしてから言ってくれ
0015名前は開発中のものです。2009/04/04(土) 22:41:09ID:DtrzgWRJ
>>14
その話とタスクシステムはどう結びつくの？
スレ違いじゃない？

もちろんタスクシステムのメリットとの話ともリンクしてるんだろうな？
0016名前は開発中のものです。2009/04/04(土) 23:57:30ID:MhD49aWD
頭悪いんだから放っておいてやれよ
0017名前は開発中のものです。2009/04/05(日) 01:47:17ID:A6XSNxaW
>>12
R&Dがあるような会社はタスクシステムも気にする必要無いんじゃね？
0018並列さん ◆dPfetnROQg 2009/04/05(日) 03:23:57ID:KXq+7Jyb
>>15
俺は14ではないが、メモリのコンパクションを行なうには、それぞれのオブジェクトに対するstd::listのようなものが
必要になるので、(典型的な)タスクシステムに搭載されているstd::listのようなものをそのまま流用すれば一石二鳥だから、
タスクシステムはメモリのコンパクションまで行なうように拡張しておけば、タスクシステムのフレームワークとしての
利用価値がさらにあがるという風にタスクシステムとメモリのコンパクションとは密接に関係している。

まあ、このスレのアンチタスク派は、まともな規模のゲームプログラムなんて作ったことなさそうだから、
メモリのコンパクションなんてやる必要性すら理解してないんだろうけども。
0019名前は開発中のものです。2009/04/05(日) 04:03:20ID:SofMJMSf
なら、テクスチャや音声や、その他mallocやnewするもの全部をタスクとして実装するの？
頭おかしいんじゃない？大丈夫？
0020名前は開発中のものです。2009/04/05(日) 04:14:18ID:XP6NPTaD
16bit機から現行機までコンシューマ機で動的にメモリコンパクションしてるのなんて見たこと無いな。
馬鹿でかい連続領域を確保するものと、パーティクルみたいに小さい固定領域を大量に確保するもの
だけを別扱いに管理する、ぐらいでやりくりできてたし。

そんなの必要になるのサーバー側とかだけじゃない？
0021名前は開発中のものです。2009/04/05(日) 04:43:57ID:SofMJMSf
サーバーにはMMUついてるだろ。
0022並列さん ◆dPfetnROQg 2009/04/05(日) 04:57:03ID:KXq+7Jyb
>>19
> なら、テクスチャや音声や、その他mallocやnewするもの全部をタスクとして実装するの？

そんなことは誰も言ってない。

そもそもテクスチャやサウンドのような巨大なresourceにとって必要なのはメモリのコンパクションではなく、
(cacheのような仕組みを提供する)マネージメントだろ。

それはcacheを実現するためのシステムを別で用意する。

それ以外でmallocやnewを使うかだが、ゲームによっては、タスクオブジェクトとテクスチャ/サウンド等の
巨大リソース以外ではmalloc/newでのメモリ確保は不要なことが多いので、そういう作りをここでは俺は
想定している。
0023並列さん ◆dPfetnROQg 2009/04/05(日) 04:59:24ID:KXq+7Jyb
>>20
> 16bit機から現行機までコンシューマ機で動的にメモリコンパクションしてるのなんて見たこと無いな。

その"現行機"にXNA環境は含まれてないの？
0024名前は開発中のものです。2009/04/05(日) 05:02:06ID:XP6NPTaD
MMUの有無だけでいえばMSハードはMMUついてるよ。メモリスワッピングしないだけで。

そしてサーバー側はメーカーによるけど意外とチープな民生用32bit Linuxマシンを使ってたり
するので4Gの壁でMMUとは別の理由でメモリコンパクションが必要になったり。

クライアント側はメーカーのエージングチェック通る時間動けばいいけど、サーバー側は連続稼働時間
長いからねぇ

>>23
>その"現行機"にXNA環境は含まれてないの？
含まれてます。がネイティブじゃなくXNAで動いてるゲームはまだサンプル以外見たことが無いな。
0025名前は開発中のものです。2009/04/05(日) 05:08:36ID:SofMJMSf
>>22
では、タスクにだけメモリコンパクションかけるつもり？意味無くない？
どっちにしろ頭沸いてるとしか思えないのだが。
0026並列さん ◆dPfetnROQg 2009/04/05(日) 05:26:56ID:KXq+7Jyb
>>25
> では、タスクにだけメモリコンパクションかけるつもり？意味無くない？

メモリのコンパクションを行なうことで、CPU cacheに載りやすくなるし、
タスクに対してtraverseするときになるべくメモリをリニアにアクセスできるようになっていれば
プリフェッチした分が無駄にならないから、そこでも効果があがる。

計測してみればすぐにわかると思うが。
0027名前は開発中のものです。2009/04/05(日) 05:31:54ID:w7j54ekv
>>25
同意
もうなにいってるのかさっぱりわからない
っていうか馬鹿黙れよって感じ
0028名前は開発中のものです。2009/04/05(日) 05:41:29ID:SofMJMSf
現実問題として、リニアにアクセスなんて出来ないし、意味ないね。
0029並列さん ◆dPfetnROQg 2009/04/05(日) 05:46:00ID:KXq+7Jyb
>>27
馬鹿はお前

>>28
> 現実問題として、リニアにアクセスなんて出来ない

出来る。

典型的なタスクシステムならタスクプライオリティを持っているので、
コンパクションのときにメモリ上でタスクプライオリティ順に並ぶように配置しなおしてやれば
タスクに対してtraverseする効率があがる。
0030名前は開発中のものです。2009/04/05(日) 05:50:57ID:SofMJMSf
どうせタスクの中で他のタスクにアクセスするだろうし、
そんなところをちまちま最適化しても意味無いって。
どうせ他のところが重いから。
0031名前は開発中のものです。2009/04/05(日) 06:04:17ID:SofMJMSf
だいたい、市販ゲームでも、メモリコンパクションしているゲームってそんなに無いだろ。
やってる奴あっても、メモリ制限が厳しいから仕方なく導入しているってだけで、
速度向上を狙ったものは聞いたことが無い。
0032並列さん ◆dPfetnROQg 2009/04/05(日) 06:14:40ID:KXq+7Jyb
>>30
> そんなところをちまちま最適化しても意味無いって。

そんなことないよ。

最近のプロセッサになればなるほどDRAMが(CPUに較べて)相対的に遅く、
扱うオブジェクトの数が多いとプリフェッチ出来ているのと出来てないのとでは大違いなんだが。

「他のタスクにアクセスする」部分にしても、シューティングで自機と弾との衝突判定をするなら
弾オブジェクトはメモリ上でリニアに並んでいるほうがアクセス効率が良いのは自明。
0033並列さん ◆dPfetnROQg 2009/04/05(日) 06:19:31ID:KXq+7Jyb
>>31
> やってる奴あっても、メモリ制限が厳しいから仕方なく導入しているってだけで、

あんた何もわかってないね。

近代的な言語が、GCを搭載するのはメモリ制限を回避するためだけかい？違うだろ。
0034名前は開発中のものです。2009/04/05(日) 06:35:18ID:SofMJMSf
何も分かってないのはお前だって。
タスクシステムのタスクのコンパクションによるキャッシュヒット率の向上が有効になるのは、
小さなタスクが何万も有る場合だが、
タスクシステムの特性から、updateが仮想関数になる以上、
やってる事がチグハグなんだよ。

ストーブつけながらクーラーつけてるみたいなものだな。
0035名前は開発中のものです。2009/04/05(日) 06:36:15ID:XP6NPTaD
DRAMメモリアクセス速度みたいなハード寄りな理由で近代的なGC搭載言語の話をするのは何かずれてるような…
0036並列さん ◆dPfetnROQg 2009/04/05(日) 06:59:38ID:KXq+7Jyb
>>34
> タスクシステムの特性から、updateが仮想関数になる以上、

そうとは限らない。

>>35
ずれてない。あんたもGCが何のためにあるのか理解してなさそう。
0037名前は開発中のものです。2009/04/05(日) 09:37:40ID:w7j54ekv
並列さん黙れよ
あんた自分がなにやってるかさっぱりわかってないじゃん
0038名前は開発中のものです。2009/04/05(日) 11:11:35ID:3oSTBu7p
＞タスクシステムの特性から、updateが仮想関数になる以上、

･･･ﾊｧ????
0039名前は開発中のものです。2009/04/05(日) 14:46:01ID:ZnQmmsrk
並列さんは、updateのなかで型を見ながらswitchするつもりなんじゃね？
0040名前は開発中のものです。2009/04/05(日) 15:41:58ID:MilQiQIm
久しぶりに来たら次スレ建ってて笑った。
相変わらずタスクじゃない話題で賑わっているね。
メモリコンパクション実装する前に他にやることあるんじゃねぇの〜
0041並列さん ◆dPfetnROQg 2009/04/05(日) 18:18:06ID:KXq+7Jyb
>>37
あんたがわかってないだけ。内容についてこれないなら、黙れ。

>>39
そんなへたれなコードはさすがに書かない。

template typename<T> update(T& actor);

こういうtemplateを用意して、これが呼び出される。(以下略)

>>40
> メモリコンパクション実装する前に他にやることあるんじゃねぇの〜

他にやることはやってあるという前提で話している。
また>18で書いたようにこれはタスクと関係ない話題ではない。
0042並列さん ◆dPfetnROQg 2009/04/05(日) 18:25:43ID: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される。
もちろん、関数呼び出しのオーバーヘッドは存在しない。
0043名前は開発中のものです。2009/04/05(日) 18:25:46ID:MilQiQIm
>>41
1点だけ知りたいのだが、並列さんはタスクシステムをメモリコンパクション仕様で書いて実装し、実際に運用したことがあるのかい？
必然的に粒度の大きくてしかもタスク切り替えの少ない場合のみのタスクしか適用できないとおもうのだが。正気の沙汰とは思えない。
0044名前は開発中のものです。2009/04/05(日) 19:25:11ID:ZnQmmsrk
>42
> もちろん、関数呼び出しのオーバーヘッドは存在しない。

全てのTに対して同じupdateが呼び出されるけどな。
0045並列さん ◆dPfetnROQg 2009/04/05(日) 20:48:32ID:KXq+7Jyb
>>43
> 1点だけ知りたいのだが、並列さんはタスクシステムをメモリコンパクション仕様で書いて実装し、実際に運用したことがあるのかい？

もちろんだよ。ある大手の商用ゲームで使ってるよ。

> 必然的に粒度の大きくて

逆だよ。GC環境は粒度の小さいオブジェクトを大量に
newしたりdeleteしたりするのに適している。

それは、GC環境下ならnewの実装が単純化されるので
通常のheap allocとは比べものにならないほど高速だから。

>>44

もちろん。update(const collection<T*>& actors)の呼び出し側で
もうひと工夫してある。あんたなら、みなまで言わずともわかるだろ。
0046名前は開発中のものです。2009/04/05(日) 22:29:45ID:qdg6blW7
テクスチャとか、でかい連続領域が欲しいときにメモリコンパクションしたくなるのは
まぁわからんでもないんだけど、 new/delete する C++ オブジェクトの話だったの？
そうなるとまるで必要性がわからん。

だれか並列さんの話についていけてる人がいるのか？
0047名前は開発中のものです。2009/04/05(日) 22:43:11ID:ZnQmmsrk
>45
あぁ、switch〜caseじゃダメっぽいから、関数テーブルにでも変更してみたか？
0048並列さん ◆dPfetnROQg 2009/04/05(日) 22:44:01ID:KXq+7Jyb
>>46
> そうなるとまるで必要性がわからん。

"必要"なのではない。誰もそんなことは言っていない。

GCがあったほうが設計が楽になるというのと、
メモリのコンパクション(とオブジェクトの並び替え)を行なったほうが
メモリアクセスの効率が上がる(>>26 >>29 >>32)と俺は言っている。
0049名前は開発中のものです。2009/04/05(日) 22:45:59ID:XP6NPTaD
>>45
>それは、GC環境下ならnewの実装が単純化されるので
”GC環境”ってひとくちにいっても”タスクシステム”並に千差万別だけど…
どんな前提のGC環境なら、GC環境を構築したC/C++よりもheap allocが高速になるのか、教えて欲しいなぁ
スレッドを使わないスクリプト系言語で、同期処理が不要だから、とかheap独自管理だから、とかか？
それならスレッド使わない、heap独自管理したC/C++系の方が高速になりそうだが。
0050名前は開発中のものです。2009/04/05(日) 22:48:37ID:SofMJMSf
>>42
それだったら、ただのstd::vectorと同じじゃん。
自分でも書いてるけど、本当ただのcollectionでしかなく、どのあたりを工夫しているのかも不明。
そのレベルのコンパクションでよいのなら、std::vectorでもしてくれる。

個人的には、タスクシステムにメモリ管理までさせている時点で糞だな。
タスクを何処にどういう風に確保するかは、タスクシステムの利用者が決めれるようにしておいた方が良い。
どういうメモリ配置にすべきかはケースバイケースで、
ベストな配置はゲームの仕様を知ってるであろうタスクシステムの利用者にしか分からない。

逆に言えば、タスクシステム内で、変なメモリ管理なんてしようとするから、
メモリコンパクションなんていう、どうでも良いことを考えなきゃいけなくなる。
ゲームの仕様も分からないのに、適切なデータ配置が出来るわけが無い。

まぁ、そうやって自分の権力の範囲を伸ばすことで、食いっぱぐれないようにしてるんだろうけどな。
老害というやつだな。
0051名前は開発中のものです。2009/04/05(日) 22:51:31ID:SofMJMSf
もう一度いうが、キャッシュヒット率まで考えてデータの配置をするというのなら、
タスクシステムに勝手にデータを並べ替えられるのは迷惑だ。
タスクシステムはゲームの仕様を知らないからな。
0052名前は開発中のものです。2009/04/05(日) 22:54:56ID:qdg6blW7
"Premature optimization is the root of all evil" ってやつだな。

こういう話してると、また「言うまでもなく、この最適化を行うかどうかはユーザーが
選択できるようになっている」とか返ってきそうだけど。
0053並列さん ◆dPfetnROQg 2009/04/05(日) 22:55:09ID: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*> >の関数テーブルを用意するのか？」と
いう質問なら、「そんな馬鹿な実装にはするはずがない」と答えるよ。
0054名前は開発中のものです。2009/04/05(日) 22:57:12ID:SofMJMSf
>template typename<T> void update(T& actor);
はインライン関数で書いても同じなのに、いちいちテンプレート使うのはコンパイラへの嫌がらせか。
わざわざテンプレートでかく意図が分からない。
コンパイラによるのかもしれんが。
0055名前は開発中のものです。2009/04/05(日) 23:04:40ID:qdg6blW7
>>53
メモリアクセスの最適化が要るループの中でインスタンス単品のアドレスをキーにした
ハッシュテーブルをひくのが「いいけどね」なの？もうわけわからん。
0056並列さん ◆dPfetnROQg 2009/04/05(日) 23:07:06ID: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の実装をしないつもりか？
0057並列さん ◆dPfetnROQg 2009/04/05(日) 23:20:19ID:KXq+7Jyb
>>55
> メモリアクセスの最適化が要るループの中でインスタンス単品のアドレスをキーにした
> ハッシュテーブルをひくのが「いいけどね」なの？

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

どうやれば本当に効率が改善されるのか自分の頭を使って考えたらどうだ？
0058名前は開発中のものです。2009/04/05(日) 23:21:29ID:XP6NPTaD
>>56
>俺は、>>45 では、GC環境なら、C/C++のheap allocより高速なnewの実装が可能に
>なることは言ったが、「GC環境を構築したC/C++よりも」だなんて一言も言ってない。
矛盾した返答だなぁ

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

GC環境とやらがネイティブのC/C++(≠ASM)にパフォーマンスで勝負するのは勝ち目が無いんで無い？
0059名前は開発中のものです。2009/04/05(日) 23:22:09ID:ZnQmmsrk
>53
C++っぽいけど全然違う脳内言語を使って脳内コンパイルしてるだけなら、その程度の話でいいのかもね。
0060名前は開発中のものです。2009/04/05(日) 23:24:28ID:SofMJMSf
>>56
>その理屈はおかしい。
>あんたはゲームの仕様が決まるまでnewやdeleteの実装をしないつもりか？

その理屈でいくのなら、自前のcollectionなんて実装せずにnewやdeleteを使ってれば良い話になるだろ。
ところがお前は、newやdeleteはタスクシステムの仕様に無頓着だから、
タスクシステムの仕様にあったアロケータを自前で開発すべきだと主張してる。
それに対して俺は、タスクシステムはゲームの仕様に無頓着だから、
ゲームの仕様にあった方法でデータは確保すべきだ、と返しているわけで。
0061名前は開発中のものです。2009/04/05(日) 23:30:02ID:qdg6blW7
>>56
> std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
> 全部そこに突っ込む(push_back)するつもりか？

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

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

いや、しないだろ、当然。コンパイラが一般的な実装は提供してくれるんだから。
ゲームの仕様がなければ自分で実装する目的が無い。
0062並列さん ◆dPfetnROQg 2009/04/05(日) 23:31:38ID:KXq+7Jyb
>>58
何か話が噛み合ってない気がする。

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

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

これはGC環境下ではないC/C++で書くカスタムアロケータより
十分高速だと思うが、これより速い実装が可能だと言うなら教えてくれ。
0063並列さん ◆dPfetnROQg 2009/04/05(日) 23:34:08ID:KXq+7Jyb
>>62
自己レスだが、メモリを上位から下位に確保していくheapなら

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

こうなる。こっちでもいい。
0064名前は開発中のものです。2009/04/05(日) 23:34:12ID:qdg6blW7
>>57
collection の要素型がポインタになってるけど、別に派生クラスとか update の詳細が
異なるインスタンスをいっしょに入れるわけじゃなくて、単一クラスのコレクションなの？

それなら、なおさら std::vector に生で入れたほうが速そうだなぁ。
0065名前は開発中のものです。2009/04/05(日) 23:36:14ID:XP6NPTaD
>>62
あのー、これheap allocでなくstackでない？
0066名前は開発中のものです。2009/04/05(日) 23:37:09ID:w7j54ekv
どう考えてもゲームの仕様依存の問題にここまでしつこいのって馬鹿じゃね？
設計失敗してるのにねばってて馬鹿みたい
プログラマやる前にまず大人になれよｗ
0067名前は開発中のものです。2009/04/05(日) 23:38:02ID:SofMJMSf
>std::vector<XXXTask>のようなものを用意して、XXXTask型のオブジェクトは
>全部そこに突っ込む(push_back)するつもりか？

型ごちゃまぜ状態でコンパクションかけるよりは、
同じ型は同じ配列に集めてコンパクションかけた方が、まだましだろう。
同じ型のデータは連続的にアクセスされる可能性が高いからな。
型ごちゃ混ぜ状態でコンパクションかけますっていうのなら、
頭どうかしてますとしか言いようが無い。ゲームでそこまでする必要なし。
0068並列さん ◆dPfetnROQg 2009/04/05(日) 23:41:04ID:KXq+7Jyb
>>60
なんか話が噛み合ってない原因がわかった。

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

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

GC環境下のほうが、小さなオブジェクトの生成/解体には有利で、
どうせGCを搭載するなら、コンパクションをやるついでにタスクの再配置も
したほうがCPU cacheの効率があがるということを主張している。
0069並列さん ◆dPfetnROQg 2009/04/05(日) 23:42:24ID:KXq+7Jyb
>>65
> あのー、これheap allocでなくstackでない？

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

定期的にGCがメモリのコンパクションを行なうから、heap allocはただひたすら
メモリの上位(or 下位)に向かって確保していくだけでいいんだ。
0070名前は開発中のものです。2009/04/05(日) 23:43:40ID:w7j54ekv
なんで話がかみ合ってないとか言い出すの？
もう疑いようもなく頭悪いのにｗ
なんでかみ合ってないとかやめてよ
きたねぇなさわんなよ気持ち悪い
0071並列さん ◆dPfetnROQg 2009/04/05(日) 23:44:27ID:KXq+7Jyb
>>66,70
馬鹿はお前。話についてこれないなら黙れ。
0072名前は開発中のものです。2009/04/05(日) 23:44:39ID:XP6NPTaD
>>69
これがGC環境のどんな言語のソースかわからんけど、
GCアルゴリズムが使われる以上、allocについてもGCのコストを考えんといけんわけだが…
「コード上」の見た目だけはC/C++で書くカスタムアロケータより速そうだね。見た目だけは。
0073名前は開発中のものです。2009/04/05(日) 23:48:22ID:w7j54ekv
>>71
だってすっげ頭悪いじゃん
全然意味ないことやってるじゃん
0074並列さん ◆dPfetnROQg 2009/04/05(日) 23:50:27ID:KXq+7Jyb
>>72
> allocについてもGCのコストを考えんといけんわけだが…

もちろん、そう。

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

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

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

GCの話題はスレ違いっぽいから、これ以上は自分の目で確かめてくれ。
0075名前は開発中のものです。2009/04/05(日) 23:51:52ID:qdg6blW7
>>62
これ、ちゃんと適用範囲限定して、ゲームの仕様にあわせて使えば GC のコストもなしに
使えてもっと速いのに。っていうか、そういう使い方ならわりと実際に使われてるはず。

region allocator ってやつね。

これが「GC環境下のheap alloc」と言い切ってしまうのが、なんとも、ねぇ。
0076名前は開発中のものです。2009/04/05(日) 23:53:14ID:SofMJMSf
>GC環境下のほうが、小さなオブジェクトの生成/解体には有利で、
>どうせGCを搭載するなら、コンパクションをやるついでにタスクの再配置も
>したほうがCPU cacheの効率があがるということを主張している。

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

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

そうとは限らない。

普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
0078名前は開発中のものです。2009/04/05(日) 23:57:17ID:XP6NPTaD
Boehm GCを使いながらキャッシュヒットの利点を持ち出すのか…
やはり根本的に矛盾しているというか何というか。
0079並列さん ◆dPfetnROQg 2009/04/05(日) 23:58:02ID:KXq+7Jyb
>>75
> これ、ちゃんと適用範囲限定して、ゲームの仕様にあわせて使えば GC のコストもなしに
> 使えてもっと速いのに。

もちろんそうだよ。
0080並列さん ◆dPfetnROQg 2009/04/05(日) 23:59:48ID:KXq+7Jyb
>>78
> Boehm GCを使いながらキャッシュヒットの利点を持ち出すのか…
> やはり根本的に矛盾しているというか何というか。

Boehm GCは、GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を
含めても)速いということを示すために挙げただけだ。
0081名前は開発中のものです。2009/04/06(月) 00:05:36ID:kRCgeJ2q
>>80
>GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を含めても)速いということを示すために挙げただけだ。
この文章だと全てのGC環境が非GC環境に比べてオブジェクトの生成/解体が速いって意味になりそうだけど
ほんとにそー思ってる？
それとも何か自分だけ常識と思ってる前提でもあるのかね。
0082名前は開発中のものです。2009/04/06(月) 00:07:16ID:SofMJMSf
>普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
メモリ使用量を減らすためだろ。
今は高速化についての話をしているはずでは？
0083名前は開発中のものです。2009/04/06(月) 00:13:08ID:B8zjnpJZ
>Boehm GCは、GC環境下のほうがオブジェクトの生成/解体は(GCのCPU時間を
>含めても)速いということを示すために挙げただけだ。

速かろうが遅かろうが、タスクシステム内でやるべきことでは無いわけで。
タスクをどう確保するかはタスクシステムの利用者に委ねるべき。
0084並列さん ◆dPfetnROQg 2009/04/06(月) 00:13:20ID:yXbkibtb
>>81
> この文章だと全てのGC環境が非GC環境に比べてオブジェクトの生成/解体が速いって意味になりそうだけど
> ほんとにそー思ってる？

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

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

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

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

.NET FrameworkのGCに関してはいろんな環境と比較したり
速度を計測したりしたし、俺GCを実装するときの参考にさせてもらった。
0085名前は開発中のものです。2009/04/06(月) 00:14:51ID:QqdC07mx
GCスレ立てろよw
0086並列さん ◆dPfetnROQg 2009/04/06(月) 00:20:34ID:yXbkibtb
>>82
>>普通のGCが型ごとにコンパクションをかけない理由を考えてみてくれ。
> メモリ使用量を減らすためだろ。

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

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

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

また、「タスクメモリをどう確保するか」は、タスクシステム側が決めても
構わないと俺は思う。タスク"システム"なんだから、嫌なら、そのシステムを
使わなければいいだけのことじゃん。
0087名前は開発中のものです。2009/04/06(月) 00:30:13ID:B8zjnpJZ
>違うね。速度面でもメリットがある。
無いね。ごちゃ混ぜにするより、同じ型を隣に並べた方がゲームの場合キャッシュヒット率が上がる。
同一型は同一ループ内で処理されるのが普通だからな。
0088名前は開発中のものです。2009/04/06(月) 00:32:14ID:B8zjnpJZ
つーかいつからGC前提の話になったんだよ。
>>18の発言はどうするつもりだ？
タスクシステム実装するならコンパクションも実装した方が一石二鳥だって話じゃなかったのかよ。
0089名前は開発中のものです。2009/04/06(月) 00:40:06ID:QqdC07mx
タスク厨はマジでしょうもないなwww
コンパクションやGCが必要になるほどの規模で、モノ作ってるワケでもあるまいにwww

たかがタスクのコレクションを順次処理していくだけなのに、キャッシュ効率だの速度だの気にしてる方が
バカらしいwww
0090名前は開発中のものです。2009/04/06(月) 00:40:40ID:gHjH+Kkr
>>87
ごちゃ混ぜコンパクションの速度面のメリットも、同じ型を隣に並べた場合の
キャッシュヒット率向上も、同じぐらいにいいかげんな話だと思うよ。

速度を上げたかったら、まず計測してボトルネックを見つけて、そこを叩かなきゃ。
0091902009/04/06(月) 00:42:54ID:gHjH+Kkr
あ、ボトルネックを見つけた後の対処としては、コンパクションを実装するより
オブジェクトを配列にまとめたほうがはるかに簡単で効果的だと思うけどね。
0092並列さん ◆dPfetnROQg 2009/04/06(月) 01:05:15ID:yXbkibtb
>>87
> 無いね。ごちゃ混ぜにするより、同じ型を隣に並べた方がゲームの場合キャッシュヒット率が上がる。
> 同一型は同一ループ内で処理されるのが普通だからな。

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

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

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

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

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

B.なら、上に書いたのと同じ理由に加えて、動的な型を判定してvector<T>に突っ込んだり、
その参照を書き換えたりするコストが必要になるので、あんたが思っているようには速くならない。
0093名前は開発中のものです。2009/04/06(月) 01:08:56ID:B8zjnpJZ
並列さん ◆dPfetnROQgは、
キャッシュヒット率が上がるからと、わざわざコンパクションをかけ、さらにはタスクの並べ替えまで行うという。
最適なデータ配置はゲームの仕様によりけりで、
ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は無意味だと言うのに。
しかも、コンパクションの実装もまずい。
型ごとに配列で保持してコンパクションかければ良いだけのものを、
わざわざごちゃ混ぜ状態で保持して折角のキャッシュヒット率を落としてしまうというセンスの無さ。
なにやってんだか。
よくよく聞けば、本職がソフト屋で、さらにゲーム関係に携わってるとか。
ハード屋の俺と争ってる時点で終わってるね。
極めつけは、タスクをどう確保するかはタスクシステム側が決める、嫌なら使わなければ良いだけだ、
などという、ソフト屋独特の独善的な恥ずかしい発想。
まずは大人になってください。
0094名前は開発中のものです。2009/04/06(月) 01:13:04ID:QqdC07mx
構図が一緒なんだよなw

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

0095名前は開発中のものです。2009/04/06(月) 01:18:54ID:/+Me6qfs
結論は意味がないのに話にのるなよ馬鹿だろ？
根本がまずい

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

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

こんな議論何時間したって無駄じゃん
すればするほど馬鹿になってくだけ
0096名前は開発中のものです。2009/04/06(月) 01:19:40ID:/+Me6qfs
ああ、それと

>並列さん ◆dPfetnROQg
そんなに馬鹿ならＰＧやめちゃえよ
0097名前は開発中のものです。2009/04/06(月) 01:31:57ID: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 >();

お前本当にソフト屋か？
0098名前は開発中のものです。2009/04/06(月) 01:51:15ID:y7ZcPLoJ
>>93
> 最適なデータ配置はゲームの仕様によりけりで、
> ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は
> 無意味だと言うのに。

全くその通りなんだけど、ほぼ
タスクシステムを実装する人＝それを使う人
なんじゃないのかな。
少なくとも仕様について直接話ができる関係でないと
タスクシステム自体を使えないと思う。
つまりありえない仮定を置いて否定するのはフェアじゃないし
技術の話としても意味が無いと言いたい。
0099名前は開発中のものです。2009/04/06(月) 01:53:56ID:B8zjnpJZ
並列さん ◆dPfetnROQg よ・・・
現実逃避目的にプログラム書くのなら、もうプロ辞めろ。
タスクシステムでキャッシュヒット率を上げようという目的も不味ければ、
その実装手段も不味い。
普通、どちらかぐらい真っ当なものなのだが。
これからは農業の時代だと聞くぞ。
0100982009/04/06(月) 01:59:15ID:iTEC611J
一応書いとくと並列さんの味方したいわけじゃなくて
並列さんの主張は独善的で視野が狭いと思う。
# 技術的な話を盛り上げるためにつっこみどころ満載の
# ネタを意図的に投下してるのかもしれんけど
0101名前は開発中のものです。2009/04/06(月) 02:07:50ID:B8zjnpJZ
>>98
>タスクシステムを実装する人＝それを使う人

だったとしても、

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

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

どうであれ、キャッシュヒット率まで考えたデータの配置を考えると言うのなら、
(タスクシステムを実装する人＝それを使う人、で有ろうが無かろうが)
タスクシステムの外から行う方が話が早い。
■ このスレッドは過去ログ倉庫に格納されています