【マルチコア】並列化について語る【使いこなせ】

これってどう？
http://www.rbbtoday.com/news/20051219/27869.html

機械語レベルで、並列化すんだろな
能書きは本当か知らんけど発想はありだな

>>370
ttp://www.nec.co.jp/press/ja/0512/1902.html
これのことか？

何を並列化するかによるわな。
マンデルブロ集合の計算とか、完全に並列化できるものなら、そらN台でN倍に
なるだろうけど、そんな簡単な用途は極めてまれなわけで。
宣伝の一人歩きだろう。

＞極めてまれ
そうでもない。
処理はシンプルでも大量に捌かないといけない場合はままある。
#尤も、そういうケースは並列化の自動化も難しいが。

んなこたあねえべさ。
むしろ順次処理じゃないといけない場面の方が少ないんじゃねぇかな？

画像処理とオンライン系のトランザクションは並列化に向いてる処理が多いって
よくいわれるよね。××ルータ、××フィルタ、××サーバと名前に付くアプリは
並列化してナンボな物が多い。

デスクトップアプリは 4 コアもあれば十分だと思うけど。

大規模マルチコアプロセッサの発売に向け準備を進めるインテル
http://japan.cnet.com/news/ent/story/0,2000056022,20350948,00.htm

IntelのTera-Scale Computing Research Program担当共同ディレクタ
ーJerry Bautista氏によると、現在、Intelの研究者らは、コンピュータ
メーカーやソフトウェア開発者らが、大量のコアを搭載するマルチコア
チップにより簡単に適応できるようにするため、それらのチップの複雑
な機能性を意識させないための手段を模索しているという。

異種マルチコアチップ内のすべてのコアを外骨格のようなもので覆い、
それらすべてのコアを複数の従来型x86コア、あるいは1個の大きなコア
に見立てる。Bautista氏は、「それは、いわば1つのリソース貯蔵庫のよ
うになり、ランタイムがその中から適当と思うものを使用する」と述べ、
「これはプログラミングを簡略化するためだ」と付け加えた。

1個のチップ内の多様なコア間で演算タスクを分配するハードウェアスケ
ジューラを使用することにより、特定の演算タスクをより短時間で完了
できるとBautista氏は指摘する。

プログラマーたちは、キャッシュ共有技術やハードウェアスケジューリング
技術を理解したり、これに対応するためにたくさんの労力をつぎ込む必要
はない。これらのオペレーションは大抵、チップ自体によって処理される
ため表面化しないのである。

>>377
素晴らしい！！
テクノロジーの進化ってとんでもねぇなｗ

Windows出たばかりの頃の宣伝の様だが

まあイソテルの「プログラミングの簡略化」の範囲はアプリ屋の話で、

　コンパイラ屋ガンガレ、死ぬまでガンガレ by Intel

って漏れの耳には聞こえてるが気のせい？

>>380
そういうのは NetBurst や Itanic で懲りていると思いたい…

>380
俺にはIntel以外のコンパイラは淘汰されてしまえ
と聞こえるが

ARM、gcc、VC++でつかえなけりゃいみねぇー
世の中ICCが全てみたいな発想がすかん

INTELはいっつもAMDいじめて悦に浸ってる変態だし
しねってかんじだ

そらそうよ、Intelはパラノイアが社訓だもん

いよいよAMDの時代
http://northwood.blog60.fc2.com/blog-entry-928.html
http://northwood.blog60.fc2.com/blog-entry-932.html
http://northwood.blog60.fc2.com/blog-entry-935.html
http://blog.livedoor.jp/amd646464/archives/50980564.html

Intel社、ソフトウエアの並列化が研究開発部門の最重要課題に
http://www.eetimes.jp/contents/200705/19305_1_20070528174750.cfm
マルチコア・プロセッサに対する需要の高まりを受け、米Intel社はソフトウエア
の並列化を最重要課題に掲げている。その取り組みの一環として、特定用途
向けプログラミング言語や既存のプログラミング言語/アプリケーションの並列化
に関する研究に250名を投入している。「オレゴン州にある研究開発部門では、
全業務の実に約3/4をソフトウエア関連が占める」

インテルが開発ツールの新版を発売、ソフトウエアの並列化を支援
http://www.eetimes.jp/contents/200706/19707_1_20070605170230.cfm
コンパイラは、ベクトル化が可能な場合、SSE命令セットを利用したコードを
生成する。また、C++のテンプレート・ライブラリとして実装されているTBBを
利用すると、ソフトウエア開発者が明示的にコードを記述しなくても、マルチ
スレッド化できる。OpenMPライブラリを利用しており、実行時に利用可能な
コア数分だけスレッドを生成する。

AMDは甘ちゃん
IBMとIntelはプロフェッショナル

次世代スパコンはスカラーとベクトルの複合型に，日立/NEC/富士通の「3社連合」で開発へ
http://techon.nikkeibp.co.jp/article/NEWS/20070613/134173/

アーキテクチャの概要は，スカラー型プロセサからなる演算システムにアクセ
ラレータを付加し，さらにベクトル型プロセサからなる演算システムを組み合わ
せる，というもの。スカラー部とベクトル部は，共有ファイル・システムを介して
データをやり取りする。これによって様々な大規模計算シミュレーションが計算
のタイプに合わせた演算環境を選べるようになる。

ハードウエアだけでなく，ソフトウエアも同時に開発する。「制御フロントエンド」
のジョブ管理を通して，ユーザーはこれら二つのシステムの違いを意識せずに
最適な演算環境を選べるようにするという。

>>384
コンピュータ様って事ですね？市民。

もうすぐメニーコアがでてくるらしい。
システム設計とかどうすりゃいいんだか・・・

http://pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm

いつも通り、頭のいい人が仕組みを考えて、俺らがそれに乗っかって儲ける
で良いんじゃないかな。頭のいい人の代わりを務めようとすると大変だけど。

シーケンス図廃止からやってみようかな？
で、その代わりに何を使えばいい？？

並列システム用のモデリングviewをUMLに策定してくれんかな。

あのさー

マルチコアに限らずソフトの最適化なんて、現場レベルでボトルネック分析し
どこを重点的に並列化するか設計フェイズにフィードバックしながらやっていくもんで
日本伝統のウォーターフォールモデルじゃ、いくらお絵かきツールが便利になっても
全然役に立たんよ。

むしろUMLの本質は抽象化なんでそもそもマルチコアを意識する必要ねぇ。
逆に具体化しちゃうと、コア数の増減やパフォーマンスの見積もり違いで破綻する希ガス。

マルチスレッドは一般的にはObserverパターン、と本で得た知識をそのまま晒してみる。
ttp://www.hyuki.com/dp/cat_Observer.html

それにしても結城先生お茶目だな。

さてと、、、

Cellスレでボコボコにされて
泣く泣くこちらのスレに逃げてきた団子が
ご迷惑をおかけしております。

ゲハ厨自演乙

>>396
バカかお前ｗｗｗ
何も知らないんだなｗｗｗｗｗ
ム板で厨認定された糞団子が帰る場所は














学歴とゲハだよｗｗｗｗｗｗｗｗ

該当するスレが見付からず、
かといってどこにかけばいいかわからないのでここで質問をします
(どこか適当なスレがあれば誘導していただければ幸いです)

今、FreeBSD 6.2のPCからPVMを起動して
Fedora 7(192.168.1.3)とVine Linux 4.2(192.168.1.4)のPCをクラスタに登録したいのですが
登録の成功をつげているのにもかかわらず
マシンには登録されていないような状況になっています

/tmp/pvml.????(????：グループID)を確認したら以下のようなメッセージが
でてきます
------------------------------
[t80040000] 06/21 15:11:35 host1 (192.168.1.2:60822) FREEBSD 3.4.5
[t80040000] 06/21 15:11:35 ready Thu Jun 21 15:11:35 2007
[t80040000] 06/21 15:14:50 netoutput() timed out sending to ryle after 14, 190.000000
[t80040000] 06/21 15:14:50  hd_dump() ref 1 t 0x80000 n "ryle" a "" ar "LINUX" dsig 0x408841
[t80040000] 06/21 15:14:50            lo "" so "" dx "" ep "" bx "" wd "" sp 1000
[t80040000] 06/21 15:14:50            sa 192.168.0.3:32790 mtu 4080 f 0x0 e 0 txq 1
[t80040000] 06/21 15:14:50            tx 2 rx 1 rtt 1.000000 id ""
[t80040000] 06/21 15:16:40 netinput() bogus pkt from 192.168.1.3:32790
------------------------------
PVMの方で勝手にタイムアウトをしているのですが
このような場合はどのようにすれば回避できるのでしょうか？

簡単なファイルコンバート処理(ファイル読み込み→変換→ファイル出力)を並列化したいんだけど、定番のパターンとか定石ってある？
自分で調べた感じだとProducer-Consumerパターンが使えそうなんだけど・・・。

UNIXのパイプ

フィックスターズが出している
http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1462-1
は、役に立つのだろうか？
立ち読みした限りでは内容がちと薄い気がするのだが。

>>402
それ持ってるけど、動くプログラムが書かれているだけで幸せ。
とりあえずコードを何回も書いて覚えている途中。

変な癖が付きそーだったら「違うよ」って教えてくれるとウレシイ。

そんなレベルの奴が並列化なんかに手を出すのが間違い

並列かなんてたいして技術いる事じゃないだろ

そういうやつが平気でぼけぼけかますのが並列化

科学計算レベルでの並列化と業務ソフトの並列化は同じレベルでは
語れないと思うんだが。そんな意味で入門には>>402はちょうどいい。
javaERの俺にはﾀﾞｸﾞﾘｰ先生の本のほうが面白かったけど。

>>406
一緒にするなよ

Amazonでの評価は微妙だね。
http://www.amazon.co.jp/dp/4798014621

俺は釣られないぞ

なんでOpenMPばっか期待されてんの？
どこにもOpenMPなんて書いてないように見えるが（本のタイトルとかに）

デザインパターンの本。
↓
Javaについてはほとんどのってないので期待はずれ。
↓
デザインパターンの本、評価は微妙。

だれもJavaって言ってないじゃん…

たしかに目次にも一言もOpenMPの文字はないね。。。
よく分からん書評だ。
俺は↓の本で勉強したけど分かりやすかった。くどいくらいだけど。

Win32マルチスレッドプログラミング
http://www.amazon.co.jp/dp/4756114040/

http://www.ebjapan.com/content/l_news/2007/07/l_news070702_0101.html
これってハードレベルで並列を実現したってこと？

>>414
説明読んでいたら、家政婦が私語を始めたり、殺人事件を目撃したりしてしまう展開が脳内を過ぎった。

業務レベルでの並列と、コードレベルでの並列って差があると思うのだが
対処方法ってどうなってるでしょうね？

>>415
FPGAのparallel random access machine/model
じゃねーのそれって？

しかし今回はそれを1個だけしか作れていないはず。
64個最大実装時（現在開発中）が現行CPUの100倍程度って事だな

まぁ、IntelとかにX86を32個とか載せた板作ってもらった方が
書きやすいと思われる。価格も現実的だし。

http://seisei.s8.xrea.com/thread/
これはどうなんだろうね？

>>418
うさんくさすぎねーかw

これが全部実現できるならIPAとかに公募して金もらうはず。

なんか穴があるはずだ。実用上の

>>418
すげぇ、胡散臭すぎて読む気にもならないよ。

読んでみたが、xorの計算をマルチスレッドで演算するソフトなわけね。
速度が速くなるとは書いてないようだな。

で？

XORをまるちすれっど？

で？

オーバーヘッドが少ないとか、実行時効率が良くなるとかじゃないみたいね。
分かりやすい管理方式の提案？

で？　
　
　

順序立てて処理する必要が無い部分はマルチスレッドで並列処理すれば蝶早く計算できる！
俺天才！！！

って事？ｗ
URL削るともっと胡散臭いｗ

えーと自家製単純インタプリタ(command)が
並列にできるところを並列化、

という感じ？

じゃなくてこれは単なる dish の簡単な使用例か。
ttp://www2.chem.nagoya-u.ac.jp/matto/90/70Proj/dish/index.phtml

>>424
やばい、ドキュメントDLで金とるよ的なページもある。

419です。
スマン、どうやらスレ汚しをしてしまったようだ。
削除依頼してくるわ。

ごめん、↑は418の間違いね

そりゃ潔癖すぎる
気楽にやろうぜ

クロック数が違うCPUでマルチコア作ってほしい。
200MGHくらいのCPUが30個くらいついていて、2G強のCPUが一個くらいのやつ。
タスクで重いやつを2Gのやつに振るとかの処理はOSなりPG任せにする仕組みで。


無理か？

200MGHってのがどんなCPUか知りませんが、やってできないことではありません。
まぁ殆ど、意味はないと思いますが。

メガドラか

200メガギガヘンリー

200万ギザエッチ

200マゾガチハーレム

ダンゴさんのレスが望まれるところだ

悪趣味だな。

だーんごー
だーんごー

たーっぷりー

だーんごー

>>438
おいこら、「つぶつぶだんご」ってフレーズが頭ん中でリピートしちまったじゃないか。

