08/03/19 18:33:39
vectorでこんなんおきてるけど、
URLﾘﾝｸ(internet.watch.impress.co.jp)
964:仕様書無しさん
08/03/19 20:54:37
シェア作家ってうんこだな
965:仕様書無しさん
08/03/20 17:10:41
木を見て森を見ずってやつか
966:851
08/03/21 17:32:15
売り上げ80万円超えたお～
967:仕様書無しさん
08/03/21 20:55:24
シェアウェアを作ってお小遣いを稼ごうと思っているのですがそれに関して質問があります。
1.どのようなソフトが求められているか
2.収入はどれぐらいか
よろしくお願い致します。
968:仕様書無しさん
08/03/21 20:56:48
連続投稿申し訳ありません。
>>967に
3.シェアウェアの値段はどれぐらいか
を追加します。
よろしくお願い致します。
969:仕様書無しさん
08/03/21 21:04:52
>>967
そんなの人（しかもマ）に聞いてる時点で無理だと思うがｗ
970:仕様書無しさん
08/03/21 21:07:45
∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
971:仕様書無しさん
08/03/21 21:56:53
マルチコアCPUマシンを高速化するツールってよくね？
WinAPIで並列処理化すると高速化しそうなものをフックして色々速くなるとか。
作りたくてたまらないけど、他のもの作っている余裕がないぜ。
存在していたらorz だけど、注目は浴びると思う。
972:仕様書無しさん
08/03/21 22:25:36
>>971
なるほど面白そうだ。
でも超速系のとかありそうだし
そもそもMSが自前で対応しそうだ
973:仕様書無しさん
08/03/21 22:26:39
マルチコアを生かしきるほど高速化できるAPIってそうそうあるか？
マルチスレッド化してなくてレスポンスもっさりとか、描画系だけど過剰更新なのを遅延するとかは可能かもしれんが、
大抵のAPIだと基本的に呼んだ時点で処理完了を前提に構成されちゃうからなぁ…。
普通に出来そうな範囲だと
勝手にダブルバッファ化して、ロックしていても再描画することで「固まっている」感覚を軽減する
→描画だけ抜き出すのがメドー。アプリじゃなくてWindows側に干渉する必要がありそう。ってかそれぐらいならレイヤードウィンドウにするだけで済む
描画を自前でキャッシュするなどで制御して過剰描画を抑制して高速化を図る
→描画がネックなら効果的だが、それ以外の効果が薄い。
投げっぱなしAPIを別スレッドに自動分離
→レジストリ書き出し・ファイルIO(CopyFileとかその辺限定)辺りだけで、それがネックの物にしか効果が無いが、それがネックになることはあんまり…
メッセージをコマンド発行系と描画その他システム系で分離してそれぞれ別スレッドに分ける
→API描画系とコマンド発行系で同じスレッド前提だとアウアウ
投げっぱなしAPIは大抵が最初から投げてるからなー…。
APIじゃなく通常のロジック部分こそマルチコア向けに変更すべき箇所だが、これを自動認識するのは骨だ。…上手くいけば効果的だろうが…
974:仕様書無しさん
08/03/21 22:32:10
>>973
描画系はビデオカードがマルチスレッド対応してないのが多いから意味なさげ。
てかデバイスからむ系は全部デバイス次第だよな。
でも自信有りそうだからなんかいいアイデアあるのかも知れんよ？
975:973
08/03/21 22:45:40
>>974
描画系のキャッシュってのは途中経過表示で100000オーダのエディットボックスを1増加毎にSetTextするような奴や、
そういう方法で描画してるGDIのことのつもりで書いた。
DirectXやOpenGLが絡む高負荷処理はルーチンワークでは手の付けようが無いと思う。
>>971の具体的な案が気になるな…。
976:974
08/03/21 23:59:20
議論に付き合っちゃうけど
描画系は結果的にビデオメモリとシステムメモリのやりとりになるっしょ。
それがマルチになってないビデオカードが多いってこと。
もちろんおまいがあげたのも最終的にそれ依存だよ。
大体ビデオメモリとシステムメモリのやりとりが
複数本無いとマルチコアなんて（ビデオ系限定じゃ）意味ねーんだから。
ビデオカード複数挿しなんて一般的じゃないし
やったとしてもマルチスレッド的になるのかも分からん。やったことねーし。
それ全部考慮して「意味なさげ」。な。
977:973
08/03/22 01:01:27
>>976
そこは理解してる。
そうじゃなくて人間が見えないくらいの速度で画面更新するソフトに対して、描画を何割か端折るって事なんだが…。
「キャッシュするなどで」「過剰描画を抑制」するわけだから。
それ以前に、単純に描画API呼び出しだけ別スレッドに流し込むって手法だけでも、描画結果待ちのブロッキングは解消されると思うけど。
モデルとしては「描画スレッド」「内部処理スレッド」に分割するイメージで。
書き忘れたが>>973ではAPIフックする高速化全般について考えてたからマルチコア関係ないチューニングも混ざってる。
混乱させてすまん。
以下話の行き違いがあったどうでも良い話題。
BitBltとかは上手くアクセラレーションが効けばビデオメモリ→ビデオメモリにはなるらしいから、システムメモリと競合はしないケースも有る。
メインメモリがコアごとに独立して無い以上、メモリ他IOが多い処理同士は並列化しても衝突する…が、逆に言えば「CPUキャッシュに収まる処理」とそれ以外(「ビデオメモリ⇔システムメモリな処理」とか)の組み合わせであれば問題無い。
筈。
978:仕様書無しさん
08/03/22 09:36:49
Su
979:仕様書無しさん
08/03/22 09:58:35
>>977
＞モデルとしては「描画スレッド」「内部処理スレッド」に分割するイメージで。
このモデルの概念なら「メインスレッド」と「作業スレッド」と言うことで
マルチスレッド機能が搭載されたwin95の時に既に確立していた。
最近はSMP以前に書かれたコードがマルチコアが当り前になってタイミング的な
バグが顕在化してるようだけど。
ともあれ>>971の具体的な案を聞きたいと言うのには共感。
980:仕様書無しさん
08/03/22 13:54:39
そこをバラしてしまったら何食わぬ顔でパクるやつがいるからなあ。
実際マルチコアで様々高速化のプログラミングしていれば、
どういった事が高速化可能かがわかるよ。
ちなみに、DirectXやOpenGLなどはマルチスレッドレンダリングという方法で
コマンドを効率よく送り込むことでパフォーマンスを上げることができる。
色々なゲームで既に行われている。
981:仕様書無しさん
08/03/22 14:44:47
↑ケチだな、もうチキッと詳しく。
アイディアくらいは良いだろう♪
とりあえず次スレも立てた。
ｽﾚﾘﾝｸ(prog板)
982:仕様書無しさん
08/03/23 12:00:18
>>979 >win95の時に既に確立していた。
確立してる割には実践して無い例も多いのが嫌なところだ。
自動でマルチコア向けに最適化しなおすってのは相当面白そうだが…
>>980
楽にパクれる簡単な方法ならばらそうがばらすまいが結局パクられるかと。
この手の最適化はやたらと面倒な手順でやらないと出来ないと思うが(100%解析しきる事は無理なんで)、
そうするとよりベターな結果を出せるエンジンを目指して同種のソフトで削りあいになるだろうさ。
983:仕様書無しさん
08/03/23 13:06:28
同種のソフトに対してイヤガラセしてんだろ？ おまえらｷﾓｯ