follow us in feedly

書評:ビッグブルース ― コンピュータ覇権をめぐるIBM vs マイクロソフト

f:id:hassyX:20140617150550p:plain

IBMマイクロソフトの共同事業となったOS/2の開発風景を通して、官僚主義に陥っていたIBMの醜態を描いたドキュメンタリー。原著は1993年に出版された。



本書を読んで、これほど官僚的な組織がアメリカに存在し得たのだという事実にただただ驚いた(実際にはその官僚主義的な振る舞いによって、90年代初頭には死に体に陥ってしまうのだが)。著者はPCとOS/2の開発に関わった多数の関係者からヒアリングを行っているようで、IBM側の登場人物が揃いも揃って大局的な観点を持たず、体面や社内の都合のみを偏執的に優先し、時には行き過ぎた完璧主義によって身動きが取れなくなる様を執拗に描いている。

話の主題がOS/2にあるので、マイクロソフトIBMの確執がふんだんに出てくる。作中のマイクロソフトIBMのやりとりを見ていると、80年代中頃のIBMは、長期的な視点で商売を展開できるメインフレーム事業は別として、生き馬の目を抜くPC事業に付いて行けるスピード感覚をまったく持ち合わせていなかったことが分かる。作業者が意思決定を行うためには、何層にも及ぶ管理職達の階層構造をくぐり抜けて承認を得なければならなかった。

プログラマ的観点から見ると、コードの評価基準を「行数が多ければ多いほど良い」としていたという事実だけで、プロジェクトに暗雲立ち込めていたことがありありと感じられると思う(IBMの開発者が書く冗長なコードは、マイクロソフト側の悩みのタネでもあったようで、マイクロソフトの開発者が33000行のコードを200行に縮めてIBMと一悶着を起こす話が出てくる)。

作中、IBM的感性から逸脱した(ように見える)エグゼクティブが登場し、硬直したIBMに改革を起こすのではないかと期待される描写が何度かあるのだが、彼らも眼前に立ちはだかる官僚機構と、社員の一人一人にまで染みついた官僚的意識に逆らうことができずに消えていく。消えていく…と書いたが、実際には結構な数の人物が、プロジェクトを失敗させて会社に大損害を与えているにも関わらず、「出世している」という事実にも驚かされる。

80年代中頃から90年代初頭までの、会社を蝕んだ官僚主義の泥沼からIBMが立ち上がるには、93年にCEOに就任したルイス・ガースナーの登場を待つことになる(彼がIBMの企業文化を改革していく様子は、「巨象も踊る」に描かれている。これも面白い本なのでオススメ)。

本書の後半では、IBMRISC戦略やワークステーション事業についても語られている。終わったことに対して部外者が「ああすればよかったのに」と蒸し返すのは野暮ではあるのだが、IBMが80年代中頃から90年代初頭までに、移り行く市場に対して適切に振る舞うことができずに、その手から拾い逃したものがいかに大きかったのかを、この本を読むことで理解することができると思う。

総評

官僚主義の怖さが部外者にも痛いほどわかる本。是非一読をお勧めしたい。

1ページに二段組みで文字がビッシリ、ページ数も多く結構な分量がある。丁寧に取材して書かれているようなので、PC勃興時のIBM/マイクロソフト両社の歴史を知る意味でも有用に思う。

ビッグブルース―コンピュータ覇権をめぐるIBMvsマイクロソフト (アスキーブックス)

ビッグブルース―コンピュータ覇権をめぐるIBMvsマイクロソフト (アスキーブックス)

巨象も踊る

巨象も踊る

誰が実際にLinuxを開発しているのか?その答えはあなたを驚かせるかもしれない。

Linuxカーネルに最も貢献している人(組織)が誰なのかを、Linux Foundationの年次報告書から探る、というお話。OSS界隈の知識が多少なりともあるプログラマにとっては既知の内容だと思いますが、各組織の貢献度が細かな数字で表されているのは良いかなと思います。

元記事:Who actually develops Linux? The answer might surprise you | ExtremeTech


f:id:hassyX:20140407123846j:plain

