トラックバック

IPv6 Ready?

はなおかじった — Wed, 25 Jan 2012 22:40:00 GMT

IPv4 のアドレスは、日本では枯渇しました。で、IPv6 なのですが。。。ところで、IPv4 は、32ビット、429,4967,296種類を表せます（実際に使用可能なアドレスはそれ以下）。IPv6 は、これを128ビット、3.4028236692093846346337460743177e+38種類にした、と。

それはいいとして、IP 層の下に、Mac アドレスってありませんでしたっけ？Mac アドレスって、枯渇しないんですかねぇ？
え？48ビット、281,474,976,710,656種類あるので、IPv4ほど差し迫ってはいない、ですって？でも、業者に割り当てられるのは、24ビットで16,777,216種類ですよね？千六百七十七万、と。ミリオンヒットを16回飛ばせるのか。しかも、機器に結びついているので、機器の破棄に伴って回収も可能、と（実際に出来るかどうかはともかく）。じゃぁ、大丈夫か。。。

そういえば、Mac アドレスって、固定じゃなく、変更出来る機器もありますよね？そして、「Wi-FiのMACアドレスはもはや住所と考えるしかない」なんて記事を見かけたのですが、これって、適当な Mac アドレスを入れると住所が出る、すなわち使われているアドレスかどうかがわかる、って事ですよね？で、その、Mac アドレスを変更出来る機器を、「存在することがわかったアドレス」に変更をすると、どうなるんでしょう？IP でのフィルターがされるから、他の所にデータが行っちゃうって事はない？他の所にもコピーされたデータが届くって事はないよね？

IPv6 とはまったく関係ないのですが、この辺のサービス提供者のやり方が気になる、というのがメインのエントリ。

ストリートビューもそうですが、「公共の場から集められるデータだから良い」のでしょうか。例えば、通りを歩いているのは、「公共の場から集められるデータ」です。でも、ある日時にある場所にいることを知られる事がイヤな場合があります。ストリートビューでは、そういう場合を、いつでも、どこからでも、誰にでも、検索して見える状態にする、という性質があります（マスキングはされますけど）。問題なのは、「公共の場で集めることができるデータを集める」事ではなく、それを「いつでも、どこからでも、誰にでも、検索して見ることが出来る状態にしている」ということ、それが「オプトインではなくオプトアウトとして提供されている」こと、「収集して公開されているということが周知されていない」ということ、ではないでしょうか。

そして、Wi-Fi による位置情報サービス。HTML5 の GeoLocation API で使用するサービスのひとつですが、ある地点で観測できた Mac アドレス（Google の場合は複数）を引き渡すと、その場所の位置情報（緯度、経度）が返ってきます。「ある地点で観測できた」という所が焦点です。無線 LAN の親機は、SSID と Mac アドレスを放送しています（ここで「放送」という用語を用いるのは正しくないが）。GPS 機能の付いた機器を用いて公道でこれを収集し、問い合わされた Mac アドレスから位置情報を逆引きして返すわけです。公道で収集できるデータだから集めて良い、ってものなんですか？私が最初に無線 LAN を導入したとき、SSID にファミリーネームを設定しちゃいましたよ。でも、鉄筋コンクリート製の建物だったせいか、電波がまったく通らないので、すぐに有線に切り替えちゃいましたけどね。引っ越しをして、今度は大丈夫だろうと思ったけど、鉄骨製だからか、扉を閉めると通らない。「ブースター付き」とかいう機械を買ってきたのに。まぁ、子機もブースター付きってのを使えば何とか受信できるのと、引き回しの関係で有線に出来ないので、不便に思いながら使っているけど。で、新しい方の SSID は、デフォルトのまま使っていますが、Mac アドレスです。自分のもの以外の観測できる SSID は、メーカー名や機器名が SSID になっています。ほう？ということは、近所の人が同じメーカーや同じ機器を買ったら、SSID がかぶっちゃうわけですね。私が買ったものは、「Mac アドレスならかぶらないだろう」ということで Mac アドレスになっているのかな。で、こいつを、公道に放送したいとは思っていません。でも、漏れて行ってしまっていると思います。止める方法があるなら教えて欲しい。「家を金属板で覆え」って？そろそろ外壁を直さなきゃいけないので、その時、本気で考えようかしら？？？

なんてことを書いていたら、こんな記事も発見しましたよ→「WiFiのアクセスポイントが街中で増えることの功罪」。公衆 Wi-Fi が増えすぎると、かえって困った事態が発生すると。Ｒさん、喜ばしいことだけではないみたいですよ。（トラックバック：「自販機 Wi-Fi」）

オブジェクトを指向してみる／そもそも「オブジェクト」って、何？

はなおかじった — Sat, 19 Jun 2010 22:29:00 GMT

「オブジェクトを指向してみる／何故インスタンスを作るの？」の続き、ってことで。

元ネタのみながわさんのコラムでは、次のように書かれています。これを考察してみましょう。

実はオブジェクト指向ってしっくりこないんです！（システムエンジニア生き残りの極意）より：

