<<前の10件

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タイトルへの"続く"に歯がゆくで。 巻ごとに趣向がかわるんでしょうか。 大きな雰囲気に一気に期待が高まってしまいます。





2010-3-15[月] watcom,dmcのテンプレート不具合

open watcom 1.9rc1 が出ている模様. が c++ 関係はあまり進展していないのか、 1.8よりちょっとは増えたようだけれどまだ未実装のSTL関係は多そうで (stable_sortなかったり)、 クラステンプレートのメンバー関数テンプレートをクラス外に書くのも まだ未サポートのよう.

template<typename T>
class Bar {
public:
    template<typename U> void test(T* t, U bgn, U end);
};

template<typename T>
template<typename U>    // この行.
void Bar<T>::test(T* dst, U start, U last) {
    while (start != last) *dst++ = *start++;
}

のBar<T>::testの2つ目のtemplateでシンタックスエラー.

template<typename T >
class Foo {
public:
    template<typename U> void test(T* t, U bgn, U end) {
        while (bgn != end) *t++ = *bgn++;
    }
};

のようにクラス内に書くのはok.

ついでに、上記は dmd(8.51) でもコンパイルエラー(startが未定義)になる。 こっちは、 テンプレートな引数の名前が Bar::test()宣言と定義で違うのが気に入らないらしい。 定義側の引数 start, last を bgn, end に修正すれば ok。 (テンプレートでない引数は名前が宣言と定義で違っても無問題)

別のコンパイラ(bcc 5.? だったか)でも、

