2013年12月22日日曜日

F#談話室(11) に関するメモ

2013年12月21日に開かれた F#談話室(11)  での談話内容に関する個人的メモです。

当勉強会に関するTwitter上の発言は、Togetterにまとめています

Twitter上の発言だけでは、当日の内容がわからない(自分自身思い出せない)ので、以下では、自分の備忘録も兼ねて、勉強会の内容をまとめ直しています。

秀丸でF#を実行するためのマクロ (自分の発表)

秀丸でF#を(即時)実行するためのマクロ を紹介させて頂きました。
このマクロは、秀丸エディタで書いた内容を(ファイル保存せず)に即実行し、その出力を秀丸エディタの出力ウィンドウに表示します。 @ohtorii さんの 秀丸でC#を実行するためのマクロをベースにしています。

マクロの内部動作は、
  1. エディタで編集中の内容を、一時ファイルに保存
  2. 一時ファイルを、fsc.exe (F#コンパイラ)でコンパイル
  3. コンパイルされたexeファイルを実行
  4. 実行時の標準出力を受け取って、
    秀丸エディタの出力ウィンドウに表示
という感じです。
F#勉強会のネタ用に即席で作ってみました。
2. -> 3.の処理の流れが上手くいかず、
マクロのコード上ではコンパイルの終了を待っている(同期実行している)にもかかわらず、実行ファイルが吐き出される前に、exeファイルを実行しようとしてこける。
という問題があったので、2.の後、ウェイト命令の代わりにメッセージダイアログを表示しています。秀丸マクロの命令をよく知らないので、こんな仕様になっています。(本当にひどい)

なんか冷静になって今考えると色々と酷いのですが、@NyaRuRuさんからは、問題の原因を調べるにあたり、MS純正のProccess Monitorがいいんじゃない的なコメントを頂きました。

ProcessMonitorは、プロセスやスレッド単位で、その動作状況、通信状況を調べられるツールです。フィルタリング(特定の条件を満たすプロセス、スレッドのみ表示)や、ログの記録も出来るので、複数のプログラムに渡るシステムのデバッグにはかなり良さそうです。

L2キャッシュの偽共有問題について (自分の発表)

F#と全然関係なく、実行効率100%でマルチコアを回そうとすると、実行時のL2キャッシュの取り扱われ方を意識した方がいいことが稀にあるかもね的な話をしてみました。

「俺のAthlon64X2が(先輩のCore2に比べて)こんな遅いわけがない!」みたいな動機で、CPUの内部アーキテクチャ(コアごとにL2キャッシュが存在する場合)を考えながら、C#2.0のコードを細工したら、最終的に実行効率100%で並列実行できましたという結果論なので、正しいことを言っているのかは確信できず…、こんな感じで考えたのですがどうでしょうと質問してみたところ、案の定、色々と突っ込みを頂きました^^;

@NyaRuRuさんからは、「それ、intelのVTuneで解析しましょう」というアドバイスを頂きました。

補足すると、サーバ向けのCPU(intelのXeon、AMDのOpteron) では、L2キャッシュの偽共有問題(スヌーピングによる問題)を解決するための対策がとられているため、ユーザーレベルで対策を打つ必要はなさそうです。

現在のコンシューマ向けのCPUがどうなっているのかはよく分かりません。が、最近のCPUはSharedのL2キャッシュになっており、そもそも偽共有問題は発生しないので、気にする必要はありません。

はぇ~(@haxe)さんとの雑談

第1回paizaハッカソンの最速コードについて。
上記記事のC#コードは、アルゴリズム的な点では特段何も無くて、『Consoleからの読み取りを如何に早くするか』だけだった。
調べてみて実行環境がx86とわかった時点で、やりたい放題できるよね的な話とか。

@kos59125 さんの発表

乱数モナドの話
すみません。わかりません。。。

@teramonagiさん

関数型言語による金融商品契約の OSS 実装ってないのかな、という質問
F# Deep Dives がPreOrderだけど良いというメンバーからの紹介あり。
一部無料で読める。

F#で数式処理したい、という質問。
MathmaticaのMathLink使ったらどうでしょうというメンバーからの提案

@omanuke さんの発表

このあたりの話、F#でもWPF書けるよというデモ。

@atsushieno さんの話

XamarinStudio買うなら、国内代理店を介して買うのがいいという話。
サポートがすごく手厚いそうです。

@NyaRuRu さんの話

検索会社のバックエンドについて。
MapReduceを多段構成(パイプライン)にすると効率が悪く、その解決策のため現在はFlumeJavaって中間層があるよっていう話がありました。ものすごく雑に要約すると、プリミティブな部分は糞でも、適切な中間パーサがいれば大丈夫、という感じのようです。

実は、Go言語は、社内における『現代的な言語につかれた人たち(BASICで育った人たちなど)』に人気。