パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Sun、SPARCプロセッサをオープンソース化」記事へのコメント

  • by ikuuya (14857) on 2006年03月27日 23時25分 (#909987) 日記
    すごく単純な意見ですけど、どこぞの誰かが回路図(HDLソース)を解析して、とてつもなく最適化された機械語を吐いてくれるコンパイラとか書いてくれそうですよね、
    それこそ秘孔を突くような、パイプラインの段数とかも考慮に入れたようなのを吐き出してくれるやつ。
    あとは、アセンブラ直書きのライブラリとか。

    #某国産RISCチップの機械語を読んで、Cのコードを書きかえて速度アップをさせた経験あり。
    #そんなに大きなコードではありませんでしたが。
    • Re:回路図の使い途 (スコア:2, すばらしい洞察)

      by lunatic_sparc (15416) on 2006年03月28日 9時46分 (#910203)
      >すごく単純な意見ですけど、どこぞの誰かが回路図(HDLソース)を解析して、とてつもなく最適化された機械語を吐いてくれるコンパイラとか書いてくれそうですよね、
      >それこそ秘孔を突くような、パイプラインの段数とかも考慮に入れたようなのを吐き出してくれるやつ。
      >あとは、アセンブラ直書きのライブラリとか。

      どの辺か、までって話はあるでしょうが、"OpenSPARC" に特化してしまうと "Scalable Processor ARChitecture" という意義が失われてしまうような希ガス。
      親コメント
    • by astro (17245) on 2006年03月28日 10時46分 (#910250) 日記
      Pentium(P5)全盛だった頃、友人がPentiumGCCで再コンパイルすると
      速くなると言って、片っ端から再コンパイルしてた記憶があります。

      昔では386と486でも高速に動かすにはコードの最適化が必要でだったはずです。
      たとえば386ではJumpはDword境界で行ったほうが効率がいいので、
      境界整合のためNOPを入れたりしたようですが、486では意識せずによくなったとか、
      命令ごとのクロックサイクルを意識することもなくなったとかいうのも
      プロセッサの設計からくる最適化ネタですかね。
      親コメント
      • by Anonymous Coward on 2006年03月28日 12時25分 (#910321)
        最適化ネタといえばそうかもしれませんが方向が逆ですね。

        コードの最適化をシリコン上でon the flyでやってしまうことがプロセッサの大きな進化です。CISC命令をRISCライク命令に変換、レジスタリネーミング、アウトオブオーダー、データプリフェッチなどなど、最適化の塊です。デコードステージがやたら長く、実行ステージがわずかなのはその証明ですね。

        そうして、コンパイラはあまり最適化など考えないでよい方向になってしまいました。それはそれでインストラクションアーキテクチャの意味がより大きくなって良いことではあります。

        こってこてのコンパイルをやるというのなら回路図から最適な最適化方法を推定するというのもありかもしれませんが。

        親コメント
        • > コードの最適化をシリコン上でon the flyでやってしま
          > うことがプロセッサの大きな進化です。CISC命令をRISC
          > ライク命令に変換、レジスタリネーミング、アウトオブ
          > オーダー、データプリフェッチなどなど、最適化の塊で
          > す。デコードステージがやたら長く、実行ステージがわ
          > ずかなのはその証明ですね。

           そのはずなんですけどね~。コンパイラが最適化を考え
          なくていいどころか、プログラマーがCのソースコード上
          で、ループアンロールまでやらないといけないのが現実
          だったりして。
           Pentium4 + IntelC++コンパイラですけど、本当のレジ
          スタなんか見えないはずなのに、Cのソース上でループ
          アンロールをはじめとする、姑息な最適化が結構効果が
          あったりしました。
          親コメント
    • by fujihara (4983) on 2006年03月27日 23時34分 (#909995)
      そのあたりくらいの最適化だと、今時のコンパイラは
      普通にやってますよね。回路図解析してまで出すのはさすがにないのかな?
      親コメント
      • by Anonymous Coward on 2006年03月27日 23時56分 (#910010)
        その手の論文も見たことはあります。CPUのバージョンによって乗算機の数とか、パイプラインの制約とかが変わるので、すべてのCPUに最適にするのは難しいね。コンパイラのオプションとかに凝るっていう手もあるけど。 どうせパフォーマンスに関係するのは全体の1%ぐらいなので、そこだけ、最適化したコードを書く方良いと思う。コンパイラに頼る風潮は、「何を最適化したいのか」っていう視点に欠けてる。
        親コメント
        • 率直に言うと (スコア:5, すばらしい洞察)

          by ko-ji.t (21285) on 2006年03月28日 0時18分 (#910025)
          >「何を最適化したいのか」
          人件費です。ハイ
          親コメント
          • Re:率直に言うと (スコア:3, おもしろおかしい)

            by Henrich (121) on 2006年03月28日 9時16分 (#910173)
            >>「何を最適化したいのか」
            >人件費です。ハイ

            人件費は最適化ではなく最小化したいものではないでしょうか?0ならサイコー :-p

            #ホントに適切に払われると困る、という企業多数と見た。

            親コメント
        • by bero (5057) on 2006年03月28日 13時33分 (#910392) 日記
          ていうかそのための仮想マシン化(VM化)じゃなかろうか。
          最適化フェイズは実行時またはロード時、インストール時に行う。
          javaは(もとは別の目的だったらしいから)瓢箪から駒っぽいけど、CLRは絶対狙ってると思う(64bitへの移行も兼ねて)
          親コメント
    • by Anonymous Coward on 2006年03月28日 0時50分 (#910046)
      大学で実践的な回路設計の演習だとか、研究の評価データに使うとか。

      新しいCADシステムを作ってみて、このソースを評価に使うことで
      XX%の性能向上が見込めただとか、どういうトラブルが発生した
      だとか。そういう実践的な評価を行おうと思うと評価用データの
      作成がネックになったりするんですよね。

      それなりに良いデータがあるのかもしれないけど、やはり本物に
      勝るもの無し。
      親コメント
    • by Anonymous Coward
      パイプラインの段数を考慮するような最適化を考える上で、プロセッサのロジックまで考慮する必要があるのですか?
      必要な情報は仕様として提供されていると思いますが。
      • by Anonymous Coward
        ロジックの状態によってリーク値が結構変わるので、
        プロセッサのロジックの状態が最小のリーク値となるように
        ソフトでしむけられないかと言った覚えはある。
        #無駄と即答されたおぼえもある。

日本発のオープンソースソフトウェアは42件 -- ある官僚

処理中...