アカウント名:
パスワード:
カリカリチューンしろという課題ならともかく、 そうでない部分の学習だとしたら教師の言うことはもっともです。
だってコンパイラやCPU自体にバグが無いって訳では無いですから。
当時は、確かにマシンコードが読めるというのはある種必要なスキルと感じましたが、JavaやVB、その他Scriptが全盛となった今、組み込みやセキュリティ関連分野以外ではマシンコードの理解が必要である、というのは疑問です。
今だと、教官がそのアセンブラを分かったとしても、そのルーチンが学生が考えぬいて最適化したのか、コンパイラで最適化したものかどうかを判別するってのは大変だろうと思います。まあ大体今時のコンパイラは下手に人間がやるよりよっぽど賢い最適化をしてくれるんで、ボロが出るとは思いますが。ただ、教官も「コンパイラに最適化をかけてアセンブラ出力したものをレポートで提出したらA判定貰えた」なんてのは避けたいと思うでしょうから、使っているコンパイラの最適化手法の知識も必要になるということで。これは大変そうですね。
おまけに「全員がA判定狙いで怪しげな自作のアセンブリコードをレポートとして提出してきた」なんて状況を考えると頭が痛いです。レポートの提出者分だけ、「このコード実装は講義レベルを越えているんだけど、すごいコード、たまたま与えたデータでは動いている、全然ダメのどのレベルなのか」を判定しなきゃいけないんですから。
研究室付き学生にそれをやるならともかく、一般教養レベルでそんな評価をした上で判定するなんて、とても1教官の努力で出来るとは思えません。
# 私は会社員でよかった。(笑
現在のサーバサイド Java の場合、最適化は確率と統計の世界に入ります。
JIT コンパイル自体が実行時間の一部になってしまうので、JIT 範囲を絞り込むためにプロファイリングを行い、HotSpot と判断した部分のみコンパイルします。
なので、同じコードでも、プログラム中での実行頻度によって実行速度が変わる -それも実行の途中から- のです。
こうなるとネイティブ環境での常識が通用しません。マイクロベンチマークを回すと極度に最適化されて良すぎる結果が出るとか。
ルールで最適化の正否を判断できないので、システムの組みように困るというか、悪いと思える場所でも影響がどのくらい有るのか分かりにくいというか。
参照: 日本HP - HP-UX Developer Edge - メモリ・リーク解析とHotSpot JVM [hp.com] (日本HPのサイトですしメモリリークを解説する記事の一部ですが、これが一番端的な解説をしていると思います)
また、javacが吐くお馬鹿なコードというのは、例えば「影響の全くない命令を幾つも並べる」というものでありこれはJITだろうが何だろうが省くに越したことはないでしょう。
マシン語とまではいかなくてもパソコンの動作原理(メモリにデータと命令が混在していて、CPUは指定したメモリ位置の命令を読んで・・・とか。いわゆるチューリングマシンの話)は知っておくべきだろう
知っていたら知っていたで武器になりますからそれはすばらしいことですけども、「知っているのが常識」みたいに言われるとちょっと引きますね
# 元ネットワークエンジニア、今はWindowsを弄ってすごしている自称ITエンジニアのAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
言語と目的によるだろ (スコア:3, すばらしい洞察)
もしかしてJavaとかPerlとかPHPとかでのコーディングははプログラミングじゃねぇ!とかいいたいんじゃ・・・とか思って元記事を見たらそうではないみたいですが。
# 学生時代に実習でマイコンのプログラミングをしたとき、「サブルーチンをアセンブラで書いてもいいですか」と教官に聞いたら「そんな無駄なことする必要はない」とか言われたことをふと思い出した
Re:言語と目的によるだろ (スコア:2, すばらしい洞察)
○「そんな(オレが知らないアセンブラをを見るという時間の)無駄なこと(をさせる気か?だから)する必要はない(ただでさえ…)」
Re:言語と目的によるだろ (スコア:2, 興味深い)
>「サブルーチンをアセンブラで書いてもいいですか」と教官に聞いたら
>「そんな無駄なことする必要はない」とか言われたことをふと思い出した
無駄です。
あなたが聞いたと言うことは、あなたが出来るからです。
なのでわざわざ書く必要がないということです。
カリカリチューンしろという課題ならともかく、
そうでない部分の学習だとしたら教師の言うことはもっともです。
# ただ「必要はない」だけで書いてもよかったんじゃないですかね?
# 完璧を期すなら、アセンブラを使うバージョンと使わないバージョンを作りましょう。
Re:言語と目的によるだろ (スコア:0)
適当に書いたアセンブリ言語のプログラムよりも、カリカリチューンしたCのプログラムのほうが処理速度が速かったりもしますし。
もちろん、カリカリチューンの一手段としてアセンブリ言語を使うことはありますが、単純にCよりもアセンブリ言語のほうが書きやすいと感じる場面もあるので…。
# 親コメとは別人ですがCよりもアセンブリ言語のほうが個人的にはラクなのでAC
Re:言語と目的によるだろ (スコア:0)
Re:言語と目的によるだろ (スコア:2, すばらしい洞察)
だってコンパイラやCPU自体にバグが無いって訳では無いですから。
Re:言語と目的によるだろ (スコア:1)
ステップ実行で動作を確認してもコードにはまったく問題は見られず、まさにお手上
げ状態でした。
「まさか...」と思いながらマシンコードを見ていると、ifの条件部分に相当する
コードが明らかにおかしく、「コンパイルのバグか!」と決着したことがあります。
当時は、確かにマシンコードが読めるというのはある種必要なスキルと感じましたが、
JavaやVB、その他Scriptが全盛となった今、組み込みやセキュリティ関連分野以外では
マシンコードの理解が必要である、というのは疑問です。
#SEはゼネラリストであることを求められる時代になっているように感じます
Re:言語と目的によるだろ (スコア:1, すばらしい洞察)
別に必須要件って訳では無いが、知らないと立ち止まって仕舞う状況でも知っていると前に進める事が増えるってだけです。
ま、保険ですね。
Re:言語と目的によるだろ (スコア:0)
> ま、保険ですね。
私は、昔々 ゴリゴリとアセンブラで BIOSだの、ブートロジックだの、
ドライバだの書いてたけど、今は C/C++ でなんとかなってる。
というより、C/C++ と デバイスメーカーからのSDK でなければ
効率悪くて業務そのものが成立してない。
アセンブラを学ぶための時間や手間と
アセンブラの知識があったことで前に進めた経験事例の数を比較すると、
これからの人には、保険料が高すぎると思いますね。
知ってたら イイコトあるかもしれないけど、
知らなくても全然問題ないよ。
「マシン語」が必要になる「目的」 (スコア:2, 興味深い)
# 実際に書いたことはないので本当に必須かどうかは知らない
Re:「マシン語」が必要になる「目的」 (スコア:2, すばらしい洞察)
食い扶持でCやC++でコードを書いている人は自分の書いたコードがどういう風に
機械語に変換されて実行されているか位は少なくとも知るべき。
自分の書いたプログラムに脆弱性が発見されてもどこをどう直せば直るのか全く
わからないという屈辱を味わう事になるよ。
#そして無能な開発者は本来はお礼を言わなきゃならない報告者に逆ギレするわけだ
Re:言語と目的によるだろ (スコア:1, 興味深い)
Re:言語と目的によるだろ (スコア:0)
#釣られたら人間、みたいなw
Re:言語と目的によるだろ (スコア:1)
レポート提出者は進化する (スコア:1)
今だと、教官がそのアセンブラを分かったとしても、そのルーチンが学生が考えぬいて最適化したのか、コンパイラで最適化したものかどうかを判別するってのは大変だろうと思います。まあ大体今時のコンパイラは下手に人間がやるよりよっぽど賢い最適化をしてくれるんで、ボロが出るとは思いますが。ただ、教官も「コンパイラに最適化をかけてアセンブラ出力したものをレポートで提出したらA判定貰えた」なんてのは避けたいと思うでしょうから、使っているコンパイラの最適化手法の知識も必要になるということで。これは大変そうですね。
おまけに「全員がA判定狙いで怪しげな自作のアセンブリコードをレポートとして提出してきた」なんて状況を考えると頭が痛いです。レポートの提出者分だけ、「このコード実装は講義レベルを越えているんだけど、すごいコード、たまたま与えたデータでは動いている、全然ダメのどのレベルなのか」を判定しなきゃいけないんですから。
研究室付き学生にそれをやるならともかく、一般教養レベルでそんな評価をした上で判定するなんて、とても1教官の努力で出来るとは思えません。
# 私は会社員でよかった。(笑
vyama 「バグ取れワンワン」
Re:レポート提出者は進化する (スコア:0)
Re:言語と目的によるだろ (スコア:0)
○「先生はアセンブラが読めません。だからアセンブラで書いたら駄目です。」
Re:言語と目的によるだろ (スコア:0)
Re:言語と目的によるだろ (スコア:2, 参考になる)
ほんとかどうかはしらんけど。
Re:言語と目的によるだろ (スコア:2, 興味深い)
無いのですよ。下手にバイトコードレベルでいじって最適化(と思い込んでいる行為)を
やるとかえって遅くなる危険性が高いですよ。
Re:言語と目的によるだろ (スコア:4, 参考になる)
現在のサーバサイド Java の場合、最適化は確率と統計の世界に入ります。
JIT コンパイル自体が実行時間の一部になってしまうので、JIT 範囲を絞り込むためにプロファイリングを行い、HotSpot と判断した部分のみコンパイルします。
なので、同じコードでも、プログラム中での実行頻度によって実行速度が変わる -それも実行の途中から- のです。
こうなるとネイティブ環境での常識が通用しません。マイクロベンチマークを回すと極度に最適化されて良すぎる結果が出るとか。
ルールで最適化の正否を判断できないので、システムの組みように困るというか、悪いと思える場所でも影響がどのくらい有るのか分かりにくいというか。
参照: 日本HP - HP-UX Developer Edge - メモリ・リーク解析とHotSpot JVM [hp.com] (日本HPのサイトですしメモリリークを解説する記事の一部ですが、これが一番端的な解説をしていると思います)
Re:言語と目的によるだろ (スコア:0)
また、javacが吐くお馬鹿なコードというのは、例えば「影響の全くない命令を幾つも並べる」というものでありこれはJITだろうが何だろうが省くに越したことはないでしょう。
--
IDとりたいんだけど、とろうと思ったIDが10回くらい連続で「すでに取られているのと似ている」で弾かれたのでいい加減諦めてAC。
とれるIDサーチ機能を付けて欲しいです!!
Re:言語と目的によるだろ (スコア:0)
Re:言語と目的によるだろ (スコア:0)
Re:言語と目的によるだろ (スコア:1)
Re:言語と目的によるだろ (スコア:0)
多分、それは「javac が吐くコード1命令ごとに、JITが1命令以上のコードを吐く」という大前提があるのではありませんか?もっと言うと、「Just In Timeな最適化」とはどういうものか、がよくわかっていないのでは…。
Re:言語と目的によるだろ (スコア:0)
>やるとかえって遅くなる危険性が高いですよ
それはあらゆる言語のコンパイラ全般に言えることだよね。
ローレベルの原始的な話で威張るぐらいならコンパイラのオプションを全部理解すべき。
Re:言語と目的によるだろ (スコア:0)
> それはあらゆる言語のコンパイラ全般に言えることだよね。
文脈を読んでくださいな。#1222709がJavaコンパイラ(=javac)が吐くコードがお馬鹿だから
自前でバイトコードいじっていると述べたので、そもそもJavaにおいては最適化は
javacの仕事ではなく、JVMのJITコンパイラの仕事だよ(+バイトコードレベル
での最適化はJITコンパイラの最適化を阻害する危険性が高いよ)、ということを言った
までであって、これは一般論としての、コンパイラの最適化に任せるべきか、
手動で最適化すべきか、という問題とは別物です。
Re:言語と目的によるだろ (スコア:0)
知っていたら知っていたで武器になりますからそれはすばらしいことですけども、「知っているのが常識」みたいに言われるとちょっと引きますね
# 元ネットワークエンジニア、今はWindowsを弄ってすごしている自称ITエンジニアのAC
Re:言語と目的によるだろ (スコア:0)
一般的な話では言っていい言葉だろうけど、ここのテーマでそれをいっちゃあ
「お前何考えてる?」と言われるだけ。
>プログラマーはマシン語を理解しておくべき?
Re:言語と目的によるだろ (スコア:0)
×アセンブラで書く
○アセンブリで書く
# 用語は正しく使おうAC
いちよう? (スコア:0)
どれ?
いちよう→一様
いちょう→胃腸
いっちょう→一丁
いちおう→一応
いっちょめ→ワァオッ!
3つ目の「一丁」かな?
#日本語は正しく使おうAC
Re:いちよう? (スコア:0)
ネタでしょう。
なぜか変換できない(はてなダイアリー) [hatena.ne.jp]
# ひ・が・し・む・ら・や・ま!