オブジェクト指向は、結局のところホントにモノ（オブジェクト）に使われている記法、例えばGUI コンポーネント、データベース、ファイルなどであって、プログラムのアルゴリズムとは無関係のものである。

ふむ。確かに、「オブジェクト」って、なんでしょう？

引用したところには、「例えば GUI コンポーネント、データベース、ファイルなどであって、プログラムのアルゴリズムとは無関係」と書かれています。これ、「プログラムのアルゴリズムとは無関係」に、強く、興味を持ちました。はたして、無関係なのでしょうか。

とりあえず、この時点では、無関係ではないと思います。

では、“アルゴリズム”って、なんでしょうか。ここから始めましょう。「アルゴリズム：プログラムを作るときに用いる、問題を解決するための手順・計算方法。◇アラビアの数学者アル＝フワリズミにちなむ。もと、算用数字を用いた筆算の意。（明鏡国語辞典）」だそうです。さて、オブジェクト志向は「プログラムの手順」とは関係がないのでしょうか。関係がないとすると、どの様に関係がないのでしょう。

その為にはまず、「オブジェクト志向言語」において、「オブジェクト」とされる物は、いったいなんでしょうか。

私は、「データと、それを扱うための手続きを組み合わせたもの」だと思います。

我々は、現実に発生している問題を解決するために、コンピューターの中に問題を投影し、プログラミング言語等を用いて問題を解決する方法を組み立てます。つまり、「会員名簿の管理」であったり、「勤怠情報の管理」であったり、「写真に写っている人を判別する」であったり、「宇宙船の姿勢を制御する」であったりという問題を解決するためにコンピューターを使います。そこには、「処理するべき情報」が存在しています。そしてその情報には、「処理されるべき手順」が存在しています。この、「処理すべき情報」に対して「処理すべき手順」を見つけ出し、ひとまとまり（パッケージ）にして扱うことが、「オブジェクト指向処理」（勝手用語）だと考えます。

「オブジェクト志向プログラミング」と、「プロセス志向プログラミング」の違いは、何に志向するか、意識や思考を向ける対象にあるのではないでしょうか。プロセス志向では、「為すべきこと」を為す手順に志向します。オブジェクト志向では、「為すべきこと」に関係するオブジェクトに志向します。従って、プロセスに志向しながら、オブジェクトを使うことはできないのではないでしょうか。ただし、オブジェクト志向では、「情報と、その操作手順」がオブジェクトですから、最終的には、プロセスにも志向しなければなりません。

では、なぜ、オブジェクトに志向する、すなわち、情報と、その操作手順をパッケージするのでしょうか。

私が最初にオブジェクト志向言語に触れたのは、当時在籍していた課でオブジェクト志向言語を扱う最初、または2番目の事案でした。そして課長が、こう尋ねました。「オブジェクト志向って、どんなもん？」。まだ触って間もないので、「どう？」と聞かれて困ったのですが、こう返答しました。「メンテナンスがし易いようにするためのものだと思います。最初に時間をかけて設計して、後のメンテナンスが楽になるようにするものだと思います」。この感想は、今でも変わっていません。オブジェクト志向が、情報と情報を扱う手順をパッケージするのは、プログラム（あるいはシステム）のメンテナンスをし易くするためと考えます。

プログラム（あるいはシステム）の「メンテナンス期間」とは、なんでしょうか。ここでは、「最初のリリースが終わってから、プログラム（あるいはシステム）が破棄されるまで」とします。あるいは、「最初のビルドが終わってから…」でも良いかもしれません。

つまり、オブジェクト志向ナントカとは、一度動くようになってから後の仕様変更に対して、如何に対応し易くするかを考えたナントカである、と考えます。

では、どうして、パッケージ化すると、仕様変更に対して対応しやすくなるのでしょうか。

たいていの場合、仕様変更は、扱う情報の変更を伴います。オブジェクト志向分析がなされ、オブジェクト志向設計がなされているなら、変更が起こった情報を特定しやすくなります。また、その情報を扱う方法は、他の情報からは独立しているはずですから、情報処理手順の変更による影響を、他の情報へ伝播させにくくなります。他の情報や、情報処理方法が、他の情報を変更したことによる影響を受けないのなら、修正の範囲は小さくなり、テストの範囲も小さくて済みます。これらの範囲が小さいと言うことは、工数の減少にも繋がります。

実際に、このような設計を行うには、かなりの経験が必要だと思います。しかし、特に Java や .NET Framework では、用意されているフレームワークにあるクラスが、高度に抽象化されています。これによって、使う人がオブジェクトに志向しなくても、オブジェクト志向言語を使ったプログラミングができてしまいます。

「オブジェクト志向言語を使ったプロセス志向プログラミング」と、「オブジェクト志向プログラミング」。この二つは、混同してはいけないと思います。

オブジェクトを指向してみる／何故インスタンスを作るの？

はなおかじった — Fri, 28 May 2010 22:20:00 GMT

実はオブジェクト指向ってしっくりこないんです！（システムエンジニア生き残りの極意）より：

　「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。

　staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。

向こうでコメントしようかと思ったけど、もったいないのでエントリーにする。

