トップ 最新 追記

U-memo

2006|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|08|
2009|08|10|
2010|02|03|
2011|11|12|
2012|04|
2016|02|
All= / Today= / Yesterday=

2008-02-05 [長年日記]

_ [雑記] Fedora8 on VMware

Fedora Core 6 の対応終了からしばらくたつので 8 に乗り換え。 Upgrade は依存関係の解決がどうしてもうまくいかなかったので 新規インストール。 こういうときのために /home は別パーティションにしておくとよいとか。

なんか VMWare-Tools を入れなくてもマウスが壁を乗り越えてる? (それとも過去の残骸を何か踏んづけたか?)

しかし、 VMWare-Tools を入れても解像度が 1024x800 より上がらない。 困ったなぁ。xorg.conf 直に 1280x1024 設定すると X が立ち上がらないから何か別の原因があるんだろうけど。

これか。VMWare Player の vmx ファイルにかいてある制限を直に食らっていた模様。FC6 のときは問題なかったのになぁ。

# Higher resolution lockout, adjust values to exceed 1024x768
svga.maxWidth = "1280"
svga.maxHeight = "1024"

_ [雑記] プログラミング言語 Verilog HDL

クソワロタ!


2008-02-07 [長年日記]

_ [雑記] CentOS 5 の gs (8.15)

これはどう見てもバグだよなぁ。 CentOS5 の GhostScript が Text の「→」を90度回転させやがる。 他の環境でレンダリングすると正しく「→」向きで表示するから、 postscript ファイル自体が壊れているわけじゃない。

で、gs を最新版(8.61) に(四苦八苦して)入れ直したら、 gv, evince がこけるようになったし。


2008-02-15 [長年日記]

_ [雑記] GPCC2008問題 発表

  • Celtis改
    • 対戦は現在は予定されていないとのこと
  • ブロックスデュオ(続)
  • 固定ピースヘキソミノ

_ [雑記] ブロックスデュオのプログラム

三輪さん(二位)も公開されている


2008-02-27 [長年日記]

_ [雑記] 半月放置

平日は仕事、休日は呆けていただけだが。

_ [プロセッサ] ハードウェアマルチスレッド方式

最初に考えたのがSMTを持たないインオーダー・スーパースカラのシングルコアCPUなのか、単純なスカラCPUのデュアルコアなのか

個人的にはボトムアップ思考つまりマルチスレッドの極限を考えた結果だと思うけれど、 どちらが先というわけでも無いというのが正直な所だと思われる。

ハード的にはダイ面積と性能(とコスト)のトレードオフが問題であって、キャッシュを今以上に大きくするよりもコアを大きくする方が性能が上がるからこうなった、と言う話だと思う。

もっと単純に、初期の実験段階では市場に受け入れられないリスクを勘が得手まで大きなコストをかけられなかったのでCGMT(Itanium2型), FGMT(Intel の HT など) しか怖くて出来なかった、というだけかもしれない。今はマルチスレッドは AMD (と Intel Xeon) 以外は常識だからマルチスレッドありきならどうするか、と言う方針で設計しても怖くない。

裏の事情として、「コア数を増やす」ことに一つの足かせがあることが挙げられる。ハードウェアマルチスレッドが登場した理由の一つでもあるのだが、データベースの代表である Oracle の値段設定:

ライセンスが必要なプロセッサ数をカウントする場合、オラクル製品がインストール、若しくは稼動する全ての「物理的」なプロセッサをカウントします。但し、ひとつのチップ上に複数のコアをもつ「マルチコア・プロセッサ」が搭載されているハードウェアでご利用いただく場合には、総コア数に以下の係数を乗じた数(小数点以下端数切り上げ)が必要ライセンス数となります。

マルチスレッド方向に増やす分にはソフトライセンスが増えることは無い。これに対しコア数を増やすと、サーバを運用する立場からすればコストがかさむことになる。 CPU 単体で性能が出ても売れなければ意味が無いのでハード屋の設計思想にも跳ね返ってくる。

つまり、価格性能比を考えたとき、ソフトのライセンス量が(特にサーバでは)無視できないので、コア数を増やす(ことによる数の暴力でのシステム性能向上)のではなくスレッド単体性能で稼ぐ必要があなる。

他にスレッド数を増やす方向 (Niagara はまさにその方向でもある) も考えられるが今のところは Niagara だけですな。

Sun は Niagara, Niagara2, Rock ともにコア数が多いけどこのソフトライセンス体系が嫌で MySQL を買収したんじゃなかろうか。

最終的にはL1キャッシュの共用が最も効果的と書いた事がある。

Rock は仕方なくやったという気がしないでもないけれどもね。 それでさえ 250W って正気じゃないよー。

共有すれば性能が確実にあがるわけじゃなくて、そのためには スレッドが鑑賞することによるスラッシングが起きない(起きにくい) ように way数 (set数) を増やす必要がある。 低レイテンシでさっと取り扱いたい L1キャッシュにこれは重荷で、 ただ SMT でおおよその手応えは得られたから... という感じだろうか。

まとまらずに終わる。

本日のツッコミ(全2件) [ツッコミを入れる]

_ うんの [おひさしぶりです!(笑) ひさしぶりなのに、さっそく typo 指摘してみたり: 勘が得手 スレッドが鑑賞する ..]

_ ukai [いやーん < typo 2とかだと異なるプログラムながしておしまい、っつーのに対してそれより多くなると人間の並列度..]