今時の子供たちは「戦争を知らない子供たち」を知らない子供たちのような気もする訳だが (2)

「今時の子供たちは「戦争を知らない子供たち」を知らない子供たちのような気もする訳だが」の続き。
今日、ブログに何も書く時間なさそうなので、これ掲示して発言したことにしておく。

Java のプログラム書けるようになるにはどの程度かかりますか、
という質問をよくされるのだが、
個人差が100倍ほどありそうで難しい。
売り物になるようなプログラムをJavaで書けるようになるには、
全く何も知らない人なら、センスが抜群によい人で、死ぬ気で勉強して1年、
同じくC言語とか熟知している人なら3年はかかるのではないかと思う。

C言語知ってるとなぜ余計にかかるかというと、
特に非オブジェクト指向言語に熟練してしまうと、
逆方向の発想に洗脳されてしまうというか、
Qwerty で打てるので Dvorak 覚えられないみたいなのがあって、
いろいろ頭の中から消してから作らないといけないことがあるので、
かえって時間がかかりそうな気がする訳だ。

まあでも一番ひっかかるのが 80386 の話。

現在の主流CPUであるPentiumやCoreDuoシリーズなど、全てのCPUの元祖ともいえるのが80386です。

そうなの?
いや、8080まで戻れというつもりはないけど。
far と near が出てくるだけでも 86 系はちょっと拒絶反応が…。
そこが重要なんだという趣旨なら、まあそういう考え方も否定しませんけど。
どうも体が勝手に。

80386を理解することは現代のCPUを理解するということであり、 これを理解しないままマルチタスクOS上で動作するプログラムを書くことはほとんど自殺行為です。

マルチタスクOS書くのならともかく、
マルチタスク上で動作するアプリケーションを作る時にもマルチタスクを意識しないといけない
というのは
OSの設計が何か根本的な所で間違っているような気がする
のだけど…まさかWindows 3.1…いやいや、
それは忘れることにして、

その昔というか、
80386 が出てきた当時、68000 系 (68030?) とかに比べると、
8086 系の CPUってダサいというか、
それは現実的なのかもしれないが、
当時の他の CPU の中では一番ドロドロしたアーキテクチャーだったような気もするのだが、
現実というのは恐ろしいもので、
汚い机の方が作業がはかどってしまうというか、
68系の CPU はそういえば見当たらないか。
それに、8086 系の CPU が今も健在なのは事実だ。

ただ、それって単に
Windows が 80386 系の pc で動いていた、
というだけの話じゃないかと思う。

もちろん、86系以外の CPU が駆逐された訳ではなく、
実際、今でも使われている。
例えば、PlayStation と PlayStation2、
何だゲーム機かと言われそうだが、中身はパソコンというか、
部分的にはそれ以上の才能も持っている訳で、
これらに使われているのは
R3000
系の CPU。
それぞれ1億台以上を出荷しているから、
R3000 系の CPU を使ったコンピュータだって、世の中に少なくとも2億台はある訳だ。
まあ2億なんて微々たるものだと言われたら、
そうなのかもしれないですけど。

(ちなみに、最近の携帯電話って、CPU何でしたっけ?)

R3000 なんてどうでもいいと言われたらそうなのだが、
ついでに書いておくけど、
遅延分岐のような「なんじゃそりゃぁ」系の面白い命令があったりして、
実際面白い。
そんなの知っていて Java のプログラミングに役に立つんかいな、
という話なのだが、
大外ししてしまうかもしれないけど、
いつだったか、RDB にアクセスする処理で、
どうも時間がかかってそこがボトルネックになっているような気がしたので、
ていうかそういうアプリは RDB がボトルネックになることが普通にあるものですが、
とりあえず何を考えてそうしたのか知らないけど、
JDBC の呼び出しの所に少し待ちを入れてみたら、
全体が速くなった、ということがあった。
あーこれは外したね。すみません。
でも、何となくそこにウェイトを入れたら全体が速くなるような気がしたんだ。

そういえば、
PS3 は Cell プロセッサという化け物 CPU 使ってますね。

RISC ももちろんだが、
Pentium なんてのは命令のキャッシュのヒット率をどうやって高めるかというのが最大のアレなわけで、

