ToDo:
師匠が書いてた文章読み飛ばしてたなーと思って読んだ
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)
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)
http://www.kmonos.net/wlog/75.html#_2341070724
原因は rope 側にあると躊躇無く決めつけてデバッグすることができました。
これ言いたい!
(01:48)
画像公開は実質点数公開だと思うんだけど、 いいのかな。
って俺こそ書いて良かったんだろうか。 まぁ明らかに勝ってないし、 こう早く「ゴメン俺まともにゲームやってない!!」と言いたかったし。
あーでもなんか俺だけ明らかにおかしい点数の増えかたしてたと思うんだけど、 なんか案外まともじゃない方法だとは気付かれなかったらしいので、 完全に黙秘して「あーアセンブラ？それそれ、俺それで解いたお!!」 とか言ってたら立派な功績になったかもしれない。
でもそれじゃネタにならない
(13:52)
基本的に mk_prefix.rb は可能な限り抽象化せずに書いて、 細かい最適化の可能性を意識できるようにしてたんだけど、 まぁあんまり意味なかったかもしれない。
それはそうと、
goto[0,0] chdir[:E] goto[150,150]
なんかの3つ目は、
strong_compress(MOVE,150) cw[] strong_compress(MOVE,150)
とかに展開されるはずだけど、
strong_compress(MOVE+CW+MOVE+CCW,150)
の方が短いに決まっている。 あと色の指定とかも甘すぎた。 前回の bucket を有効利用できるシーンとかも あったはずだし。
このへん時間があればちゃんとやりたかったけど、 どうせ10000くらいしか点数変わらんし それなら細かいとこ埋めた方が良いのであった。
(14:09)
via http://d.hatena.ne.jp/uskz/20070724/p1
http://hpcgi1.nifty.com/MADIA/Vcbbs/wwwlng.cgi?print+200707/07070029.txt
おもしろいなぁ。
この手の fj 文化的(なのかは知らんけど)はまだ生きてるんだなぁと。
まぁ質問者がアレなのはいいとして、 回答者もアレに見える理由を少し考えてみた。
途中にあった「説明が趣味」っていうのはわかりやすいな。 説明が趣味な連中はブログに説明を書くようになったのもあって ML が死にたえたりこの手の伝統的なやりとりを見る量が減ってきたのかもしれない。
でなんというか、このログ見てる限りでは、 途中から明らかに答えだけが知りたいような雰囲気の子だから、 どう考えてもスルーするか答えだけポンと投げるか以外だと お互い不幸になるっていうか少なくとも 説明しても相手は喜ばないし何も学ばないのは自明に見える。
でもわざわざ説明を喜ばない相手に説明するってのは、 こいう教えて君死ね文化の再生成とかそんなことのためなのかもしれないなぁとか。
(10:51)
http://kzk9.net/blog/2007/07/icfp_2007.html
ノイズが大変だと言及してくださってうれしかった。 僕もみなさんの 1/1000 くらいは頭使ったんだ!!
それはそうと画像調べるに Risk は僕の半分強か。 なるほどなぁ。
(11:24)
最後の最後でっ…!
http://b.hatena.ne.jp/entrylist?sort=eid&url=http%3A%2F%2Fshinh.skr.jp%2F
僕のはてぶパラパラマンガがっ…!
この2日間アンテナも回さなかったのが敗因!
(14:55)
The current top 20 (in random order) Team icfp_onlooker shinh just me ProactiveApathy Optimistic Lambda Lover fix error internetsdotorg camelimelo Warlords Frodnix Bloody Camls Gathering Gleegers The Church of the Least Fixed Point seversk Moliere Vaincra! Rhinos Red Hot Curry Peppers Pretend Robot Pants Side Effects May Include...
入りますた記念パピコ
(03:16)
| 前 | 2025年 9月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ wo [「罪悪感をencap なんとか」、いい言葉ですね。僕も今後使っていきます。（使う場面無いですが） 「最初にサイズ調..]
_ Ozy [「通常」って書いてしまうと、きっと良くないですね…。書き直したほうがいいような気がしてきました。]
_ shinh [あ、はい先に長さだけ記録して行く、ってのはわかってたんですが、とりあえず malloc*1 と realloc*lo..]
_ wo [うえー。数えるよりreallocするほうがだいぶ速い、というのは結構意外ですね。ちゃんとベンチマークしましょう。> ..]
_ shinh [意外というより正直うさんくさいと思ったので自前の tree でもうちょい確実に比較してみた方が良さげですね。]