パスワードを忘れた? アカウント作成
6352280 story
Debian

AMD64、Debianでもっとも人気のあるアーキテクチャになる 46

ストーリー by hylom
64ビットの時代 部門より
あるAnonymous Coward 曰く、

長らくの間、Debian GNU/Linuxでもっとも人気のあるアーキテクチャはi386だった。しかし、debian-develメーリングリストへのBill Allombert氏による投稿によると、Debianパッケージの利用状況の統計を行っている「Debian Popularity Contest」において、AMD64アーキテクチャの導入数がついにi386アーキテクチャの導入数を抜いたという。

ちなみに第2位はi386だが、第三位はarmel(ARMベースのアーキテクチャ)となっており、最近のARMプロセッサ人気を反映するものとなっている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Henrich (121) on 2012年09月07日 8時19分 (#2226575)
    armelの話は蛇足のような。
  • by Anonymous Coward on 2012年09月07日 8時58分 (#2226598)

    メインメモリが4~8GB程度なら、64bitでのロスを考えるとx86にPAEでも良いけどさ
    メモリ16~32GB積んでx86は無いでしょ、常識的に考えて…
    しかし今や8GB DIMMですら5000円以下の時代だからね
    そりゃあ今更x86とか使ってらんないよ

    • by Anonymous Coward on 2012年09月07日 10時35分 (#2226680)

      メモリ量の64bitのロスより
      x87 -> SSEによる浮動小数点演算の高速化のメリットのほうがでかいっす。

      Apacheのhttps処理速度なんて10倍ぐらいでるもん。

      親コメント
      • by miyuri (33181) on 2012年09月07日 18時14分 (#2227080) 日記

        Apacheのhttps処理速度なんて10倍ぐらいでるもん。

        AES周りに専用の命令を使っていたってオチ?

        親コメント
      • by kemeco (41597) on 2012年09月08日 21時47分 (#2227697)

        単純なコードで試した場合に、fpu と sse とで何倍くらいの差がでるのか試してみました。
        (float型の3万個程度の配列の各要素を2乗する場合で、fpuとsseでどの程度の差がしょうじるか)

        http://codepad.org/Ot3oQyRV [codepad.org]
        fs() は、普通にループで普通に掛け算するだけです。
        fv_a() は、掛け算を sse のに置き換えて、4個づつ計算してくようなの。(4倍速いはず?)
        fv_b() は、32要素づつまとめて計算してくかんじの。(xmmレジスターは1個だけで使いまわし)
        fv_c() は、fv_b()と同じだけど、xmmレジスターを無駄に8個全部使うかんじの。(xmmレジスターを沢山使うと逆に遅くなるかどうか)

        それぞれを交互に1000回試して、各関数毎にトータルの所用時間をくらべてみました

        gcc -O0 でコンパイルした場合 :
         fs: 301437253 clock (1.000000 fs/fx)
         fv_a: 87463181 clock (3.446447 fs/fx)
         fv_b: 33049757 clock (9.120710 fs/fx)
         fv_c: 33274995 clock (9.058972 fs/fx)
        いちおう、ただsseに置き換えるだけで 3.5倍速くなって、もっとがんばると10倍くらい速くなってるみたいです、-O0ですが。

        gcc -O3 でコンパイルしたばあい:
         fs: 66715454 clock (1.000000 fs/fx)
         fv_a: 31263297 clock (2.133987 fs/fx)
         fv_b: 30580498 clock (2.181634 fs/fx)
         fv_c: 29792373 clock (2.239347 fs/fx)
        普通のコードが最適化で速くなって、sse との速度差が2倍程度にまで縮まる。
        あと、sseの3種類の関数の速度差が悲しい程に縮まる。

        gcc -O3 -msse2 でコンパイルした場合(悲しいお知らせ)
         fs: 30884061 clock (1.000000 fs/fx)
         fv_a: 33528261 clock (0.921135 fs/fx)
         fv_b: 30616261 clock (1.008747 fs/fx)
         fv_c: 29912155 clock (1.032492 fs/fx)
        普通のコードでも sse が使われて、結果 _a() より速くなる。 (なまじfv_a()のようなことすると、最適化した際に逆に遅くなる…orz)
        _b, _c は辛うじて速いけど、辛うじてってレベルの差でしかないので悲しい。

        最適化コンパイルすると、手書きsseと大差無いsseコードが吐き出されるっぽいでした…。いい時代ですねorz

        親コメント
      • by Anonymous Coward
        暗号で浮動小数点演算なんか使われるんですか?
        • by Anonymous Coward

          SSEが効果的なのは確かですが整数演算ですよね。

      • by Anonymous Coward

        SSE だと理想的な場合でも float で4倍、double で2倍程度じゃないすか?
        10倍は何か他の要素があるんじゃないかと。

        # AVX だとしても10倍はないような。

      • by Anonymous Coward

        初めてAthlon64を買った時、oggencのi386とamd64のバイナリを用意して時間を測ったらamd64の方が2割くらい速かった覚えがあります。

        以来、多少メモリを食われようがお構いなしにamd64にしています。

        Intel Core2だと大差ないんでしたっけ?

      • by Anonymous Coward

        SSE は 64bit には関係ないけど、パフォーマンスの話をするならレジスタ増える方かねぇ。

        個人的には 2GB 超えるあたりで 64bit 化かな。
        メモリ、特にカーネルメモリとユーザメモリの割り当て自由度が 32bit と 64bit では雲泥の差がある。

        ユーザー+カーネルメモリが 2GB+2GB とか 3GB+1GB とか構成考えなくていいのは、
        例え物理メモリが 2GB しか搭載されてなかったとしても、
        ある種のチューニング作業としてはかなり楽になる。

        • by kusanagi (3927) on 2012年09月07日 12時29分 (#2226793)

          >SSE は 64bit には関係ないけど、パフォーマンスの話をするならレジスタ増える方かねぇ。

          うんにゃAMD64ではSSE2が標準定義なので。

          --
          kusanagi shin
          親コメント
        • by Anonymous Coward

          > SSE は 64bit には関係ないけど、
          AMD64の必須機能に含まれているので、存在を前提にできるという点が関係あります。
          自分でビルドできるんだからi386でもSSE有効でビルドすればいいじゃんとは思うけど。

      • by Anonymous Coward

        メモリ量の64bitのロスより
        x87 -> SSEによる浮動小数点演算の高速化のメリットのほうがでかいっす。

        じゃあ32bitでSSEが最強じゃん。

    • by Anonymous Coward

      オーバーヘッドよりもlow memが死ぬ

  • by Anonymous Coward on 2012年09月07日 9時38分 (#2226635)

    自主的にアーキテクチャを選べるOSの中では
    割とスムーズに移行が進んでるような気がします

    • by Anonymous Coward

      そんな時代なのに、Mozilla Firefoxは相変わらず32bitバイナリしか配布していないような……。DebianのIceweaselだっけ?はどうなんだろう。
      もしかしてプラグインの問題かな。プラグインコンテナだけ32bitにするとかできないんだろうか。

      • by aoppana (16506) on 2012年09月07日 10時08分 (#2226646) 日記

        iceweasel はフツーにamd64 版ありますよ。
        sid なんかだと本家のバージョンアップに最初(i386 版より先)に対応してる気がする。

        親コメント
      • by qwerty (20776) on 2012年09月08日 3時05分 (#2227320) 日記

        逆ですね。
        相変わらず32bitバイナリだけ配布していても、移行することが出来るという事です。
        後方互換性の賜物じゃあないですか。
        # x86_64 のバイナリも配布されているという書き込みは棚に置いてます。

        --
        [Q][W][E][R][T][Y]
        親コメント
        • by Anonymous Coward

          64bit環境で動かそうとすると、それなりに環境整備しなきゃいけないんだよね。足りない32bitライブラリを自分で用意しないといけないとか。
          それが面倒で、ずっとFlashで音を出せないまま使ってた。

      • by Anonymous Coward

        公式ビルドでは、4.0からx86_64版は配布されていますが、いつの時代の話でしょうか。
        https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/4.0/linux-x86_64/ [mozilla.org]

        • by Anonymous Coward

          なるほどそんなところに。どうしたら行けるのだろう、教えて(ry
          まあぐーぐる先生に聞いたら教えてくれたけど。
          いっしょに3年くらい前のQ&Aも見つかった。やはりプラグイン関連で64bit版の公開は(当時)前面には押し出していなかったそうで。

          • by Anonymous Coward

            Operaは64bit版ブラウザで32bitプラグインもサポートしているけど、それでも標準でダウンロード・インストールされるのは32bit版。
            Modern Style UIのIE10がFlashしかサポートしていないWindows 8の普及で状況が変わるといいなあ。

          • by Anonymous Coward

            なるほどそんなところに。どうしたら行けるのだろう、教えて(ry

            公式サーバーでビルドされて公式FTPサーバーにありますが、公式にリリースされていないためです。

  • by Anonymous Coward on 2012年09月07日 10時39分 (#2226686)

    popularity-contest パッケージをインストールしていて、なおかつ Debian パッケージ利用調査に参加するよう設定していると週に1回利用状況が送信されるのか。

  • by Anonymous Coward on 2012年09月07日 11時10分 (#2226715)

    という理解で良かったのだろうか?
    コメントを読み進めると何か違う気がしてきた。

typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

読み込み中...