さて、コメントに、コラム著者のサイトSE WORLD システムエンジニアの世界 IT技術というサイトへのリンクがありました。そしてそこには、「ASP.NET ASP.NETのサンプルコードです。典型的なコードパターンを列挙してみました」というのがあるので、ここを見ます。…だって、MVP for ASP.NET なんだもん、一応。その中で、これを取り上げてみる。

ファイルアップロードコントロール（SE WORLD システムエンジニアの世界 IT技術）より：
using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
public partial class _Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
    protected void Button1_Click(object sender, EventArgs e)
    {
        if (FileUpload1.HasFile) {
            //string strSaveAs = "C:/test/" + FileUpload1.FileName;
            string strSaveAs = "//マシン名/フォルダ名/" + FileUpload1.FileName;
            FileUpload1.SaveAs(strSaveAs);
        }
    }
}
　リモートマシンにも保存できるが、アクセス権がeveryone 書き込みになってないと難しい。ちなみにIIS6.0のASP.NETのプログラムアカウントのデフォルト値はNetwork Serviceです。

センタリングされていて見にくいので、見やすいように修正しました。

さて、この中で、FileUpload1 というのが、FileUpload クラスのインスタンスです。そして、HasFile とか、SaveAs というのは、FileUpload クラスのメンバーです。では、いちいちインスタンス宣言しているので笑ってしまうということなので、インスタンス宣言しなくてもいいように（インスタンスを作らなくてもいいように）、FileUpload クラスのメンバーが全て pubulic static宣言されていると仮定します。つまり、「pubulic static宣言だと、こんなに使いにくいぞ」ということを示すことで、なぜインスタンスを作るのかを理解してみよう、という試みです。

FileUpload クラスのメンバーが全て静的なので、1ページからは1度に1つのファイルしか、アップロードできなくなります。複数のファイルをアップロードしようとすると、FileUpload クラスから導出して、FileUpload1 クラス、FileUpload2 クラス、FileUpload3...と、インスタンスの代わりにクラスを複数作らなければなりません。これは、「コードを書く手間」を考えると、とても不便ではないでしょうか。また、それぞれでクラスが違うのですから、最初に配列を宣言して、インスタンスを作るというわけにもいきません。これも、不便ではないでしょうか。


// 配列を宣言して、インスタンスを生成する
FileUpload[] fileUp = new FileUpload[10];
foreach (FileUpload f in fileUp) {
    f = new FileUpload();
}
// メンバーを静的にすると、上記のように出来ず、
// クラスを10個作らなければならない
class FileUpload01 : FileUpload {};
class FileUpload02 : FileUpload {};
class FileUpload03 : FileUpload {};
...
// その後、配列に登録する。
FileUpload[] fileUp = new FileUpload[10];
fileUp[0] = FileUpload01; おおっと、クラスは登録できないや！！

これで、「static にせずにインスタンスを作るのはなぜ？」の答（のひとつ）になるかな？

それでは、反論も考えてみましょう。

2010年4月28日 (水) 08:53

むしろC言語の構造体はいやになるほど書いたから、逆にビジネスロジックのクラスの優位性についてピンとこないのです。

なるほど。

FileUpload は、データだけを持つ構造体であるとすると、どうなるでしょうか。例えば、こんな定義がどこかにあって、それを使って保存することになります。


public class StaticFunctions {
    private StaticFunctions() {};
    public static void SaveAs(const FileUpload fu, const string saveFileName) {
        // 処理は省略
    }
    public static void SaveAs(const FileStream fs, const string saveFileName) {
        // 処理は省略
    }
    public static void SaveAs(const MyStructure ms, const string saveFileName) {
        // 処理は・・・おおっと、オーバーロードさせてよかった？
    }
}

私は、似て非なる構造体を多数書いたので、クラスの方がいい、と思いましたね。

様々なコメントが付いていますが、このコメントがもっとも秀逸だと思います。

2010年4月27日 (火) 16:14

OOPは理解できないから使わない、と主張されるのは結構だと思います。

しかし、自分が理解できないからといって「知ったかぶってOOPするヤツら笑っちゃう」というような論調で話を進められるのは宜しくないですね。

変数が隠蔽できるか否かはOOPの本質ではないんです。そもそも言語仕様としてクラスやプロパティがあるかどうかも本質ではないのです。言語仕様はよりOOPしやすくするための道具にすぎません。

極意を示すコラムなのですから、OOPを理解したうえで「俺はOOPしない！」と主張する生え抜きのロートルエンジニア（＜良い意味で言っています）が、その経験と技術でもってOOP全盛時代を生き残る方法論を論じる、くらいのレベルの高さがあって欲しいですね。

こんな風に、簡単にまとめられる技量が欲しいです。。。

協調性とリーダーシップは対立する？

はなおかじった — Thu, 22 Apr 2010 22:01:00 GMT

リーダーシップより協調性　保護者の「理想子ども像」（MSN 産経ニュース）より：

