アカウント名:
パスワード:
その5%で、元の100%のプログラムと同じ機能を持つものを作ってみてほしい。それをして、初めて「95%は冗長だった」と言えるんじゃないの?
lisperかhaskellerに頼めば。
Computer Langauge Benchmarks Gameというサイトに行けば、コードの長さも評価に入れた言語対抗ベンチマークがありますよ。
これはJava vs Dartの例。http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=java&... [debian.org]
最適化して機械語にして圧縮をかけたら、それぐらいにならないかな。
最適化を少しでもやってみるといい:一晩も二晩も苦労して数パーセントも減らないなんてざら。(思いつきで実行速度数倍なんてこともあるにはあるけど)機械語で書いてみるといい:いまの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に補完させれば良いので、タイプ量が多いとかそういう話になるとまた違いそう。
リフレクションのある言語であるコードが決して使われないか静的に確定するのは無理ゲー。
最適化したらループ展開でかえってサイズが増えるなんてザラだが
どうして、サイズ最小化オプションを使わないんです
一つの修正をするのに、あちらこちら修正して回らないとならない頻度は多い言語だと思う
まああれだ、自然言語にはメッセージの伝達以外の機能はなくて、機能を表現したコンピュータ言語を同じ方法で評価するのは無理がある。休日にコーヒーでも飲みながら、へぇぇ、と言って眺める程度のものだよ。そんな目くじらたてても仕方ないんじゃないかな。HTMLを同じパーサに掛ければもっと冗長度が低いとでるだろう。
いや、ソースコードの大半は人間が読むためにあるんで、メッセージ性ってのは重要な要素だよ。#人間が読む必要なければ基本的にバイナリで十分だから##OSやライブラリへの追従のためのリコンパイルはあるけど、重要度は低い
まあ、自然言語の冗長性というか無駄とされる部分も、韻や間を含めニュアンスとかあるんでどこから無駄とするかって閾値が一義的に定まらないだろうし、それはソースコードでも同じだろうし、自然言語とは比較できないだろうからなんとも言えないだろう。
とはいえ、洗練することが出来たなら、ソースコードの読みやすさやメンテ性の指標の1つになりうる可能性はもってるんじゃないかな?
メッセージ性とか全く関係ない言葉遊びだと思われ。
んー、この論文て、関数名やら変数名やら2度目に出てきたら冗長といってるんだよね?その理論でいくと、機械語で同じ番地を同じインデックス修飾で参照したら冗長ということになりそうだけど。コンパイルしたところで理論的には冗長度は変わらないはず。
人間はそれほど複雑な構文を扱わない(扱えない)ので冗長性が低いメッセージを扱うことが多くて、取扱説明書とっいた類の文書はやっぱり冗長性高いという分析結果になるだろう。プログラムなんて、取扱説明書の束みたいなもんだから、そりゃ冗長性高いだろ。
5%でした、と言われても、じゃぁ他はいくつなの?としか言いようがないよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
だったら、 (スコア:2, すばらしい洞察)
その5%で、元の100%のプログラムと同じ機能を持つものを作ってみてほしい。
それをして、初めて「95%は冗長だった」と言えるんじゃないの?
Re:だったら、 (スコア:1)
lisperかhaskellerに頼めば。
Re:だったら、 (スコア:1)
Computer Langauge Benchmarks Gameというサイトに行けば、コードの長さも評価に入れた言語対抗ベンチマークがありますよ。
これはJava vs Dartの例。
http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=java&... [debian.org]
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)
どうして、サイズ最小化オプションを使わないんです
Re: (スコア:0)
一つの修正をするのに、あちらこちら修正して回らないとならない頻度は多い言語だと思う
Re: (スコア:0)
まああれだ、自然言語にはメッセージの伝達以外の機能はなくて、機能を表現したコンピュータ言語を同じ方法で評価するのは無理がある。
休日にコーヒーでも飲みながら、へぇぇ、と言って眺める程度のものだよ。
そんな目くじらたてても仕方ないんじゃないかな。
HTMLを同じパーサに掛ければもっと冗長度が低いとでるだろう。
Re: (スコア:0)
いや、ソースコードの大半は人間が読むためにあるんで、メッセージ性ってのは重要な要素だよ。
#人間が読む必要なければ基本的にバイナリで十分だから
##OSやライブラリへの追従のためのリコンパイルはあるけど、重要度は低い
まあ、自然言語の冗長性というか無駄とされる部分も、韻や間を含めニュアンスとかあるんでどこから無駄とするかって閾値が一義的に定まらないだろうし、
それはソースコードでも同じだろうし、自然言語とは比較できないだろうからなんとも言えないだろう。
とはいえ、洗練することが出来たなら、ソースコードの読みやすさやメンテ性の指標の1つになりうる可能性はもってるんじゃないかな?
Re:だったら、 (スコア:1)
メッセージ性とか全く関係ない言葉遊びだと思われ。
んー、この論文て、関数名やら変数名やら2度目に出てきたら冗長といってるんだよね?
その理論でいくと、機械語で同じ番地を同じインデックス修飾で参照したら冗長ということになりそうだけど。
コンパイルしたところで理論的には冗長度は変わらないはず。
人間はそれほど複雑な構文を扱わない(扱えない)ので冗長性が低いメッセージを扱うことが多くて、
取扱説明書とっいた類の文書はやっぱり冗長性高いという分析結果になるだろう。
プログラムなんて、取扱説明書の束みたいなもんだから、そりゃ冗長性高いだろ。
5%でした、と言われても、じゃぁ他はいくつなの?としか言いようがないよ。