total 808
-rw-------  1 mc  mc    5123 24 Jul 14:17 bar.c
-rw-------  1 mc  mc   39474 24 Jul 14:19 bar.o
-rw-------  1 mc  mc    7856 24 Jul 14:17 foo.c
-rw-------  1 mc  mc   28443 24 Jul 14:19 foo.o
-rwx--x--x  1 mc  mc  319742 24 Jul 14:19 foobar*
-rw-------  1 mc  mc    1045 24 Jul 14:21 foobar.h

ccacheを使う

ccache（compiler cacheの省略）ツールはコンパイルで生成された情報をキャッシュし、例えばヘッダー・ファイルのようにビルドの特定な部分のキャッシュ情報を使うことで、通常はcppで情報を構文解析するために使われるはずの時間を節約します。例えばリスト2のファイルのコンパイルについて言えば、（foobar.hが他のヘッダー・ファイルへの参照を含んでいるとすると）ccacheはincludeステートメントを、cppで構文解析した方のファイルで置き換えるのです。これほど単純なのです。ccacheは実際に内容を読み取って理解し解釈するのではなく、（それまではファイルとなるべき最終テキストであった）あとはコンパイルするだけだったものを、単にコピーするのです。

                
#include "foobar.h"
void main(void)
{
}

インストール

ccacheのインストールも、それを使うのも、皆さんが想像するほど複雑なものではありません。ccacheは今までのコンパイラーの使い方には全く影響を与えることはなく、皆さんとコンパイラーの間のインターフェースとして動作するのです。ですから、必要に応じて使うか使わないかという選択ができます。ccacheをインストールするにはSambaグループから直接ソースをダウンロードするか、あるいはローカルのミラー（参考文献）からダウンロードします。そしてダウンロードしたものを解凍します。

$ bunzip2 -c ccache-2.3.tar.bz2|tar xf -

次のディレクトリに変更します。

$ cd ccache-2.3

configureを実行します。

$ ./configure

ビルドします。

$ make

そして最後にccacheをインストールします。

$ make install

これで準備完了です。

展開

先に述べた通り、ccacheは皆さんと通常のコンパイラーの間に位置することによって動作します。ですからgccを呼ぶ代わりに、gccを最初の引き数としてccacheを呼びます。例えばコマンドラインからファイルをコンパイルするには、通常次のようにします。

$ gcc foo.c

ccacheを使うには次のようにタイプします。

$ ccache gcc foo.c

こうしたファイルを一度だけコンパイルしても、特にccacheを使ってファイルをコンパイルするのが初めてであれば、コンパイル情報はまだキャッシュされていないので、何ら利点は感じないでしょう。ですから、一般的にはccacheを設定して、恒久的にメインのコンパイラーとして入れ替える方が効果的です。そのためにはCC環境変数の値を設定します。

$ export set CC='ccache gcc'

ccacheをプロジェクト・ベースでのみ使用可能にしたいのであれば、例えばPerlのようなサードパーティーのツールをコンパイルする時にのみ使用可能にしたいのであれば、環境のトリックを使うか、configureスクリプトでそのように指定するか、またはどのCコンパイラーを使うかを指定するようなコマンドを作ります。

キャッシュを制御する

ccacheはデフォルトで、カレント・ユーザーのホーム・ディレクトリ（$HOME/.ccache）内のディレクトリを使ってキャッシュ情報を保持します。チーム環境では、誰もがビルド中にキャッシュ情報を使えるように、中心となる場所をキャッシュ用に使いたいでしょう。もう一つの環境変数CCACHE_DIRがキャッシュ・ディレクトリの位置を規定します。単一マシンの環境では、必要な人が誰でもアクセスできるようなディレクトリにこれを置きます。充分なメモリーがあるとして、さらに高速にするためには、tmpfsを使ってマウントされたディレクトリを使います。これによってさらに10%から25%高速化することができます。

ネットワークを経由して接続したマシンでccacheを使用するのであれば、必ず共有するディレクトリがNFSでエクスポートされ、各クライアントにマウントされるようにします。この場合でも、さらに高速化したい場合にはtmpfsファイルシステムを使うことができます。

キャッシュをさらに細かく制御できるようなオプションが他にも幾つかあります。