　国公立の幼稚園に通う子供を持つ保護者に「理想の子ども像」を聞いたところ、ほぼ全員が「人に迷惑をかけない」など協調性を求めたのに対し、「リーダーシップがとれる」とした保護者は約半数にとどまったことが８日、全国国公立幼稚園長会が実施した調査で明らかになった。

　岡上直子会長は「最初から協調性ばかり求めると、成長した時に他人の意見ばかり気にして、自分の意見が言えないようになる恐れがある」と話している。

　調査は昨年１０～１１月に実施され、全国の保護者約３千人や教員約１１００人が回答した。

　子供の理想像（複数回答）では、「人に迷惑をかけない」「礼儀作法をわきまえる」「ルールや決まりを守れる」という項目で、「そう思う」「ややそう思う」と答えた保護者が合わせて９８～９９％に上った。

　一方「リーダーシップをとれる」は合わせて５４％、「人より秀でたところがある」も５９％に留まった。

ニュースのタイトルは「リーダーシップより協調性」となっている。これより、「対立」しているかどうかはともかく、「別の物」という事になっていることは、わかる。このブログのタイトルは「釣りタイトル」として、はたしてリーダーシップと協調性は別の物なのだろうか。

ニュースタイトルを読んだ時点での感想は、「違う」、つまり「同じ物」あるいは「リーダーシップは協調性の延長線上にある」というもの。

リーダーは、集団をまとめなければならない。集団には、様々な意見がある。反対意見をまとめ、説得しなければならない。単に「俺の命令を聞け」は、リーダーではない。独裁者だ。違いは、協力を得られるかどうか。いや、まぁ、ヒトラーも、彼を崇拝する人からは尊敬や協力を得ていたのだろうけれど。だからといって、彼を「リーダー」と言う人がいるだろうか。とすると、「後の評価」になるのか。「後に遺恨を残さない方法で、集団の協力を得る」とか。

何にしても、「協力を得る」ためには「協調性」が要るだろ、と。

最後に、Wikipedia から引用。

リーダーシップ（Wikipedia）より：

リーダーシップの概念は非常にさまざまな議論があるが、一般的には一人の人間がその他の人間から服従、信頼、尊敬、忠誠、協力を得られるような方法で人間の思考、計画、行動を指揮でき、かつそのような特権を持てるようになる技術及び才能を指すと考えられている。それは意思決定を行う指揮、労力や資源を配分・管理する統制、心的作用による統御の三機能から構成されると考えられているのが一般的。

cout はマルチスレッドセーフではない？

はなおかじった — Fri, 12 Mar 2010 00:26:00 GMT

ネタ元から引用。

スレッドセーフとインテルTBBのコンテナの、コメントより：

　最後にcoutの取り扱いについての注意するべき点を書きます。このサンプルでは単純化するためにロック処理をしていませんが、coutはスレッドセーフではないので、並列処理時にcoutに出力を指定するとコンソール画面の表示が滅茶苦茶になります。試しにparallel_for( blocked_range( 0, count, 10000 ), pop );の部分をparallel_for( blocked_range( 0, count, 1 ), pop );に変えてみてください。何度も実行すると表示がおかしくなるのが確認できます。もしうまく行かない場合は、さらにcout << value << " ";の部分を変更して、長い文字列を出力するようにしてください。

これを踏まえて、コメント。

インドリ（2010/03/03 09:12）

＞スケジューラーの初期化について
並列処理では実行順序が保障されません。
しかも、アセンブラレベルで命令が実行されております。
その状態なのですから、初心者がTBBとネイティブスレッド・OpenMPなどの処理を併用させたときに、どのようなプログラムでも正しく実行できると100％の自信を持って言えるでしょうか？
私はそんな危険を冒すよりも1行のプログラムを書く方を勧めます。

インドリ（2010/03/03 15:55）

スレッドセーフをもっと正式に言いますと、クラスが複数のスレッドからアクセスされた時に、各スレッドのスケジューリングや実行のタイミングがどうであっても、また呼び出し側コードからの同期化努力やその他の調停努力がなくても正しく振舞う事をスレッドセーフといいます。

MSの実装ではcoutを一行で書いた場合、短いサンプルでは一応各文字が混ざる事はありません。しかし、必ず一行で書くというのは実務的に考えて無理な話です。ですから普通の人は・・・
cout << "foo" << .....
(なんらかの処理をする)
cout << "bar" << ...
とプログラミングするでしょう。また必ず一行で書くという行為はcoutという標準出力オブジェクトの不変項と事後条件を満たしていると言えるでしょうか？

ふぅ。。。なんという素人。

まず、cout、iostream がスレッドセーフであるというエビデンスから。

Sun Studio 12 Update 1: C++ ユーザーズガイドより：

11.1 マルチスレッドプログラムの構築

C++ コンパイラに付属しているライブラリは、すべてマルチスレッドで使用しても安全です。

11.1.2 C++ サポートライブラリの使用

C++ サポートライブラリ(llibCrun、libiostream、libCstd、libC) は、マルチスレッドで使用しても安全ですが、非同期では安全(非同期例外で使用しても安全) ではありません。したがって、マルチスレッドアプリケーションのシグナルハンドラでは、これらのライブラリに含まれている関数を使用しないでください。使用するとデッドロックが発生する可能性があります。マルチスレッドアプリケーションのシグナルハンドラでは、次のものは安全に使用できません。

