トップ «前月 最新 翌月» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

ToDo:


2012-12-01

_ ぷよぷよS級

今にはじまったことじゃないけど、やばいなー

http://www.nicovideo.jp/watch/sm19420263

なんか A 級はチラチラ見てる感じ、参考になるなーと思う時が結構あるんだけど、 S 級は理解を越えてる。

なんでそんなことするん? って思っちゃう置き方がちらほらあるのは、ちぎりとか考えてる感じなんかなぁ

(00:23)


2012-12-04

_ 2^n に切り上げ

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)


2012-12-05

_ ゴルフ

http://codeiq.hatenablog.com/entry/2012/12/03/234209

うーん。1位がたくさん出るってのはゴルフの問題としてはどうでもよかった、ってことなんだけどな。

同着の人がみんな僕のコードと似たような形のコードだとすると、ここまではまあテクニックといくらかの時間だけで書けるコードで、アルゴリズムはわりと自明な感じだった、ってことなので。

もうちょいいい問題だと、アルゴリズム的な転回とテクニックのバランスが色々でてきて、まぁそこが面白くて難しくて時間が無駄に消費される部分だと思うんだけど。

というわけでこの問題を面白かったことにできんもんかと、なんとか削れんもんかなーとたまに眺めるもののキツい。

(03:11)


2012-12-08

_ intel のなんか

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 への敵対心というか、まぁ普通に考えて不利な立場だからか、かなり攻撃的な感じだった。内容は

  • たしかにピーク性能は少し負けている
  • ただ 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)

_ ruby w/ thread

http://jstorimer.com/2012/11/08/matz-is-not-a-threading-guy.html

via https://twitter.com/_ko1/status/277343915261169665

よくわかってないんだけど、 ruby に thread があったら何するんだろう。それはプロセスではダメなんだろうか

(19:15)

本日のツッコミ(全1件) [ツッコミを入れる]

_ Axel [Cool :-) Strom und Gas Vergleich auf [[https://www.nostro..]


2012-12-13

_ ffmpeg

コマンドメモ

絵をとる

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)


2012-12-16

_ android斑鳩

https://play.google.com/store/apps/details?id=com.ggee.vividruntime.game_ticket_1791

ムリムリ腕いたい…

ラフレシア前後半の間と長元坊だけは相変わらず稼ぎ所だった。処理落ちしまくってるせいで音楽が全然あってないのが残念ですね…

(01:06)

_ フカシギな数え方

https://www.youtube.com/watch?v=ge8vy4tc_kQ

で、これどういうアルゴリズムで早く計算できるんだろう…

(19:42)

本日のツッコミ(全3件) [ツッコミを入れる]

_ yt [2x2であれば、水平移動量[+1,+1]、[+1,-1,+1,+1]、[+1,+1,-1,+1]、[+1,+1,-1..]

_ bero [一時ソース http://www.miraikan.jst.go.jp/info/120720157189.htm..]

_ shinh [ありがとうございます。適当にぐぐって見つけた http://d.hatena.ne.jp/nowokay/20..]


2012-12-21

_ kernel ビルド

実にひさびさに kernel をビルドした。というのは買ったUSBキャプチャ装置が動かなくて、僕はドライバってやつは型番を配列に足してやればだいたい動くもんだという認識があるので、適当に足しみたのだった。

適当にやると音はなんか鳴るようになって、でも絵がうまくいかなかった。 lsusb -v や windows でのドライバ名とかを見るに、なにやらチップの世代が違うらしく、ああこれはちゃんと調べて書かないと無理ぽいな…という結論になって、諦めた。

いいかげんな認識をあらためるべき

(03:04)

_ 左右判定

http://sakidatsumono.ifdef.jp/draft3.html

をやってみて、まあそのへんだろうなあという位置に来て面白かった。

政治的な右・左度(保守・リベラル度) -4.6 経済的な右・左度(市場信頼派・政府介入派) -2.59

(03:06)


2012-12-23

_ Write in C

http://www.youtube.com/watch?v=1S1fISh-pag

面白すぎるな…

(10:40)


2012-12-25

_ 青が出ないバグ

昨日ふと困ったバグは少しおもしろかった。バグ自体はなんてことないものなんだけど。 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 で浮動小数に or する

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)

_ pxe boot

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)

_ ミク小説

http://www.amazon.co.jp/gp/product/4758043566/

とかあるのかー

(09:35)


2012-12-28

_ AAABBBBC 的平積み

http://bit.ly/UwMNx1

コレを考える。 やりやすい形だと思うけど、なんか自由度がありすぎてたまに混乱するので…

C がたくさん来たら普通に新GTRに。 赤の先はこういう<形にしないと苦しい気がする

http://bit.ly/UwN9E4

B がたくさん来たら左を伸ばすと新GTRと、勝手に momoken 積みと呼んでる同色系の両天秤。

http://bit.ly/V85Nj4

B の後に A もたくさん来た時がカニばさみなのかなあ

http://bit.ly/UwNGpy

カニばさみって形も先折りになる気がするんだけど、あんまうまい人がやってるのを見たことない気がするよな…

http://bit.ly/UwNN4o

DD が来たら左端に立てるので良い気がする。最初の形の新GTRにもなるし、 D を先に消す新 GTR にもなるし。

DDCD でペルシャとかにするとかっこいいんだろうか…ホントかな…

http://bit.ly/UwOjiK

まあなんか選択肢多い形だな

(12:13)


2012-12-30

_ linus かっこいいなー

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)

_ linus リンク

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
1.Axel(2021-01-20 01:50) 2.shinh(2012-12-21 03:18) 3.bero(2012-12-17 02:55)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h