アカウント名:
パスワード:
プリンタのレンダラ、携帯内蔵アプリ、NASサーバ、3DCGボード、BIOS…うーむやはり組み込みなのかなぁ。確かにアプリ系はあまりやっていないような気がする。つーかそんなに長時間かけていない気がする。チップセットとCPUとコンパイラの気持ちがわからない奴なんかプログラマじゃない、と思ってるしなぁ。
でも、力でコーディングするのも、プログラマとは呼べないと思ってるものなぁ。「力でコーディングするプログラムを書くのだ。そう考えない奴は、キーボードの付属品だ!」とか平気で言うしなぁ。
かといって、「フレームワーク? 他人が作ったフレームワークなんぞゴミだ。フレームワークは、プロジェクトごとに練り上げていく楽しみの一部じゃないか。それを他人任せにしてどうする!!」と言う発想は明らかに IT 系じゃないしなぁ。
.
まぁ、「クラウドコンピューターなんて大きな組み込みマシンだよ」と考えれば、組み込み系無敵って事で。
チップセットとCPUとコンパイラの気持ちがわからない奴なんかプログラマじゃない、と思ってるしなぁ。
かといって、 「フレームワーク? 他人が作ったフレームワークなんぞゴミだ。フレームワークは、プロジェクトごとに練り上げていく楽しみの一部じゃないか。それを他人任せにしてどうする!!」 と言う発想は明らかに IT 系じゃないしなぁ。
たしかに、組み込み系の場合、リアルタイム性への要求や信頼性確保の関連でITに比べてブラックボックスを嫌うことが多いかもしれません。 自分のしらない所で何かやっているのが嫌というか。 だから、Cであっても生成されるであろうアセンブラを意識してしまうのですよね。
自分のしらない所で何かやっているのが嫌というか。だから、Cであっても生成されるであろうアセンブラを意識してしまうのですよね。
もし、それが組み込み系技術者が生成されるアセンブラを意識する理由だとするなら、そこは私は違いますね。
私が「コンパイラの気持ちがわかる」といった場合、それは『コンパイラにとって、どれとどれが同じ内容で、どれとどれは違う内容なのか』を意識する、という事です。
一例ですが…最近は少ないでしょうが、昔の大抵のコンパイラは
a = x ? y : z;
と
if ( x ) { a = y;} else { a = z;}
を同じと見なす能力がありませんでした。それぞれに対応する中間コードがあって、それ故にその後の最適化が変わる。で、ごく初期のコンパイラを除いて、三項演算子の方が一般には『効率が悪い』コードを出したのです。gccが始めてこの2つを完全同一視してくれたときは感動したものです。
「同じ内容であってもどう書くかで最適化は変わる」ので、「コンパイラにとって判りやすい書き方」「不明瞭な点がなるべく少ない書き方」という2つの条件を満たした方がコードは早くなりますし、コンパイラが進化したときにコードを書き直す必要性も減るのです。
厄介なのは「不明瞭な点がなるべく少ない書き方」という奴でして。「不明瞭な点」があると、コンパイラは最適化を諦めて安全サイドに出力を倒す必要があります。
言語規格上は別にそうしなくてもよい、という理由で gcc が安全サイドに倒さなかったために起こったバグの例としては Linux kernel 2.6.30 と 2.6.30.1 にだけある、セキュリティホールがあります。http://kenichiokuyama.blogspot.com/2009/07/linux-kernel-zero-day-explo... [blogspot.com]に説明を書いておきましたので内容に関してはそちらを見ていただくとして。ようするに、こういう問題が起こるので、コンパイラは「最適化をかけてよい条件」をかなり厳しく設定する必要がある。
わかりづらいコードを書くと、人間だけでなくコンパイラも「最適化をかけてよいかどうか」の判断に手間取ります。あまりにも最適化条件に合致しているかどうかの判断がかけずらい場合、コンパイラは「そのコードに、この最適化は適用しない」という判断を下す可能性がある。コンパイラ自身が使えるメモリも、CPUパワーも限界がありますからね。せっかく「早くなるに違いない」と思って駆使したコーディングテクニックが、コンパイラの最適化対象外になったために効率が相殺されてむしろ遅くなるのでは意味がありません。
また、逆にコンパイラの最適化適用規則が甘いとバグの元になる。
それらを可能な限り排除した書き方で書かれたコードが 良いコード なわけです。このような事も含めて、「コンパイラの気持ちがわかる」ようでなくては、プログラマとはいえない、というわけ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
うーむ、じゃぁ私は? (スコア:1)
プリンタのレンダラ、携帯内蔵アプリ、NASサーバ、3DCGボード、BIOS…うーむやはり組み込みなのかなぁ。確かにアプリ系はあまりやっていないような気がする。つーかそんなに長時間かけていない気がする。
チップセットとCPUとコンパイラの気持ちがわからない奴なんかプログラマじゃない、と思ってるしなぁ。
でも、力でコーディングするのも、プログラマとは呼べないと思ってるものなぁ。
「力でコーディングするプログラムを書くのだ。そう考えない奴は、キーボードの付属品だ!」
とか平気で言うしなぁ。
かといって、
「フレームワーク? 他人が作ったフレームワークなんぞゴミだ。フレームワークは、プロジェクトごとに練り上げていく楽しみの一部じゃないか。それを他人任せにしてどうする!!」
と言う発想は明らかに IT 系じゃないしなぁ。
.
まぁ、「クラウドコンピューターなんて大きな組み込みマシンだよ」と考えれば、組み込み系無敵って事で。
fjの教祖様
Re:うーむ、じゃぁ私は? (スコア:1)
たしかに、組み込み系の場合、リアルタイム性への要求や信頼性確保の関連でITに比べてブラックボックスを嫌うことが多いかもしれません。
自分のしらない所で何かやっているのが嫌というか。
だから、Cであっても生成されるであろうアセンブラを意識してしまうのですよね。
Re:うーむ、じゃぁ私は? (スコア:1)
もし、それが組み込み系技術者が生成されるアセンブラを意識する理由だとするなら、そこは私は違いますね。
私が「コンパイラの気持ちがわかる」といった場合、それは『コンパイラにとって、どれとどれが同じ内容で、どれとどれは違う内容なのか』を意識する、という事です。
一例ですが…最近は少ないでしょうが、昔の大抵のコンパイラは
と
を同じと見なす能力がありませんでした。それぞれに対応する中間コードがあって、それ故にその後の最適化が変わる。で、ごく初期のコンパイラを除いて、三項演算子の方が一般には『効率が悪い』コードを出したのです。gccが始めてこの2つを完全同一視してくれたときは感動したものです。
「同じ内容であってもどう書くかで最適化は変わる」ので、
「コンパイラにとって判りやすい書き方」
「不明瞭な点がなるべく少ない書き方」
という2つの条件を満たした方がコードは早くなりますし、コンパイラが進化したときにコードを書き直す必要性も減るのです。
.
厄介なのは「不明瞭な点がなるべく少ない書き方」という奴でして。「不明瞭な点」があると、コンパイラは最適化を諦めて安全サイドに出力を倒す必要があります。
言語規格上は別にそうしなくてもよい、という理由で gcc が安全サイドに倒さなかったために起こったバグの例としては Linux kernel 2.6.30 と 2.6.30.1 にだけある、セキュリティホールがあります。
http://kenichiokuyama.blogspot.com/2009/07/linux-kernel-zero-day-explo... [blogspot.com]
に説明を書いておきましたので内容に関してはそちらを見ていただくとして。ようするに、こういう問題が起こるので、コンパイラは「最適化をかけてよい条件」をかなり厳しく設定する必要がある。
わかりづらいコードを書くと、人間だけでなくコンパイラも「最適化をかけてよいかどうか」の判断に手間取ります。あまりにも最適化条件に合致しているかどうかの判断がかけずらい場合、コンパイラは「そのコードに、この最適化は適用しない」という判断を下す可能性がある。コンパイラ自身が使えるメモリも、CPUパワーも限界がありますからね。せっかく「早くなるに違いない」と思って駆使したコーディングテクニックが、コンパイラの最適化対象外になったために効率が相殺されてむしろ遅くなるのでは意味がありません。
また、逆にコンパイラの最適化適用規則が甘いとバグの元になる。
それらを可能な限り排除した書き方で書かれたコードが 良いコード なわけです。このような事も含めて、「コンパイラの気持ちがわかる」ようでなくては、プログラマとはいえない、というわけ。
fjの教祖様