• CCACHE_LOGFILE環境変数は、ログファイル（ccacheを使うと中身が入ります）の場所を定義します。
• ccacheで-sコマンドライン・オプションを使うと、キャッシュのパフォーマンス統計が分かります（リスト3）。
• -Mコマンドライン・オプションを使うと、キャッシュの最大サイズを設定できます。デフォルトは1 GBです。キャッシュに対する設定はキャッシュ・ディレクトリに書き込まれます。ですから別々のユーザーやグループに対して、別々の場所で別々のキャッシュ・サイズを設定することができます。
• -Fオプションは最大ファイル数を設定しますが、一番近い16の倍数に丸められます。-Mと同様、デフォルトを変更したい時にのみ使用します。
• -cオプションはキャッシュを整理します。ccacheは実行中に情報を更新するため、通常はこれを使うべきではありませんが、しばらく使っていなかったキャッシュ・ディレクトリを再び使用するような時には、このオプションを使うことができます。
• -Cオプションはキャッシュを完全にクリアします。

                
cache hit                             44
cache miss                           152
called for link                      107
compile failed                        11
no input file                          2
files in cache                       304
cache size                           8.8 MB
max cache size                     976.6 MB

初期オプションを設定し、ディレクトリやキャッシュ・サイズを設定してしまえば、何も変更する必要はありません。定期的なメンテナンスを行う必要もありません。

上に戻る

ccacheとdistccを組み合わせる

皆さんは、同じくSambaグループの別のツールdistccを既にご存じかも知れません。distccを使うと、何台かのマシンにコンパイルのプロセスを分散させることができます。そのため、あたかもmakeで（-jコマンドライン・オプションを使って）複数ジョブ・オプションを使ったかのように、起こり得る同時コンパイルの数を実質的に増やすことができます。各ホストでは、ソースファイルを構文解析前の最終形式で受け付けてから（出来上がったオブジェクト・ファイルを戻す前に）ファイルをローカルでコンパイルするデーモンがあり、distccシステムはこのデーモンを使うことで動作します。

distccはソースファイル全体を分散するので、効果があるのは一つ以上のソースファイルがあるようなプロジェクトのみです。適切に使った場合、同等な新しいノードを追加する毎にビルド時間が減少する割合は、直線的な減少よりもやや少ないものになります。

distccは構文解析された状態でファイルを分散するので、Cのプリプロセス部分をスピードアップするccacheとdistccを組み合わせて、オブジェクト・コードを生成する実際のコンパイルを行うことができます。distccとccacheをこの方法で使うには、自分のホストでdistccを設定し、メインの開発マシンでdistccとccacheを設定します。

リスト4のように、プロジェクトをビルドしたいマシンで環境変数を設定します。

                
export set DISTCC_HOSTS='localhost atuin nautilus pteppic kernel'
export set CCACHE_DIR=/Data/Cache/CCache
export set CCACHE_PREFIX=distcc
export set CCACHE_LOGFILE=/Data/Cache/CCache.log
export set CC='ccache gcc'

環境変数は次のように定義されます。

• DISTCC_HOSTS は作業を分散する先のホストを指定します。
• CCACHE_DIR はccacheディレクトリの位置を指定します。
• CCACHE_PREFIX はccacheが（プリプロセスの後）ソースをコンパイルする真のコンパイラーを呼ぶ時に使うプレフィックスを指定します。
• CC は最初に使うCコンパイラー（ccache）の名前を設定します。

同時に実行するコンパイルの数を-jオプションで指定してmakeを実行すると、ファイルはdistccのホストの一台に分散される前に、最初にccacheで（必要な場合にはそのキャッシュを使って）構文解析されます。

distccはコンパイルのプロセスをスピードアップしますが、環境の持つ基本的な制約を変更するわけではありません。例えば、makeが操作する同時ジョブの数は、使用できるCPUの数の2倍以上にすべきではありません。例えば４台の２ＣＰＵマシンの場合、ジョブの値を16以上に設定しても、ほとんどスピードの改善は感じられないでしょう。

上に戻る

統計

さて、全てが設定できたところで、どのくらい差があるものかを見てみましょう。ここではPerlをビルドする一連のテストを実行しました。ccacheは構文解析されたヘッダー・ファイルをキャッシュした時に最も効果があるので、コンパイルするにはよく身の詰まったものが必要です。これは単にmakeフェーズであり、標準のconfigureを（configure.gnuを使って）実行した後に起こります。コードのコンパイルに関係したものだけではなく、全てのステージを含んでいますが、非コンパイラー操作は全体的な統計には影響しません。

先に述べた通り、ccacheの効果は最初のコンパイルでは感じられません。以前のプリプロセッサーのパスを再利用する時に、その違いが出るのです。表1に示す再コンパイル時間は、メインのPerlソース・ディレクトリにあるCソースファイルのそれぞれを、ごくわずかいじった結果に基づいています。ここでは4ノードのネットワークで同時に行われるdistccジョブの様々な値を使って、ごく普通のgccでビルドした場合、ccache+gccでビルドした場合、ccache+distcc+gccでビルドした場合の時間を計測しています。