>438
それ、たらこだろ？

キャッシュヒット率を多少改善するくらいしかやれることなんてないだろ

イチローの出番だわな

>>430
ヘテロなマルチコアならcellがあるじゃまいか

そうじゃなくてね、クロック数の低いコアを十数個のせて低コストのプロセス
なりスレッドを割り当てして、OSなどの重い処理専用のコアというふうにわけ
れば効率よくマルチプロセス・スレッドができると思ったのよ。

>200MGH
200MHと間違えたよorz

＞クロック数の低いコアを十数個のせて低コストのプロセスなりスレッドを割り当てして

重い処理をするコアが数パーセントの稼働率でその処理やればいいんじゃない？
あまった時間はクロックダウンして各種電源OFFしてればいいし。

ってのはともかくとして、キーボードやスイッチ、外部デバイスの監視みたいな
低速簡単タスクはPICとか使ってやってるシステムもあるよね。

どうやって低コストかどうかを判断するんだ。
アプリ自体にプロセス毎の振り分けフラッグでも付いてないと適切に割り当てられんし、
低コストならメインCPUでやっちゃってもすぐ終わるから問題ないとも言える。
その考え方ならCPUコア分割よりIOコストをうまく割り振ってどれだけCPUをビジーに保てるかを
考えたほうが建設的だと思う。

分散すれば仕事が早くなるってアホな幻想いだいてるから
間違った方向にいくんだよなぁ。

人も機械もどれだけパンクギリギリまで仕事詰め込めるかが命なのに

>分散すれば仕事が早くなるってアホな幻想

お前がアホなんだろｗ

無理なものは無理

つまり馬鹿に仕事を割り振る方法を考える時間があったら
自分でやった方が速いってことだな。

工場の単純労働者は1000人必要かもしれない
だからといって社長（＋役員）は20人もいらない

でもXeon20個搭載可能なマシンあったら
夢がひろがりんぐだろw

>>452
それなんていう暖房機具？

1UラックマウントのXeon*2搭載可能なサーバがあるから、10Uラックでいけるな。
暖房器具っつーか、騒音源だな。

今なら１U3台で済むよ

QuadXeon 6個＋ﾏﾏﾝ3枚でｵｹ

Xeon20個っていってるのに6個って、何考えているんだ?
まさか、Xeon20個ってコア数だとおもっているのか?
おめでたいな。

頭が4つもついてる役員は怖いです。

バスが飽和しそうです。

>>454-456
お前らブレードサーバも知らんのか？

6U で Xeon 20個 コア 80個ぐらいは積めるだろ。

http://japan.cnet.com/news/ent/story/0,2000056022,20353310,00.htm

GPL？

記事読んだ感じだと、例外付き GPL なんじゃないの

LGPLだなたしか。

でも実際これら使っても効果出る範囲狭いみたいだぞ。

タスク境界を自動で検出するTOOLないかね？

foobarなどで複数のエンコーダを使って処理速度を上げてるってやつがあるけど
よっぽどうまく設計しないとハードディスクへのアクセスがボトルネックとなるじゃね。

http://www.itmedia.co.jp/news/articles/0708/21/news021.html

>>465
どういう計算だよｗ

http://pc.watch.impress.co.jp/docs/2007/0821/tilera.htm

http://www.atmarkit.co.jp/news/200708/21/tile.html

http://pc.watch.impress.co.jp/docs/2007/0821/tilera.htm

Wikiﾍﾟﾃﾞｨｱより
>また、Windows Vista Home Basicおよび同Home Premiumではマルチプロセッサには対応しておらず

マジか

>>471
そこでいうマルチプロセッサは、マルチソケットのことでマルチコアでは
ないことは理解してる？

一応理解している。
シングルコアをくっつけて作るデュアル環境と、ダイに複数コアをのっける
ものの違いだと認識している。


多分

XP HOMEもそうだったでしょ。
物理CPUに対応してるのは１個まで。
物理CPU１個ならコアが４個あっても大丈夫（のはず）

物理CPU２個はXP PROFESSIONALから。４個以上は知らない。

それは違うぞ。

じゃあどうなの

いや、自分でもよくわからないんだけどさ

>>473
ちがうよ。
マルチプロセッサってのは文字通り
マザボに CPU を複数のっけることだよ。
ハードディスクを 2 個繋げたり
メモリを 4 枚さすのと同じ。

http://www.atmarkit.co.jp/fwin2k/special/whatiswin2k_rev1/server4.html
　　　　　　　Windows 2000 Server Advanced Server
最大SMP CPU数 　　　4CPU　　　　　　　　 8CPU

http://win64xp.impress.co.jp/change/index.htm
　　　　　 Windows XP Professional Windows XP Professional x64 Edition
対応CPU数 　　　　　2　　　　　　　　　　　　　　　　　　 2

http://q.hatena.ne.jp/1185032304
1.WindowsXP HomeEdition … 1 ソケット
2.WindowsXP ProfessionalEdition … 2 ソケット
3.WindowsVista HomePremiumEdition … 1 ソケット
4.WindowsVista BusinessEdition … 2 ソケット
5.WindowsVista UltimateEdition … 2 ソケット
6.WindowsServer2003 StandardEdition … 4 ソケット

コア数は４個だろうが８個だろうが全て認識するようです

コアが32個あるタスクメジャー見たなｗｗｗｗｗｗｗｗ

並列化・並列計算のスレってこの板には多分ここくらいしかないので、
ここで質問します。

太陽系の惑星の軌道を並列計算をするときに、
時刻tでの惑星の速度と位置のデータを
他のプロセスに渡して次の時刻(t+1)の速度と位置を計算させて、
全ての惑星の分を計算し終わったら次の時刻の計算を・・・
と繰り返す処理をPVM ＋ C言語で組んでいるのですが、
どうもデータの送受信部分のコーディングがうまくいきません。

繰り返し1回目はちゃんと結果が帰ってくるんけど、
2回目は送信はできるけど計算結果が帰ってこない、
というような状況になっております。

並列計算で繰り返し処理を行う場合は
データの送受信の処理はどのようにコーディングすればいいのでしょうか。
(作りかけのプログラムをどっかにうpしたほうがいいんですかね・・・？)

>>481
MPIのスレがあるぞ

>>482
そうなんですがMPI以外の話になっちゃうので
抵抗がありまして・・・

地球時間とか木星時間の一年周期で同期したらいいんじゃね

cygwin+gccだとどのような方法がありますか？

ない

lam-mpiならcygwinにインスコできた。
mpichもたぶんできる。

IntelのCt言語っててにはいるのかな？

「小飼弾のアルファギークに逢ってきた」っていう本に
Dave ThomasがErlangの本を書いているって書いてあったんだけど
詳細が分かる人いますか？

07年7月に出版予定とか書いてあったけど、どうもAmazonの洋書でそれらしいものがない。

すみません。
誤爆しました。

128bit レジスタ を 8 コアで SSE 拡張として繋げて、
1024bit のベクトルプロセッサとして使える。

、、、とかだったら面白くなりそうなんだけどな

>>491
どれかのプロセスがそれをやっている間他のプロセスが割りを食いそうだからやだ。

>>491
逆に並列性が下がりそう

素朴な疑問だけど、これからはメニーコアの時代、とかいうが、
コア間で「人月の神話」と同じ問題は発生しないのかえ

する。

つーか、大昔からのマルチプロセッシングの課題が
いかにリニアにスケールさせるか、です。

それじゃ漠然としすぎて無意味だよ

大昔からリニアにスケールさせるにはどうしたらいいかって話で
結局は個別対応になるから、一般論として本当に軽い話しかできない

古い記事だけどマルチコア、マルチスレッドで
どこらへんに苦労したかっていうのは書いてあるけどほとんど一般論
http://www.4gamer.net/specials/capcom_x_intel/capcom_x_intel_01.shtml

ＥｆｆｉｃｉｅｎｔC++も肝心の部分は結局言及できずにたいしたことは書いてなかった。
だから、個別の事例をまとめるしかないと思うが、そういう記述をできる人は
その筋で仕事してたりする人ぐらいだから記事としては出てこないだろうし
結局は本人の試行錯誤という。

>>497
知りたいことの的を絞ってくれればある程度話ができるよ。

mac osx ppc64 で tbb を使って遊んでみようと思ってます（当然シングルコアなので雰囲気だけ）

ところが、libtbb.dylibとlibtbbmalloc.dylib を入れてもリンクエラーが発生します。
自分でソースからビルドしてdylibを作り直してもダメ。
dylibの中をみてもそれらしいシンボル名がないようなんですが、どうすれば動くんでしょうか。

おおむね一年研究してみたが、マルチコア化でいちばん厄介なのは

1.どれだけスレッドセーフなコードを簡単に作れるか
2.どれだけスレッドセーフを意識しなくてもよくできるか

の二点にかかっている、これに伴って

スレッド化が問題を引き起こすのは、作る側、使う側の間で、仕様伝達がもつれてしまったり、
一旦スレッド化すると、非スレッドセーフに戻したり、逆に非スレッドセーフに作ったコードを簡単にスレッド化できない事で
オブジェクト指向で言えば、オブジェクト間の結合がスレッドによってむやみに強められてしまう点がまずい。
スレッドセーフは、メソッドにつけられる属性の一つとして機能するが、言語機構てきに簡単には取り付けられない。
なにしろ、何につていスレッドセーフかという問題もあって厄介だ。
逆のこの点を解消すれば、むしろ色々な物(IO同期処理等)が統合できて便利だと思った。
『やりたいことの記述と、どう実装するかの記述を分離する事』が最も重要だ。

>結局は個別対応になるから、一般論として本当に軽い話
初めて見た時は不可能そうに見えたが、一般論化しないかぎり成功しない、そしてそれは不可能でもないと思った。
逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。
一言でいえば、いかにサクッと書けるか書き換えられるか、同期が必要なデータが明白化できるかが、そのまま並列化の性能になってしまう。
並列化はパフォーマンスを求めるために使う技術だが、パフォーマンスを求ている内は使い物になりそうにない。
VBが、GUIのコードをあっさり書けるようして、実用的にしたように、マルチコア化も同様なものが必要でスケールとかは意識しても仕方がないと思った。
概念として重要そうなのは、C#やVBのLINQやHaskell等で実装されている遅延評価が使えそうだという点か。

CPU・・・衝突、不一致を嫌う設計
脳・・・衝突、不一致を積極的に利用

CPUの設計原理を変えずに、脳の真似をするのは難しい。

>>501
> 逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。

業務用ゲーム業界に職人技的に伝えられてきたというあの「タスクシステム」？

タスクシステムなんてこのＷＥＢ全盛時代にはもはや化石だなｗ

並列化のキーワードは網羅って聞いたことがあるような。
例えばソートだと、順列(全パターン)を作ってそれが並んでいるか調べるだけでいい。

現在の手法は今までのアルゴリズムを並列化しようとしているからロックとかで問題になっているんでしょ？
アルゴリズムを根本から変えれば良いと思うけど。

>>503
カプコンのMTフレームワークは使うかどうかはともかく、見ておく価値はあるよ。
http://watch.impress.co.jp/game%2Fdocs/20070131/3dlp.htm
十分とは思えないが、役に立たない理屈と違い実戦的な並列化手法の一つだから。

>>505
量子コンピュータ時代になれば、役に立つかもなw

>>507
ある程度コア数が大きくなったら役立ちそうだと思うけど
別に1パターン1コアに分けなくてもいいし。

>>508
> ある程度コア数が大きくなったら役立ちそうだと思うけど

算数からやり直した方がいいと思う。

>>508
たとえば1000の組み合わせの数を数えてみたらどうかな？
n qubitに対して、並列度が 2^n である量子コンピュータなら
2^1000程度の並列度を持たせれば、その組み合わせ数にも打ち勝てる可能性はあるが、
10個や20個のコアでなんとかなるかな？

あーかなり勘違いしてたよ。
でも、そこに道があるような気がする。
アルゴリズムが分かりやすいし。

>>511
極めて単純なものだけに有効でしかないよ
総列挙を行うと、ひとつ条件分岐が増えるごとに二倍になる。倍々ゲームだからな。
宇宙の全素粒子をトランジスタにしたって追いつかないほどの並列度がすぐに必要になる。
そして、総列挙以外の方法で解けない問題はNP問題といって、楽しい研究対象だ。
量子コンピュータは、時間的な並行宇宙が倍々ゲームで増えていくことを利用して、
自分たちが感知できない別の宇宙にコンピュータを配置する、
今配置すれば、処理を何工程か経ることによって未来の並行宇宙に倍々ゲームでマシンを配置できる。
これに一斉処理をさせれば、宇宙の全素粒子の冪乗に当たるような並列度が取れるので、解けることもある。
ただし、結果を得る方法がきわめて特殊なので、結局解けないケースが多い。
それにしても一番気になるのは計算機よりも並行宇宙そのものだ。

量子コンピュータを神秘視しすぎだろwww

>>513
逆に問うてみようか、並行宇宙でないとすると、ありゃ何処で計算されてるいんだ？
どうころんでも、どう解釈してもキモ過ぎだよ

