- PR -

アンマネージのC++でメンバクラスをもちつつ、VBから利用できるソフトの作り方(LinuxSquareより移動しまし

«前のページへ 1|2
投稿者投稿内容
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2005-03-30 07:35
引用:

チキンさんの書き込み (2005-03-26 09:18) より:
○[DLLImport]部分で、2.8Gのマシンで20MSくらい直接Callよりも余分にかかる。

Mはメガ
ミリはm
チキン
会議室デビュー日: 2005/03/15
投稿数: 11
投稿日時: 2005-03-30 19:14
Jittaさん
分かりにくい文章をご指摘されて、同感です。申し訳ありません。で少し追加で説明をしますと、色々と誤解されている点は当方の表現の方法の問題と、言葉を誤ったことおよび非常に特殊なアプリを開発していることから来ていると思います。
１．VBと言わないで、すべてVB.NETと言うべきでした、古いBasicは全く使っていません、プロトもVB.NETで作りました。
２．アプリは戦略ゲームで、1個の判断に、軽く、10万回のケースを調べるような類のソフトです。市販のソフトは誰もDBを使っていませんし、使う気持ちになりません。最も高速のDBの最低10倍は早くならないと、使いものになりません。では、実際どうしているかと言うと、データ構造の大きさを、100MBくらいであきらめて、それ以上大きなデータを必要とする戦略の考察を、止めているのが、現状です。ところが、もし、10GBとかのDBを扱えたら活気的なゲームソフトが可能ではないかと考えて、今に至っています。早いことが何しろ大切なソフトです。そのためには、アセンブラーの利用や、マイクロコードも最終的には一部導入する可能性があるという世界です。DBは別ですがゲームソフト本体ではここまでやっている人があります。変な世界ですみません。分かりにくかったと思います。
３．個人的な経験では、専門の仕事としてメーカ固有OS上の市販のDBソフトの一部を10年くらい作っていたことがあり、いかに、DBソフトが、汎用性のために、速度をあきらめているかは痛く分かっています。しかし、また、この汎用性がDBソフトの命ともいえます。
また、バッファーの有効なキャッシングは非常に重要ですが、今回の、一度書くとUpdateやDeleteがないと言うデータの特性が、画期的に利用できると踏んでいます。
あるいは、いま、CPUはGHｚなのに、メモリは100nsのサイクルで、きわめて遅く、CPUのキャッシュのヒット率が致命的になってきていると思いますが、汎用的にこの問題を解決できていないのが現状で、個別に特殊解なら作れるかも知れないと思ってます。
４．そこで、今回、VB.NETを残したまま、市販のDBソフトより10倍早いDBソフトと言うか、（汎用性がないので、単にDiskも使える特殊Indedx構造体といったほうが正確なのでしょうが）を作ってみようとおもっています。

５Windowsの世界は、素人そのものですが、今後は、開発を、Windowsでやりたいと考えています。なんといっても、シェアが大きいです。それで、色々と分からないことを教えていただけると助かるなとおもっています。よろしくお願いします。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2005-03-31 21:00
　ゲームですか．．．確かに、スピード命ですね。私も、N60-BASICで苦労したことがありますから（いつの話だ）、わからないでもないです。

　ただ、10GBのデータとなると、他の問題もありますよね。つまり、圧縮／展開です。また、10GBのデータをどうやって配布しますか？ダウンロードするにしてもアレだし、DVDに入れても３枚？また、それだけのディスク容量を用意できるのか、というのも問題だと思います。ヘビーゲーマーなら10GBくらい用意するでしょうが、あるいはそのゲームのためだけに用意するでしょうか。
　また、本当に10GBを一時にメモリ上に展開しなければならないなら、ハードディスクの空きはインストール用の10GB以上の他に、ページファイル用に10GB以上が必要になるわけですよね。

　ネットワークゲームというのがあったか(^^;
　それだと、ひとりがするだけでなく、予定参加人数の２倍程度の余裕を見ておかなければならないですね。
　あ〜、でも、ネットワークゲームのサーバーでメモリが256MBってことはないか。

　アンマネージの、というのが気になるのですが、CLRが実行直前にネイティブコードにコンパイルして、ということを気にされているなら、先にコンパイルしておく方法もあります。「ngen.exe」をキーに、検索してみてください。
　それ以外の部分でアンマネージC++の方が速いだろうと思われているなら、C++自体が遅いです。オブジェクト指向言語は、実行時解釈やオブジェクト生成のオーバーヘッドなどのために、非常に実行速度の遅い言語です。アセンブラか、マネージ／アンマネージにかかわらず、C++ではないただのC言語を使うべきだと思います。
　開発の利便性とおっしゃいますが、利便性はただで得られるわけではありません。利便性のために犠牲になっているものがあります。オブジェクト指向言語の場合、速さとリソースです。

_________________
チキン
会議室デビュー日: 2005/03/15
投稿数: 11
投稿日時: 2005-04-01 01:21
Jittaさん
レスありがとうございます。
たしかにCのほうが良いように思います。実際アンマネージと言っているのは、C++のコンパイラーを使いますが、オブジェクトの継承などは、ほとんど避けて、また、Linked　Listなどの構造も避けて（配列に無理にしたうえで、配列を一回作ると何べんでも、上書きして使いオブジェクトの生成と破棄がほとんどないように）います。

実際、アロケートしたBYTE配列に勝手にKEYとか、Pointerとか、データ長、とかを定義して、その場その場で意味つけてやっているので、タイプチェックなどを、かわすことに専念していて、Cのほうがいいような感じは正直あります。

ただDebug用のデータ構造のTarceとか、ListとかはVBに渡すと、短時間でかなりのものが出来るので、ゲームの枠組みの制御にVBは捨てがたいです。その意味で、マネージC++で可能なら、整合性は良いのですが、、

NGenは現Vertionでは、期待値をさげさせられるようなMSの発言が多いので、期待値が低いのですが、実際に測定してみないと分かりません。

商品化の面では、非常にきびしいと思ってますが、特殊な分野なので、マシンの能力はある程度までは、要求できると思っています、また、できあがるのは2年以上かかりそうで、そのころのハードの進展にいくらか期待しています。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）