コンピュータの構成と設計、通称パタヘネ本が7年ぶりの改訂版 70
ストーリー by yoosee
変わる技術、変わらぬ基礎知識 部門より
変わる技術、変わらぬ基礎知識 部門より
saratoga曰く、"気づくのが遅れたが、俗に「パタヘネ」と称される、David A. Patterson と John L. Hennessy による
「コンピュータの構成と設計(上巻、下巻)」が7年ぶりに改定され、第3版が出たようだ 。
個人的には、ついでに「ヘネパタ」こと「コンピュータ・アーキテクチャ」の方も、ぜひ価格改定をお願いしたい。
ところで今の時期は新人さんが入ってくる季節だと思うが、新人さんたちにはややこしいソフトを書く前に、これらで少しはハードウェアの勉強もして欲しい、と願うばかりだ。「できればこれは読んでおいていただきたい」という定番・原典・基本書には他にどんなものがあるだろうか。諸賢のご意見を伺いたい。"
ハードの勉強が必要? (スコア:4, 興味深い)
>これらで少しはハードウェアの勉強もして欲しい、
>と願うばかりだ。
私はSEで、今でもハードの知識はほとんどないままです。(PC自作程度)
また、業務上ハードの勉強が必要だな~と感じたこともありません。
もちろん業務の内容によると思いますが、ソフト屋にとって
ハードの勉強は必要ですか?(というかどこまで必要?)
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:ハードの勉強が必要? (スコア:5, すばらしい洞察)
まぁでも、昨今そう言い切るのは、原理主義的かなとも思います。たしかに、ハードウエアに近いレベルの仕事でない限り、仕事上必須とは言えないと思います。仕事による。
ある物事を理解するには、必要に応じてどこまで理解すればよいのか?という段階が変わりますし、それは仕事上のみならず、個人の趣味によっても変わると思います。やたらに底辺の事情を詳しくても、現実問題として役に立たないと意味はないです。時間も有限ですしね。
ハードウエアのみならず、ソフトウエアの世界でもアルゴリズム論みたいなところまで突っ込んで興味をもつ必要があるのか?という議論と一緒だと思う。ソフトって言っても、下から上までいろいろあるし、理論チックになるとそりゃ、実際のコーディングからははずれてしまうし。どの辺に興味を持つのかはそれぞれだし、その辺が必要かは仕事による。ソフトかハードではなくて、「仕事」次第。SEってくくっても幅は広いし。
ただ、見識を深めるという意味もあるし、根本的なところを押さえる・押さえたい、という欲求はきわめて健全だと思うし、「これだけできれば仕事はできるので、それはいいや」という姿勢は好ましくないと思います。
でも、仕事に直結する技能ではなく、それ以外に広く探っても、結局のところスキルの向上はしないというのも事実です。器用貧乏は意味がない。深く深く掘り下げることの方が重要で、その結果自然と穴は深いだけではなく広がっていく、これが重要だし、もし転職(スキルアップ・ジョブチェンジ)したときには、それが重要になってきますし。その穴の深さと広さがかならずその人の力になります。
まぁ、日々、目の前の雑多なコーディングに追われているのが普通だと思うので、そうはうまくいかないんですけど。そういうのが生かせる職場というのはなかなかないし。なっても、結構しんどい(つらくはないけど)。
そのへん、仕事と趣味と興味の都合難しいのですけど、必要ないと言い切るよりは、つねにレーダーを張り巡らせておくのを心がけた方がよいかと。
普通のやつらの下を行け (スコア:1, 興味深い)
荒っぽいレイヤ分けですが、アプリならOS,OSなら計算機アーキ、アーキなら回路、回路ならチップ、チップなら物理、物理なら数学。
Re:ハードの勉強が必要? (スコア:4, 参考になる)
コンシューマ向けのPCソフトや組み込みをやるようになってからは、重要だと感じるようになりましたよ。
設計時の実装感覚や、デバッグ・チューニング時の実行感覚に直結します。
Re:ハードの勉強が必要? (スコア:2, 興味深い)
メモリ関係とかネットワーク帯域とかHDDなどの 記憶装置はパフォーマンスを考える上で原理を知らないと 話になりませんし。
パフォーマンスでなくとも、ソフトを乗っけるハードを どうするということを考えられないと、 ソフトは出来上がっても運用をはじめられませんよ。
ロードバランサが入ってアプリケーションサーバが 複数入ってDBサーバがあって、みたいな構成はざらですし。
(このストーリーで話題にしている「ハード」とは 意味合いがやや異なるかもしれませんが)
Re:ハードの勉強が必要? (スコア:3, すばらしい洞察)
何も身に付けた知識で他者の領域に口を出せということではないんです。
ただ製品の最終的似姿を意識しない(できない)で、
「おれの領域はここまで、後は知らん。」て姿勢で
仕事するエンジニアって、いいか悪いか以前に魅力がないです。
ソフトってそれ単体でクローズすることは本当は一切ないでしょ?
あくまでそれによって制御されるハードが動いた結果現れる事象が
サービスとして現実世界の顧客に提供されるわけですから。
ここで言う顧客があなたの直接のお客ではなく、
客があなたから買った成果で提供するなにかを受け取る人々だとしても
その姿がイメージできない、しようとしないんだとすると
いいものがつくれるとは思えないのです。
逆に言えば、それができる程度に対象システムが理解できるぐらいの
勉強が出来てればそれで十分じゃないでしょうか。
Re:ハードの勉強が必要? (スコア:3, 興味深い)
「稼働環境」という意味でのハードは理解しています。
しかし、それ以上深いレベルの知識って使うことが
ありませんでした(もちろん業務による、という話)。
/.は技術系なのでハードよりになるのは分かるんですが、
個人的には、ハードよりも顧客のビジネス理解やコスト意識
といったものをもっと学んでもらいたいです。
もちろんバランスの問題なんですけど、その視点の教育って
本当に弱いと思うんですよ・・・。
ということを本当は書きたかったんですが、微妙にオフトピ気味
なので疑問を出すに留めました。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:ハードの勉強が必要? (スコア:2, すばらしい洞察)
> 顧客のビジネス理解やコスト意識といったものをもっと学んで
という点で、ハードを勉強してほしいです。
SE とプログラマの違いは何かというと
プログラマ: 実現方法を知っている
SE: 何が出来て何が出来ないかを知っている
ということだと思います。
ソフトで実現するより専用ハードを導入した方が安いのか、
逆に、専用ハードを廃止してソフトで実現したほうがいいのか、
とか、そういう検討はSEの担当。
そういう点で、SEこそハードを知っておいて欲しいです。
Re:ハードの勉強が必要? (スコア:2, 興味深い)
> といったものをもっと学んでもらいたいです。
お客さんの要求条件に対して、普通はソフトウェアの機能だけではなく、ハードウェアを含めた構成を考えます。
要求性能や仕様、コストに対してどれだけの投資を出来るかの判断はソフトとハードの両方を知らないと本来は出来ません。
また性能的なボトルネックが出た場合にどこを増強するか、ないしソフトのどこを改修して逃げるかと言った話、
実際の運用に際してどれくらいの故障率があるのでこれくらいの可用性を確保するには、どういうハードとソフトを
組み合わせてどういう保守と運用体制を組むかなど、ハードウェアを含めて考えることはたくさんあります。
そうした全体の構成を考える上で、技術革新が目まぐるしく起こるこの業界では、コンピュータがどう動いているか
といった基礎知識は、新しい技術を即時的に評価・利用するために非常に有益なものです。
> その視点の教育って本当に弱いと思うんですよ・・・。
正直言えば技術をきっちり理解して展開できる人の方がレアだと思います。
もちろんビジネスをきっちり理解している人もかなりレアでしょうけど。
ビジネス理論が必要ないとはいいませんが、その方向性で必要なのはビジネスに関する専門知識よりはお客さんが
本当に望んでいることを聞き出すためのコミュニケーション能力と分析能力かも知れません。
と言いつつ、お金の事を考えていないエンジニアをよく見掛けるというのも確かですけどね。
Re:ハードの勉強が必要? (スコア:1)
Re:ハードの勉強が必要? (スコア:1, 参考になる)
実装自体はライブラリ使うだけだとしても、テストケース想定するにはハードの動きを知らないと。
似たような事例は他にもあるだろう。
Re:ハードの勉強が必要? (スコア:3, 参考になる)
とんでもないプログラムを書いてくれる人はいますね。
通信速度に見合ったファイルのやり取りではなくローカルHDDの
転送速度・容量・エラー処理を前提としたプログラムとか(泣)、
各種レスポンスがゼロを期待したプログラムとか。
全部を知る必要は無いが、少なくともその位の制限or限界を
知ったプログラムを組んでくれ、とは思う。
Re:ハードの勉強が必要? (スコア:1)
特に性能については本当はキャッシュやバスの特性, IO性能を考慮して... とか言いたいところなんですが, 実際の業務プログラムだとそれ以前のアルゴリズムの段階で性能が出ないのが当然という例の方が圧倒的多数なので, 何とも言えないですね.
# さらにその前の, 動く/動かないの問題の方が多いし
Re:ハードの勉強が必要? (スコア:1)
お客さんの所でなんで動かないor変な挙動する時に原因が解りやすくなるかも?
役立ったのっていうと、ほんと基本情報技術者(FE)の試験(今週末の日曜ですよー)と周囲のPCトラブルの解決というサポート方面な感じだなぁ・・・
ほんと何かあった時の助けになるかも程度な気がします。
# あとは、特殊な機器(バーコードリーダーとか温度センサ)をRS-232Cとかで自分でソフトから制御しなくていけなくて、しかもライブラリが無いとかの時ぐらい?
Re:ハードの勉強が必要? (スコア:3, 興味深い)
近年のキャッシュ当然, マルチプロセッサ(マルチコア)も普通なんて状況だといやが応でもハードを意識しますよ.
そうでないとデータひとつペリフェラルに本当に書き込まれたかどうか分かりませんし, 逆にペリフェラルから読んだつもりになっているだけとかもありえます. 並行して流れているスレッドが使っているデータは同じ物か保証できません. SMPでマルチスレッド化したら性能が落ちたなんてことも当然ありえます.
こういう物は大抵OSの同期化サービス(システムコール)とかミドルウェアでカバーされて, 初級プログラマにとってはおまじない化されているんですが, 古今おまじないは詠唱に時間がかかるのが相場です. ですからおまじないの背景にあるハードを理解していないと, 唱え過ぎで性能劣化を起こしたり, 逆に唱えるのを忘れて再現性の悪いバグを起こしたりするはめになります.
こんな問題は昔は大型サーバ・汎用機やワークステーション・スパコンの類, あるいはドライバ等のカーネルモジュールを扱う場合だけのものだったんですが, 最近のPCではそうした一昔前のハード構成と同じ様な物が使われていますので, プログラミングレベルでも同じような注意が必要になってきたわけですね. まあほとんどの場合, 性能は気にしないという条件さえ有れば無視できることが多いのですが.
Re:ハードの勉強が必要? (スコア:0)
私はハード寄りのソフト屋で、WebアプリケーションやらXMLやらの知識はほとんどなく、これまでに要求されたこともありませんが、
これだけ流行っているのを見ると、一応勉強しておかないとまずいのではないかと感じることもあります。
実際には、不要なのでしょうけどね。
Re:ハードの勉強が必要? (スコア:0)
エロゲー作る人には必要ないよな。
ハートの勉強は必要かもしれないが。
何を仕事としてやっているのかに関係するってことだ。
ただ、広い視野がなければいつまでも同じということだろう。
#一生エロゲーを作って暮したいかということと同じだな。
Re:ハードの勉強が必要? (スコア:1, おもしろおかしい)
エフェクトも変えていった方がより臨場感も溢れ、売れ行きにも……
#最近は買ってないのでAC
なんだ品切れじゃん……と思ったら (スコア:2, 参考になる)
こっちが(下) [amazon.co.jp]。
2冊セットで約8000円かぁ。
ヘネパタ原著第三版 (スコア:1)
http://www.amazon.co.jp/exec/obidos/ASIN/1558607242/
DLXプロセッサの章はなくなり、MIPSアーキでサンプルコードが書かれています。こっちの方の訳書を早く出して欲しい。
「計算機プログラムの構造と解釈」 (スコア:2, 参考になる)
http://www.amazon.co.jp/exec/obidos/ASIN/489471163X/
Re:「計算機プログラムの構造と解釈」 (スコア:1, 興味深い)
一度も見たことがありません。
知っている限り、一例もありません。
Amazon の書評だけではありません。
口コミ含めてです。
そこまで技術系の翻訳者はダメ揃いなのでしょうか?
むしろ最近では、原典が素晴らしければ素晴らしいほど、
作法として、和訳を貶さなければならないものだと考えています。
具体的な指摘がない限り、物知り顔の評者の「和訳がダメ」は
「原典が素晴らしい」と読み替えたほうがよろしいかと。
Re:「計算機プログラムの構造と解釈」 (スコア:2, すばらしい洞察)
そもそも、文芸書じゃぁないんだから技術書で「すばらしい訳」なんてされたら困るんじゃないですか?
#原著の説明では分かりにくいところを訳注で補ったりとか、
#原著が書かれた後の変化に対してフォローを入れたりとかいうのはありだろうけど。
Re:「計算機プログラムの構造と解釈」 (スコア:4, 興味深い)
これは同感。
これとは別の話としてAmazonなどで「訳が悪い」と言われている
ものには3種類存在します。
1、原書は普通なのに訳す段階で誤訳一歩手前の下手な
翻訳のために、和訳が理解し難いものになっている。
2、原書に忠実に訳しているのに、原書が理解し難いので
和訳が理解し難いものになっている。
3、原書も翻訳も問題ないのに、内容が難しいので理解でき
ないのを翻訳のせいにしている。
本当に「翻訳が悪い」のは1だけですが、Amazonの書評では
3の例が結構ありそうです。高度な専門書なんて、どれだけ
上手に訳しても素人には理解困難なものです。こういう人は
訳本でなくても理解できないのは変わりません。
>そこまで技術系の翻訳者はダメ揃いなのでしょうか?
まともな翻訳者も執筆者もいますが、極めて少数だと思います。
高い技術力が求められる上に報酬が十分とは言えない現状では
当然の結果です。
優れた技術系の翻訳者は、
1、翻訳(英文和訳)の能力
2、その専門分野の技術知識
を兼ね備えている必要があります。翻訳者に限らず2の条件を
満たす人さえも不足している現状で、1の能力も兼ね備えた
人材がそんなにいるわけがないでしょう?
Re:「計算機プログラムの構造と解釈」 (スコア:1, 参考になる)
翻訳者のリソース不足もありますが、編集・校閲など品質管理する側の問題も大きいように思えます。
日本語として適当か、読んで理解できる内容に仕上がっているかをチェックするのは彼らの仕事ですから。
以前に「0、原書は普通なのに日本語になっていない」というのもありますしね。(大概、原文を想像すれば読める)
文脈上、「独特の実装」となるはずの部分が「一意の実装」となっていた本を(文字通り)ぶん投げたことがあります。
おかげで原典に当たるのに抵抗がなくなったので、四千円分恨みつつ、ちょっと感謝していたりします(笑)。#もちろん他の部分も同様。
#ほぼ機械翻訳のまま、技術用語のみ全文置換をかけた感じでしたね。
Re:「計算機プログラムの構造と解釈」 (スコア:1)
商業ベースだと確かに難しいか。
せめて駄目な訳者、良い訳者を抽出したリストでも作って、ここでも 2ch ででも展開できないかな。
間接的にでも淘汰の一助になればいいんだけど。
Re:「計算機プログラムの構造と解釈」 (スコア:1)
思わず出版社の編集部にこれはひどいんじゃない,とメールしちゃいましたが・・・. ちゃんとした翻訳ができる人は不足しているので仕方ないみたいです.
ひどい訳でも訳者は本名/略歴を隠さずに出してる例が多いので,翻訳者自身はちゃんとできているつもりで居るのかも.
Re:「計算機プログラムの構造と解釈」 (スコア:1, 参考になる)
私の知る範囲では、プログラミングMicrosoft Visual Basic .NET〈Vol.1〉基礎編 マイクロソフト公式解説書 [amazon.co.jp] の toytoy2 氏の書評が例外ですね。確かにこの本は内容も訳もよく、おすすめです。
# VB6 は大嫌いだが VB.NET には惚れているので AC
酷い訳は、現実に存在します。 (スコア:0)
Extreme Programming Explained とか、
Python Desktop Reference (だっけ)の最初の訳とか。
Re:酷い訳は、現実に存在します。 (スコア:2, 参考になる)
Amazonのカスタマーレビュー [amazon.co.jp] にも批判が書かれていますが、単語を無視して 訳している部分もあり、ひどいにもほどがあります。
原文 [gnu.org]を ダウンロードして読むか、 若干古いのですが、 GNU Make日本語訳(Coop編) [ecoop.net] を読む方が良い本です。
Re:酷い訳は、現実に存在します。 (スコア:1)
こちらの話は聞いたことがあります。有志によるerrata [objectclub.jp]が出ましたね。
第2版 [pearsoned.co.jp]が出てますが、訳は直っているのでしょうか?
#悪魔本 [ascii.co.jp]も訳がどうとかMLで話が出てた。
Re:「計算機プログラムの構造と解釈」 (スコア:1)
昔は英語/日本語を試験中に選択できたので良かったのですが、
今は日本語を選択すると日本語だけになってしまい少々不便。
更にメジャーではないベンダー試験はもっと酷い場合も・・・。
#オフトピ気味だけどID
Re:「計算機プログラムの構造と解釈」 (スコア:0)
Re:「計算機プログラムの構造と解釈」 (スコア:3, 参考になる)
http://mitpress.mit.edu/sicp/ [mit.edu]
Re:「計算機プログラムの構造と解釈」(オフトピ) (スコア:1)
私が調べたときは、1ページ目の京都大学のURLで示されたページから見つかりました。
URLを教えてあげるのは一般的には親切ではあるけど、今回の件に限れば、/.に来るような人には、
蛇足かなって気もする。
とはいっても、mnrさんの知識と親切心に対しては相応の敬意は払いたい。
お約束ですが (スコア:2)
「はじめてのC [gihyo.co.jp]」
ですかね。
#そういや後輩に貸し出したままなのを思い出したgesaku
Re:お約束ですが (スコア:0)
と結ばれているトピックに対して、
>やっぱり最初は
>「はじめてのC」
>ですかね。
のコメント。
なぜオフトピがつく?
Re:お約束ですが (スコア:2, おもしろおかしい)
初心者にこれを紹介するとセクハラだと言われるからです。
特に中年男性が新人の若い女性にこの本を見せるときは
注意しましょう。
あと電車の中でカバーを付けずに読んでると、たまになぜか
高校生からクスクス笑われたりするそうな。
#私は試していません。都市伝説であることを祈ります。
Re:お約束ですが (スコア:1, すばらしい洞察)
> 新人さんたちにはややこしいソフトを書く前に、これらで少しはハードウェアの勉強もして欲しい
に、「はじめてのC」は該当しないと思います。
ヘネパタなのかパタヘネなのか (スコア:1, おもしろおかしい)
とやおい好きな人が言ってました
ヘネ×パタ≠パタ×ヘネ(オフトピ) (スコア:5, おもしろおかしい)
Re:ヘネ×パタ≠パタ×ヘネ(オフトピ) (スコア:3, 参考になる)
……こっちは交換法則が成り立つんだそうな。
Re:ヘネ×パタ≠パタ×ヘネ(オフトピ) (スコア:0)
Interface6月号にSH2基盤がついてくる(PDF) [cqpub.co.jp]ので下調べしてたんだが、
SHシリーズの開発秘話 [renesas.com]にもヘネパタ本の存在が出てくるよね。
ここは、「翻訳に取り組む人もいたほど」とあるから原著を読んでたみたいだが。
Re:ヘネパタなのかパタヘネなのか (スコア:1, 参考になる)
「コンピュータ・アーキテクチャ」
ヘネシー&パターソン → ヘネパタ
「コンピュータの構成と設計」
パターソン&ヘネシー → パタヘネ
単に、著者の並びで呼んでいるだけ。
(と言うか、日本で両書を区別するのに適当だったというのが真相)
ちなみに、パターソンはSPARC、ヘネシーはMIPSに深く
関わっています。(著者紹介のところに書いてあるが)
# この本はPC8801永久保存版と同時期にタレ込んだが
# 採用されなくて、スラドとは方向性が違うのか思っていた。
# 88の方もブックレビューセクションにしか載らなかった
# ので、みんなの目に触れなかったのか盛り上がらんし。
# スラドの採用基準が全く分からんよ。
ハードウエアの本 (スコア:1, 参考になる)
Re:ハードウエアの本 (スコア:2, 興味深い)
お約束 (スコア:1, 参考になる)
これ [amazon.co.jp]かな?
Re:お約束 (スコア:0)
積ん読 (スコア:0)
くやしいので今日から読み始めようかな
どうせなら1冊に (スコア:0)
この本の5章を読んではじめてプロセッサって何ってことがわかるので、上下必ず買わせる戦略としては有効な区切ですけど。
第2版在庫切れで無理矢理原著を買わせた者としては、もうちょっとひっぱってくれてもよかった。