<<前の10件

2012-1-1[日]

あけましておめでとうございます。
厄明け初っ端のおみくじで大吉引いて幸先いい気分です ……ええ気分だけでなんの根拠にもなりませんが、 今年は少しは積極的に動きたいところ(本業)。




2011-11-30[水]

とりあえず11末までの現場が終了で飲み会あれど断ってそうそうに引き上げてしまったのは立場的にあまりよろしくないのだけど久しぶりの戸川純ライブを我慢出来ませんでした。なかなか大阪までは来ないものなのでこの機会を逃すと次また何年後かもしれず……ああダメ人間。良い現場だったので後ろ髪ひかれ会場ついてもくよくよでしたが。でも、気持よく通る歌声を聞けば現金なもので、今、これだけ出てる歌声を(生で)聞ける幸せを堪能。メンツ的にかyapoos系の曲が多く歌い方も(彼が殴るの や トルエンズのテーマも なんか素直?な印象なような)。お客さんは当然順当に年を重ねた層も多いですが、思いの外若い人いて、ざっとまんべんなく20〜50代がいた感じ。ちょっと安心した気分です。





2011-11-11[金] C++11 を忘れたい、3年くらい

ポッキーの日、と言われてすぐになんのことか思え出せなかった虚け者です...いや、覚えていなくてもいいと思うけれど おすそ分けのポッキー食べたんだからちょっとくらいは覚えておこう>己。で連鎖的に C++11 を思い出す、けど、まともな処理系がでてくる2,3年後までは知らずにすませていたかったというか忘れたい。今 C++ 03 で(ライブラリを)作るものにとっては非常に目の毒です。(と、ま、ただの生存証明)




2011-5-27[金]

とりあえず毎年のカウントアップ。かろうじて生きてます.





2011-1-6[木] stlport.org

ひさしぶりに www.stlport.org を見に行ったら消失していて焦ってしまう。 といっても sorceforge にも頁があるので…

というより http://stlport.sourceforge.net/Home.shtml が公式ということか? 左サイドのメニューをちゃんと認識していなかった。 いまさらながらhistoryFAQを見てなんとなく納得。 (放置してた旧サイトのドメインが消失したってだけのことでいいのかな)

あと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 時ほどではないのだろうけれど)


それと 以前 気になっていた type_traits の ライセンスの "Academic Free License ("AFL") v. 3.0" はやめたようで、(STLport共通の)緩いライセンスに変わった模様。type_traitsだけでなく他のファイルでも "AFL v.3.0" のものは無くなっていた。(以前 そのライセンスの.makファイルのあった buildフォルダごと無くなっている:)

ライセンスについては LICENSE ファイルが同梱されているので、それを確認、と。

[1/8追記] どうも http://stlport.com/ がある模様。消失じゃなくて移転ということなのか?
[5/22追記] 単に一時的に失効してただけみたいでstlport.orgも復活している模様




2011-1-1[土]

あけましておめでとうございます。今年もよろしく。

去年は人生の節目のようなことがあった反面、 総じてグダグダな一年だったので来年はもっと頑張る予定。 いや今年はも少し頑張るです(数え年は気になる)


といったところであいかわらずgdgdだけど、年末に自宅PCを win7(64)に移行した。 vista64 のwindows updateでエラー80070024が出て更新できなくなり、 ググって見つかる試せる解法はすべてダメであとはMSにメールするしかないパターンのようなので…いっそ更地インストール。 動作環境を残しての移行なので、PC崩壊からの移行にくらべれば楽ではあるけれど、時間は掛かるし動作環境復元できないものもやっぱりあるので、毎度のことながら消耗はげしい。

また、そこそこ環境整い、さて年賀状印刷しようとしたら、今度はプリンタ(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)

コンパイラBilinear 拡大(ミリ秒)安易 インタプリタ(秒)quick sort(μ秒)QSORT(μ秒)Dhrystone/secWhetstone (MWIPS)
llcでasm→exe105.827.61987135860(25056376)1525.463
lliで実行 103.626.01749939343(26184864)1530.688

大筋 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にしたテストの1つ目。 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 を生成。
なのだが、このまま別の(複数の)コンパイラでコンパイルしてみると __imp__iobやQueryPerformanceCounter等が未定義参照だと リンカに怒られる。 __imp__iob は stderr の本体(を収めた配列名)、 QueryPerfomance…は時間取得につかってるWin-APIのもの。

ヘッダ込みでコンパイルされた結果を C化してるのだから、 
llvm-gcc でコンパイルする場合のヘッダ/ライブラリと、
ターゲット・コンパイラでのヘッダ/ライブラリが同じ(矛盾しない)
でないと当然マズいのだった。

とりあえずstderrやwin-apiを使わないようにして(外部はC標準関数だけにして)回避。
ソースは、 これこれ
それを llc で変換した後のソースは、 これ

ついでに 一旦 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()だけになっている。


2つの変換後のソースは、だいたい他のコンパイラでもコンパイル可能。
(ダミーの alloca.h の読み込みを用意したり、 dmc では bool のtypedefが衝突するのでダミー alloca.h 内で誤魔化したり する必要はあった) (このとき使ったllvmは rev.98686 )

