00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:04:55  * paddybyersquit (Ping timeout: 256 seconds)
00:15:35  * AvianFlujoined
00:16:32  * c4miloquit (Remote host closed the connection)
00:17:58  * c4milo_quit (Remote host closed the connection)
00:20:13  * mikealquit (Read error: Connection reset by peer)
00:24:05  * mikealjoined
00:25:11  * mikealquit (Client Quit)
00:30:55  * karupaneruraquit (Excess Flood)
00:31:42  * qmx|awaychanged nick to qmx
00:32:17  * qmxquit (Changing host)
00:32:17  * qmxjoined
00:34:26  * karupanerurajoined
00:35:29  * jerickson__joined
00:35:30  * jerickson_quit (Read error: Connection reset by peer)
00:37:14  * pieternjoined
00:40:59  <bnoordhuis>man, ret insns cause massive pipeline stalls: 75.73 6f2758: c3 ret
00:41:35  <bnoordhuis>that's percentage of a single function
00:45:12  * brsonjoined
00:56:32  * pieternquit (Quit: pietern)
01:11:31  * indexzeroquit (Quit: indexzero)
01:20:46  * AvianFluquit (Remote host closed the connection)
01:25:22  <isaacs>bnoordhuis: neat. thanks for the heads up.
01:25:30  <isaacs>bnoordhuis: backporting a patch would be fine
01:26:07  * rumpjoined
01:26:22  * rumppart
01:27:43  <bnoordhuis>- 1.34% node perf-9795.map [.] LoadIC:A load IC from the snapshot ▒
01:27:47  <bnoordhuis> - LoadIC:A load IC from the snapshot ▒
01:27:51  <bnoordhuis> + 12.28% Builtin:A builtin from the snapshot ▒
01:27:55  <bnoordhuis> + 10.75% Builtin:A builtin from the snapshot ▒
01:27:59  <bnoordhuis> + 10.75% Builtin:A builtin from the snapshot ▒
01:28:03  <bnoordhuis> + 10.75% LazyCompile:*Stream stream.js:42 ▒
01:28:07  <bnoordhuis> + 9.87% LazyCompile:*Readable.on _stream_readable.js:577 ▒
01:28:11  <bnoordhuis> + 6.58% Builtin:A builtin from the snapshot ▒
01:28:15  <bnoordhuis> + 4.82% LazyCompile:*exports.active timers.js:160 ▒
01:28:19  <bnoordhuis> + 3.95% LazyCompile:*OutgoingMessage.end http.js:787
01:28:21  * c4milojoined
01:28:22  <bnoordhuis>^ this is so awesome
01:28:24  <bnoordhuis>i instrumented v8 to make it create a perf.map file
01:28:38  <tjfontaine>nice
01:29:06  <tjfontaine>I also notice you have a very wide terminal at the moment :)
01:31:59  * c4miloquit (Remote host closed the connection)
01:41:14  <bnoordhuis>isaacs: so i have been benchmarking all the things
01:42:04  <bnoordhuis>particularly net-pipe.js
01:42:25  <bnoordhuis>the short of it is that the bindings layer and v8 have become faster
01:42:34  <bnoordhuis>the slowdown is all in js land
01:43:17  <isaacs>bnoordhuis: hm. ok.
01:43:27  <isaacs>bnoordhuis: how come http.sh is faster with v0.8 than with streams1?
01:43:38  <isaacs>that seems to contradict the "all in js land" theory
01:43:47  <isaacs>i gotta run.
01:43:48  <bnoordhuis>i haven't looked at that yet, just net-pipe.js
01:44:03  <bnoordhuis>but that one i have studied in microscopic detail :)
01:44:18  <isaacs>bnoordhuis: https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc#gid=1
01:44:30  <isaacs>bnoordhuis: could be http_parser is to blame, then?
01:44:43  <isaacs>net-pipe is indeed likely to be affected by js more than http.sh
01:45:03  <isaacs>ok, i have to go get dinner now or i'll be in trouble. good evening :)
01:45:05  * isaacs&
01:45:06  <LOUDBOT>I'M GONNA POUR A BEER IN MY PUSSY SO THAT I'LL GET A YEAST INFECTION!
01:45:10  <bnoordhuis>bon appetite :)
01:57:32  * c4milojoined
02:37:44  * EhevuTovjoined
02:41:03  * bnoordhuisquit (Ping timeout: 244 seconds)
02:41:16  * hzquit
02:42:01  * abraxasjoined
02:44:09  * AvianFlujoined
02:45:51  * jerickson__quit (Ping timeout: 245 seconds)
02:53:59  * mikealjoined
02:55:03  * mikealquit (Client Quit)
03:07:37  * c4miloquit (Remote host closed the connection)
03:31:42  * trevnorrisjoined
03:40:24  <trevnorris>anyone home?
03:41:38  * brsonquit (Ping timeout: 255 seconds)
03:53:24  * indexzerojoined
04:23:22  * AvianFluquit (Remote host closed the connection)
04:34:55  * mikealjoined
04:40:15  * brsonjoined
04:42:27  * mikealquit (Quit: Leaving.)
05:42:28  * snojjoined
05:48:13  * snojquit (Ping timeout: 246 seconds)
05:50:35  * pfox__joined
05:50:42  <pfox__>any maintainers awake?
06:08:47  * mikealjoined
06:12:29  * mikealquit (Client Quit)
06:16:14  * mikealjoined
06:16:32  * mikealquit (Client Quit)
06:18:21  * bradleymeckjoined
06:21:25  * trevnorrisquit (Quit: Leaving)
06:28:01  * mikealjoined
06:32:38  * qmxquit (Ping timeout: 256 seconds)
06:35:37  * brsonquit (Quit: leaving)
06:35:51  * brsonjoined
06:38:57  * indexzeroquit (Quit: indexzero)
06:39:17  * paddybyersjoined
06:46:19  * qmx|awayjoined
06:49:07  <indutny>yes
06:49:14  <indutny>morning
06:50:22  <indutny>pfox__: sup?
07:02:35  * indexzerojoined
07:06:16  * brsonquit (Ping timeout: 245 seconds)
07:06:52  * brsonjoined
07:25:12  * felixgejoined
07:25:12  * felixgequit (Changing host)
07:25:12  * felixgejoined
07:28:42  * Raltquit (Ping timeout: 276 seconds)
07:29:42  * felixgequit (Ping timeout: 252 seconds)
07:31:24  * paddybyersquit (Ping timeout: 260 seconds)
07:37:41  * EhevuTovquit (Quit: This computer has gone to sleep)
07:38:07  * paddybyersjoined
07:41:13  * felixgejoined
07:45:22  * brsonquit (Ping timeout: 244 seconds)
07:46:23  * rendarjoined
07:47:34  * `3rdEdenjoined
08:05:02  * `3rdEdenquit (Remote host closed the connection)
08:09:59  * EhevuTovjoined
08:22:46  * indexzeroquit (Quit: indexzero)
08:23:26  * indexzerojoined
08:25:18  * indexzeroquit (Client Quit)
08:40:08  * qmx|awaychanged nick to qmx
08:49:39  * qmxchanged nick to qmx|away
08:55:23  * EhevuTovquit (Quit: This computer has gone to sleep)
08:58:59  * paddybyers_joined
09:02:57  * paddybyersquit (Ping timeout: 276 seconds)
09:02:57  * paddybyers_changed nick to paddybyers
09:11:07  * googolquit (Remote host closed the connection)
09:29:16  <saghul>hello
09:29:50  <saghul>which of the uv_loop_t fields are supposed to be private? all but data?
09:46:15  * stagasjoined
09:52:00  * `3rdEdenjoined
10:08:33  * Raltjoined
10:20:31  * loladiroquit (Quit: loladiro)
10:30:32  * abraxasquit (Remote host closed the connection)
11:04:07  <indutny>hello
11:15:15  * bnoordhuisjoined
11:15:17  <stagas>hi indutny
11:15:23  <indutny>bnoordhuis: hey man
11:15:25  <indutny>stagas: hi
11:15:33  <bnoordhuis>indutny: ho man
11:16:03  <indutny>bnoordhuis: lets fix da awful bugs https://github.com/joyent/node/pull/4671
11:16:30  <bnoordhuis>indutny: but only if they come with regression tests :)
11:16:35  <indutny>oh noes
11:16:49  <indutny>btw
11:16:53  <indutny>I've been at notary office today
11:17:01  <indutny>they're very rich in Moscow
11:17:09  <indutny>whole office in wood and leather
11:17:17  <indutny>big tables and everything like this
11:17:18  <indutny>and also
11:17:25  <indutny>there was radio
11:17:33  <indutny>and song from Pulp Fiction
11:18:25  <bnoordhuis>being a notary is a sweet job
11:18:42  <bnoordhuis>all you do is copy/paste word documents all day
11:18:48  <bnoordhuis>but you charge outrageous rates
11:19:05  <indutny>well, rates are not that big
11:19:11  <indutny>they've different source of money
11:19:14  <indutny>at least, in russia
11:19:27  <bnoordhuis>oh dear, what source?
11:19:44  <indutny>I suppose that furniture in their office costs ~ 1m$
11:19:55  <indutny>probably less, but something around it
11:20:04  <indutny>bnoordhuis: you better not ask
11:24:27  <rendar>indutny: is russia so corrupted?
11:25:33  <indutny>yeah, some parts are
11:25:39  <indutny>mostly related to business
11:25:43  <rendar>also here in italy
11:26:02  <indutny>well, I think we're on the same level here
11:26:05  <rendar>now i see why berlusconi and putin are so close friends, lol
11:26:10  <indutny>haha
11:26:11  <indutny>yeah
11:32:52  <indutny>bnoordhuis: interesting thing
11:33:02  <indutny>bnoordhuis: if I'll use net.Server - that thing is not reproducible...
11:33:13  <indutny>if I'll remove net.Server code - it'll appear again
11:33:14  <indutny>hm...
11:36:42  * creationixquit (Ping timeout: 264 seconds)
11:38:53  * creationixjoined
11:43:59  <MI6>joyent/node: Ben Noordhuis master * a39f669 : test: move simple/test-http-dns-fail to test/internet The test times out - http://git.io/joMEIA
11:49:31  <indutny>bnoordhuis: ok, figured it out
11:49:51  <indutny>bnoordhuis: enjoy https://github.com/joyent/node/pull/4671
11:49:51  <indutny>;)
11:50:00  * hzjoined
11:55:56  <saghul>I'll ask again, since there are more people here now :-) which of the uv_loop_t fields are supposed to be private? all but data?
11:56:48  <indutny>I think all that're visible in uv.h
11:56:55  <indutny>but yeah, data is the only one that makes sense
11:57:00  <indutny>for external use
11:57:16  <saghul>I don't think one is supposed to touch the handle_queue
11:57:18  <saghul>xD
11:57:50  <saghul>the one I'm interested in is active_handles, more precisely
11:58:08  <saghul>not interested, but wondering about, more precisely
12:11:27  <indutny>bnoordhuis: so, hm... lgtm?
12:11:31  <indutny>s/lgtm/lgty/
12:12:27  * mmalecki[fly]changed nick to mmalecki
12:21:25  * qmx|awaychanged nick to qmx
12:21:34  <bnoordhuis>saghul: only data, active_handles and active_reqs may change
12:21:38  * qmxquit (Changing host)
12:21:39  * qmxjoined
12:21:51  <indutny>bnoordhuis: may be move them to PRIVATE_FIELDS then?
12:22:06  <bnoordhuis>yes, maybe
12:22:16  <bnoordhuis>also, we could presumably add api functions for them
12:22:23  <indutny>active handles?
12:22:27  <indutny>I thought we have one
12:22:36  <bnoordhuis>we do, active_handles
12:22:44  <indutny>uv_walk
12:22:49  <bnoordhuis>oh, like that
12:22:51  <indutny>I mean API
12:23:15  <bnoordhuis>yes, that's true. we don't have one for reqs though
12:23:32  <indutny>well
12:23:40  <bnoordhuis>also, uv_walk is kind of overkill if all you want to know is the # of active handles
12:23:49  <indutny>agree
12:27:30  <indutny>bnoordhuis: do you have a minute?
12:27:38  <indutny>for this https://github.com/joyent/node/pull/4671
12:27:40  <bnoordhuis>indutny: 60, 59, 58...
12:28:51  <bnoordhuis>indutny: why the setTimeout in the test?
12:29:08  <indutny>because I want child to receive handle
12:29:14  <indutny>and do not want to synchronize
12:29:17  <indutny>:)
12:29:20  <indutny>too lazy for it
12:30:42  <bnoordhuis>so instead you're opting for timing sensitive tests?
12:31:03  <indutny>ok
12:31:06  <indutny>I'll do it
12:31:08  <indutny>just for you
12:31:10  <bnoordhuis>good :)
12:31:21  <bnoordhuis>but not just for me, for all the people coming after you
12:31:39  <bnoordhuis>the process.exit shouldn't be necessary, should it?
12:31:59  <bnoordhuis>the worker should exit automatically once the server is stopped
12:32:02  * sgallaghjoined
12:32:25  <bnoordhuis>apart from that, lgtm
12:32:29  <indutny>great
12:32:34  <indutny>bnoordhuis: no, it won't exit
12:32:40  <indutny>bnoordhuis: believe me :)
12:32:41  <bnoordhuis>no? why not
12:32:49  <indutny>probably because I'm using child_process.fork
12:32:52  <bnoordhuis>seems to work for me
12:32:55  <indutny>not cluster.fork()
12:33:02  <indutny>bnoordhuis: even when master crashes?
12:33:17  <indutny>test it on non-patched node
12:33:53  <bnoordhuis>well, duh - the idea is to fix that, right? :)
12:34:13  <bnoordhuis>still, when the master process crashes, it takes the process group with it
12:34:23  <bnoordhuis>eind goed, al goed
12:35:24  <indutny>well
12:35:29  <indutny>can't confrim it
12:35:34  <indutny>s/confrim/confirm/
12:36:33  <saghul>bnoordhuis thanks for confirming
12:37:28  <MI6>joyent/node: Fedor Indutny master * 0d7a021 : net: initialize TCPWrap when receiving socket TCPWrap::Initialize() and - http://git.io/KOuLJQ
12:40:50  <indutny>bnoordhuis: so where are we now with performance testing?
12:40:54  <indutny>any new ideas? results?
12:41:13  <bnoordhuis>indutny: i bisected benchmark/net-pipe.js at the microscopic level
12:41:22  <indutny>and?
12:41:25  <bnoordhuis>and the conclusion there was that v8 and the binding layer have become faster
12:41:30  <indutny>oh
12:41:30  <bnoordhuis>the slowdown is pure js
12:41:36  <bnoordhuis>next up is http
12:41:37  <indutny>interesting
12:42:02  <indutny>you was running git bisect?
12:42:20  <indutny>or just resetting commits one by one and running benchmarks?
12:42:27  <bnoordhuis>ah no, bisect as in split into teensy weensy chunks and benchmark the crap out of that
12:42:45  <bnoordhuis>and check generated assembly, code stubs, etc.
12:42:45  <indutny>ah
12:42:53  <indutny>ok
12:42:59  <indutny>I think I may setup automatical script
12:43:10  <indutny>to check every commit since 0.8
12:43:15  * hzquit
12:43:16  <indutny>and graph performance
12:43:30  <bnoordhuis>you'll find at least one or two big dips
12:43:44  <bnoordhuis>where a certain person who shall rename unnamed forgot to reapply certain v8 patches :)
12:44:00  <bnoordhuis>but yeah, good idea
12:44:00  <indutny>ahha
12:44:08  <indutny>you blame me again
12:44:22  <bnoordhuis>no, i'm just teasing you
12:44:37  <bnoordhuis>and it's very fulfilling, i must say
12:45:19  <bnoordhuis>i got an email from a google recruiter saying she's interested in my combination of c++ and python skills
12:45:27  <bnoordhuis>what does she know about me that i don't?
12:47:23  <indutny>may be she's interested in you
12:57:19  * AvianFlujoined
13:04:41  <indutny>bnoordhuis: so what should sane person run in order to get one number representing benchmark result?
13:05:04  <bnoordhuis>indutny: depends on what you want to measure
13:05:09  <indutny>http rps
13:05:14  <indutny>for some response body
13:05:19  <indutny>doesn't matter much
13:05:24  <bnoordhuis>but trying to distill it into 'one number' is usually the wrong approach
13:05:30  <bnoordhuis>if nothing else, outliers will skew the result
13:06:04  <bnoordhuis>re http, run e.g. benchmark/http_simple_auto with -c 1000 -n 200000 bytes/1024
13:06:17  <bnoordhuis>compare the master and v0.8 results, see what needs improving
13:06:59  <indutny>ok
13:07:07  <indutny>lets see :)
13:11:04  <bnoordhuis>indutny: btw, when you're running benchmarks close everything that's non-essential
13:11:13  <bnoordhuis>i.e. browsers, media players, chat apps, etc.
13:11:19  <bnoordhuis>ssh sessions too
13:11:32  <indutny>bnoordhuis: I'll run them on server
13:11:38  <bnoordhuis>i have had more than one benchmark screwed up because ssh dediced to renegotiate the session
13:11:43  <indutny>aha
13:11:43  <bnoordhuis>*decided
13:16:04  <indutny>apr_socket_connect(): Connection refused (146)
13:16:04  <indutny>Total of 8532 requests completed
13:16:04  <indutny>oh
13:16:12  <indutny>smartos, please no
13:18:23  <indutny>I guess I'll need sane server for his
13:18:26  <indutny>s/his/this/
13:21:55  * piscisaureus_joined
13:25:16  <indutny>ah, obviously problem was with -c 1000
13:25:18  <indutny>that's too much
13:28:58  <indutny>bnoordhuis: for future generations and you https://gist.github.com/4655489
13:29:23  * snojjoined
13:33:00  <bnoordhuis>indutny: hah, i would've done that in a couple of lines of shell
13:33:21  <indutny>yes, but what for? :)
13:33:41  <indutny>bnoordhuis: btw, can you run it on your box?
13:33:43  <indutny>or anywhere else
13:33:49  <bnoordhuis>yes, but not now
13:37:19  <bnoordhuis>indutny: btw, https://github.com/bnoordhuis/node/compare/perf-map - if/when you're profiling with perf
13:37:38  <bnoordhuis>it creates a map file that lets perf map generated code to symbolic names
13:37:51  <indutny>kewl
13:38:15  <bnoordhuis>the one downside is that the map format doesn't let you specify code moves/deletions
13:38:16  * jmar777joined
13:38:35  <bnoordhuis>you might get somewhat skewed numbers but it doesn't seem to be a big issue so far
13:38:45  <bnoordhuis>v8 doesn't move/delete that often
13:39:07  <bnoordhuis>still, i've sent an email to the perf maintainers asking if they're interested in a patch
13:50:02  * Guest__joined
13:50:45  <indutny>yeah
13:50:54  <indutny>it's pretty cool thing that v8 removes dead code, though
13:51:06  <indutny>btw, I was thinking about one interesting thing
13:51:27  <indutny>what if VM's stack might be placed inside heap
13:51:32  <indutny>well, it might be non-movable
13:51:45  <indutny>and not really GCed, since parts of it die rarely
13:51:58  <indutny>but you'll get much deeper recursion
13:52:05  <indutny>only limited with your memory
13:53:44  * felixgequit (Ping timeout: 255 seconds)
13:54:19  * felixgejoined
13:54:19  * felixgequit (Changing host)
13:54:19  * felixgejoined
14:06:32  * snojquit (Quit: Leaving)
14:24:38  * bradleymeckquit (Quit: bradleymeck)
14:26:15  * c4milojoined
14:31:56  * AvianFluquit
14:39:02  <piscisaureus_>hmm
14:39:29  <piscisaureus_>when using cluster, how are tcp handles disconnected as workers disconnect themselves?
14:39:39  <piscisaureus_>I can tell it works, only I can't find the code that does it...
14:44:29  * c4miloquit (Remote host closed the connection)
14:49:17  <piscisaureus_>hmm something is off about udp handle reference counting I'm afraid
14:50:46  <cjd>just to take a straw poll, if I were to write a patch to make available the entropy collected in each call to uv_hrtime(), would it have a reasonable chance of getting pulled?
15:02:40  <piscisaureus_>cjd: ?
15:04:41  * loladirojoined
15:05:32  * loladiroquit (Client Quit)
15:05:34  <cjd>I am working on a random generator for my application and I need to supply it with a feed of entropy, I know node.js uses openssl so it's not needed for node but I don't want to pull in openssl.
15:06:34  <cjd>Just thinking of storing a uint64_t in the event loop and adding the current hrtime to it each time hrtime is called, then making it accessable
15:07:11  <cjd>And each time it's accessed, zeroing it so the reader can tell if no entropy has been collected since the last access
15:07:13  <saghul>cjd you could store that in loop->data
15:07:24  <saghul>ah, wait, no
15:07:34  <cjd>I'll need to modify hrtime() to feed it
15:16:59  * bradleymeckjoined
15:31:08  * c4milojoined
15:44:21  <piscisaureus_>cjd: ah - no that patch won't be taken
15:44:41  <cjd>ok
15:44:52  <piscisaureus_>cjd: I mean, that's *extremely* specific to your use case
15:45:08  <piscisaureus_>cjd: what you could do is add an uv_prepare_t or uv_idle_t and call uv_hrtime() from there
15:46:20  <cjd>/nod
15:51:20  * Guest__quit (Quit: ["Textual IRC Client: www.textualapp.com"])
15:52:34  <bnoordhuis>cjd: uv_hrtime() is not necessarily a great source of entropy
15:52:49  <bnoordhuis>if the system doesn't have high-res timers, you may be stuck with a granularity of e.g. 10 ms
15:53:59  <cjd>yeap, I'm using a 128 byte buffer and it's mixed 128 times before being introduced into the generator
15:54:16  <cjd>128 *bit
15:54:30  <cjd>so each sample is worth 1 bit
15:55:12  <cjd>I could also write a patch to node so it's added using RAND_add() :)
15:55:19  <cjd>same algorithm
15:57:15  <cjd>oops nope, 256 bit buffer.. so each sample == 2 bits of added entropy assuming I stick with the 128 number
15:57:50  <isaacs>good morning
15:57:50  * jmar777quit (Remote host closed the connection)
15:57:53  * isaacswaves
15:57:56  <cjd>gm
15:58:25  * jmar777joined
15:59:56  * jmar777_joined
15:59:59  * jmar777quit (Read error: Connection reset by peer)
16:00:21  * jmar777_quit (Remote host closed the connection)
16:00:57  * jmar777joined
16:01:49  * qmxchanged nick to qmx|lunch
16:03:54  * bradleymeckquit (Quit: bradleymeck)
16:05:16  * jmar777quit (Ping timeout: 246 seconds)
16:10:33  * `3rdEdenchanged nick to `3E|Cooking
16:13:03  * hzjoined
16:14:11  <pfox__>morning
16:14:18  <indutny>morning
16:14:28  <pfox__>so, i'm working on updating rust's libuv bindings, which are pretty ancient (witha few patches applied)
16:14:47  <pfox__>we have a patch, for android compatibility, that applies a bunch of changes against src/unix/eio and src/unix/ev
16:14:53  <pfox__>those dirs aren't in tree, anymore
16:14:57  <pfox__>and i don't see them in uv.gyp
16:15:09  <pfox__>are they still deps? are they taken as linked dependencies, or what?
16:15:22  <indutny>nope
16:15:27  <pfox__>they're gone?
16:15:27  <indutny>they were removed
16:15:29  <indutny>yes
16:15:29  <pfox__>nice.
16:15:36  <pfox__>ok, that makes my job easier :)
16:15:37  <indutny>yeah, can you show me your patches?
16:15:47  <pfox__>sure, one moment
16:16:07  <pfox__>https://github.com/graydon/libuv/commit/1d6aec9d54c7a684ade521f71a4d538a6a88b14f
16:16:12  <indutny>replacement code is completely new, but I'd like to be sure that your patches shoudn't be applied to fix any issues
16:16:13  <pfox__>and https://github.com/graydon/libuv/commit/4d392c86feb6389f550d8110d36fa90d66c09251
16:16:40  <pfox__>(i'm not graydon, btw.. going to do a pull req to this repo once complete though)
16:16:50  <pfox__>graydon/libuv is the submodule that rust builds against
16:17:05  <pfox__>my local work is in olsonjeffery/libuv branch libuv_update
16:17:10  <pfox__>i skipped those two commits in the rebase
16:17:16  <indutny>bnoordhuis: thoughts ^
16:17:20  <indutny>ok
16:17:26  <indutny>first question - does it work? :)
16:17:28  <indutny>on android
16:17:30  <pfox__>this is the one patch that i did apply, though
16:17:30  <pfox__>https://github.com/graydon/libuv/commit/1170ffba3ac5191930b40c897d4569a9d8a296a3
16:17:36  <bnoordhuis>pfox__: i noticed a while ago that rust has platform-specific code for mutexes, semaphores, etc.
16:17:47  <bnoordhuis>you may be able to replace those with the libuv ones
16:18:06  <pfox__>yeah. my hope-beyond-hope is that rust can build from a clean libuv tree
16:19:09  <pfox__>indutny: re: android.. i don't know, i was inactive in the project when this patch came ni and don't really understand the context
16:19:21  * bradleymeckjoined
16:19:22  <pfox__>brson, who'll probably be around later, could answer that question
16:19:23  <bnoordhuis>IPV6_HOPLIMIT <- that should probably become a #define in src/win/winapi.h
16:20:02  <bnoordhuis>pfox__: sony was working on porting libuv/node to android. they said they'd follow up with patches sometime in february
16:20:13  <bnoordhuis>in case you have build issues and don't want to look into it yourself :)
16:21:04  <pfox__>yeah. i can't speak for graydon or brson, but im not sure that android is actually a priority build target atm.
16:21:14  <pfox__>but ill file that away, for sure.
16:21:48  <indutny>great
16:21:51  <indutny>delegation of work :)
16:22:03  * `3E|Cookingquit (Remote host closed the connection)
16:23:00  <pfox__>anywho. it sounds like we're ok for now, re: eio and ev changes. i'll just move on to the next phase of my integration work. thanks for answering my questions.
16:32:51  * trevnorrisjoined
16:38:04  <trevnorris>isaacs: sup?
16:40:06  * dapjoined
16:41:02  <MI6>joyent/node: isaacs master * e26622b : stream: Correct Transform class backpressure The refactor in b43e544140c - http://git.io/kjgB7A
16:41:28  <isaacs>bnoordhuis: i'm going to dig into profiling the js in net-pipe
16:41:40  <trevnorris>isaacs: already there. been doing it all weekend. =)
16:41:43  <isaacs>bnoordhuis: can you turn your attention to the http_simple benchmarks?
16:41:48  <isaacs>trevnorris: kewl! what'd you find?
16:42:02  <isaacs>trevnorris: or should we just pull your `make bench` stuff?
16:42:23  <isaacs>trevnorris: i'd like to get bnoordhuis and indutny to sign off on it first.
16:42:34  <trevnorris>I can have it ready in the next few hours. but there are a couple cleanups I need to do.
16:42:37  <indutny>wha?
16:45:43  <isaacs>indutny: trevnorris has been working on a `make bench` target that will produce more useful and consistent output
16:46:01  <isaacs>indutny: rather than our current set of benchmarks that all make completely different output
16:46:17  <indutny>aaah!
16:46:18  <indutny>great
16:46:46  <trevnorris>(plus things like command line parameterization, arguments parsing, async test support, completion hooks to write to file, etc. think it's all in there. =)
16:47:20  <indutny>btw, I'm running http benchmark across all commits since v0.8
16:47:22  <isaacs>trevnorris: what profiling have you been doing of net-pipe?
16:47:32  <isaacs>indutny: awesome :)
16:47:37  <indutny>to find out if there was some commits that degraded performance significantly
16:48:02  <isaacs>that's good
16:49:34  * qmx|lunchchanged nick to qmx
16:49:43  <isaacs>there's one last API change that i think we ought to make before 0.10, and then it's just all about the performance regressions.
16:50:00  <isaacs>(minor. duplex streams should take 2 options objects, so you can configure the readable and writable sides separately)
16:54:42  * bradleymeckquit (Read error: Connection reset by peer)
16:55:04  * bradleymeckjoined
16:55:17  <isaacs>Can someone review these two minor obvious fixes? https://github.com/isaacs/node/compare/master
16:56:11  <indutny>isaacs: lgtm, btw, can you initialize ._handle on socket too?
16:56:12  <indutny>please
16:56:25  <indutny>I think we should look through code's lines
16:56:36  <indutny>and find other properties that are added to classes dynamically
16:56:44  <trevnorris>isaacs: I think context switching is hurting. .call() is being called almost 40% more.
16:56:45  <indutny>its pretty bad thing - hidden class creation, etc
16:56:53  <trevnorris>isaacs: check this: https://gist.github.com/4657156
16:57:02  <trevnorris>a lot of node is hurt by context switching.
16:57:33  <isaacs>trevnorris: yeah, we .call in EventEmitter.emit
16:57:35  <isaacs>i believe
16:57:51  <isaacs>trevnorris: but Date.now() is not reliable enough, i think
16:58:02  <trevnorris>isaacs: must. I ran net-tcp for 1 sec and .call was called 40k times.
16:58:05  <trevnorris>that's insane
16:58:18  <indutny>so far everything is pretty stable
16:58:18  <indutny>0d7a021 - 2280.4
16:58:18  <indutny>a39f669 - 2443.96
16:58:19  <indutny>acd0df4 - 2354.13
16:58:19  <indutny>2e371b8 - 2308.07
16:58:19  <indutny>0972acb - 2247.25
16:58:19  <indutny>7f2a78b - 2286.37
16:58:20  <indutny>bdc7251 - 2387.51
16:58:24  <trevnorris>isaacs: Date.now() is reliable for benchmarks over 1 sec.
16:58:31  <isaacs>trevnorris: yeah, i guess
16:58:43  <trevnorris>i'll swap it. give me a moment
16:59:06  <isaacs>trevnorris: btw, i usually prefer to report benchmarks as ops/time rather than time/N-opts
16:59:25  <trevnorris>cool. easy change
16:59:40  <isaacs>trevnorris: that way, a "40% regression" is actually "40% fewer operations per second" rather than being "40% more seconds per operation" which is the inverse of what you care about.
17:00:05  * indexzerojoined
17:00:13  <isaacs>trevnorris: then it's a measure of speed rather than a measure of 1/speed
17:00:20  <trevnorris>ah, got it.
17:00:31  <isaacs>it gets really weird around the extreme fast end.
17:02:30  <isaacs>on master:
17:02:33  <isaacs>=== release test-cluster-net-send ===
17:02:33  <isaacs>Path: simple/test-cluster-net-send
17:02:33  <isaacs>[91906] master
17:02:33  <isaacs>[91907] worker
17:02:33  <isaacs>Assertion failed: (tcpConstructor.IsEmpty() == false), function Instantiate, file ../src/tcp_wrap.cc, line 63.
17:02:36  <isaacs>Command: out/Release/node /Users/isaacs/dev/js/node-master/test/simple/test-cluster-net-send.js
17:02:45  <isaacs>but only when run through the test runner.
17:03:09  <isaacs>indutny: i'm suspicious of 0d7a021
17:03:32  <indutny>isaacs: erm?
17:03:36  <indutny>it works for me
17:03:53  <trevnorris>isaacs: updated the gist to use hrtime(). same results.
17:03:55  <isaacs>indutny: are you runing make test, or ./node test/simple/test-cluster-net-send.js?
17:04:01  <indutny>latter one
17:04:13  <isaacs>indutny: try `python tools/test.py simple/test-cluster-net-send`
17:05:00  <indutny>huuuh??
17:05:02  <indutny>wtf
17:05:23  <indutny>it works 100% of time when run from repl
17:05:55  <isaacs>indutny: https://gist.github.com/4657227
17:05:56  <isaacs>yeah
17:05:59  <isaacs>same here
17:06:13  <isaacs>something odd with the python runner's stdio maybe?
17:07:17  <isaacs>oh, i guess it has to be 0d7a021 that's the culprit, since the test doesn't exist before then ;)
17:08:33  <indutny>erm?
17:10:05  <indutny>interesting thing...
17:10:09  <indutny>will figure it out soon
17:10:29  <isaacs>kewl
17:10:31  <isaacs>thanks :)
17:10:32  <MI6>joyent/node: isaacs master * 4c78a52 : net: Initialize _connection, _handle in Socket ctor The better to reduce (+1 more commits) - http://git.io/uMEeXw
17:12:25  * piscisaureus_quit (Ping timeout: 260 seconds)
17:14:09  <isaacs>trevnorris: i'm not sure how we could get around using .call in EE.emit
17:14:24  <isaacs>trevnorris: since the function is actually attached to emitter._events
17:14:48  <isaacs>trevnorris: the alternative would be to create a buttload of hidden classes, or swap out a temp field, which is probably worse.
17:15:20  <isaacs>trevnorris: ie, instead of handler.call(emitter, ...) we could do emitter.__tmpHandler = handler; emitter.__tmpHandler(...)
17:15:40  <isaacs>trevnorris: might be worth investigating, at least, i guess
17:15:56  <trevnorris>isaacs: haven't taken a look yet. just know it's being called 40% more and .call is 20% slower than calling the function right out.
17:16:03  <trevnorris>just something to keep in mind.
17:16:26  <trevnorris>fixing up the benchmarks now for review.
17:17:11  <isaacs>kewl
17:17:27  <isaacs>i'll see what effect the __tmpHandler has on http-simple, if any
17:24:24  <indutny>isaacs: bnoordhuis: https://gist.github.com/ac8b471e51ae80069fda
17:24:27  <indutny>fixes python test
17:25:54  <isaacs>indutny: lgtm
17:25:54  <indutny>isaacs: do we have big ubuntu drone?
17:25:57  <indutny>gret
17:25:58  <isaacs>indutny: yes.
17:26:04  <isaacs>indutny: make sure that `make test` passes now
17:26:04  <indutny>huuuh?
17:26:06  <indutny>where is it?
17:26:22  <isaacs>indutny: 165.225.130.75
17:26:28  <isaacs>indutny: it's not *that* big
17:26:29  <isaacs>but it's pretty big
17:26:33  <indutny>and I was spending my money on it....
17:26:35  <indutny>shit :)
17:26:49  <indutny>ok, I'm going to restart benchmarks on it
17:26:50  <isaacs>dude, don't spend your own money on servers. that's what employers are for
17:27:09  <indutny>this basically means that it better not get touched in 24h
17:27:15  <indutny>a lot of commits to check
17:27:51  <indutny>isaacs: np, I've some cash
17:27:52  <indutny>:)
17:28:19  <isaacs>indutny: that's fine. i only use it for builds
17:28:22  <isaacs>indutny: go nuts on it :)
17:28:27  <indutny>haha :)
17:28:28  <indutny>ok
17:28:28  <indutny>deal
17:30:04  <indutny>tomorrow I'll be tortured
17:30:06  <indutny>by dentist
17:30:15  <indutny>so I'll probably be offline for a lot
17:30:16  <MI6>joyent/node: Fedor Indutny master * c13354e : child_process: move binding init in constructor Doing this in net.Socket - http://git.io/oTV8Bw
17:30:16  <indutny>of time
17:33:29  <isaacs>trevnorris: using a temp method is way slower than .call()
17:33:36  <isaacs>trevnorris: in real usage, anyway
17:33:46  <trevnorris>hm interesting. thanks.
17:34:14  * AndreasMadsenjoined
17:36:09  <isaacs>trevnorris: oh, actually. not way slower. just fluctuating more.
17:36:24  <isaacs>but about the same, actually
17:37:24  <trevnorris>even stranger. only reason I can think of is gc is going nuts.
17:42:01  * bradleymeckquit (Quit: bradleymeck)
17:47:22  <isaacs>maybe
17:47:31  <isaacs>i'm runninga more thorough test now
18:00:41  <isaacs>trevnorris: https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc#gid=8
18:01:26  <trevnorris>thx
18:02:02  <isaacs>trevnorris: so, yes, elimitating .call() is slightly faster overall
18:02:27  <trevnorris>isaacs: but there's probably still a context switch somewhere. saw the same problem when working with buffers.
18:02:42  <isaacs>trevnorris: oh, wait. i think i might have had them switched...
18:02:43  <trevnorris>isaacs: writeFloat/writeDouble are 20% faster when done directly on a slow buffer.
18:02:53  <isaacs>trevnorris: oh, yes, i did
18:03:07  <isaacs>trevnorris: .call() is slightly faster overall. 3% faster.
18:03:09  <trevnorris>ah. ok. but yeah. much higher stdev
18:03:48  <isaacs>trevnorris: .call() is 3% faster, with a 6% lower st dev
18:05:41  * mikealquit (Quit: Leaving.)
18:10:37  * `3E|Cookingjoined
18:11:21  * `3rdEdenjoined
18:15:18  * `3E|Cookingquit (Ping timeout: 256 seconds)
18:17:48  * bradleymeckjoined
18:19:37  <trevnorris>isaacs: for some reason when I change a few of the test parameters I get:
18:19:38  <trevnorris>(node) warning: Recursive process.nextTick detected. This will break in the next version of node.
18:21:17  <isaacs>trevnorris: are you calling process.nextTick from a process.nextTick callback?
18:22:16  * nsmjoined
18:23:27  * TooTallNatejoined
18:24:29  <trevnorris>isaacs: um. only thing I can think would be http://git.io/OTVHvQ
18:26:03  <bnoordhuis>back
18:26:18  <bnoordhuis>isaacs: yeah, i'll look at http (already was, a little)
18:27:38  <trevnorris>isaacs: also, there is a 20% regression between v0.8 and master for tcp_net.js, but only 2% for tcp_netclient.js
18:29:14  * jmar777joined
18:34:41  <isaacs>awesome.
18:34:44  <isaacs>you guys are the best.
18:35:32  <isaacs>trevnorris: i don't see why http://git.io/OTVHvQ would cause a nextTick recursion
18:37:07  <isaacs>trevnorris: your stuff is in benchmark-refactor branch, yes?
18:38:17  * qmxchanged nick to qmx|brb
18:38:22  <trevnorris>isaacs: yeah it is. still updating tests from your gist, but a few are there.
18:39:40  * nsmquit (Quit: nsm)
18:39:43  <trevnorris>isaacs: if you grab it. run the following from benchmark/ : `../node net/tcp_netclient.js --port 3000 --write 0xfffff --size 0xffffff --len 5`
18:39:53  <trevnorris>that should spew the messages.
18:39:55  <isaacs>k
18:40:34  <trevnorris>actually, just the `--size 0xfffff` param is the important one.
18:46:29  <trevnorris>isaacs: oh, and fyi. 0 regression for tcp_raw.js
18:46:30  <isaacs>trevnorris: yeah, it's coming out of Socket.write
18:46:34  <isaacs>trevnorris: fantastic.
18:46:35  <isaacs>ok
18:47:08  <isaacs>it's like a see-saw. we make things a little faster, then find a bug, and fix the bug, and the bugfix makes things slower.
18:47:32  <trevnorris>heh
18:49:15  <isaacs>the tick warnings are coming from the fact that our write() is being flushed entirely in the first tick, so the cb gets called on nextTick rather than immediately
18:51:02  <isaacs>myabe we should get rid of that guarantee
18:51:41  * `3rdEdenquit (Quit: BRBLULZ)
18:52:55  <trevnorris>isaacs: what would be the usage impact?
18:53:11  <isaacs>trevnorris: we can't get rid of that guarantee :)
18:53:13  <isaacs>actually
18:53:24  <isaacs>the trade-off is that you get a stack overflow instead.
18:53:47  <isaacs>actualy, Socket.write() should not ever be sync, since the writeReq should not allow that anyway
18:53:50  <isaacs>so i think something is wrong
18:54:20  <trevnorris>is the callback called in a nextTick?
18:54:29  * `3E|Cookingjoined
18:54:29  * `3E|Cookingchanged nick to `3rdEden
18:54:46  * loladirojoined
18:55:09  * qmx|brbchanged nick to qmx
18:55:37  <isaacs>trevnorris: you realize that new Buffer(bufSize).length === 8 here?
18:55:59  <isaacs>> new Buffer("0xffffff")
18:56:00  <isaacs><Buffer 30 78 66 66 66 66 66 66>
18:56:21  <trevnorris>isaacs: ah mother. parser fail. i'll fix that. thanks.
18:56:33  * AvianFlujoined
18:56:51  <isaacs>np
18:56:56  <isaacs>that's why it's flushing entirely.
18:57:23  <trevnorris>ok, so it's because the buffer is so small?
18:57:47  <isaacs>trevnorris: right
18:58:11  <isaacs>trevnorris: and net.js has an optimization where it checks to see if the socket was able to eat all the data, and then calls cb() right now, instead of waiting for libuv to come back with the afterWrite function
18:58:15  <isaacs>trevnorris: in 0.8, we always waited
18:58:16  * nsmjoined
18:58:48  <isaacs>trevnorris: but _stream_writable.js will *always* wait until nextTick, so with a zillion tiny writes, you get this nexttick recursion
18:59:16  <trevnorris>ah... ok. interesting. so think there's a fix somewhere, or good as is?
18:59:31  <isaacs>trevnorris: oddly enough, it's *faster* to do it this way (wit hteh nt recursion) because we're letting it write more in a tight loop instead of waiting until the event loop does stuff.
18:59:49  <isaacs>trevnorris: i think we do have to fix this, yes.
19:00:06  <isaacs>trevnorris: but i am not happy about removing the optimization :)
19:00:33  <isaacs>trevnorris: especialy, for stdio sync streams, it's not ideal.
19:02:30  <trevnorris>isaacs: seriously. sorry. not familiar enough with that part to have any ideas. but it's got to be in there somewhere.
19:02:48  <isaacs>yeah
19:03:03  <isaacs>it seems like there's a few use cases for knowing process.tickDepth
19:04:12  * loladiroquit (Quit: loladiro)
19:11:45  <indutny>isaacs: my benchmark has checked commits up to 3d7818f :)
19:14:40  * brsonjoined
19:15:15  * lohkeyjoined
19:16:14  <isaacs>indutny: kewl
19:16:22  <isaacs>indutny: any interesting tidbits?
19:19:13  * nsmquit (Quit: nsm)
19:26:33  * bradleymeckquit (Quit: bradleymeck)
19:26:40  <indutny>isaacs: not yet
19:26:47  <indutny>it's pretty the same thing for now
19:26:49  * EhevuTovjoined
19:27:54  <isaacs>k
19:28:04  <isaacs>indutny: what benchmark are you checking? net-pipe?
19:28:10  <indutny>http_auto
19:28:13  <isaacs>ok
19:28:52  <isaacs>indutny: with which args?
19:28:55  * loladirojoined
19:29:05  <indutny>benchmark/http_simple_auto -c 250 -n 200000 bytes/1024
19:29:10  * sgallaghquit (Remote host closed the connection)
19:29:14  <isaacs>indutny: throw a -k on there
19:29:26  <indutny>oh, its too late :)
19:29:28  <indutny>https://gist.github.com/4655489
19:29:35  <indutny>^ that's the script I'm using
19:30:55  <isaacs>indutny: pk
19:31:02  <isaacs>indutny: maybe tomorrow when it finally finishes :)
19:31:05  <indutny>haha
19:31:10  <indutny>hopefully it'll be tomorrow :)
19:31:10  <isaacs>indutny: also, -c 250 is too much for mac ab
19:31:14  <indutny>so far it's going pretty slow
19:31:20  <isaacs>i usually use -c 50
19:31:21  <indutny>that's running on your ubuntu drone
19:31:24  <isaacs>k
19:31:33  <indutny>and I wanted to have sort of stable results
19:31:38  <indutny>anyway
19:31:45  <indutny>yeah, it's too big, but ok
19:32:36  * `3rdEdenquit (Quit: brb)
19:32:55  <isaacs>i gotta run. i'll be back in a few hours.
19:33:11  <isaacs>bnoordhuis: care to review? https://github.com/joyent/node/pull/4676
19:33:24  <isaacs>trevnorris: fixes your tickDepth warning woes ^
19:34:04  <trevnorris>isaacs: hey. I could have been intentionally running w/ a small buffer. ;-)
19:34:28  * `3rdEdenjoined
19:36:14  * loladiroquit (Quit: loladiro)
19:36:15  <trevnorris>about to test
19:37:09  * AvianFluquit (Remote host closed the connection)
19:38:13  <bnoordhuis>isaacs: hm, i don't know. i understand the motivation but it still seems somewhat hacky
19:38:52  <trevnorris>isaacs: works, but performance is worse than crap: --size 4 -> 0.0015 Gbits/sec
19:39:51  <trevnorris>but it was always like that.
19:40:00  <trevnorris>nothing to do w/ your patch
19:40:01  * c4miloquit (Remote host closed the connection)
19:42:22  * loladirojoined
19:42:36  <indutny>bnoordhuis: so what's up with queen in netherlands?
19:42:44  <bnoordhuis>indutny: she's stepping down :/
19:42:52  <indutny>bnoordhuis: why?
19:43:02  <bnoordhuis>because she turns 75 this year
19:43:42  <indutny>but you'll have a king soon
19:44:31  <bnoordhuis>yep
19:45:15  <indutny>hm... he doesn't look as good as she too me
19:45:31  <indutny>though, I know little about him and her majesty
19:46:54  <bnoordhuis>ah well, he'll do fine
19:47:01  <bnoordhuis>it's mostly ceremonial anyway
19:48:10  <bnoordhuis>1a91a9e24560 15a StoreIC: connection <- why is that event upsetting perf so bad?
19:48:16  <CoverSlide>maxima looks kinda hot
19:48:41  <CoverSlide>oh she's from argentina
19:49:04  <indutny>bnoordhuis: interesting thing
19:49:14  <indutny>do you have line number?
19:49:31  <bnoordhuis>indutny: it's a perf map file generated from a v8.log
19:49:42  <indutny>em... no line numbers, I guess? :)
19:49:46  <bnoordhuis>nope
19:50:11  <indutny>too bad
19:50:51  <bnoordhuis>if i move it a few lines up, it works...
19:50:52  <indutny>bnoordhuis: is it http benchmark?
19:50:55  <bnoordhuis>yes
19:51:06  <trevnorris>isaacs: fixed that bug. thanks for pointing that out. the net benchmarks are still incomplete, but think there are enough there to be helpful.
19:51:23  <indutny>bnoordhuis: what if you'll add .connection property to OutgoingMessage?
19:51:24  <indutny>say
19:51:28  <indutny>this.connection = null;
19:51:49  <bnoordhuis>nah, i just want to know why perf won't parse it
19:52:04  <indutny>what do you mean by won't parse it?
19:52:15  <indutny>aah
19:52:17  <indutny>you know it's address
19:52:20  <indutny>but it didn't take it
19:52:27  <bnoordhuis>yep
19:52:28  <indutny>btw, have you seen my callgrind.js thingy?
19:52:36  <indutny>https://github.com/indutny/callgrind.js
19:52:44  <indutny>it does pretty the same thing, but for callgrind results
19:53:03  <bnoordhuis>yeah, i've seen that :)
19:53:13  <bnoordhuis>but perf lets me drill down into the actual code
19:53:18  <isaacs>bnoordhuis, trevnorris: Maybe should be just a regular property instead of a getter.
19:53:37  * loladiroquit (Quit: loladiro)
19:53:40  <trevnorris>isaacs: sorry, where?
19:53:42  <bnoordhuis>oh, i guess i should get some dinner before it's too late
19:53:45  * bnoordhuisis biab
19:55:05  <trevnorris>isaacs: quick overview: tcp_net.js - ~20% regression; tcp_netclient.js - ~5% regression; tcp_raw.js - 0 regression
19:55:12  * AvianFlujoined
19:55:34  <indutny>trevnorris: and http_auto ?
19:56:40  <trevnorris>indutny: haven't done that one yet. been adding some net tests isaacs gist'd and testing w/ the new benchmark api.
19:58:00  <trevnorris>haven't actually made any code changes. just trying to benchmark the tiny bits.
19:58:05  <indutny>oh god
19:58:07  <indutny>I've counted
19:58:21  <indutny>with current speed I'll need 42 days to benchmark all commits since v0.8
19:58:33  <trevnorris>indutny: lol, awesome.
19:58:49  * c4milojoined
20:19:12  <trevnorris>indutny: how long is a single benchmark taking?
20:19:53  <indutny>30sec
20:20:00  <indutny>including build time
20:20:11  <indutny>I'm using stepping now
20:20:17  <indutny>building every third commit
20:20:30  <indutny>so it should take much less time now
20:20:42  <indutny>hopefully around 5 hours
20:20:54  <trevnorris>um. like 1/3 the time?
20:21:32  <indutny>well
20:21:38  <indutny>I've made benchmarks smaller too
20:21:42  <indutny>it was around 1.5 minutes
20:21:46  <indutny>now 30 seconds
20:21:49  <trevnorris>ah, ok.
20:21:50  <indutny>err
20:21:55  <indutny>something likes this
20:22:28  <indutny>do not want to waste much time on it
20:22:35  <indutny>since I'm not sure if we'll get anything useful out of it
20:23:20  <trevnorris>indutny: if you have a spare min, mind looking over GH-4656. still needs work, but the basic api is there.
20:23:30  <trevnorris>it's meant to ease this benchmark pain.
20:31:01  * loladirojoined
20:37:48  * qmxchanged nick to qmx|brb
20:39:41  * bradleymeckjoined
20:42:15  <trevnorris>bnoordhuis: mind giving me a hint if any of the following is worth taking note? https://gist.github.com/4658797
20:42:50  <trevnorris>just ran valgrind -q ...
20:46:12  * sgallaghjoined
20:47:45  * indexzeroquit (Quit: indexzero)
20:52:47  * qmx|brbchanged nick to qmx
20:54:51  * EhevuTovquit (Quit: This computer has gone to sleep)
20:55:20  * EhevuTovjoined
21:00:16  * AndreasMadsenquit (Remote host closed the connection)
21:16:41  * piscisaureus_joined
21:16:54  <MI6>joyent/node: piscisaureus created branch dgram-cluster - http://git.io/xBCPZQ
21:17:10  <piscisaureus_>bnoordhuis: ^-- can you review? https://github.com/joyent/node/compare/dgram-cluster
21:17:53  <piscisaureus_>bnoordhuis: the only delta between the cluster commit and what you reviewed earlier are the tests btw. The other is a small fix.
21:19:21  <MI6>joyent/node: Bert Belder dgram-cluster * 6311f1c : dgram: avoid EventEmitter leak warning When a datagram socket hasn't bee - http://git.io/y6k8YA
21:35:21  <piscisaureus_>node -e "c=require('cluster');if (c.isMaster)for(i=0;i<8;i++)c.fork();else while(true);" <-- ... comfortable warmth for your lap
21:35:48  * indexzerojoined
21:36:51  <indutny>why not spinning in master too?
21:36:58  * hzquit (Disconnected by services)
21:37:02  <piscisaureus_>ah that
21:37:02  * hzjoined
21:37:06  <indutny>remove `else`
21:37:06  <piscisaureus_>that'd be shorter for sure
21:37:16  <piscisaureus_>but it wouldn't help
21:37:22  <indutny>depends
21:37:25  <indutny>if i<3
21:37:25  <piscisaureus_>I need a way to make my gpu sweat as well :-)
21:37:30  <indutny>oooh
21:37:55  <piscisaureus_>of cours I can just run far cry 3 in the background :-p
21:39:36  <indutny>and or just webgl application
21:39:42  <indutny>with lets say 10k rotating gears
21:40:05  <indutny>but... that'll sweat CPU...
21:40:07  <indutny>hm...
21:40:11  <indutny>better mine bitcoins
21:40:14  <indutny>on GPU
21:40:15  <indutny>yeah
21:40:22  <indutny>anyway
21:40:29  <indutny>is it that cold in Netherlands right now?
21:40:31  * rendarquit
21:40:58  <trevnorris>isaacs: what's the difference between raw and raw-singlewrite?
21:42:41  <piscisaureus_>indutny: well it's cold enough :-)
21:44:24  <piscisaureus_>yes, far cry is pretty effective. :-p
21:45:52  * EhevuTovquit (Quit: This computer has gone to sleep)
21:46:20  * EhevuTovjoined
21:46:58  * mikealjoined
21:47:50  * EhevuTov_joined
21:48:09  * EhevuTov_quit (Remote host closed the connection)
21:51:43  * sgallaghquit (Read error: Operation timed out)
21:51:48  * EhevuTovquit (Ping timeout: 264 seconds)
21:54:42  * bradleymeckquit (Quit: bradleymeck)
21:57:51  * qmxchanged nick to qmx|away
22:00:55  * hzquit
22:01:09  * wolfeidauquit (Remote host closed the connection)
22:04:03  * felixgequit (Quit: felixge)
22:08:06  <trevnorris>indutny: how's the benchmarks going?
22:09:29  * felixgejoined
22:09:40  <bnoordhuis>trevnorris: left a comment on the gist
22:10:15  <trevnorris>bnoordhuis: awesome dude. thanks.
22:11:59  <mmalecki>bnoordhuis: hey, how busy are you? mind looking at your PM?
22:12:45  <isaacs>trevnorris: my guess would be that raw-singlewrite only writes once?
22:12:50  <isaacs>trevnorris: is this going to be on the test?
22:13:23  <trevnorris>isaacs: i've posted all the tests in the gist except that singewrite.
22:13:43  <trevnorris>and they've produced interesting results.
22:13:59  <isaacs>nice
22:14:07  <trevnorris>segmenting each one that way has made it hecka easy to perf check
22:14:23  * `3rdEdenquit (Remote host closed the connection)
22:16:52  * wolfeidaujoined
22:17:21  * jmar777quit (Remote host closed the connection)
22:17:57  * jmar777joined
22:19:32  * indexzeroquit (Quit: indexzero)
22:21:44  * wolfeidauquit (Ping timeout: 252 seconds)
22:22:39  * jmar777quit (Ping timeout: 256 seconds)
22:24:28  * wolfeidaujoined
22:25:16  <trevnorris>suck. need to watch out for which trace options I use when running a benchmark. =/
22:28:59  <trevnorris>isaacs: know what's going on here:
22:29:00  <trevnorris>`../node net/tcp_raw.js --size 0xf --iter 5 2> /dev/null` 0.008 Gb/sec (1200 kb / 1129259 �s)
22:29:19  <trevnorris>when the buffer is super small, performance is ridonculously slow
22:30:05  <isaacs>trevnorris: so... you're writing a very small bufer?
22:30:10  <trevnorris>and it's only a tiny faster in v0.8: "0.020 Gb/sec (2816 kb / 1099408 �s)"
22:30:18  <trevnorris>yeah. the buffer is only 16 bytes.
22:30:26  <isaacs>trevnorris: yeah. well, you're using the write cb for this
22:30:30  <isaacs>trevnorris: it's going to be slowe.
22:31:02  <isaacs>trevnorris: write() in a tight loop until it returns false, then listen for drain, and do it again
22:31:16  <isaacs>trevnorris: that'll be much faster, and it's more like what we actually do
22:31:29  <trevnorris>cool. i'll update the bench to reflect that.
22:36:45  <trevnorris>isaacs: um... sorry. how would I do that when writing directly to the tcp wrap?
22:41:49  <isaacs>trevnorris: look at handle.writeQueueSize. if that's > 0, then attach a callback and wait for the afterwrite function
22:41:55  <isaacs>trevnorris: otherwise, just go again
22:43:26  <isaacs>omg, the wifi in this cafe gets worse every time i come here.
22:43:27  <isaacs>srsly
22:43:54  <trevnorris>isaacs: did you mean to go again if > 0?
22:52:04  <isaacs>trevnorris: no, the writeQueueSize > 0 means that something is queued up
22:52:14  <isaacs>trevnorris: that's like a return false from write()
22:52:54  <trevnorris>isaacs: ok, cool. i'm getting it. just trying to understand what's going on in StreamWrap::WriteBuffer.
22:53:06  <isaacs>kewl
22:53:49  <isaacs>anyone else having problems pushing to github right now?
22:55:14  <trevnorris>works for me
22:57:37  <isaacs>ugh. ok, fed up. going home. if it wasn't for the couches and perfect location, I'd never come to this cafe. bad coffee, bad internet.
22:57:40  <isaacs>bbiab
23:01:04  <MI6>joyent/node: Bert Belder master * 6311f1c : dgram: avoid EventEmitter leak warning When a datagram socket hasn't bee (+1 more commits) - http://git.io/xo3wIQ
23:03:47  <pfox__>anyone here who can talk about libuv gyp devil magic?
23:03:52  <pfox__>curious if all of the unix/linux, unix/freebsd stuff went away and if its all in unix, now
23:04:05  <TooTallNate>pfox__: gyp hasn't changed much
23:04:47  <TooTallNate>isaacs: you think it should be Duplex(readOpts, writeOpts) or Duplex(writeOpts, readOpts)?
23:04:50  <pfox__>how about since before the refcount refactor?
23:04:54  <TooTallNate>\/cc Raynos
23:04:56  <pfox__>like in the past year+
23:05:33  <TooTallNate>pfox__: what are you trying to do?
23:05:50  <pfox__>TooTallNate: update the libuv submodule in rust
23:05:56  <pfox__>so build nightmare stuff
23:06:14  <TooTallNate>pfox__: can't you just use the existing libuv.gyp file?
23:08:45  <pfox__>TooTallNate: we do, sorta. this is the script i'm working from for updating the libuv makefiles that rust uses: https://github.com/mozilla/rust/blob/master/src/etc/gyp-uv
23:08:59  <pfox__>it's terrible and everyone hates it
23:09:11  <pfox__>so if you'd like to school on a Better Way, i'm totally receptive to that.
23:09:30  * EhevuTovjoined
23:09:49  <TooTallNate>pfox__: do you use gyp for the Rust build system?
23:09:58  <TooTallNate>i mean ideally you do it like node does
23:10:12  <TooTallNate>adding libuv as a gyp dependency
23:10:13  <pfox__>no
23:10:46  <TooTallNate>can't say i really have any better advice then
23:15:04  * felixgequit (Quit: felixge)
23:16:17  <trevnorris>ok. just to solidify. net doesn't use buffers directly. it uses the slaballocator, right?
23:20:41  * isaacsback
23:20:56  <isaacs>TooTallNate: Duplex(options, writeOptions)
23:21:04  <isaacs>TooTallNate: writeOptions = writeOptions || options
23:21:24  <isaacs>TooTallNate: also, make sure to update Transform, PassThrough, and all descendents (Socket, Zlib, etc.)
23:21:43  <TooTallNate>isaacs: yup, i mean i kinda agree, except that it looks backwards when you write it out
23:22:02  <TooTallNate>isaacs: since the writable side is the "left-hand side"
23:22:03  <isaacs>TooTallNate: read, write?
23:22:08  <isaacs>oh.. i guess.
23:22:14  <TooTallNate>if you're thinking about it in terms of unix pipes
23:22:46  <isaacs>TooTallNate: not always! if you use <() it can be on the right
23:22:56  <isaacs>totobut yoer' right, it's writable.pipe(readable)
23:23:02  <isaacs>TooTallNate: ^
23:23:16  * isaacsuses "toot<tab>" to address TooTallNate
23:23:23  <TooTallNate>hahaha
23:23:30  <TooTallNate>isaacs: so you changed you mind then?
23:23:37  <isaacs>TooTallNate: sure.
23:23:47  <isaacs>whatever. as long as one-option object makes it default to both
23:23:56  <TooTallNate>yup, of course
23:32:56  <isaacs>bnoordhuis, trevnorris: New commit pushed to https://github.com/joyent/node/pull/4676
23:33:06  <isaacs>as a plain-old-property, it doesn't degrade performance, afaict
23:33:57  <bnoordhuis>pfox__: what's the issue?
23:34:42  <trevnorris>isaacs: lgtm. and if there's a performance hit, it's in the microseconds.
23:35:05  <isaacs>trevnorris: i'm showing <1% chagne to net-pipe, and the direction seems to switch back and forth
23:35:11  <isaacs>just jitter
23:35:22  <isaacs>bnoordhuis: any concerns about exposing tickDepth?
23:35:26  <isaacs>from a philosophical pov?
23:35:52  <bnoordhuis>isaacs: maybe not exposing it. but using it in lib/net.js...
23:36:15  <isaacs>well, that means it has to be exposed. may as well be documented with a scary "don't touch! undefined behavior!" warning
23:36:36  <pfox__>bnoordhuis: i've taken on the enviable task of migrating rust's libuv submodule forward to joyent/master . we haven't updated since well before the refcount refactor
23:36:42  <isaacs>or are you saying that using it in net.js is bad, but exposing it is fine?
23:36:59  <bnoordhuis>isaacs: yes, that
23:37:11  <pfox__>bnoordhuis: part of this is that we have to regen the makefiles that rust uses, whenever we update
23:37:25  <pfox__>the automation around this is probably badly out of date and this is my first go at this problem
23:37:39  <pfox__>so i'm just trying to get my arms around the issue. thrashing.
23:38:12  <bnoordhuis>pfox__: i could land some patches that let you use the old, non-gyp makefile
23:38:12  <pfox__>there's some scripting to spit out a bunch of mk/makefile stuff based on the libuv gyp file
23:38:19  <bnoordhuis>e.g. make ARCH=ia32
23:38:42  <isaacs>bnoordhuis: how do you propose we handle stream.write(smallbuffer, function w() { stream.write(smallBuffer, w) })?
23:39:04  <isaacs>bnoordhuis: we could just always defer the cb, like 0.8 does
23:39:16  <bnoordhuis>isaacs: i would suggest you do that, yes
23:39:28  <pfox__>bnoordhuis: i appreciate it, but i don't know if that's the right answer.
23:39:32  <isaacs>that's kind of an unnecessary delay, though
23:39:37  <pfox__>well i don't know much at all. kind of fumbling about blindly, atm.
23:39:43  <bnoordhuis>isaacs: i have a feeling of deja vu. have we discussed this before?
23:39:44  <isaacs>but i suppose it doesnt' affect the most common case.
23:40:15  <isaacs>bnoordhuis: no, i don't think this one specifically
23:41:26  <bnoordhuis>pfox__: if there's anything in particular you run into, let me know
23:41:55  <pfox__>bnoordhuis: did you see the gyp-uv script i pasted, above?
23:42:01  <pfox__>that's what we use to generate the makefiles
23:42:12  <pfox__>does the general flow strike you as Super Wrong?
23:42:23  <bnoordhuis>well... maybe Slightly Wrong
23:42:42  <bnoordhuis>but it's not the worst build system atrocity ever
23:43:11  <bnoordhuis>what do you need to regenerate the makefiles for?
23:43:40  <pfox__>well if the source tree layout changes, we need new makefiles (like, say, if ares, ev and eio all exit the src tree)
23:44:03  <pfox__>i don't know why the build doesn't do `make` from the /Makefile in the the root of the libuv repo
23:45:22  <bnoordhuis>maybe you can inquire if that's a limitation that can be lifted
23:45:45  <trevnorris>isaacs: is there an example of using net.connect with the new streams2 api (not using the 'data' event)?
23:45:45  <pfox__>is the Makefile arch agnostic?
23:46:15  <bnoordhuis>yes, insofar that it sniffs the arch/platform it's running on and proceeds to do the Right Thing
23:46:18  <bnoordhuis>(hopefully)
23:46:56  <bnoordhuis>i could add ARCH and PLATFORM or OS overrides
23:47:11  <pfox__>graydon is coming
23:47:20  <bnoordhuis>that sounds so ominous
23:47:34  <pfox__>heh. he's the nicest BDFL ive ever met.
23:47:59  <pfox__>anywho, he has way more insight into the build system than i do and can ask better questions.
23:48:16  * graydonjoined
23:48:40  <graydon>bnoordhuis: 'lo
23:48:45  <bnoordhuis>graydon: hi
23:49:10  <graydon>so erm, you've been chatting with pfox?
23:49:18  <graydon>concerning the libuv rust has in its build
23:49:21  <bnoordhuis>yes
23:49:28  <pfox__>graydon: yeah.. ive shown the gyp-uv script
23:49:30  <graydon>which is old and also has a hilariously wonky inter-relationship between the builds
23:49:31  <CoverSlide>brace yourself ... graydon is coming
23:49:41  <bnoordhuis>i suggested he use the plain makefile and stop horsing around with gyp
23:49:49  <graydon>I would like to do that!
23:49:56  <graydon>um
23:50:14  <graydon>I am just trying to reconstruct why we aren't doing so regularly, and try to figure out what we might gain or lose by that adventure
23:50:32  <graydon>we do out-of-tree builds. this is ok?
23:50:59  <bnoordhuis>i guess so
23:51:09  <bnoordhuis>you mean you copy the tree verbatim or?
23:51:21  <graydon>like presently we do make -C place/with/libuv/sources builddir_name=place/we/are/building/it
23:51:25  <pfox__>we don't keep the build artifacts in the repo
23:51:36  <bnoordhuis>ah right
23:51:43  <bnoordhuis>the current makefile doesn't support that
23:51:47  <graydon>and that builds out-of-tree. that should work with the .. eh
23:51:48  <graydon>oh
23:51:56  <graydon>but the makefiles generated by gyp do?
23:52:11  <graydon>(are these makefiles different, i.e. not-generated-by-gyp?)
23:52:20  <bnoordhuis>yes, they build in out/ or however you configure gyp
23:52:25  <bnoordhuis>yes, the makefiles are hand-written
23:52:46  <bnoordhuis>i could add an out-of-tree option, that's not the issue
23:52:57  * c4miloquit (Remote host closed the connection)
23:53:05  <bnoordhuis>*an issue
23:53:32  <graydon>ok
23:53:41  <graydon>I'm curious why there are two sets
23:54:01  <graydon>I mean, gyp is a bit of a struggle but it makes some amount of sense too..
23:54:07  <bnoordhuis>it's mostly because node and v8 use gyp
23:54:26  <graydon>at some point we'll probably shift to packaged binary builds of libuv and this will all get easier
23:54:44  <bnoordhuis>the plain makefiles are for people who want to compile a .a or .so quickly without monkeying around with meta build systems
23:55:03  <bnoordhuis>alternatively, rust could switch to gyp and all these problems will go away :)
23:55:07  <graydon>right. well I've no love in my heart for monkeying with meta build systems.
23:55:18  <isaacs>bnoordhuis: ok, removing that automatic cb() call doesn't affect net-pipe or http_simple in any bad way.
23:55:21  <graydon>yeah, we're .. not likely to do that. more likely to back away from 3rd party build tools altogether.
23:55:34  <bnoordhuis>sensible
23:55:41  <graydon>but each thing in order. are the hand-written makefiles relatively easy to understand?
23:55:50  <bnoordhuis>yes, they're maybe 100 lines tops
23:56:01  <bnoordhuis>but if you tell me what you need, i'll add it
23:56:12  <bnoordhuis>out of tree builds, arch and platform overrides, anything else?
23:56:14  <graydon>so if we copy that into our sources for the time being and hack on it for any local adaptations, that's probably just as easy as anything?
23:56:20  <bnoordhuis>yep
23:56:23  <graydon>ok
23:56:59  <graydon>that should be it. um, oh, a long-ish term thing would be to build in "minimal" mode, like not sniff the host's capabilities. I guess that comes along with arch/platform override.
23:57:27  <bnoordhuis>yes. i've been meaning to add that but i never got around to it
23:57:30  <graydon>we do cross compiling / self hosting, and bundle the libuv with a snapshot build, so if we build on a fancy new linux it makes it less portable to old ones.
23:57:38  <bnoordhuis>now at least i have a reason to stop putting it off
23:57:51  <graydon>ok. for the time being though I think even just out-of-tree is sufficient to get us going.
23:57:57  <bnoordhuis>oh, libuv sniffs features at runtime
23:58:00  <graydon>the other stuff there are other things blocking besides libuv so it's not high priority.
23:58:19  <graydon>but it expects certain glibc symbols if it was built where they exist
23:58:20  <graydon>no?
23:58:25  <graydon>did you figure out a way to make it stop doing so?
23:58:31  <graydon>i think we have a _very_ old libuv in our tree
23:58:40  <bnoordhuis>yeah, i've worked on that quite a bit
23:58:48  <bnoordhuis>what glibc symbols were you having issues with?
23:59:03  <bnoordhuis>i think it should compile with anything from 2.3 up
23:59:06  <graydon>don't remember; I whittled a number of them down and then gave up when I found libstdc++ was doing the same thing.
23:59:22  <graydon>needing to excise libstdc++ from librustrt is a bigger task
23:59:31  <graydon>(one I don't mind doing, but .. all in good time)