量子の状態は重ね合わせで表されるような状態である。
それは量子というものの性質そのものであって、解釈なぞどうでもよい。

キモいと言えばキモい性質ではある。

並行宇宙ﾜﾛﾀ

並行宇宙ヤバイ

>>512マジキモイ

2XXX年のオリコン一位

「並列宇宙」

>>517-519 話についていけないなら泣いていい(笑)
はたしてテンソル積はどこまでも増やしてゆけるのか
量子コンピュータをみていると、現在の物理法則はどこまで正しいかどうか見ものだよ。

Erlangスレに進展があったよ。
どっかのいい人がホームページ作ってくれたみたい。

宗教の話は他でやってくれないか。

ミクロとマクロの視点を
ごっちゃにしているアホが騒いでいるだけ

>>520
量子コンピュータが量子力学の正しさを証明しても
並行宇宙解釈が主流になる事は無いと思われ

ここム板やで。

>>1
boinc環境を用意してねらーを煽る。

懐かしの宇宙ヤバイを思い出した。

ちょっと、細かい質問なんだが、
tbbの本３８ページに書いてある、粒度ってどういう意味なんでしょうか。
本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。

たとえば、2コアのＣＰＵで１０００回のループのを並列処理するときに、grainsizeを５００にする、
４コアならgrainsizeを２５０にすることで、理想的にスケールするということなんでしょうか。

この本肝心なとこの訳が意味不明で困る。
ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか（TBBのもいい参考書だとおもいますけど。）。

>>528
その本持ってないから意味不明で困る。

処理を細かい粒に分けて並列処理をする。粒度は粒の大きさだ。粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ。

>この本肝心なとこの訳が意味不明で困る
文句言ってる暇があるなら原著嫁

>>529
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな、ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。

>>530
ツマンネー事いってないで必要な情報は全部書けよ、この自己完結野郎

>>531 の文書が変だとおもったのでちょっと修正
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。

調整といっても、問い合わせたプロセッサ数で分割とか、100mS分くらいに分割するとか程度だろ。その程度のことで開発は時間との戦いとか理想論とかってｗ

>>533
ややこしいデッドロック問題とか、複数のマルチスレッドライブラリが組み合わさった状態とかまったく想定していないショボイ開発だけ見ているだろw
例えば、ライブラリが二つあるだけでも最優先で実行すべきコードが変化するんだぜ、囚人のジレンマって言ってな、個々ライブラリが最優先に実行してほしい物を最優先にすると、最低な結果になる事も結構あるんだぜ。

>>534
「複数のマルチスレッドライブラリが組み合わさった状態」
になったら「ショボイ開発」って思わなきゃダメだよ

10000行で完成する程度のコードしか組んだことないんだなw

並列・分散処理に関しては以下のホームページが参考になります。
主要な言語に対応したツールなどの紹介もあります。

www.cspjapan.org

>>537
宣伝でつか？
マルチポストでやるのは、あまりイメージ良くないですよ。

>>537
ちらっと見ただけだけど、通信部分が浮いている感じがするな、もっと洗練できると思う。

グリッドコンピューティング？には合ってる部分もあるのかもだけど
昨今のマルチコア活用方向とは全く合わんのじゃ…
大体想定環境・状況が古すぎるような…

プロセス代数は基本だと思うし、オブジェクト間通信という考えの元でも問題はないと思う。
マルチコア活用を阻害している最大の要因はパフォーマンスではなくて
直感的に記述することや効率よく記述すること、デバッグを容易にすることが重要だという点に気付いているかが気になった。

もうひとつあるな、現行残っているシングルスレッドモデルで記述された大量のコードを徐々に移行していくための仕組みがいる。

>>534
想定しなくていいように作るもんだろ
それに囚人のジレンマは場違いもいいとこ

>>532
> コードがスマートになる粒度にハードウェアを調節しないと駄目だ。

プログラマからするとソフトウェアもコードがスマートになるように作ってほしいですよね。

>>543
俺も思ったけど、Wikiみたら使い方あってるみたい。

> 囚人のジレンマ
> 個々の最適な選択が全体として最適な選択とはならない状況の例としてよく挙げられる問題。

>>543
すべてのライブラリが自家製とかありえないだろ、ふつう

>想定しなくていいように作るもんだろ
想定しなくていいように作る＝毎回開発でスクラップアンドビルド
だが、良いのか？

>想定しなくていいように作る＝毎回開発でスクラップアンドビルド

うわっバカだ

マルチスレッド並列化で解決すべき深刻な問題の一つだからな、保守性の無さと再利用性の低さは。

>>537
今更CSP紹介されてもな…何十年前の話題だよ。
CSPを普通に実装するとプロセス間をデータが流れることになり、
キャッシュを越えるコア間のデータ転送が増えて、途方もなく
効率悪いと思うんだが。
その辺まで言及してくれればこのスレ的な話題になる。

>>548
＞ 保守性の無さと再利用性の低さは。

STM はその辺強いのかね

>>550
変な用語を使うのはヤメレ、シングルスレッドモデルといいたいのだろうが・・・
ちょっとでも触ればマルチスレッドを使った並列化の現状が論外な状態だと判るはず。
可能ならとっくに流行っている。

>>549
現在のプロセッサの最大の弱点はプロセッサ相対で低速なメモリーであって
キャッシュ間の転送は、小さくはないが致命的でもない。

>>551
アフォか。Software Transctional Memoryだろが

>>552
一般論としてはそうだが例えばfork/joinはスティールされない限り
同じスレッドで実行することでデータ転送を減らすよう考慮されてる
スティールされるのが古いタスクからなのも同じ理由
それに比べてCSPはどうだ？

>>554
>fork/joinはスティールされない限り同じスレッドで実行することでデータ転送を減らすよう考慮されてる
SMT(ハイパースレッディング)が登場してから、おかしな対処をしないと性能がでなくなって必ずしもそうなっていないよ、今は。

>>555
そうか？tbbやjsr166yのfor/joinは>554で書いたようになってると理解してるが。
ソースｷﾎﾞﾝ

しかしまぁ、オペレーションズ・リサーチは情報系出身なら常識だろうと思うが、こういった基本すら知らない奴はどうしてくれるかなぁ
ゲーム理論や囚人のジレンマも知らないというのはどうかと思うんだ・・・

>>556
Core 2 Quadマシンと、Windows Vista 買ってきて、ひとつアプリを走らせろ
そして、タスクマネージャーなり、ガジェットからCPUメーターをダウンロードして睨めっこをするんだ
そうすれば、ソースも必要ないし説明するまでもない筈。

>>558
まさかProcessor affinityの話をしてるのか？

>>559
謎用語出す前に、基本を勉強しとけ

>>560
謎用語て…単なる煽りか？それなら消えてくれ
煽りじゃないなら>558とjork/joinのタスクスケジューリングの関係を説明してほしい

ソースだせと、なぞ用語で捲し立てるのが趣味なら消えてくれ

>>557
常識だと思うけど、大学卒業して10年の俺はさっぱり覚えてないw

頭の悪いGKがいる、絶対いるw

>>562
Processor affinityはWindowsでもLinuxでも商用UNIXでもAPIになってる
特定のプロセス／スレッドを特定のCPUに割り当てられやすくするもの。

fork/joinのスケジュールがスレッドのローカルなキューからタスクを
取ってくるのも新しいタスクをキューの先頭に入れるのも
他のスレッドからキューの後ろからスティールするのも
Processor affinityの元でスレッドが同じコア上で実行される場合に
キャッシュが効率的に使われることを目指していると俺は理解している。

さて、>555や>558について説明してもらえないかな

>>565
CPUメーターみてみなよ、OSが勝手にスケジュールを調整してこちらの意向を無視している。

>>566
そのアプリがSetThreadAffinityMask読んでないなけだろ

>>567
単に、特定アプリに依存すると障害が多いからMSが調整しただけかと

>>568
意味が分からない
SetThreadAffinityMaskを呼び出していないスレッドをOSが勝手に
スケジュールするのは当然のことだ
お前さんの言ってるアプリはSetThreadAffinityMaskを呼び出してるのか？
呼び出してないアプリでCPUメーター見ても全く意味がないんだが
Processor affinityを知らなかっただけじゃね？

そっちの言っている事こそ意味不明だわw

じゃあさ、>558で「ひとつアプリを走らせろ」のアプリが
SetThreadAffinityMaskを呼び出してるアプリのことかどうかだけ答えてくれ
yes/noだけでいいからさ

こんなの、つまらないコード書いて、パフォーマンス確認目的でパフォーマンスカウンタ見れば一発なんだが・・・
なんでこんなややこしい話が登場するのかと・・・

バカ相手にするのは疲れる

>>572
ややこしい話はしていない
そのつまらないコードでSetThreadAffinityMaskを呼んだのかどうか、それだけだ。
これもyes/noだけでいいから答えてくれ

SetThreadAffinityMaskじゃなくSetProcessAffinityMaskなら
タスクマネージャーから設定できる。
プロセスタブでプロセスを選んで右クリック、関係の設定でCPUを選ぶだけ

逃げたようだな。結局Processor affinityすら知らなかっただけだけか
何が「基本を勉強しとけ」だよｗ
きっとfork/joinも何のことかわかってないんだろうな…

割り込んでごめんなさい。
windows 2k serverってマルチコアに対応してますか？

windows serverは全部対応してるって記事をネットで見たけど、
記事自体、いまいち信用できないんです。

雑誌記事が信用できずに、誰の発言かもわからない
掲示板の話を信用するんですか？

>>578
どっちもどっちですが、広告だらけのブログで「対応してる。」って言われるのと比べるなら、
まだ、ここのほうが信用できます。

「ここで公式に書いてるよ！」みたいなレスがあればなぁなどと思った次第です。

それプログラミングと関係ないだろスレ違いだしageんな

>>578
P4-2.4Cで2個見えてるから、2個までは対応してると思うよ
＃手元に2コアまでしかないからそれ以上は分からんｗ

初心者ですまんが
Ｐｇ作るのにマルチコアなんて気にする必要アンの？
いいところスレッド処理とか流せば
しかたねえな　ってかってに動いてくれそうだけど

そのいいところってのが難しいんじゃない？
いままでみたいな粗い粒度のスレッドの使い方じゃなくて、もっと積極的に
例えば単なるクイックソートを2〜4スレッドで並列実行して高速化しようとか、
そういうのを考えるんじゃないかなたぶん

>>582
ここは君が来るところではないんだよ。
ここはデュアルコアならシングルコアの2倍、クアッドコアなら4倍の
パフォーマンスを目指すスレ。

今のところ有益な議論は一度もないけどな。

Processor affinityも知らないSoftware Transactional Memoryも知らない
wait freeやlock freeの話も出ない
有益な議論のしようがないなｗ

>>584
キャッシュに入るような小さな処理から頻繁にメモリアクセスが必要な処理をした際
実際のパフォーマンスを比較したものってどっかにないの？

マルチスレッドスレと話題かぶるからなぁ

>>582
俺も気になった。
winのapiには無いと思う。

２つのスレッドを２つのコアにわけるなら話も早いけど、
１つのスレッドを２つのコアにわけると、なんか、戻りとか処理のオーバーヘッドがでかそう。
win上で動くプログラムからそこを制御できるかも、よくわかんないし。

と、初心者は思うのでした。

初心者だと思うなら、「winのapiには無いと思う。」なんてろくろく調べもしないで
レスするなよ。

マルチコア対応apiはwinにはないね。未熟なOSなのかも。

同一ソケット上のマルチコアに特化したAPIはないわな。未熟だわなｗｗｗ

windows上なら、SetXXXAffinityMaskってのを使うみたいだけど、
OSに任せたほうが無難だろうな。
ビットマスクに何指定するのか、俺の古いMSDNだとわかんないし。

あとNT3.5から対応してるんだな。
これ使ってプログラム組んでれば、
別にwin 2kでもwin 2k severでもマルチコアに対応できる気がする。
（OSが認識さえできれば、で、マルチコアは2kで認識できるはず。非公式だけど。）

>>577への回答ね。マルチコア対応プログラムなら、おそらくwin2kでもおっけ。
むしろ余分な他プロセスのバックグラウンド処理が少ない分、win 2kがxpやvistaより早いと思う。

それ以外は、OSの判断だけど、多分２つCPUあるときと同じだから、win2kでも大丈夫な気がする。
こっちはあんま自信ない。

以上、>>577の自己回答でした。

>>589
嫌味な上級者は、絶対何も言わないんだよな。

さっきからずっと、むかつくレスしてんのこいつだろ？
上司でたまにいるんだよ。
知ったかして、具体的に何も言わないで、誰かが言ったら便乗するやつ。

そりゃ、言うべきじゃない時を心得てるのが上級者というものだからなあ

>>592
MSDN見たなら「参照」も見るといいよ

>>592
あんまり調べる気無い。
何か映像関係の高速処理組むなら別だけど予定もないし。
スレッド、プロセス関連は完全に２、３継承のクラス化しちゃってるし、
いまさらOSの判断以上の速度が出るように直す気はない。