もし私が、オープンソースプロジェクトについて考えるようにあなたに命じたとすると、恐らく心に浮かぶ最初の言葉はLinuxでしょう。(FirefoxまたはApacheを思い浮かべたかもしれませんが、議論のためにLinuxについて考えたとしておきましょう)。それから、オープンソースが実際にどのような意味を持つのか、ということを尋ねたとしたら、おそらくはこう言うでしょう。「オープンソースとは、誰でもコードを自由に利用できることを意味し、それはたいてい、世界/インターネットをより良い場所にするために、無償で労働力を提供する多くの独立したプログラマによって開発されています」。そう、それはLinux FoundationのLinuxカーネルについての年次報告書を読むまでに、私が考えていたのと同じことです。このレポートの内容はあなたを驚かせるかもしれません。

f:id:hassyX:20140407124134j:plain

まず最初に、上記の図表を見てください。このグラフは、バージョン3.0から3.10の間にLinuxカーネルに貢献した全てのパッチの内訳を表しています。貢献の80%以上が、巨大な営利企業に雇用されている開発者からであることがはっきり分かるでしょう。報告書は、Linuxカーネルに貢献する無償の開発者の数が長年ゆっくりと減少しており、今現在は13.6%(前回の報告書では14.6%)であることを述べています。

当然のことながら、Red Hat — 数少ない成功したドットコム企業のひとつ — は最も力のあるメンバーです。Linux Foundationは、この一年間でモバイルおよび組み込みシステムの企業(SamsungTexas Instruments、Linaro)がかなり増加している、と報告しています。去年の報告書では、これらの3つの企業は、カーネルの変更分のちょうど4.4%に貢献していました。今年はおおよそ11%程度となっています。Linaroとは、LinuxのARMサポートを改善する目的のために、ARM、Freescale、IBMSamsung、ST-Ericsson、そしてTexas Instrumentsによって設立された非営利組織です。非営利とはいっても、それはLinaroの開発者がお金をもらわないということではありません。

f:id:hassyX:20140407124229j:plain

この報告書はさらに、リーナス・トーバルズ(リナックスの創造者、およびプロジェクトの全面的な調整者)が、パッチ適用のプロセスに直接関与しなくなっていると報告しています。トーバルズは、バージョン3.0と3.10との間に568個のパッチ(0.7%)をコミットしました。最近、彼はサブシステムのメンテナ(彼らの大部分はRed HatIntelGoogleなどの高給取りである)にサインオフを委任しました。

このレポートで最後に目を引く所は、カーネルのコード量が膨張していることです。Linux 3.0(2011年7月)とLinux 3.10の間で、230万行を超えるコードがカーネルに加えられました。Linux 3.10の時点で、Linuxカーネルはおおよそ1700万行ほどの分量でした(この記事を書いている時点でバージョンは3.13まで進んでいます。よって、コード量はもっと増加しているはずです)。カーネルを構築するファイルの数は、37,000から43,000まで増加しています。Linuxカーネルが1991年に最初にリリースされた時、コードの行数は一万行ほどでした。このインフレーションの大部分は、ドライバおよび新しいファイルシステムのサポートによります。ビルドプロセスの際には、あなたのハードウェアによって実際に要求されるコード行だけがコンパイルされることになります。実際のところ、それは1700万行のうちのごく一部分になるはずです。

なぜLinuxが今、主に高級取りのエンジニアによって開発されているかに関しては、考えられる理由が無数にあります。最も明白で注目せざるを得ない理由は、これらの大手企業がLinuxの継続的な健全性に対して、商業的な関心を持っているということです。10年前、Linuxは愛好家およびスパコン企業のおもちゃでした。今日、それは、スマートフォン(Android)から無線通信ルーター、そしてセットトップボックスまですべてに動力を供給します。Linuxへの商業的な関心は、報告書の中の別の統計によって強調されます:2011年中頃、191社の企業だけがLinuxカーネルに関与していました。2013年の終わりまでに、その数は243社にまで増加しました。

