発売日なので早速朝からヨドバシへ。
ヨドバシは9:30開店なので9:15頃に到着。何人かは並んでいるのではないかと思っていたのですが誰も陳んでいないようです。信号が青になった途端にダッシュしてヨドバシに駆け込んでいく男性が一人。って駆け込んで中に入り込んだようですがなぜ開いてますか。まだ開店時間じゃないはずなのに。っていうか開店時間前に開店してますか。んがー。このダマラム、一生の不覚。
もちろん売り切れてました。終了。
CeBIT前にXpress 3200チップセットを発表してしまったために見せるものが無くなってしまったのでしょうか。
我々はCeBITに思い入れがあるので、ATIのCeBIT不参加という決定には賛同できない。でもこれはお金の無駄遣いだし、CeBITで発表するものが無いのに参加するならば100万ドル浪費することになる。
でも、これはATIがCeBITに出展しないという意味では無い。多分、何処かパートナとブースを共有するかもしれない。例えばドイツのドレスデンに巨大な工場を持つくらい大きなAMDですらここ二年間はブースを共有している。AMDは顧客と組むのが好きだし、今年もそうするようだ。
逆にNVIDIAはCeBITに合わせて大きな発表を行う準備をしている。GeForce 7900 GTX/GTとして製品化されるG71マイクロアーキテクチャが公開されます。そしてGeForce 7600 GT/GSベースのカードも発表されます。この大きな発表はCeBITでお金を大量に使うだけの意味があります。
読んでみたらあまり意味のあることは書いてませんでした。CeBITへの参加が無駄遣いに思える程ATIの台所は厳しいのでしょうか。Creativeも3Dlabsをハイエンド事業から撤退させてしまいましたし、大きな併合や撤退の予感。
Nintendo DS Liteにぶつけてきましたか。
気になる価格ですが、安くて599ドルだとか。記事では「なぜこんなに安い値段を付けられるのかわからない。でも、これは(買う人は)ハッピーだね」とあります。
7600は249.99ドルだとか。6800 GSを置き換えるものと思われます。ATI製品で価格上ぶつかるのはX1800GTO。
GeForce 7900 GTXはNVIDIAが望む程の速度が得られないとか。
INQは、ATIのX1900XTXを打ち負かすには最低でも700MHzが必要としてますから、NVIDIAの目的、打倒ATIを実現するには性能が足りないという話のようです。
この記事では
としていますが、後藤さんの記事ではパイプラインは32本とされているのでINQの前提条件が間違っているのかもしれません。パイプライン24本を650MHzで動かせば勝てる、というのでしたら(* 24 700)で16,800のパワーがあれば勝てるということです。逆算すると(/ (* 24 700) 32)、つまり525MHzあれば勝ち目があります。そこで650MHzですから楽勝といえます。
GeForce 7900の登場に合わせて引退。
GeForce 6800GSを買って喜んでいる私の立場は。
RADEON X1600はメモリは128ビットインタフェースのものしかありませんが、GeForce 6800GSは256ビットインタフェースなのでベンチマーカや購入者の心をガッチリキャッチ。
しかしながら7600は型番からも想像できるように128ビットインタフェイスに据え置かれる模様です。256ビットインタフェースを実装するとダイサイズが大きくなりすぎるようです。128ビットインタフェイスでも性能上、価格上ではこれでもX1600XT/PROと張り合えるという見込みのようです。
さらに一部のベンダは585MHzにオーバクロックしたものを出荷するとのこと。
しかし、ATIは12パイプラインで256ビットインタフェイスのX1800GTOを準備しているので油断できません。
アジアのパートナ各社は、近日発表の7900 GTXにがっかりしている。多くの会社が既にサンプルを入手してテストしているが、その性能によりハッピーとは言えない。最初のテストでは7900 GTXはベストケースで7800 GTX 512の8%から10%上回る性能を示した。
つまり、7900 GTXはATIのX1900 XTXに近付くことになるが多くのベンチマークでは負けることになる。予想ではx4アンチエイリアスとx8またはx16の異方性フィルタを有効にした状態ではX1900 XTXが最速の座を譲らない。
圧倒的な性能を叩き出すはずの7900ですが、あまり芳しい状態ではないようです。
Intelの次期グラフィクスコアに対する後藤さんの記事。
この時期でもDirectX 10対応という話です。つまりピクセルシェーダとバーテックスシェーダとの区別の無い統合シェーダになるかというと、そういうオプションは無いようです。汎用プロセッサになってしまうとトランジスタ効率が下がるか性能が下がってしまうのでバーテックスシェーダとピクセルシェーダという使い分けがなされている間は、別のハードウェアとして実装してアプリケーションからは隠蔽してしまうアプローチでも問題は起きないでしょう。
ピクセルパイプラインは4本とのこと。これは、以前の笠原さんの記事ではシェーダエンジンは8基
ということなので、バーテックスシェーダが4、ピクセルシェーダが4の合計8ということでしょうか。後藤さんの記事でフィルレートから逆算したコアクロックが666MHzと推測しています。666MHzというのはかなり高く、これはGeForce 7900と同等のクロックです。これは高すぎるように思えます。フィルレートの数値は確定しているようなので、実はシェーダが8つで周波数が333MHzなのではないでしょうか。ただ、トランジスタを増やしてダイサイズを大きくするというのは価格をあげたくないIntelとしては避けたいところ。小さいコアを作って高クロックで駆動させるというのは考えられるオプション。しかし、トランジスタがかなり増えているということとDirect X10の統合シェーダに対応しているということ、シェーダが8つという情報もあること、4つのシェーダでは周波数が高くなりすぎることから8パイプラインの333MHzではないかと考えます。つまり、Intelは本気でDirect X10の統合グラフィックスを取りにきています。
もっとも、Intelはいつでも本気ですが。
というわけで(なにがだ)誕生日おめでとうございます。
hotplugとかmurasakiとかudevがピンチ。
というわけで、先日の続き。
小寺さんからの返答とも言える記事が掲載されました。タイトルからして「ブログにおける情報の重さ」と、こちらの意図は全然通じていないようで残念な限りです。もっとも、「信頼関係の構築方法」などの後で書くつもりでそのまま忘れてしまった部分があるので私が悪い。このあたりについては小寺さんは「ブランドが普及する仮定」として一節費して取り上げてくださっているので大体安心。
さて、3ページめに次のような記述があります。
ブログにおいては、まじめな姿勢で情報発信に努める人と、まあ個人だし日記だし適当に書きたいこと書ければいいやぁ、という人の間に、見た目の差が発生しない。ブログ以前のホームページには、それにかける労力という面で、見ればすぐにわかる差があったんである。
私は情報の価値はメディアを問わない、つまり情報自体の価値で決まるし、その重さは発信者で決まるという意味で書いたつもりだったのです。しかしながら「見た目の差が発生しない」という一言からこのあたりは伝えきれていないと感じました。blogにおける見た目というのはたいした意味はなく、重要なのは中身です。そしてその内容を問うには、誰が書いたかというのが大きなポイントです。直接、間接的な利害関係者が書いたようなものでは当てになりません。「Pentium 4はAthlon XPより速い」という内容の記事があっても、それを書いた人がIntelの中の人だった場合には信用できません。内容がでたらめかどうかも重要ですが誰が書いたかが重要なのは情報の客観性を判断するのに必要だからです。逆に見た目はまったく評価対象になりません。たとえばセキュリティホールmemoは見た目はシンプルですが、だからといって内容が無価値である訳ではありません。見た目は見ため、中身は中身です。
新聞や書籍、テレビなどで意見を表明するのにはかなりのコストがかかります。「見た目に差がある」HTMLというのは同様に手間暇といったコストをかけた結果です。しかし、見た目で勝負するのではなくて内容で勝負する場合、「見た目に差が無い」状態でも問題ありません。むしろ、見た目に流される人をフィルタリングするためや、見た目だけで先入観を持ってしまう人に対する対抗策としては見た目には差が無い状態の方が好ましいと思えます。見た目が良いから大丈夫、と判断する精神はテレビだから、新聞だから大丈夫、と判断する精神と同じ構造です。
ブログだから情報が重い、もしくは軽いと「メディア」で判断するのではなく内容で判断すべきものなのです。
テレビだってドキュメンタリがあったり娯楽番組があったり、テレビというメディアは同じでも内容で重さが違うはずです。
Nintendo DSはボタンが若干斜めに付いているそうです。基板上、ボタンのベース部分は斜めになっているのでしょうか。分解レポートでは特に傾いているようには見えませんが。
午後の紅茶は甘すぎる。そんな誤解をしていませんか。
ですとか、
この味で低カロリー
というので甘さが抑えられたのかと思って買ってみたところ、いつものように甘すぎる。甘すぎました。
「甘すぎる」というクレームに対して「甘いけどカロリーは少ない」と言ったところで効果は無いような気がします。問題はカロリーの多少ではなくて甘いか甘くないかです。
アセンブラの書き方が大きく変わりそうな予感。というのもMacro-Fusionが比較命令と条件分岐を一つの内部命令に変換するという記述があるからです。PA-RISCか。
今までは
と書かずに
と書いていました。というのも比較命令(cmp)の結果が反映されて分岐命令(jne)が読み出せるようになるまでに遅延があるので、cmpの直後に書くのは無駄だったのです。大抵2,3命令くらいはさんでおいたり無意味にいつくまで命令を詰め込めるだろうか(比較をどこまで早めに行えるか)、とかチャレンジしたものです。
このようなPentiu以降のCPUに向けた調整をMacro-Fusionはどこまで認識できるのでしょうか。x86命令レベルで比較命令と分岐命令を統合するようなので、インストラクションキューの深さによると思いますがキューにはどのくらいため込んでおけるのかは見えてきません。キューは1サイクルで6命令取り込むそうですらキューの深さが6命令ということは無さそうです。コンパイラが生成したコードであれば6命令あれば大抵の比較命令と条件分岐は射程内に捉えられそうですし、手書きのコードでも12命令ほどあれば95%はカバーできるのではないでしょうか。
意外にもピクセルシェーダの数は24本と据え置かれてきました。Inquirerの記事が正しかった訳ですがそうなると700MHzのクロックがひつようという話になります。
4gaer.netの記事によるとマルチクロックドメインになっていてバーテックスシェーダとピクセルシェーダは動作クロックを変えているそうです。今朝は4gamer.netのサイトが復活していたのですがまたダウンしているので詳細が判りません。
NVIDIAはATIのRADEON X1900xTXとの比較で「ALU換算ではピクセルパイプは48本に相当する」と主張しているようですが、とりあえず演算能力がどの程度なのかMFLOPSなどの数値で示してほしい所。そもそも7800のピクセルシェーダとはALUの数が違うのでしょうか。
私はプロセスルールの変更によりトランジスタをさらに上乗せしてくると思っていたのですが減らしてきたというのが意外。DirectX 10の統合シェーダを視野にいれているのでしょうか。
ALUの数だけを考えると積和演算が可能な48個のALUを持つGeForce 7900と積和演算が可能な48個のALUに加えて積和演算はできないシンプルなALUを48個備えるRADEON X1900ではRADEONの方が速くなりそうです。解像度を高くした場合やアンチエイリアス、異方性フィルタリングのようなそれほど負荷が少ない演算を行うケースではパイプラインが多いRADEONの方が並列処理がしやすい分速くなるはず。GeForceの方が速くなるケースというのは積和演算を多用するシェーダを動かしたときくらいでしょうか。そんなシェーダプログラムを動かすのかどうか。
帰宅が日付が変わってからだったので、寝過ごすだろうと思っていたのですが7:40頃に目が覚めてしまったのでとりあえずヨドバシに。
8時を少し過ぎたくらいに到着したら、東側入り口に数人の人だかりが。意外と少ない? と思ったら北側まで行列が続いていて、途中には毛布にくるまっている人がいたりして。これは徹夜組か何かでしょうか。さらに最後尾はどこかと思ったら行列はさらに西側まで続いていて、北東角から南西角までを埋め尽くしていました。
というわけで敗北。
せっかくだからビックカメラも見てみましたが、こちらにはクリスタルホワイトは無いとのことなので却下。
殺さないのに「必殺技」とはこれ如何なるものか。
「得意技」と言い換えるべきではないか、という展開になるのですが、大抵の場合での必殺技というのは勝負を決める役割があるのでただの得意技ではニュアンスが違います。というわけで、必ず倒す、という雰囲気で「必倒技」というのはどうか。「必倒技・イナバウアー!! こけたァーッ!!」みたいな。こけてどうする。
気が向いたのでひたすらに練習。
PSR-290にはメモリに録音するというナイス機能があるので試しに録音したら、あっはっは。
薬指が特に弱いようで音が小さい。あと、どうして鍵盤楽器というのはまっすぐなんでしょうかね。オクターヴ超えになると指が届かなくて隣の鍵盤と同時押ししてしまうのを鍵盤のせいにしているわけですが、弧を描いている方が正しい姿のような気がします。しかしそういうピアノは見たことがありません。
「使わない無駄なキーは取り外した」とかいうキーボードがあったら面白いな、とか。A#は要るだろ、とか、いや要らない、とか使用頻度の低いキーはFnと同時押しとか。
ちっともハッピーになれそうにありません。
持ち運びやすさだけを考えるとロールピアノが近いのかも。
You Tubeでライブ映像を見てしまったので無性に弾きたくなってしまいました。弾けませんが。
そんな矢先、オフィシャルスコアブック坂本龍一「/04」が発売されるというので思わず購入。ついでに、PSR-290用のフットスイッチFC-5も追加。
気持ちのいいピアノが鳴るキーボードが欲しい今日この頃。
喧々囂々?
延期の理由にはBlu-ray Discの規格化が遅れたためとありますが、既にドライブ単体で売ってたりしませんでしたっけ。今販売されているのは企画未対応? 論理フォーマットが未定というだけだからハードウェアとしては問題ない?
ピアノの弾き方についてググると、「脱力」「旋回」といった言葉が出てきます。
この旋回という言葉の示す動作が判りません。回転軸がX/Y/Zのどれなのか。つまり、ピッチを変えるのかロールするのか、ヨーを変えるのか。最近、ヨー角を変える動きがぎこちないような気がしてならないのでこの方向で手首を動かすように心がけてはいますが。
あとは薬指。中指で鍵盤を押さえたまま薬指と小指でトリルしようとすると指がもたもたします。
手元にあるCD-Rメディアが650MBのものなのですが、Fedora Core 5のISOイメージを記録するには700MBのメディアが必要という罠にはまりました。
仕方がないのでCD1とレスキューディスクだけ作成してネットワークインストールしようと思ったのですがプロンプトで linux と入力した時点でリブートしてしまい失敗。loading vmlinuz.... というような表示は一瞬見えるのですがなぜここでリブートしてしまうのかがわかりません。
yum upgradeで更新。さらに罠が。
X11がRelease 7になっているのですがこのために imakeやxmkmfが無くなってしまいました。つまりローカルディレクトリブラウザ(仮)の開発が困難に。ピーンチ。
- [bee@mpc101 ~]$ rpm -qf `which xmkmf`
- xorg-x11-devel-6.8.2-37.FC4.49.2
- [bee@mpc101 ~]$ rpm -qf `which imake`
- xorg-x11-devel-6.8.2-37.FC4.49.2
autoconf/automake自体はGPLですが、これを利用するプログラムはGPLにしなければならないのでしょうか。理屈の上ではそんなことにはならないのですが、たとえばautoscanで生成するconfigure.scanはGPLなのでしょうか。もしGPLだとこれを修正して作成したconfigure.inもGPLになりますし、そのconfigure.inを取り込んだプログラムもGPLに。
そんなことにはならないような気はしていますが、どこかに明文化されていないものでしょうか。
そんなことを気にするくらいならautoconfを使わない方がてっとり早いという気もしますが。いまのところXawが使えないならGtkを使う(逆だろ)みたいなビルド環境に応じてコードを変更する仕組みはいれていませんし。
携帯端末なら画面解像度も高くないのでPC用や専用ゲーム機ほどの性能は不要です。
ピクセル解像度はHDTV/1080pだと1,920×1,080で、PCでも1,280×1,024、ハイエンドなら1,600×1,280といった解像度でさらにアンチエイリアスをかけたりしますが今時の携帯できるDVDプレイヤでは800×480くらいです。
| 名称 | 解像度 | 画素数 | DVDプレイヤとの比率 |
|---|---|---|---|
| 1080p | (* 1920 1080) | 2,073,600 | 5.4 |
| PC | (* 1600 1280) | 2,048,000 | 5.3 |
| DVDプレイヤ | (* 800 480) | 384,000 | 1.0 |
ピクセル解像度だけを見れば、20%程度の性能があれば余裕、と。アンチエイリアスが要らないか、倍率を×4位にとどめておくならばさらに下げられそうです。また、液晶でしょうからリフレッシュレートもそれほど高くないはずで、書き換え頻度が多くなければあまり性能は要求されないように思えます。
先日、NVIDIAがHybrid Graphicsを買収したのはこの布石かも知れませんね。
PSE法が中古販売に対して「実質容認」と言う流れだそうです。立法や行政はライブドアの時間外取引から何を学んだというのでしょうか。
電話網が株主の物だというのなら設備負担金を返還していただけないですかね。
コマンド実行の失敗をハンドリングしてみました。
エラーメッセージをfork元に通知しようとして文字列を生成してそのポインタを渡そうと思ったのですがコーディング中にアドレス空間が別だということに気がついて、とりあえずメッセージ番号だけを通知することに。
XClientMessageEvent::data.l[]ってlongなのですが、64ビット環境ではlongのままなのでしょうか。ネットワーク的にアレなので32ビット整数になっているような気がしてならないのですが。
ポインタの伝達にこれを使っているのですが、64ビット環境でははみでる予感。