ToDo:
今にはじまったことじゃないけど、やばいなー
http://www.nicovideo.jp/watch/sm19420263
なんか A 級はチラチラ見てる感じ、参考になるなーと思う時が結構あるんだけど、 S 級は理解を越えてる。
なんでそんなことするん? って思っちゃう置き方がちらほらあるのは、ちぎりとか考えてる感じなんかなぁ
(00:23)
http://d.hatena.ne.jp/kazuhooku/20121203/1354552696
GCC 前提で…
#include <stdio.h>
inline long long ct_binary_roundup(long long n) {
long long r = 1LL << (64 - __builtin_clzll(n));
return r == n * 2 ? n : r;
}
int main() {
printf("%lld\n", ct_binary_roundup(256LL));
printf("%lld\n", ct_binary_roundup(432432423LL));
printf("%lld\n", ct_binary_roundup(432432423999LL));
}
とかは割とアリな気がする。 log とかでも消えるんじゃないかなーと思ったけど、なんかうまくいかなさげ…
(03:40)
http://codeiq.hatenablog.com/entry/2012/12/03/234209
うーん。1位がたくさん出るってのはゴルフの問題としてはどうでもよかった、ってことなんだけどな。
同着の人がみんな僕のコードと似たような形のコードだとすると、ここまではまあテクニックといくらかの時間だけで書けるコードで、アルゴリズムはわりと自明な感じだった、ってことなので。
もうちょいいい問題だと、アルゴリズム的な転回とテクニックのバランスが色々でてきて、まぁそこが面白くて難しくて時間が無駄に消費される部分だと思うんだけど。
というわけでこの問題を面白かったことにできんもんかと、なんとか削れんもんかなーとたまに眺めるもののキツい。
(03:11)
http://sw-event.intel.jp/event_4.html
これに行ってみた。 intel cilk plus ってやつ普通に良さそうだなぁとか思った。なんか後で cilk_spawn どうやって実装してるの? co-routine? って聞きにいったらそうだとのこと。なんか network 越える場合厄介でみたいなこと言ってた気がして越えるのかすごいな…とか思ってたけど、なんか勘違いぽい気がする。 GCC に入ってる branch があるらしいから実装読んでみたいところ。ていうか実装についての論文があればそっちの方がいいんだけど、あるかな。
あと array slicing てこれ領域重なってる場合どうなるの、っていうお決まりの質問もしたけど、ヤバイ、とのこと。最初は大丈夫に作ったけどパフォーマンスがよくないからやめたとか。そりゃそうだ。単純な例ならコンパイラが warning 出せるってのと、あと現状では runtime checker 的なのは無いとのこと。
こういうのライブラリとして直接さわらず使ってる人は結構ハマったり、そうでなくても大丈夫なんだろうか…って気になってうっとうしい部分だと思うんで、 runtime checker があるといいんだろうなと思う。
あと xeon phi はこう GPGPU への敵対心というか、まぁ普通に考えて不利な立場だからか、かなり攻撃的な感じだった。内容は
みたいな感じだった。
直前に読んだ
http://d.hatena.ne.jp/w_o/20121202#1354384823
のエントリで紹介されてる論文も「ちゃんとした学会で発表された論文でもGPGPUは100ばいはやいとかはおかしいって言ってるよ」！とかいう感じで引用してて、それオマエらが書いた論文やんけ、とか思った。
とはいえ、攻撃的だったと書いたけど、実際こうかなり公平な感じの言及だったと思う。なんていうか intel ってやつは昔から技術に関して真摯なイメージがあるんだよな。何倍速いとかは必ず小数点以下1ケタまで書く印象というか。昔 Mac OSX が出た時に Apple が 4x faster とか広告出してる隣で、 core2 の宣伝で 127% performance improvement みたいな(数字は適当)地味な宣伝を出してたのを思い出す。まあ当時はこの 127% 速いコアに変えて 4x faster ってことは、根拠もなく速いって言ってた G4 ってなんだったんだろうな、とかアップルにムカついてただけだけど。
あとは普通の xeon と xeon phi 積んだマシン複数用意して、それを全部同じコードで同時にぶんまわす、ってのができるよ、っていうのが楽しげだなーと思った。実際デモもやってたし。
しかし xeon phi は xeon のざっくり 2.X 倍くらいとのことで、なんか普通のマルチコアでいいんじゃね…っていう疑問には割と答えられてない気もした。まぁムーアの法則的にコアの数増やすのはできるはず、って話なんだろうけど。
(18:12)
http://cilkplus.org/sites/default/files/open_specifications/CilkPlusABI_1.1.pdf
を読めばわかる気がする。
via http://cilkplus.org/download#open-specification
(18:26)
http://jstorimer.com/2012/11/08/matz-is-not-a-threading-guy.html
via https://twitter.com/_ko1/status/277343915261169665
よくわかってないんだけど、 ruby に thread があったら何するんだろう。それはプロセスではダメなんだろうか
(19:15)
コマンドメモ
絵をとる
ffmpeg -r 20 -s 1024x768 -f x11grab -i :0.0 -acodec libmp3lame -vcodec libx264 -b 1000k -ar 22050 -ab 48k -threads 5 -vsync 1 -y -f flv ~/out.flv
音をまぜる
ffmpeg -t 00:01:15 -itsoffset -00:00:05 -i out.flv -i mus.mp3 -map 0:0 -map 1:0 -target ntsc-dvd -b 500k mov.webm
(13:24)
https://play.google.com/store/apps/details?id=com.ggee.vividruntime.game_ticket_1791
ムリムリ腕いたい…
ラフレシア前後半の間と長元坊だけは相変わらず稼ぎ所だった。処理落ちしまくってるせいで音楽が全然あってないのが残念ですね…
(01:06)
実にひさびさに kernel をビルドした。というのは買ったUSBキャプチャ装置が動かなくて、僕はドライバってやつは型番を配列に足してやればだいたい動くもんだという認識があるので、適当に足しみたのだった。
適当にやると音はなんか鳴るようになって、でも絵がうまくいかなかった。 lsusb -v や windows でのドライバ名とかを見るに、なにやらチップの世代が違うらしく、ああこれはちゃんと調べて書かないと無理ぽいな…という結論になって、諦めた。
いいかげんな認識をあらためるべき
(03:04)
http://sakidatsumono.ifdef.jp/draft3.html
をやってみて、まあそのへんだろうなあという位置に来て面白かった。
政治的な右・左度(保守・リベラル度) -4.6 経済的な右・左度(市場信頼派・政府介入派) -2.59
(03:06)
昨日ふと困ったバグは少しおもしろかった。バグ自体はなんてことないものなんだけど。 SDL 使って書いてるもので、青だけ出ない。なんか青くあるべき場所が黒い。
なんか SDL のビデオドライバとかがおかしなことになって、ピクセルフォーマット勘違いしてたりするのかなーとか最初は思ったんだけど、まぁよく考えると Mac なんていうメジャーなプラットフォームにそんなバグあるわけない。そもそも白が出てる部分もあるんで、青が完全に死んでるわけじゃない。けど、灰色が出るべきところは黄色ぽくなってたりして、やっぱ青がおかしい感じではあるんだよなあ、と。
で、色つくってる部分のコードを見てみてると、
Uint32 c = 0;
switch (color) {
case EMPTY:
c = SDL_MapRGB(scr_->format, 0, 0, 0);
break;
case OJAMA:
c = SDL_MapRGB(scr_->format, 127, 127, 127);
break;
case WALL:
c = SDL_MapRGB(scr_->format, 255, 255, 255);
break;
case RED:
c = SDL_MapRGB(scr_->format, 255, 0, 0);
break;
case BLUE:
c = SDL_MapRGB(scr_->format, 0, 0, 255);
break;
case YELLOW:
c = SDL_MapRGB(scr_->format, 255, 255, 0);
break;
case GREEN:
c = SDL_MapRGB(scr_->format, 0, 255, 0);
break;
default:
break;
}
//return c;
と、最後の return が無かった。ああまたやらかしたかー、アホだなー、そりゃヘンなことも起こるよなーと思って、その場は次にいった。
その後の呑み会で、いやそんなわけないだろうと思う。そりゃヘンなことも起こるかもしれないけど、上記のコードで青だけ落ちるってのはどう考えてもおかしい。というのは SDL_MapRGB が返り値として RAX を代入してくれてるはずなんで、この return は別に無くても大丈夫な気がする。
switch とかってなにやら賢いことするからそれで BLUE のパスだけ RAX 壊れたりするのかなーと思って、この部分の逆アセンブリ見てみても特に RAX が壊れる感じがしない、というか SDL_MapRGB を呼んだ直後に ret している。まあ switch のコードはなかなか賢そうな感じで、やるなあとか思ったけど…
でまーとなるとなんでかなーと思って考えてみると、むしろこの関数を呼ぶ側があやしいんじゃないかと。特にインライン展開されてたらそっちを見ないといけない。見てみると、インライン展開はされてないんだけど、
Uint32 c = GetPuyoColor(color);
SDL_FillRect(scr_, &r, c);
が
0000000100008736 callq 0x100014d72 ; symbol stub for: __ZN6GuiSdl12GetPuyoColorEc 000000010000873b movq 0x08(%rbx),%rdi 000000010000873f leaq 0xffffff58(%rbp),%rsi 0000000100008746 callq 0x100014e0e ; symbol stub for: _SDL_FillRect
となっていた。つまり RAX を引数として使ってない。 return を入れてやると
0000000100008841 callq 0x100014d72 ; symbol stub for: __ZN6GuiSdl12GetPuyoColorEc 0000000100008846 movq 0x08(%r15),%rdi 000000010000884a movq %r14,%rsi 000000010000884d movl %eax,%edx 000000010000884f callq 0x100014e0e ; symbol stub for: _SDL_FillRect
となる。なるほど return が無いバージョンは不定な値返してる、ってのは同じ compile unit にあるからわかるわけで、だからどうせ意味ないなら次に渡す必要もないよねー的な感じで消されちゃってるんだろう。関数またいだフロー解析的な最適化みたいな感じなのかな?
でまあ RDX (SDL_FillRect の第三引数) は SDL_MapRGB 内でたまたま青を合成する前の値を保持するレジスタとして使われて、その後いじられなかったんだろう、と思う。
なにやらコンパイラさん賢いなあというか、ややびっくり感が強い
(03:22)
JS でよく a=1.5 とかを 1 に切り捨てをするために、 a|0 とか書く。浮動小数を整数にする時のゴルフイディオム的な感じ。
さて、デカい浮動小数に対してこれをやると int の範囲に落ちる。
js> 1e20|0 1661992960
て感じ。 irb で確認してやると
irb(main):006:0> (10**20)%(2**32) => 1661992960
ただしい。 1e21 になると signed int の値域で考えると負数になるので少し ruby 側の処理が変わるけど
js> 1e21|0 -559939584 irb(main):007:0> (10**21)%(2**32)-2**32 => -559939584
となって一致する。 1e22 も一致するんだけど、 23 から話がおかしくなる。
js> 1e22|0 -1304428544 irb(main):010:0> (10**22)%(2**32)-2**32 => -1304428544
js> 1e23|0 -167772160 irb(main):011:0> (10**23)%(2**32)-2**32 => -159383552
js> 1e24|0 -1610612736 irb(main):012:0> (10**24)%(2**32)-2**32 => -1593835520
js> 1e25|0 -2147483648 irb(main):013:0> (10**25)%(2**32)-2**32 => -3053453312
js> 1e26|0 0 irb(main):014:0> (10**26)%(2**32)-2**32 => -469762048
さてこれは何故でしょうか、ってのを考えると、精度の問題。 double の 53bit の精度から下は切り上げ切り下げの後に 0 になっちゃうわけだけど、 1e22 まではその切れる部分はもともと全部 0 だったから問題なかったけど、 1e23 から 1 が入ってる場合があって、そこが消えちゃうとまずい、と。
こういうのもちょっと面白い
js> 18014398509481986|0 0 js> 18014398509481987|0 4
まあなんか、 ruby でも
irb(main):025:0> 1e23.to_i => 99999999999999991611392 irb(main):024:0> 1e23.to_i%2**32-2**32 => -167772160
とかやれば再現できるわけで、よく考えれば不思議でも不気味でもなんでもないんだけど、なんか JS キモいな、と思ってしまったのは、唯一の組み込みの数値型が浮動小数だからかな…
(03:24)
CD-R が見つからないので PXE boot でのインストールにチャレンジ
/etc/dhcp/dhcpd.conf
default-lease-time 86400;
max-lease-time 259200;
ddns-update-style none;
subnet 192.168.11.0 netmask 255.255.255.0 {
range 192.168.11.200 192.168.11.250;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.11.255;
option routers 192.168.11.1;
option domain-name-servers 192.168.11.1;
option domain-name "shinh.org";
deny unknown-clients;
}
host pxeclient {
hardware ethernet 00:1D:72:8A:AD:D8;
fixed-address 192.168.11.200;
filename "/pxelinux.0";
next-server 192.168.11.17;
}
/etc/xinetd.d/tftp の disable を no に。
$ sudo systemctl restart dhcpd.service $ sudo systemctl restart xinetd.service
/var/lib/tftpboot を適当に準備
find /var/lib/tftpboot /var/lib/tftpboot/ /var/lib/tftpboot/initrd.img /var/lib/tftpboot/pxelinux.cfg /var/lib/tftpboot/pxelinux.cfg/default /var/lib/tftpboot/vmlinuz /var/lib/tftpboot/pxelinux.0
pxelinux.0 は
$ sudo cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot
で良し。 vmlinuz と initrd.img はちゃんとバージョンをあわせる。
# wget http://ftp.riken.jp/Linux/fedora/releases/17/Fedora/x86_64/os/images/pxeboot/vmlinuz # wget http://ftp.riken.jp/Linux/fedora/releases/17/Fedora/x86_64/os/images/pxeboot/initrd.img
あと pxelinux の設定ファイルは
# cat pxelinux.cfg/default
prompt
label fedora
kernel vmlinuz
append load initrd=initrd.img devfs=nomount method=http://ftp.riken.jp/Linux/fedora/releases/17/Fedora/x86_64/os/
などとした。 ISO を http で供給する方法だとローカルのディスクサイズが足りなくて、 NFS でなんかする方法はうまくいかなくてあきらめたんだけど、今にして思うとたぶん squashfs.img をマウントしたものを見せるべきだったんだろうな…
(03:17)
コレを考える。 やりやすい形だと思うけど、なんか自由度がありすぎてたまに混乱するので…
C がたくさん来たら普通に新GTRに。 赤の先はこういう<形にしないと苦しい気がする
B がたくさん来たら左を伸ばすと新GTRと、勝手に momoken 積みと呼んでる同色系の両天秤。
B の後に A もたくさん来た時がカニばさみなのかなあ
カニばさみって形も先折りになる気がするんだけど、あんまうまい人がやってるのを見たことない気がするよな…
DD が来たら左端に立てるので良い気がする。最初の形の新GTRにもなるし、 D を先に消す新 GTR にもなるし。
DDCD でペルシャとかにするとかっこいいんだろうか…ホントかな…
まあなんか選択肢多い形だな
(12:13)
http://gihyo.jp/admin/clip/01/linux_dt/201212/28
via https://twitter.com/kazuho/status/285042604670861314
ioctl で ENOENT は man にも無いしいかにもよろしくなりそうな感じだけどカーネルよくわからんから知らない。もうファイル開いてるのにオカしいでしょ、ってのはわかるんだけど、こないだ sysctl が ENOTDIR 返すって知ってびっくりしたんだよな… sysfs 的なものの ENOTDIR て感じなのかな。
こんなコードで
#define _GNU_SOURCE
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <linux/sysctl.h>
int _sysctl(struct __sysctl_args *args);
int main() {
struct __sysctl_args args;
memset(&args, 0, sizeof(args));
int name[] = { 999, 999 };
args.name = name;
args.nlen = sizeof(name) / sizeof(name[0]);
syscall(SYS__sysctl, &args);
perror("_sysctl");
return 0;
}
Not a directory と言われてびびる。しかし今 64bit でやってみたら ENOSYS だ。おかしいなまあ深追いはいいや…
で、後のフォローアップによると ENOENT は userland に返すつもりじゃなくて、内部コードとして使ってただけのつもりだった、みたいなことを言ってる。それならまあだいぶ許せる気がする。まあでもたぶん返しちゃってたぽいし、スジ悪そうではある。
ところで、平謝りしてるメンテナのメールもスレッドに見当たらないし、メンテナの地位がどうこうという話も見ないんだけど
(01:29)
http://gihyo.jp/admin/clip/01/linux_dt/201206/18
ついでにこっちも見た。おもしろいな。
youtube の方はその後で一応他の会社も完璧てわけじゃないよってフォローした後の、みんな僕みたいにいい人ばっかりならいいのにとか、まあ気がきいてる感じだなぁとか
なんか git の話聞いた時も思ったけど話がうまいんだろうな…
(01:45)
| 前 | 2012年 12月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ Axel [Cool :-) Strom und Gas Vergleich auf [[https://www.nostro..]