実際に、私たちは、これらの企業が自社の商業的ニーズのために、Linuxの開発を歪めているようには見えないことを感謝すべきです。それはオープンソースのマジックであり — そしてトーバルズとカーネル・メンテナ達の、厳格で無慈悲な支配によるものです。

詳解UNIXプログラミング 第3版

詳解UNIXプログラミング 第3版

Linuxプログラミングインタフェース

Linuxプログラミングインタフェース

Geforce GTX780TiのBitcoin採掘スコア

Radeon R9 290Xの対抗機としてNVIDIAが市場に送り込んだGeforce GTX780Tiですが、ビットコイン採掘のパフォーマンスは大して振るわないみたいです。

EXTREMETECH: GeForce GTX 780 Ti: Nvidia strikes back, retaking the performance crown from AMD(3/4)
f:id:hassyX:20131224114320p:plain

アーキテクチャ的に現行Geforce(Kepler)のビットコイン採掘パフォーマンスが振るわないのは周知の事実だったので(ここら辺を参照)、GTX780Tiでも現状は変わらないということですね。

R9 290Xは、前世代ハイエンドのHD7970と比較して30%以上採掘能力が向上してます。780TiはTitan比で10%程度の向上です。R9 290Xと780Tiは2倍以上の性能差があります…

AMDは当面GCNアーキテクチャをベースに拡張していく方向でしょうから、次世代モデルでも採掘市場におけるRadeonの絶対的な採掘パフォーマンスの良さは続くと思います(NVIDIAの頑張りによって、AMDの相対的な地位が低下する可能性はありえる)。

AMDにとって、Radeonの採掘需要は結構な追い風になっていると思うんですが、 ビットコインの市場がこれからも持ちこたえられるのかがちと心配ではありますね。

AMDがBitcoin採掘でNvidiaを打ち破る、差はいつ埋まるのか(2/3)

AMDがBitcoin採掘でNvidiaを打ち破る、差はいつ埋まるのか(1/3) - 更地 の続きです。

ビットコイン採掘のパフォーマンス

まずは、rpcminerを使用して、最適化されていないTitanのOpenCLカーネル(cgminer 2.11使用)と、より最近のCUDAに最適化されたカーネルのGTX 680に対するパフォーマンスを見ていこう。rpcminerとcgminerは共通のコード・ベースを共有しているので、OpenGLを使用する場合のパフォーマンスは同等である。最適化されていないテストのために、我々はpoclbmカーネルを選んだ。最適化されたテストの方では、修正されたCUDA対応カーネルを使用した。このカーネルNVIDIAのカード用の自動設定が使用できるのだが、我々は手動設定も試してみて、スレッドの数とグリッドサイズの数の調整を試みた。だが、手動設定によるオプション変更では、パフォーマンスを有意に向上させることはできなかった。

テスト環境は、Intel Core i7-3770K、8GBのRAM、Asus P8Z77V-Deluxe、電源はThermaltakeの1275W 80PLUS Platinumである。AMDRadeonは、すべてdiakgcnカーネルを使用するように設定された。パフォーマンスと電力消費量は2時間記録された。不安定なCUDAの採掘パフォーマンスを安定させるために、これだけの時間を要している。

Bitcoinの採鉱では典型的に、与えられたカードのハッシュレートは安定し続けるものである。CUDAによる採掘処理では、GTX 680とTitanの双方のスコアが乱高下しているのだが、このような大きな変動が生じる原因はよくわかっていない。これらのカードのパフォーマンス値は、測定における平均ハッシュレートを表している。

f:id:hassyX:20131216013934p:plain

注意すべき最初のことは、Titanのスコアが、単純なコア数の増加やクロック速度から説明されるものよりも、はるかに高速であるということである。CUDA向けに最適化すると、双方のコアで約20%のパフォーマンスの改善をみる。NVIDIAは、GK110が数学的なワークロードで大幅に改善されたパフォーマンスを提供すると約束しており、その事実はここにもよく現れている。同一の2枚のカード間で最大17%に及ぶスコアの改善は、GTX Titan上で実行するために、NVIDIAのドライバがコードを自動最適化することを示唆している。

GK110はGK104よりも大幅に高速だが、この結果にRadeonのデータを追加すると何が起こるのだろうか…

