アカウント名:
パスワード:
マルチスレッド対応のマルチコアCPUはシングルコアのCPUと比べて価格とか消費電力に違いは無いのでしょうかね。
原価が上がると数が出る製品には使いにくいし、消費電力が上がるとバッテリの持ちが悪くなるし。買うほうとしては安くて長持ちするほうがありがたいものも多いのではないかと。
マルチコアって逆に、消費電力の**改善**に貢献したりする
私のやった範囲だと考えにくいです。
ほとんどのタスクは消費電力や応答速度の維持のためにすぐにスリープさせます。スリープしているので消費電力的には影響は無いと思いますが、スリープしているコアが増えたからといってありがたいことは特にありません。
ビジーな処理をしていても一つコアが空いていれば応答速度を維持できるのでその点ではメリットがあります。しかし、現状ではビジーな処理は専用ロジックに回してしまうのでコアが増えてもやっぱり影響が少ないです。つまり非対称マルチプロセサになっています。
専用コアだとチップの数が多すぎる、という場合ではマルチコアのSMP構成もありかもしれませんが汎用コアの性能と専用コアの性能とでは大違いなので、専用コアを置き換えるにはまだ性能が足りません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
プログラミング言語の選択 (スコア:4, すばらしい洞察)
それに何よりプログラマの習熟度、そういうしがらみで決まるもんでしょう。
そんなに簡単にスイッチできるものなら、いまやWindowsアプリの半分ぐらいは
並列化言語とやらで書かれていてもおかしくないはずなのに、そんな話は聞かない。
ましてより制約の厳しい組み込み業界ならなおさら。
ソレを動かすこと自体が仕事ならともかく。
リンク先より
>同氏は、「組み込み機器のソフトウエア開発者は、高レベルな複数のプログラムやモジュールをマルチコア・プロセッサで単に別々に動作させることで、並列プログラミング言語への移行に伴う苦労を避けようとしている」とソフトウエア開発者の現状の姿勢を批判した。
何様? って感じ。
お前がその苦労のコストを払ってくれるのかと。
Re:プログラミング言語の選択 (スコア:4, すばらしい洞察)
ハードを売りたい人がやってる釣りだと思うよ。熱くなっちゃダメ。
マルチスレッドへの対応は時流の流れで仕方の無いことだけど、
パラダイムの大変更なわけだから、焦ってやったって不安定なものが
できて不幸な人が増えるだけ。じっくり腰を据えてやりましょう。
Re:プログラミング言語の選択 (スコア:5, 興味深い)
マルチスレッド万能伝説みたいに、マルチスレッド当たり前の世界観があるのは理解します。
PCやWSの世界では、CPU数を変化させて、性能のスケールUPを目指すわけですから、
マルチスレッドの極地だとおもうんですよ。
しかしメニーコアなCPUを複数個乗せたりすると、カーネルがスレッドスケジューリングの際
キャッシュコーヒーレントなどを考え、どのコアに配置するかを動的に悩みだすわけで。
じゃ、組み込み世界で、この「動的な悩み」を解決するコストが妥当か?
シングルコアのマルチスレッドのような並行処理は重要かもしれないけど
(というか、適度な並行処理がないと設計モデルが破綻すると思う)
じゃ、メニーコアなCPUでどこにどの機能を担当するスレッド・タスクをマッピングするかを
動的に悩むのか?これが問題と思う。
そもそも「動画処理」と「音声処理」はこのコア、「UI処理」はこのコアと静的に割り振るのが
妥当なときもあると思う。
対称マルチプロセッサは、ある意味正しいと思うけど、それを実現する動的コストが妥当かどうか
だと思います。非対称マルチプロセッサ(ASMP)がある意味解なわけで、そうなると並列処理言語より
ASMP支援ライブラリだとおもうんですよ。
Re:プログラミング言語の選択 (スコア:1, 興味深い)
並行(concurrent)と並列(parallel)は意味が違ことはきっとご存じだと思う。
で、訳文を見てみると 並列 としつこく書いてある。
え? 組み込みで 並列 なの?
と思って、原文を探してみた。
たぶん、これ
http://www.eetimes.com/showArticle.jhtml;jsessionid=AG5UTXCIMCYGAQSNDL... [eetimes.com]
やっぱ、 parallel と書いてある。
結論:
コレはスレッディング以上の恐ろしいことについて、さらっと流している戦慄すべき記事のようです。
我々がスレッドで書いているような粒度の問題を気にしているわけではなさそうな...
という続きは、明日羽田空港で(もし私の知っている人なら。違ってたらスンマセン)。
Re:プログラミング言語の選択 (スコア:0)
ちなみにその場合、スレッド(と呼ぶならば)はどう静的に割り当てるのが吉なんでしょうか?
スレッドの数は固定で、それぞれをもちろん静的に各コアに割り当て、各スレッドがそれぞれ仕事をするんでしょうか?
でもそれだといわゆるマルチスレッド的な処理が欲しくなったらちょっと困りそう。
スレッドの生成は動的だけど、そのスレッドをどのコアに割り当てるかを「処理の種類」か何かで決めるのだと事前に決めておく、という感じでしょうか?
Re:プログラミング言語の選択 (スコア:0)
プロセッサの特性とリンクしたスレッドプールを作ればよさそうに思います。
このスレッドプールに突っ込むと動画、音声処理用とか、
このスレッドプールは暗号化処理用とか。
JavaとかC#のような中間表現を使う言語の場合、
実行時にスレッドプール特性に応じてJITコンパイルしてくれるとうれしいですね。
組み込みだと無理でしょうから、事前に各スレッドプール用にインストラクションをチューニングしとくとか。
Re:プログラミング言語の選択 (スコア:1)
マルチスレッド対応のマルチコアCPUはシングルコアのCPUと比べて価格とか消費電力に違いは無いのでしょうかね。
原価が上がると数が出る製品には使いにくいし、消費電力が上がるとバッテリの持ちが悪くなるし。買うほうとしては安くて長持ちするほうがありがたいものも多いのではないかと。
Re:プログラミング言語の選択 (スコア:0)
判ってない者の素朴な質問ですみません。
マルチコアって逆に、消費電力の**改善**に貢献したりすることは無い(ありえない)ものなんでしょうか?
単純に馬鹿食い方向にしかならないなら、そりゃ組み込み業界からマルチコアは一掃粛清されるべきですが、奴らもそこまで馬鹿じゃないでしょうから、なんか良い面もある(という実装も有る)んだったりしないんでしょうか。
Re:プログラミング言語の選択 (スコア:4, 興味深い)
私のやった範囲だと考えにくいです。
ほとんどのタスクは消費電力や応答速度の維持のためにすぐにスリープさせます。スリープしているので消費電力的には影響は無いと思いますが、スリープしているコアが増えたからといってありがたいことは特にありません。
ビジーな処理をしていても一つコアが空いていれば応答速度を維持できるのでその点ではメリットがあります。しかし、現状ではビジーな処理は専用ロジックに回してしまうのでコアが増えてもやっぱり影響が少ないです。つまり非対称マルチプロセサになっています。
専用コアだとチップの数が多すぎる、という場合ではマルチコアのSMP構成もありかもしれませんが汎用コアの性能と専用コアの性能とでは大違いなので、専用コアを置き換えるにはまだ性能が足りません。
Re:プログラミング言語の選択 (スコア:1, 参考になる)
Re:プログラミング言語の選択 (スコア:1, すばらしい洞察)
遠大すぎると地に足が着かないが、近視眼的すぎてもダメってことだろう。数年後に後塵を拝するかどうかは、現在の努力に掛かっているわけで、まあ、実際にその手法を学ぶかどうかはともかく、投資先の一つと考えるのは悪くないと思う。
Re:プログラミング言語の選択 (スコア:3, 参考になる)
それをするためのハードウェアのコストを払ってくれるならな。コストをハードウェアに乗せるかソフトウェアに乗せるかはどのくらい数を出すつもりなのかとかの外部的な要因に左右されるので単に速いとか遅いとかで決定できるようなもんじゃない。それに、その方法で実行時間が一定に収まる事を保証できるかい? 演算性能を犠牲にしてもそれが必要な用途もあるんだよ? まーまずは演算速度だけが性能じゃないんだって事をわかれ。
Re:プログラミング言語の選択 (スコア:1, すばらしい洞察)
世の中の組み込みには、炊飯ジャー起動から、リアルタイムエンコーディングまであるんだから、最初から切り捨ててるような思考しかできないんだったら、関わりができるはずもないだろう。組み込み機器でももっと性能が欲しい場合はいくらでもあるんだから、自分が想像できないからって、頭ごなし「わかれ」ってのはねぇ。
誤った使い方 (スコア:0)
コアの1つをそのプロセスに占有させる、みたいな使い方をしたいです。
OSが提供するスケジューリングのしくみをきちっと使いこなせればそんなことす
る必要はないのですが、いかんせんみんなでよってたかって設計すると、スケジュー
リングに対する考慮が甘い人(プロセス)が1人いるだけで、他の人(プロセス)がみ
んな痛いめに合うので辛いです。。。