NEONでandnot

bitboardの操作で  a & ~b としたいときに、NEONでSSE2と同様に処理するためにどう書くか確認してみた。

SSE2では_mm_andnot_si128(__m128i, __m128i)を使い、最初の引数に~が適用されるため、

_mm_andnot_si128(b, a);

と書く。NEONではvbicq_u32(uint32x4_t, uint32x4_t)を使い、SSE2とは逆に第2引数に~が適用されるため、

vbicq_u32(a, b);

と書く(引数の型により関数名は適宜変える)。

電気代

中部電力でも5月1日から電気代が上がったらしい。 料金単価表の従量電灯Bを見ると300kWhを超えると1kWhあたり27.97円ということらしい。 うちの2ndマシン(PhenomII X4 940 TDP125W)をフルロード(4スレッドで学習)で動かすと160Wを消費するので、1ヶ月だと0.16×24×30＝115.2kWhで電気代は3,222円(消費税は？)。 1年続けたら、電気代で Core i7 が買えてしまう。 TDPだと3770K(Ivy)が77W、4771(Haswell)が84Wなので、システムの消費電力をCPUのTDP＋35Wと仮定するとIvyは112W、Haswellは119Wなので、1ヶ月で2,256円～2,397円で年間1万円前後違いますね。 なお、FX-8350だとシステムで240Wくらい行くのでさらに差が広がります。 というわけで、学習を回しつつ、floodgate投入は厳しいなぁ～。

GDI+ にはまる

jpeg や png を表示する必要性に迫られて、初めて GDI+ を使ってみました。

いやー、便利ですね。
文字列は WCHAR で渡す必要があるとか表示が遅いとかいろいろありますが、ファイルの読み込みから表示があっさりできてしまいました。
しかも、α付の png なら抜き色とかANDで抜いてORで描くとか何も考えずに単に上書きすればちゃんと表示される。
楽チン、楽チン…、と思ったら落とし穴にはまりました。

単にウインドウ全面に描くときには気づかなかったのですが、始点を指定して表示すると妙に大きく描画されはみ出す？！
で、いろいろ調べてみたら画面の解像度(標準は96DPI)と表示したい画像の解像度(72DPI)が違うとサイズが同じになるように描画される(96/72倍される)ようです。

Graphics の複数ある DrawImage メソッドのうち、描画側と元画像の両方の領域を指定してやるメソッドを使って、同じ画素数になるように指定してやれば意図したサイズで表示されることがわかりました。

あんまり C++ で GDI+ を使う情報がないみたいで、ヘッダを見ながら試行錯誤しながらやってます。

詰ルーチン開発中

今、詰ルーチンを作り直しています。
まだ、単純なdf-pnに岸本さんの最小距離法を組み合わせただけで、問題を解かせると回答率がやや低いので、とりあえず解けた問題だけ今年の選手権バージョンの詰ルーチンとの比較をしてみました。

すると、意外と健闘…というか、進歩本２の問題集では処理時間が短くなっていそうです。
もうひとつ、羽生の将棋 実戦[詰み＆必死]200の詰め問題だとなんとなくまだ勝っているかな?という感じ。
(不詰証明が速い??)










これはけっこう期待が持てるかも? と思いつつ、次回の選手権まであと11ヶ月で、あまりのんびりしていられない、か？！

WCSC21版(WPNS)：WPNS＋最小距離法＋証明駒・反証駒＋優越関係＋固定深さの詰ルーチン併用
5月30日版(df-pn)：df-pn＋最小距離法

moves/yss

aki.さんのd.hatena.ne.jp/ak11/20110515#p1に刺激されて、測定してみました。
・・・だいぶ負けていました。orz

CPU	YSSベンチ(s)	moves/sec	moves/yss
Athlon64X2 5000+	9.5	5,026,514	47,751,883

ちょっと単位の表記はおかしいんじゃないかと思いますがｗ