2012年2月12日 (日)

アジア・太平洋地域の国別 IPv6, IPv4 アドレスリスト (最新版)

掲題のタイトルで、国別の IPv6、IPv4アドレスをほぼ毎週 blog にまとめて来ましたが、今後は、一つのURLに最新情報を随時上書きする形で掲載する事にしました。つまり、blogからは切り離します。

新しいページはこちらです。
http://eelgrass.cocolog-nifty.com/apnic_ipv6_by_country.html

どうぞよろしくお願いします。

移行に従い、これまでblogに載せた関連記事は削除しました。

| | コメント (0) | トラックバック (0)

2008年3月 6日 (木)

バックアップ方法再考

私はMac OS Xを使っているが、作業環境として、Bootcamp 及び VMwareとして使う Windowsのパーティションを保持している。「作業環境」と言ったのは、大事なデータは殆ど入っていないという意味で、例えば外付けドライブのファイルを閲覧したり、後でMacに渡す Microsoft Office 書類を作成したり、という一時的な用途に使っている。

Bootcamp パーティションのバックアップは、多くのユーザが懸念することと思われるが、作業環境として割り切るなら、dd コマンドを使ってパーティションを丸ごとバックアップするのは、案外良い選択だと思った。

dd は、例えば、このように使う。

# 対象デバイスの識別子を確認する
$ diskutil list

# 確認したBootcampパーティションをアンマウントする
$ diskutil unmount /dev/disk0s3

# パーティションのイメージを外部ディスクにバックアップする
$ dd if=/dev/disk0s3 of=/Volumes/External_Disk/(ファイル名)

最大のメリットは速さだ。大きなファイルをコピーするような感覚で終わる。USB2.0 で接続した 7200rmp の外付けディスクの場合は、約15Mbyte/sの速さが出た。USB2.0 で単純にファイルコピーをする時の実効速度は20Mbyte/s前後だったから、その快適さが分かると思う。約9.5GBのパーティションだったので、ほんの12分でバックアップできた。(パーティションがこの大きさなのは、まさに作業環境でしかないからだ。) IEEE1394 や eSATA で繋いだディスクになら、もっと速く終わるのではないだろうか。

個別にファイルをバックアップしたり、差分を取ったりすると、これよりずっと遅くなる。「作業環境」のバックアップは、正常に動くシステム及びアプリケーションの保存だから、差分でバックアップを取る必要性は小さい。むしろ正常に動く環境を丸ごと残した方が便利だ。

案外問題になるのは、dd コマンドを使うことの心理的な敷居の高さだと思う。

| | コメント (0) | トラックバック (0)

2007年12月16日 (日)

ソフトウェアの最適化ビルド

CPUのアーキテクチャに最適化したソフトウェアは、どれほどのパフォーマンスの向上をもたらすのだろうか?最近はIntelのデュアルコアCPUが大幅な性能向上を果たしたが、仮にソフトウェアをビルドする過程でCPUの新しいアーキテクチャを活かしきれていないとしたら、それはもったいないことだ。

最適化という意味では二つの岐路がある。一つはコンパイラの選択、もう一つはコンパイルオプションの選択。前者に関しては、いくつかのウェブサイトで比較を見ることができる。GNUコンパイラに比べて、インテルの商用コンパイラは非常に良い結果を出すらしい。(一方、GNUコンパイラは、バージョン4.0および4.1ではIntel Core Duoを使った場合に僅かに3.3より改善、それ以外のCPUではバージョン3.3より良い性能は出ないらしい。4.2になってやっとましになったとのこと。)

残るコンパイルオプションの選択は、ソフトウェアの演算能力をどう変えるのか。Intel Core Duo 2.0 GHzを搭載した Macbook Proで実験してみた。今回取り上げるソフトウェアは、画像処理の ImageMagick である。

比較したのは次の二つである。

(ア) Mac OS X 10.4 に付属のGNUコンパイラ 4.0.1を用い、最適化フラグは -O2 だけでビルドしたImageMagick 6.3.7

(イ) GNUコンパイラ 4.2.2を用い、Core Duo向けの最適化フラグとして -pipe -O2 -march=prescott -msse3 -fomit-frame-pointer を用いてビルドしたImageMagick 6.3.7

純粋に最適化オプションだけの比較でなく、むしろMac OSのデフォルトの開発環境と、新しくて性能にも留意した開発環境との比較ということになる。

ImageMagick の convert コマンドを用い、5016 x 7602 ピクセルの大きさの 16 bit TIFF形式の画像ファイルを、unsharpマスクをかけて縮小し、その時間を計測した。それぞれの実施前にはコンピュータを再起動し、ほどなく実験を行っている。Unsharpマスクには、Catromを選択した。Catrom自体がどのような計算をしているのか私は詳しく知らないが、積分及び行列計算が多くを占めると想像している。これが、最適化の検証に ImageMagick を用いようと思った一つの動機である。

