ADPを開発する上で避けて通れないのが、『どうやって流行らすか？』になります。
もっとも、自己満足と言われようが何と言われようがADPの開発は続けますし使ってもいくと思うので、流行らなくてもという良いという考えもなくもないのです。
しかし、個人でやる開発ならそれでOKなのですが、人と仕事をする上ではこの手のこだわりが障害になったりしますし、この手の複雑なソフトウェアは広く動作させてフィードバックをもらうことが品質面からも重要になります。
要するにプロのエンジニア目線で考えると、自分が作った言語とは言えマイナーなプログラミング言語にかかわっているヒマはないということになるのですが、であればメジャーにすればよいということで『流行らそう』ということになりました。
もちろん、大前提として、流行らすに値する言語かということもありますが、そのあたりについてはまたの機会に書きます。
で、具体的に何をするねんって話になるのですが、色々考えているのですが、もちろんこのブログも布教活動の一環としてやっているのですが、その1つとして、未踏ソフトに挑戦するということがあります。ちなみにその後は、LLイベント（http://ll.jus.or.jp/）にパネリストとしてADPを布教することを目標にしております。
未踏ソフトですが、以前は2008年の下期に応募したのですが、残念ながら採択にならず、その後仕事が忙しくなったので応募していなかったのですが、今年はタイミングよく応募できそうです。
そのような訳でちょっと知らなかったのが、いつからか年齢制限（というか年齢での優遇）が35歳未満になったらしく、今年40の私としては、『いまさら応募するのもな~』という思いと、制度の趣旨が『人材発掘』つまり天才を発掘しようということらしく『じゃなんで俺を選ばないの？』という訳のわからん自信とが交錯し、どうするか迷う面があるのですが、とにもかくにも人から評価を受けるというのは非常に大事なことなのではあります。で決めかねています。
説明会の内容ですが、私的には面白い内容でした。単なる制度の説明だけでなくちょっと聞けない技術的な話もありましたので、たまにはこういうイベントに参加するのも良いものだと思います。これからもやるでしょうから未踏に応募する人は一度説明会に参加されることをお勧めします。
未踏の説明会の続きですが、説明会の中に技術的なセッションもありまして、グーグル株式会社のソフトウェアエンジニア 鵜飼さんの講演が面白かったのですが、その中で、『1GBのintのソートにかかる時間は、封筒の裏計算で、30秒』というのがありました。
パフォーマンスには一家言ある私ですが、さすがに1GBのintのソート時間にはピンと来ませんでした。
という訳で、ホントかどうかやってみました。
#include <vector>
#include <algorithm>
#include <iostream>
#include <time.h>
using namespace std;
int main(void)
{
vector<int> values;
srand(time(0));
// vectorに適当な値を入れる
for ( int i = 0; i < 1024*1024*1024 / sizeof(int); i++ ) {
values.push_back((int)(rand()*rand()-i));
}
// ソートする
clock_t t = clock();
sort( values.begin(), values.end());
cout << "Time(sort) is "
<< (double)(clock() - t) / CLOCKS_PER_SEC << "sec." << endl;
return 0;
}
実行時間（Core i7-920 Windows7 コンパイルVC++2008 リリースモード 64ビットモード）は以下になります。上記のプログラムですが、32ビットモードでは動作しません。32ビットプロセスはリニアに1GBのメモリは確保できないです。
Time(sort) is 43.895sec.
なるほど、確かに30秒からそう離れていません。
ちなみに、この手の封筒の裏計算ですが、桁が違わなければOKと考えてよいでしょう。なので、細かい値の違いが問題になる場合は、実アプリでキチンとベンチマークをとるのがよいでしょう。
この手の結果の受け止め方ですが、おそらく一般の業務アプリを作成する人にとっては『理論的限界値』程度に思っていた方がよいでしょう。つまり
1秒間に数百万個のint型のソートができる。数千万個になったら要注意。
と思っておけばよろしいかと思います。実際に私の経験でも行数が数百万件のソートをSQLで行うのはあまり問題になることはなかったです。（もちろんメモリが十分にあればの話ですが）。
実行時間の詳細ですが、説明では以下のとおりでした。
・要素を比較する回数（ソートのオーダnlogn）から、
2^28 * log(2^28) → 2^28 * 28 → 2^28 * 2^5 → 2^33(2の33乗)回
・比較に際してのL1キャッシュのアクセス時間 0.5ns / 回
・比較に際してのブランチペナルティ 2.5ns / 回（2回に1回ペナルティがあると仮定する）
実行時間 2^33 * (0.5 + 2.5)nsec = 25.76sec 約30秒
ただ、上記の計算ですが、ブランチペナルティが全体の速度を決定しているというのはいささか疑問があります。上記の場合、メモリのアクセス回数から計算した方が良いのでは？と思います。
つまり、
・要素を比較する回数（ソートのオーダnlogn）から、
2^28 * log(2^28) → 2^28 * 28 → 2^28 * 2^5 → 2^33（2の33乗）回
・ 比較に際してのメモリアクセス回数 2回（リード&ライト） 2*4バイト
・キャッシュライン 32バイト
・メインメモリへのアクセス回数 2^33 * 2 * 4 / 32 = 2^31 回
・メインメモリアクセス性能 1回のアクセス 10nsec（DDR3のレイテンシーから）
実行時間 2^31 * 10nsec = 21.47sec
うーん、数値的には似たり寄ったりであまり変わらないか・・・・
少し間があきましたが、技術ネタで。
new/deleteは、C++はもとより、最近のプログラミング言語なら当たり前のようにやる（おっとdeleteはしないか）かと思いますが、そのコストについてはついつい忘れがちになります。
ADPは、C++で作成しているのですが、オブジェクトをリサイクルするように変更したところ、実行速度が倍ぐらいに速くなった。もともとは速くするために行った訳ではないのだが意外な副産物となった。
Visutal C++ではいつのころからか（遅くともVC++ 2003以降）、newすると最終的にはWindowsのAPIが呼び出される。パフォーマンスにシビアなシステムでは、ローカル変数の定義のようにお気楽に出来るものではないかもしれない。
といっても理屈だけではなんなので、具体的にどのくらいのコストがかかるかベンチマークしてみました。
#include <iostream>
#include <vector>
#include <time.h>
using namespace std;
class myobject {
int myvalue;
public:
myobject() : myvalue(0){};
};
myobject *myobjects[10*1000*1000];
int test(int v)
{
return v * 1000;
}
int main(void)
{
clock_t t = clock();
// new（1千万回）
t = clock();
for ( int i = 0; i < 10 * 1000 * 1000; i++ ) {
myobjects[i] = new myobject();
}
cout << "Time(new) is "
<< (double)(clock() - t) / CLOCKS_PER_SEC << "sec." << endl;
// delete（1千万回)
t = clock();
for ( int i = 0; i < 10 * 1000 * 1000; i++ ) {
delete myobjects[i];
}
cout << "Time(delete) is "
<< (double)(clock() - t) / CLOCKS_PER_SEC << "sec." << endl;
// 関数呼出し（1千万回)
t = clock();
for ( int i = 0; i < 10 * 1000 * 1000; i++ ) {
test(i);
}
cout << "Time(function call) is "
<< (double)(clock() - t) / CLOCKS_PER_SEC << "sec." << endl;
return 0;
}
以下、実行結果（Core i7-920 Windows7 コンパイルVC++2008 デバッグモード）
Time(new) is 2.065sec.
Time(delete) is 2.35sec.
Time(function call) is 0.26sec.
Windows環境でC++だと、おおむね1秒間に約数百万個のオブジェクトが作れるようです。また、関数呼び出しは数千万回できるようです。
上記の実行結果はデバッグ環境で行っていますので、リリースモードで実行するとこれから数倍速くなります。
この手の数字にピンとこない人の為に補足しますと、最近のコンピュータは1秒間に数十億個の命令が実行できます。単純に計算しますと、メモリの確保は約千個の命令を使っており、関数呼び出しは約百個の命令を使うということになります。
先週は、嫌なお客の話をしたので、今週は、もう一度ご一緒に仕事をしてみたいお客様の話をします。
そのお客さんは、とあるCEサイトを業者に作ってもらったのですが、残念ながらバグバグのシステムで大変不満を持たれていました。おりしも不況と重なって会社もリストラを始めたり、元々の担当者が止めたりで、新しく担当になった方は、業務は解るが、IT（WEBサイト）のことはよく知らないといった感じの人でした。色々不満もあったかと思いますが、そういったことは表に出さないで真面目にプロジェクトに取り組まれていました。
もっともITのことはあまり詳しくなかったので私が業者との交渉（バグの伝え方から、改修予算の値引き交渉やら、相手から来たメールの意図を翻訳したり）のサポートを行っていたました。
ただ、ECサイトによくあることですが、いかんせん売上が上がりませんでした。そういう中で次期開発の話が出てきたのですが、当然やりたいことにお金（予算、売り上げ）がついてこないので、そのギャップに担当者の方が悩んでいまして、ミーティングで愚痴を言われていました。そこで、思わず私が、
「今までの経験上、上手く行かないやり方を続けていてはダメになるばかりでっせ」
と言いました。
つまり、売上を上げていないのなら、無理に開発を進めるのではなく現行のシステムは修正にとどめたり、儲からないサービスやめたりするのも手ですよというある意味当然のことを言ったのですが、ただ、多くの日本人は『止める』という発想がなかなかできないようで、私も過去にこのようなことを言ってプロジェクトから外されたこともありました（本音を言ってくれてありがとうという人もいました）。
今回もこれは言い過ぎかなとも思ったのですが、この一言が担当者を救ったらしく、サービスメニューの構成を変えるように話しが進みました。以前なら『生意気なことを言うな』と言われるところだったのですが、平成不況も長くなると営業の現場の人もプライドを捨てて話をされるようになったようです。
その後、残念なことにやはり改修の規模が大きくなり、コストがかさむと同時にリストラが進み担当者もご勇退されプロジェクト自体が空中分解して、結局はそのECサイトはまったく改善をされずに閉鎖になりました。
私自身は営業的に失敗したプロジェクトをいくつも経験しているし僭越ながら自社のシステムを含めて成功しているプロジェクトも経験しているのですが、そのプロジェクトが終了したことは残念でした。もちろん予算がないプロジェクトだったので私自身もアドバイザーという形で週に1回しか打ち合わせに参加していなかったので、私のかかわり方として不完全燃焼な面もありました。
次回、その顧客と仕事をする機会があればぜひもっと良い結果を出せるように頑張りたいと思いました。
不況が長く続きますが、こういう難局を乗り越えるのもソフトウェアエンジニアというよりビジネスパーソンとして真価を問われていることだと思います。頑張りたいものです。
このブログにアクセスするOSのトップは WindowsXP でブラウザはIE6だったりします。
一応バリバリの技術系のブログなのであまり普通の人は見に来ないと思うのですが、今週も、約3割が、IE6からのアクセスになります。IE6っていまだに現役なのですね。
第2位ですが、OSはVista(含む7）で、ブラウザはfirefoxだったりすします。
（私のAnalogは、最新のOSとfirefoxのバージョンをカウントしていない・・・。）
最近では、MACが増えてきましたが、このページはMACは扱っていなのだが・・・。
意外なのが、いまだにWindows98とか、Windows95、たまにWindows3.1アクセスがあるのですが、
おそらくそれらはスパムだと思われる。