何と素晴らしい！ ccacheを使うだけでPerlのビルド時間をほとんど3分（実は2分45秒ですが）の短縮です。これはすべて、ccacheが事前に構文解析されたヘッダー・ファイルを保存しておいて使うためであり、各ソースファイルに対して常にcppを再実行することがないからです。プロセスの中にdistccも取り入れれば、再コンパイル時間が少し早くなると同時に、全体的なスピードも向上します。

上に戻る

まとめ

この記事では、ccacheのように比較的単純で使いやすいツールを使うことによって、どれほどスピードが改善されるかを見てきました。ccacheをdistccと組み合わせて使えば、さらにコンパイル時間を短縮することができます。こうしたツールをチーム環境で使えば、コンパイル時間だけで毎日何時間も節約できることになります。開発メンバーにとってはコーヒー・ブレークの時間が少なくなることを意味するかも知れませんが、アプリケーションの開発時間も短縮できるのです。

参考文献

• Samba.orgから ccacheとdistccをダウンロードしてください。
  
  
• ccacheやdistccのようなソフトウェアをソースからコンパイルするのに助けが必要であれば、チュートリアル「Compiling and installing software from sources」（developerWorks, 2000年8月）をよく読んでください。
  
  
• tmpfsファイルシステムの紹介であれば、Daniel Robbinsによる記事、共通テーマ: アドバンスト・ファイルシステム・インプリメンター・ガイド: 第3回: 仮想記憶（VM）ファイルシステムとバインド・マウントの使い方（developerWorks, 2001年9月）を読んでください。
  
  
• GCCをIBM eServer™pSeries®マシン上のAIXで使うのであれば、Tips and tricks of using the GNU C/C++ compiler on AIX（developerWorks, 2003年10月）が紹介記事として好適です。
  
  
• developerWorksのLinuxゾーンにはLinux開発者のための資料が取り揃えられています。
  
  
• Developer BookstoreのLinuxセクションではLinux関係の書籍が値引きして購入できますのでご利用ください。
  
  
• Linux上で実行する、より抜きのdeveloperWorks Subscription製品の無料の試用版をダウンロードして下さい。developerWorksのSpeed-start your Linux appセクションからWebSphere Studio Site DeveloperやWebSphere SDK for Web services、WebSphere Application Server、DB2 Universal Database Personal Developers Edition、Tivoli Access ManagerそれにLotus Domino Serverが入手できます。もっと手早くしたければ、ハウ・ツー記事や技術サポートが製品毎に集められていますので、ご自由に入手して下さい。
  

설명 #

선언된 함수가 저장된 메모리 번지값을 담고 있는 포인터 변수

실행결과는 아래와 같습니다.

시험출력1:테스트
시험출력2:테스트

main()안에서는 funcPtr만 실행했지만 마치 testout1, testout2를 각각 실행한 것과 같은 효과가 있음을 알 수 있습니다.

typedef LRESULT(CALLBACK *WNDPROC)(HWND,UINT,WPARAM,LPARAM);

실제로 사용될 때에는 다음과 같이 사용됩니다.

LRESULT CALLBACK winproc1(HWND,UINT,WPARAM,LPARAM) { };
...
WNDPROC winprocPtr = winproc1;
...

꽤 유용한 문법이니 알아두시면 좋습니다.

Domain Controller

For the remainder of this chapter the focus is on the configuration of domain control. The examples that follow are for two implementation strategies. Remember, our objective is to create a simple but working solution. The remainder of this book should help to highlight opportunity for greater functionality and the complexity that goes with it.

A domain controller configuration can be achieved with a simple configuration using the new tdbsam password backend. This type of configuration is good for small offices, but has limited scalability (cannot be replicated), and performance can be expected to fall as the size and complexity of the domain increases.

The use of tdbsam is best limited to sites that do not need more than a Primary Domain Controller (PDC). As the size of a domain grows the need for additional domain controllers becomes apparent. Do not attempt to under-resource a Microsoft Windows network environment; domain controllers provide essential authentication services. The following are symptoms of an under-resourced domain control environment:

A more scalable domain control authentication backend option might use Microsoft Active Directory or an LDAP-based backend. Samba-3 provides for both options as a domain member server. As a PDC, Samba-3 is not able to provide an exact alternative to the functionality that is available with Active Directory. Samba-3 can provide a scalable LDAP-based PDC/BDC solution.

The tdbsam authentication backend provides no facility to replicate the contents of the database, except by external means (i.e., there is no self-contained protocol in Samba-3 for Security Account Manager database [SAM] replication).