結果は、50%に縮小した場合(convertのunsharpパラメターは9x1.4+1.0+0.02を使用。演算量は多いはず)

(ア) 1分6秒56
(イ) 1分5秒11 (-1.45秒)

12.5%に縮小した場合(unsharpパラメターは2.3x0.43+1.0+0.02)

(ア) 33秒86
(イ) 34秒73 (-0.87秒)

となった。計測時間には、241MBもの大きさのファイルの読み込みから、書き出しまでが含まれるので、演算自体の所要時間は分からないが、いずれにせよ目立った改善にはならなかった。

ImageMagick は MacPorts を使って導入している。MacPortsに登録された多くのソフトウェアが、デフォルトでは(ア)の条件でビルドするように設定されており、(イ)の条件を適用するのは少々面倒なのだが、その設定をするだけの価値は気休め程度でしかないということだ。性能向上のためなら、Intelのコンパイラを用い、半年でもあとに発売されたコンピュータを用いるほうが効果的だ。

| | コメント (0) | トラックバック (0)

2007年7月31日 (火)

Mac OS XからVMwareクライアントへのポートフォワード

Mac OS X でポートフォワードを実現するには、通常のUnix/Linuxの方法が使えないようだ。

ネット上を検索すると、一つには、OS X の「インターネット共有」として稼働している natd を一度終了させ、新たに作成した設定ファイル (nat.conf) を読み込ませて natd を再起動する方法が用いられている。他には、/usr/libexe/InternetSharing  というコンパイル済みのファイルの可読部分を変更している例もあったが、これは他の手段がある以上、避けるべきだろう。 

これらの方法は、あくまで OS X の NAT の設定を変えるためのものだ。よって、フォワード先が Parallels Desktop や VMware Fusion (以下、VMware)のバーチャルマシンである場合は、バーチャルマシンはそれぞれのアプリケーションに付属する DHCP/NAT の下にあるため、同じ方法を使うことが出来ない。

VMwareの場合はどうすれば良いか。VMwareのNATは、vmnet-natd というプログラムによって動いているのだが、私はこの設定ファイルを変更することで、port forward を実現することが出来た。

まず、動いているプログラムと引数を調べる。ターミナルで ps -ax | grep  natd を実行すると、

/Library/Application Support/VMware Fusion/vmnet-natd -c /Library/Application Support/VMware Fusion/vmnet8/nat.conf -m /Library/Application Support/VMware Fusion/vmnet8/nat.mac -d /var/run/vmnet-natd-vmnet8.pid vmnet8

の一行が表示され、設定に使われている nat.conf が特定できた(VMwareで別のネットワーク形式を選択している場合は、'vmnet8' に相当する部分が異なる)。このファイルを開くと、カスタマイズ例がコメントアウトした状態で書き込まれており、実はカスタマイズを想定していることが伺える。このファイルの [incomingtcp] のセクションに、例えば

8080 =  172.16.226.128:8080

と書けば、port foward の設定が完了である。この例では、インターネットからのポート8080へのパケットは、natdによって172...のIPアドレスを持つバーチャルマシンへと宛先を書き換えられ、転送される。逆向きのパケットも同様に処理される。

NATの設定が終了したら、ファイアーフォールの設定も忘れずに行っておく。システム環境設定から先程指定したポートを開放しておく。私は ipfw を使って、より細かく設定したファイアーウォールを敷いているので、ipfw のルールに次のような行を加えた。

ipfw add allow tcp from any to me dst-port 8080 in

これにより、インターネットからen0 を経由してOS Xに入って来るパケット(これは後にNATに拾われ、バーチャルマシンに転送される)と、バーチャルマシンからvmnet8 を経由して OS X に入ってくるパケット(後にインターネットに向けて転送される)の両方が、ポート8080に限って許可される。

括弧内に記述した、OS X から外に出て行くパケットについては、別の行で他の通信と一括して許可しているのでここでは触れない。

なお、一般的に、ipfw と nat を用いた port forward には、ipfw の divert という命令を使うことも出来るようだが、同時に実行する natd に転送先IPアドレスを指定しなければならない。VMwareの場合に出来たとしても、vmnet-natd に何らかの設定が必要になるので、手間は変わらない。私が試した通り、vmnet-natd に想定された使い方をするのが最善だろう。

追記:VMwareの新しいバージョンをインストールすると、今回変更した設定ファイル nat.conf が上書きされていた。同じディレクトリにバックアップファイルは置かれているので、アップグレードの都度、設定を復元する必要がある。

| | コメント (0) | トラックバック (0)