f:id:hassyX:20131216014019p:plain

なんてこった。$149のRadeon 7790が、Titanの80%の性能を、15%の価格で提供している。Radeon 7970においては、Titanの半額で性能は2倍である。CUDAで高速化されたカーネルでさえ、NVIDIAのハードウェアをAMDと同じ土俵へは登らせてくれない。Titanは561mm平方のダイと71億トランジスタGPUであることに留意してほしい。Radeon 7790が112mm平方サイズのダイでTitanに匹敵するパフォーマンスを発揮するという事実。

以下に示すように、もし我々が消費電力(MHash/ワット)、または初期費用とハッシュレートに基づいたGPU効率を考察したとしても、状況は同じように、まったく不均衡である。

f:id:hassyX:20131216014053p:plain
f:id:hassyX:20131216014101p:plain

AMDNVIDIA間のGPGPU性能の詳しい説明はこの記事の範囲外だが、いくつかのパフォーマンスチェックを行ってみることにしよう。下にあるのは、OpenCLベースのLuxmark 2.0ベンチマークの結果である。GTX 680、GTX Titan、HD 7970およびHD 7790の結果はすべて、ここに記載されている。

f:id:hassyX:20131216014112p:plain

GTX TitanはGTX 680と比較すると大きな改善が見られるが、それはまだ、HD 7970の半分程度の性能である。

(次のページに続く)



GIGABYTE ビデオカード R9-290搭載 GV-R929OC-4GD

GIGABYTE ビデオカード R9-290搭載 GV-R929OC-4GD

GIGABYTE ビデオカード R9-270X搭載 GV-R927XOC-4GD

GIGABYTE ビデオカード R9-270X搭載 GV-R927XOC-4GD

AMDがBitcoin採掘でNvidiaを打ち破る、差はいつ埋まるのか(1/3)

ちと古い話題になりますが(2013/4)、ビットコインの採掘でRadeonが良い結果を叩き出している件について、EXTREMETECHが検証記事を出していました。3ページあるので、1ページずつ訳していきたいと思います。

元記事はこちら。
AMD destroys Nvidia at Bitcoin mining, can the gap ever be bridged? | ExtremeTech

結構意訳した部分があるので、間違いなどあれば指摘頂けると有難いです。

f:id:hassyX:20131210120805j:plain

はじめに

もしあなたがゲーミング環境でのGPU性能に詳しく、そしてビットコインの採掘に興味を持ち始めていたとしたら、ゲーミング市場での実情とは真逆に、AMDがパフォーマンスリーダーであるという事実に驚くだろう。

これは、PCグラフィックス市場において、AMDのHD7000シリーズがNVIDIAのGK104(Geforce 600シリーズ)に後塵を喫していた事実とはまったく対照的だ。ビットコインの採掘においては、状況はほぼ完全に逆転する。Radeon HD7970は、550M/秒でのハッシュ値計算が可能だが、GTX 680はおおよそHD7970の1/5の速度しかない。

Bitcoin Wikiに、この性能差を説明しようとした記事があるのだが、2011年以来更新されていない。その記事は、FermiAMDVLIWアーキテクチャを参照し、AMDの優位がNVIDIAよりもはるかに多いシェーダコアを有するためである、と結論付けている。

この結論は不正確であり、GTX 680がはるかに多くのコアを有するにもかかわらず、ビットコインの採掘でGTX 580よりも遅い理由を説明できていない。

この記事では、改良されたCUDA MinerがAMDNVIDIA間のパフォーマンス差を大幅にシフトするのかどうか、またNVIDIAGPGPU性能が最近のAMDのそれに匹敵するかどうか、ということに言及し、過去の記事との違いを説明しようとするものだ。

この記事で説明しないトピックは次の通り:

  • ビットコインのバブルについて。
  • 投資機会について。
  • ASICが 来月 今夏 将来現れた時に、GPUによる採鉱市場を破壊するかどうか。

これらは重要なテーマではあるが、この記事の焦点ではない。我々はある程度まで、出力効率およびワットあたりのハッシュ生成量について議論するだろう。これらの要因は、AMDNVIDIAの採掘パフォーマンスの比較に影響を及ぼすからだ。

