test
震災から3 ヶ月が経過し、世の中は徐々に平静を取り戻そうとしています。 だけど、何かがちょっと以前とは違うと思いませんか？ 明日には何が起こるのかわからない、という現実を目の当たりにして、 「生きる上で本当に大切なものは何なのか？」という疑問を 日本人全員が突きつけられたからなのではないかと思います。 それは一瞬の興味を引くような、真新しいものや斬新な物や、 飾り立てられた何かやエンタテインメントではなくて、 生活の土台である、寝るところや食べるもの、着る物、 そして家族や仲間という、必要最低限のもの。 重厚長大な構造よりも、できるだけ簡素な構造へ。 それぞれの人が、世の中のシステムを知り、 自分たちの足でたくましく歩ける世の中へ。 何かが変わる時代が来たことをそこここに感じずにはいられません。 そんなときにひょっこりこの世の中へ登場したUSP MAGAZINE。 まだまだひよっこではございますが、 技術に人生をかけたエンジニアの皆さんを、 シェルスクリプトという簡素な技術でつなぎ、 奥深い技術の世界へと誘う骨太な雑誌を目指したい！！と 心の奥から思う次第です。 どうぞ今後ともごひいきに。
プログラムの背後で、CPUはどのような働きをしているのでしょうか？本書はその原理と仕組みを簡単な実験で確かめ、コードを研ぎすます方法を紹介します。
【著者あとがきより】
高速なプログラムが求められる場面は少ないながらも厳然として存在し、いざ性能が必要になったときに対応できる技術者が非常に少なくなっているのが気がかりです。特に、業務システムなどの数値演算系以外の分野では、絶滅危惧種と言ってよいのではないでしょうか。
その原因のひとつは、高級言語と統合開発環境の普及によって、機械命令レベルのプログラム実行を意識しなくてもすむようになっていることです。どのように実行されるかを意識しないので、実行コストが高い処理が平気で使われています。もうひとつの原因は、アルゴリズムに対する理解不足です。
開発するプログラムが高度化、パターン化してきているため、アルゴリズムについて学ぶ機会がなくなっているのではないでしょうか。
本書は、プログラムを高速化する個々の方策を並べるのではなく、方策を見つけるための道筋を示すように心がけました。
1.1 高速道路と横断歩道
1.2 コンパイラは何をしているのか
コンパイル後のアセンブリ言語プログラムを覗く
最適化オプションを付けるとどうなるか
1.3 CPUは何をしているのか
命令セットアーキテクチャとマイクロアーキテクチャ
命令はどのように実行されるのか
命令パイプライン
キャッシュメモリ
もっとキャッシュ
キャッシュブロックの置換アルゴリズム
スーパースカラ実行
[1章は重箱の隅なのか]
2.1 プログラムの実行コスト
2.2 計る・測る・謀る
本書のアプローチ
2.3 ベンチマークテストプログラムの最適化を防ぐ
操作の「おまとめ」を防ぐ
初期値設定の最適化を防ぐ
単純な繰り返し操作の最適化を防ぐ
本書のベンチマークテストプログラム
2.4 検証――遅いのはどの操作?
2.5 基本の加算と代入
単純な代入（レジスタ間の転送）
単純な代入（データの競合がある場合）
定数の代入
変数どうしの加算
変数に定数を加算
2.6 乗算は遅い
変数どうしの乗算
変数に定数を乗算
2.7 除算はとっても遅い
変数で除算（レジスタどうしの演算）
定数2、4で除算
2のべき乗以外の定数で除算
符号なし整数の場合はどうか
2のべき乗で除算するときはシフト演算がお得
2.8 メモリへのアクセス
小さい配列へのアクセス（狭い範囲のメモリ操作）
大きい配列へのアクセス（広い範囲のメモリ操作）
デスクトップ向けCPUとの比較
2.9 コンディションで差がでる条件分岐
else節のないif文
else節のあるif文
2.10 32/64ビット環境で違う関数呼び出し
2.11 実験のまとめ
[愛がほしくば愛を差し出せ]
3.1 gprofを使ったプロファイリング
gprofの使い方
3.2 何がどれだけ時間を喰っているか
ライブラリ関数のプロファイルも取得する
時間喰いの関数たち
ライブラリ関数の呼び出し回数を表示させるには
3.3 何が何を呼び出しているか
3.4 プロファイリングの仕組み
3.5 そのほかのプロファイラ
[達人の技を伝える教育システム]
4.1 達人はどこに目をつけるか?
ハードウェア編
コンパイラ／ミドルウェア編
アルゴリズム編
4.2 ［ハードウェア編］配列とキャッシュメモリの活用
行列の積を計算する
配列操作の順番を入れ替える
ループを展開する
行列のタイリング
4.3 ［ライブラリ編］遅い関数をめぐる紆余曲折
なぜstrcmp関数は遅いのか
最適化の落とし穴
4.4 ［ハードウェア編］SIMDを用いた文字列比較
4.5 ［ライブラリ編］入出力方法いろいろ比べ
行データの入力方法を比べる
出力方法はどうだろう
パイプ入出力の特殊事情
パイプ入出力 vs. ファイル入出力
4.6 ［アルゴリズム編］バイナリサーチと平衡二分探索木
大量データのソート
[そこまでやる? ね、ね、そこまでやるの?]
5.1 レベル分けされている最適化オプション
GCCの最適化オプション
「最適化なし」はデバッグに役立つ
未定義動作がないことを想定しているレベル2以上の最適化
5.2 最適化・レジスタ・外部変数
5.3 共通部分式削除を知ってプログラムすっきり
5.4 ポインタと強度低減
5.5 インライン関数でユーザー関数も展開
[他人に差をつけろ!]
6.1 ソートと文字列操作をねらえ
6.2 小数点数の計算と文字列／数値の変換
ブロック入出力とフィールド分割
小数部付きの数を集計する
整数を文字列に変換する
パフォーマンスチューニングの結果
6.3 半角文字から全角文字への変換
文字のバイト数を判別する
ASCII文字と半角カナ文字の判別
ASCII文字から全角文字への変換
半角カナから全角文字への変換
パフォーマンスチューニングの結果
文字のバイト数を調べる別の方法
より道UTF-8
6.4 データの特性を利用した配列の探索
データの特性を考慮する
バイナリサーチとリニアサーチを組み合わせた照合
パフォーマンスチューニングの結果
[あとがきに代えて]
アジャイルでもない、ウォーターフォールでもない…、シェルスクリプトとテキストデータ、そしてオリジナルのコマンドを組み合わせ て、従来の数十倍の開発スピードで企業の基幹システムを構築する「ユニケージ開発手法」。これまで十数年間ベールに包まれていた本開発手法を解説した初の 論文集が出版されます。
その圧倒的な柔軟性、スピード、コスト削減効果で、注目を集めている本開発手法について、考案者、ユーザ、研究者が、それぞれの立場から、技術の概略、特徴、従来の開発手法との比較を論じます。
「システムは業務にある。コンピュータは道具にすぎない」
「業務のつながりは、人のコミュニケーション」
「データは更新しない、発生データは捨てないで整理集約しておけばよい」等々、本開発手法を表現した数々の言葉は、従来型の開発に携わるエンジニアにとっても、得るものが多いはずです。
1.1 ユニケージの外見
1.2 ユニケージの世界観
1.3 ユニケージのデータ論
1.4 ユニケージによる開発・運用
1.5 ユニケージ文化：コンピューティングと心
2.1 「情シス」という仕事
2.2 システム開発における価値の根拠
2.3 システムの内製化へ
2.4 ユニケージとの出会い
2.5 ユニケージの「ミラクル」
2.6 良品計画とユニケージの現在
3.1 技術革新への途
3.2 ユニケージの分析と評価
3.3 UNIXシステムとデータベースシステムの再考
4.1 ユーザサイドから見たIT 基盤・産業論
4.2 ユーザサイドから見たシステム
4.3 ユニケージへの期待と評価
5.1 業務のつながりは人のコミュニケーション
5.2 テキスト処理だけで全部仕事ができた
5.3 データは更新しない、発生データは捨てないで整理集約しておけばよい
5.4 データの管理方式とデータ名称の付け方
私たちエンジニアは、常に技術についての選択を迫られている存在と言えます。 1994 年、マイク・ガンカーズ（X Window System 開発チームの一員）は、 以下の9 つの至上命令に集約される「UNIX 哲学」を創出しました。
これらのUNIX 哲学は、複雑化した現代社会において、物事の本質を貫き、 シンプルに強く生きていくための指標として、多くの人々の支えとなっています。 シェル（shell）は、ユーザからの指示を受けて解釈し、OS の中核部分に伝達することで、 プログラムの起動や制御などを行うプログラムです。 あらゆるプログラムは、シェルからの起動が可能であり、シェルスクリプトに処理の順番を 記述することで、複数のプログラムを操ることができます。 シェルスクリプトは、平易で短く書けるためユーザとの親和性が高いのも特徴です。 様々な言語で書かれたプログラムを自由に操るシェルスクリプトの可能性は無限大といっても過言では ありません。 現代に生きる私たちが直面する多くの課題も、この強くて柔軟な「UNIX の精神」と 「シェルプログラミングの技術」によって解決できるのではないか、と私たちは考えます。 USP MAGAZINE はUNIX 精神の原点に立ち返り、 シェルプログラミングをはじめとする広範な「洗練された」技術を紹介することで、 エンジニアの皆さんに改めてテクノロジーの楽しさ、深さを伝える雑誌を目指します。