Green Hills Software [ghs.com]はリアルタイムOSを前面に出している会社のようです。 Wind River [windriver.com]はVxWorksで有名な会社です。Linuxカーネル2.6.x＋αの販売も行っているようです。 Virtutech [virtutech.com]は組み込み用開発ツールの会社でしょうか？ Venture Development [vdc-corp.com]は元記事にあるように市場調査会社のようです。 元記事によれば、これらの会社のお偉いさんとかが「これからもC言語が使われるだろう」と言っているとのことです。
それに対して、Rick Merritt：EE Times は、Venture DevelopmentのEric Heikkila氏の発言「並列プログラミング言語が主流になる見込みはない」に文脈的につながっている次の段落で、以下のように書いています。
プログラミング言語の選択 (スコア:4, すばらしい洞察)
それに何よりプログラマの習熟度、そういうしがらみで決まるもんでしょう。
そんなに簡単にスイッチできるものなら、いまやWindowsアプリの半分ぐらいは
並列化言語とやらで書かれていてもおかしくないはずなのに、そんな話は聞かない。
ましてより制約の厳しい組み込み業界ならなおさら。
ソレを動かすこと自体が仕事ならともかく。
リンク先より
>同氏は、「組み込み機器のソフトウエア開発者は、高レベルな複数のプログラムやモジュールをマルチコア・プロセッサで単に別々に動作させることで、並列プログラミング言語への移行に伴う苦労を避けようとしている」とソフトウエア開発者の現状の姿勢を批判した。
何様? って感じ。
お前がその苦労のコストを払ってくれるのかと。
Re:プログラミング言語の選択 (スコア:4, すばらしい洞察)
ハードを売りたい人がやってる釣りだと思うよ。熱くなっちゃダメ。
マルチスレッドへの対応は時流の流れで仕方の無いことだけど、
パラダイムの大変更なわけだから、焦ってやったって不安定なものが
できて不幸な人が増えるだけ。じっくり腰を据えてやりましょう。
Re:プログラミング言語の選択 (スコア:5, 興味深い)
マルチスレッド万能伝説みたいに、マルチスレッド当たり前の世界観があるのは理解します。
ＰＣやＷＳの世界では、ＣＰＵ数を変化させて、性能のスケールＵＰを目指すわけですから、
マルチスレッドの極地だとおもうんですよ。
しかしメニーコアなＣＰＵを複数個乗せたりすると、カーネルがスレッドスケジューリングの際
キャッシュコーヒーレントなどを考え、どのコアに配置するかを動的に悩みだすわけで。
じゃ、組み込み世界で、この「動的な悩み」を解決するコストが妥当か？
シングルコアのマルチスレッドのような並行処理は重要かもしれないけど
（というか、適度な並行処理がないと設計モデルが破綻すると思う）
じゃ、メニーコアなＣＰＵでどこにどの機能を担当するスレッド・タスクをマッピングするかを
動的に悩むのか？これが問題と思う。
そもそも「動画処理」と「音声処理」はこのコア、「ＵＩ処理」はこのコアと静的に割り振るのが
妥当なときもあると思う。
対称マルチプロセッサは、ある意味正しいと思うけど、それを実現する動的コストが妥当かどうか
だと思います。非対称マルチプロセッサ（ＡＳＭＰ）がある意味解なわけで、そうなると並列処理言語より
ＡＳＭＰ支援ライブラリだとおもうんですよ。
Re:プログラミング言語の選択 (スコア:1, 興味深い)
並行(concurrent）と並列（parallel）は意味が違ことはきっとご存じだと思う。
で、訳文を見てみると 並列 としつこく書いてある。
え？ 組み込みで 並列 なの？
と思って、原文を探してみた。
たぶん、これ
http://www.eetimes.com/showArticle.jhtml;jsessionid=AG5UTXCIMCYGAQSNDL... [eetimes.com]
やっぱ、 parallel と書いてある。
結論：
コレはスレッディング以上の恐ろしいことについて、さらっと流している戦慄すべき記事のようです。
我々がスレッドで書いているような粒度の問題を気にしているわけではなさそうな...
という続きは、明日羽田空港で（もし私の知っている人なら。違ってたらスンマセン）。
Re:プログラミング言語の選択 (スコア:1)
マルチスレッド対応のマルチコアCPUはシングルコアのCPUと比べて価格とか消費電力に違いは無いのでしょうかね。
原価が上がると数が出る製品には使いにくいし、消費電力が上がるとバッテリの持ちが悪くなるし。買うほうとしては安くて長持ちするほうがありがたいものも多いのではないかと。
Re:プログラミング言語の選択 (スコア:4, 興味深い)
私のやった範囲だと考えにくいです。
ほとんどのタスクは消費電力や応答速度の維持のためにすぐにスリープさせます。スリープしているので消費電力的には影響は無いと思いますが、スリープしているコアが増えたからといってありがたいことは特にありません。
ビジーな処理をしていても一つコアが空いていれば応答速度を維持できるのでその点ではメリットがあります。しかし、現状ではビジーな処理は専用ロジックに回してしまうのでコアが増えてもやっぱり影響が少ないです。つまり非対称マルチプロセサになっています。
専用コアだとチップの数が多すぎる、という場合ではマルチコアのSMP構成もありかもしれませんが汎用コアの性能と専用コアの性能とでは大違いなので、専用コアを置き換えるにはまだ性能が足りません。
Re:プログラミング言語の選択 (スコア:1, 参考になる)
Re:プログラミング言語の選択 (スコア:1, すばらしい洞察)
遠大すぎると地に足が着かないが、近視眼的すぎてもダメってことだろう。数年後に後塵を拝するかどうかは、現在の努力に掛かっているわけで、まあ、実際にその手法を学ぶかどうかはともかく、投資先の一つと考えるのは悪くないと思う。
Re:プログラミング言語の選択 (スコア:3, 参考になる)
それをするためのハードウェアのコストを払ってくれるならな。コストをハードウェアに乗せるかソフトウェアに乗せるかはどのくらい数を出すつもりなのかとかの外部的な要因に左右されるので単に速いとか遅いとかで決定できるようなもんじゃない。それに、その方法で実行時間が一定に収まる事を保証できるかい? 演算性能を犠牲にしてもそれが必要な用途もあるんだよ? まーまずは演算速度だけが性能じゃないんだって事をわかれ。
Re:プログラミング言語の選択 (スコア:1, すばらしい洞察)
世の中の組み込みには、炊飯ジャー起動から、リアルタイムエンコーディングまであるんだから、最初から切り捨ててるような思考しかできないんだったら、関わりができるはずもないだろう。組み込み機器でももっと性能が欲しい場合はいくらでもあるんだから、自分が想像できないからって、頭ごなし「わかれ」ってのはねぇ。
1個でも大変なのに (スコア:4, 興味深い)
ちょうどマルチコアではないけど、マルチプロセッサのシステムで開発を追えたばかりなのでIDで愚痴っぽく。
この２、３年位で、組込みの世界でもようやくLinuxがまともに使えるようになってきて、
その共通プラットフォームとしての利点を活かして
PCで先考開発して、とか、別の基板向けので開発した資産を流用、なんてことが
ほんとにようやくできるようになってきたところ、と感じています。（あくまで自分の回りの話ですが）
マルチコアの件もそういう環境（開発環境、諸々の気運）が整ってようやく、なんでしょうね。
Re:1個でも大変なのに (スコア:3, 興味深い)
> そういう環境（開発環境、諸々の気運）
この一節にひかれてここに。
こういうのって（新しいハードを売り込みたいハード屋さんの強力なバックアップを得て）採算よりも新進性を取れる体力（と赤字回収を見込めるだけの能力）があるトコが何か凄いことをやって、アンテナ伸ばしている人から順に「俺もやってみてぇな」ってなって、手軽に試せる環境が出てきて、それではじめてちらほらと導入されていくもんなんじゃないかと思います。
お客さんが一斉にパッと変わってくれることを期待してちゃ商売になりませんよ。
# ならば今すぐ愚民どもすべてに英知を授けｔ(ry
Re:1個でも大変なのに (スコア:2, すばらしい洞察)
その「手間」を減らすためにこそ並列処理型言語どうよ？という話なんだと思う。それ自体は理屈の上ではTRUEなのは間違いないでしょう。
だから逆にいえば、論点とすべきは、そいつの言い分が「額面どおり」なのかどうか？って点だと思う。
並列プログラミング言語って何？ (スコア:3, おもしろおかしい)
ふつーDSPつんだりASIC起こしたりする (スコア:3, 参考になる)
H8クラスの遅いマイコンとTIとかのDSPとかがコスト的に現実的な設計だったりするけどね
あ最近C++使うためにSHに転びました。
てか組み込み系っていうけど少なくともわたしの周辺は製品の数だけ選択するCPU違うので
マルチコアって紋切り型にいわれてもなんとも賛同できませんね。
「携帯電話」とかだと同じプラットフォームを延々つかうんだっけ。ふーんてなかんじ
本末転倒になってはいかん (スコア:3, すばらしい洞察)
並列化言語が必要な状況がある場合に並列化言語への要求が生まれるのだが、
単にマルチなCPUを使っているだけで並列化言語を使おうとするのは
組み込み機器の安定性を阻害するだけの話だ。
安定し、かつ、使いやすい並列化言語があるなら使ってもいいかもしれないが、
そうでないのであれば並列化言語なんてのは無用の長物。
組み込み機器向けマルチコア・プロセッサやその手の開発環境を売りたいだけの
セールストークに惑わされず、実質を見極めてこそ安定した機器を送り出せる
エンジニアと言えよう。
C/C++を使う理由って (スコア:3, 興味深い)
そのリッチな支援のために、実行時にハードウェアリソース（ＣＰＵ・メモリ・電力）を支払っていると思う。
対価として開発のしやすさを得ているのでしょう。
＃いわゆる等価交換の原理ってやつ？（ハガレンの見すぎ）
じゃ、その対価を払うと、借金をしないといけない環境だったら、C/C++を使うわけで。
Cって、マクロアセンブラ , C++ って高級オブジェクト指向マクロアセンブラと考えられる
くらい、ハードウェア密着型言語だとおもう。
だからといって、C / C++ を擁護しているわけじゃなく、適材適所ってだけだと思う。
新しい環境がそろい、そのプラットフォームがそろえば、新しい環境に移ってくれても
全然問題ないわけで、逆にブレークスルーの為に環境移行が必要であれば積極的に行わないと。
で、並列処理言語をいれると、どんなブレークスルーが起こるんでしょうか？
現在の2桁くらいかわる性能がだせるとか？
現在の2桁くらい電力消費量が減るのとか？
組み込みに並列化言語が必要かどうか以前に (スコア:3, すばらしい洞察)
いて技術的な話をすることが困難なのかもしれない。
組み込み機器を規模や用途によって明確に分類するような工業規格
が登場すれば、組み込み機器の設計に関する技術ももっと整理され
るのかもしれない。
ここらへんも使われるようになるか? (スコア:2)
テラスケールコンピューティングのための言語「Ct」 [impress.co.jp]
コンパイラ/ライブラリを上手く移植できれば動くかねぇ
# 知識にまったく自信がない(汗
M-FalconSky (暑いか寒い)
Re:ここらへんも使われるようになるか? (スコア:4, 参考になる)
# 最近CSPについてちょっとかじったので、たまたま知ってた
選択肢 (スコア:2, 興味深い)
開発言語として、アーキテクチャによってはアセンブリ言語かC/C++言語しかないので仕方なくC/C++言語を使っているという人がほとんどだと思う。
Re:選択肢 (スコア:2, 興味深い)
お願いです。他の言語にするのはやめて。
「特定の動作のときにメモリが化ける」とか「この評価ボードだけ動作がおかしい」とか難癖
つけられてＣコンパイラが吐き出したコードまで追い回して調査させられるハード屋なので。
（ソースのバグ、コンパイラのバグ、・・・そんなんばっかですが）
ただ、量産を始めるとｐｐｍのオーダーではあるものの、本当にメモリ化けするチップがでる
ことがあるから疑われる・・・。
＃Ｊａｖａにしてくれればポインタバグは無くなって平和になれるかな・・？
追い回せなくなるけど・・。
やっと時代が追いついたぞ！ (スコア:2, おもしろおかしい)
つPIM/KL1 [wikipedia.org]
元記事を別の方面からまとめてみた (スコア:2, 参考になる)
Wind River [windriver.com]はVxWorksで有名な会社です。Linuxカーネル2.6.x＋αの販売も行っているようです。
Virtutech [virtutech.com]は組み込み用開発ツールの会社でしょうか？
Venture Development [vdc-corp.com]は元記事にあるように市場調査会社のようです。
元記事によれば、これらの会社のお偉いさんとかが「これからもC言語が使われるだろう」と言っているとのことです。
それに対して、Rick Merritt：EE Times は、Venture DevelopmentのEric Heikkila氏の発言「並列プログラミング言語が主流になる見込みはない」に文脈的につながっている次の段落で、以下のように書いています。
EE TimesのRick Merrittさんは、チャレンジングスピリットを持った熱い人なのかもしれませんが、少し変ですね。
今はマルチコア対応よりもっと重要なこと(価格とか納期とか)があるわけで、マルチコアの必要性があればみんなやると思います。
# 並列プログラミングと聞いて、遥か昔のSeeNa 88版がFDDにも演算させていたらしいという話を思い出しました。
てか組み込みにプログラミングパラダイムって２次的 (スコア:2, 興味深い)
ASICやFPGAの部品代をケチるために姑息なこんなことはしないリアルタイム処理作ったりとか割り込みが足りなくなって外に変な論理回路組んで自前割り込み共有作ったりとかというところに
組み込みプログラミングの醍醐味ってはあると思いますね。というかプログラミングパラダイム以前にエネルギーを注ぎ込むところです。結果部品代が100円下がるというような世界です。
民意が低いっていわれようがこれが現実。すべて現場対応。
並列化言語とは？ (スコア:1)
逆行列の計算は、並列処理ができるけど、コンパイラがそうできるようにするところを見ると、
最初から並列処理できるとわかっているものはコンパイラで処理すればよい。
並列化言語って、コンパイラが並列処理をするかどうか判断するような言語のことではないですよね？
Re:並列化言語とは？ (スコア:1)
「並列化コンパイラ」と呼ばれる物はあるけど、さすがに勝手に並列性を
抽出するのは無理。「この部分を並列化してね」という指示をコンパイラに
与えると、後の処理は自動的にやってくれるというだけ。
Intelのコンパイラとかがやってくれるというのは命令レベル並列化を
支援する程度じゃないの？
Re:並列化言語とは？ (スコア:2, 参考になる)
インテルコンパイラー自動並列化ガイド(PDF) [intel.com]
もちろん、OpenMPの記述で「この部分を並列化してね」という指示をコンパイラに与えることもできますが。
ユビキタスはムリ目？ (スコア:1)
…残念なりよ。
Re:ユビキタスはムリ目？ (スコア:2, すばらしい洞察)
設計思想が間違ってる (スコア:1, すばらしい洞察)
並列は個々は干渉せず全体で緩やかに統合するような処理内容であり
いちプログラムで統合しようとするものではありません
もし並列かしたコンピュータを設計するなら
プログラムの処理が速くも遅くもならないで処理する作りでしょうね
それでバラバラ動かすと、パソコンではない気がするが
そんな所だろ
マルチコアへ移行する理由 (スコア:1, 興味深い)
私が知るものの多くは複数のチップを使っていた機能を、
ひとつのチップに集約してコストダウンというのもばかりでした。
そこに並列プログラミング言語が普及する余地はあるでしょうか？
ホント、フレームの元だね (スコア:2, すばらしい洞察)
仮にそれで本当に生産性が高かったとしても、優れているのはLL言語
（の開発者）であって、それを利用しているだけの利用者ではないでしょう。
むしろJavaScriptやPHPしか使えない人の技術力が最低な場合の
方が多いと思う。本当に動くだけの最低なコードを書く人というのは
実在するんですよ。
Re:ホント、フレームの元だね (スコア:2, おもしろおかしい)
#include<stdio.h>
int main(){
return 0;
}
こうですか！？わかりません！
Re:ホント、フレームの元だね (スコア:1, おもしろおかしい)
>#include<stdio.h>
不要なコードを書くってところが「最低なコード」なんですね。
Re:そんなのまだまだ (スコア:2, おもしろおかしい)
書いて来たアイツのことかぁぁぁぁぁ！
Re:そんなのまだまだ (スコア:2, 興味深い)
実に気合の入ったコードなら納品された事があります。
wild wild computing
Re:ホント、フレームの元だね (スコア:2, 興味深い)
>後者の方が何倍も偉い。
それは比較対照が間違っている。
「奇麗だし動くコード」と「（汚いけれど）動くだけのコード」を比較すべき。
動かないコードを作る奴や、動くだけのコードを作る奴はどちらもプロ失格。
日本だと「綺麗で且つ動くコード」を作れるプログラマが絶滅しかけてるらしい
けどね。だからと言って、動くだけのコードを納品する奴もプロ失格だろ。
>完璧主義性こそが、ソフトウェアの分野で日本がアメリカに負けている理由だと思う。
そんなもの完璧主義とは言わないよ。
綺麗で且つ動くコードも作れないようなプロ失格の奴の見苦しい言い訳に過ぎない。
Re:ホント、時代遅れだよね (スコア:2, 興味深い)
総合的な技術力の高いWEBプログラマならあっという間だろうね。
Re:ホント、時代遅れだよね (スコア:1)
「そのくらい普通じゃないですか.」と言うと, 「自分のレベルで仕事の難易度を考えてはいけない.」と怒られた新人時代.
積み木の上で踊ってるだけのヤツが何言ってんだか (スコア:2, すばらしい洞察)
最終目的のそばにある歯車が、自分は一山で大きな仕事をこなせるからと下の歯車を笑うか、
エンジンのすぐそばの超高速回転に耐えてる歯車が、上のゆっくり回ってる歯車を笑うか、
そんだけの話です。
つーか、高効率マクロアセンブラでしかないC言語はもうイヤじゃ。
設計のダメダメさ加減が如実なC++ももうイヤじゃ。
もうちょっとモダンな思想をもった、ネイティブコードを吐く処理系を切実に願ってるのはホントよ...
Re:ホント、時代遅れだよね (スコア:1, 興味深い)
それこそ業務系（IT系）とかWeb系ならLL言語だのフレームワークだの次から次に方法論とかツールとか言語とか出てきているけど、組み込みはずっとアセンブラ、C/C++がメイン。Javaとかも多少はあるみたいだけど…周りじゃ聞かない。
この世界で長く仕事してると「違う仕事に行くことになったら潰しが効かなくなってるんじゃ」っていう不安をいつも抱えているよ。もちろん、自分はそうなるのがイヤなのでいろいろLL系言語とかWeb系とか手を出したりしてせいぜい足掻いているけども。
エンジニアの生涯としていつまでもずっと同じような仕事（ハードに近いドライバ屋とか）ができるなら、組み込み系でも経験を積むことで「職人」になり得るかもしれないけど、下請けSIerのような、いつ別の分野の仕事に回されるかという状況だと、組み込みをずっとやっていると漠然とした「取り残されてるんじゃないか感」を感じるように思う。
進化進化って言うけど、別に進化してないよ？ (スコア:2, すばらしい洞察)
アレも枯れた技術をうまい事組み合わせて新しく見せているだけだし。
理論は既に出来上がっていて時代がそれに追いついてきたって感じかなぁ。
昔は馬鹿みたいにリソースを無駄使い出来たわけじゃないから。
というか、全体的にハードの性能アップがソフトの性能アップを超えてるからそう感じるのでは？
以前と立場が逆転してますな。
組み込み系も(昔に比べたら)「進化」が早くなっていると感じるんだけど、それは自分がWeb系だからかな？
-----
＃他人のプログラムは青い
Re:ホント、時代遅れだよね (スコア:1, 参考になる)
組み込みはハードウェアがある程度自由に組めるので
機能ごとに専用ICを割り当てることが多いというだけ。
オブジェクト指向なのですよ。
私が高価なマルチコアCPU使うとしたら、たぶんそれは
部品の実装面積に困が足りなくてどうしようもない時だと思う
適材適所（Re:ホント、時代遅れだよね） (スコア:1, 参考になる)
しかも機械のリソースが非常に限られていて、サーバやパソコンのように湯水のようにCPUやメモリ・ストレージなどを投入できる場合は殆ど無い。
UIがたくさんあるようなアプリとかの層でもリソース的にかつかつの状況で可能な限り多機能に…と言うのが最近の風潮ですから、営業サイドの要求するものと「出来ること」に差がありすぎる場合も少なくない。
それに、最近はGNU/Linuxベースのシステムや組み込みWindowsベースのシステムが電脳家電でも多くはなりましたが、それでも組み込み機器の場合には本当に重要な機能のリアルタイム性が最優先だし、ハードウェアとも密着した部分が多いですし。
ましてや車とかの制御とか小さな機械のファームとかなると…WEBプログラマとはまったく違う方向での「レベルの高さ」が必要になる訳で、どれがレベル高いとは言えないですよ。
# とは言え、計算機工学や電子工学の基礎も理解しないで設計書や仕様書出す顧客が多くなってて、
# それに対して問題点を挙げたりバグ潰す時に改悪したのに気づかないで商品化しようとしてデスマーチに
# はまってしまうプログラマが（逆に言うと基礎の部分と勉強する心構えあたりがダメなのに
# 職業プログラマやってる人が）組み込みでさえ多くなってきているのも事実…
で、基本的にスクリプト言語はリソースを猛烈に喰うコードを安易に作ってしまう傾向があるので（と言うか「とにかく動いた」って辺りで出して品質管理もパスする場合が多いですから）ソフト作る側からだけでなくハードウェアを作る側からも嫌われる場合が多い様です。
うまく使えばスクリプト言語の方がデバッグとか楽でリソースもそんなに喰わなくて済む部分も結構あるので（特に見た目とか）一長一短ではありますが。
それと、組み込みやってる人は基本的に「枯れた」技術を好みます。あくまでも「基本的に」ですが。
少し前まではCのみでC++もちょっとなぁ…と言う場合が多かったですが、最近はリソースやクロスコンパイラがマトモになってきたのでC++もよく使われるようになってきたようですし、インタプリタ系の環境でも組み込みに特化したランタイムやバイトコード実行前提のOS環境とそれに見合った計算機資源を安価に提供できる状況が出てきたのでバイトコードインタプリタであるJavaとかも普通に使われるようになって来ましたが…
Re:ホント、時代遅れだよね (スコア:1, すばらしい洞察)
Re:ホント、時代遅れだよね (スコア:1)
Re:ホント、時代遅れだよね (スコア:1)
署名スパムがウザい？アカウント作って非表示に設定すればスッキリさ。
Re:ホント、時代遅れだよね（フレームのもと:-1） (スコア:2)
日本語は読み手に知性と察しを要求するんだよ。
俳句や川柳にでも突っ込んでろ。
Re:組込み系の人って (スコア:2, すばらしい洞察)