が失敗したモノもあり、
vc64に関しては、ハング(作られたソースが32ビットcpu専用のソースかも?)。
bcc 5.5.1 は宣言に型が多すぎる、と怒ってくれてコンパイルできず (bcc 5.8.2は可)。
clang は型チェック関係でひっかかるので挫折。
mingw440 は、前者の変換ソースのものを実行するとハング。
pcc では、後者の変換ソースでは、DEP チェックにひっかかりハング。

実行できたものについての結果は以下 (単位:ミリ秒)

コンパイラ 元の結果前者の変換での結果後者の変換での結果
vc9sp1 197153162
cygwin gcc344 256238237
mingw gcc345 255239237
mingw gcc440 269---255
LLVM-gcc42(SSE?使用) 103109104
open watcom(1.9rc1) 397327317
dmc(8.51) 352301317
pcc 323308---
coins 493334317
PellesC 408353350
TinyCC 449397396

測定したタイミングによっては10,20ぐらいの差がでたりするかもで、 ざっくりとした感じに受け止めてもらうとして。

LLVMのツールであるllvm-gccではあまり差はないようだが、 他のコンパイラでの結果は、多少なりとも llc で変換したソースのほうが速くなってる雰囲気。

ただ前者と後者の変換については、モノによって多少違うも、 測定誤差でありえる範囲の差で、あまり違いはなさそうに思う (関数の分割具合の違いによるオプティマイズの トレードオフはあるだろうで、それが微妙に出てる可能性もあるけれど)

他のソースも試すべきたんだろうが、面倒で挫折... 他の例でも速くなるのか遅くなるのかどうかは結局ソースしだいと思うが、 それでも元のソースよりも速くなる例ができたわけだから (元ソースがヘボいのだろう、というのは置いといて)、 他の例でもそう酷く遅くなるようなことはないんじゃないかと期待.

※'元の結果'は3/12の結果と比べて少しずれてる。やってることはほぼ同じだけれどソース的には多少(時間取得関数だけでなくclang測定対策等)違うせいか、測定誤差といいきれない差のものがある. 前回のexeを実行すればやはり前回と同様の値なので、ソース変更の影響のよう。今回は今回、ということで。

zip


C++ → C

で、 肝心の c++ → c .
C++標準ライブラリの使用については、 実体がすべてヘッダでの定義ですんでいるようなモノ(std::sortとか)を使う分には、 (実体がライブラリ(アーカイブ .libや.a)化されているものを使わない範囲では)、 変換ソースを他のCコンパイラでもコンパイル&実行できる(た)。

が、g++(clang)側のライブラリ(.a)に実体がある関数や機能を使った場合は、 コンパイルできても当然リンクが行えない状態。 bad_alloc みたいなライブラリものもそうだけれど、 virtual使ったり 例外を使った場合もそう。その他諸々。 C++らしい組み方をしてるとまずその手のものは使われてるだろうで...

足りてないリンク物の代用品をターゲット環境用にも用意できれば なんとかなるかもだが、大仕事だろう。(あるいはターゲット対応をllcに施すとか... どちらにしろ個人がチョロですむ作業ではなく)

I/Oを含まずtemplateを使ったような処理をベターCの範囲で書いてCに持ってくる、くらいなら...と思うも、やっぱ面倒だなあ.


あと、llc は c だけじゃなく c++ ソースも生成できる。
計測に使ったソースを後者の変換をしてみたものが これ

なんかすごい、というか、目が点になる、というか。
効率どうこう以前に趣旨が違うもののような気もする。
(パッと見でincludeフォルダ設定を追加してコンパイルを 試しみたけど、どれも上手くいかず。あまり追及する気にもなれず)


※と、まあ、発展途上のllvmを使っての感想なんで今後どうなっていくか、わからないけれど

他のC++ → C トランスレータ

ついでのメモ。

元祖のC++実装の cfront は、Cソースへのトランスレータとして実装されている。 例外が実装されずに開発は終わっているが、 こちら でR3.0.3等いくつかのバージョンのソースが公開されている模様。 (使えるかどうかはしらない)

現行のC++をサポートしているだろうトランスレータとしては Comeau C/C++。 有料だけど低価格($50)。 面倒がって未購入だけど。 他環境向けのCソース生成ならこちらのほうがよい?(夢見てるかも)... といっても、ターゲット環境ごとの個別対応は必要だろうで、 Comeauのサイトで対応と書かれているのは比較的メジャーな環境のみのよう。





2010-3-18[木]

小川一水『天冥の標II』読了。Iの直続きでなく、 打って変わって現代に近い未来での伝染病話。 鼻が効かず(むずむず)涙が出る(かゆい)状態で 読むのはなんともいえません(花粉症)。 これだけの単品のように楽しめて 直に続きそうにないIIIタイトルへの"続く"に歯がゆくで。 巻ごとに趣向がかわるんでしょうか。 大きな雰囲気に一気に期待が高まってしまいます。





<<前の10件