採掘の仕組み

ビットコインの採掘は、SHA2-256アルゴリズムの具体的な実装である。AMDのカードがビットコインの採掘において優れている理由の1つは、整数演算性能を増強する多くの特徴を持っているからだ。これは本当に風変りである - GPUのワークロードは、テクスチャがhalf(FP16)またはfull(FP32)の精度で格納されているという理由から、歴史的に浮動小数点演算性能を重視してきた。

問題は、NVIDIAがCUDAを推し進めた時に、Geforceの主な利点としてパスワード解析を強調したという事実によって混乱させられる。G80から始まるGeForce GPUがCPUより著しく高い暗号化パフォーマンスを提供したのは事実だ。しかし、AMDのハードウェアは今、NVIDIAのそれを凌駕している

AMDのカードが、ビットコイン採掘でNVIDAを超えるパフォーマンスを発揮する第一の理由は、SHA-256アルゴリズムが32ビット整数の右ローテート命令を利用するからだ。これは、整数値がシフトされる(説明はここで)けれども、シフトによって失われたビットは元の値に再設定されることを意味する。右シフトでは、右端から消えたビットは左端に設定される。AMDGPUは、1ステップでこの操作を行うことができる。しかし、GTX Titan以前のNVIDIA GPUでは、2回のシフトと1回の加算の計3ステップを要する。

「GTX Titan以前」と表現したが、これはNVIDIAがCompute Capability 3.5(GTX Titan と Tesla K20/K20Xでのみサポート)でファネルシフタを導入したからである。ファネルシフタはオペレーションを結合でき、3サイクルのペナルティを削減できる。これはGK104からGK110への唯一の改良点ではないので、我々は直ちにパフォーマンスがどのように改善されていくか見ていくことにする。GK110はまた、1SMX(Titanは14個のSMXを持っている)あたり最大64個の32bit整数をシフトすることができる。対照的にGK104は、1SMXあたり32個の整数のみをシフト可能で、8個のSMXブロックしか持っていない。

f:id:hassyX:20131210121400p:plain

この図は、CC 3.0とCC 3.5の間での32ビット整数シフトの機能差をハイライトしている。

AMDは、GCN(Graphics Core Next)の32bit整数演算性能を公表していない。しかし、同社はGCNが倍精度浮動小数点と同じ速度で32ビット整数値のコードを実行することを確認している。これは、1CUについて、1クロック当たりの論理的なピーク値が、32bit整数値を64個処理可能であることを意味する。これはGK104の2倍である。

それ以外のAMDの利点としては、GPUを構成する演算ユニット(CU)が膨大な数であることだ。Titanは、我々が述べてきたように、HD7970の32個のCUと比較して、14個のSMXを持っている。CU(Compute Unit) / SMXの数の方が、これらの文脈におけるコアの総数よりもはるかに重要なのかもしれない。

(次のページに続く)



GIGABYTE ビデオカード R9-290搭載 GV-R929OC-4GD

GIGABYTE ビデオカード R9-290搭載 GV-R929OC-4GD

GIGABYTE ビデオカード R9-270X搭載 GV-R927XOC-4GD

GIGABYTE ビデオカード R9-270X搭載 GV-R927XOC-4GD

Mac OS X Mavericks の Preview でPDFを結合するとサイズが膨れ上がる現象について

定期的に手持ちの書籍をPDF化するようにしていて、裁断した書籍の取り込みはScanSnap S1500で、PDFの結合作業はMacのPreviewを使っているのですが、どうもMavericksのPreviewがバグっぽい挙動をしていたので、メモを残しておきます。

発生している問題

透明テキストの含まれているPDFをMavericksのPreviewで結合すると、サイズがありえないくらいに膨れ上がる場合がある。

作業環境

PDFの読み取り:ScanSnap Manager(ScanSnap S1500に付属のPDF読み取り&OCRツール)

書籍を全編カラーで読み込むとサイズが膨れ上がり、また紙の黄ばみといった不要な情報まで拾ってしまうので、表紙だけはカラーで、本文(中身)はグレースケールで読み込むようにしています。