時代がマルチコアなのになぜ対応apiがないのか？
これはMSの怠慢ではないだろうか
高いOSライセンス代（１台につき１万〜３万）を定期的（５年程度）に払っているというのに
ひどい話だ

>>597
マルチコア対応APIって具体的にどういうものよ？

>>597
だからwindowsにもあるって。
プロセッサを直接指定できるapiが。
やっぱNT系のカーネル作った連中は偉いわ。
おれもまだまだ2kで行く。

マルチコアねぇ…
TPC風にProcessor/Core/Threadで表すと、Core2Quadの1/4/4はマルチコアだよな。
じゃあシングルコアXeonを4個使った4/4/8とかItaniumを64個使った64/128/256は？
後者もマルチコアならマルチコア対応APIは既にある。

マルチダイもマルチコアに含めてるしな、、、思想的には
ていうか、やっぱまだ２ｋって需要あるかなー？
今新規にフリーソフト作ってるが、どこまでサポートするか悩む

>>599
Processor affinityはDECのVMSの時代からある。
WindowsNTと作った連中は同じだけどなｗ

>>601
俺、フリーソフトは、2kで作って、xpで軽く動かしてテスト終わり。
2kで動いて、xpで動かなくなったことはない。
基本、Direct X関係に気をつけるだけ。

CPUが別パッケージかオンダイかを気にするような場面には出くわしたことないなあ
キャッシュの奪い合いとか同期の頻度とかが問題になるのかな？

むしろhyper threadingが特別だったんじゃないかと思う

Win32のSetThreadAffinityMaskはaffinity maskがDWORDで32bitしかない
64/128/256のSuperdomeはOSからは256プロセッサに見えるんだがどうするんだ？ｗ

hyper threadingは鬼門

>>606
Pen4のHyper Threadingだけが鬼門？ SMT全般が鬼門？
ちょっとだけPower使ったときは何もなかったけどな

>>605
いずれSEtThreadAffinityMaskExが出来るだけよ

>>608
いずれってかSuperdomeにWindowsが乗ってから5年以上経ってないか？
Windows乗ったSuperdome俺は見たことないけどｗ

テキトウに仮想化でもしたほうが効率よさそうな気が

>>610
それは現実的すぐるｗ
とりあえずタスクマネージャーはこうなる
ttp://www.microsoft.com/japan/sql/images/ssj/ki03_02_l.jpg
これで「関連の設定」は64CPU設定できるのか？
つかItaniumだから64bit Windowsか…

Win64ではﾓｰﾏﾝﾀｲだた

BOOL WINAPI GetProcessAffinityMask(
__in HANDLE hProcess,
__out PDWORD_PTR lpProcessAffinityMask,
__out PDWORD_PTR lpSystemAffinityMask
);

DWORD_PTR WINAPI SetThreadAffinityMask(
__in HANDLE hThread,
__in DWORD_PTR dwThreadAffinityMask
);

>>607
606じゃないけど、HTは面倒な存在じゃない？
普通のマルチプロセッサなら異なるプロセッサ間で同じキャッシュラインに
アクセスしない方が良いが、HTの場合は逆でしょ？
ベンチ取ってないんで、どのくらい影響があるのかは具体的には分からんが。

menndouda

>>613
それはPower含めてSMT全般にいえるし、少しレイヤをずらすと
2(3)次キャッシュ共有のマルチコアやNUMAにもいえるんで、
そんなに特殊なことではない。

さっきWin64調べてたらこんなAPIがあった
BOOL WINAPI GetNumaNodeProcessorMask(
__in UCHAR Node,
__out PULONGLONG ProcessorMask
);

これで距離の近いノード内のプロセッサマスクを取得できる。
NUMAアーキテクチャに限定せず、SMTやキャッシュ共有のコアを
ノードと見なすことができると、細粒度並列実行で効果的なヒントを
与えられるかもしれない。

マルチコア対策としてこんなのがあります。

http://www.axon7.com/

また、これも参考になります。

http://www.cspjapan.org/

>>616
>537

マルチプロセス、マルチスレッド、マルチコア、マルチプロセッサ、SMT、メモコン共有、キャッシュ共有、演算器共有。
これが複合的に絡んだときの最適化は複雑すぎる。

>>617
>549

間違えた、>619は>616へ。

>>618
それをコンパイラで成し遂げることが前提のItaniumは不可能に挑んだようなものだな

マルチコアは、今までのソフトウェア技術を台無しにしてくれる素晴らしい技術だよね。
これからはソフトウェアとハードウェアの境界が無くなって、
プログラムを作るのは、より一層大変になる。

ハードとソフトが緊密に絡む領域はこれまでもあったんだけどな
無停止システムとか

今までのマルチプロセッサ向けのソフトウェア技術の延長にあるから
台無しという事は無いよ。もう何十年も研究が続けられている分野だ。

何十年も研究とか、無駄の極地だねｗｗｗ

ロックフリーのアルゴリズムやトランザクショナルな変数アクセスが
もっと一般化してくれば、そんなに恐れる物でもない気がするけどね

>>621
いったい何に怯えているんだろうか

まあそりゃ単一スレッドで速くなるほうがありがたいけどな

荒い粒度の並列化や、ベクトルの並列処理はとっくに研究され尽くされてるけど、
その中間が非常に厄介。
しかし、これからは単一スレッドでは速くならないわけだから、それをやらないといけない。

ループを展開する自動並列化くらいはインフラとして整備して欲しいね

>>629
自動じゃなくてもparallel array使えばおk

>>628
divide and conquer
work stealing
fork/join
parallel array

遅レスだが
ハードウェア・ソフトウェア協調設計等は組み込みでは昔からよく見られるんじゃないか？
まあ、シミュレーター等の開発統合環境が整えられているなら最適化はむずかしくないよ。
ただ工数と時間と労力が膨大に費やされていくだけで

組み込みの場合は、環境のプロセッサ数やプロセス数は固定されてるから、難易度は低いんじゃないかな。
PCの場合は、対象のプロセッサ数は予想できないし、同時にどんなプロセスが動くかも分からないから、難易度が高い。
というか、PCの場合は、何らかの動的最適化メカニズムが必要になるんだよね。

http://pc.watch.impress.co.jp/docs/2008/0613/hot554.htm
インテルはCを拡張してJITコンパイラで最適化する研究をしてるようだけど、
実用化はまだまだ先だよな。

１．マルチなんたらとか並列化とか、なにも考えずに作る。
２．あとは開発環境とOSがなんとかしてくれる。
３．下手なこと考えるより、そのほうが最終的に効率が良い。

こういうのが理想なんだけどなぁ…。

スレ民じゃないけどマルチコアネタがあったのでぺたぺたしていきます。

「Ruby 1.9は1.8より平均5倍速い」、YARV笹田氏 − ＠IT
ttp://www.atmarkit.co.jp/news/200709/07/yarv.html
今後のテーマは並列処理によるスケーラビリティ向上

　今後の研究テーマとして笹田氏は、並列処理への対応など
スケーラビリティに取り組みたいと話す。ただ、「Rybyの言語仕様の
枠組みでスケーラビリティを上げるのは難しい」ため、マルチコア、
マルチプロセッサといった密度の高い並列化よりも、クラスターや
グリッドのようにネットワークで接続された複数ホストによる並列化を
実現していくのがいいのではないかという。

>>634
それ何て第五世代

>>635
むしろマルチコア関係なくね？

マルチコア向けの最適化はしない方向だ、という内容だな。

今後もRubyのスレッドはマルチコアを使いこなすようにはしない方針ということだな

Rubyなんて並列化のこと何も考えてないじゃん。
書いててわくわくするとか日和ったこと言ってる言語では到底無理。

並列化に興味をもったRuby使いはErlangあたりに移行するのだろうか

アルファブロガー（笑）あたりに煽ってもらえばイッパツよ

jruby

Erlangが騒がれてるのは副作用がないのとメッセージングがあるからなの?
ほかの言語でも多少見苦しくなっても同じことはできんの？教えてエロイ人。

>クラスターや
>グリッドのようにネットワークで接続された複数ホストによる並列化を
>実現していくのがいいのではないかという。

ハードは明らかにマルチコアに進んでいて、
サーバも集約統合が進んでいるというのに。

Rubyみたいなソフト側が手前の都合だけで
「いいのではないか」とかいって方針だしても何の意味もないわけだが。

誰もそんなハード持ってません。
今のハードにあってません。

ってなるだけ。

なに、寝ぼけたレスしてるんだ？
>>644 は、Ryby という新言語について語っているんだぞ。

>>645
誰に言ってるの?

なに、寝ぼけたレスしてるんだ？
>>644 は、Ruby という言語について語っているんだぞ。

なんだ、キ印か。

>>644 って、Googleのサーバーとか、AmazonのEC2とか、分散環境が流行ってるのを知らないのか。
サーバーの集約統合が進んでるのは、既存のサーバーや負荷の低いサーバーでしょ。

分散環境が流行ってるって…
すごい規模なんだからどっちにしても分散が必要なのは当たり前。
googleなんかは2003年の時点でこれからはマルチコアみたいなこと言ってるぞ。

実際流行ってるんだけどなぁ。
クラウドとかいうキーワードでぐぐってみりゃわかると思うよ。
実効性はともかくね。

クラウドが流行ってるってのはSOAが流行ってるってのと
どっこいどっこいだな。
ごく一部で当たり前になってるのと広く使われてるのとは
全然違ってて、どっちの話をしてるかがズレてるんだな。

P2P→グリッド（言い換え）→クラウド（言い換え２）

オフコン時代の鯖だと鯖っていえば特定の対応関係になってたのが
OOのポリモフィズムみたいな多態になっただけだ

C<->Sの関係が1:1だったのが
C<->Sの関係がN:Mになっただけだ
SOAはC<->Sの関係がN:1だったがな

たしたことない。言葉変えて変化を促そうとしている単なる言い換えだ
詐欺の一種だ

クラウドとマルチコアって関係ないじゃん

まあ関係はないね
ハードの保守性とソフトのスケーラビリティを考えて、
マルチコアのマシンを仮想化してクラウドにするみたいな
話は聴いた事あるけど

>>654
ハイプで成り立ってる所も大きいから、そんなもんかと

http://www.atmarkit.co.jp/aig/04biz/hypecycle.html

とりあえずクラウドはスレ違いだろ
並列化の粒度が違う。クラウドは祖粒度、こっちは細粒度
ネタがないから構わんけど

>>652
どっこいどっこいというか、いままでSOAをかついでたところが、クラウドを担ぐようになってる。
SOAのように、クラウドは流行っている。まあそういう意味だ。
この件は、これで。

すかしっ屁こいてクライアント騙すのがクラウドなのか？

そう思う奴はいつまでも足踏みしてればいいのさ

>>657
×祖粒度
○粗粒度

クラウドもSOAもわかってないやつ多すぎ。
そんなやつらがマルチコア云々なんてしょーもねー。
せいぜい単純労働者としてコキ使われてなｗ

どっちもバズワードなんだから分かっているという方がおかしい

バズワード自体がバズワードというパラノイア

バズワードを使ってる人間はバズワードかどうかなんて気にしていないから、
一回りして結局おk

>>658
SOAと普及でぐぐると
・普及が進まない
・普及促進
・普及狙う
・普及を目指す
・普及を後押しする
こんなんばっかですけど？
流行ってるけど普及しない。笛吹けど踊らずw

クラウドはどうかと思うが、分散は物理的な話でもあるし必要なところには普及するんじゃないかな。
CPUでの並列だと限界が低いし拡張も難しいから、>>656の言うようなマルチコアマシンの仮想化で分散ってのが現実的ではないだろうか

つまり金融工学みたいな
もんですね

「クラウド・コンピューティング」は「仮想化」以来の“乱用語大賞”
http://www.computerworld.jp/topics/cloud/123069.html

644ですが普段アーキスレとかに書いている身からすると、
このスレの住人はレベルが低すぎます。
キミらが並列化について語るのはまず無理。
チップあたりの性能をあげられなくなったら、
分散処理でも同一コストで性能あげられないの。
Rubyの件はいかにもソフトしかしらない人向けの
苦しいいいわけだなあと。

自分以外みんなバカ症候群

ひんと: 賢い奴はこんなスレの住人なんて相手にしない

レベルが低過ぎてどこを縦読みすれば良いのか分からないや

アーキスレってどこ？
殴りこみかけてくる

残念だけど、現状ではマルチコアってサーバサイドや一部の
embarrassingly parallel な処理以外では絵に描いた餅だよね。
デスクトップ機でクアッドコア以上のプロセッサが必要な
場面は思い付かない。それこそハード寄りの知識を持っていない、
スレッド周りの実装の知識も無い様なプログラマが、難しい事を
考えずに処理性能を出せる仕組みが欲しい物だね。fork/join でも
ヘテロなマルチコアでも何でも良いけど。

後はトランザクショナルメモリと投機的実行も期待してるけど
なかなかこういうのは普及しないねえ…

ゲーム機でやってるじゃん

>>676
投機的実行ってRockのスカウトスレッド？
命令レベルの投機的実行と紛らわしいから用語は分けたいな
同時投機スレッド(Simultaneous Speculative Threading)とかな

