00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:04:58  * loladiroquit (Quit: loladiro)
00:10:28  * stagasquit (Ping timeout: 246 seconds)
00:23:16  * trevnorrisquit (Quit: Leaving)
01:01:07  * c4miloquit (Remote host closed the connection)
01:05:29  * indexzerojoined
01:15:44  * indexzeroquit (Quit: indexzero)
01:28:38  * abraxasjoined
01:33:58  * c4milojoined
01:37:20  * qmx|awaychanged nick to qmx
01:49:51  * loladirojoined
01:51:08  * indexzerojoined
01:51:58  * abraxasquit (Ping timeout: 252 seconds)
02:04:12  * ericktquit (Quit: erickt)
02:05:44  * loladiroquit (Quit: loladiro)
02:12:10  * abraxasjoined
02:35:28  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:46:59  * jmar777quit (Remote host closed the connection)
02:47:34  * jmar777joined
02:51:48  * jmar777quit (Ping timeout: 245 seconds)
03:04:37  * trevnorrisjoined
03:05:20  * qmxchanged nick to qmx|away
03:11:36  * trevnorrisquit (Quit: Leaving)
03:13:11  * brsonquit (Quit: leaving)
03:14:59  * toothrotquit (Ping timeout: 244 seconds)
03:17:01  * toothrjoined
03:35:43  * toothrchanged nick to toothrot
03:37:31  * c4miloquit (Remote host closed the connection)
03:41:03  * ericktjoined
03:42:57  * travis-cijoined
03:42:57  <travis-ci>[travis-ci] joyent/libuv#1039 (threadpool-rework - f794d3e : Ben Noordhuis): The build has errored.
03:42:57  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/1e200258d5a2...f794d3e84006
03:42:57  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/4265208
03:42:57  * travis-cipart
03:50:51  * indexzeroquit (Quit: indexzero)
03:52:19  * travis-cijoined
03:52:19  <travis-ci>[travis-ci] joyent/libuv#1038 (threadpool-rework - 1e20025 : Ben Noordhuis): The build has errored.
03:52:19  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/4840e3a163a1^...1e200258d5a2
03:52:19  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/4264225
03:52:19  * travis-cipart
04:01:04  * c4milojoined
04:18:08  * indexzerojoined
04:46:04  * Benviejoined
05:01:59  * brsonjoined
05:09:06  * c4miloquit (Remote host closed the connection)
05:17:45  * ericktquit (Quit: erickt)
05:31:03  * EhevuTovjoined
05:43:28  * skebcioquit (Read error: Operation timed out)
05:44:38  * skebciojoined
05:50:55  * indexzeroquit (Quit: indexzero)
06:39:22  * wolfeidauquit (Remote host closed the connection)
06:41:36  * paddybyersjoined
06:47:28  * indexzerojoined
07:06:46  * abraxas_joined
07:07:45  * abraxasquit (Ping timeout: 255 seconds)
07:15:03  * rumpjoined
07:26:27  * toothrotquit (Ping timeout: 248 seconds)
07:29:27  * indexzeroquit (Quit: indexzero)
07:29:57  * rendarjoined
07:30:22  * toothrjoined
07:30:28  * AvianFluquit (Remote host closed the connection)
07:42:54  * `3rdEdenjoined
07:44:52  * bnoordhuisjoined
07:53:08  * brsonquit (Ping timeout: 252 seconds)
07:55:30  * abraxas_quit (Remote host closed the connection)
07:56:03  * abraxasjoined
07:56:06  * abraxasquit (Remote host closed the connection)
07:56:40  * abraxasjoined
08:24:26  <indutny>bnoordhuis: heya
08:24:30  <bnoordhuis>indutny: hoya
08:24:45  <indutny>so, what's final version of your threadpool patch?
08:25:26  <bnoordhuis>indutny: what i pushed yesterday. but it's semi-final
08:25:41  <bnoordhuis>i'm probably going to look into per-fd serialization
08:25:44  <indutny>https://github.com/joyent/libuv/compare/4840e3a163a1%5E...1e200258d5a2 ?
08:26:04  <bnoordhuis>indutny: yes, that one
08:26:07  <indutny>ok
08:26:16  <indutny>are tests failing or what?
08:26:22  <bnoordhuis>no, i fixed that
08:26:31  <indutny>aah
08:26:35  <indutny>missed your message
08:26:41  <bnoordhuis>turns out a 16k stack is too small for glibc's 64 bits version of getaddrinfo
08:26:48  <indutny>haha
08:26:49  <indutny>nice
08:26:57  <indutny>I wonder how much space do they need for it
08:27:15  <bnoordhuis>it was something like 23k, i think
08:27:22  <bnoordhuis>but only the first time, when it does a global init
08:28:19  <indutny>bnoordhuis: interesting
08:28:25  <indutny>so let me ask
08:28:29  <indutny>why so small limit?
08:28:34  <indutny>err
08:28:38  <indutny>why limit is so small?
08:31:02  <bnoordhuis>indutny: you mean the stack size?
08:31:10  <indutny>no, the other thing
08:31:12  <indutny>of course stack size
08:31:44  <bnoordhuis>because the default stack size is like 2 mb and that takes up way too much address space
08:32:11  <bnoordhuis>those i/o threads don't need much because they'll be blocked in syscalls all the time
08:32:42  <indutny>256kb then?
08:32:50  <indutny>should be enough for everyone and ok
08:32:54  <indutny>or 64kb
08:32:58  <indutny>anyway
08:33:02  <indutny>you can choose it yourself
08:33:12  <indutny>so do you want me to review that threading patch?
08:33:41  <bnoordhuis>indutny: no. but you can if you want to
08:33:52  <indutny>yeah, surely I can
08:33:53  <indutny>:)
08:34:11  <indutny>at least, do you mind, reviewing my patches?
08:34:20  <bnoordhuis>yes, i mind that very much
08:34:26  <bnoordhuis>reviewing, reviewing, reviewing
08:34:30  <bnoordhuis>i want to write code :(
08:34:42  <bnoordhuis>(i half-kid)
08:34:54  <bnoordhuis>i'll probably drop the stack size limit for cpu threads
08:35:21  <bnoordhuis>it might be an issue for people with 256 core systems but presumably they run 64 bits anyway :)
08:35:32  <indutny>:)
08:36:30  <indutny>haha
08:36:36  <indutny>yeah, I understand
08:36:39  <indutny>I want to write some code too
08:36:45  <indutny>but freebsd dtrace module waits me to debug it
08:38:30  <bnoordhuis>i'm reviewing your PR actually :)
08:38:43  <indutny>aha!
08:38:44  <indutny>I felt it
08:38:50  <bnoordhuis>indutny: why wrapped_val = curr_val & 0xffffffff ?
08:39:04  <indutny>commit message describes it, but I'll explain it now
08:39:11  <indutny>on freebsd objdump reports odd values
08:39:16  <indutny>like 9-byte long numbers
08:39:21  <indutny>or 5-byte long
08:39:33  <indutny>all exported by v8 values are int's
08:39:41  <indutny>and definitely 4 bytes long
08:39:48  <bnoordhuis>are you parsing addresses or values there?
08:39:53  <indutny>values
08:39:56  <bnoordhuis>ah
08:40:11  <bnoordhuis>a comment would be good
08:40:29  <indutny>erm
08:40:35  <indutny>haven't I commented it?
08:40:42  <indutny>let me see
08:40:59  <indutny>Every constant is certainly 4 bytes now, but freebsd's objdump utility
08:40:59  <indutny>prints out odd byte sequences (5-bytes, 6-bytes and even 9-bytes long)
08:40:59  <indutny>for v8's data section. We can safely ignore all upper bytes, because all
08:40:59  <indutny>constants that we're using are just `int`s.
08:41:02  <indutny>that's in commit's log
08:41:19  <indutny>bnoordhuis: ^
08:41:29  <bnoordhuis>yes, i've read that
08:42:19  <indutny>ok
08:42:23  <indutny>what should I comment?
08:42:52  <bnoordhuis>indutny: that you're parsing 32 bits values there, hence the bit twiddlery
08:42:58  <indutny>ah
08:42:59  <indutny>ok
08:43:31  <bnoordhuis>on a completely unrelated note, do you know why the script calls objdump -D -z?
08:43:54  <indutny>-D - disassemle everything
08:44:02  <indutny>-z - disassemble zeroes
08:44:08  <indutny>well, it's pretty odd
08:44:20  <indutny>but that's the only way to get data values out of object file :)
08:44:31  <bnoordhuis>i know what the switches do :)
08:44:32  <indutny>it prefixes all values with their name
08:44:41  <indutny>0x0000.... <v8dbg_....>:
08:44:43  <indutny>and outputs
08:44:48  <indutny>00 00 00 00 : asm code
08:44:55  <bnoordhuis>seems kind of inefficient if all you want is symbol locations/values
08:45:06  <indutny>bnoordhuis: I agree with you
08:45:17  <indutny>any ideas how to extract it in more effecient way?
08:45:18  <bnoordhuis>but whatever, it's not important. just curious
08:45:18  * EhevuTovquit (Quit: This computer has gone to sleep)
08:48:17  <indutny>bnoordhuis: updated message https://github.com/joyent/node/pull/4630
08:48:28  <indutny>"...Since on all supported
08:48:28  <indutny>platforms `int` is 32bit long (and anyway v8's constants are 32bit too),
08:48:28  <indutny>we ignore all higher bits if they were read."
08:50:27  <indutny>ok, pushing
08:50:53  <MI6>joyent/node: Fedor Indutny master * e2592cc : gyp: fix build with dtrace support on FreeBSD Fix undefined reference to (+1 more commits) - http://git.io/hG9stg
08:51:08  <indutny>bnoordhuis: thanks
08:51:15  <indutny>one more left to make this thing work on freebsd
08:51:17  <indutny>(I mean node)
08:51:36  <indutny>https://github.com/joyent/libuv/pull/691
09:04:43  <bnoordhuis>benchmark/fs-readfile.js has regressed something awful, compared to v0.8 :/
09:04:56  <indutny>readfile?
09:04:59  <indutny>are you kidding
09:06:00  * rumpquit (Quit: rump)
09:06:08  <bnoordhuis>indutny: you should know by now that i never jest
09:06:26  <indutny>can't confirm it on osx
09:06:36  <indutny>https://gist.github.com/311dab8d6eee287b2ff4
09:06:39  <bnoordhuis>no surprise. os x has always been terrible
09:06:40  <indutny>will try smartos
09:06:48  <indutny>or ubuntu?
09:06:53  <bnoordhuis>try ubuntu
09:06:56  <rendar>bnoordhuis: why macosx has been so terrible?
09:06:57  <indutny>one sec
09:07:03  <indutny>rendar: because it's unix certified
09:07:15  <bnoordhuis>rendar: all write and pwrite calls are guarded by a Big Lock
09:07:26  <bnoordhuis>because said syscalls are not thread-safe on os x
09:07:38  <rendar>hmm i see
09:07:47  <rendar>but that big log will kill performance in such a way
09:07:50  <rendar>lock*
09:07:52  <bnoordhuis>but apart from that, i/o performance is terrible in general
09:08:15  <indutny>bnoordhuis: building node again
09:08:15  <rendar>bnoordhuis: which is the best Os where i/o perf is not so bad? :)
09:08:24  <bnoordhuis>rendar: linux, by a long shot
09:08:30  <indutny>ahahha
09:08:36  <indutny>BSD
09:08:36  <rendar>heh
09:08:47  <rendar>yeah, i guessed freebsd and linux too
09:08:48  <indutny>Fedora was much more faster
09:09:00  <bnoordhuis>rendar: it depends on the fs, of course
09:09:05  <indutny>last time I've checked it
09:09:09  <indutny>and I was benchmarking databases
09:09:15  <rendar>bnoordhuis: yeah right
09:09:16  <indutny>with really high throughput
09:09:43  <rendar>indutny: which fs?
09:09:51  <indutny>ext4
09:09:51  <indutny>both
09:09:56  <rendar>cool
09:10:13  <rendar>a friend of mine uses reiserfs, but dunno if its still developed
09:10:30  <indutny>hm... was it developed by some russian hacker that was jailed after that?
09:10:35  <indutny>for other crimes
09:10:37  <rendar>yeah right
09:10:38  <indutny>not developing this fs
09:10:43  <rendar>lol
09:10:50  <rendar>they say he killed is wife
09:10:52  <rendar>his*
09:11:23  <bnoordhuis>re ext4 performance, it matters a lot if it's mounted with data=writeback or data=journal
09:11:31  <rendar>also, i heard good tings about xfs for a bunch of small files, like src tree, but never tried it
09:11:43  <bnoordhuis>the first one is faster, they second one is safer (in case of power loss)
09:11:46  <bnoordhuis>*the
09:12:01  <rendar>bnoordhuis: yeah, good point
09:12:08  <bnoordhuis>rendar: from limited personal experience, xfs only shines on big raids
09:12:21  <rendar>i see
09:12:29  <rendar>what about the great zfs?
09:12:35  <bnoordhuis>and it degrades pretty bad when the disks are nearly full
09:12:50  <bnoordhuis>i don't know much about zfs actually :)
09:12:54  <rendar>:)
09:14:21  <rendar>well, returning back to libuv, does libuv allocate some structure every time a new tcp connection arrives?
09:14:37  <indutny>yes
09:14:39  <rendar>(if i have a server listening)
09:15:20  <bnoordhuis>rendar: no. it's up to the user to allocate memory for the uv_tcp_t struct
09:15:24  <rendar>indutny: i see, now my question is, who has the ownership of this list of structures that are created? i mean, who deallocates them?
09:15:33  <rendar>bnoordhuis: oh...i see
09:15:33  <indutny>bnoordhuis: huh?
09:15:46  <indutny>bnoordhuis: aaaah
09:15:50  <bnoordhuis>indutny: libuv calls the user's connection_cb
09:15:51  <indutny>bnoordhuis: we should call accept manually
09:15:54  <bnoordhuis>yep
09:15:56  <indutny>yeah, I forgot about that
09:16:02  <indutny>rendar: sorry for disinformation
09:16:09  <rendar>indutny: no problem man!
09:16:10  <rendar>:)
09:16:14  <rendar>ok, i got it
09:16:35  <bnoordhuis>rendar: libuv mallocs only in a few places
09:16:56  <rendar>bnoordhuis: well i think so, since it works in a very bottom level
09:17:06  <bnoordhuis>for tcp, it only happens when you pass > 4 bufs in a single uv_write() call
09:17:26  <bnoordhuis>(on unices. on windows, it's slightly different.)
09:17:43  <rendar>yeah on windows you have to allocate OVERLAPPED structures and so on
09:18:28  <rendar>bnoordhuis: so in uv_write() if i pass a buffer whose size > 4 it allocates memory
09:18:32  <indutny>bnoordhuis: built 0.9.x, building 0.8.18
09:18:46  <indutny>I think you should pass multiple buffers
09:18:50  <bnoordhuis>rendar: no, if you pass > 4 uv_buf_t structs in one call
09:19:24  <rendar>bnoordhuis: oh i see, but if i pass > 1 uv_buf_t structs, doesn't it became a scatter/gather i/o operation?
09:19:43  <bnoordhuis>rendar: well... possibly
09:20:12  <bnoordhuis>libuv uses writev() sometimes but it prefers write()
09:20:15  <rendar>bnoordhuis: so libuv internally decides if shot N write api calls or call 1 single api for scatter/gather i/o ?
09:20:30  <bnoordhuis>because writev() is often slower than calling write() multiple times
09:20:40  <bnoordhuis>rendar: yes, that's more or less correct
09:20:45  <rendar>hmm i see
09:21:00  <rendar>bnoordhuis: does this is valid also for read() ?
09:21:30  <bnoordhuis>rendar: yes, somewhat
09:21:37  <bnoordhuis>it always uses read() or recvmsg()
09:21:43  <rendar>hmm, i see
09:21:47  <bnoordhuis>i added support for recvmmsg() at one time
09:21:53  <bnoordhuis>but it was actually quite a bit slower
09:22:53  <rendar>bnoordhuis: well, if libuv shots 4 read()s, the callbacks will receive 4 completion calls, one for each read() call, right? and no matter in which order, because buffers are separated
09:23:04  <bnoordhuis>rendar: yes, correct
09:23:21  <rendar>very interesting topic
09:23:29  <bnoordhuis>the actual syscall used is all internal. as a user, you don't have to worry about it
09:23:37  <rendar>bnoordhuis: and of course in the case of readv() it will receive only 1 callback call in completion?
09:23:41  <bnoordhuis>yes
09:24:01  <indutny>bnoordhuis: hm... I see difference in fs-readfile benchmark
09:24:03  <indutny>and it's pretty odd
09:24:08  <rendar>bnoordhuis: cool, and what are the variables that makes libuv to decides if using read() or readv() ?
09:24:34  <bnoordhuis>rendar: ah, to be clear - libuv doesn't use readv(). it's either read() or recvmsg() (for udp)
09:25:04  <rendar>oh i see
09:25:20  <bnoordhuis>for streams, we ask for a buffer that's big enough to contain any probable read (64k)
09:25:48  <bnoordhuis>and for udp, we use recvmsg because recvmmsg turned out to be slower
09:25:51  <rendar>that 64k is decided by libuv?
09:25:58  <bnoordhuis>yes
09:26:03  <rendar>i see
09:26:04  <bnoordhuis>but it uses whatever your alloc_cb returns
09:26:29  <rendar>ok
09:27:51  <bnoordhuis>indutny: you know the galling thing? if i reduce the number of threads to 1 or 2, it's twice as fast
09:27:56  <bnoordhuis>but still slower than v0.8
09:28:01  <indutny>erm
09:28:07  <indutny>I see only 20% difference
09:28:17  <indutny>let me rerun it again
09:28:31  <bnoordhuis>indutny: you're running it in a vm, aren't you?
09:29:11  <indutny>this time even less difference
09:29:12  <indutny>bnoordhuis: yes
09:29:12  <indutny>8320.77 reads per sec (higher is better)
09:29:18  <indutny>vs
09:29:19  <indutny>8032.83 reads per sec (higher is better)
09:29:29  <bnoordhuis>yeah, i don't know how reliable that is
09:29:35  <rendar>bnoordhuis: well, saying i'm writing a server with libuv, when libuv accepts a new connection i have to allocate a stateful context for every connection, and i have to put this control block somewhere, in the case i want to shutdown the server and cleans all of these objects. now my question is: do i have to use a lock when i add these control blocks say in a linked list? because the copmletion
09:29:35  <rendar>routine can be called by serveral threads in the same time..
09:29:58  <bnoordhuis>rendar: completion routine?
09:30:15  <rendar>bnoordhuis: completion routine of a new socket arrives
09:30:32  <bnoordhuis>rendar: everything runs on the same thread
09:31:01  <rendar>bnoordhuis: so all completion routines are called by 1 thread?
09:31:09  <bnoordhuis>rendar: yes
09:31:09  <bnoordhuis>read the file 302808 times (higher is better)
09:31:09  <bnoordhuis>33028.43 ns per read (lower is better)
09:31:09  <bnoordhuis>30276.94 reads per sec (higher is better)
09:31:13  <bnoordhuis>^ that's v0.8
09:31:24  <bnoordhuis>read the file 182421 times (higher is better)
09:31:24  <bnoordhuis>54829.12 ns per read (lower is better)
09:31:24  <bnoordhuis>18238.48 reads per sec (higher is better)
09:31:29  <indutny>whoa
09:31:33  <bnoordhuis>^ master with new (tweaked) threadpool
09:31:35  <indutny>yes, big difference
09:31:38  <indutny>aaah
09:31:45  <indutny>what about master without this tweaks?
09:31:57  <bnoordhuis>about 100k
09:32:08  <bnoordhuis>i.e. slower
09:32:15  <bnoordhuis>*slower still
09:32:41  <indutny>5404.67 reads per sec (higher is better)
09:32:46  <indutny>6314.4 reads per sec (higher is better)
09:32:47  <indutny>smartos
09:32:54  <bnoordhuis>hah, seriously?
09:32:54  <indutny>latter one is 0.8
09:32:57  <indutny>yes
09:33:00  <indutny>and it's 12 core machine
09:33:05  <bnoordhuis>bwahah
09:33:08  <indutny>I don't understand why it is so slow
09:33:21  <bnoordhuis>it's probably virtualized / zoneified
09:33:27  <indutny>yes
09:33:27  <indutny>but
09:33:30  <indutny>you know
09:33:36  <bnoordhuis>still, that's ridiculously slow
09:33:37  <indutny>it's even slower than ubuntu in virtualbox
09:33:41  <indutny>on macbook
09:33:48  <indutny>when playing Porcupine Tree via itunes
09:33:53  <bnoordhuis>haha
09:33:54  <indutny>and writing this message
09:34:05  <bnoordhuis> /cc @isaacs
09:34:13  <indutny>looks like there're some resource constraints
09:34:27  <indutny>or just old kernel/zone
09:34:38  <indutny>ah
09:34:41  <indutny>uptime 238 days
09:34:47  <bnoordhuis>there's probably some cpu or i/o rate limiting in effect
09:35:33  <indutny>yes
09:35:35  <indutny>I think so
09:35:41  <indutny>or probably everyone forgot about this machine
09:35:52  <indutny>and there're a lot of other zones here
09:36:21  <bnoordhuis>read the file 258018 times (higher is better)
09:36:21  <bnoordhuis>38759.66 ns per read (lower is better)
09:36:22  <bnoordhuis>25800.01 reads per sec (higher is better)
09:36:28  <bnoordhuis>^ that's with one i/o thread
09:36:34  <indutny>nice
09:36:41  <indutny>much closer
09:36:42  <bnoordhuis>yeah well, it's still slower
09:36:48  <bnoordhuis>but it's an improvement
09:36:49  <indutny>I'm dtracing it atm
09:36:59  <indutny>btw
09:37:02  <bnoordhuis>it angers me that i/o is such a fickle beast though
09:37:06  <indutny>I told ya that concurrent write()s won't work well
09:37:14  <indutny>and read()s
09:37:39  <indutny>especially on one inode
09:42:27  <indutny>wanna look at flamegraphs?
09:42:28  <indutny>bnoordhuis: ^
09:42:35  <bnoordhuis>indutny: sure
09:43:13  <indutny>http://blog.indutny.com/f/fs-0.8.18.svg
09:43:17  <indutny>http://blog.indutny.com/f/fs-0.9.7.svg
09:43:27  <indutny>it's 32bit version
09:43:33  <indutny>unfortunatelly I forgot to patch config.gypi
09:43:56  <bnoordhuis>remind me again how i should read them
09:44:11  <bnoordhuis>lower and darker is more time spent inside right?
09:44:24  <indutny>not exactly
09:44:31  <indutny>lower is parent in stack traces
09:44:35  <indutny>higher is top functions
09:44:44  <indutny>so every column represents stack trace
09:44:54  <indutny>and width represents how often this stack trace was seen
09:45:01  <indutny>so yeah
09:45:12  <indutny>if some bar is wide it was called either too often
09:45:19  <indutny>or spent too much time
09:45:37  <bnoordhuis>0.9 is flatter which is good, i think
09:45:44  <bnoordhuis>but also wider
09:45:49  <indutny>ehm
09:45:54  <indutny>don't look at flattness
09:45:58  <indutny>I've removed small peaks
09:46:06  <indutny>like long-long stack traces that was seen only once
09:46:53  <indutny>so, interesting thing
09:46:58  <indutny>is it using async_t?
09:47:02  <indutny>ah
09:47:05  <indutny>it reads in other thread
09:49:11  <indutny>oh... it's too hard to figure something out of it
09:49:23  <indutny>may be I should use the same node version but with different libuv version?
09:50:06  <indutny>btw
09:50:08  <indutny>interesting thing
09:50:15  <indutny>worker seems to be spending less time in mutexes
09:50:32  <indutny>and it become faster in master
09:53:36  <bnoordhuis>then i did at least something right :)
09:53:44  <indutny>haha
09:56:37  <indutny>hm...
09:56:43  <indutny>bnoordhuis: is that benchmark reading directory?
09:57:05  <indutny>odd
09:57:07  <indutny>looks like not
09:57:11  <indutny>but Array::New() is called
09:57:12  <bnoordhuis>indutny: don't think so. why do you ask?
09:57:49  <indutny>I see Array::New() call from node::After(uv_fs_t)
09:57:55  <indutny>in flamegraph
09:58:43  <indutny>it shouldn't be there
09:59:28  <indutny>http://blog.indutny.com/f/fs-0.8.18.svg
09:59:29  <indutny>oops
09:59:35  <indutny>this:
09:59:35  <indutny> node`_ZN2v88internal4Heap11RecordWriteEPhi
09:59:35  <indutny> node`_ZN2v88internal7Factory10NewJSArrayEiNS0_12ElementsKindENS0_13PretenureFlagE+0x55
09:59:36  <indutny> node`_ZN2v85Array3NewEi+0xaa
09:59:36  <indutny> node`_ZN4nodeL5AfterEP7uv_fs_s+0x136
09:59:36  <indutny> node`uv__work_done+0x83
09:59:38  <indutny> node`uv__async_io+0xb6
09:59:40  <indutny> node`uv__io_poll+0x259
09:59:46  <indutny> node`uv_run+0xda
09:59:46  <indutny> node`_ZN4node5StartEiPPc+0x16d
09:59:47  <indutny> node`main+0x1b
09:59:48  <indutny> node`_start+0x83
10:00:25  <indutny>erm
10:00:31  <indutny>it must be some mistak
10:00:32  <indutny>mistkae
10:00:37  <indutny>either v8 is calling it internally
10:00:39  <indutny>or I don't know
10:08:45  <indutny>aaah
10:08:48  <indutny>this is MakeCallback
10:08:49  <indutny>holy shit
10:09:03  * stagasjoined
10:14:41  <indutny>bnoordhuis: yt?
10:14:46  <bnoordhuis>indutny: ih
10:15:01  <indutny>can you please try benchmarking master after this patch
10:15:08  <indutny>https://gist.github.com/f0202f9fa89fa19b95aa
10:15:34  <indutny>tests will probably fail, but benchmark seems to be working
10:15:40  <indutny>and I wonder what numbers will you see
10:16:45  <bnoordhuis>indutny: benchmark master?
10:16:55  <bnoordhuis>and with or without the threadpool rework?
10:16:56  <indutny>run fs-readfile.js
10:17:02  <indutny>better without
10:17:05  <bnoordhuis>okay
10:17:23  <indutny>after this patch numbers are equal on osx
10:17:28  <indutny>for 0.8.18 and master
10:17:32  <indutny>on fs-readfile benchmark
10:17:40  <indutny>I suppose it might affect http benchmark too
10:19:17  <bnoordhuis>indutny: seems it's slower
10:19:19  * stagasquit (Quit: ChatZilla 0.9.89-rdmsoft [XULRunner 1.9.0.17/2009122204])
10:19:23  <bnoordhuis>at least, on fs-readfile
10:19:41  <bnoordhuis>104300 and 100918 vs. 161284 and 125370
10:19:50  <bnoordhuis>lots of variation without
10:20:01  <indutny>wait
10:20:06  <indutny>it became slower on your machine?
10:20:10  <indutny>after this patch?
10:20:19  <indutny>slower than just master?
10:20:38  <indutny>let me test it in VM
10:21:17  <bnoordhuis>performance is kind of unpredictable though
10:21:32  <indutny>heh
10:21:34  <bnoordhuis>let's see what perf says
10:24:49  <indutny>bnoordhuis: let me explain why I did it
10:25:03  <indutny>I see Array::New() call occupies 2.48% of time in flamegraph
10:25:14  <indutny>and apparently it was added to MakeCallback since v0.8
10:25:21  * stagasjoined
10:26:48  <bnoordhuis>right
10:27:04  <bnoordhuis>seems it gets drowned out by i/o variance
10:27:14  <bnoordhuis>on my machine at least
10:27:18  <indutny>ok
10:27:21  <indutny>what are numbers now?
10:29:55  * abraxasquit (Remote host closed the connection)
10:30:35  <bnoordhuis>funny thing, when i profile with --prof --log, i get better numbers
10:31:31  <indutny>in my vm
10:31:31  <indutny>8999.99 reads per sec (higher is better)
10:31:33  <indutny>master ^
10:31:38  <indutny>8365.64 reads per sec (higher is better)
10:31:39  * abraxasjoined
10:31:39  <indutny>v0.8 ^
10:31:57  <bnoordhuis>lunch, biab
10:32:26  <indutny>bnoordhuis: at the right time :)
10:33:06  <indutny>bnoordhuis: see ya
10:33:49  * stagas_joined
10:34:40  * stagasquit (Ping timeout: 244 seconds)
10:34:43  * stagas_changed nick to stagas
10:36:13  <indutny>bnoordhuis: http benchmarks are slightly better too
10:36:26  * abraxasquit (Ping timeout: 256 seconds)
10:41:17  <indutny>apparently process.nextTick "improvements" are also affecting it
10:55:23  * `3rdEdenchanged nick to `3E|LUNCH
11:00:54  <rendar>hmm, uv_loop_t can be viewed as a "threadpool" ?
11:04:37  * stagasquit (Read error: Connection reset by peer)
11:06:31  * stagasjoined
11:09:33  <indutny>rendar: what do you mean?
11:12:17  <rendar>if uv_loop_t structure represent only 1 loop where to post tasks, or also multiple loops with multiple threads, so like a threadpool
11:12:44  <indutny>oh
11:12:55  <indutny>IO work is performed in threads
11:12:59  <indutny>to improve performance
11:13:04  <indutny>but this is questionable idea
11:13:22  <rendar>yeah, and that uv_loop_t strucure represents these threads, right?
11:13:48  <indutny>it stores their context
11:13:52  <indutny>if you're talking about that
11:14:00  <rendar>yep
11:14:00  <indutny>you don't have direct API to affect this threads
11:14:07  <rendar>exactly
11:44:36  <bnoordhuis>back
11:44:53  <indutny>bnoordhuis: so on smartos difference is not that significant
11:45:05  <indutny>but on ubuntu I get better results
11:45:20  <bnoordhuis>indutny: i would remove 'on' and 'difference' from that sentence
11:45:31  <indutny>:)
11:46:10  <bnoordhuis>i'm going to work on the new threadpool some more
11:46:28  <rendar>bnoordhuis: is that the new uv_loop_t ?
11:46:40  <bnoordhuis>rendar: no, an implementation detail of libuv
11:46:48  <rendar>i see
11:46:50  <indutny>bnoordhuis: can you test my patch first?
11:47:26  <bnoordhuis>indutny: i can but i won't, i've enough distractions as it is :)
11:47:31  <indutny>ahha
11:47:32  <indutny>ok
11:47:42  <rendar>bnoordhuis: we were discussing before if uv_loop_t object can be seen as a "closed" threadpool, closed in the meaning you cannot modify the single thread
11:48:06  <bnoordhuis>rendar: ?
11:48:12  * `3E|LUNCHchanged nick to `3rdEden
11:48:47  <rendar>bnoordhuis: sorry, i mean if i could say that uv_loop_t structures represents threadpools basically
11:49:02  <bnoordhuis>rendar: no. there is just one program-wide threadpool
11:49:28  <rendar>and uv_loop_t structure "communicate" with the global one threadpool
11:50:48  <bnoordhuis>yes
12:04:49  <indutny>bnoordhuis: wanna pull my patch for libuv first?
12:04:50  <indutny>:)
12:04:58  * indutnyis just saying
12:05:30  * abraxasjoined
12:07:42  * abraxasquit (Remote host closed the connection)
12:26:14  <indutny>bnoordhuis: why you never told me about -g flag for `perf record`
12:28:42  * hzjoined
12:38:24  <indutny>bnoordhuis: ok, I confirm it node gets worse with this patch
13:14:39  <indutny>oh shit
13:14:43  <indutny>profiling is so complicated
13:18:42  * qmx|awaychanged nick to qmx
13:18:54  * stagasquit (Quit: ChatZilla 0.9.89-rdmsoft [XULRunner 1.9.0.17/2009122204])
13:21:56  <indutny>especially considering that tick-processor doesn't work on master
13:29:29  <bnoordhuis>indutny: you probably need to upgrade the tick processor
13:29:36  <indutny>you think so?
13:29:43  * stagasjoined
13:29:48  <bnoordhuis>or install node-profiler, its nprof is from v8's bleeding edge
13:29:50  <indutny>I'm using node module just FYI
13:29:54  <indutny>oh
13:29:57  <indutny>node-profiler
13:32:02  * qmxchanged nick to qmx|coffee
13:32:29  <indutny>heh
13:32:32  <indutny>it doesn't work either
13:32:42  <indutny>v8 has added one additional number to profile line
13:32:45  <indutny>not sure what it means
13:37:41  <indutny>looks like a subtype
13:38:28  <indutny>yes
13:38:40  * qmx|coffeechanged nick to qmx
13:38:50  <indutny>nice
14:03:44  * jmar777joined
14:17:33  * loladirojoined
14:32:58  * loladiroquit (Quit: loladiro)
15:03:27  * loladirojoined
15:07:32  * rendar_joined
15:07:51  * rendarquit (Read error: Connection reset by peer)
15:08:07  * c4milojoined
15:13:19  * c4miloquit (Read error: Connection reset by peer)
15:15:28  * c4milojoined
15:27:09  * mmaleckichanged nick to mmalecki[out]
15:49:45  <bnoordhuis>==25297== Process terminating with default action of signal 11 (SIGSEGV)
15:49:46  <bnoordhuis>==25297== Bad permissions for mapped region at address 0x40455B8
15:49:46  <bnoordhuis>==25297== at 0x54AA19F: buffered_vfprintf (vfprintf.c:2313)
15:49:49  <bnoordhuis>^ nice :/
15:54:30  <txdv>o boy
15:54:34  <txdv>how do I compile libuv on windows again
15:54:58  <saghul>vcbuild.bat Release ?
15:55:04  <saghul>or Debug
15:58:00  <txdv>it needs python
15:58:01  <txdv>what version?
15:58:04  <txdv>not the newest?
15:59:29  <MI6>joyent/libuv: Ben Noordhuis threadpool-rework * 0c31d2a : unix: make threadpool spiffier (+2 more commits) - http://git.io/1K20eQ
15:59:41  <tjfontaine>spiffier is a technical term
15:59:57  <saghul>txdv 2.6 or 2.7 should be fine
16:00:42  <bnoordhuis>tjfontaine: and defined precisely
16:01:00  * piscisaureus_joined
16:01:13  <indutny>spiffer = spiffy + dapper
16:01:16  <indutny>nice
16:01:32  <bnoordhuis>at least we're in the same ballpark as v0.8 again, ~255k/s vs 300k/s
16:01:48  <bnoordhuis>as opposed to 100k/s vs 300k/s
16:02:18  <indutny>with threadpool?
16:02:30  * travis-cijoined
16:02:30  <travis-ci>[travis-ci] joyent/libuv#1040 (threadpool-rework - 0c31d2a : Ben Noordhuis): The build has errored.
16:02:30  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f794d3e84006...0c31d2a4deb2
16:02:30  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/4285118
16:02:30  * travis-cipart
16:02:35  <bnoordhuis>indutny: yes, benchmark/fs-readfile.js
16:02:58  <indutny>jenkins hash?
16:03:01  <indutny>seriously
16:03:03  <indutny>oh man
16:03:20  <bnoordhuis>indutny: explain yourself
16:03:32  <indutny>are you think this place can be hackable?
16:03:44  <indutny>or what do you really expect?
16:03:48  <indutny>why not just % m
16:04:08  <indutny>(I'm totally in love with jenkins hash, but using it everywhere)
16:04:10  <indutny>(meh)
16:04:27  <bnoordhuis>have you been touching the moonshine again, fedor?
16:04:40  * bradleymeckjoined
16:05:13  <indutny>bnoordhuis: I understand that after weed its easy to forget, but no I'm not living in Netherlands, Ben
16:05:25  * qmxchanged nick to qmx|lunch
16:05:37  <indutny>is it legal in AMS?
16:05:42  <bnoordhuis>yes
16:05:52  <bnoordhuis>but are you making a point or just generally complaining?
16:05:58  <bnoordhuis>in the latter case, carry on
16:05:59  <indutny>ah
16:06:05  <indutny>it's just a spirit
16:06:12  <indutny>I thought you was talking about some sort of drug
16:06:21  <bnoordhuis>oh, like that
16:06:28  <bnoordhuis>moonshine = homebrew liquor
16:06:36  <indutny>yeah, I see now
16:06:47  <indutny>bnoordhuis: my point is that jenkins hash is useless here
16:06:59  <indutny>and that's what you probably would tell me if I'll show you patch like this
16:07:18  <bnoordhuis>indutny: so what do you think it's used for?
16:07:32  <indutny>for distributing load between threads
16:07:39  <indutny>and to lock on fds
16:07:46  <indutny>and do not work with similar fds concurrently
16:07:47  * felixgejoined
16:07:47  * felixgequit (Changing host)
16:07:47  * felixgejoined
16:07:51  <indutny>I read code, if you're talking about this
16:08:17  <tjfontaine>you're worried that someone is going to craft paths such that only one thread is ever loaded?
16:08:41  <indutny>that's what I thought too
16:08:48  <indutny>but using unseeded jenkins hash won't solve it
16:08:55  <indutny>collisions are still possible
16:08:58  <bnoordhuis>it's not locking but distributing loads, yes
16:09:16  <tjfontaine>I'm not sure what the fuss is about
16:09:20  <indutny>well, it'll make write/pwrite work properly on osx
16:09:21  <bnoordhuis>next patch makes threads steal work from each other
16:09:26  <indutny>oh
16:09:30  <indutny>ah
16:09:33  <indutny>why jenkins then?
16:09:40  <bnoordhuis>why not? it's fast
16:10:02  <indutny>faster that modulo?
16:10:19  <bnoordhuis>a couple of shifts and ors? yes
16:10:34  <indutny>module is actually one `and`
16:10:48  <indutny>and you're doing modulo anyway
16:10:51  <indutny>later
16:10:54  <indutny>when using hint's value
16:11:00  <bnoordhuis>eventually
16:11:01  <indutny>oooh
16:11:04  <indutny>I'm tired of this
16:11:05  <indutny>ok
16:11:12  <indutny>if you want jenkins hash
16:11:17  <indutny>who can be against you
16:11:19  <bnoordhuis>but an AND only distributes well with power-of-twos
16:11:38  <indutny>okok
16:11:46  <bnoordhuis>but anyway, the hash is a _minor_ implementation detail
16:12:05  <indutny>yeah
16:14:33  <txdv>c1 : fatal error C1083: Cannot open source file: '3.0': No such file or directory
16:15:13  <txdv>nevermidn, seems to work with vs08
16:15:53  <indutny>bnoordhuis: sorry about jenkins hash
16:15:59  <indutny>it's late and I'm tired
16:16:05  <indutny>I thought you was using it for file descriptors
16:16:13  <indutny>but apparently you're using it for strings
16:16:38  <bnoordhuis>yep
16:16:57  <bnoordhuis>and it's just to distribute across threads with some modicum of fairness
16:17:09  <indutny>ye
16:17:15  <indutny>that's correct
16:18:38  * `3rdEdenchanged nick to `3E|DINNER
16:18:43  * ryah_quit (Quit: out)
16:19:33  <bnoordhuis>dinner time, biab (maybe)
16:21:07  * c4miloquit (Remote host closed the connection)
16:26:33  * TheJHjoined
16:50:47  * mikealjoined
16:53:16  * dapjoined
16:59:42  * benoitcquit (Excess Flood)
16:59:59  * hzquit
17:01:40  * loladiroquit (Quit: loladiro)
17:02:24  * benoitcjoined
17:06:16  * mikealquit (Quit: Leaving.)
17:07:45  * AvianFlujoined
17:09:38  * pooyajoined
17:13:17  * qmx|lunchchanged nick to qmx
17:18:18  * indexzerojoined
17:20:57  * ericktjoined
17:27:33  * pooyaquit (Quit: pooya)
17:30:47  * `3E|DINNERchanged nick to `3rdEden
17:38:01  * KiNgMaRquit (Ping timeout: 264 seconds)
17:41:06  * ericktquit (Quit: erickt)
17:43:33  * KiNgMaRjoined
17:43:34  * mmalecki[out]changed nick to mmalecki
17:45:06  * wolfeidaujoined
17:49:12  * pooyajoined
17:49:25  * c4milojoined
17:53:07  * ericktjoined
17:59:36  * KiNgMaRquit (*.net *.split)
17:59:36  * benoitcquit (*.net *.split)
18:00:59  * TooTallNatejoined
18:07:54  * benoitcjoined
18:11:06  * KiNgMaRjoined
18:14:17  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
18:15:42  * TooTallNatejoined
18:33:16  * loladirojoined
18:44:11  * felixgequit (Quit: felixge)
19:11:00  * lohkeyjoined
19:29:36  * EhevuTovjoined
19:34:25  * EhevuTovquit (Ping timeout: 240 seconds)
19:42:30  * EhevuTovjoined
19:43:41  * EhevuTovquit (Read error: Connection reset by peer)
19:45:09  * EhevuTovjoined
19:49:10  * brsonjoined
19:58:31  * skebcioquit (Quit: No Ping reply in 180 seconds.)
19:59:54  <indutny>dap: hello!
20:00:05  <indutny>dap: how are you?
20:00:21  <dap>indutny: Hi. Not bad.
20:00:26  <dap>I've gotta run in a minute though.
20:00:29  <dap>But what's up?
20:00:57  <indutny>ah, nothing serious. Just want to ask if you heard any news from Apple guys about dtrace thing
20:01:03  <indutny>not really imporant, we can talk later about it
20:01:06  <indutny>if you'll have time
20:01:47  <dap>I haven't…but I've been waiting for years. Did you email Bryan about it?
20:02:24  <indutny>ah, should I?
20:02:31  <indutny>didn't get it last time :)
20:02:33  <indutny>ok, I'll do
20:02:34  <indutny>thank you
20:03:15  <dap>I would suggest emailing him and explain your plan, and what you want (basically, as I recall, to get in touch with the Apple guys). Then he can reply and CC them or something.
20:06:00  * EhevuTovquit (Quit: Leaving)
20:06:05  <indutny>dap: thank you!
20:06:18  <dap>No problem. I'd love to see these issues fixed.
20:09:24  * `3rdEdenquit (Quit: brb, device swap)
20:23:51  * stagas_joined
20:24:44  * `3rdEdenjoined
20:24:48  * stagasquit (Ping timeout: 252 seconds)
20:25:01  * stagas_changed nick to stagas
20:35:08  * loladiroquit (Quit: loladiro)
20:48:31  * rumpjoined
20:52:29  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:05:00  * TooTallNatejoined
21:17:57  * trevnorrisjoined
21:19:59  * brsonquit (Ping timeout: 244 seconds)
21:29:20  * AvianFluquit (Remote host closed the connection)
21:32:03  * wolfeidauquit (Remote host closed the connection)
21:39:05  * loladirojoined
21:55:44  * c4miloquit (Remote host closed the connection)
22:04:19  * lohkeypart
22:07:06  * hij1nxquit (Quit: WeeChat 0.3.2)
22:07:15  * hij1nxjoined
22:07:44  * indexzeroquit (Quit: indexzero)
22:09:31  * c4milojoined
22:11:12  * rendar_quit
22:13:38  * wolfeidaujoined
22:14:36  * hij1nxquit (Quit: WeeChat 0.3.2)
22:14:45  * hij1nxjoined
22:15:07  * brsonjoined
22:34:07  * chobiejoined
22:36:43  <trevnorris>TooTallNate: yo yo. while the documentation doesn't specifically state it, think it's necessary to throw if copy target_start < 0?
22:37:06  <TooTallNate>trevnorris: seems sane to me
22:37:08  <mmalecki>piscisaureus_: during the party, did anything happen which could have caused my card to stop working?
22:37:18  <trevnorris>have a check that's faster, but it silently makes target_start == 0 if < 0;
22:37:40  <trevnorris>ok. i'll leave that check in.
22:37:55  <TooTallNate>trevnorris: (cause otherwise you could potentially read/write earlier into the parent SlowBuffer, right?)
22:38:39  <trevnorris>TooTallNate: no. slow buffer checks are done in cc land, so the values are being double checked.
22:39:41  <trevnorris>basically it would force target_start == 0, if target_start was anything other than a uint.
22:40:17  <trevnorris>almost have a fix for the issue (though covers a few other things, like perf improvements)
22:40:25  * chobiequit (Quit: WeeChat 0.3.7)
22:41:02  <trevnorris>TooTallNate: btw, w/o this patch if you write to a slow buffer w/o all arguments it'll make the copy about 2x's slower (though dependent on buffer size).
22:42:04  <TooTallNate>trevnorris: well without your patch i currently can't copy to a slowbuffer at all :p
22:42:30  <TooTallNate>well, slowbuf.slice(0) works at least...
22:42:33  <TooTallNate>but that's a hack
22:42:41  <trevnorris>heh, ok. i'll post it and fix anything from code review.
22:43:04  <TooTallNate>trevnorris: if there's no API changes, this should target v0.8 i'd think
22:43:24  <TooTallNate>trevnorris: though throwing under new circumstances is arguably an API change...
22:43:39  <TooTallNate>i defer to isaacs on which branch, but i'd personally like v0.8
22:45:22  <trevnorris>ah, good point. did a couple other changes that can't go in v0.8 (e.g. correct Throw types, not generic Error) but I'll back port and post that too.
22:45:35  * piscisaureus_quit (Read error: No route to host)
22:46:05  * TheJHquit (Ping timeout: 260 seconds)
22:49:51  * c4miloquit (Remote host closed the connection)
22:53:23  * AvianFlujoined
22:54:46  * chobiejoined
22:56:52  <trevnorris>TooTallNate: heh, just noticed a potential flaw in the copy tests. multiple copies are done and values are compared. but the values are never changed. so values are always the same after the first copy.
22:57:25  <TooTallNate>trevnorris: heh
22:57:26  <mmalecki>ircretary: ask piscisaureus_ during the party, did anything happen which could have caused my card to stop working?
22:57:26  <ircretary>mmalecki: I'll tell piscisaureus_ you asked.
22:57:27  <TooTallNate>that's silly
22:57:54  <mmalecki>ircretary: ask piscisaureus_ like, throwing it at people or such?
22:57:54  <ircretary>mmalecki: I'll tell piscisaureus_ you asked.
23:01:48  * trevnorrisquit (Quit: Leaving)
23:02:19  * c4milojoined
23:02:31  * bradleymeckquit (Quit: bradleymeck)
23:03:44  * chobiequit (Quit: WeeChat 0.4.0)
23:04:06  * bradleymeckjoined
23:06:13  * chobiejoined
23:10:10  * piscisaureus_joined
23:10:32  <piscisaureus_>mmalecki: hi
23:11:47  <mmalecki>piscisaureus_: hey
23:12:03  <piscisaureus_>mmalecki: no, atleast not while you were in my line of sight :-)
23:12:04  <indutny>ho
23:12:08  <piscisaureus_>mmalecki: did it stop working?
23:12:33  <mmalecki>piscisaureus_: yeah, like, suddenly. terminals here wouldn't ever read it. oh well :)
23:12:42  <mmalecki>brb boarding
23:12:46  <piscisaureus_>mmalecki: credit limit?
23:12:56  <piscisaureus_>mmalecki: ah, well. Soon you'll be home :-)
23:12:59  <indutny>tty
23:13:01  <indutny>l
23:13:02  <mmalecki>piscisaureus_: nah, like, it wouldn'teven ask me for PIN.
23:13:12  <mmalecki>like, terminal would say 'Card Error'
23:13:24  <mmalecki>meh. gotta board.
23:13:29  <piscisaureus_>hmm, odd
23:15:58  <TooTallNate>mmalecki: demagnetized it sounds like?
23:16:07  <TooTallNate>i've never had that happen before though...
23:16:32  <piscisaureus_>maybe you held it in a speaker? :-p
23:26:47  * c4miloquit (Remote host closed the connection)
23:30:19  * bradleymeckquit (Quit: bradleymeck)
23:33:54  * qmxchanged nick to qmx|away
23:41:27  * toothrchanged nick to toothrot
23:57:37  * `3rdEdenquit (Quit: Zzz gnite)