PDFの結合:MacのPreview

表紙と中身で別の読み取り設定を使っていると、別々のPDFが出来上がるため、最終的にそれらを結合する必要があります。私は結合にMacのPreviewを使っています。

問題の再現方法

  1. 透明テキストが含まれるPDFを2つ用意します。それぞれのサイズは、100MB、5MBとします。
  2. この2つのPDFを結合する際に、「100MBに5MBを追加する」のと「5MBに100MBを追加する」のとで、結合後のサイズが大きく異なってきます。

100MBと5MBのファイルを結合したのですから、結果は大体105MB程度になると予想できます。実際に、「100MBに5MBを追加する」場合だと、大体105MB程度のPDFファイルが出来上がります。しかし、「5MBに100MBを追加する」場合では、400MBを超えるサイズのPDFが出来上がってしまうのです。

サイズが異常に大きくなる原因

透明テキストのサイズが肥大化しているのが原因のようです。400MBに膨れ上がってしまったPDFに対して、Adobe Acrobat XI Proを使って透明テキストを削除してみたところ、105MB程度までファイルが小さくなることが確認できました。つまり透明テキストだけで200数十MBという、通常ありえないサイズを占有していたことになります。(*Adobe Acrobat XI Proは30日間の無料体験版を使いました)

まとめ

MacのPreviewで透明テキスト付きのPDFを結合する場合は、サイズの大きいPDFに小さいPDFを結合するようにした方が良いかと思います。これを逆にすると、ファイルのサイズがびっくりするほど膨れ上がってしまうことがあります。

これ、バグっぽい挙動にも思えますが、どうなんでしょうかね。


書評: DECの興亡―IT先端企業の栄光と挫折

f:id:hassyX:20131114083130p:plain

「DECの興亡」を読んだ。

著者のエドガー・H・シャインは、長年DECのコンサルタントを勤めた人物で、本書を見る限りCEOのケン・オルセンとの距離も非常に近く、DECの社内運営にも深く関わった人物。

ある意味DECのインサイダーであり、著名な組織文化の研究家でもある著者が送る、偉大な企業・DECが潰れるに至った経緯。



この本が繰り返し主張することは、DECという企業が終始ケン・オルセンという人物の個性そのものであった、ということ。

特筆すべきなのは、ケンが部下に会社としての方向性を指示することがまったくといっていいほどなかった、という点。

社員は、すべきことを自らが決めることを求められ、個人間や組織間で利害の不一致が生じる場合は、徹底的な議論によって着地点を見つけることを求められた。

ケン自身は、部下に何かをしろと指示することはなく、議論を活発化させる役割に徹していた。

この「するべきことは自らが決める」方針は、会社が小規模の組織で、売上も右肩上がりで伸びていたDECの創世記では問題となっておらず、むしろ良い影響を与えていたともいえるのだが、次第に組織が肥大化していくに従って、組織間がまったく連携をとろうとせず、熾烈な政治闘争が生み出される原因となってしまう。

そして、各組織が非効率な政治闘争に明け暮れていた真っ只中にあっても、ケンの「自らが積極的に介入しない」という姿勢により、それが是正されることはなかった。

1998年、DECはコンパックに買収され、企業としてのDECは姿を消した。



DECは新興市場であるPC市場に飲み込まれようとしているにも関わらず、対応が後手後手となり、企業として適切な対応をとることができなかった。

この本の終わりには、DECは消えたが、元DECの人材はIT企業の各所で大活躍しており、今もDECの魂は生き続けているのだ、といった風に結ばれている。

人材もそうだが、現在DECは「破壊的イノベーションに対応できなかった企業はどのような末路を辿るのか」という、イノベーションのジレンマを説明する際に使われることが多いように思う。反面教師として、DECが遺したものも大きかったのではないだろうか。

総評

良い本だと思います。「イノベーションのジレンマ」と合わせて読むといいかも。

DECの興亡―IT先端企業の栄光と挫折

DECの興亡―IT先端企業の栄光と挫折

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)

デル株式会社