トランザクショナルメモリはどうかねー
RockのHTMじゃアプリケーションレベルのトランザクション
扱うのは無理だしSTM組み合わせるとオーバーヘッドが大きすぎて
性能出ないと予想してる
つRockの出荷来年の後半とか遅れすぎだろjk

今普及しているデュアルコアマシンみたいな感じで
6 core のマシンが一番売れ筋のマシンになったら
プログラマはどうすればいい?

Vistaをお勧めする
あとセキュリティソフトを３つぐらい重ねがけ
これで万全

>>674
CPUアーキテクチャについて語れ Part.12
http://pc11.2ch.net/test/read.cgi/jisaku/1219884494/

最近は常駐コテの意地の張り合いばかりでつまらないくなってきてるけど
アーキテクチャスレは↑
普段は名無しだが、MACオタ(翻訳)などは漏れ。
がんばって殴り込みに言ってくれや。

>>681
なんでこのスレ来てるの？

>>681
2chらしいスレだなw

40 名前：Socket774[sage] 投稿日：2008/08/29(金) 02:47:03 ID:Yk6PbdtE
ま、MACオタよりよっぽどマシな態度なんで、いじめるのはここまでにします

とか書かれててﾜﾛﾀ
お前そんなに態度悪いのかよw

ダンゴさんそこでがんばってたのか

お似合いだなｗ

せっかく収まるところに収まってるのに煽らないでくれ。頼むから。

644みたいな状態って、自分の専門は知ってるんだけど他のことは知らなくて、自分の知らないことはたいしたことないって思ってるだけなんだよね。
というか、自分が他のことを知らないことを知らない。
だから、「このスレの住人はレベルが低すぎ」とか言っちゃう。

でもまぁ、このスレのレベルが低いのは事実だろう。
レベル高い議論って一つでもあったか？ないよな。そういうことだ

マルチコア用のテンプレートライブラリを活用しているという話を聞かないね
良さげなのにググっても実際に使っている例が殆ど出て来ない
C++ の人気が無いのかテンプレートが嫌われてるのか…

http://www.threadingbuildingblocks.org/
http://spc.unige.ch/mptl
http://sourceforge.net/projects/rpa
http://www.extreme.indiana.edu/hpc++/docs/overview/class-lib/PSTL/

ライブラリの話はマルチスレッドスレがあるからなあ
このスレいらない子なんじゃ…

>>687
「住人はレベルが低すぎ」などと書いて無用に荒らすのが一番レベル低いがな。

>>689
要らなかったらスレが亡くなるだけだから気にしなくておk

>>689
マルチスレッドとマルチコアでの並列化は違う。

>>692
どう違うか語ってもらおうか

マルチスレッドは、タイムスライスで同時に動かなくてもおけ

マルチスレッドが並列に動かなくていいわけないだろ
マルチコア以前からマルチプロセッサは当たり前にあるんだしよぉ
本気でレベル低いなここ…

・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできなくてもマルチスレッドは可能ってことわかってるのかな？
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。

windowsもクラウドが標準になるんだな
http://japanese.engadget.com/2008/10/01/os-windows-cloud/

>>696
・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできない時のマルチスレッドとマルチコア/マルチプロセサでのマルチスレッドじゃ状況が違うってことわかってるのかな？
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。

>>692
そもそも、マルチコアとマルチスレッドを比較するなよ。

>>698
おいおい、状況は違うのは分かるが、プログラムは同じにしとかないと
まずいだろ。

どこかのエンコソフトみたいにCPUのコア数によって使うルーチンを切り替える
ようにするなら話は別だが。

誰もプログラムを別にするとかなんて言ってないけど？

状況が違うと言うのはシングルコア and シングルプロセサで問題ないプログラムでも
マルチコア or マルチプロセサで問題が発生するケースがあるってだけ。

種々の要件によって、その状況によってプログラムを切り替える実装はあると思うが、
それはもっと条件を限定しないと議論できない。

デッドロックとかレース状態とかそういう次元の事かな。
確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
マルチコアにした途端に顕在化する場合はあるね。

>>701
マルチスレッドプログラミングとしては単なるバグじゃん

> 確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
> マルチコアにした途端に顕在化する場合はあるね。

そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
プロセサではあり得ない問題」のことだよ。

>>703
それはクリティカルセクションを入れるのが当たり前だろ

>そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
>ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
>プロセサではあり得ない問題」のことだよ。
アトミック操作でないのにロックせずに破壊した場合プログラマの責任だと思うが。

>>703
そんなバグ埋め込んでマルチスレッドとか恥ずかしいぞ

>>703
もうちょっとOS関連の本を読んでマルチプロセス/マルチスレッドに
ついて勉強してから書いた方がいいよ。恥かくだけだぞ今のままじゃ。

>>698
そもそもというなら、マルチスレッドとマルチコアの話は、 >>689に言ってくださいな

「マルチスレッドが並列に動かなくていいわけないだろ」とか言っておいて逆切れせずに。

>>708
比較なんかしてないぞ
マルチスレッドがマルチコア環境で正しく並行動作するのは当然
だからライブラリの話はマルチスレッドスレの方がそれなりに議論してて
適切だろうってことだ
マルチスレッドスレを並行動作しなくていい話題に限定したら
糞スレ確定で速攻落ちるぞw

同じ変数を複数スレッドで更新する可能性があるなら、UP/MPに限らずバリア入れる。
更新するのが一人だけだったら、ちょっと考えてから決める。

そういう話は、その時点でやってくださいな。
あと出しで切れるのカコワルイ

>> 709 ね。

>>711
どこが後出し？w

>>704
そもそもクリティカルセクションをどう構成するかと言うレベルの話だから、
君には用はないので当分 ROM っててくれ。

>>705-706
シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。

マルチコア/マルチプロセサではちゃんと動かないから良くないコーディングと
言うならまだわかるが。

