アカウント名:
パスワード:
その5%で、元の100%のプログラムと同じ機能を持つものを作ってみてほしい。それをして、初めて「95%は冗長だった」と言えるんじゃないの?
最適化して機械語にして圧縮をかけたら、それぐらいにならないかな。
最適化を少しでもやってみるといい:一晩も二晩も苦労して数パーセントも減らないなんてざら。(思いつきで実行速度数倍なんてこともあるにはあるけど)機械語で書いてみるといい:いまのCPUアセンブラで書いたらかえって遅いくらいなのを体で理解するよ。(ネイティブコード化ってことならまたちょっと違ってくるけど)圧縮アルゴリズム勉強したらいい:圧縮の適用先が理解できるようになるよ。
挙げてもらった3要素すべてにおいて勉強不足だな。
javac通すだけでもかなり減るんじゃない?バイナリリソースなければjarでソースのサイズの1/20とかなったりしないのかな?そこまでは無理?それなら元論文の手法か、vmやコンパイラ、どちらかに改良の余地があるんじゃないか。#速度のために冗長な可能性もあるが
たとえ現時点で多少速度が稼げても、数年後には逆転していることもある。Javaでいくと、「連結はStringBufferで」をきちんと解釈できなかった人が、×String a = b + c;○String a = new StringBuffer(b).append(c).toString();などとコーディング規約に盛り込んでいたりした。(たしかJava8でも、StringBuffer→StringBuilderの置換まではしてくれない)
昔アセンブラで1バイト、1クロック削れたら嬉しかったもんだけど、今はアルゴリズムが絡まない限り余計な最適化はせず、素直に書く方が良いだろう。可読性からも。
まあ、今回の元の話はコーディングではなくJavaという言語仕様自体の話だと思うけど。
ソースコードの最適化なんて無駄ということですな。可読性が低くなるだけでほとんどメリットはない。高速化はアルゴリズムレベルで試みるべき。
今でもアセンブラでSIMD処理に特化すれば軽く数倍のパフォーマンスはでる。SIMDは制約が多いので、文脈からコンパイラが自動ベクトル化して処理速度を向上させるのはほぼ無理、SIMD命令を使う事自体は可能だが性能が出ない。汎用的な四則演算、分岐、メモリアクセス命令をアセンブラで書く意味がないだけで。
最後の一言が言いたかっただけで残りは冗長ですね。
うん、その通りだと思う。この目的なら、わざわざ自然言語処理におけるその文章解析なんて引っ張り出してくる必要が無い。プログラミング言語の冗長な記述を可能な限り省略しつつ、かつ、元のプログラムと全く同じ動作する最小の部分を切り出す処理って、最適化とコンパイルがまさに、やりたい事そのものでしょこれ。(もちろん実際には最小にできるほどの最適化の性能はないけど、文章解析の方も100%完璧じゃなかろうし)
ソースコードのサイズとコンパイル後のバイナリサイズの差がでかい言語という意味ではJavaはそう。ただ、IDEに補完させれば良いので、タイプ量が多いとかそういう話になるとまた違いそう。
リフレクションのある言語であるコードが決して使われないか静的に確定するのは無理ゲー。
最適化したらループ展開でかえってサイズが増えるなんてザラだが
どうして、サイズ最小化オプションを使わないんです
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
だったら、 (スコア:2, すばらしい洞察)
その5%で、元の100%のプログラムと同じ機能を持つものを作ってみてほしい。
それをして、初めて「95%は冗長だった」と言えるんじゃないの?
Re:だったら、 (スコア:0)
最適化して機械語にして圧縮をかけたら、それぐらいにならないかな。
Re: (スコア:0)
最適化を少しでもやってみるといい:一晩も二晩も苦労して数パーセントも減らないなんてざら。
(思いつきで実行速度数倍なんてこともあるにはあるけど)
機械語で書いてみるといい:いまのCPUアセンブラで書いたらかえって遅いくらいなのを体で理解するよ。
(ネイティブコード化ってことならまたちょっと違ってくるけど)
圧縮アルゴリズム勉強したらいい:圧縮の適用先が理解できるようになるよ。
挙げてもらった3要素すべてにおいて勉強不足だな。
Re: (スコア:0)
javac通すだけでもかなり減るんじゃない?
バイナリリソースなければjarでソースのサイズの1/20とかなったりしないのかな?
そこまでは無理?それなら元論文の手法か、vmやコンパイラ、どちらかに改良の余地があるんじゃないか。
#速度のために冗長な可能性もあるが
Re: (スコア:0)
たとえ現時点で多少速度が稼げても、数年後には逆転していることもある。
Javaでいくと、「連結はStringBufferで」をきちんと解釈できなかった人が、
×String a = b + c;
○String a = new StringBuffer(b).append(c).toString();
などとコーディング規約に盛り込んでいたりした。
(たしかJava8でも、StringBuffer→StringBuilderの置換まではしてくれない)
昔アセンブラで1バイト、1クロック削れたら嬉しかったもんだけど、
今はアルゴリズムが絡まない限り余計な最適化はせず、素直に書く方が良いだろう。可読性からも。
まあ、今回の元の話はコーディングではなくJavaという言語仕様自体の話だと思うけど。
Re: (スコア:0)
ソースコードの最適化なんて無駄ということですな。
可読性が低くなるだけでほとんどメリットはない。
高速化はアルゴリズムレベルで試みるべき。
Re: (スコア:0)
今でもアセンブラでSIMD処理に特化すれば軽く数倍のパフォーマンスはでる。
SIMDは制約が多いので、文脈からコンパイラが自動ベクトル化して処理速度を向上させるのはほぼ無理、SIMD命令を使う事自体は可能だが性能が出ない。
汎用的な四則演算、分岐、メモリアクセス命令をアセンブラで書く意味がないだけで。
Re: (スコア:0)
最後の一言が言いたかっただけで残りは冗長ですね。
Re: (スコア:0)
うん、その通りだと思う。この目的なら、わざわざ自然言語処理におけるその文章解析なんて引っ張り出してくる必要が無い。
プログラミング言語の冗長な記述を可能な限り省略しつつ、かつ、元のプログラムと全く同じ動作する最小の部分を切り出す処理って、
最適化とコンパイルがまさに、やりたい事そのものでしょこれ。
(もちろん実際には最小にできるほどの最適化の性能はないけど、文章解析の方も100%完璧じゃなかろうし)
ソースコードのサイズとコンパイル後のバイナリサイズの差がでかい言語という意味ではJavaはそう。
ただ、IDEに補完させれば良いので、タイプ量が多いとかそういう話になるとまた違いそう。
Re: (スコア:0)
リフレクションのある言語であるコードが決して使われないか静的に確定するのは無理ゲー。
Re: (スコア:0)
最適化したらループ展開でかえってサイズが増えるなんてザラだが
Re: (スコア:0)
どうして、サイズ最小化オプションを使わないんです