ToDo:
http://d.hatena.ne.jp/higepon/20070804/1186241590
#include <stdio.h>
int is_tail_opt() {
return __builtin_return_address(1) != __builtin_return_address(2);
}
int fact(int x) {
printf("%s\n", is_tail_opt() ? "tail opt" : "not opt");
return x == 1 ? 1 : fact(x-1) * x;
}
int main() {
printf("%d\n", fact(5));
}
超いいかげんにこんなんを考えた。
i@um ~/test> gcc -O2 tail_opt.c i@um ~/test> ./a.out tail opt tail opt tail opt tail opt tail opt 120 i@um ~/test> gcc tail_opt.c i@um ~/test> ./a.out tail opt tail opt not opt not opt not opt 120
どのへんがいいかげんかというと、全部 tail opt って出れば最適化されてて、ひとつでも not opt って出れば最適化されてない、っていうあやしげな判断を人間がしなければならないところ。
(00:54)
荒らすぞ! という心意気とかそのへんを胸に秘めて帰宅したのだけど、 お題が難しすぎるよ…
JPEG を取得して色反転だなんて、 僕の好きな(荒らすのに適切な)言語ではできそうもない。
(01:01)
http://d.hatena.ne.jp/niha/20070802#1186070742
いや C もだけど、 初心者の敵度で言うと Unix のたいがいさはたいがいだろうなぁ。 pipe とか select とか。 あと sigpipe とかですか。 wait 忘れるとか。
未だになんも見ずにデーモン作れないよ。
(01:13)
とりあえず SIGINT ほってから しばらくして止まってなかったら諦めて SIGKILL とかどうするのとか。
いや普通にできるのかもしれんけど、 ゴルフ場でうまいこと実装できんかった気がする。
(01:16)
古いものはこうまぁ色々ほころんでるから 老害とか言うんは簡単で実際そいう側面はまぁ強いのはいいとして。
まぁよりベターなものを生む礎になれば良いのじゃー というのはあるんだろうけど、 そのわりには POSIX API をちゃんとラップするような ライブラリってあんま無いよな的な。
いやあるんだけどな。 libruby とかそういうヤツ。
(01:28)
Java puzzlers はそいう論調で Java を擁護するのだよな。 曰く、色々クソな点はたしかにあるけど、 そのクソな点が十分研究されて発見されてるのは 十分に受け入れられて吟味されているからだし、 Java は比較的クソな点が少ないからこそ受け入れられたのじゃとかなんとか。
同じ論理が C に適用された時、僕は C を許すのだけど、 Java はこう許せないのだよな。 Java ってほころびるほど古い言語じゃないじゃん。 もうちょいなんか検討しとけよ、とか。
short x = 0; int i = 123456; x = x + i; // コンパイルエラー x += i; // 無問題
とか見てると何がしたかったの君、的な。
(01:38)
http://d.hatena.ne.jp/soutaro/20070803/1186130441
あー別スレッドから殺すのいいですね。
現状のゴルフ場見てみた。
`pgrep -P #{pid}`.each do |l|
puts "kill #{l}"
Process.kill(:KILL, l.to_i) rescue puts "already died? #{l}"
end
puts "kill #{pid}"
# Process::kill(:INT, pid)
Process::kill(:KILL, pid) rescue puts "already died? #{pid}"
Process::wait(pid)
SIGINT の後はなんか色々試した記憶はあるけど なんかそのへんのコードは今は全く残ってないみたいだ。
(21:52)
と X がこうアプリから独立してていいことは CPU に負荷かかっててもウィンドウスイッチはできるというような。
で OSX で window switch してると 負荷かかってる時は反応が遅れて来て困る。 んで、 Quick silver から fork => Apple event 送る => Apple event に返事、 のたぶん最後の部分に時間かかってるんじゃないかなと 思ってたんだけど、 本当にそうなのか確認する価値はある、 っていうのと やっぱコアの部分は CGS 系でやれるといいのかなとか。
ああそうか、負荷がかかってるアプリへの情報問い合わせに時間かかるのか。 なら前回値記憶しておいてタイムアウトしたらそっち使うようにすればいいか。
(02:51)
師匠が書いてた文章読み飛ばしてたなーと思って読んだ
http://morihyphen.hp.infoseek.co.jp/log2/200707.html#2007-07-22
ら、前ざっと見た時と同じ疑問が生まれてきたんだけど、 最後に
と思ったけど、これって最初にサイズ調べておくのとどう違うの？
書いてあった。
興味あるのは今の環境だとどっちが速いのかなぁということかな。 なんか realloc の方が速いくらいなんじゃないかとか思うけど、 なんとなく realloc がイヤなのは激しく同感で、 C++ とか realloc を隠して罪悪感を隠蔽してくれるのはすばらしい。
カプセル化ってのは罪悪感を encap なんとか (←なぜかつづれない)していると言ってよい。
#include <stdlib.h>
#include <time.h>
#include <set>
#include <vector>
using namespace std;
int main() {
set<int> m;
for (int i = 0; i < 10000; i++) {
for (int j = 0; j < 100; j++) {
m.insert(rand());
}
}
vector<int> v;
clock_t s = clock();
for (int i = 0; i < 10; i++) {
//copy(m.begin(), m.end(), back_inserter(v));
v.resize(m.size());
copy(m.begin(), m.end(), v.begin());
}
printf("%f\n", 1.0 * (clock()-s) / CLOCKS_PER_SEC);
}
とかだと前者 1.6 秒後者 1.3 秒か。 set::size は O(1) でできちゃうので まぁ realloc があると少しはパフォーマンスに影響するってことだろう。
えーとつまりツリー構造にはサイズを保持しとくっていう結論に。
いや個々の要素の長さが固定で 1 だからっていうような話もあるけど まぁそれも中身の長さの総量を記録しておけばいいのだけど まぁそれも pretty print とかのためにそんな情報残しておくわけがない。
にしてもまぁ 100万回もランダム生成して木構造につっこんでバランスツリー調整して、 その100万要素のツリーを10回もなめつつ1000万要素のvectorを 文句も言わず作ってくれるコンピュータさんはえらいと思う。
俺はこういう偉い人に対して 「お前のようなヤツがいるから他の子への仕事の要求が上がるんだよ!」 とか言ってるわけで、 まぁなかなかむずかしいところ。
(01:40)
http://shinh.skr.jp/m/?date=20070730#c03
まぁめどいのでとりあえずさっきのコードを Linux on Celeron 1.7GHz で。
size を外部に持つずるいヤツが 4.37 秒で、 realloc しまくるヤツが 5.15 秒で、 最初に数えとくやつが 8.57 秒。
さっきの Core2Duo とかよりキャッシュの乗り方とか 悪かったりすると変わるかなーと思ったんだけどだいたい似たような割合やね。
さっきのはまとめると 1.3秒 1.6秒 2.6秒 。
直感的に同じメモリに対して realloc 繰り返すのは 速そう(だしなんか速いと聞いた気もする) んだけどそれにしても、直感的に差がありすぎてうさんくさい。
まぁカンばっかりなのでまた今度。
(21:57)
やっぱりそうなのか!
http://arena.nikkeibp.co.jp/article/column/20070607/1000581/?P=2
Windows XPと同じように、Windows Vistaも使い込むと遅くて重くなる。特に、
で、それなんでなの。というのが長年の疑問。
95系みたいに使い込むと不安定になるとかよりはマシなのかもしれないけど。
(22:02)
_ wo [「罪悪感をencap なんとか」、いい言葉ですね。僕も今後使っていきます。（使う場面無いですが） 「最初にサイズ調..]
_ Ozy [「通常」って書いてしまうと、きっと良くないですね…。書き直したほうがいいような気がしてきました。]
_ shinh [あ、はい先に長さだけ記録して行く、ってのはわかってたんですが、とりあえず malloc*1 と realloc*lo..]
_ wo [うえー。数えるよりreallocするほうがだいぶ速い、というのは結構意外ですね。ちゃんとベンチマークしましょう。> ..]
_ shinh [意外というより正直うさんくさいと思ったので自前の tree でもうちょい確実に比較してみた方が良さげですね。]
http://blog.livedoor.jp/dankogai/archives/50881558.html
よくわからんけど、なんでその二択しかないんだよという。
だらだら闘争しつつだらだらしたいんだけど。 あとだらだらしたい。
あとオリジナルの jkondo さんのよりはるかに dankogai さんの方が気にいらないのはたぶん、 jkondo さんのは仕事好きなら好きにすりゃいいじゃんと思ったけど dankogai さんのは若者よ働けチックだったからかな。
(14:14)
何度か書いてる気もするけど、 仕事好きなら好きにすりゃいいじゃん てのも雇用側なら好きにすればいいんだけど、 働く側に極端にマジメに働く子がいると あいつが頑張ってるんだからお前も頑張れ的な 暗黙の強制が生まれてよろしくないという話が。
勝手に頑張って勝手にたくさん稼ぐだけなら無問題なんだけど、 他の子の時給落としちゃうのよね、 という。
この話か。
http://d.hatena.ne.jp/sumii/20060731/1154301189
(23:28)
http://two-wugs.net/emacs/mode-tutorial.html
hmhm
(23:57)
http://www.rubyist.net/~matz/20070713.html#p01
それ3つとも「Prologぽいから」じゃないのだろうかと思った。
(01:59)
x += 'IIPIP' + asnat(l) + 'IIFIIF' + 'IFPP' + protect(c) + 'IFPPIIF' + 'C' * (i-2)
とかでいいだろアホー、と思った。
が
おそろしいことに protect が実装できない、というか 試しにやってみても 6000B くらいしか縮まん。 まぁそんなもんか && そんだけ縮んだら十分か
(01:31)
| 前 | 2024年 11月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ ひげぽん [>__builtin_return_address(1) おお。知らなかった。]
_ nonovesyvet [Swimming and playing in the pool is preferably oddziajwujケ..]