>>707
どこがどうおかしいかちゃんと指摘してくれ。
まさか、>>705-706 の的外れの指摘のこと言ってるのか？ (w

>>714
アホですか
RISCはロード/ストア命令とモディファイ命令を１命令で実行できない
物があるのでアトミックではない場合がある

つーか明らかな自分のミスを認められないグラマって
必要ないな。

こういう奴がいると絶対にプログラムにバグを入れてくれる。

そろそろダンゴさんがピシっと〆めてくれそうだ

つかシングルコアでも他デバイスがDMAしてきたらアトミックにならんやろ

メモリにアクセスするプロセッサがひとつだけっていつの話？

Java のでも GCC 組み込みのでも、OS ネイティブのでも良いけど、
アトミック命令ってみんな使ってるの?

排他やると暗黙的に使われるんじゃね

無意味な連番つけるときに AtomicInteger を使ったことはある

AtomicReferenceFieldUpdaterは友達

レベルの低いスレ/話題は伸びるのが速い。

レベルの低い話題に詳しそうだな

>>715
> RISCはロード/ストア命令とモディファイ命令を１命令で実行できない
> 物があるのでアトミックではない場合がある

そんなプロセサにメモリに対する inc 命令なんかあるのか？
あるんならそのプロセサの型名書いてくれ。

>>716
「明らかな自分のミス」ってどれのこと？
ちゃんと指摘してくれって書いてあるのに指摘できないの？

>>718
ああ、DMA はあるな。
ただ、通常の DMAC はレジスタで制御するから、メモリ上で排他なんかしないでしょ？

> メモリにアクセスするプロセッサがひとつだけっていつの話？

今でも普通にあるよ。PC しか眼中にないの？

また前提が増えたな。

DMA無しだとさ。

>>718見て、Windows 98で386のときのInterlockedIncrementは、
デバイスドライバ内で割り込み禁止してincを実行するって話を思い出した。
http://blogs.msdn.com/oldnewthing/archive/2004/05/06/127141.aspx

>>726
また？
DMA 以外で増えた前提って何のことだ、ちゃんと書いてくれよ。

>>725
> そんなプロセサにメモリに対する inc 命令なんかあるのか？
> あるんならそのプロセサの型名書いてくれ。
無いからバグなんだろ。

>714 の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
に対する返信だろう。

>>728
きっと>714の「シングルプロセサ/シングルコアなら」のことだろうね

>>725
> 今でも普通にあるよ。PC しか眼中にないの？

SPARC/Power/Itaniumサーバも眼中に入ってるよ

>>725
> 「明らかな自分のミス」ってどれのこと？
> ちゃんと指摘してくれって書いてあるのに指摘できないの？

>714の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
のことだろうね

Itaniumなんてもうフェードアウトだろｗ

>>733
FNHではバリバリですよ
FはSPARCに注力した方がいいと思うけど東証決まってるからなあ

なんか、自分のミスはスルー、この反応みると本当に気づいてないようだ。だから自分はノーミスだと思っている。
前提をあとからつけて、人の意見を間違っているという。
まわりが全員レベル低いんじゃなくて、君ひとりがまわりの会話についていけてないんだってば。

>>729, >>732
> 無いからバグなんだろ。

「メモリに対する inc 命令持たないプロセサだとメモリのインクリメントは必然的に
複数命令になるからアトミックじゃないだろ？」って言ってるの？

ならすまん、inc 命令の話してる時にその命令持たないプロセサまで考慮して話せと
言う奴がいることまでは想定できなかったよ。

世の中には自力ではメモリのインクリメント自体ができないプロセサもあったりする
からそこから前提におけということかな？ (w

>>730
>>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。

>>731
> SPARC/Power/Itaniumサーバも眼中に入ってるよ

で、それしか知らないと思ってていいのか？
なら、もう少し見聞広めた方がいいんじゃね？ としか言えないけど。

>>735
「ミス」とか「間違っている」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。

指摘されてもスルーなのが笑える

これはひどい。
いくらなんでも釣りだろ？

itaniumはもう終わりだろｗｗｗ




と5年間言われ続けて、無事生存中

>>725
incはアトミックじゃない。
でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。
おまえさんはコンパイラがincに落とすのを当然と考えた上でincがバス制御しない事を忘れてる。

>>736
> >>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。

その前提を持ち出してるのが大間違いの元なんだよ。
マルチスレッドプログラミング全般としてはそんな前提はないわけ。
君にとってはシングルプロセッサかつシングルコアがデフォで
マルチプロセッサ／マルチコアが特殊なのかもしれないが、
マルチスレッドプログラミング全般としてはシングルプロセッサかつ
シングルコアはマルチプロセッサ／マルチコアの特殊ケースでしかない。
マルチプロセッサ／マルチコアでちゃんと動かないようなのはただのバグ。

というか、このスレ全体がひどい。
まず、議論になってない。
そして、議論以前に半分以上の書き込みが用語を並べてみているだけで技術的に意味の通る文章になっていない。
コンピュータ用語に語彙の偏った人口無脳がはき出したような文面の書き込みばかりで流れがない。
今時マルチスレッド、マルチコア、分散処理の区別もつけられない人がこんなにいるなんて信じられない。
日本のプログラマってこんなレベル低いんだ…こりゃ将来が危ぶまれるわ。

>>742
だってここ2chだし

>>742
たしかに、この発言とかひどいよね
「マルチスレッドが並列に動かなくていいわけないだろ」

>>744
どうひどいか語ってもらおうか

>>742
「このスレ全体がひどい。」とか「議論になってない。」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。

今このPC、 AthlonXP 1500+ で 53プロセス 562スレッド 動いてるぜー

>>745
マルチスレッドは並列に動かなくてもいい。

マルチスレットは、タイムスライスでもいいから、並列に同時に動く必要はない。

GreenThread

>>748-749
並列に「動かさなくてもいい」ならそうだが
「動かない」ってのはダメだろ
つか確かに議論になってないな
コンテキスト整理するからちょっと待ってろ

そもそも「同時に動く」ってのはどういう意味でいってるつもりなんだ?
意味わからん。
たとえば
・レジスタやメモリに結果を書くのを同時といってる?
・実行ユニットで演算されるのを同時といってる?
・前後を入れ替えても意味が変わらない処理を同時だといってる?
もう少し頭の中で整理してかいてよ。
タイムスライスってどういう意味でいってるの?
コンテキスト情報をスワップすることがよくいわれる時分割の本質的な意味でしょ?
コンテキスト情報が複数ハード上にあるのがマルチプロセッサだったりマルチコアだったり
ハードウエアマルチスレッディングがスレッドレベルで並列であることの本質なわけだけど。
CPUが実行ユニットで同時に計算しているとか同時にメモリに結果を書くとか関係ないよね?
このスレで議論している連中は用語をならべているだけで、その中身についてはよくわかってない気がする。
回路設計が本業の漏れからみてもまず基礎がひどいと思いました。

>>737
どこがスルー？
具体的に指摘しなよ。

>>740
> incはアトミックじゃない。

DMA の話？ それ以外にシングルコア/シングルプロセサを前提としてあるなら、具体的に
書いてくれ。

> でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。

そう言う命令がないプロセサもあるから、ちゃんと前提つけないとクレームつけられるよ。(w

> おまえさんはコンパイラがincに落とすのを当然と考えた

人の心まで読めるの？ 上級エスパーさんにはかなわないな。

>>741
前提つけたら、そんな前提が間違ってると来たか...。
そこまでしてレスしたいの？
まあ、どっちにしろそう言う文句は >>696 辺りにつけてくれ。

>>752
> このスレで議論している連中は用語をならべているだけで、その中身については
> よくわかってない気がする。

自己紹介乙。

結局、そこで議論にならなくなってるわけでね。

そろそろ753はコテハンつけて欲しい

>753は>703なんだよな？
だが>753は>696じゃないのか？
俺流れが見えてねぇw

元々このスレはハードウェア主体でマルチコア化が進んでいるせいで、
ソフトウェアを並列化しないといけなくなったのに不満を持った
アンチマルチコア派ｗがたてたスレだからね。本当はソフト屋さんの
ためのスレッドなんだけど、有意義な話がなかなかでない。

回路屋が何かとソフト屋を馬鹿にしているようだけど、せっかく
マルチコアの石があっても、ソフトウェア側の理論がないと意味がなく、
またソフト屋はソフト屋の理屈があるのでそこら辺勘違いしないように
お願いします。

並列化といっても必ずしもバスアービタがどうとかそういう回路よりの
話だけでなく、並列型言語とかプロセス代数とか形式手法とかそういう話を
期待ているんだけど、やっぱり並列化に対するソフトウェア技術者の
意識は弱く、そういう話をができる人はあまりいないみたいだね。
(俺も話ができない一人だが、そういう人の出現を待ってこのスレ読んでます)

だんごやさんだよ。
色んな意味でマルチスレッドだよ。

> 並列型言語とかプロセス代数とか形式手法とか

ここ強調すると住人総入れ替えじゃないか？w
もし次スレ立てるならスレタイに【Π計算】って入れようぜ

Π革命

>>757
> >753は>703なんだよな？

あたり。

> だが>753は>696じゃないのか？

>>696 じゃなくて、>>698

> 俺流れが見えてねぇw

簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
マルチプロセサ」で、状況が違う例としてメモリに対する inc 命令を取り上げ
たら、inc 命令ないプロセサでは状況が違うとか (当たり前だ)、そもそも
「シングルコアでシングルプロセサ」なんて前提がおかしいとか言う奴が出て
きて騒いでるだけ。

# 正直 DMA のこと忘れてたのは事実。
# DMAC とメモリーを排他制御したことないので、すっかり忘れてた。

まあ、流れを追う価値はないから、安心してくれ。(w

△ やっぱり並列化に対するソフトウェア技術者の意識は弱く
○ ソフトウェアベンダの合理的経営判断に基づいた技術者・コード屋に対する適切な仕事配分の結果

Cilk とか UPC とか?

>>762
> 簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
> マルチプロセサ」で、状況が違う例

その状況の違いは本来不要だったんだよ
どっちもマルチスレッドスレの対象になってるんだから
発端は

>>689
> ライブラリの話はマルチスレッドスレがあるからなあ
> このスレいらない子なんじゃ…

>>692
> マルチスレッドとマルチコアでの並列化は違う。

なんだから、マルチスレッドスレでは扱わないがこのスレ(マルチコアスレ)
の対象になる違いが話題になるべきだったんだ
マルチスレッドスレが「シングルコアでシングルプロセサ」の話題限定なら
外れてないがそんなこたーないわけ

以前からあった並列計算機以上のことはできない罠

>>764
C++なら>688、Javaならjsr166yのfork/joinやParallelArray、C#ならTPLとか？

OpenMP, MPI

>>758
まあ、回路屋といっても計算機のアーキテクチャとかあんまり関係ないんだけど。

それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
このスレを読み返すと前提から大分抜け落ちているように見える。

ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
ことはできない。個人的にはマルチコアは好きではないが、
ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。

一方グーグルはマルチプロセスを使った（クロームで）

> それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
> シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
仕方ないのはいいけど、マルチコアにした後にどうやって使うか回路屋
まったくノーアイデアでしょ。ソフト屋としてはめちゃくちゃケツ
ふかされている感がたっぷりなんですが...。

> CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
> このスレを読み返すと前提から大分抜け落ちているように見える。
こういう風に好意的(というか同情的？)に思うソフト屋は少ないんじゃないの？
だって勝手に回路屋がこれからはマルチコアの時代だよねっ！て勝手に言っているんだもん。
仕方なくやっているんだったら、もうちょっとネガティブな感じでアピールして欲しい。

> ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
> ことはできない。個人的にはマルチコアは好きではないが、
> ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。
これは結局お互いさまという当たり前の話になるので、まあ言い分としては
理解できます。

今までの時代がソフトウェア屋さんに優し過ぎたって事なんじゃないの

優しかった時代なんてない

布団で寝てても数ヶ月したらクロックが高いプロセッサが出てくるなんて
夢の様な時代だったじゃない。

相対的にはこの15年くらいはそれ以前より優しかったと言える
でなけりゃJavaがメインストリームになることはなかったはず

>>771
>回路屋
>まったくノーアイデアでしょ。

ノーアイディアっつー事も無いんじゃない?

あまり詳しくないけど、、、
Intel >> TBB
Sun >> JSR166y, Fortress
IBM >> X10

サーバサイドなら仮想化とか Map/Reduce とかもあるし、
マルチプロセッサの歴史が長いから、そもそもスケールする
アプリも多いよ。

PCIバスもバスマスタになるからメモリ書き込むよ

Pentium 4で3GHz到達したくらいまでが天国だったろ？

MapReduceはサーバーサイドじゃないけどね。

>>765
> その状況の違いは本来不要だったんだよ

え゛っ、今更そんな言い訳ですか...。

だったら、RISC がどうのこうのとか言ってた奴はまんまバカじゃん。
まあ、実際バカだと思うけど。(w

て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
グルコアとの違いを書いただけで、常識的なことだから普通に流され
ると思っていたんだが...。

>>780
今更って…>709でも同じように書いてるんだけど
言い訳とか後出し(>711)とか意味わかんないし
話が>689から始まったのを分かってないのか？

> て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
> グルコアとの違いを書いただけで

繰り返しになるが、マルチスレッドスレがシングルコアスレなら
それが違いになるが、そんなこたーないわけ
この話続けてもかみ合いそうもないから俺はもう逃げるよ

この板の連中もたいしたことねーな

>>779
わざわざ説明しなくても良いと思ったんだけど、必要だった?

なんか不思議だよね。CPUのクロックは別にまだ上げられるだろ。
消費電力考えたら、マルチコアにいくのがいいよね〜っていうだけで。

で、マルチコアのプログラム支援が言語レベルであれば理想的だが、
なくてもそこそこやれる（やれてる）でしょ？コア数が100とか
1000とかになってくると、言語レベルの支援がないと厳しく
なってくるかもしれんが。

何がいいたいか、自分でもわからｎ

あげられないからマルチコアになったんだよ。

クロックは上げられるけど、投資対効果が期待出来るスピードで
クロックを上げ続けるのは無理。それより余ったトランジスタで
コアを増やした方が取り敢えず嬉しい。

マルチコアの方が使っててスカスカに軽く感じるじゃん？
当面はそれでいいんじゃないかと思う。

で、ユーザーがマルチコアの潜在能力を活かしてプログラム
全体の速度を上げられないかと言い出したらそういうプログラム
を作ればいいが、そうするとシングルコアと同じく多数のプログラム
は同時に動かしにくくなる。

どうせみんな8つくらい同時にプログラム動かすよね。
じゃあ、クライアントアプリなら、なんも考えなくてもいいんじゃないか

8つくらい立ち上げてても、ほとんどのプログラムは待機状態だと思う

>>781
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>692 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>709 比較なんかしてないぞ

「違う」と書きながら、指摘されたら「比較してない」って言い張るわけですね。
比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

まあ、「逃げる」とか書いてるぐらいだから、流石にもうでてこないだろう。
普通に考えても、恥ずかしくて出てこれないと思うけど。(w

>>790
>692と>709は別人ね。

マルチコアに対応と言っても並列化したいのはほんの一部分だし、
スレッドプールとタスクキューを作れば何とかなりそうな気が…

つまり「ミニOS」みたいな構造にしてCPUにさせる仕事を細かく分解し
やらせる仕事は片っ端からキューに叩き込んで行き仕事を終えたコア
が次の仕事を取りに来る、とか

並列化したい部分なんてのは単純に並列化すればいいだけで何の問題もなく、
特に並列化したいわけでもない普通の部分をいかに並列化してパフォーマンスアップに繋げようかってのが難しいんじゃない？

>>790
>>692の中のアンカー読めるか？>>692は>>689へのレスだぞ
そして>>709の名前欄読めるか？>>709は>>689だぞ
>>692と>>689=709は別人、流れはこうだろう

>>689 このスレいらない子なんじゃ…
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

比較して違うと言ったのは>>692
比較してないと言ったのは>>689

> 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

謎なのはお前の読解力だw

長文ウゼ(´Α｀)

よくしらんがコンカレントCとかadaとかか？

>>795
まあレス番素直に読めばそうだな。

そうすると、>>708 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w

すまん、レス番間違えた。

そうすると、>>709 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w

>>784
パイプラインを細分化してもレイテンシが大きくなりすぎて効率が上がらないし
配線間隔が狭くなりすぎてリーク電流を抑えるのに神経使う時代が到来した今
シングルコアでクロックをひたすら上げるアプローチなんてどこもやらないよ。
強いて言えばPOWER6くらいか。

5年で5〜10倍なんてペースで進化する時代はもう終わった。

コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
一番有効な手段だったりする。

>>799
> そうすると、>>709 は話の流れに関係なく唐突に

もう一回書くぞw

>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

AがBに「比較するな」と言い、BがそれはCに言えと言い、
それでCが「比較してない」ってのは「話の流れに関係なく」でも
「唐突に」でもないだろ

>>709=689 (俺は)比較なんかしてないぞ

の方がよかったかもしれんけどな
突っ込むなら比較して違うと書いたくせにCに振ったB(>>708=692)だろ

だったら、おまえら二人で相談でも何でもして解決してくれよ。

俺は、>>692 に「比較するのはおかしい」と指摘しただけで、
お前ら二人が別人かどうかなんてわからんのだし。

>>802
> お前ら二人が別人かどうかなんてわからんのだし。

誤読しといて開き直るなよw

ここ住人は行った人結構いそうだな
ttp://d.hatena.ne.jp/potasiumch/20080827#1219824560

＞一般企業での並列化は遅々として進んでいない。某 Ad○be 社に
＞並列化コンサルティングに行ったところ、「○○処理の部分はプログラマが
＞だいぶ前に死んだのでそれ以降誰も触っていない・触れない」「え、リコンパイル？　
＞そんなことしたらもう動かなくなったりしないかなあ」などと言われた。

＞（だからあの会社の製品はあんなに重いのだろうか？）

ワロタと同時にゾッとした

シングルコアとクロック数の話で　「周波数と消費電力が2乗の関係」
ということが論じられていない件について

ああ、CPUなんて1Hzでいいよ

>>806
fは1乗

CMOSデジタル回路の消費電力

P = Na×C×V^2×f + Nt×Il×V

P:消費電力
Na:動作ノード数
Nt:全ノード数
C:ノード容量
V:電源電圧
f:周波数
Il:ノード当たりのリーク電流

>>806
同じアーキテクチャで同一電圧での話なら2乗だけど
ある程度以上はクロックを上げるのに電圧盛らないといけないので3乗になるんじゃなかったっけ

>>806
ここはソフトウェアの板だから、そっち方面の話題の需要は無いと思われ

ソフトオンリーの人がハードを含む話をすると悲惨たからな。
>>50->>57あたりにソフトウエアの板のマルチコアCPUに対する理解度があらわれているよ。

ソフトウエア板住人の

生活に直結していないから不要な知識なんじゃないの。
多分 >>803 みたいな話がむしろ当然な世界でしょ。
食い扶持に影響する様になったらガッと動くけど、
手を抜ける所は手を抜くのも仕事では重要だし、
コア数が一桁のうちは今のままでも困らないかと。
秘伝のソースを書き換えたりアーキテクチャを一から
変更したりするとテストだ互換性だと色々面倒だし。

ｽﾏｿ。レス番間違えた。

×　>>803
◎　>>805

レンダラーとかゲームの思考エンジンとか、並列処理に向いてるソフトウェアでも
売り物じゃないオープンソースのは並列化されていない事が殆どだね。やっぱり
一手間加えるのがマンドクサイのかな。

>>800

> コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
> 一番有効な手段だったりする。

いやだから、そんなことは当たり前であって。2個とか4個とかなら、その
CPUをフルに活用するようなプログラム作れるかもしれないが。

100個とか1000個とかになったときには言語レベルで支援がないと
きつくなるのじゃないかな？っていう話。まぁ100個とかになる前に、
バスネックになると思うが。

100 CPU 越えのマシンは既にあるよ。
1 socket で 64 並列の CPU もあるし。

>>803
おまえらが別人かどうかもわからんのに誤読とか言われても知らんがな。
にちゃん初心者か？

>>816
なるほろ
確かに、これから先コア数がガンガン増えていったとして
デクストップアプリケーション、例えばExcelなんかが
その性能に比例して進化していけるのか
今までのアプローチでそれが可能なのか
不安が残るな

今のスペックでそこそこ動いているものを挙げたって仕方ないだろ。
コア数が増えるならそれに適応したシステムになるのは当然。
コア数が増えて初めて恩恵を得るようなものを作っていかないといけない。

マシンがすでにあることなど関係ない

>>811
どうみてもまじめにつっこむとことちゃうだろ

>>818
くやしいのうwwwwwくやしいのうwwwwww
「レス番素直に読めば」別人ってわかるだろうがw開き直んなw
もう一回書いてやるよ。こぴぺだけどな

>>692の中のアンカー読めるか？>>692は>>689へのレスだぞ
そして>>709の名前欄読めるか？>>709は>>689だぞ
>>692と>>689=709は別人、流れはこうだろう

>>689 このスレいらない子なんじゃ…
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

比較して違うと言ったのは>>692
比較してないと言ったのは>>689

> 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw

オマイ等そろそろ他所でやれよな。
2ch だからって何書いても良いという訳じゃないんだぜ。

ああそろそろ規制議論板に報告して芋掘りしてもらう頃合いだな

>>823
> 別人ってわかるだろうが

そもそもお前が誰かもわからんのに、何を言ってるんだろうこの人。(w

>>826
そうだね、君の読解力じゃ無理だよねw
笑えるよなぁ、コテハン付けて勝利宣言(>790)のつもりが墓穴だもんなwww
そのコテハンそろそろ捨てた方がいいんじゃないの？他の人に迷惑だしさ
普通に考えても、恥ずかしくて出てこれないと思うけど。(w

私のために争うのはやめて！
てのはさておき、いい加減にしたらどうなんだ。

元の話でいえば、シングルコアのCPU上のマルチスレッドプログラム
が、マルチコアのCPU上で動作しなくなることなんて、バグじゃなく
ても当然ありうる。タイムスライス限定とかいうなよ？自分の
知ってる範囲だけがマルチスレッドじゃないのだから。

優先度に基づいたマルチスレッドもあるし、そういう環境で無駄な
排他を排除することは当然ありうる。マルチスレッドじゃないが、
割り込み禁止で排他する場合も、マルチコアじゃぁ別のCPUで
割り込みハンドラが動くこともある。

最初からシングルコアっていうかその環境専用に作ってるならバグじゃないし
マルチコアは想定外と最初から言ってないなら普通はバグと判断される
それだけのこと

>>829
何をいいたいのかわからんが。そのプログラムがどんな
システム向けに作られたかしだいでしょ。最初から
「マルチコアを想定して作ることを求められたプログラム」
ならバグであるし、そうでないならバグではない。

30年前のシングルコアしかなかった時代のプログラム
は全部バグっているというのかい？

折角の週末を無駄にして、君たちは一体何と戦っているんだい？

>>830
俺は>829に同意。
デフォでマルチプロセッサをサポートしてるのが当然な環境が今は多い。
PCでもWindowsNTWSは最初から2プロセッサをサポートしてたよな。
動作環境にNTが含まれていたら、対象外と明示していない限り、
マルチプロセッサ／マルチコアで動かなければそれはバグ。
前提の環境がマルチプロセッサを含まないことが明白な場合は別。

>>832
だから、なんのプログラムに対してバグっているといっているのだ？
仮にあなたが発注元で要求仕様に「マルチコアでも動作すること」
という条件を含めていなかったら、それはバグではなくて仕様。

その変のフリーでころがってるプログラムがマルチコアで動作しな
いとしたら、それは＊あなたが＊バグであるかどうかを判断する
立場にはないよ。作者がマルチコアに対応するつもりでプログラム
作っているなら＊作者＊はバグであるというかもしれないし、
シングルコアのみに対応するつもりなら、＊作者＊は仕様だと
いうだろう。

前提が不明なのだよ。

それはない。逆。
このソフトはマルチコア環境では動作しません。
とうたっていない限り、バグ。

>>833
仮に動作環境がWindows2000やXPだったら、「マルチコアで動作しない」
と書いてない限り、動かなかったらバグだよ。
OSがサポートしている環境ではマルチコアもその範囲内だから。
それは明白だよ。不明じゃない。
はっきり書いてない場合にマルチコアで動いて当然の環境があるんだよ。
作者がマルチコアを想定してなくて動かなかったなら、コードを直すか
ドキュメントの動作環境を直すかのどちらかは必要だろう。
つまりコードのバグか、ドキュメントのバグかのどちらかになる。

極端な話、3GHz以上のCPUでは動きませんと明記していないかぎり、
3.2GHzだろうが5GHzだろうが暗黙の了解でソフトは動いて当然。
動かなかったらバグだろ。それと同じだよ。

特殊なソフトじゃない限り、「シングルコアのCPUじゃないと動きません」なんて、許されんな。

『動く』と書いてあるのに動かないのはバグ。
書いてなくて動かないなら、動かなくてもおｋ

『動かない』と書いてないのに動かないのはバグ。
書いてあって動かないなら、動かなくてもおｋ

>>835
Windozeとか、べつにタイムスライスしかないのだから、ドライバで
ないかぎりマルチスレッドプログラムは、普通にマルチコアでも動く
だろ。何をいってるんだ？

>>840
上のほう読んでよ。アトミック操作を適切に行っていないプログラムは、
マルチコアで動かないけどシングルコアでマルチスレッドなら動くって眉唾なこと言っている奴がいたんだ。

>>838
そう思ってるのは開発側だけだな。

そういや昔、マルチスレッドのプログラムがちゃんと動くかどうかテストするのに
マルチプロセッサのPC組み立てたっけ。
90MHzのPentiumでDaytonaだった。

高速なCPUで動かないｿﾌﾄといったらWindows95だろ
たかだかK6-2の350MHzでｺｹるってどんだけだよと

コア数が増えてoccam復権しねぇかなぁ

>>843
マヌケだなｗ

>>840-841
二人とも0点

一般的なソフトウェア開発の観点では、プロセッサもしくはランタイム環境の、主にメモリモデルに起因する問題が多い

>>864
理解できない時は素直に認めた方がいいぞ。

スルーパス出ました

>>827
>>826

このスレ絶望的にレベルが低いですね。

今日はそうみたいだな。

ダンゴさんが最近発言していないからな

ここ的にはMSのCCRは問題外ですか?

LeopardでLAMMPIをコンパイルしたのですが正常に動きません。
なんでなん

お前がバグだからだ

俺がバグだ
目標を駆逐する

超初心者なんですけど、
quad coreで単純に４つのexeファイルを起動したとき
それぞれのプロセスが各CPUに割り振られて
シングルコアの４倍の速度になると考えて良いでしょうか？

exeファイルはシングルコアで動かすときのプログラムと全く同じで
何も変えずに4つ実行するということで。
要は、quadで動かすときに何か特別なプログラミングをしないといけないの？
ということなんですけど。

cpuしか使わんプログラムなら4倍になる。

>>861
４倍にできない場合ってどういう場合なんでしょう？

ディスクアクセスなど入出力が多い場合とか

メモリアクセスとかにもよるだろ。
CPUのアーキテクチャにもよるだろが。

演算性能上げるのに並列処理を抽出してプログラミングするには、
書く内容がかなり変わる。

シングル用に書かれたプログラムは、そのまま実行できる。

シングル用のプログラムの性能は、ほとんど同じ性能で走ることもあるが、
メモリバス性能など、ネックがある箇所によっては各々が1/4がそれ以下の性能しか
出ないこともある。

例えば大量にメモリアクセスするようなら、メモリアクセスがボトルネックになって性能出なかったりするわな

NUMAにしてローカルなメモリ意外触らない

特別なプログラミングしてるじゃねーか

だから4つコアで4つプログラム動かしたときって言ってるだろ。日本語が読めないのか？

誰に言ってんの？
どれに言ってんの？

IKE NUMA

メモリでボトルネックに成ってたらほとんどの処理は絶望的だな。
ディスクもネットももっと遅い。

OpenMPとOpenCLとboost::threadとpthreadとWindows API threadの良し悪しを教えてくださいませんか？

ほらyo
OpenMP×
OpenCL ×
boost::thread ○
Windows API thread ×

CCRはネ申..._φ(ﾟ∀ﾟ )ｱﾋｬ

PS3薄型と旧型の違い

旧型PS3：
Linuxインストール機能内蔵でPS3をPCとして使うことができる。
PPC Linux用の無料のソフトがいっぱい動く。
また、Cellの開発ツールも無料で入手できるので自分でCellのプログラムを作って実行させることができる。
ドルビーTrueHD、DTS-HDMAはリニアPCM変換で対応。
HDD〜80G。実勢価格30000円程度

薄型PS3：
Linuxインストール機能は除去された。
ブラビアリンク機能でブラビアと連動した電源のON OFFができる。
ドルビーTrueHD、DTS-HDMAのビットストリーム出力対応。
HDD120G。低騒音低発熱。実勢価格29980円

シングルコアのPC上で動作させるwindowsのタイマーを複数使ったプログラミングを
マルチコアのPCで動作させても並列処理にはなりませんか？
何か特別なやり方とかしないといけないでしょうか？

なるわけがなかろう

>>878
やっぱりそうですか。
もう根本的に無理ですか？

シングルコアのPC上で動作させるwindowsのタイマーを使ったプログラム複数を
だったら。

そもそも、そのタイマーの処理は、並列実行しても安全なようにコードを書いてあるのか？

>>880
やっぱり複数のアプリを立ち上げないとダメなんですね。
>>881
普通にタイマーを複数作っているだけで、
どう作れば並列実行に安全かもよく分かりません。

まず、そもそも並列する意味があるかどうかをだな

>>883
意味ははあります。
とりあえず複数プログラム間でのプロセス通信はしてますが、
通信だといろいろ設定やらやり取りがややこしいので、
一つのアプリで並列動作させたいのです。

「タイマとか関係なく、1プロセス内で平行処理させたければ、スレッド起こせ」という結論でFA
まあCreateWaitableTimer + RegisterWaitForSingleObjectのように勝手にそこまでやってくれるような組み合わせもあるけど。

>>884
それってマルチスレッドにすれば解決するか、
マルチコアで並列にしても解決しないか、どっちかだろ。

OpenMPを使えるか調べてみたら？
複雑な同期がいらない並列プログラムなら手軽でいいよ

Interlocked周りを使ったパターンってあるもの？
いままであまり使ったこと無かった。
RWLockとかにもつかえそうなんだが。

そりゃいくらでもある。
全ての同期の基本に近い。

たとえば？

ミューテックス・クリティカルセッションなどと呼ばれるもののの実装とか、
あとは、Lock-freeでググれば、キューとかリストの実装も見つかるだろう。

その話題はマルチスレッドスレでやってる。

マルチスレッドで書けば、マルチコア対応にも成るからなあ。
結局の所、マルチコアを使いこなすならマルチスレッドで書いとけもひとつの解だし。

つーかマルチスレッドとマルチコアってわけんの？
おなじCPU上で動かす云々とかもあるけれどあまりそこまで意識しようとしてないわ-

キャッシュのコヒーレンシの問題あるからなあ
共有メモリで互いのメモリ監視が多い場合、マルチコアのシステムだとかなりパフォーマンスが落ちるはず

互いにほとんどメモリ参照しないで走っている感じだとマルチコアのほうがHTTよりもパフォーマンスがいい可能性もある

プログラムの種類にもよるだろうけどそこら辺を考慮した実装と市内ものでどれだけパフォーマンスに違いあるかみてみたい。
たいてい1割も違わないんじゃ？

いやいや、並列化が本当に必用な領域では、キャッシュ
コヒーレンシ維持のためのオーバーヘッドや各スレッドの
連続する処理でアクセスするメモリのサイズについて真剣に
考慮しないと下手すると何倍もの差が出るのが通常だよ。
少なくとも俺の経験では。

そもそも複数のスレッドでメモリ空間が重複してる時点で
並列化失敗してるんじゃないの？

逆だ。キャッシュの効率を考えて、同じCPUで近いメモリ空間を使うように設計するんだ。
例えば行列演算の場合、2core*2cpuならCPU間では空間を離し、core間は近くする。
巧くすれば、対策前の2倍は充分有り得るね。

>>899
fortran あたりは、よきに図らってくれたりしないのかな？

そんなコンパイラスイッチ見た事無いな。
インテルのCPUが出る旅にバージョンアップが必要とか？

>>901
すまん、スパコンとかそっち方面を考えてた
インテルの fortran って、自動並列化は結構賢いって聞いたことがあるが…

>>899
core毎に隔離した方が良い

>>903 CPU によっては L2 がコア間共用だったりすることもある

まぁそこら辺はプログルマがごちゃごちゃやるよりコンパイラの中のエロイ人にやって欲しいものだ( ﾟДﾟ)y─┛~~

するとプログラマの人件費が減らされて、メーカ謹製のコンパイラ代に変わる訳だが。

共用キャッシュでもいろいろ有るしなあ。プリフェッチ深いのとか。
クラウドコンピューティングとかごった煮環境じゃ最適化厳しいでしょ。
スレッドプログラミングで最大公約数的な所で落ち着くと思うけど。

今時のスパコンってたったの2コアだったりするの？
ALUとか実行ユニット積みまくれば速度は稼げるのかもしれないが。

>906
いやその分プログルマは他の所に時間が割けるようになるでしょ？
自分で考えられる人工知能が出来ない限り要素の調停を行う場所がシフトするだけでプログラマの仕事は変わらないよ。

>>906
> 今時のスパコンってたったの2コアだったりするの？
パッケージ内のコアって意味ならたいして多くない。数使ってなんぼの世界

NEC SX-9: スカラユニット x 1 + ベクトルパイプ x 8 で 1 CPU
シングルノードで4〜16CPU

つか、今時、専用プロセッサ使ってるの NEC 位じゃね
cray は opteron だし
IBM は Power6 とか CELL だし
日立は IBM 製品使うみたいだし
富士通は命令拡張したマルチコア sparc に行くみたいだし

>>908
NECが専用使ってるのは国策？

>>909
10 ペタマシンからおりちゃったし、違うんじゃないかな？

Power5/6はデュアルコアだけどL2が共有だからHPCに使う場合は片方のコアつぶして
シングルコアとして使う

>>911
Power6 は L2 分離だったはず。
調べようと思ったらいつの間にか有料にorz
http://www.research.ibm.com/journal/

>>912
ｽﾏﾝｶｯﾀ

Allowable Card Account Number Lengths Visa Card 16 digits. ,

メニーコアとSMT対応ってどう違うんだ？
4コアCPUと2コア4スレッドCPUのパフォーマンスは同じにならんの？

>>915
普通のアプリだとそこまで気にすることはないと思う。

OSのスケジューラなんかだと、今実行できるスレッドが2つのとき、
2コア4スレッドの環境なら、片方1つのコアで2スレッド実行させるより
2つのコアで1スレッドずつ実行させるほうが効率がよい、なんてことも気に掛けるみたいだけど。

4コアは演算器の完全なセットが4つある
2コアは演算器が2セットぶんしかないが、もし空いてればそのぶんは別のスレッドも動かせる
例えば整数演算メインのスレッドと浮動小数点演算メインのスレッドがあれば、
お互いメインに使う演算器が違うから同時に動かせる率が高いけど、
整数演算のスレッドばっかりだと同時に動かせる率が低い
って感じじゃね

HTはたまたま空いてるCPUの演算機を使って仮想的にもうひとつスレッドを動かす。
だから、仮想スレッドはせいぜい20〜30%までの性能が限度。
普通10〜20%とか、もっと低いくらい。
マルチコアとは全く違うよ。

コンパイラの吐き出すコードの効率が高いほど
HTの効能下がるな。

どういうオプション指定かにもよるので。
シングル用かデュアル用ならHTも悪くない。HT用が最良だけど。

新しいサーバ買ってもらった。16コア。何に使おう

梱包して発想の準備をしてから待っていてくれたまえ。

窓からぶん投げる日を教えてくれ。

パイプラインの長いコアだとHTは効率改善には効果的みたいだな。
１コア辺り８スレッドなんてのもある。
しかし、効率はいいんだろうが、スレッド視点で見たとき
期待通りにうまく動くんだろうか…

(´・ω・｀)

コンピュータサイエンス史上最大の課題「並列処理による性能向上」
〜情報処理学会創立50周年記念全国大会の招待講演
http://www.publickey.jp/blog/10/50.html

>>926
その人の顔入りマグカップが送られてきた気がするが、即捨てたな。

なんともったいない。どんな絵柄であろうとも、マグカップとしての機能には
何の問題もないというのに。

>>926
高水準で問題領域を絞ったDSLが開発される方向を想定してるのか
つまり処理系にできるだけ多くの情報を与えて、最適化をがんばらせると

実用上は、処理系がうまくやってくれないケースもあり得る以上は
抽象を破って低水準をプログラマが直接操作できるメカニズムが必要だと思うんだけどな
かといって、低水準から高水準まで幅広くサポートしようとすると
C++みたいな化け物になりかねない……

飲もうとする時に、その人の顔を見てしまう事で味が変化するとしたら損失だろう。
便所とかに置かれてるとかペット用になってるとかだとアレかもなw

プログラマが最適化出来るとも限らない訳で。

>>930
カップの絵柄で中身の味は変化しない。
貴方の主張は非論理的すぎます。

中身は変化しないが
味覚というのは脳が眼耳鼻舌身(触覚)意識を総動員して感じるものだから
見た目が変われば味が変わるということは非論理的なことでは決してない

うんこ食ってるときにカレーの話なんかするなよ

むしろ化学的な組成という客観量から味という主観的な概念が
一意に決まるという考えの方が非論理的

>>926
汎用言語を捨てるならいっそ汎用プロセッサも
諦めてしまえば…と思ったが、先祖帰りな気がするなあ

そういやjavaプロセッサってもう無いのかな？
ibmの汎用機とかはjava処理用のプロセッサ積めるらしいが。

専用言語が実行速度的には有利だろうけど、習得に時間がかかるので、既存の汎用言語で最適化したほうが、まだ有効だろうね。
全世界を専用言語の英語に統一したほうがコンピューティング処理が向上するから、日本語処理を諦めようというのを日本語で公演する矛盾を感じる。

Jazelleが使われているシーンを見たことが無い
いやどっかでは使われてたんだろうけど・・・

C言語の呪縛
http://techon.nikkeibp.co.jp/article/TOPCOL/20091209/178442/

この記事を思い出した。
理想はともかく現実的にはこういうアプローチも必要なんだろうね。

これからはErlangやScala、CCRのようなメッセージ伝達並列性が主流になる.

WindowsおよびはUnixでC++を使ってプログラミングしています。
4コアのCPUを使っていて、1スレッドのプログラムを実行したとき、
タスクマネージャで見ると使うコアが次々と変わっていくのですが
これを抑止する方法はありませんか？

Windows(Win32)ならsetThreadAffinityMask()

便乗で質問させて下さい。
スケジューリングから外して、このコアはこのプロセス(スレッド)専用だからねっ！！ってできますか？

そりゃ、無理だ。
DeviceDriverの挙動までは手が出せないからねぇ

>>939
Solaris では processor_bind(2) を使えば、スレッドを CPU に完全に貼付ける事が出来るよ。
同じ事をするコマンドで pbind(1M) というコマンドもあります。1スレッドのプログラムなら
コンテクストスイッチが無くなる分、性能も良くなります。

http://docs.sun.com/app/docs/doc/816-5167/processor-bind-2
http://docs.sun.com/app/docs/doc/816-5166/pbind-1m
http://developers.sun.com/solaris/articles/solaris_linux_app.html

>>941
Solaris では psrset(1M) コマンドで CPU のプールを作って、それをあるプロセス（スレッド）
だけに割り当てる事が出来るよ。psrset -f でその CPU がインタラプトを処理しない様にも
設定出来るから、デバイスドライバにも影響されず、ほぼ完全に CPU を占有出来ます。

http://docs.sun.com/app/docs/doc/816-5166/psrset-1m
http://developers.sun.com/solaris/articles/solaris_processor.html
http://docs.sun.com/app/docs/doc/816-5166/psradm-1m

>>943
うわーーー、知らなかった。
ありがとうございます。
Solarisなんて随分触ってなかったけど、ちょっとOpenSolarisでもいじってみます。

OpenMPで各スレッドをそれぞれのコアに貼り付けるにはどうしたらいいのでしょうか？
Linux、g++です。

http://pc12.2ch.net/test/read.cgi/tech/1102483474/
OpenMPプログラミング

あげ

Corei3なんですけどどうすればSSE2命令を並列に実行できますか？

GPUに汎用計算させたほうが行列演算は高速になりますか？

要はどうしたらいいんですか？

何をしたい訳？

それが判らないから聞いているんです。

ヲレには心当たりが無い。残念だったな。

まずは、パンツを脱ぐんだ

既にノーパンで全部剃ってるけどな。舐めても安全。

>>955
おいらの義妹はそんな下品なことは言わない。

マルチコアってマルチスレッドで効果があるみたいだけど
マルチプロセスだとどうなの？
windowsとかのバックグラウンドプロセスにも効果でてる？

>>957
M$のOSはしらんが、make -j<N> とかやるとちゃんと効いてるわな <Unix系OS

>>957
Windows のマルチプロセスは組みにくい。fork() にあたるものがない。
逆に、p-thread って誰得？と時々思う。

つまりですよ、マルチコアを意識して
マルチスレッドプログラミングをわざわざ書かなくても

常に他のプロセスにコアが割り当てられているから
アプリ側はふつうにシングルスレッドプログラムで
作れば十分なんじゃないかなーと思って聞いてみたわけです

十分かどうかは処理の内容によるでしょ。
スレッドの切り替えよりプロセスの切り替えの方がコストが掛かるし、
データの受け渡しも大掛かりになる。

ピクセル単位の画像処理なんかはスレッドを使うのが普通だろうし、
ウェブサーバとかなら I/O 待ちの時間が多いからマルチプロセスでも
良いんじゃねとか、そんな感じ。

不足すればHWを買い換えるなりすればいいから、好きな方で実装すればいい

マルチコアになったら関数型言語が主流になりますか？
でも、マルチコアにしてまで計算能力を向上させる意味ってあるんですか？
マルチコアになることのメリットが良く分かりません。
例えば、携帯電話とか、マルチコアになって何か凄いことができるようになったり
しますか？

>>963
>マルチコアになったら関数型言語が主流になりますか？

ならない。副作用が無いと並列度を抽出し易いとかは、絵に描いた餅。

>でも、マルチコアにしてまで計算能力を向上させる意味ってあるんですか？

あるよ。計算能力が上がれば今まで無かった様なプログラムが作れる様になったり、
プログラマが楽出来たりする。

>マルチコアになることのメリットが良く分かりません。

クロックを上げる方向の性能向上が頭打ちになったからマルチコアになったのであって、
シングルコアで性能が出せるならシングルコアの方が良かった。

>例えば、携帯電話とか、マルチコアになって何か凄いことができるようになったり
>しますか？

デュアルコアになると、レスポンスが向上したり、バックグラウンドでプロセスを動かし
続けたり出来て、分かり易い恩恵があるよ。マルチコアと言っても、携帯ならデュアルで
十分で、クアッドとかは要らないだろうね。

>>964
なるほど。
マルチコアの時代でもC++やJavaが主流のままなのでしょうか？

HPCの世界はもう既にマルチコアの時代だけど、C/C++ばかりだねぇ。

>>966
速さを重視する分野でC/C++を使うのは分かるんですが、生産性と両立させなければ
ならないような分野ではどうなんでしょうか？スレッド管理を手動で行う言語では、
大規模開発ではバグを誘発するような気がします

問題は、C/C++以外の言語をHPC用にチューンするコストを誰が掛けるかだな。

一応 Intel の TBB とかもあるけど、広範に受け入れられているかというとどうなんだろうね。

あ、C/C++ 以外の言語か。HPC は特殊な世界だから、カリカリにチューニング出来る
C や C++ が当分はのして行くと思うけどな。CPU 使用時間単位で課金されたら、
誰でもそうすると思われ。

行列の計算ですが高速化する方法ありますか？
for(j=0;j<16;j++){
o=FG[a[j]]^FG[u1.m[j]];
p=FG[b[j]]^FG[u.m[j]];

for(i=0;i<16;i++){
d1[j]^=t[o][h1[p][i]];
d2[j]^=t[o][h2[p][i]];
}
buf[j]=d1[j];
buf[j+16]=d2[j];
}

なるほど。まずは質問を投機的にマルチスレッド化したわけですね。

ワロタw

ダメだこりゃ。

>>971
フォートランで書くといいと思うよ

根拠は？

並列構文使えば勝手に並列化してくれる

それが最適化されてるか検証が面倒。

hpc用にcで最適化するってのもなんだかなあと思う。
そこまでして性能出さないと予算取りにくいほど不景気なんだろうけど。
電気自動車の性能を上げる為にマイコン積まずにフルマニュアル化しましたみたいなもので。

違うな。要求性能が決まっているとしたら、pc100台要るところを1%高速化すれば1台減らせるんだよ。
1台じゃ高が知れているけど、それが10%で10台となればそれを達成するための人件費を設備費が上回ってくる。

でもその為に本来の研究者の利用者がc覚えたり最適化手法を覚えたりって、研究が停滞するだけだと思うけど。
まあ実際は助手とかに丸投げして助手がhpc使いこなすのに膨大な労力と時間を浪費してるだけだとは思うが。

んなもん、研究者が書いたものをSIerに高速化させるんだよ。
研究者が直接最終版までコーディングするなんてどんな低予算研究なんだ?

>>981
論文読むなりして、研究者が書いたものを高速化できるほど、頭のいい人間を
抱えているSIerは稀にしかない

SIerって土方の集まりだろ

歳三?

SIerは土方を丸投げするだけだから、知識はさらにない。
逆に今日びコードの書けない研究者はいらない子。

歳三?

肘肩腰。神速三段腹