iostream

new 式とdelete 式

例外

11.3 C++ 標準ライブラリのオブジェクトのスレッド間での共有

C++ 標準ライブラリ(libCstd -library=Cstd) は、いくつかのロケールを除けばマルチスレッドで使用しても安全なライブラリで、このライブラリの内部は、マルチスレッド環境で正しく機能することが保証されています。ただし、依然、スレッド間で共有するライブラリオブジェクト周りには注意を払う必要があります。setlocale(3C) およびattributes(5) のマニュアルページを参照してください。

Thread Safety in the Standard C++ Library （.NET Framework 4）より：

iostream Classes

The iostream classes follow the same rules as the other classes, with one exception. It is safe to write to an object from multiple threads. For example, thread 1 can write to cout at the same time as thread 2. However, this can result in the output from the two threads being intermixed.

Thread Safety in the Standard C++ Library （.NET Framework 1.1）より：

iostream Classes

Note that reading from a stream buffer is not considered to be a read operation. It should be considered as a write operation, because this changes the state of the class.

For reads to the same object, the object is thread safe for reading:

From one thread at a time when no writers on other threads.

From many threads at a time when no writers on other threads.

For writes to the same object, , the object is thread safe for writing:

From one thread when no readers on other threads.

From many threads (when accesses are limited to stream buffers).

For reads to different objects of the same class, , the object is thread safe for reading:

From one thread at a time.

From one thread at a time when no writers on other threads.

From many threads at a time.

From many threads at a time when no writers on other threads.

For writes to different objects of the same class, the object is thread safe for writing:

From one thread when no readers on other threads

From many threads

この様に、iostream は、スレッドセーフです。ただし、スレッドセーフなライブラリだけを使ったからといって、アプリケーションがスレッドセーフになるわけではありません。ここの所を勘違いすると、困ったことになります。上の例は、そういう勘違いをしているわけです。

さて、どういうことでしょうか。

concurrent_queue は、マルチスレッドで使えるように、TBB で用意されたクラスです。このクラスに用意されたメソッドは、スレッドセーフです。では、次のようなプログラムを作ったら、どうなるでしょう？


キューは、concurrent_bounded_queue を使うものとする。
スレッド1() {
    1～10000のうち、奇数をキュー インする。
}
スレッド2() {
    1～10000のうち、偶数をキュー インする。
}

こんなことでコード書いて動作検証するのも面倒。はい、上記2つを、並列に動作するスレッドで呼び出したとします。キューには、どの様に入るでしょうか。答え。予測不能。はい、アプリケーションは、マルチスレッドで、期待する動作と異なる結果を返しました。よって、「concurrent_bounded_queue はスレッドアンセーフです」。

そんなバカな。

スレッドアンセーフなのはアプリケーションであって、concurrent_bounded_queue ではありません。もしくは、「スレッドセーフか」は関数やメソッド単位で保証されるものであり、開発者がアプリケーションとしてどうなのかを作り込みます。ここを取り違えて「cout はスレッドセーフではない」というのは、まったく馬鹿げています。いじょ。

並列化に関する記事紹介

はなおかじった — Wed, 23 Dec 2009 21:53:00 GMT

紹介→「並列化の難しさの議論には間違った部分がある」

Intel の中の人へのインタビュー記事。特に、この言葉に注目→並列プログラミングの難しさ（snip）は，効果的なアルゴリズムの選択だ。メモリーの内容が壊れてしまうとか，制御フローを組むのが難しいといった部分は，本質的なものではな（い）

あることを実現する方法は、ひとつだけとは限りません。ふたつ、あるいはそれ以上、存在することが多々あります。同じ事を実現するために、より効率がよい方法を選ぶことは、重要なことです。ここで「効率」は、単に実行速度が速い、ということだけでなく、拡張性や保守性といった因子も含まれます。多くの知識を持っていることは、多くの選択肢を持っていることに繋がります。勉強の嫌いな私にとって、「多くの選択肢を持つ」ために勉強しなければならないのは、苦痛なんですけどねorz

あと、並列化の事じゃないけど、2ページ目の、ここ→他のコンパイラで作って，最後にコンパイルをする人だけIntelの製品を使ってもいい
な、なるほど！こういう考え方は、なかったわ！！

Multi-Core と Multi-Thread

はなおかじった — Wed, 16 Dec 2009 22:40:00 GMT

ネタもと→インテルスレッディング・ビルディング・ブロックの概要

どうして、こう、中途半端な記事を上げられるのか、不思議。ハッ！こうしてトラックバックさせることで、記事の参照数を増やそうという魂胆か？！

さてさて。何でもかんでもマルチスレッドに出来るか、というと、そうでもありません。マルチスレッドの、向き不向きがあります。それをまず、検証するのが、今回のエントリ。

ちょっと考えたのですが、Quick Sort のアルゴリズムが説明しやすいかな？