エンジンの最低限の仕組み、自動車が走り、止まり、曲がる最も基本的な仕組みを理解せず、 材料の知識もなく、熱設計もサスペンションも見たことが無くて、エンジンの分解・組み立てもしたことがない人が、 NC工作機械とCADソフトの前だけで自動車の全ての部分を設計するとしたら脅威というより恐怖です。

この命題だけなら
激しく同意したいな。
禿同というらしいが。
ただ、自動車の全ての部分を一人で設計する人って居るのか、今時?

例えば自動車のオプションというか今では必須なんだろうけど、
カーナビの設計担当の人が、
エンジンの分解、組み立てができないと仕事にならないかというと、
当たり前だが No に決まっている。
逆に、サスペンションとかフレームを設計する人が、
ABSを動作させるための組み込みソフトウェアまで理解していないといけないかというと、
そんな訳ないような気がする。

それよりも今重要なのは、
ロボットの操作ではないか。
手作りの車なんて今では絶滅種に近い。
車を作っているのはロボットですから。
何か Java 書くんだったら Eclipse に熟練しろと言ってるみたいで爽快だな。
メモリは1GB以上積んでおくんだぞ、みたいな話?

弊社の入社試験には必ず論理回路の問題が出てくるくらい

カルノー図とか出てくるのかな?
カルノー図知らなくてもプログラムは書けますか。
そういう細かいことたくさん知っていても、
and と or をうっかり間違えるし、
さっきも compare(hoge1, hoge2) と書いたつもりの所が
compare(hoge2, hoge2) になっていて、
なんじゃこりゃぁぁ、と思わず叫んだ所だ。
現実世界というのはそういう所だ。

プログラミングで重要な裏技というか、
表技かもしれないけど、デバッグ技術というのがありますが、
あれはマシン語と関係あるのかというと、
ICE 使ってデバッグとかした人なら「大有りだよ」と言うのかもしれない。
さっきも書いたような気かするけど、
CPU のレジスタの中身を見てデバッグしないといけないような API があったとしたら、
そりゃ API が何かおかしいんじゃないか、
という気もする。
いや実際おかしい API は世の中にいくらでもあるのだが。

デバッグプリントは9600bpsのシリアルポート経由で表示されるので、 毎フレーム表示しようとすると確実に処理速度が落ちます。

そういえばシリアルポート知らない人いるんじゃないか、最近。
昔はパソコン通信とかモデムとかあったから誰でも知ってたけど。

で、クリティカルセクションがアレでタスクスイッチが、
とかいう話が書いてあるのだけど、
そうじゃなくて単に

ふつー、デバッグプリントすると遅くなる

という安直な経験的知識持っていれば済む話ではないだろうか。
脳内コンパイルすら必要ない。
必要なのは、天使のささやきに気付くだけの些細な観察力だけだ。

しかしこの箇所、もっと重要なことが出てきますよね。

偉そうに言っていたパフォーマンスの1/100もでないぞ

最近あった何人かのプログラマーに、
この論点がすこし欠落していたような気がする。
つまりその処理にどの程度のパフォーマンスが出るのが普通なのかが分からないのだ。
つまり、それが本来の1/100の速度しか出ていない、
という事実にそもそも気付かなかったりするのだ。

マシン語を知っていると、
大雑把にそういう所も概算できるようになる。
CPU クロックが 1.8GHz だと、1秒間に最大何命令実行できて、
このサーチには何命令かかりそうだから、1秒間に何回サーチできる、
みたいな計算ができるのだが、
例えば、未照合のデータが5000万件あるとして、
照合するのに何秒かかるのか、というような計算は、
実際に運用するためのプログラムを作るときには必須に近いものだ。
これが計算できないと年金が宙に浮いたままになってしまうから大変だ。

秒じゃ無理っぽいけど、
未照合のデータの突合せをDB経由でやるなんてのは、
命令サイクルが分かっていても計算できそうにないが、
例えば、1件が1msで処理できるか、それとも1秒かかるのか、
みたいなことはおよその目安で知っていた方がいいような気がする。

(終) 前の記事からリクエストしたトラックバックは無視されているようだが一応書いておく、元ネタは「マシン語を知らない子ども達」。引用は同ページより。