template<typename CharT, class Traits>
class Foo {

のようにクラス定義してメンバー関数を外に

template<typename C, class T>
void Foo<C,T>::hoge(…) {

みたいにテンプレート引数名を変えていたら 某かの不具合がでた覚えがあり(名前を統一したらok)

汎用性を思うならば(古いコンパイラ気にするなら)、 クラステンプレートのメンバー(関数)は、 下手にクラス定義から分離せずに、内部に書いてしまうほうが 余計なバグに出会わずに済むのかも。 (分離する場合は名前を揃える... てか、ひょっとして普通揃えないとダメなのかな?)

(ごちゃごちゃする定義はクラス外部に追い出して、 クラス宣言は身軽にしておこう、 なんて考えてたらドツボにハマることもあった、と)






2010-3-14[日] winの LLVM-Clang でコンパイル.

Clangで、なんとか、コンパイルできた。 (前日冒頭のつづき)
単純なhello.cで#include <stdio.h>だけなら、実はそのまま出来てた。 ただ、3/12のテストルーチンをコンパイルするとヘッダ関係でいろいろ不具合出た。

コンパイル出来た llvm,Clang のソースは llvm rev.98447、clang rev.98448のもの(結構頻繁に更新されてるよう)で、vs2008sp1 にて release の ALL_BUILD して生成.

まず、_WIN32等が設定されてたのは まさに Clangのソース内で設定されていた。 win環境なら _WIN32 定義してて、また、VC環境だと VCのinclude等のパス設定するような処理があった. (VCでコンパイルしたから呼ばれるのかVCがinstall済みだからよばれるのかは よくわかってないけど). でもってmingw関係も定義されてる雰囲気だった(mingwやgccを詐称してるよう).

VC関係は邪魔なので -nostdinc 指定してデフォルトのincludeパスを見に行かないようにし、 引数で llvm-gcc-4.2 の環境を流用して設定するようにした。 (別に llvmのでなく普通の(最近のバージョンの)mingwの環境でも大丈夫そう)
だいたい

clang.exe -nostdinc -Dwint_t=wchar_t -D__declspec=__declspec -Ix:/llvm/bin/lib/clang/1.1/include -Ix:/llvm-gcc-4.2/include -Ix:/llvm-gcc-4.2/lib/gcc/i386-mingw32/4.2.1/include -O2 -o test.exe test.c

といった感じにコンパイル. +こまごま修正.

  • windows.h を受け付けてくれるが wint_t が未設定だったみたいで -Dwint_t=wchar_t で誤魔化した.
  • time.hをincludeしたときは、__MINGW_IMPORTが未定義扱いだったので -D__declspec=__declspec を定義して誤魔化した.
  • inline関数だった箇所がリンク時に未定義だって怒られたので、static inline に修正した(C++じゃなくてCなんだから static inline じゃないとマズイのだろうな).
  • ctype.h をincludeしたら_imp____mb_cur_max_dll等で怒られ、とりえあず ctype.h を使わないようにして逃げた.

ヘマして何か設定が足りてないだけかもしれないが、まだ、ちょっと面倒な状況かも、で。

テストの実行結果は以下の通り。 (最適化オプションは-O2にしたけど妥当かどうかは未考慮)

コンパイラBilinear 拡大(ミリ秒)安易 インタプリタ(秒)quick sort(μ秒)QSORT(μ秒)Dhrystone/secWhetstone (MWIPS)
LLVM-clang 199.927.91522567820128419161478.956

他の結果はこっちみて...
結構いい感じ。 このテストだと、VCの次くらい …gccよりよかったり悪かったりがあるので、類似物じゃないよな。 (安易インタプリタはctype.h関係を手書きマクロに置き換えたので若干条件違うことになるが→結局、他も計測しなおした)

LLVM-gcc は、dmc に対する gdc のようなものに思ってたのだけれど、どうも、測定結果を思い直すと(llvm用コードでなく)ネイティブコード生成時はただのgcc(4.2)なのかも。

追記: やっぱりマ抜けていた。--emit-llvm を指定しないとただのgccかも. --emit-llvm でllvmなコードを一旦はいてからx86向けを作る、みたい. (コンパイル手順はこっちに, 結果はこっちに追記)

で、clang も -emit-llvm 付で生成すれば同様にさらにオプティマイズできるよう。
ただ、手もとの環境で作ると、生成した.exeはハングするので、ちと残念な状態。 (ハングする前に計測結果のでたモノをみるかぎり llvm-gccと同様に早くなってた)
4/23追記: 最近のclang(1.5 trunk 102038)で試したら修正されてるようで動作。(試したのはbilinearのだけだが、さらに速く(97)なっている感じ)





2010-3-13[土] win標準と衝突するunix系コマンド.

こちらでclangのvcでのコンパイルを紹介されてたので、やってみた。出来たコンパイラを使うとincludeでvc側の ヘッダ読み込まれてエラー。 _WIN32が定義されてるし、何か、しなきゃいけない (環境)設定が抜けてるんだろうなあ。 (includeしてないソースのコンパイルでexeやasmはつくれてた)

で、そのとき、こちらの GnuWin32 をインストール.

cygwinやmsys同様 unix系フォルダ構成を持つ状態のコマンドラインツール群で、 dllや言語ファイルがあるので単体コマンドを流用したい身には一長一短だけど、 コンパイラやスクリプト言語等は含まれていないので、ある意味、身軽で、 通常(常用)の環境変数PATHの最後にGnuWin32/binを追加して使うのでも よいように思えてきた。

unix系ツールと win(dos)標準コマンド名でいくつか衝突するけど、Windows/System32/*.exeとgnuwin32/bin/*.exeを比べると

calc.exe 電卓だが、gnuのはコンソール、WinのはGUIアプリ.
expand.exe 圧縮データの解凍、だが、対象とするデータ形式は(たぶん)違ったはずだし、 引数オプションも違う.
find.exe gnuのは ファイル検索、Winのは テキスト中の文字列検索.
sort.exe ともにテキストのソートだが、オプション引数は違う.
whoami.exe ともにユーザー名表示だが、表示形式が若干違い、gnuのは ユーザー名だけだが、winのは コンピュータ名\ユーザー名 となっている. オプションも違う.

ぐらいか。
まあ、これらが関係ない状況で使う分には大丈夫かな、と。

当然他のパスも通るので衝突がありえるけど. (コンパイラ関係だと link.exe とか)
cmd.exeの内蔵のecho,mkdirも衝突するが内蔵コマンドゆえwin側としては問題なし. unix系ベースで考えるときは問題あるだろうけど、そういうときは cygwin,msysあたりをつかっているだろう、で.


※と書いたが、別に GnuWin32 でなくmsys でもほぼ同様かもだけど... (cygwinはともかく msys+mingw環境も特殊性があるのかどうか)





2010-3-12[金] ちょっと速度比較

前回触った LLVM-gccやpcc,coins (で作ったプログラム)の速度が気になったので、 手持ちのCコンパイラ(vc意外はフリーのもの)で適当に実行速度を計ってみた。

(3/14修正: cygwinの計測が間違って別のmingwでの結果になってました).
(3/15修正: llvm-gccは生成方法を間違えていたためやり直しました. また他と比較しずらいので clangの結果も含めました)

試したコンパイラは全てwin環境用で

コンパイラ 生成にかかわるオプション補足
vc9sp1 64bit -GR- -Ox -DNDEBUG -MT
vc9sp1 32bit -GR- -Ox -DNDEBUG -MT
cygwin gcc 3.4.4 -O2 -DNDEBUG bashでなくcmd.exe上で実行.
mingw32 gcc 3.4.5-O2 -DNDEBUG
mingw32 gcc 4.4.0-O2 -DNDEBUG
LLVM-gcc 2.6 -O2 -DNDEBUG -emit-llvm 実際には一度に作れず複数工程になる
clang -O2 -DNDEBUG -emit-llvmせずで、おそらくclang単体での生成
Open Watcom 1.8 -Ot -O3 -DNDEBUG -finline-functions
-frerun-optimizer -floop-optimize
-funroll-loops -finline-math
dmc 8.51 -o -DNDEBUG
pcc-20090818-win32-O3 -DNDEBUG
COINS 1.4.4.3-en -O2 -DNDEBUG bashでなくcmd.exe上で実行
BorlandC 5.5.1 -O2 -Ox -RT- -d -dc -DNDEBUG
PellesC 6.00.6 /Zx /Ze /Ox -DNDEBUG
TinyCC 0.9.25 -DNDEBUG オプティマイズは無い

正直、オプションが、どの適度適切かは不明。 Watcomはつけすぎてるけど、基本はデフォルトに近い状態。
浮動小数点関係は、設定しだいで結構違うだろうけど不精してせず(watcom以外)。

試したテストプログラム

バイリニアによる画像拡大 乱数で生成したピクセルで埋め尽くされた640x480の32ビット色(ARGB)画像を1920x1080へ拡大する処理。10回の平均値。
安易インタプリタでのスクリプト実行 400行ほどのおもちゃのインタプリタ言語で、 5000*5000ループの適当なサンプル実行. (仕組みが手抜すぎて実際的な比較向けではなかったかも)
クィックソート 以前試したCでかかれたQUICKソートと、Cライブラリのqsort互換のクィックソートルーチン のテスト.
とりあえず、この頁の結果には int 1000000個をソートしたときの時間を記入.
Dhrystone 2.1 整数演算用ベンチマーク. Wikipedia等みて. モノは、こちらの記事から リンクされているモノを使用. ソースは2.1のモノだけ使用(コンパイル楽なため). けど、Old-Cスタイルでエラーだすコンパイラ対策でANSI-Cスタイルに修正したり ヘッダ依存関係調整したり. 使用時はループ回数を100000000回にして実行.
Whetstone 浮動少数点演算用ベンチマーク. wikipedia等みて. こちらのサイトの BenchNT.zip に入っていたソースを利用. こちらもコンパイラごとの調整のための修正あり.

download:上記のソースのzip

たくさんやるのも面倒なので、これだけ(これだけでも結構しんどく)。 自分が大雑把に雰囲気をつかむため、なので、あまり適切でないサンプルかも。 1core 1threadな簡易な処理だけだし。 Dhrystone,Whetstoneは一応してみたけど、あまりピンときていない (処理内容わかってないからだろうけど).


実行環境は vista64(PhenomIIx4 3G)、通常のデスクトップでDOS窓とエディタ程度だが、サービスや常駐モノはある程度残った状態で実行.(テスト中の 1core がフル稼働で、あとの処理は他のcoreが大筋まかなってるだろうと期待. 以前別の計測にてsafemodeで起動して計測したほうが安定していた感じはあったけれど、酷すぎるほどの差もなかったので楽してる)

実行結果 は (3/14 一部計測し直し. cygwin計測ミス、安易インタプリタのclang対処反映)

コンパイラBilinear 拡大(ミリ秒)安易 インタプリタ(秒)quick sort(μ秒)QSORT(μ秒)Dhrystone/secWhetstone (MWIPS)
vc9sp1 64 87.525.21443939856142146413465.753
vc9sp1 32 189.224.71445269039115300362284.091
cygwin 344262.020.22030060900102082482108.046
mingw 345 245.025.4191666155698931541456.068
mingw 440 265.025.31911885483102732691554.432
LLVM-gcc(sse2)105.827.61987135860(25056376)1525.463
clang 199.927.91522567820128419161478.956
watcom 387.326.42822242918111869342199.402
dmc 371.925.1212246058090407741560.336
pcc 289.932.3194367962780334191176.030
COINS 384.128.0187006550059908941335.854
Bcc 5.5 582.239.41909259047101112231692.216
PellesC 429.330.4146966679473179651241.080
TinyCC 511.449.96621310585857544021063.352
(補足) ↓good↓good↓good↓good↑good↑good


たったこれだけだし、 測定(実行)環境はザルで実行毎の誤差からすれば 細かい数値みちゃうとまずいだろう。 特に浮動少数演算関係のオプション設定が適切でないだろうで 設定かえたら(Whetstoneとか)結果変わってきそうな気もする. (c標準ライブラリも計測範囲で使われてるので それの影響もどう据えるかにもよるし)。 が、おおざっぱに、vcが1番よさそうで次gcc系、 後は混戦で、ケツがTinyCCって感じか。
今回以外の例を思えば vcが抜きでてるとはいいきれないけれど. (Intel C/C++気になるけど懐的に手が出せないのでVCで満足しとく)

vc9sp1 64 の結果は CPUが64bit CPUなので、コンパイラの比較ってよりCPUの比較になるけど、 64ビットOS用にコンパイルするだけで、 結構違いがでる処理もある、という例になってるかも、で(代わり映えしない処理もあるけど)。

バイリニア拡大の結果は、 64ビット整数の利用頻度が少なかろうと 汎用レジスタが増えたことによるメリットが効いている例だろう (あとSSE2も関係あるか? 追記:というか、汎用レジスタどうこうでなく、 まさにSSE2になったことが効いているよう。 clangの結果がいいのも、SSE?なコードが生成されているためのよう (clangのほうはsseしてない) )。 32bitでもVCが結構速くなる例で、結構かたよった代物だろうけど... (この手の画像処理なんかは普通からすれば特殊な扱いになるのかも. 速度/ハードを気にしだすと生のCだけで済まさないだろうし)

感想としては llvm(-gcc)は(いろいろミスして勘違いしまくりだったけれど)ものによっては非常に速くなったりでびっくりで早く使い易くなってほしく、 Clangはllvmをしなくても(?)これだけの性能あっていろいろ期待、 PCC は速度は思ってたよりはいいかも、だけど(Win版は)思ったより安定してなさそう、 PellesC はそんなもんだろう、 TinyCC は実行時速度じゃなくてコンパイル速度優先で(-benchなんてオプションがあるくらいだし)スクリプト言語的にCソースを扱うような方向があるようなので 実行時速度はこの程度の差ならokなんだろう、 COINSは悪くないのだけど期待しすぎてたため (ひょっとするとあまりx86系向きじゃないのかもだけど) ちょっと哀しい気分、てとこか。

※追記:cygwin-gcc、測定ミスでやりなおしたけど、gcc3.4の範囲なのでたいして値はかわってない(でもWhetstoneは結構ちがうか。浮動小数点はオプション設定しだいだろうでデフォルトがいい状態だったのかも)。 もともとcygwin使ったCOINSの結果と比較するのにmingwのでいいか微妙な気もして追加したものなので(ただの計算だけだとそう違わないだろうけど). あと最初の4つのテストで cygwin-gccとCOINSは win-apiでなくtime.hを用いて計測しているため若干条件が違う、とも.

※追記:安易インタプリタの結果は、clang対策での修正前にくらべ、どれも4,5秒短くなっている. isalphaやtoupperを手抜きなマクロに置き換えただけだが、結構ライブラリのオーバーヘッドがあったということか. テーブル参照より単純比較のほうが速いのかスレッド関係やロケール対策がらみなのかはしらないけれど。

※追記: llvm-gcc のやり直しにおいて、Bilinear拡大は最適化されすぎて計算がなくなってしまったため、そうならないよう、若干ソースを修正(計測時間外での対処)した.
また、Dhrystone2.1の結果も最適化されるぎている可能性があるかも(大丈夫?).
(dhry_1.c dhry_2.c を1つのソースにした場合のvc64も結構はやかったので 全体最適化としてはありなのかも?)

※追記:llvm-gcc 同様に clangも -emit-llvm で生成すると速くなる模様 (例えばbilinear拡大のは 100.9 に). が、どうも何かミスっていて正常終了できないハングするexeが作られるためちゃんと試せていない.(追記:スタックフレームポインタを保持してるはずの ebp を退避せずに汎用レジスタ的に破壊して使うコードができてる模様) (4/23追記: 試したのはbilinearのだけだが、最近のclang(1.5 trunk 102038)で試したら修正されてるようで動作)


コンパイル不具合のメモ

  • pcc は #include で、#より前に空白が置かれていると、エラーになる場合があった.
  • 行頭に#を置けばok. #の後ろに空白が入るのはok.
  • pcc で、初期化していないグローバル or static 変数でハングする場合あり(必ずではなく).
  • char buf[10] ={0}; な感じに初期値を入れてしまうことで回避できた.
  • COINSでdhrystoneコンパイル時、 gccのヘッダを流用しているため?か、
  • stdio.hヘッダにあるstatic inlineになっていないinline関数(fget?の内部関数)が 複数のobjでincludeされてると、リンクで名前の衝突が発生. (実際に必要としたソースは1つだったので、includeを調整して回避).
  • COINS, 正常なtolower(c)で')'がらみでエラー. (interpreter_smp:マクロでtoupperを乗っ取って回避).

(とかいたけど、coinsはちゃんと環境できていない可能性もあり)






2010-3-9[火] マイナーなCコンパイラをちょっと触る

フリーでwin環境用exeが作れる、ちょっとマイナーな Cコンパイラをちょろっと触ってみた、というかインストールしてみた時のメモ.

試したのは LLVM-gcc, PCC, LCC, TinyCC, COINS。

(マイナーというと語弊のあるモノもあるけど win環境用のcコンパイラとしては、で)

LLVM-gcc

(※追記:LLVM-gccでllvmを使う場合-emit-llvmオプションとつけないとダメだったよう)

(wikipedia)

LLVM&clang は、 そのvmな仕組みとか、 オプティマイズ等の実力とか、 使用用途(appleの動向)とか、 GPL(v3)より緩いライセンスがらみとか、 いろいろ話題で今後の発展に期待大なコンパイラ(vm)、 だけど、 win環境で試すには、 mingw-msys 環境に追加する方法になっていて、 ちょっとまだ敷居が高い感じ。

また、残念ながら win 環境向けにはまだ clang バイナリは無いようなので、試せるのは gccフロントエンドのモノのみ。 (追記:clangのほうは自分でコンパイルすれば使える..ということでさらに敷居が高い)

ただ llvm-gcc側にコンパイル環境として(mingw-gccをベースにした)必要なものは一通り入っているので、mingwコンパイラをインストールしておく必要はない(あってもかまわないけど)。

設定としては、まず msys 環境が必要。 mingw本家TDM等から適当なのをインストール。
うちは 猫研pack のtdm-gcc環境を使ってるのでそこに寄生。
ここでは c:\msys にmsysがあるとする。

LLVMのダウンロード頁から以下の2つを取得

    • LLVM Binaries for Mingw32/x86 (試した時は、v2.6)
    • LLVM-GCC 4.? Front End Binaries for Mingw32/x86 (試した時は gcc-4.2)

ダウンロードしたファイルを適当な場所、たとえば
  x:\llvm-2.6 x:\llvm-gcc-4.2
に解凍したとする。(来月には2.7が出るみたいだけど、今はまだ)

msys込みで、パスを設定。

set "path=x:\llvm-2.6;x:\llvm-gcc-4.2\bin;c:\msys\bin;%path%;"

あとは、llvmc 、または、llvm-gcc, llvm-g++ を用いて、 適当なソースをコンパイル、といった感じだろう。 (※簡単にヤッたら間違ってた。追記参照)

mingw 環境のコンパイラだけ置き換えた状態のようなんで、 使い方は mingw(gcc)。 win-apiアプリの コンパイルもできるよう。 (簡単な窓を出すだけのhelloプログラムは動いた)。

速度等はろくに調べていないけれど、xorshiftのときのサンプルをコンパイルしてみたところ、inline展開が働いた時のスコアは結構よいほうだった。 ただ、inline 展開をあきらめるのがvcやg++4.4より早いようで、xorshift128あたり から関数呼出になってスコア落ちた。gcc3.4.5同様素直な感じなのかな、と。

追記: llvmとしてコンパイルするにはオプションが必要のよう. でもってコンパイラ環境がうまく設定されていないのか、一度にコンパイルできず.こちら等を参考にして

llvm-gcc -O2 -DNDEBUG --emit-llvm -S test.c
llvm-as test.s
llc test.s.bc
llvm-gcc -o test.exe test.s.s

llvm-gcc -DNDEBUG -O2 --emit-llvm -S test.c
llvm-as -o tmp.bc test.s
llvm-ld -o tmp.2.exe tmp.bc
llc tmp.2.exe.bc
llvm-gcc -o test.exe tmp.2.exe.s

て感じにしてみる(後者のほうが全体に対するオプティマイズが効くかも)

※ llc で -march=x86 を付けるとwin用でなくなるみたいでマズイのだった.

※追記 こっちでLLVM-Clangを使ってみた。


PCC(Portable C Compiler)

(wikipedia)

かって(ANSI-C以前)の Cの標準だったろう Cコンパイラで、 最近はこちらでC99化していってるらしい。 (こちらもGPLv3の影響で脚光を浴びてるかんじ?)

もともと移植性のいいモノなためか、ちゃんとwin32版も用意されている。
コンパイラ以外はgnuツールなりmingwツール/ライブラリが採用されているようだ。

こちら から、 pcc-20090818-win32.exe をダウンロード。実行してインストール。

とりあえず通常のプログラムフォルダ c:\Program Files (win64なら c:\Program Files (x86)) にインストールしたとする.
※ひょっとすると、win64でも(x86)ついてなかったかもしれないので注意.

コマンドプロンプト窓でコンパイラを使う場合は、

set "path=%ProgramFiles%\pcc\bin;%path%"

を先に実行。この状態で pcc を用いてコンパイル。

pcc --help でヘルプ表示すると ld の分しか表示されず涙目だけど、 元はunix系のccそのものだろうから、そのあたりを見ればいいのか。 (基本部分はgccが同じにしてるはずだろうからgccのを試せばよいのかも)

mingwベースなんで、winプログラムも同様。とりあえず窓helloは、

pcc w_p_smp1.c -l gdi32

でいけた。

なお、出来たexeは mingw 同様 msvcrt.dll に依存している。


PCC コンパイラのコンパイル

当初 win32バイナリの配布に気づかず、ソースにwin32用バッチがあったので コンパイルしてみてた。 ので、そのメモも。
ソース修正は1行挿入のみだけど環境設定がちょっと面倒だった。

ソースについては、こちらから pcc-cvs-100306.tgz、こちら から pcc-libs-cvs-100306.tgz をダウンロード。 展開してできたフォルダを x:\pcc, x:\pcc-libs とする。
(どうも毎日バックアップされてるもののようで日による差分は不明、最新版とればいいんじゃね、で)

ソース修正は pcc/os/win32/config.h の31行目付近の

#if !defined(vsnprintf)
#include <stdio.h>     //この一行を追加.
#define vsnprintf _vsnprintf
#endif

をコメントのように#include <stdio.h> を追加するだけ。 (あとからstdio.hがincludeされるとvsnprintf置換でバグになるため)

面倒なのは bison や flex を使うのでそれらを用意する必要があること。 幸い猫研パックのmsys に入ってるので、msys環境を用いれば済みそう。

と実際にためすと、flex がハング。msys-regex-1.dll が無いと怒られる。mingwのダウンロード頁 から regex の dll 版をダウンロードして解凍(lzmaというあまり普及していない形式なので解凍ソフト(7z)も入れたり). とりだせた msys-regex-1.dll を msys\bin にコピーしたらok。(ああ、うちのmsysはちょっと古くパックの_a004のモノなので最新で直ってる可能性あり)

vc2008 でコンパイルする場合は

call "%VS90COMNTOOLS%vsvars32.bat"

をしておき(2005なら%VS80…,2003なら%VS71…だろう)

x:/pcc/os/win32 へカレントディレクトリを移動し、

build /cl /pccsrcdir x:\pcc /pcclibssrcdir x:\pcc-libs

を実行。うまくいけば pcc.exe (とmkext.exe) が出来ているハズ。

※bison等のツールの具合によっては、build /cl のみでコンパイルできるかもだが、己の使ったバージョンの場合、bisonに(相対パスの)ファイルが見つからないと怒られた。で、絶対パス指定してみたら回避できた、という状態。

できたexeを試す場合は、配布バイナリをインストールした環境のpcc.exeと置き換えてみれば、で。


また pcc 自身でもコンパイルできる。この場合は、インストールしたpcc環境のbinへパスを通した状態で

build /pcc /pccsrcdir x:\pcc /pcclibssrcdir x:\pcc-libs

を実行.

もし pccのインストールディレクトリを c:\program files\pcc 以外にしていた場合は、build オプションとして /pccdir c:\hoge\pcc のようにインストールしたpccフォルダを追加する必要がある。win64の場合 (x86)付なので指定が必要だろう(/pccdir "%ProgramFiles%" かな)。

LCC

LCC は、こちら が大本。 コンパイラ作成の教材のような感じで、 配布されているものは、ソースのみでバイナリなし。

ただ、これをベースに使える環境にしたパッケージがいくつかあるようで

といったものがある。


こちら にlcc対応のデバッガが公開されてる。

LCC-WIN32

LCC-WIN32 は結構昔からあって、 昔試した時点で、IDE環境完備でデバッガ等の出来もよく、 言語仕様拡張や生成改善等もされていて で独自発展していたのだけれど、 今、サイトをみると頁はあるけれどコンパイラ等へのリンク等がことごとく切れてる。 一応、去年の秋はまだダウンロードできてたのだけど。 開発会社のトップページを みると権利関係が別の会社に移譲されたようなことが書いてあるようで... 現状フリー配布はなくなったってことなのかな(LCC-WIN32系のサイトをあたれば、FTPからのダウンロードがまだできるかもだけど、リンクしないでおく)。


Pelles C

PellesC もLCC-WIN32同様に IDE完備の開発環境になっている。 IDE上でSJIS入力できたり、char文字列中に表やソで\含文字を使っても 実行で文字化けせず表示されてちょっと感動。 デバッガもそこそこいい感じ。ただwatchポイントは貼れず(LCC-WIN32は出来てた)。 プロジェクト設定は DEBUG/RELEASE切り替え等はできないようで、 プロジェクトのオプション設定でコンパイラ頁とリンカ頁のデバッグ設定をそのつど 切り替えないと駄目なよう(たぶん。でも、その程度)。

当然Winアプリ作れる。(ウィザードもあり)
(あとWinCE用の開発環境にもなっている)

コマンドプロンプトで使用するときは、まず、

set "PATH=%ProgramFiles%\PellesC\bin;%PATH%"

を実行。cc を用いて

cc hello.c

といった感じ。win窓helloなら

cc /Ze w_p_smp1.c user32.lib gdi32.lib

で、とりあえず。


LCC コンパイラのコンパイル

大本のLCCはソースしかないけれど、win32様のコンパイルバッチが入ってたので 試してみた... が、少々修正する必要があった。 のでそのメモ。

試したのは v4.2 のもの。tar.gz, tar.Z, zip の3つの圧縮ファイルがあるけれど、 基本同じものだけど、ソースの改行コードが違うかも。 winなら zip のモノを選ぶのが吉。

※実は tar.gz のを使った。lburg/lburg.c ファイルのみ改行コードが lf(\0a) でなくcr(\0d) だったためコンパイラに怒られた。lfに置換して済ましたけれど、zipのを展開したらcrlfでそもそも出会わないはずの不具合だったorz

win向けにコンパイルするのには、makefile.nt を使う。 使用するコンパイラは vc. ただちょっと古いバージョン(vc6ぽい) 向けみたいでvc2008にはすでにないオプションが使われていたり。

makefile.nt の9行目付近からの

CFLAGS=-DWIN32 -Zi -MLd -Fd$(BUILDDIR)^\
LD=cl -nologo
LDFLAGS=-Zi -MLd -Fd$(BUILDDIR)^\

の部分を

BUILDDIR=.
CFLAGS=-Doutp=outP -DWIN32 -Zi -MT -Fd$(BUILDDIR)^\
LD=cl -nologo
LDFLAGS=-Zi -MT -Fd$(BUILDDIR)^\

のように修正.
-Doutp=outP として、マクロ置換しているのは、関数宣言された名前を変数名としてつかったといって怒られたため、その回避。 (outpはx86系のout命令をc用にした名前として昔からある...のでビルトイン関数かなにかの影響だろうか... とりあえずのお試しで回避できたため原因追求せず)
(-MTにしてるから-Ziいらないけど、面倒なので残したまま。逆に-MTdにするでもいいが後述の修正箇所の.lib名もそれにあわせる必要あり)

あと、etc/win32.c の

  • 8行目付近

    #define LCCDIR "\\progra~1\\lcc\\4.1\\bin\\"

    の内容を、実際にlcc.exeをインストールするフォルダに変更.
    とりあえず、お試しなので "x:\lcc42" で作業しているとして、そこを設定。


  • 20行目付近の "libc.lib""libcmt.lib" に修正する。

win32.c を見ての通り、結構、環境をハードコーディングしているので、 本格的に使うならば、いろいろ修正したほうがよさげな雰囲気。
また、この内容から、コンパイラ以外のリンカやライブラリ等は VCに寄生するスタイルのよう。

とりあえず、staticリンクライブラリが使えるエディションならコンパイル可能になったはず。

dllランタイム版でコンパイルする場合は、上記までの修正に対してさらに、

  • makefile.nt の CFLAGS,LDFLAGS の -MT-MD に変更
  • cpp/unix.c の memmove関数の定義を #ifndef _MSC_VER で挟む.
  • etc/lcc.c の extern int getpid(void);宣言を #ifndef _MSC_VER で挟む.
  • etc/win32.c の "libcmt.lib"(元"libc.lib") を "msvcrt.lib" に変更.

を施す。

で、vc2008を使ってコマンドプロンプトでコンパイル

call "%VS90COMNTOOLS%vsvars32.bat"

を実行(2005なら%VS80…,2010なら%VS100…って感じか)

作業場所が x:\lcc42 フォルダだとして、そこに移動して

nmake -f makefile.nt clean
nmake -f makefile.nt all

を実行. 上手くいけばlcc.exe,cpp.exe等が作られてる(ハズ)。

お試しは

extern int printf(const char* fmt, ...);
int main(int argc, char* argv[]) {
    printf("hello world\n");
    return 0;
}

を hello.c としてセーブ.

lcc hello.c

でコンパイル。 うまくいけば a.exe ができるので、a.exeを実行してhello worldが表示できたらokと。
※ リンカー等はvcのモノを使うので、vcコンソール環境が使える状態で使うこと.

なお、#include をせずに直接 extern でprintfを宣言してるのは、#include <stdio.h> をすると cpp.exe 実行中に帰ってこなくなったため... 追求するのは面倒なので、お試しとしては、これで終わりにしておく。


TinyCC

TinyCC は小さいCコンパイラ。 (コンパイラ本体のc,hソース行数は3万行弱)。

けど、文法は、ほぼフルスペックのC89+α(C99の一部)。 (浮動小数点数も構造体もビットフィールドもあるし long long もある, らしい)

とりあえず、サイトからwin用のバイナリを取得して、適当な フォルダに展開。とりあえず、c:\tcc にいれたとする。

set "PATH=c:\tcc;%path%"

でパスを通して、あとは tcc hello.c のようにしてコンパイルするだけ。 winアプリも出来るよう(examples/hello_win.c )
※ランタイムとしてmsvcrtを使用の様.

すごく、あっさり使えてしまう代物のよう。


※実は試すまで、この作者のotcc の延長のモノかと思ってた。 舐めてました。すみません。 otccのほうはwin用でなくlinux用の 1000行に満たない小さいソースのKR-C系ミニ言語. 実行ファイル生成. (IOCCC 2002優勝らしく. 配布ではちゃんと可読なバージョンもあるのでそれをみるのも吉. それどもトリッキーですが)

TinyCC コンパイラのコンパイル

mingw-gcc を用いる。
mingw-gcc を使える状態にしておいて、 サイトから取ってきたソースのzipを x:\tcc-0.9.?? にでも展開する。

x:\tcc-0.9.??\win32 フォルダに移動して、 build-tcc.bat を実行する。exeができたら吉。


COINS

COINS についてはリンク先の概要をみるなりして。 コンパイラ研究のインフラとしてのCコンパイラが配布されてるよう。 ライセンスはApache Licene Version 2.0

モノは java で作られていて、また win環境では cygwin を使う ので、予め、それらがインストールされている必要がある。

javaに関しては、コンパイラをコンパイルするのでなければ jdk は必要でなく jre がインストールされていればよさそう。何かの折にjre6がインストール済みなのでそれを利用。
c:\Program Files (x86)\java\jre6 にインストールされているとする。

cygwin は gcc等の基本的な開発ツールがインストールされていればよく。 かなり昔にインストール済みなので、新規インストールについては他のサイトを適当にみてもらって。 と自分の環境はしばらく更新してなかったのでsetupで更新... したら、どうも最新のcygwin環境だとCOINSはちょっと不具合がでるようで対処が必要になる.後述)
cygwin は c:\cygwin にインストールされているとする。

COINSコンパイラのインストールや使い方については、こちらこちら やその他諸々を参考に...

ダウンロードはCOINSのダウンロード頁 から、 こちらのサイトの助言にしたがい 国際(en)版をダウンロード。 (jp版は euc が使われているためツールによっちゃwin環境では不味い場合があるらしい... なおjp版だけならSourceForgeの頁 からもダウンロードできる)。
己が入手したのは coins-1.4.4.3-en.jar

ダウンロードしたファイルを(jarだけど)zipファイルとして適当なフォルダに解凍。
とりあえず、 x:\coins\ に解凍したとして、
  x:\coins\coins-1.4.4.3-en
ができているとする。

※この中には classes\ フォルダがあり中身が生成済みだったので、今回はそれをそのまま使うことにした。ソースのみ配布のバージョンなら当然再コンパイルが必要。


最新のcygwin での不具合回避のため、c:\cygwin\bin 中から gcc-3.exe cpp-3.exe
gcc.exe cpp.exe に変名して x:\coins\bin\ フォルダ作ってコピー.

こちらで紹介されてる不具合回避方法だとCOINS以外で不味い場合もあるかも(?)なので、また、今回はhello world のみの簡易なお試しなので暫定的な回避にした。


コンパイルでのコマンドプロンプトでの記述が長くなるので、次の一行をバッチにしておく。

java -class x:/coins/coins-1.4.4.3-en/classes coins.driver.Driver -coins:target=x86-cygwin,assembler=as %1 %2 %3 %4 %5 %6 %7 %8 %9

名前は coins_tc.bat として x:\coins\bin\ にセーブ。


コマンドプロンプト窓(dos窓)をあけ、pathを設定する。

set "PATH=x:\coins\bin;c:\cygwin\bin;%ProgramFiles%\java\jre6\bin;%PATH%"

※不具合回避で置換すべきexeのあるフォルダがpath検索で先に見つかるように設定。

hello.cとして以下を適当なフォルダに作成しておく.

#include <stdio.h>
int main() {
    printf("Hello World!\n");
    return 0;
}

先のバッチを使い

coins_tc.bat -o hello.exe hello.c

のようにコンパイル。出来た hello.exe を実行して、hello world が出力されたらok.

cygwin ツールを cygwin 環境以外で使うため、パス関係の警告がいろいろ出るけど無視。

もし cygwin 環境で実行したいならば、この(上記path設定の)状態で

bash --login -i

を実行。カレントがhomeに移動してるので、お試しフォルダへ再度移動。
そこで coins_tc.bat -o hello.exe hello.c を実行すれば、パス名警告は減る(無くなる)かも。


コンパイルして出来上がったexeは、cygwinのgccのライブラリをリンクしているだろうで、当然、その制限をうける。


(※だめもとでmingw環境でコンパイルしたらやっぱり駄目だった。リンク関係でいろいろ無いと怒られる。けど、そのへんの問題だけなのかも?)


その他

  • hello world頁をどうこうしようと思ってやり始めたが面倒になってあきらめ... が、折角試した分くらいは、で書いたのがこの頁。
  • vc,bcc,dmc,watcom はとりあえず、いろんなサイトあるし。
  • Fail-Safe Cというモノもある模様。win用はなさそう?で、cygwinで試しみるも失敗。(どちらかというとocaml関係に振り回される時間のほうが多くorz)
  • COINSしたくてcygwinも使ったが、cygwinだとunix系のモノが試せてしまい、前行のようにダークサイドへ突入...で疲れたので止め。ポート済み以外はみないですまさないと... TenDRAはないのかな。
  • 試して無いけどwinで動くcインタプリタとして Ch とか CINTとか
  • Under C++ とか、 その他諸々以外とある模様。






2010-3-1[月]ありすとBOBO(川崎康宏)読了

川崎康宏『ありすとBOBO』いまごろ読了(書店で見かけて知ったのが昨日)。 「ラ、ラブコメよ、ラブコメ。でも、ちょっとだけラブコメじゃないの」 と言ってみたくなる (某PG格言を久しぶりにみて。その元ネタは実はやってないけれどヤっぱ何にでも使えるテンプレートだなぁ... ああ発売日って2週間ほど前だったのか、時期はずした模様)。 いや、言ってみただけです、相変わらずの作風で(ちょっとじゃなくて十分)、クマが主人公。 ええ、Aliceの続編の様。 内容的にはAlice未読でも前作が存在するなんておもわないだろー程度に 独立してるので(もっと匂わしてくれてもいいのに) リメイクの可能性も浮かぶけれど、 作者BBS で1週間くらいしかたってないと書かれてる:) なにげに重要情報の出るBBSです。 続刊もすぐらしい...念願の3巻突入できるのでせうか(変則換算だけど)。 ぜひつづいてほしいなあ。 Aliceのほうは中表紙すばらしいのに表紙が大人しくて勿体なかったけど、 今回は絵もオビもよかったし。 なんというか騙されて(語弊大)買う人もいてくれそうな、で。

鮎川はぎの『横柄巫女と宰相陛下1-3』言葉足らずで失言通りこして横柄に見られてしまう巫女見習いが王位継承問題に巻き込まれる話(1巻)。わりと王道の少女小説か。 すぐさま続刊に手を出す程度には気に入ってしまった模様。 己にしては珍しく特定の声で読めてしまってるし(ナガトでなく千秋).

那須雪絵『魔法使いの娘(8)』最終巻。 こういうラストをかける人なんだよなあ。 エビアンワンダー(おがきちか)と近いものがある、ってか、 視点的に似てるのか。細かくみると結構違うんだけれど... というか素直な少年(スカとかハリとか内沢とか)は描く気ないのかなあ。 ああ悪い方向にそのまんま年食ったのが無山なんだろーけど、 挫折してヒネてしまった野郎ばかりのような。

(新刊嬉しくてついひさしぶりに書いてみたけど、やっぱりシンドイ。 前のは選択なんて考えず無差別だからかけてたんだなあ)





<<前の10件