ご存知ではない方のために、ごくごく簡単に説明しておきます。例えば、次のような数値が与えられているとして、これを1から順番に並べたいとします。

{ 1, 8, 4, 10, 65, 3, 87, 5, 90, 52, 31, 78, 45, 9, 34, 67, 11, 41, 99, 75, 21 }

第1ステップは、ここから適当に1つを選びます。例えば、「75」とします。この、「適当にひとつを選ぶ」という事についても、蘊蓄が色々あるので調べてみて下さい。
第2ステップは、この「75」より小さいものは「75」の左へ、大きいものは「75」の右へ、順番は適当で良いので寄せます。

{ { 1, 8, 4, 10, 65, 3, 5, 52, 31, 45, 9, 34, 67, 11, 41, 21 }, [75], { 87, 90, 78, 99 } }

すると、「75」の位置が確定しました。
第3ステップは、確定した数値の右と左で、2つのステップを繰り返します。

しまった。「75より小さい」「75より大きい」としてしまった。当然、「75が複数あったらどうなるの？」という疑問が生じます。大きい方か、小さい方か、どちらか決めて、寄せます。

と、ここで、考えます。これから行う事は、「1．ひとつの数値を選ぶ。」「2．その数値と全ての数値を比べ、大小によって分類する（ここでは、あえてソートと言わない）。」「3．分類された項目の数が1つになるまで、分類結果に対して1と2を繰り返す。」です。分類しなければならない範囲は異なりますが、しなければならない作業は同じです。つまり、for や while による繰り返し、あるいは再帰構文によって、表現できることがわかります。

マルチスレッドが効率的に機能する（箇所のひとつ）のは、ここです。マルチで作業することが、互いに影響を及ぼしあわない。そして、それがそれなりに時間がかかるとき、です。

複数の処理で行う事が、互いに影響を及ぼしあうときを考えます。処理Ａが読み込む値は、処理Ｂが計算します。このとき、処理Ａは、処理Ｂが計算を終えてしまうまで、待機しておかなければなりません。この場合、処理Ａと処理Ｂを平行に実行させる意味はありません。

遅いけれども、アルゴリズムの説明によく用いられる、バブルソートというソート方法があります。これは、マルチスレッドで行う事で、高速化が見込めるでしょうか。検証します。

まず、アルゴリズムの確認です。バブルソートは、配列の終端（あるいは始端）から2つの要素を比較し、より小さい方（大きい方）を配列の始端（終端）の方へ入れ替えます。1度配列の要素を全て比較すると、一番小さいものが始端にきています。これを、何度も繰り返します。

{ 1, 8, 4, 10, 65, 3, 87, 5, 90, 52, 31, 78, 45, 9, 34, 67, 11, 41, 99, [ 75, 21 ] }

75と21を比べると、21の方が小さいので、入れ替える。以下、順に前へ移動していく。

{ 1, 8, 4, 10, 65, 3, 87, 5, 90, 52, 31, 78, 45, 9, 34, 67, 11, 41, [ 99, 21 ], 75 }
{ 1, 8, 4, 10, 65, 3, 87, 5, 90, 52, 31, 78, 45, 9, 34, 67, 11, [ 41, 21 ], 99, 75 }
{ 1, 8, 4, 10, 65, 3, 87, 5, 90, 52, 31, 78, 45, 9, 34, 67, [ 11, 21] , 41, 99, 75 }
{ 1, 8, 4, 10, 65, 3, 87, 5, 90, 52, 31, 78, 45, 9, 34, [ 67, 11] , 21, 41, 99, 75 }
{ 1, 8, 4, 10, 65, 3, 87, 5, 90, 52, 31, 78, 45, 9, [ 34, 11 ], 67, 21, 41, 99, 75 }
{ 1, 8, 4, 10, 65, 3, 87, 5, 90, 52, 31, 78, 45, [ 9, 11 ], 34, 67, 21, 41, 99, 75 }

ここから面倒なので早送り

{ 1, 8, 4, 10, 65, 3, 87, [ 5, 9 ], 90, 52, 31, 78, 45, 11, 34, 67, 21, 41, 99, 75 }
{ 1, 8, 4, 10, 65, [ 3, 5 ], 87, 9, 90, 52, 31, 78, 45, 11, 34, 67, 21, 41, 99, 75 }
{ [ 1, 3 ], 8, 4, 10, 65, 5, 87, 9, 90, 52, 31, 78, 45, 11, 34, 67, 21, 41, 99, 75 }

やっと先頭が確定。今度は99と75を比べるところから、またスタート。

バブルソートは、二重のループが使われます。ループするのだから、マルチスレッドにすると速くなるでしょうか。

残念ながら、バブルソートは、マルチスレッド化出来ません。2回目のループで比較するのは、1回目のループで比較した結果だからです。内側のループも、外側のループも、ひとつ手前の回の結果が必要なので、順次処理するしかないのです。

このように、ある処理をするために、別の処理の結果が必要な場合、マルチスレッド化することは出来ません。「必要」な処理が済むまで、出来ないのですから。

