|
2012-1-1[日]
あけましておめでとうございます。
2011-11-30[水]とりあえず11末までの現場が終了で飲み会あれど断ってそうそうに引き上げてしまったのは立場的にあまりよろしくないのだけど久しぶりの戸川純ライブを我慢出来ませんでした。なかなか大阪までは来ないものなのでこの機会を逃すと次また何年後かもしれず……ああダメ人間。良い現場だったので後ろ髪ひかれ会場ついてもくよくよでしたが。でも、気持よく通る歌声を聞けば現金なもので、今、これだけ出てる歌声を(生で)聞ける幸せを堪能。メンツ的にかyapoos系の曲が多く歌い方も（彼が殴るの や トルエンズのテーマも なんか素直?な印象なような）。お客さんは当然順当に年を重ねた層も多いですが、思いの外若い人いて、ざっとまんべんなく20〜50代がいた感じ。ちょっと安心した気分です。
2011-11-11[金] C++11 を忘れたい、３年くらい
ポッキーの日、と言われてすぐになんのことか思え出せなかった虚け者です...いや、覚えていなくてもいいと思うけれど おすそ分けのポッキー食べたんだからちょっとくらいは覚えておこう＞己。で連鎖的に C++11 を思い出す、けど、まともな処理系がでてくる2,3年後までは知らずにすませていたかったというか忘れたい。今 C++ 03 で(ライブラリを)作るものにとっては非常に目の毒です。（と、ま、ただの生存証明）
2011-5-27[金]とりあえず毎年のカウントアップ。かろうじて生きてます.
2011-1-6[木] stlport.orgひさしぶりに www.stlport.org を見に行ったら消失していて焦ってしまう。 といっても sorceforge にも頁があるので… というより http://stlport.sourceforge.net/Home.shtml が公式ということか? 左サイドのメニューをちゃんと認識していなかった。 いまさらながらhistoryやFAQを見てなんとなく納得。 （放置してた旧サイトのドメインが消失したってだけのことでいいのかな） あとFAQみて4.6系はいまいちな状態でv4の最後の綺麗な版が4.5.3だったことを知る。dmc用公式 stlport が4.5.3どまりなのはそのへんもあるのかと連想。 現在の最終の公式リリースは 5.2.1(2008) のままだけど、開発版のソースをみると、メジャーバージョン(#define)は 6 になっていた（6に向けての開発中) C++0xを考慮してるし、あまりに古い仕様のコンパイラは対象外にしていってるよう。 さすがに、メンバー関数テンプレートのサポートは必須扱い、stdint.hも利用してるしで、互換のためにごちゃごちゃしていた記述が省かれたり単純になったりですっきりしてきている。（v4→v5 時ほどではないのだろうけれど）
ライセンスについては LICENSE ファイルが同梱されているので、それを確認、と。
[1/8追記] どうも http://stlport.com/ がある模様。消失じゃなくて移転ということなのか?
2011-1-1[土]あけましておめでとうございます。今年もよろしく。 去年は人生の節目のようなことがあった反面、 総じてグダグダな一年だったので来年はもっと頑張る予定。 いや今年はも少し頑張るです（数え年は気になる）
また、そこそこ環境整い、さて年賀状印刷しようとしたら、今度はプリンタ(Canon MP640)がエラー6C10 で動作できず。検索でみつかるモノを見ると、基本、メーカー修理するしかなさそうだ。年末年始修理受け付けてないようなので後日。しかしまだ半年経ってなくてあまり使ってないのに…いやプリンタは使用頻度が低すぎるのがまずいのだろうけど。ああ6C10で引っかかる頁はMP640以外もあるのでCanonの機種はエラーコードを継続しているのだなあ、と当たり前といえばそうだけれど妙に感心してしまった。
2010-3-31[水] 科学館によってみた.油断したころに同じ過ちをしてしまうもので、 日曜に右足を少し捻り古傷直撃で激痛, 3,4年前の再発...とはならず、 幸いたいしたことはなさそうで 痛みは（微妙に残ってるけど大方） 引いて一安心。気をつけて生きねば （自主リハビリしろ、だ） そんな中、所用で梅田行ったついでに、 大阪市立科学館によってみた。 長年、その近所で働いていたのに 一度も入ったことなかったので（隣の美術館はあるのだけど）、 暇してる今のうちに、と... というかプラネタリウムホールでの上映目当て。 どうもIMAXでアバターみたときの微妙な 物足りなさ/不満が燻ってしまっていたようで、 ドームいっぱいに描かれる映像は気持ちよかったです。 3D作品ではないけれど、それに近い気分が味わえて。 はやぶさのナレーションは科学番組的であってくれたほうが よかったけれど（語りはちょっとしんどい）、 映像はまあまあよく。 はやぶさのサイズを知っていないと スケールがわからないのはちょっとつらいけれど。 （3D映像に関しては、全編、同一スケール（できれば1/1スケール）の 作品が見てみたい、って気が強くなる。 1/1を維持したまま舞台劇のような感じのモノを カメラ位置だけ変えて写したものを見てみたく）。 プラネタリウムは、解説たのしかったけれど、 も少し星空をじっくりみてみたかったという気もあり。 あと、展示されてた隕石は触れてよかった。 茶色いし隕石という名についつい石や岩を思ってしまってたけれど 金属(鉄)の塊だった。茶色いのは錆で ところどころ擦れ跡から金属の輝きあり。 （ギベオン隕石でググるといっぱいひっかかる代物のよう。あやしげな売り口上も多そうだ）
[コメント]
2010-3-21[日] LLVM lli での実行そういや LLVM の VM(lli) ってどれくらいなんだろうか、とちょっと気になったので 3/12のを lli で実行してみた。 llvm-gccでコンパイルして、 llc で生成したネイティブアセンブラソースからexeを作ったもの、と、 lli で実行したもの。 llcからのexe結果は不精して、前回のからコピペ。 今回試した lli はそのときより数日新しいllvmになっていたり 多少測定環境がぶれていたりするけれど、おおざっぱな雰囲気をみる分には...で。 （ソース&exe)
大筋 lliの実行結果は llc でネイティブアセンブラ生成した場合と同様の結果のよう… 仕組みからすれば、lliのほうは測定範囲外の部分で余分に時間かかってる (実行時コンパイルしてる)だろうが、 .bcサイズに対する今時の実行環境のパワーを思えば たいしてペナルティがあるわけでなく、ってとこ、か? （ ロード時に一括コンパイルしているのかな？） ネイティブ実行以外興味なくて、最初にちょろっと試しただけで、以外に速いかも なんて思ってたのだけど、以外に、どころじゃ、なかった。 LLVM関係の記事(appleのopenglな件とか)に書かれていることを思い返せば、 こういうことなんだろうけど、実感してなかった、というか、わかってなかったことを実感です。
2010-3-20[土] LLVMで Cに変換してみるLLVM (llc) には Cソースコードを生成する機能があり、 C++ソースをCソースにすることができる模様。 ただし C++ から C への直接変換するのではなく、 一旦.ll/.bc(llvm用アセンブラソース,ビットコード)にしたものを、 llc.exe で（ターゲットCPU用アセンブラソースのかわりに） Cソースへ変換するというもの。 普通のアセンブラソースをCに変換した場合 オーバーヘッドは当然あり、 全体として問題になることはそうないかもだが (昔アセンブラソースからCに変換しての移植作業を何本かやったときの印象)、 何割(何倍)か遅くなっていてもおかしくない。 が llvmの .ll/.bc は、 普通のアセンブラソース/オブジェファイルでなく、 それより情報の多い中間コードなわけだし、 llvm-gcc & llc でオプティマイズしているため、 Cソースになっても元よりも速くなる可能性もありそう。 ということで、ちょっと、試してみた。 3/12にしたテストの１つ目。 C++でなく Cソースだけど。 (32bit色640x480→1920x1080拡大の50回生成の平均時間を求める奴. 実行環境は前回同様) llvm-gcc で llvm-gcc -S -o tmp.ll -emit-llvm -O2 -DNDEBUG test.c llvm-as -f -o tmp.bc tmp.ll llc -march=c -f -o test_dst.c tmp.bc
として test_dst.c を生成。
ヘッダ込みでコンパイルされた結果を C化してるのだから、
とりあえずstderrやwin-apiを使わないようにして(外部はC標準関数だけにして)回避。 ついでに 一旦 ldでまとめたものを.llに戻してから llc したものも試す。 llvm-gcc -S -o tmp.ll -emit-llvm -O2 -DNDEBUG test.c llvm-as -f -o tmp.ll.bc tmp.ll llvm-ld -o tmp.ll.exe tmp.ll.bc llvm-dis -f -o tmp.2.ll tmp.ll.exe.bc llvm-as -f -o tmp.2.bc tmp.2.ll llc -march=c -f -o test_dst.c tmp.2.bc 変換後のソースは、 これ。 前者の変換後ソースには元の関数を維持しているが、 後者の変換後ソースでは関数はmain()だけになっている。
が失敗したモノもあり、 実行できたものについての結果は以下 (単位：ミリ秒）
測定したタイミングによっては10,20ぐらいの差がでたりするかもで、 ざっくりとした感じに受け止めてもらうとして。 LLVMのツールであるllvm-gccではあまり差はないようだが、 他のコンパイラでの結果は、多少なりとも llc で変換したソースのほうが速くなってる雰囲気。 ただ前者と後者の変換については、モノによって多少違うも、 測定誤差でありえる範囲の差で、あまり違いはなさそうに思う （関数の分割具合の違いによるオプティマイズの トレードオフはあるだろうで、それが微妙に出てる可能性もあるけれど) 他のソースも試すべきたんだろうが、面倒で挫折... 他の例でも速くなるのか遅くなるのかどうかは結局ソースしだいと思うが、 それでも元のソースよりも速くなる例ができたわけだから （元ソースがヘボいのだろう、というのは置いといて）、 他の例でもそう酷く遅くなるようなことはないんじゃないかと期待.
C++ → C
で、 肝心の c++ → c . が、g++(clang)側のライブラリ(.a)に実体がある関数や機能を使った場合は、 コンパイルできても当然リンクが行えない状態。 bad_alloc みたいなライブラリものもそうだけれど、 virtual使ったり 例外を使った場合もそう。その他諸々。 C++らしい組み方をしてるとまずその手のものは使われてるだろうで... 足りてないリンク物の代用品をターゲット環境用にも用意できれば なんとかなるかもだが、大仕事だろう。(あるいはターゲット対応をllcに施すとか... どちらにしろ個人がチョロですむ作業ではなく）
I/Oを含まずtemplateを使ったような処理をベターCの範囲で書いてCに持ってくる、くらいなら...と思うも、やっぱ面倒だなあ.
あと、llc は c だけじゃなく c++ ソースも生成できる。
なんかすごい、というか、目が点になる、というか。
※と、まあ、発展途上のllvmを使っての感想なんで今後どうなっていくか、わからないけれど
他のC++ → C トランスレータついでのメモ。 元祖のC++実装の cfront は、Cソースへのトランスレータとして実装されている。 例外が実装されずに開発は終わっているが、 こちら でR3.0.3等いくつかのバージョンのソースが公開されている模様。 （使えるかどうかはしらない） 現行のC++をサポートしているだろうトランスレータとしては Comeau C/C++。 有料だけど低価格($50)。 面倒がって未購入だけど。 他環境向けのCソース生成ならこちらのほうがよい?(夢見てるかも)... といっても、ターゲット環境ごとの個別対応は必要だろうで、 Comeauのサイトで対応と書かれているのは比較的メジャーな環境のみのよう。
2010-3-18[木]小川一水『天冥の標II』読了。Iの直続きでなく、 打って変わって現代に近い未来での伝染病話。 鼻が効かず(むずむず)涙が出る(かゆい)状態で 読むのはなんともいえません(花粉症)。 これだけの単品のように楽しめて 直に続きそうにないIIIタイトルへの"続く"に歯がゆくで。 巻ごとに趣向がかわるんでしょうか。 大きな雰囲気に一気に期待が高まってしまいます。
|