プログラミング言語とエネルギー効率 76
ストーリー by nagazou
条件次第 部門より
条件次第 部門より
ポルトガルの大学に所属する6人の研究者が「プログラミング言語全体のエネルギー効率[PDF]」というタイトルの論文を発表したそうだ。研究者たちは、27種類の異なる言語で書かれた10個のプログラミング実行し、実行時の速度と消費電力、そしてメモリ使用量を計測した。テスト用の10個のプログラムには"Computer Language Benchmarks Gameが使用されたという（The New Stack、ブログ: 最も電力を使わないプログラミング言語は？）。
この論文では、より高速なプログラムは総合的なエネルギー消費は少ないという考えは見直されるべきだと指摘している。プログラム実行中は電力が一定の割合で消費されているわけではないためだという。例えば、実験で使われたベンチマークテストの中の一つでは、Chapel言語で記述されたものは、Pascalで記述された同等のプログラムより55％実行時間は短縮されたが、エネルギー使用量はPascalで書かれたものの方が10％少なかった。
確かにエネルギー効率が最も高い上位5つの言語は、エネルギー効率は実行時間の短い順で高い。しかし、これを24言語にまで広げた場合は、OCaml、Haskel、Racket、Pythonに関しては、エネルギー効率と実行時間の短さが一致するものの、ほかの言語は条件によっては全く一致しなかったとしている。
この論文では、より高速なプログラムは総合的なエネルギー消費は少ないという考えは見直されるべきだと指摘している。プログラム実行中は電力が一定の割合で消費されているわけではないためだという。例えば、実験で使われたベンチマークテストの中の一つでは、Chapel言語で記述されたものは、Pascalで記述された同等のプログラムより55％実行時間は短縮されたが、エネルギー使用量はPascalで書かれたものの方が10％少なかった。
確かにエネルギー効率が最も高い上位5つの言語は、エネルギー効率は実行時間の短い順で高い。しかし、これを24言語にまで広げた場合は、OCaml、Haskel、Racket、Pythonに関しては、エネルギー効率と実行時間の短さが一致するものの、ほかの言語は条件によっては全く一致しなかったとしている。
難しい研究テーマですね… (スコア:2, すばらしい洞察)
論文にも以下の様に記載されている通りなんですが、
結果に影響する要素が多いんで、難易度の高いテーマですね…
Comparing software languages, however, is an extremely complex task,
since the performance of a language is influenced by the quality of
its compiler, virtual machine, garbage collector, available libraries, etc.
特にライブラリがSIMD演算器使うか、GPU使うかとかで、
実行速度と消費電力のバランスは変わってきますし、
測定環境に使われたIntel Core i5-4460はTurboBoostをサポートしているので、
OS、インタプリタ、ベンチマーク負荷のタイミング、CPU温度によっても結果は変わってきます。
厳密な評価をするのが凄く難しいと思えます。
かといって、厳密性を重視しすぎてクロック固定のOSレスで測定したとしても、
実環境とかけ離れた条件での測定結果は、研究成果として微妙とも考えられます。
考えれば考える程に難しいです…
興味深いテーマを研究されている研究者の方々に敬意を。
あとCPU(ISA)によっても結果が変わりそうですね。
# そういえばARMが昔JazelleというJAVAバイトコードをCPUで直接実行できる
# 機能を発表してたけど、殆ど普及しませんでしたね…面白そうだったので残念
Re: (スコア:0)
そう簡単に相関しない事を、どうにか相関があると、そう考えているのかしら
> 論文の最後に、研究者たちは、さらなる研究のために、長期的な総メモリ使用量と消費エネルギーとの相関性を調べたいと付け加えています。
短期的な要求に応じて動的に負荷が変わる用途（普通のサーバやクライアント）とは別なのかな。必要な応答速度に応じてアルゴリズム切替とかは珍しくなさそうな気も。別のプログラム言語での実装にまで切り替えた方がベターとかなると、人的コストに響きそう。
プログラム実装 (スコア:2)
エネルギー消費量という事を考えた場合、
プログラム実行時のエネルギーよりも
プログラム実装時のエネルギーの方が多いのは当然なんだから(電気エネルギーだけじゃなく人的エネルギーとかいろいろとかかるんで)
本当の効率化を求めるんなら、いかにエネルギーを使わずにプログラム実装できるかを考えるべきだよね。
Re: (スコア:0)
プログラム実行時のエネルギーよりもプログラム実装時のエネルギーの方が多いのは当然なんだから(電気エネルギーだけじゃなく人的エネルギーとかいろいろとかかるんで)
？
例えばWindowsのソリティアのプレイで消費された延べエネルギーは考えたくもないレベルだと思うけど、実装にそれ以上のエネルギーがかかったの？
Re: (スコア:0)
「プログラミング実行し、」なんて言うもんだからそういう話かと思ったわ
言語の話をガバガバ言語で語るなと
Re: (スコア:0)
この頓珍漢なコメントがプラスモデなの？大丈夫？
Re: (スコア:0)
実装するコードの自動生成とかあたりに注力して本当の効率化を
とかなんとかいいたかったのかなと。 自動生成させるための
コードの実装に多大なエネルギーが必須なのは自明なんだけどね。
Re: (スコア:0)
だれもモデレートしていない。IDだから+1、カルマがたくさんあるから+1で、最初から2。
なんとなくナンセンス? (スコア:1)
言語というより、昨今のCPUではキャッシュに入る処理量とか、
パイプラインが(なるべく)廃棄されない流れであるとか、
そういった処理系の実装の違いを評価しないと
知りたいことは分からないと思う
カブとNSR50で (スコア:1)
カブのが遅いけど同じ燃料で遠くまで走れるみたいな？
リファクタリング (スコア:0)
大変だ！？
趣味と実益を兼ねた言い訳が台無しになっちゃうじゃないですか！
# 可読性は人的コストに貢献。。。電力と同じくコストの数値化、では該当部署に。。。え？許可しない、あ、はい。。。
JavaScript (スコア:0)
インタープリタ型なのにコンパイル型と肩を並べとるな。
Re:JavaScript (スコア:1)
結果の表にある言語の前の表記は
(c) コンパイル方式
(v) VM（JIT）方式
(i) インタプリタ方式
のようなので、消費電力だと JavaScript より上に「(i)Dart」がいますね（処理速度はほぼ同じ）
個人的には Lisp が全体的に好成績でびっくり（今も改良続けられているんだろうな、と）
Re: (スコア:0)
最適化頑張りすぎてJIT型コンパイラみたいな状態になってるからね
Re: (スコア:0)
JavaScriptはもはや純粋なインタープリタ型として動作する部分のほうが少ないのでは……
というか動的コンパイル技術がここまで進んだ現代ではインタープリタ型とコンパイル型という分類にあまり意味はないような気もしますね
Re: (スコア:0)
意味はあります。観念的な説明としてJavaScriptをコンパイル型の言語とは言わないですから。
実行時最適化の発想は古くからありますが、インタプリタのコードが
逐次処理されるかコード変換が掛かるかは、それを動かすエンジンによります。
分類に意味が無いと考えるなら、逆に言えば最初からそこに意味は無かったのです。
Re: (スコア:0)
ARM V8もAMD64もインタプリタだよね
Re: (スコア:0)
javaをコンパイル型に分類するような分類の仕方ならjsをインタープリタに分類するだろうなとは思うけど、
そろそろjavaとjsのこのクソみたいな分類改めろと思う。
言語の差異のせいなのかね (スコア:0)
コンパイラの最適化度合いの違いじゃないのかな。
Re: (スコア:0)
同じ言語(同じ処理系)で最適化レベルを変えた時のエネルギー効率はどうなるんでしょうね？
総合的なエネルギー消費を抑える言語とは (スコア:0)
むやみにハードウェア性能を引き出[さ|せ]ない言語、かなあ?
もっとも電源を使用するのはCPUだと仮定すると、
・スレッド間でしなくていい同期を取ろうとしてsleep多発する言語
・非同期処理が効率が悪すぎて同期処理で書かれがちで結果としてsleep多発な言語
なのが上位に来るのかしら
ま、許容できる時間内に課題を解決できるプログラムならそれでもいいという経営上の判断はありそう
Re:総合的なエネルギー消費を抑える言語とは (スコア:1)
今時のCPUってクロックが可変。
で、電力効率もクロックで可変しそう。
特にTurboBoostとかの高クロックになると効率が落ち込みやすい気がします。
となると、一番効率が良い周波数で動く程度の負荷だと結果的に良くなる？
# OSのスケジューラに、電力効率重視って通知するAPIとかあったっけ？
Re: (スコア:0)
エネルギー消費だけを考えたら、単一スレッドで逐次処理が一番いいのではないだろうか。
Re: (スコア:0)
リンク先には
平均して大部分(約88%)の電力がCPUによって消費されていると結論付けました。
とあるので、CPU が大部分の電力を消費しているのはその通りのようです。
sleep 連発するのは、処理速度は遅いけど電力消費は少ない、みたいな直感に反するタイプになるかと
消費電力が少ないのは、目的達成のために余計な処理が挟まれない言語かなーと思いました
インタプリタは言わずもがな、JIT でも翻訳だったり実行中の解析だったり、純粋な目的達成のアルゴリズム以外の処理が動いています
上位の C、Rust、C++ はそれらが少ないから、最小の処理で目的が達成でき、また途中に余計な処理が挟まれないのでキャッシュヒット率も良くて効率がいいのかな、と
Re: (スコア:0)
CPUを作るのにかかるエネルギー消費まで含めると、壊れるまで出来うる限りフルパワーで回し続けた方が良さそう。
C「また勝ってしまったか…」 (スコア:0)
敗北を知りたい
Re: (スコア:0)
ぬるぽ
Re: (スコア:0)
確かにバグ発生頻度・深刻度でも大勝利だし。
Re: (スコア:0)
アセンブラ「それなら俺の勝ちだ！でもユーザー数は圧倒的に負けているorz」
Re: (スコア:0)
お願いです、もう滅びてください…何でもしますから！
Re: (スコア:0)
何でもっていったね。
ではC++をやってもらおうか。
寝てる間にゴキブリに持っていかれた (スコア:0)
フォンノイマンなCPUに対して命令型言語が効率よいって当然では。
じゃあ今の技術でLispマシンを作ったらLispを最高効率で実行できるのか？
なんか、雑な比較じゃない？ (スコア:0)
JavaScript/TypeScriptの実行環境は明記されてないようだけど、多分Node.jsだよね？
でも、Node.jsってV8だから、実質インタプリタではなくコンパイラなのでは？
そうすると、JavaScriptが遅いのはインタプリタだからじゃなく、JavaScriptのデータ構造自体に起因するように思う。
（ソースコードが見当たらないから何とも言えないけど）
それに、多分正規表現ライブラリはC++で書かれているだろうから、実質C++を計測しているだけのような……。
あと、TypeScriptはJavaScript(ECMAScript)にトランスパイルされるんだから、更に事情が複雑だと思う。
ターゲットバージョンが異なると、全然違うコードを吐き出すしね。
Re: (スコア:0)
ここにベンチマークのソースがあります。
https://github.com/greensoftwarelab/Energy-Languages [github.com]
javascript の Makefile を見る限り、Node.js の v7.9.0 を使っているようです
Re: (スコア:0)
こりゃまたどえりゃー古いやつですな。とっくの昔にサポートも終わってる。
実はハード側要因なんじゃ (スコア:0)
高負荷時にガッツ入りアクセラレーション入れるのか、それともトータルの負荷を考慮して調整するのかとかでも変わって来るんじゃ。
一番実行が高速なのは (スコア:0)
マシン語じゃないの？
作る速度は最低かもしれない
Re:一番実行が高速なのは (スコア:1)
Re: (スコア:0)
人間が書いたマシン語が一番速かったのはインオーダー実行の初期32ビットCPUの頃では？
キャッシュとか分岐予測とかアウトオブオーダー実行とかをCPUが実装しだした時点で人間がついていけないもの。
Re:一番実行が高速なのは (スコア:1)
いや、ついていけよ。
ついていけないとか言わずに、ついていけよ。
今でも性能出ない部分はアセンブリ手書きだよ。
マルチコアが普通になったおかげで、今はコンパイラの最適化ではとても期待性能出せなくて、コンパイラの出力を人が最適化してるよ。
Re: (スコア:0)
しかも今は当たり前のようにマルチコア環境なので、同時並行で動作する裏のタスクが変化する状況では、
JITコンパイラの威力もバカにできないという・・
Re: (スコア:0)
雑なアセンブラだとCの方が速いとかは確かにある。
でも、本当に速度が必要な部分は今でもアセンブラ使ってるよ。
x264とかx265なんかでも、コアの部分はアセンブラコードがある。
ライブラリやドライバを使う側の人は滅多に触らなくなったけど、作る側の人は今でもアセンブラが必要。
Re:一番実行が高速なのは (スコア:1)
コンパイラで対策できないの？ (スコア:0)
現在のコンパイラは、実効速度が最速になるように最適化されてコンパイルされる
コンパイルオプションで、エネルギー効率が最大になるように最適化するオプションがあればいいのでは？
Re:コンパイラで対策できないの？ (スコア:1)
採用には至っていないようだけど、そういう話が出たことはある。
本の虫: LLVMに電力効率を最適化するコンパイルオプションの議論 (2013-04-17) [blogspot.com]
Perlは (スコア:0)
自分の中ではバランスいいとか思ってたが違うのか。
カーニハン、ロブ・パイクのプログラミング作法を読んで、Perl最高！って思ってたのに。
Re:Perlは (スコア:2)
逆になんでPerlがバランスにおいて優れていると思ったか不思議。
常識的に考えて、インタプリタは実行速度でもメモリ使用率でも不利なのは仕方ない気がするし、
エネルギー効率が良くなる理由も特には無いわけだし。
それに、Perlは今や進化から取り残された存在って感じ。
ただ、人間がコードを書いて、動かして、デバッグして、結果を得る、というトータルな流れを見れば、インタプリタ系の言語も悪くないかもしれない。
Re:Perlは (スコア:1)
Perlは「正しいPerlの文法」がないのが難点なんだと思う。
いろんな書き方を受け入れるから、当然コンパイラの最適化効率も悪くなるし。
あとやっぱり、書き手によって全く別の言語になるのがチーム開発では最悪。
たぶんデファクトスタンダードはCみたいな書き方なんだろうけど。
Re:Perlは (スコア:1)
それは間違いだな。
Perlらしいコードを書けば、(数日後の)本人だって理解不能なコードになる
Re:Perlは (スコア:2)