このことは、システム開発の「工程」に照らし合わせると、より理解できるのではないでしょうか。システムを作り上げるために、必要な「処理」が洗い出されます。その処理の依存性を明らかにして、「処理群」を作ります。処理群を、担当者に割り当てます。この、「担当者に割り当てる」というところが、複数のスレッドを作ることになるわけです。

このとき、並行に処理させられる処理群は、リソース、つまり担当者の数によって決まります。担当者の数を超えて平行な処理群を作っても、誰かが一人で処理群を切り換えながら処理を行うため、効率は上がらず、返って切り換えのために効率を落とすことになるかもしれません。もちろん、処理内容によって、実際にどうなのかは異なります。待ち時間が多い処理ならば、その待ち時間を他の処理群に割り当てることで、効率的に処理できるかもしれません。もちろん、他の処理の結果に依存しないことが前提です。

どの様なところに、マルチスレッドが活きるか。それを見極めるために、まず、分析ということですね。実行するべき事同士が、結果に依存しないなら、並行に処理させられます。結果に依存するなら、平行には出来ません。やるべき事を把握していれば、何も難しくはありません。

これはとてもひどい

はなおかじった — Thu, 29 Oct 2009 22:51:00 GMT

ネタもと→こ　れ　は　ひ　ど　い

なんか、システムエンジニアさん、らしいです。本当かよ、この乱文。

特に、これといったエクスペリエンスはなかったので、あ、何となく軽くなったかな、といった程度で、Vista の焼き直し版的な色彩が強いです。

推敲した？見直した？こうじゃない？→「特に、これといったエクスペリエンスは見あたりません。「あ、何となく軽くなったかな？」といった程度で、Vista の焼き直し版的な色彩が濃いです。」

「Vista の焼き直し」ってなぁ。。。winver.exe コマンドを実行すればわかりますが、Windows 7 のバージョンは 6.1。Vista は 6.0 です。Windows 2000（5.0）に対する Windows XP（5.1）と同じ位置なわけです。XP の時も、色々あったなぁ。

「これといったエクスペリエンスは見あたらない」んだ。私は、ふるふるシェイカーに驚いたけどね。エクスプローラーのメニューに、「新しいフォルダー」があるのも、ぐぅ～！Aero が有効な場合、右下にマウスカーソルを移動させるとデスクトップが見えたり、他のウィンドウを透明にするのなかんも、気に入っているんだけどなぁ（Virtual PC 内で使う分には、使えないのが悲しい）。

うちの場合、以下のアプリケーションがインストールに際して除去しなければいけなかったものです。

「何を」インストールするために、除去しなければならなかったのか、わかりません。おそらく、Windows 7 へアップグレードインストールするために、前もってアンインストールしておかなければならなかった物だと思います。でも、どうして、アンインストールしておかなければならないとわかったのか、わかりません。

なお、WinDVD 6 は、OSアップグレード後、もう一度インストールすることで解決できましたし、LBP-3100も、キヤノンのホームページにデバイスドライバがあったので、それを使用して解決できました。

うん。で、他のは？

これは、何らかの原因で、旧来の Ready Boost が0バイトになっていましたので、デバイスを再フォーマットして、作り直す必要があります。

私のところでは、フォーマットの必要はなかった。ドライブのプロパティで、ReadyBoost タブを開き、「このデバイスを使用しない」にして [OK]。USB ドライブのルートから、ReadyBoost.sfcache ファイルがなくなっているのを確認してから、もう一度設定すれば OK。

「なんらかの原因で」って、原因はわからないのね？抜き差しの仕方が悪くて壊れたかもしれないのね？

MS Outlook 2007 で、メッセージのハイパーリンクが押下できない

何が起こって、どういう申し出に、どういう対応があったのか、さっぱりわからん。わかるのは、「名前を間違われた」事だけ。それも、相手が悪いのかどうか、よく分からん。私は、「はなおか」だけど、「たなか」と聞き直されることがある。私の発音、滑舌が悪いからなんだろう。

なんか、これ、コラムなの？

コラム: 新聞・雑誌などで、短い評論などを載せる囲みの欄。
評論: ある物事の内容を論じ、批評すること。
論じる: ある物事について筋道を立てて述べる。
批評: 物事の長短・優劣などを指摘して評価を述べること。

長短、優劣などの「指摘」が、何処にされているんだろう？ここに書かれているのは、個人の「感情」でしょ。ここに書かれている事の何処が、「筋道を立てて述べてある」のだろう？感情が感情のままに書かれているだけでしょ。コラムじゃなくて、メモだよ、これ。メモはチラシの裏か、自分のブログでどうぞ。

しかも、コメントが、また、ひどい。

あんたもひつこかね。今、大阪脱出作戦に向けて、首都圏の親類縁者すべてにホームステイ願いをお願いしているところなので、お前と遊んでいる暇はなかばい。

どこへでも去ね。あと、こんにちは、じゃなくて、こんばんはの時間なので、コピペなどというちゃちいことはやめようね。やることが姑息で幼いよ。

ん～～～。これ、“本文に”書いていたら、掲載されるのだろうか？

ここはひどい

はなおかじった — Mon, 26 Oct 2009 22:38:00 GMT

