パスワードを忘れた? アカウント作成
14967341 story
プログラミング

プログラミング言語とエネルギー効率 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に関しては、エネルギー効率と実行時間の短さが一致するものの、ほかの言語は条件によっては全く一致しなかったとしている。
  • by Anonymous Coward on 2020年10月22日 17時47分 (#3911347)

    論文にも以下の様に記載されている通りなんですが、
    結果に影響する要素が多いんで、難易度の高いテーマですね…

    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で直接実行できる
    # 機能を発表してたけど、殆ど普及しませんでしたね…面白そうだったので残念

    ここに返信
    • by Anonymous Coward

      そう簡単に相関しない事を、どうにか相関があると、そう考えているのかしら

      > 論文の最後に、研究者たちは、さらなる研究のために、長期的な総メモリ使用量と消費エネルギーとの相関性を調べたいと付け加えています。

      短期的な要求に応じて動的に負荷が変わる用途(普通のサーバやクライアント)とは別なのかな。必要な応答速度に応じてアルゴリズム切替とかは珍しくなさそうな気も。別のプログラム言語での実装にまで切り替えた方がベターとかなると、人的コストに響きそう。

  • by hakikuma (47737) on 2020年10月22日 18時16分 (#3911373)

    エネルギー消費量という事を考えた場合、
    プログラム実行時のエネルギーよりも
    プログラム実装時のエネルギーの方が多いのは当然なんだから(電気エネルギーだけじゃなく人的エネルギーとかいろいろとかかるんで)
    本当の効率化を求めるんなら、いかにエネルギーを使わずにプログラム実装できるかを考えるべきだよね。

    ここに返信
    • by Anonymous Coward

      プログラム実行時のエネルギーよりもプログラム実装時のエネルギーの方が多いのは当然なんだから(電気エネルギーだけじゃなく人的エネルギーとかいろいろとかかるんで)


      例えばWindowsのソリティアのプレイで消費された延べエネルギーは考えたくもないレベルだと思うけど、実装にそれ以上のエネルギーがかかったの?

    • by Anonymous Coward

      「プログラミング実行し、」なんて言うもんだからそういう話かと思ったわ
      言語の話をガバガバ言語で語るなと

    • by Anonymous Coward

      この頓珍漢なコメントがプラスモデなの?大丈夫?

      • by Anonymous Coward

        実装するコードの自動生成とかあたりに注力して本当の効率化を
        とかなんとかいいたかったのかなと。 自動生成させるための
        コードの実装に多大なエネルギーが必須なのは自明なんだけどね。

      • by Anonymous Coward

        だれもモデレートしていない。IDだから+1、カルマがたくさんあるから+1で、最初から2。

  • by Anonymous Coward on 2020年10月22日 16時44分 (#3911320)

    言語というより、昨今のCPUではキャッシュに入る処理量とか、
    パイプラインが(なるべく)廃棄されない流れであるとか、
    そういった処理系の実装の違いを評価しないと
    知りたいことは分からないと思う

    ここに返信
  • by Anonymous Coward on 2020年10月22日 21時25分 (#3911497)

    カブのが遅いけど同じ燃料で遠くまで走れるみたいな?

    ここに返信
  • by Anonymous Coward on 2020年10月22日 16時16分 (#3911297)

    大変だ!?
    趣味と実益を兼ねた言い訳が台無しになっちゃうじゃないですか!

    # 可読性は人的コストに貢献。。。電力と同じくコストの数値化、では該当部署に。。。え?許可しない、あ、はい。。。

    ここに返信
  • by Anonymous Coward on 2020年10月22日 16時26分 (#3911302)

    インタープリタ型なのにコンパイル型と肩を並べとるな。

    ここに返信
    • by Anonymous Coward on 2020年10月22日 16時35分 (#3911312)

      結果の表にある言語の前の表記は
       (c) コンパイル方式
       (v) VM(JIT)方式
       (i) インタプリタ方式
      のようなので、消費電力だと JavaScript より上に「(i)Dart」がいますね(処理速度はほぼ同じ)

      個人的には Lisp が全体的に好成績でびっくり(今も改良続けられているんだろうな、と)

    • by Anonymous Coward

      最適化頑張りすぎてJIT型コンパイラみたいな状態になってるからね

    • by Anonymous Coward

      JavaScriptはもはや純粋なインタープリタ型として動作する部分のほうが少ないのでは……
      というか動的コンパイル技術がここまで進んだ現代ではインタープリタ型とコンパイル型という分類にあまり意味はないような気もしますね

      • by Anonymous Coward

        意味はあります。観念的な説明としてJavaScriptをコンパイル型の言語とは言わないですから。
        実行時最適化の発想は古くからありますが、インタプリタのコードが
        逐次処理されるかコード変換が掛かるかは、それを動かすエンジンによります。
        分類に意味が無いと考えるなら、逆に言えば最初からそこに意味は無かったのです。

      • by Anonymous Coward

        ARM V8もAMD64もインタプリタだよね

      • by Anonymous Coward

        javaをコンパイル型に分類するような分類の仕方ならjsをインタープリタに分類するだろうなとは思うけど、
        そろそろjavaとjsのこのクソみたいな分類改めろと思う。

  • by Anonymous Coward on 2020年10月22日 16時27分 (#3911303)

    コンパイラの最適化度合いの違いじゃないのかな。

    ここに返信
    • by Anonymous Coward

      同じ言語(同じ処理系)で最適化レベルを変えた時のエネルギー効率はどうなるんでしょうね?

  • by Anonymous Coward on 2020年10月22日 16時33分 (#3911307)

    むやみにハードウェア性能を引き出[さ|せ]ない言語、かなあ?

    もっとも電源を使用するのはCPUだと仮定すると、

    ・スレッド間でしなくていい同期を取ろうとしてsleep多発する言語
    ・非同期処理が効率が悪すぎて同期処理で書かれがちで結果としてsleep多発な言語

    なのが上位に来るのかしら
    ま、許容できる時間内に課題を解決できるプログラムならそれでもいいという経営上の判断はありそう

    ここに返信
    • 今時のCPUってクロックが可変。
      で、電力効率もクロックで可変しそう。
      特にTurboBoostとかの高クロックになると効率が落ち込みやすい気がします。

      となると、一番効率が良い周波数で動く程度の負荷だと結果的に良くなる?

      # OSのスケジューラに、電力効率重視って通知するAPIとかあったっけ?

      --
      私を信じないで、貴方を裏切ってしまうから。
    • by Anonymous Coward

      エネルギー消費だけを考えたら、単一スレッドで逐次処理が一番いいのではないだろうか。

    • by Anonymous Coward

      リンク先には

      平均して大部分(約88%)の電力がCPUによって消費されていると結論付けました。

      とあるので、CPU が大部分の電力を消費しているのはその通りのようです。

      sleep 連発するのは、処理速度は遅いけど電力消費は少ない、みたいな直感に反するタイプになるかと

      消費電力が少ないのは、目的達成のために余計な処理が挟まれない言語かなーと思いました
      インタプリタは言わずもがな、JIT でも翻訳だったり実行中の解析だったり、純粋な目的達成のアルゴリズム以外の処理が動いています
      上位の C、Rust、C++ はそれらが少ないから、最小の処理で目的が達成でき、また途中に余計な処理が挟まれないのでキャッシュヒット率も良くて効率がいいのかな、と

    • by Anonymous Coward

      CPUを作るのにかかるエネルギー消費まで含めると、壊れるまで出来うる限りフルパワーで回し続けた方が良さそう。

  • by Anonymous Coward on 2020年10月22日 16時37分 (#3911314)

    敗北を知りたい

    ここに返信
    • by Anonymous Coward

      ぬるぽ

    • by Anonymous Coward

      確かにバグ発生頻度・深刻度でも大勝利だし。

      • by Anonymous Coward

        アセンブラ「それなら俺の勝ちだ!でもユーザー数は圧倒的に負けているorz」

    • by Anonymous Coward

      お願いです、もう滅びてください…何でもしますから!

      • by Anonymous Coward

        何でもっていったね。
        ではC++をやってもらおうか。

  • by Anonymous Coward on 2020年10月22日 17時13分 (#3911331)

    フォンノイマンなCPUに対して命令型言語が効率よいって当然では。
    じゃあ今の技術でLispマシンを作ったらLispを最高効率で実行できるのか?

    ここに返信
  • by Anonymous Coward on 2020年10月22日 17時13分 (#3911332)

    JavaScript/TypeScriptの実行環境は明記されてないようだけど、多分Node.jsだよね?
    でも、Node.jsってV8だから、実質インタプリタではなくコンパイラなのでは?
    そうすると、JavaScriptが遅いのはインタプリタだからじゃなく、JavaScriptのデータ構造自体に起因するように思う。
    (ソースコードが見当たらないから何とも言えないけど)
    それに、多分正規表現ライブラリはC++で書かれているだろうから、実質C++を計測しているだけのような……。

    あと、TypeScriptはJavaScript(ECMAScript)にトランスパイルされるんだから、更に事情が複雑だと思う。
    ターゲットバージョンが異なると、全然違うコードを吐き出すしね。

    ここに返信
  • by Anonymous Coward on 2020年10月22日 17時59分 (#3911358)

    高負荷時にガッツ入りアクセラレーション入れるのか、それともトータルの負荷を考慮して調整するのかとかでも変わって来るんじゃ。

    ここに返信
  • by Anonymous Coward on 2020年10月22日 18時17分 (#3911374)

    マシン語じゃないの?
    作る速度は最低かもしれない

    ここに返信
    • これがそうでもなくて。コンパイラの最適化はある部分で人間のソレを超えている状況。
      • by Anonymous Coward

        人間が書いたマシン語が一番速かったのはインオーダー実行の初期32ビットCPUの頃では?
        キャッシュとか分岐予測とかアウトオブオーダー実行とかをCPUが実装しだした時点で人間がついていけないもの。

        • by Anonymous Coward on 2020年10月23日 0時45分 (#3911572)

          いや、ついていけよ。
          ついていけないとか言わずに、ついていけよ。
          今でも性能出ない部分はアセンブリ手書きだよ。
          マルチコアが普通になったおかげで、今はコンパイラの最適化ではとても期待性能出せなくて、コンパイラの出力を人が最適化してるよ。

        • by Anonymous Coward

          しかも今は当たり前のようにマルチコア環境なので、同時並行で動作する裏のタスクが変化する状況では、
          JITコンパイラの威力もバカにできないという・・

        • by Anonymous Coward

          雑なアセンブラだとCの方が速いとかは確かにある。
          でも、本当に速度が必要な部分は今でもアセンブラ使ってるよ。
          x264とかx265なんかでも、コアの部分はアセンブラコードがある。

          ライブラリやドライバを使う側の人は滅多に触らなくなったけど、作る側の人は今でもアセンブラが必要。

  • by Anonymous Coward on 2020年10月22日 22時33分 (#3911519)

    現在のコンパイラは、実効速度が最速になるように最適化されてコンパイルされる
    コンパイルオプションで、エネルギー効率が最大になるように最適化するオプションがあればいいのでは?

    ここに返信
  • by Anonymous Coward on 2020年10月22日 22時37分 (#3911521)

    自分の中ではバランスいいとか思ってたが違うのか。
    カーニハン、ロブ・パイクのプログラミング作法を読んで、Perl最高!って思ってたのに。

    ここに返信
    • by Ryo.F (3896) on 2020年10月23日 0時42分 (#3911571) 日記

      逆になんでPerlがバランスにおいて優れていると思ったか不思議。
      常識的に考えて、インタプリタは実行速度でもメモリ使用率でも不利なのは仕方ない気がするし、
      エネルギー効率が良くなる理由も特には無いわけだし。
      それに、Perlは今や進化から取り残された存在って感じ。

      ただ、人間がコードを書いて、動かして、デバッグして、結果を得る、というトータルな流れを見れば、インタプリタ系の言語も悪くないかもしれない。

      • by Anonymous Coward on 2020年10月23日 1時12分 (#3911579)

        Perlは「正しいPerlの文法」がないのが難点なんだと思う。
        いろんな書き方を受け入れるから、当然コンパイラの最適化効率も悪くなるし。

        あとやっぱり、書き手によって全く別の言語になるのがチーム開発では最悪。
        たぶんデファクトスタンダードはCみたいな書き方なんだろうけど。

typodupeerror

普通のやつらの下を行け -- バッドノウハウ専門家

読み込み中...