【戸田覚がWin7を総点検2】そもそもWindows 7は使いやすくなったのか？（戸田覚がWindows 7の○と×を総点検）より：

さすがのWindows 7も、常駐ソフトが増えると起動に時間がかかるのだ。

記事ではなく、上記引用部分ピンポイントです。

いくら OS が進化しようが、いくら CPU コア数が増えようが、「ハードディスクからメモリへの転送」は、順次処理するしかなく、バスの転送速度以上に速くなったりしない。この言葉は、なんか、間違ってる。

1から10まで足す、ですって？

はなおかじった — Thu, 01 Oct 2009 22:41:00 GMT

プチ祭り？「気がつくと」とか、「[C++] １から１０まで足す」とか、「1+2+…+10」とか、「[C] 1から10までの総和をマクロでエレファントに解く。」とか。

「55と出力する」に決まってるじゃないですか。


10 REM This code is written for N80-BASIC
20 PRINT 55

大元のネタは、おそらく、「転職活動する暇があったらブログを書け」について（ベンチャー社長で技術者で）だと思います。私の答えは、一般社会ではそれではダメで、意図がまったく読み取れてないからゼロです。だ、そうです。

うむ、そうですか。私は、意図を、読みません。だって、読み間違えていたら、手戻り作業が大変じゃないですか。だから、意図は尋ね、確認します。・・・いや、ごめんなさい。これからは確認します。今、意図を読み違えて大変なことになっているのよ～～(T^T)

私が上記のようなコードを書いた意図は、わざわざ「written for N80-BASIC」と、今回は remark を振ったところにあります。N80-BASIC は、インタープリター言語です。逐次翻訳です。FOR 文を書いたら、命令をコンパイルしながら実行するので、遅いのです。先に計算できるものはしておく。インタープリター言語を使っていた頃の、ひとつの知識です。

もちろん、C/C++ で、次のように書くのもありです。これもコンパイル時に最適化で計算されてしまいます。


#include "stdafx.h"
#include <iostream>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
    cout << 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 << endl;
    return 0;
}

ところで、ここのコメントに、「10億だったら…」とありますが。

まず、10億だったら、答えは何か。
10だと、55
100だと、5050
1000だと、500500、です。法則が見えましたね。
10億は1000000000、0が9個あるので、5の後に0を8個入れた、500000000500000000…50京5億です。

これがコンピューターに計算できるか？微妙です。なぜなら、コンピューターが扱える数の範囲には、限りがあるからです。

演算に用いる型のビット数が32ビットの場合、約21億（符号無しで約42億）が最大となります。このため、32ビットの整数型では、計算途中にオーバーフローが発生します。64ビットだと、約922京（符号無しだと約1844京）です。SQL Server や Oracle ではもっと大きな数字を扱えます。SQL Server 2005以降と Oracle では38桁扱えます。えっと。。。京、垓、杼（正しくはノ木偏）、穣、溝、澗の、澗（カン）だそうです。

じゃぁ、64ビットだと、いくつまで計算できるでしょうか。10億で50京です。100億だと5千京です。ああ、超えた。。。

反対にしよう。総和が922京になる数字を求めよう。・・・4294967295。これの答えが9223372034707292160。約922京なので、求められるはずです。

ところが、生島さんが期待する「(n + 1) × n ÷ 2」の計算式では、答えが求められないのです。

なぜでしょう？

「(n + 1) × n」で、約1844京となり、桁あふれを起こすからです。922京を2倍して平方根を取ると、42億になります。が、それを先に書くと1844京という値が先に出てしまい、オーバーフローがチョンばれです。その為、上ではいきなり42億という数字を出しています。

検証
#include "stdafx.h"
#include <iostream>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
    __int64 max = 4294967295;
    __int64 sum = 0;
    for (__int64 i = 1; i <= max; ++i) {
        sum += i;
    }
    cout << sum << endl;
    cout << (max + 1) * max / 2 << endl;
    return 0;
}

結果
C:\Projects\TestSolution\Debug>totalSum.exe
9223372034707292160
-2147483648

これを防ぐためには、「(n + 1) × (n ÷ 2)」とするのが、ひとつの方法です。しかし、n が奇数の場合、正しい結果が得られません（9223372032559808512になる）。整数と整数の除算は整数になり、0.5が捨てられるからです。n が奇数の場合は、「((n + 1) ÷ 2) × n」とします。


#include "stdafx.h"
#include <iostream>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
    __int64 max = 4294967295;
    __int64 sum = 0;
    for (__int64 i = 1; i <= max; ++i) {
        sum += i;
    }
    cout << sum << endl;
    cout << (max + 1) * max / 2 << endl;
    cout << ((max % 2 == 1) ? ((max + 1) / 2) * max
                                  : (max + 1) * (max / 2))
        << endl;
    return 0;
}

結果
C:\Projects\TestSolution\Debug>totalSum.exe
9223372034707292160
-2147483648
9223372034707292160

今回は固定の数字を求めましたが、ユーザーによる手入力の場合は、上限を超えるような数字ではないことを確認しておく必要があるかもしれません。