00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:19  * dshaw_quit (Quit: Leaving.)
00:00:23  * octetcloudjoined
00:00:36  <MI6>nodejs-master: #654 UNSTABLE osx-x64 (1/654) smartos-ia32 (6/654) smartos-x64 (8/654) http://jenkins.nodejs.org/job/nodejs-master/654/
00:01:27  * dshaw_joined
00:02:51  * AvianFlujoined
00:03:11  * FROGGSjoined
00:06:55  * loladirojoined
00:07:06  * AvianFluquit (Ping timeout: 245 seconds)
00:08:08  * dshaw_quit (Quit: Leaving.)
00:09:45  <MI6>libuv-master-gyp: #252 ABORTED smartos-ia32 (2/195) smartos-x64 (2/195) osx-x64 (1/196) http://jenkins.nodejs.org/job/libuv-master-gyp/252/
00:09:54  <MI6>libuv-master: #311 ABORTED smartos (3/195) http://jenkins.nodejs.org/job/libuv-master/311/
00:09:56  <MI6>libuv-review: #81 ABORTED smartos-x64 (2/195) osx-ia32 (1/196) osx-x64 (3/196) smartos-ia32 (4/195) http://jenkins.nodejs.org/job/libuv-review/81/
00:10:16  <MI6>libuv-master-gyp: #253 ABORTED http://jenkins.nodejs.org/job/libuv-master-gyp/253/
00:11:22  <MI6>joyent/node: tjfontaine created branch v0.11.8-release - http://git.io/Fknl6g
00:11:55  * dshaw_joined
00:13:32  <trevnorris>can someone else confirm that the styles on https://github.com/joyent/node/pull/6011 are totally fubar?
00:13:38  <trevnorris>nm. fixed.
00:15:49  * octetcloudquit (Ping timeout: 272 seconds)
00:18:04  <trevnorris>wow... 6011 is finally cleaned up. i'll be happy to see that thing go.
00:21:47  * dshaw_quit (Quit: Leaving.)
00:30:10  <MI6>nodejs-master-windows: #443 UNSTABLE windows-x64 (23/654) windows-ia32 (25/654) http://jenkins.nodejs.org/job/nodejs-master-windows/443/
00:31:00  * zz_karupanerurachanged nick to karupanerura
00:43:17  * AvianFlujoined
00:49:36  * AvianFluquit (Ping timeout: 245 seconds)
00:50:26  <MI6>nodejs-master-windows: #444 UNSTABLE windows-x64 (23/654) windows-ia32 (22/654) http://jenkins.nodejs.org/job/nodejs-master-windows/444/
00:52:08  * AvianFlujoined
00:54:22  * kazuponjoined
00:57:10  * superjoe30quit (Ping timeout: 246 seconds)
00:58:21  * c4milojoined
01:00:09  * bnoordhuisjoined
01:04:26  * bnoordhuisquit (Ping timeout: 240 seconds)
01:19:42  <othiym23>trevnorris: the diff on that PR hurts GH, and by extension Chrome
01:20:06  <othiym23>lookin good, though
01:24:57  * kazuponquit (Remote host closed the connection)
01:25:27  * kazuponjoined
01:26:39  * indexzerojoined
01:26:50  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
01:29:43  * kazuponquit (Ping timeout: 246 seconds)
01:33:59  * kazuponjoined
01:35:37  * sblomquit (Ping timeout: 272 seconds)
01:35:41  * abraxasjoined
01:36:07  * abraxasquit (Remote host closed the connection)
01:36:24  * abraxasjoined
01:45:18  * indexzero_joined
01:47:06  * indexzeroquit (Ping timeout: 245 seconds)
01:47:06  * indexzero_changed nick to indexzero
02:04:40  * Cesar1joined
02:09:12  <Cesar1>hola
02:09:36  * Cesar1part
02:15:12  * kellabytejoined
02:15:23  * kellabytequit (Changing host)
02:15:23  * kellabytejoined
02:15:23  * kellabytequit (Changing host)
02:15:23  * kellabytejoined
02:36:14  * loladiroquit (Quit: loladiro)
02:36:42  * loladirojoined
02:39:29  * indexzeroquit (Quit: indexzero)
02:41:36  * AvianFluquit (Remote host closed the connection)
02:49:55  * abraxasquit (Remote host closed the connection)
03:03:21  * LOUDBOT_quit (Remote host closed the connection)
03:03:34  * LOUDBOTjoined
03:05:43  * abraxasjoined
03:06:49  * julianduquequit (Ping timeout: 240 seconds)
03:11:38  * indexzerojoined
03:19:20  * julianduquejoined
03:22:10  * c4miloquit (Remote host closed the connection)
03:22:42  * c4milojoined
03:26:48  * c4miloquit (Ping timeout: 245 seconds)
03:30:09  * brsonquit (Ping timeout: 240 seconds)
03:34:52  * defunctzombiechanged nick to defunctzombie_zz
03:44:35  * luxigo_quit (Ping timeout: 245 seconds)
03:58:44  * piscisaureus_quit (Read error: Operation timed out)
03:59:09  * kazuponquit (Remote host closed the connection)
03:59:37  * kazuponjoined
04:03:51  * kazuponquit (Ping timeout: 240 seconds)
04:07:47  * piscisaureus_joined
04:17:59  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
04:19:57  * abraxasquit (Remote host closed the connection)
04:30:14  * jcrugzzjoined
04:31:05  <jcrugzz>anyone around that could lend a hand with some odd mdb behavior?
04:42:19  * kazuponjoined
05:00:07  * amartensquit (Quit: Leaving.)
05:05:46  <wolfeidau>jcrugzz: which bit?
05:11:26  * c4milojoined
05:12:04  <jcrugzz>wolfeidau: so i got a core dump on a small little machine from node
05:12:13  <jcrugzz>which cannot be processed on that 256mb machine
05:12:21  <jcrugzz>cause when i try and run ::findjsobjects -v
05:12:23  <jcrugzz>it never completes
05:12:29  <wolfeidau>aha
05:12:32  <jcrugzz>so
05:12:34  <jcrugzz>i take this core dum
05:12:40  <wolfeidau>This is what i am doing
05:12:42  <jcrugzz>scp it on a bigger machine
05:12:56  <jcrugzz>but get https://gist.github.com/jcrugzz/62a558a8da2a5bdda9a7 when i try and do ::load v8
05:13:18  <jcrugzz>when on the small machine with the same smartos version and everything
05:13:21  <jcrugzz>it loads perfectly fine
05:13:26  <wolfeidau>are they both 64bit?
05:13:31  <jcrugzz>yea
05:13:44  <wolfeidau>and the same mdb version?
05:13:47  <jcrugzz>core dump came from 32bit node version running on the 64bit machine
05:13:55  <wolfeidau>ok
05:14:21  <wolfeidau>Most of the stuff i have been doing is on 64 bit using one of tjfontaine updated v8 libs
05:14:40  <wolfeidau>I normally start by running
05:14:49  <wolfeidau>::findjsobjects ! sort -k2
05:14:56  <jcrugzz>wolfeidau: id like to get my hands on that if you have a link
05:15:04  <jcrugzz>id rather run it with 64bit node
05:15:20  <wolfeidau>jcrugzz: You have to use the same arch i believe
05:15:43  <wolfeidau>for the core dump, he has both 32 and 64
05:16:25  * c4miloquit (Ping timeout: 268 seconds)
05:17:35  <wolfeidau>Just spinning up my vm to see if i still have teh URL
05:18:26  <jcrugzz>wolfeidau: awesome thanks
05:20:52  <wolfeidau>jcrugzz: commented on gist
05:20:54  <wolfeidau>:)
05:22:26  <wolfeidau>jcrugzz: quite a version difference https://gist.github.com/wolfeidau/6882870#comment-925387
05:23:05  * ryandotsmithjoined
05:25:56  <jcrugzz>wolfeidau: you are the main
05:25:58  <jcrugzz>man*
05:26:00  <jcrugzz>and LOL
05:26:02  <jcrugzz>wtf
05:26:09  <jcrugzz>quite the difference indeed
05:26:43  <wolfeidau>jcrugzz: Yeah the whole tracking releases thing with smartos mite be coming into play here
05:27:16  <wolfeidau>I am running from a vm which i keep relatively up to date, but even that is not close to tjfontaine builds
05:27:43  <jcrugzz>wolfeidau: newer smartos builds?
05:28:06  <wolfeidau>if you run pkgin up i think it is you will see it points to a release directory
05:28:54  <wolfeidau>jcrugzz: Like http://pkgsrc.joyent.com/packages/SmartOS/2013Q2/x86_64/All
05:29:15  <wolfeidau>If you browse that tree you will see there are more recent snapshots
05:30:43  <wolfeidau>I have no idea how it all works, I just nuke my zone and rebuild from a later image ever few months
05:31:13  <wolfeidau>pkgin is a pretty robust and simple package manager
05:31:39  <wolfeidau>so did that core load with the new library?
05:32:49  <jcrugzz>wolfeidau: ahh interesting, and im multitasking a bit so i havent had the chance to try. doing a server migration xD
05:33:07  <wolfeidau>jcrugzz: haha opslife :)
05:33:25  <jcrugzz>haha indeed!
05:37:20  * ryandotsmithquit (Remote host closed the connection)
05:37:21  <jcrugzz>wolfeidau: but thanks a bunch for the info, i may ping you later when i have the chance to use it ;)
05:38:00  <wolfeidau>jcrugzz: np I am but a novice, but i have gleaned a few commands :)
05:38:14  <jcrugzz>gotta start somewhere! :)
05:38:24  <wolfeidau>jcrugzz: indeed :)
05:47:24  * loladiroquit (Quit: loladiro)
05:52:18  * loladirojoined
05:53:37  * loladiroquit (Client Quit)
06:04:17  * abraxasjoined
06:21:15  * julianduquequit (Ping timeout: 272 seconds)
06:22:36  * julianduquejoined
06:29:16  * julianduquequit (Ping timeout: 264 seconds)
06:41:02  <MI6>nodejs-v0.10-windows: #294 UNSTABLE windows-ia32 (10/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/294/
06:41:31  * FROGGSquit (Ping timeout: 272 seconds)
06:53:14  * FROGGSjoined
07:00:20  * c4milojoined
07:04:36  * c4miloquit (Ping timeout: 245 seconds)
07:14:37  * indexzeroquit (Quit: indexzero)
07:15:33  * rendarjoined
07:57:40  * skabbesquit (Quit: skabbes)
08:02:39  * paddybyersquit (Quit: paddybyers)
08:05:13  * paddybyersjoined
08:16:10  * paddybyersquit (Quit: paddybyers)
08:24:44  <indutny>heya
08:24:45  <indutny>morning
08:31:28  * mraleph1quit (Ping timeout: 246 seconds)
08:40:58  <MI6>joyent/libuv: Fedor Indutny v0.10 * 29fdb34 : unix: update events from pevents between polls - http://git.io/21nIUw
08:45:00  * mralephjoined
08:49:04  * c4milojoined
08:50:35  <mmalecki>indutny: morning Fedor. how're you?
08:50:44  <indutny>morning mmalecki
08:50:46  <indutny>still good :P
08:50:47  <indutny>how are you?
08:50:58  <indutny>writing test for the commit above
08:53:06  * hzjoined
08:53:20  <mmalecki>indutny: good too! nice commit you have there
08:54:06  * c4miloquit (Ping timeout: 268 seconds)
09:03:43  * hzquit
09:07:16  <SquirrelCZECH_>saghul: tip tap? can I bother you with something? :-) do you think it would be able to create additional handler to "pyuv" in python?
09:07:43  <saghul>SquirrelCZECH_ define "additional handler"
09:08:11  <SquirrelCZECH_>saghul: for example "Serial handler" which would make "PySerial" work like "pyuv-handler"
09:08:50  <saghul>you shouldn't need to create a handler, I think sing a TTY handler would work
09:09:55  <SquirrelCZECH_>aaaah
09:10:02  <SquirrelCZECH_>saghul: my bad! :D
09:10:17  <saghul>no problem :-)
09:10:32  * paddybyersjoined
09:10:48  <SquirrelCZECH_>saghul: it didn't worked for me yestrday
09:11:01  <saghul>how did you try?
09:11:05  <SquirrelCZECH_>but today I noticed that I've got wires on "usb serial adapters" wrong
09:11:08  <saghul>else try a Pipe handle
09:11:16  <SquirrelCZECH_>saghul: ttyUSB1 -> ttyUSB2 :-)
09:11:25  <saghul>I meant the code :-)
09:13:41  <SquirrelCZECH_>saghul: oh... what exactly now? :D
09:14:07  * SquirrelCZECH_uses "serial" instance to get file description ant than let's pyuv.TTY do it's work
09:15:59  <SquirrelCZECH_>saghul: http://pastebin.com/yXPb7tpx this is the way I wanted to make it work
09:16:51  <saghul>yes, that should work
09:17:00  <saghul>doesn't it? any exception?
09:18:23  <SquirrelCZECH_>saghul: still problem with hardware I test it on
09:18:43  <saghul>SquirrelCZECH_I can't fix that one from here ;-) good luck!
09:18:52  * hzjoined
09:19:17  <SquirrelCZECH_>saghul: yep, it works now! :D
09:19:25  <SquirrelCZECH_>saghul: you got great piece of code btw! :D
09:19:58  <saghul>thanks!
09:20:46  <SquirrelCZECH_>saghul: btw: did you ever tried performance test vs twisted?
09:21:17  * SquirrelCZECH_hates when he asks something on #python, mentions that he uses pyuv and it's always the same
09:21:24  <SquirrelCZECH_>"why don't you use twisted instead?"
09:21:28  <saghul>nope
09:21:58  <SquirrelCZECH_>P.S: I personally hate when one library tries to do things from socket to http server! P.P.S: I also hate when 99% use only one thing on solving something
09:22:13  <SquirrelCZECH_>saghul: maybe I will force myself one day :-)
09:22:16  <saghul>well, you can have the best of both worlds: https://github.com/saghul/twisted-pyuv :-)
09:22:49  <SquirrelCZECH_>wow :D
09:22:57  <SquirrelCZECH_>saghul: but this is the place to test performance I would say :-P :-)
09:23:08  <SquirrelCZECH_>saghul: thanks, I just love and live with pyuv
09:45:00  * bnoordhuisjoined
09:45:51  * karupanerurachanged nick to zz_karupanerura
09:59:53  * kazuponquit (Remote host closed the connection)
10:00:20  * kazuponjoined
10:03:37  * kuebkjoined
10:05:16  * kazuponquit (Ping timeout: 264 seconds)
10:09:27  <kuebk>hello
10:09:31  <kuebk>anyone here can help me with npm?
10:09:57  <kuebk>i can't unpublish nor publish --force
10:09:58  <kuebk>:(
10:14:42  <bnoordhuis>kuebk: not really on topic for #Libuv
10:15:00  <kuebk>yea i know
10:15:29  <kuebk>but everytime i ask unusual question on #node.js
10:15:32  <kuebk>i don't get answer
10:16:25  <bnoordhuis>that's irc for you
10:19:36  <kuebk>;>
10:31:47  * DarkGodjoined
10:34:13  <DarkGod>Hi, how should one correctly copy an uv_tcp_t in C? I mean I have two structs like that: struct foo { ... uv_tcp_t sock; ... } and I want to copy sock from one to the other. I tried a simple sock = sock copy; I tried to memcpy with the size given by uv_handle_size(UV_TCP); yet nothing works; when I try to use uv_write on the copy it complains with an assert on req->handle == stream
10:34:26  <DarkGod>am I missing something terribly obvious ?
10:34:51  * abraxasquit (Remote host closed the connection)
10:37:59  * c4milojoined
10:38:56  * zot1joined
10:42:30  * c4miloquit (Ping timeout: 245 seconds)
10:48:28  <MI6>nodejs-v0.10: #1570 UNSTABLE smartos-x64 (4/603) smartos-ia32 (4/603) linux-x64 (1/603) linux-ia32 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1570/
10:52:52  <bnoordhuis>DarkGod: in a nutshell, you can't
10:53:01  <bnoordhuis>DarkGod: if you want to clone the socket, you have to jump through some hoops
10:53:35  <DarkGod>it's not realyl clone, the firzst struct would never be used again
10:53:42  <DarkGod>I just need totransfer the sockto a new struct
10:54:38  <bnoordhuis>DarkGod: that won't work either. the uv_tcp_t is part of libuv's internal data structures
10:56:46  <DarkGod>you mean it keeps track of the actual memory address of it ? so the clone is not correctly recognized ?
10:57:48  <bnoordhuis>correct
10:58:15  <DarkGod>damn ..
10:58:56  <DarkGod>so I must make it a pointer in my structs so I can just copy the pointer I suppose
11:01:26  <rendar>as i can see from libuv srcs, the async wait for a process completion consists on repeatdly call of waitpid with WNOHANG, right? but i can't get how libuv can map the just finished pid to the process_t* object in order to call exit_cb
11:03:42  <bnoordhuis>rendar: it looks up the associated handle in a red-black tree
11:03:57  <rendar>bnoordhuis, i see, why not an hash table?
11:03:58  <bnoordhuis>rendar: subject to change though, the current implementation is not quite optimal
11:04:16  <rendar>bnoordhuis, hmm there is a better way to map that?
11:04:20  <bnoordhuis>rendar: turn that question around: why a hash table? :)
11:04:31  <rendar>eheheh i see
11:04:58  <rendar>bnoordhuis, so basically the solution is polling waitpid with WNOHANG
11:05:17  <rendar>bnoordhuis, but wouldn't this bring cpu use of 100% for that thread?
11:05:32  <bnoordhuis>no, because we only call waitpid() when we get a SIGCHLD
11:05:48  <rendar>oh ok
11:06:19  <rendar>so uv_child() is called fromt he SIGCHLD handler
11:06:29  <bnoordhuis>not directly
11:06:57  <rendar>yep
11:07:14  <rendar>bnoordhuis, of course is needed a separate thread for that
11:07:50  <bnoordhuis>no, not really. the signal handler writes to a pipe which in turn wakes up any event loops that are interested in the signal
11:08:02  <bnoordhuis>but like i said, the above is all subject to change :)
11:08:12  <rendar>hmm i see
11:08:21  * zot1quit (Quit: Leaving.)
11:10:07  <rendar>bnoordhuis, time ago for a project i did use this method: all threads with signals blocked, only 1 thread could catch SIGCHLD, then waiting for a pipe to read commands, the commands were add_pid, or wakeup, then the thread did sleep on read(), when SIGCHLD arrived it calls waitpid(-1,...) and map the pid to a callback
11:10:48  <bnoordhuis>rendar: yeah, that works
11:10:54  <bnoordhuis>but we can do better
11:10:55  * zot1joined
11:11:19  <rendar>bnoordhuis, hmmm, how that can be done better?
11:11:23  <bnoordhuis>for instance, the siginfo_t struct that gets passed to your signal handler has the pid in the si_pid field
11:11:35  <rendar>oh
11:11:51  <rendar>so you don't need to call waitpid(-1
11:11:55  <rendar>for example
11:11:56  <bnoordhuis>exactly
11:12:13  <bnoordhuis>that's something of a bug in libuv right now
11:12:26  <bnoordhuis>if you have multiple uv_signal_t watchers that listen for SIGCHLD
11:12:34  <rendar>the point is: how you can get siginfo_t from your signal handler, if the signal handler receive only a int as a prameter?
11:12:47  <bnoordhuis>then libuv will consume all waitpid() events before the other watchers get a chance
11:12:58  <bnoordhuis>rendar: SA_SIGACTION :)
11:13:10  <bnoordhuis>er, SA_SIGINFO
11:13:20  <bnoordhuis>and call sigaction() instead of signal()
11:13:29  <bnoordhuis>was typing too fast :)
11:13:34  <rendar>oh right! i remember..i knew that
11:15:03  <rendar>bnoordhuis, but my point is: if an user who use libuv create a new thread, how we can assure that thread won't receive SIGCHLDs?
11:16:54  <bnoordhuis>rendar: you don't unless you block it with pthread_sigmask()
11:17:15  <bnoordhuis>that's up to the user
11:17:36  <rendar>hmm i see
11:17:45  <bnoordhuis>it doesn't really matter though because signal handlers are global to the process, not local to the thread
11:18:25  <rendar>yeah, but libuv's thread know how to manage a SIGCHLD, a random user thread don't, and the signal is lost, losing the process completion, right?
11:25:41  <bnoordhuis>rendar: no, because the signal handler is global. it doesn't matter on which thread the signal is delivered, libuv's signal handler will catch it anyway
11:27:01  <rendar>oh, ok
11:27:41  <rendar>bnoordhuis, of course if we have more threads completing SIGCHLD, there will be a lock for that rb-tree or hash map structure
11:28:55  <bnoordhuis>that's correct
11:29:40  <bnoordhuis>completely different subject, gettimeofday(3) is supposed to call __vdso_gettimeofday() when available
11:30:05  <bnoordhuis>which it is - but glibc is still making the SYS_gettimeofday system call
11:30:21  <bnoordhuis>and i'm not sure why...
11:31:31  <rendar>hmm whats that __vdso should mean?
11:32:00  <bnoordhuis>it's basically a page (or two pages) of kernel memory that's mapped into the process's address space
11:32:28  <bnoordhuis>it's a teeny tiny elf library with fast wrappers for common functionality
11:33:27  <rendar>i see
11:33:38  <bnoordhuis>__vdso_gettimeofday() is supposed to read out the kernel's timestamp counter (which is also mapped into the vdso) instead of making a syscall
11:33:50  <bnoordhuis>but it's still making the syscall...
11:34:26  <rendar>oh, isn't that vdso that memory page which is shared across processes and contain also the routine to make syscalls switch to kernel mode? iirc :)
11:35:11  <bnoordhuis>kind of. you don't need the vdso to make syscalls, that's what int $0x80 and the sysenter/syscall instructions are for
11:35:45  <bnoordhuis>actually, the vdso's purpose is to avoid making some syscalls altogether :)
11:36:12  <rendar>yeah right, but i remember that the routine which finally accomplish int 0x80; was in the vsdo shared memory, but maybe i remember wrongly
11:36:38  <rendar>bnoordhuis, i see
11:39:21  <bnoordhuis>okay, so __vdso_gettimeofday() is getting called but it determines that the timestamp counter is unreliable and falls back to making the syscall
11:39:46  <bnoordhuis>it's amusing that you can actually put a breakpoint on it with `break __vdso_gettimeofday`
11:39:59  <bnoordhuis>well done, gdb developers
11:40:40  <rendar>yeah very cool
11:41:00  <rendar>bnoordhuis, thats because it is treated as a normal code memory page, of the actual process
11:41:02  <rendar>i guess
11:41:37  <bnoordhuis>i suppose so. it's for all practical purposes a valid elf library, but one that only exists in memory
11:41:44  <bnoordhuis>i wonder if gdb somehow hooks into the dynamic loader
11:42:34  <bnoordhuis>anyway, i guess the conclusion is that clock_gettime(CLOCK_MONOTONIC_COARSE) > gettimeofday() because the former gets serviced inside the vdso
11:42:45  <rendar>bnoordhuis, thats interesting how if you can change the vdso library you can hook *ALL* the syscalls of the system of all processes :)
11:42:46  <bnoordhuis>now to patch libuv and v8
11:43:05  <bnoordhuis>rendar: no, no - it only contains wrappers for a handful of syscalls
11:43:12  <rendar>ok
11:43:46  <rendar>so clock_gettime(CLOCK_MONOTONIC_COARSE) should be used instead of gettimeofday() :)
11:43:58  <bnoordhuis>if you turn off aslr, then you can dump the vdso with e.g. xxd and see for yourself
11:44:11  <rendar>bnoordhuis, very interesting, yeah
11:44:31  <bnoordhuis>because i'm a nice guy:
11:44:31  <bnoordhuis>0000260: 1600 0000 0000 0000 005f 5f76 6473 6f5f 636c 6f63 6b5f 6765 7474 696d 6500 5f5f .........__vdso_clock_gettime.__
11:44:34  <bnoordhuis>0000280: 7664 736f 5f67 6574 7469 6d65 6f66 6461 7900 5f5f 7664 736f 5f74 696d 6500 5f5f vdso_gettimeofday.__vdso_time.__
11:44:37  <bnoordhuis>00002a0: 7664 736f 5f67 6574 6370 7500 6c69 6e75 782d 7664 736f 2e73 6f2e 3100 4c49 4e55 vdso_getcpu.linux-vdso.so.1.LINU
11:44:40  <bnoordhuis>00002c0: 585f 322e 3600 0000 0000 0200 0200 0200 0200 0200 0200 0200 0200 0200 0000 0000 X_2.6...........................
11:45:16  <rendar>lol! :)
11:47:39  <rendar>bnoordhuis, yeah grouping those apis like clock_gettime which returns a system-wide global value (like the time, or ticks or clocks or whatever) in a shared memory makes sense indeed, but i cannot understand why gettimeofday() is not serivced there, i guess for a mistake
11:50:02  <bnoordhuis>yeah. i think i'm going to try it on one or two more systems
11:50:23  <bnoordhuis>my fedora box is running 3.10 which is ancient history by now, of course
11:50:50  * bnoordhuisswitches machines
11:53:16  * bnoordhu1sjoined
11:53:53  <bnoordhu1s>the balmy if volatile goodness of 3.12-rc6
11:54:16  <bnoordhu1s>at least video works again. -rc2 pretty much broke the world
11:54:18  <bnoordhu1s>okay, back to work
11:54:24  <rendar>eheh :-)
11:55:24  * bnoordhuisquit (Ping timeout: 268 seconds)
11:56:36  * bnoordhu1schanged nick to bnoordhuis
11:56:47  <bnoordhuis>interesting... on this system, it does use the vdso...
11:59:30  <rendar>maybe the bug has been adjusted
12:00:09  <bnoordhuis>i guess it's possible
12:00:26  <bnoordhuis>the vdso does a 'is the timestamp reliable?' check
12:01:12  <bnoordhuis>i suppose it's possible that on my fedora machine said check fails often or always. it's a relatively old and underpowered system
12:01:13  <mmalecki>bnoordhuis: disassable either __vdso_gettimeofday or gettimeofday and compare?
12:01:31  <bnoordhuis>mmalecki: you think i haven't already stepped through it? :)
12:01:53  <bnoordhuis>challenge me again and i'll dump the full assembly output here!
12:02:06  * Kakera_joined
12:02:23  <mmalecki>bnoordhuis: haha, just out of curiosity, how long is it?
12:02:31  <bnoordhuis>what's interesting is that it's also making the syscall when i run it in a vm
12:02:42  <bnoordhuis>mmalecki: about 100-150 lines
12:03:01  <bnoordhuis>the c source in arch/x86/vdso is ~15 lines
12:04:36  * zot1quit (Quit: Leaving.)
12:07:55  * zot1joined
12:17:56  <bnoordhuis>huzzah! https://github.com/bnoordhuis/v8/compare/v8:master...clock-monotonic-coarse
12:22:48  * mcavage_joined
12:22:49  * mcavagequit (Read error: Connection reset by peer)
12:26:54  * c4milojoined
12:31:33  * c4miloquit (Ping timeout: 248 seconds)
12:31:38  * SquirrelCZECH_quit
12:32:18  * SquirrelCZECHjoined
12:33:39  <bnoordhuis>for posterity and/or future reference: https://codereview.chromium.org/51333007/
12:35:35  * abraxasjoined
12:38:14  * FROGGSquit (Read error: Connection reset by peer)
12:40:08  * abraxasquit (Ping timeout: 240 seconds)
12:40:37  * FROGGSjoined
12:54:26  <SquirrelCZECH>hi folks
12:54:31  <SquirrelCZECH>what do you use for data compression?
12:54:42  * SquirrelCZECHsends data over network in key:data format
12:54:45  <SquirrelCZECH>and keys repeat a lot
12:55:30  <bnoordhuis>SquirrelCZECH: zlib?
12:55:47  <bnoordhuis>you can set a fixed dictionary if you have one
12:55:52  <bnoordhuis>like spdy does
12:58:59  <SquirrelCZECH>yep
12:59:03  <SquirrelCZECH>bnoordhuis: thinking about it
13:01:04  * FROGGSquit (Read error: Connection reset by peer)
13:01:12  * bnoordhu1sjoined
13:01:39  * FROGGSjoined
13:02:49  <indutny>bnoordhu1s: P
13:02:58  <indutny>bnoordhuis: MONOTONIC!!!!!
13:05:31  * bnoordhu1squit (Ping timeout: 246 seconds)
13:08:46  * zot1quit (Quit: Leaving.)
13:14:14  <bnoordhuis>indutny: i found an amusing bug in libuv actually
13:14:40  <bnoordhuis>we assume in some places that two successive calls to uv__hrtime() will produce different values
13:15:10  <bnoordhuis>which is now not always the case any more
13:15:31  <bnoordhuis>pretty trivial to fix in libuv but i wonder if node is susceptible to the same issue
13:16:30  * loladirojoined
13:16:51  * loladiroquit (Client Quit)
13:25:12  * hzquit
13:28:28  <indutny>bnoordhuis: haha
13:28:30  <indutny>nice
13:28:38  <indutny>I'll finish up merging PRs later today
13:28:46  <indutny>was doing completely different stuff all day
13:28:47  <indutny>heh
13:28:53  <indutny>ttys
13:33:55  * AvianFlujoined
13:43:34  * kaesoquit (Read error: Operation timed out)
13:43:45  * kaesojoined
13:45:36  * kaesoquit (Client Quit)
13:46:07  * kaesojoined
13:55:34  * zot1joined
14:15:47  * c4milojoined
14:20:33  * c4miloquit (Ping timeout: 246 seconds)
14:21:19  * pachetjoined
14:21:19  * pachetquit (Changing host)
14:21:19  * pachetjoined
14:35:49  * zot1quit (Ping timeout: 248 seconds)
14:36:53  * abraxasjoined
14:38:33  * c4milojoined
14:39:16  <DarkGod>silly question but still: callbacks from libuv (in this case the read callback of a tcp stream) happen in the thread that created them: libuv doesnt make a thread behind my back and invokes my CB from it, right ?
14:41:24  * abraxasquit (Ping timeout: 256 seconds)
14:51:49  <Domenic_>isaacs: there are some constituents in this revamped-web-streams discussion who are pretty insistent on having binary streams be only a special case of obejct streams (which they conceptualize as RxJS-like observables). Thoughts?
14:58:25  <bnoordhuis>DarkGod: correct
15:03:33  * julianduquejoined
15:17:07  * dddtest_97403joined
15:17:38  <rendar>bnoordhuis, can libuv do timed wait for a process?
15:17:45  <rendar>bnoordhuis, i saw thats painful on uni
15:17:47  <rendar>unix*
15:18:10  <bnoordhuis>rendar: not possible. it's async all the way, baby
15:18:27  <rendar>bnoordhuis, eheh yeah
15:18:50  * indexzerojoined
15:19:07  <rendar>bnoordhuis, btw, just for the sake of discussing, what about a cond.var. signalled on SIGCHLD completion? then another thread could wait (or timed wait) on that cond.var.
15:19:22  <rendar>s/signaled/broadcasted/
15:19:28  <bnoordhuis>rendar: you can't use condvars in signal handlers
15:20:02  <bnoordhuis>only sem_post() is async signal-safe iirc
15:20:05  <MI6>nodejs-master: #655 UNSTABLE osx-x64 (1/654) smartos-ia32 (6/654) linux-x64 (1/654) smartos-x64 (7/654) osx-ia32 (1/654) http://jenkins.nodejs.org/job/nodejs-master/655/
15:20:08  <bnoordhuis>okay, gotta run. biab
15:20:14  <rendar>bnoordhuis, ok bye :)
15:21:00  * c4miloquit (Remote host closed the connection)
15:21:35  * c4milojoined
15:26:16  * c4miloquit (Ping timeout: 264 seconds)
15:29:30  * kuebkquit (Quit: Leaving.)
15:31:49  * 36DABNT8Gjoined
15:32:09  * 36DABNT8Gquit (K-Lined)
15:32:14  * bradleymeckjoined
15:34:09  * c4milojoined
15:49:06  * c4milo_joined
15:49:30  * loladirojoined
15:52:13  * c4miloquit (Ping timeout: 245 seconds)
15:53:34  * bajtosjoined
15:54:07  <bajtos>bnoordhuis: ping
15:54:47  <MI6>joyent/node: tjfontaine created tag v0.11.8 - http://git.io/6NJuGQ
15:55:10  <MI6>joyent/node: Timothy J Fontaine master * bae4c90 : Now working on 0.11.9 (+2 more commits) - http://git.io/M51hQg
15:58:12  * superjoe30joined
16:06:07  * ryandotsmithjoined
16:07:15  * wrljoined
16:07:33  <isaacs>Domenic_: i think having binary/string streams as a special case of object streams is not terrible
16:07:47  <tjfontaine>how special of a case?
16:07:56  <Domenic_>that's the question, isn't it :)
16:07:56  <isaacs>tjfontaine: not very special, hopefully :)
16:07:58  <tjfontaine>oh this is web-js
16:08:08  <Domenic_>no it's supposed to be js generally
16:08:17  <tjfontaine>nod
16:08:35  <isaacs>it loses high water marks and buffering, which is a nice feature for some cases.
16:08:43  <isaacs>but it's also a feature that's kinda hard to get right
16:08:51  <Domenic_>i don't htink it necessarily does
16:08:51  <isaacs>especially in a general way
16:09:00  <Domenic_>what if you used the .length property of the objects, or defaulted to 1
16:09:15  <isaacs>Domenic_: yeah... meh.
16:09:19  <isaacs>Domenic_: that seems weird
16:09:33  <isaacs>Domenic_: so an array is counted as thenumber of items, but a giant-ass object is counted as one thing?
16:09:34  <Domenic_>seems nice, works for strings, arraybuffers, ...
16:09:42  <isaacs>it's a wart.
16:09:46  <MI6>joyent/node: Timothy J Fontaine v0.10 * 9f7f9d1 : blog: Post for v0.11.8 - http://git.io/WH_Rvg
16:09:47  <Domenic_>right, arrays are a bit of a strange case
16:09:50  <isaacs>warts always seem nice :)
16:09:54  <Domenic_>oh 0.11.8 yay
16:09:54  <isaacs>until you have to implement and use them :)
16:09:59  <isaacs>tjfontaine: ++
16:10:23  <tjfontaine>I let it build last night, but am just finishing up the last pieces today :)
16:10:27  <isaacs>tjfontaine: kewl
16:10:30  <Domenic_>i mean buffering is kind of crucial, no?
16:10:33  <tjfontaine>shall I go to a weekly cadence?
16:11:24  <isaacs>tjfontaine: YES! :)
16:11:27  <tjfontaine>sold.
16:11:40  <isaacs>tjfontaine: 0.10 is slowing down
16:11:48  <isaacs>let's get that drum beating for v0.12!
16:12:04  * ryandotsmithpart
16:12:18  <isaacs>Domenic_: well, it must buffer if data is being put in, and not taken out
16:12:41  <tjfontaine>tweetified
16:12:43  <isaacs>Domenic_: but, the "buffer" could just be "I have >0 things already"
16:13:58  <isaacs>Domenic_: for purposes of backpressure
16:14:31  * loladiroquit (Quit: loladiro)
16:14:50  <Domenic_>isaacs: in-ter-est-ing...
16:15:26  <isaacs>Domenic_: you could conceivably build high water buffering stuff on top of that, i suppose
16:16:49  <Domenic_>how useful is highWaterMark anyway
16:16:53  <Domenic_>do people often set it manually?
16:18:40  <MI6>nodejs-master: #656 UNSTABLE osx-x64 (2/654) smartos-ia32 (7/654) linux-x64 (1/654) smartos-x64 (11/654) osx-ia32 (2/654) linux-ia32 (4/654) http://jenkins.nodejs.org/job/nodejs-master/656/
16:18:44  <Domenic_>i don't see the vm bugfixes in this changelog
16:18:53  <isaacs>Domenic_: they're there.
16:19:07  <isaacs>Domenic_: but they're just a bugfix, and there's like, dozens of new features.
16:19:16  <isaacs>Domenic_: didn't make the cut for the changelog :)
16:19:34  <Domenic_>haha ok
16:20:01  <isaacs>bnoordhuis: can you find some time tonight/morrow/week to review the c++ bits of https://github.com/joyent/node/pull/6148?
16:20:13  <isaacs>(toweek? hrm. whatever, acceptable.)
16:21:05  * amartensjoined
16:21:10  * loladirojoined
16:21:20  * bajtosquit (Quit: bajtos)
16:23:06  <isaacs>Domenic_: also: "glimmer in implementors' eye" <-- Node is an implementor
16:23:08  <isaacs>(in this case)
16:24:03  <isaacs>Domenic_: I think Promises and Streams are actually at similar levels of abstraction, in terms of being conceptual primitives in async JS progrmming
16:24:36  <isaacs>Domenic_: having one depend on the other seems odd to me
16:24:41  <indutny>bnoordhuis: and I'm back
16:24:56  * hzjoined
16:25:30  <Domenic_>isaacs: i think promises are at the callback level of abstraction. so if streams depend on callbacks, then they might as well depend on promises.
16:25:40  * bnoordhu1sjoined
16:26:46  <isaacs>Domenic_: i'm not conviced they're any better than callbacks, i guess is my point.
16:27:07  <indutny>different approaches to the same problem, IMHO
16:27:13  <isaacs>Domenic_: they're certainly not faster in most cases, if you take advantage of V8's function handling (and don't shoot the JIT in the head)
16:27:15  <Domenic_>isaacs: sure, that's fair. most other people are, though :P
16:27:16  <indutny>just oriented in different directions
16:27:36  <isaacs>Domenic_: and, it's easy enough to do "return promise if no cb given, otherwise call the cb when you have a value"
16:27:48  <isaacs>Domenic_: they ARE a higher level of abstraction than callbacks.
16:28:13  <isaacs>foo(cb) vs foo().then(cb)
16:28:29  <isaacs>in the first case, there's no promise object created, and the return value of cb is irrelevant
16:28:58  <Domenic_>yes, i'm aware you can apply legacy back-compat patterns to allow consumers used to node.js-style apis their flavor as well.
16:29:06  <bradleymeck>there are some interesting optimizations that Promises may afford for host objects though is what I am seeing in the W3C side of things, unsure if it can be applied to node/libuv
16:29:07  <isaacs>you can *ignore* the difference, in many cases, but there IS a difference in abstraction level
16:29:47  <isaacs>back-compating from Promises to cb is not ever going to be as cheap as treating callbacks as first-class, and creating a promise only if you don't get a cb
16:30:16  * bajtosjoined
16:30:22  <Domenic_>right, and functions will never be as cheap as longjmp
16:30:46  <isaacs>come now, callbacks aren't goto
16:30:58  <MI6>nodejs-v0.10: #1571 UNSTABLE smartos-x64 (8/603) smartos-ia32 (6/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1571/
16:30:58  <isaacs>i'm not saying that abstraction as such is a bad thing
16:31:05  <isaacs>i'm saying that promises are more abstraction that callbacks
16:31:12  <isaacs>and that abstraction costs.
16:31:47  <isaacs>if we're building something that's going to be called zillions of times per second, these sorts of microoptimizations kinda matter.
16:32:10  * indexzeroquit (Quit: indexzero)
16:32:51  <Domenic_>i agree they are more an abstraction, i went down the wrong direction with that argument
16:33:01  <rendar>isaacs, i agree, the highest level of abstraction, the slower it will execute :)
16:33:03  <isaacs>Domenic_: fair enough :)
16:34:01  <Domenic_>isaacs: in happier news: https://github.com/isaacs/npm/pull/4058 :O!
16:34:06  <isaacs>Domenic_: when I say "language primitive", i guess what i really mean is, "language primitive that is optimized the way that functions, arrays, and objects are optimized"
16:34:34  <bnoordhu1s>bajtos: pong
16:34:49  <MI6>nodejs-master-windows: #445 UNSTABLE windows-x64 (26/654) windows-ia32 (29/654) http://jenkins.nodejs.org/job/nodejs-master-windows/445/
16:34:52  <isaacs>Domenic_: adding to review queue :)
16:36:37  <isaacs>Domenic_: hmm.. this implementation is not so great.
16:37:12  <isaacs>Domenic_: the point of #3313 is to *remove* a lib/utils/ file completely, not add another one :0
16:37:45  * abraxasjoined
16:38:39  <Domenic_>isaacs: by remove you mean move to a new package?
16:41:48  * indexzerojoined
16:41:57  * abraxasquit (Ping timeout: 246 seconds)
16:42:10  * TooTallNatejoined
16:45:31  * c4milo_quit (Remote host closed the connection)
16:46:03  * c4milojoined
16:47:00  * loladiroquit (Quit: loladiro)
16:50:52  * c4miloquit (Ping timeout: 264 seconds)
16:50:53  * julianduquequit (Quit: leaving)
16:50:54  * loladirojoined
16:52:09  <trevnorris>morning all
16:53:00  * octetcloudjoined
16:55:50  <indutny>morning
16:56:37  * indexzeroquit (Quit: indexzero)
16:57:18  * c4milojoined
17:03:09  * paulfryzeljoined
17:03:46  <trevnorris>isaacs: see anything wrong here?
17:03:46  <trevnorris>buffers/buffer-creation.js type=fast len=10 n=1024: 5116.5
17:03:46  <trevnorris>buffers/buffer-creation.js type=slow len=10 n=1024: 2762.6
17:04:00  <trevnorris>oh wait. nm
17:04:21  <trevnorris>seriously got to get more sleep
17:04:24  <tjfontaine>heh
17:04:47  * ryandotsmithjoined
17:04:48  <isaacs>trevnorris: and THIS is why we pick one (bigger|smaller)-is-better option and stick with it! ;)
17:05:15  <isaacs>Domenic_: yes, move to a new package.
17:05:18  <isaacs>Domenic_: i've got it partly written already
17:05:32  <isaacs>grndcr's taking too long :
17:05:33  * bnoordhu1squit (Ping timeout: 245 seconds)
17:05:35  <isaacs>)
17:05:40  <trevnorris>isaacs: well I have, but forget that you chose the other ;P
17:05:54  <isaacs>trevnorris: i very much prefer bigger-is-better
17:06:09  <isaacs>though, it doesn't expose the asymptotic nature of extended perfectionism
17:06:24  <isaacs>sometimes the difference betweeen 1MM ops and 10MM ops is negligible, fo rexample.
17:06:32  * ryandotsmithpart
17:06:44  <isaacs>the diff between 0.001 and 0.00001 is more clearly irrelevant
17:07:18  <trevnorris>heh, and i measure buffer operations by ns
17:07:58  * bnoordhu1sjoined
17:12:13  * AvianFluquit (Remote host closed the connection)
17:14:14  * bnoordhu1squit (Ping timeout: 240 seconds)
17:15:40  <MI6>node-review: #99 UNSTABLE osx-x64 (1/654) smartos-x64 (11/654) centos-x64 (5/654) windows-x64 (24/654) linux-x64 (2/654) osx-ia32 (3/654) windows-ia32 (31/654) centos-ia32 (4/654) smartos-ia32 (8/654) http://jenkins.nodejs.org/job/node-review/99/
17:16:21  <trevnorris>bnoordhuis: perf list isn't showing any tracepoint events. swear remember you telling me how I might get those. I checked and CONFIG_EVENT_TRACING=y
17:16:29  <trevnorris>and google is just sucking right now
17:16:54  * bradleymeckpart
17:18:21  <trevnorris>actually, let me hit up the irc channel about it
17:21:46  * indexzerojoined
17:23:39  * sblomjoined
17:35:02  * AvianFlujoined
17:36:01  <trevnorris>oh man, i'm a dip. needed to run it as root. :P
17:43:57  <indutny>bnoordhuis: yt?
18:04:45  * einaros_quit (Quit: Lost terminal)
18:05:13  * einarosjoined
18:06:57  * dshaw_joined
18:10:38  * defunctzombie_zzchanged nick to defunctzombie
18:13:13  * piscisaureus_joined
18:14:47  <piscisaureus_>isaacs: i'm not un-interested in spawnSync but it doesn't have much priority for me
18:15:01  <piscisaureus_>isaacs: eventually if nobody touches it I will finish it off
18:15:17  <piscisaureus_>isaacs: I wonder though what's wrong with the js bits? Style?
18:15:22  <isaacs>piscisaureus_: k, good to know
18:15:23  <MI6>nodejs-v0.10-windows: #295 UNSTABLE windows-ia32 (13/603) windows-x64 (13/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/295/
18:15:38  <isaacs>piscisaureus_: just a few style nits, and some missed optimization opportunities
18:15:47  <piscisaureus_>oh wait there's comments :)
18:15:49  <isaacs>piscisaureus_: mostly that's minor
18:15:55  <isaacs>piscisaureus_: yeah, what trevnorris said about it, basically
18:16:02  <isaacs>piscisaureus_: the bigger thing is the lack of execSync :)
18:16:47  * hzquit
18:20:50  * bnoordhu1sjoined
18:21:55  <piscisaureus_>isaacs: actually it's mostly the tests :)
18:22:16  <isaacs>piscisaureus_: oh, yeah, that too :)
18:22:23  <piscisaureus_>isaacs: I can write execSync on the back of a napkin - I just wasn't sure about the api you had in mind for that :)
18:22:32  <isaacs>piscisaureus_: i can spend a bit of time on it before next week's 0.11, probably
18:22:40  <piscisaureus_>cool
18:22:49  <isaacs>piscisaureus_: and yeah, execSync is strictly API design, the functional bits are clearly all there.
18:23:00  <isaacs>it's more art than science now :)
18:24:51  * bnoordhu1squit (Ping timeout: 246 seconds)
18:25:00  * DarkGodquit (Ping timeout: 245 seconds)
18:27:17  * inolenjoined
18:29:48  <trevnorris>i forget, how do you pass cflags to configure?
18:33:09  <trevnorris>nm
18:38:16  * sblomquit (Ping timeout: 256 seconds)
18:38:38  * abraxasjoined
18:41:10  * FROGGSquit (Read error: Connection reset by peer)
18:41:23  * dshaw_quit (Quit: Leaving.)
18:41:28  * FROGGSjoined
18:42:38  * inolenquit (Quit: Leaving.)
18:43:04  * abraxasquit (Ping timeout: 264 seconds)
18:48:12  * inolenjoined
18:49:19  * bradleymeckjoined
18:55:28  * julianduquejoined
19:00:53  * mikealjoined
19:02:12  <trevnorris>bnoordhuis: what's op: 3 in epoll_ctl ?
19:03:15  * amartensquit (Quit: Leaving.)
19:04:28  * piscisaureus_quit (Ping timeout: 240 seconds)
19:10:18  <isaacs>trevnorris: what's the status on 6011? you said something about landing part of it, but keeping the rest around for further review?
19:10:40  <trevnorris>isaacs: done did :)
19:10:47  <trevnorris>and cleaned it up. it's ready for merge whenever
19:10:51  <isaacs>kewl!
19:11:05  <trevnorris>indutny: ping
19:11:06  * st_lukejoined
19:13:31  <trevnorris>bnoordhuis: did a perf stat of chunked at not. here's some of the results: https://gist.github.com/trevnorris/7238286
19:20:35  * defunctzombiechanged nick to defunctzombie_zz
19:31:07  * bajtosquit (Quit: bajtos)
19:32:02  * defunctzombie_zzchanged nick to defunctzombie
19:34:07  * amartensjoined
19:38:28  * amartensquit (Ping timeout: 245 seconds)
19:38:42  <trevnorris>ok, while looking at exec sync I have to keep reminding myself, "it's not meant to be fast, it's not meant to be fast."
19:38:53  <trevnorris>makes me huddle in a corner somewhere.
19:52:31  <isaacs>trevnorris: well, it's not meant to be fast, per se, but it's also not meant to be unnecessarily slow
19:52:34  <indutny>trevnorris: pong
19:53:48  <indutny>bnoordhuis: ping
19:56:05  * brsonjoined
19:58:33  * midimajoined
20:00:53  * bajtosjoined
20:03:40  * st_lukequit (Read error: Connection reset by peer)
20:03:58  * st_lukejoined
20:05:30  <roxlu>indutny: are you experienced with SSE?
20:05:41  <indutny>what SSE do you mean?
20:06:45  <roxlu>simd, __m128
20:06:54  <indutny>roxlu: a bit
20:06:58  <indutny>roxlu: what's up?
20:07:04  <roxlu>ah awesome : )
20:07:23  <roxlu>indutny: I posted my question here: https://gist.github.com/roxlu/f1fe9c4c7dda433709d4
20:07:47  <roxlu>I wrote it down there because I needs some explanation
20:08:36  * AvianFlu_joined
20:08:45  <indutny>roxlu: hah, I'm afraid I don't know that much about it, sorry
20:08:55  <indutny>like, I know what it does
20:09:05  <indutny>but nothing about performance
20:09:09  <indutny>or optimization tips
20:09:19  <roxlu>ok, I'm a noob with this too
20:09:39  <roxlu>trying to find someone who knows more about this stuff
20:10:25  * bajtosquit (Quit: bajtos)
20:10:46  <indutny>bnoordhuis might be the right person
20:11:51  <roxlu>ping bnoordhuis
20:12:01  <indutny>roxlu: what if you'll cache force?
20:12:14  * AvianFluquit (Ping timeout: 240 seconds)
20:12:29  <indutny>try making it static
20:12:42  <roxlu>indutny: the _mm_prefetch fetch data into the cache
20:12:47  <roxlu>making what static
20:12:49  <roxlu>?
20:12:56  <indutny>force_x, force_y
20:12:57  * midimaquit (Read error: Connection reset by peer)
20:13:03  <indutny>hah
20:13:07  <indutny>it won't make it faster
20:13:07  <indutny>nvm
20:13:49  <roxlu>my code is definitely slow because of cache misses
20:14:00  <indutny>interesting
20:14:12  <indutny>as I understand - you're using Visual Studio?
20:14:19  <roxlu>no linux, gcc
20:14:22  <indutny>hm...
20:14:23  <indutny>ok
20:14:31  <indutny>you see, I'm total noob here
20:14:49  <indutny>it seems to be wasting time in interesting places
20:14:52  <roxlu>yeah np, thanks for at least tryign : )
20:14:53  <roxlu>nah
20:15:06  <roxlu>oh yeah, trying to look into it now
20:15:14  <indutny>vmovap
20:15:22  <indutny>seems like a cache failure
20:15:26  <indutny>as you said
20:15:35  <roxlu>yeah
20:15:50  <roxlu>I'm curious why I have "add" and "vaddps" in that log
20:15:54  <roxlu>here https://gist.github.com/roxlu/f1fe9c4c7dda433709d4#file-perf-log-L35-L37
20:16:27  <indutny>you're seems to be prefetching wrong stuff
20:16:31  <indutny>prefet (%rdx) ▒
20:16:31  <indutny> │ prefet 0xc00(%rdx)
20:16:35  <indutny> vmovap -0x10(%rdx),%xmm0
20:16:46  <indutny>may be this is the answer?
20:16:57  <indutny>again, I'm not really proficient here
20:17:31  <roxlu>from my understanding it's prefetching the particles: https://gist.github.com/roxlu/f1fe9c4c7dda433709d4#file-main-cpp-L113-L114 or it should
20:19:23  <indutny>yeah, I know
20:19:45  <roxlu>maybe it's just the data structure which is failing
20:20:42  * indexzeroquit (Quit: indexzero)
20:22:12  <indutny>roxlu: I'm not sure what to say
20:22:14  <indutny>;)
20:22:26  * bnoordhu1sjoined
20:22:27  <indutny>roxlu: but just curious if you'll prefetch previous element
20:22:33  <indutny>what code would it generate?
20:22:41  <roxlu>maybe you know of other channels where people might know this?
20:23:08  <roxlu>prefetch previous element?
20:23:17  <indutny>ah wait
20:23:26  <indutny>I just realized that its mostly ok
20:24:07  <indutny>also, I think you're not prefetching all stuff
20:24:19  <indutny>if I remember correctly - cache lines are usually 256 bytes
20:24:34  <roxlu>oh ha! I was told 4096 bytes :)
20:25:08  <roxlu>but indeed, when not using prefecthing my code is actually faster :) haha
20:25:21  <indutny>or even 128
20:25:23  <indutny>haha
20:25:26  <indutny>ok, so that was it
20:25:32  <indutny>you was playing bad games with cache
20:25:54  <indutny>I think CPU should be smart enough to load next lines automatically
20:26:07  <indutny>when you're processing it sequentially
20:26:08  <roxlu>hmm not sure about that ^.^
20:26:16  <indutny>well, it usually does
20:26:20  <indutny>you can try it out
20:26:24  <indutny>and tell me if it'll work for you :P
20:26:29  <indutny>I mean
20:26:35  <indutny>benchmark right prefetching vs no prefetching
20:26:41  <roxlu>yeah
20:26:53  <roxlu>but I'm not sure how to use correct prefetching
20:27:13  <indutny>I don't know sizeof(_m256)
20:27:21  <indutny>does it mean 256 bits?
20:27:31  <roxlu>yes
20:27:51  <indutny>then one your structure is 192
20:27:53  <indutny>bytes
20:27:59  <roxlu>yep
20:28:00  <indutny>or 96
20:28:01  <roxlu>or
20:28:02  <roxlu>yes
20:28:13  <indutny>not really good for aligning :P
20:28:18  <indutny>well, it works
20:28:28  <indutny>ah, anyway
20:28:36  <roxlu>so I was thinking: cache_size / sizeof(particle_group)
20:28:45  <roxlu>and then the best power of two values
20:28:48  <roxlu>value
20:28:51  * vladsemenjoined
20:29:05  <indutny>I would try prefetching next structure
20:29:10  <indutny>even next two structures
20:29:21  <indutny>just for testing purposes
20:29:33  * kostrikoljoined
20:29:54  * kostrikolquit (Read error: Connection reset by peer)
20:30:05  <indutny>say every 4th structure
20:30:06  <roxlu>so would that be: _mm_prefetch(particles + i, _MM_HINT_T0) ?
20:30:12  <indutny>I guess it'll be
20:30:16  <indutny>if (i % 4 == 0)
20:30:19  <indutny>{
20:30:26  <indutny>_mm_prefetch(particles + i + 1, ...)
20:30:30  * defunctzombiechanged nick to defunctzombie_zz
20:30:34  <indutny>_mm_prefetch(particles + i + 2, ...)
20:30:40  <indutny>_mm_prefetch(paritcles + i + 3, ...)
20:30:40  <indutny>}
20:30:43  <indutny>something like this
20:30:51  <indutny>well
20:30:57  <indutny>you may also try skipping the middle one
20:30:58  <indutny>i + 2
20:31:02  <indutny>it should be loaded anyway
20:31:09  <indutny>in either +1 line of cache
20:31:12  <indutny>or in +3's one
20:31:15  <roxlu>but _mm_prefetch "loads one cache line of data"
20:31:24  <roxlu>wouldn't that be 256 bytes?
20:31:34  <indutny>well, depends on your machine
20:31:34  <roxlu>if I do: _mm_prefetch(particles + i,..) ?
20:31:35  <indutny>could be smaller
20:31:37  <roxlu>yeah
20:31:43  <indutny>just give it a try :P
20:31:47  <indutny>I'm really curious
20:31:54  <roxlu>but if we assume 256 bytes, it would load 256 bytes right?
20:32:03  <indutny>it should
20:32:29  * indexzerojoined
20:33:07  <roxlu>soL _mm_prefetch(particles i + 2, would load "256" bytes, starting at particles[i + 2] ?
20:33:20  <roxlu>(which means some data will be loaded twices, one by + 1 and one by + 2
20:33:29  <indutny>I guess
20:33:33  <indutny>well
20:33:39  <indutny>you can try different numbers
20:33:43  <indutny>and see which one will work best for you
20:34:36  <roxlu>doing 4 prefetches is a bit faster
20:34:42  <roxlu>0.148 compared to 0.151
20:34:57  * amartensjoined
20:35:16  <indutny>ok, that's nice
20:35:26  <indutny>still it is a bit slow, right?
20:35:35  <roxlu>yeah it should be: 0.06
20:35:48  <indutny>what if you'll remove all prefetches?
20:35:49  <roxlu>or that is what I got before using a different solution
20:36:00  <roxlu>~0.15 w/o prefetches
20:36:39  <indutny>hm...
20:36:41  <indutny>quite shitty
20:36:42  <indutny>brb
20:37:07  <roxlu>funny.. .uv_hrtime seems to use sse :)
20:39:21  * amartensquit (Ping timeout: 240 seconds)
20:39:27  * abraxasjoined
20:40:17  * hzjoined
20:43:48  * abraxasquit (Ping timeout: 246 seconds)
20:53:15  * AvianFlu_quit (Remote host closed the connection)
20:53:35  <bnoordhu1s>indutny: nice work on the test case
20:53:43  <indutny>bnoordhu1s: haha, not really
20:53:48  <indutny>bnoordhu1s: I tried 3 other choices
20:53:55  <indutny>bnoordhu1s: using pipe() and uv_pipe_t
20:54:00  <indutny>bnoordhu1s: using uv__io_init()
20:54:01  * bnoordhuisquit (Quit: leaving)
20:54:05  <indutny>and other stuff
20:54:06  * bnoordhu1schanged nick to bnoordhuis
20:54:17  <indutny>uv__io_init() was working, actually
20:54:28  <indutny>but I thought that it is a wrong idea to rely on internals in tests
20:54:42  <bnoordhuis>yes, very much agreed :)
20:55:07  <bnoordhuis>sometimes you can't avoid it but yeah, preferably you don't
20:55:13  <indutny>bnoordhuis: yiech
20:55:16  <indutny>bnoordhuis: UV_FS_EVENT_RECURSIVE=3
20:55:21  <indutny>seems like a mistake
20:55:40  <isaacs>trevnorris: Probably better to split this into separate tests: http://jenkins.nodejs.org/job/node-pullrequest/1471/DESTCPU=x64,label=osx/tapTestReport/test.tap-5/
20:56:17  <trevnorris>isaacs: interesting. will do. thanks.
20:56:51  * inolenquit (Quit: Leaving.)
20:57:06  <trevnorris>indutny: use perf trace to collect some data about http chunked, and see that writev is used, but not used when content-length is specified: https://gist.github.com/trevnorris/7238286
20:57:43  <trevnorris>indutny: and i don't understand the specifics enough to know why. was hoping you could explain a little :)
20:57:44  * mikealquit (Quit: Leaving.)
20:58:12  * mikealjoined
20:58:18  <indutny>huh?
20:58:28  <indutny>use the source, luke :P
20:58:41  <indutny>can you give me the source of your tests?
20:59:03  * c4milo_joined
20:59:18  * c4miloquit (Ping timeout: 245 seconds)
20:59:34  <trevnorris>just ran benchmark/http_simple.js, hit it with ./wrk -c 32 -t 4 -d 10 'http://127.0.0.1:8000/bytes/1024' (and '/bytes/1024/2'), collected that using perf trace.
21:00:14  <trevnorris>chunked.out is the '/bytes/1024/2' and not-chunked.out is '/bytes/1024'
21:00:19  <bnoordhuis>indutny: mistake? how so?
21:00:27  <indutny>bnoordhuis: it is a flag
21:00:31  <indutny>bnoordhuis: and checked using &
21:00:39  <indutny>and we have flags with 1 and 2 value
21:00:40  <indutny>:P
21:04:22  <bnoordhuis>right
21:04:31  <bnoordhuis>that counts as a mistake, yes
21:06:05  <bnoordhuis>hm, you mean this? -> if ((handle->cf_flags & UV_FS_EVENT_RECURSIVE) == 0) {
21:06:13  * vladsemenquit (Ping timeout: 248 seconds)
21:07:10  <roxlu>__attribute((
21:07:13  <MI6>joyent/libuv: Fedor Indutny master * 43bef41 : fsevents: report errors to user - http://git.io/njYpkw
21:07:14  <roxlu>oops sorry
21:07:21  <bnoordhuis>right, node doesn't pass any UV_FS_EVENT_* flags whatsoever right now. that's why it never got triggered
21:07:40  <indutny>yes, exactly
21:07:47  <indutny>but it'll in a couple of minutes
21:07:49  <indutny>in master, though
21:07:55  <indutny>can I just fix it without reviewal?
21:07:58  <indutny>I mean in libuv
21:08:05  <bnoordhuis>if you don't screw it up :)
21:08:14  <bnoordhuis>and make the commit log great!
21:08:57  <bnoordhuis>indutny: on that subject, 43bef41 could go into a little more detail...
21:09:08  <roxlu>bnoordhuis: are you experienced with SSE/SIMD?
21:09:12  <bnoordhuis>i'm not a fan of oneliner commit logs
21:09:20  <bnoordhuis>roxlu: somewhat. why do you ask?
21:09:51  <roxlu>I'm experimenting with a particle system, took some time to look into different ways to organize my data
21:10:21  * AvianFlujoined
21:10:24  <roxlu>I experimented with a SoA, AoS, with and w/o simd
21:10:38  <roxlu>I got really good results with SoA + SIMD,
21:11:09  <roxlu>someone told me I should use AoSoA (Arrays of Structures of Arrays)
21:11:17  <bnoordhuis>oh, that kind of soa :)
21:11:18  <MI6>joyent/libuv: Fedor Indutny master * 8a4aa22 : include: UV_FS_EVENT_RECURSIVE is a flag - http://git.io/eSBJdQ
21:11:21  <roxlu>but it seems to be way slower
21:11:22  <roxlu>haha
21:11:26  * dddtest_97403quit (Remote host closed the connection)
21:11:34  <roxlu>yeah in dutch it has some other meaning ^.^
21:11:46  <bnoordhuis>quite :)
21:12:02  <indutny>bnoordhuis: good enough?
21:12:04  <roxlu>hehe in relations to optimization it's even funnier : )
21:12:19  <bnoordhuis>indutny: it's never good enough but it sure is better
21:12:35  <bnoordhuis>roxlu: are you streaming data to the gpu or ?
21:12:38  <roxlu>bnoordhuis: I've posted my question here https://gist.github.com/roxlu/f1fe9c4c7dda433709d4
21:12:43  <roxlu>no, it's cpu
21:13:08  <MI6>joyent/node: Nick Simmons master * 33c9f0c : fs: Added recursive subdirectory support to watch - http://git.io/ngtEIw
21:13:25  <bnoordhuis>indutny: ^ present tense, s/Added/add/
21:13:32  <indutny>argh
21:13:34  <indutny>force push?
21:13:51  <bnoordhuis>well... that gets tj upset
21:13:59  <bnoordhuis>was there really a conflict?
21:14:02  <indutny>tjfontaine: sorry
21:14:13  <MI6>joyent/node: Nick Simmons master * 691b9eb : fs: add recursive subdirectory support to fs.watch - http://git.io/liSIbw
21:15:05  <bnoordhuis>roxlu: can you give me the executive summary? i don't really have time to read through the entire example
21:15:51  <roxlu>I'm yep I'll post a short example ( I removed lots of code)
21:16:23  * indexzeroquit (Quit: indexzero)
21:16:45  <MI6>joyent/libuv: Fedor Indutny v0.10 * f996018 : test: add regression test for 29fdb3471 - http://git.io/-c9LKQ
21:17:05  <indutny>bnoordhuis: I'm on the wave
21:17:15  <indutny>bnoordhuis: thanks for reviewing all that shit
21:17:17  <bnoordhuis>indutny: make sure you don't fall off
21:17:50  <indutny>ok, now I have only 18 letters in my inbox
21:18:07  <roxlu>bnoordhuis: https://gist.github.com/roxlu/c1a61e2b1ca85f843043#file-perf-log-L5 that's the one I don't understand (besides that this code takes way to much time)
21:18:42  <roxlu>the line numbers in the perf.log are wrong now as I cut only part of the code
21:20:19  * julianduquequit (Quit: leaving)
21:20:30  <bnoordhuis>roxlu: 55% for an add? did you check what byte sequence is generated?
21:20:44  <bnoordhuis>if it's a 32 bits add, then i guess it makes sense it's slow
21:20:57  <roxlu>what do you mean? (and how can I check)
21:21:14  <trevnorris>isaacs: bugger. testing for error asynchronous error catching is sort of a pain in the butt. :P
21:21:23  <bnoordhuis>roxlu: 55.13 │ add $0x1,%ecx <- that's the expensive one, right?
21:21:30  * dshaw_joined
21:21:31  <roxlu>yeah
21:21:46  <bnoordhuis>so, sometimes gcc generates terrible code for loop counters
21:21:49  <roxlu>but what did you mean with "what byte sequence is generated" ?
21:21:57  <roxlu>yeah I thought it was my loop counter indeed
21:22:01  <bnoordhuis>sorry, i mean what opcode does it actually generate :)
21:22:18  <bnoordhuis>what does it look like when you disassemble it in gdb?
21:22:19  <roxlu>bnoordhuis: can I export or see to opcode in some way?
21:22:39  <bnoordhuis>^ see above :) disassembling with objdump would also work
21:22:47  <roxlu>wah?
21:22:49  * roxlugoogling
21:22:53  <indutny>bnoordhuis: one PR left :P
21:23:03  * bradleymeckquit (Quit: bradleymeck)
21:23:20  <indutny>ah
21:23:21  <indutny>nvm
21:23:35  <trevnorris>tjfontaine: is there a way to run a single test on the windows machine? there's one that no way should be failing, but it is.
21:23:36  <indutny>isaacs: May I ask you to review this, please: https://github.com/joyent/node/pull/6428 ?
21:23:39  <indutny>or tjfontaine trevnorris ^
21:23:52  <bnoordhuis>roxlu: maybe press 'o' in perf's disassembly view
21:23:55  <indutny>bnoordhuis already reviewed most of my stuff, so I don't want to bother him much
21:24:00  * piscisaureus_joined
21:24:03  <indutny>bnoordhuis: odd perf timings, right?
21:24:05  <bnoordhuis>roxlu: iirc that gives you addresses
21:24:16  <indutny>bnoordhuis: add $1, %ecx couldn't be that slow
21:24:23  <roxlu>ak (I'm new to perf ... found it today but loving it already)
21:24:24  <indutny>in any condition
21:24:27  <indutny>if only!
21:24:44  <indutny>bnoordhuis: if only it isn't on a cache-line boundary
21:24:47  <indutny>haha
21:24:49  <bnoordhuis>indutny: i've seen code like that before, it sometimes happens when the loop body is really fast that the counter dominates
21:25:03  <indutny>bnoordhuis: it could be on next cache line anyway
21:25:10  <indutny>bnoordhuis: and evicted because of that mm_prefetch things
21:25:27  <bnoordhuis>possible. easy to check with perf if your cpu supports it
21:25:30  <roxlu>bnoordhuis: ok I got the addresses now
21:25:38  <bnoordhuis>and?
21:25:39  <indutny>GIVE US THE ADDRESSES
21:25:40  <LOUDBOT>WHY DOES THE LOUD BOT WANT US TO STOP SHOUTING?
21:25:45  <roxlu>you want to see the address?
21:25:53  <roxlu>(sorry I'm a total noob with this)
21:26:06  <bnoordhuis>addresses, plural :) to calculate the instruction size
21:26:22  <roxlu>https://gist.github.com/roxlu/bfd0b15514dc85a6e7d8
21:26:23  <bnoordhuis>i.e. the address of the instruction itself and the one after that
21:26:27  <indutny>bnoordhuis: I guess it is 6 bytes
21:26:40  <indutny>nah
21:26:41  <indutny>4 bytes
21:26:53  <indutny>and it seems to be indeed in next cache line
21:26:54  <indutny>:P
21:26:59  <indutny>if I understand it correctly
21:27:08  * dshaw_quit (Quit: Leaving.)
21:27:10  <roxlu>indutny: how do you see that so quickly? (4 bytes + cache line)
21:27:24  <indutny>roxlu: hex calculator implant
21:27:29  <roxlu>haha
21:27:41  <indutny>roxlu: surgery in a childhood
21:27:45  <bnoordhuis>it's unaligned though that shouldn't matter too much
21:27:51  <roxlu>I want one :)
21:28:46  <roxlu>bnoordhuis: so not a gcc loop counter issue?
21:29:21  <bnoordhuis>probably not. it's only 0.82% now btw
21:29:40  <bnoordhuis>what flags do you use when compiling?
21:30:09  <roxlu>-Os
21:30:20  <roxlu>and -march=native -msse
21:30:20  <bnoordhuis>ah. try -O3 :)
21:30:23  <roxlu>ok
21:30:32  <bnoordhuis>also, 0x60 is kind of an odd stride
21:30:38  <MI6>nodejs-master: #657 UNSTABLE osx-x64 (2/655) smartos-ia32 (7/655) linux-x64 (1/655) smartos-x64 (9/655) osx-ia32 (2/655) linux-ia32 (1/655) http://jenkins.nodejs.org/job/nodejs-master/657/
21:30:45  <roxlu>these are all options: -O3 -march=native -msse -msse4.1 -msse4.2 -mavx
21:31:05  <bnoordhuis>okay, good
21:31:06  * dg_joined
21:31:42  <roxlu>https://gist.github.com/roxlu/31aaf72432694e812dfe
21:32:00  * mikealquit (Read error: Connection reset by peer)
21:32:15  * mikealjoined
21:32:32  <roxlu>is there a better way to check what source code causes the 'add $0x1,%ecx' ? (or any other asm)
21:32:55  <trevnorris>indutny: done
21:32:56  <bnoordhuis>roxlu: disassemble/m in recent versions of gdb
21:32:59  <indutny>trevnorris: thanks
21:33:25  <bnoordhuis>curious that gcc generates an add rather than an inc. i wonder why that is
21:33:41  <roxlu>I've got: GNU gdb (GDB) 7.6.1
21:33:56  * sblomjoined
21:34:28  * defunctzombie_zzchanged nick to defunctzombie
21:34:38  <bnoordhuis>roxlu: yeah, that should work
21:34:44  <roxlu>wow I thought trying to use s uint64_t :) and my timings go from 0.07 to 0.12 : )
21:35:10  <roxlu>bnoordhuis: I assume I don't need to compile with -ggdb ?
21:35:16  <bnoordhuis>no, not necessary
21:35:26  <bnoordhuis>btw, how many cycles do you perf?
21:35:38  <bnoordhuis>if they're really short runs, then it's probably not that representative
21:35:50  * amartensjoined
21:35:55  <roxlu>16227
21:35:57  <roxlu>samples
21:36:15  <roxlu>9K of event samples
21:36:21  <roxlu>uhh event cycles
21:36:50  <bnoordhuis>right. that's not nearly enough for accurate sampling :)
21:37:07  <bnoordhuis>try perf record with e.g. -c 5000
21:37:25  * pachetquit (Quit: leaving)
21:37:31  <bnoordhuis>make sure you have a fast hard disk with lots of free space :)
21:37:45  <roxlu>like: perf record -c 5000 ./particle_performance ?
21:38:00  <bnoordhuis>yeah, and probably -i
21:38:12  <roxlu>ok, got 1M cycles now :)
21:38:29  * roxlunot sure what it means though
21:39:00  <bnoordhuis>lower values of -c mean that more samples get recorded
21:39:09  <bnoordhuis>the default granularity is pretty coarse
21:39:17  <bnoordhuis>not that useful when you're profiling a single hot loop
21:39:39  <roxlu>ok good to know, so using -c 5000 -i is "better"
21:39:47  <bnoordhuis>yeah. you can go even lower if your machine can kee up
21:39:49  <bnoordhuis>*keep up
21:39:55  <roxlu>ok
21:39:56  <bnoordhuis>btw, did you specify any events with -e?
21:40:11  <roxlu>hmm not that I'm aware of
21:40:20  <roxlu>how do I specify an event?
21:40:28  <bnoordhuis>with -e :)
21:40:33  * roxluso many questions... only touching the surfce here
21:40:40  * amartensquit (Ping timeout: 264 seconds)
21:40:40  <bnoordhuis>e.g. -e cycles:u only records cpu cycles in user mode
21:40:41  <roxlu>so I just add -e ?
21:40:57  <bnoordhuis>as opposed to -e cycles:k which only records kernel side cpu cycles (which you're not interested in)
21:41:10  <roxlu>ok, should I do that ? -e cycles:u ?
21:41:17  <bnoordhuis>yes :)
21:41:24  <bnoordhuis>btw, check `perf list` for a list of events
21:41:30  <roxlu>ok cool
21:41:43  <roxlu>so when I start gdb, how do I get the dissambler?
21:42:11  <bnoordhuis>it's built in. type `help disassemble` and it'll tell you how it works
21:42:34  <bnoordhuis>the /m switch is a recent addition, from gdb 7.2 iirc
21:43:17  <MI6>nodejs-master: #658 UNSTABLE osx-x64 (1/655) smartos-ia32 (5/655) smartos-x64 (9/655) http://jenkins.nodejs.org/job/nodejs-master/658/
21:47:30  * dshaw_joined
21:50:09  <roxlu>hmm /disassemble /m doesn't show me more info: https://gist.github.com/roxlu/290fbea635d9021de25e
21:53:12  * c4milo_quit (Remote host closed the connection)
21:53:31  <bnoordhuis>roxlu: add -g3 :)
21:53:46  * c4milojoined
21:54:02  <roxlu>I added -ggdb, or is that not so good?
21:55:52  <bnoordhuis>-ggdb with -g might be a no-op, it just tells gcc to assume gdb extensions
21:56:18  <bnoordhuis>er, *without -g
21:56:23  <trevnorris>isaacs: it cool if I test the changes on the 6011-isfinal branch?
21:56:25  <roxlu>ok
21:56:38  <trevnorris>i'd like to be able to run jus that test again, but probably not possible...
21:57:35  <roxlu>bnoordhuis: it seems to be the counter indeed: https://gist.github.com/roxlu/3be5b919b495094a402f#file-gistfile1-txt-L179
21:57:39  <MI6>joyent/node: Fedor Indutny master * ba7c9ce : tls: do not default to 'localhost' servername (+1 more commits) - http://git.io/bHt9wg
21:57:50  * c4miloquit (Ping timeout: 240 seconds)
21:58:33  <roxlu>(oh but now I tried to force a uint32 ..)
21:59:00  <indutny>ON THE WAVE
21:59:01  <LOUDBOT>PACKAGE CANNOT BE USED EXCEPT TO REFER TO A BOX PEOPLE
21:59:03  <indutny>bnoordhuis: you still there?
21:59:09  <indutny>bnoordhuis: I forgot about https://github.com/joyent/libuv/pull/971
21:59:15  <indutny>because you never replied to it
21:59:18  <indutny>and it didn't get into my inbox
21:59:22  <groundwater_>trevnorris: where is that branch?
21:59:28  <groundwater_>6011-isfinal
21:59:34  <indutny>bnoordhuis: can you at least put a comment on it?
21:59:40  <indutny>bnoordhuis: so I'll add tags in gmail :P
21:59:41  <trevnorris>groundwater_: on node
21:59:48  <groundwater_>joyent/node?
21:59:58  <bnoordhuis>indutny: commented "FAIL!"
21:59:59  <trevnorris>groundwater_: when we push a branch to joyent/node it runs all the CI, including windows.
22:00:02  <bnoordhuis>(kidding)
22:00:04  <indutny>thanks
22:00:09  <indutny>oh, you didn't
22:00:14  <indutny>you kiddo
22:01:03  <trevnorris>windows is jacked. the only way the test could have reached that fail state is if one of the callbacks didn't fire before the process exited.
22:01:06  <bnoordhuis>indutny: commented :)
22:01:09  <groundwater_>trevnorris: just wanna see if there were any semantic changes in the tests
22:01:39  <trevnorris>groundwater_: well, i've heavily updated 6011 for cleanup and i'm still doing so now.
22:01:50  <indutny>bnoordhuis: thanks :P
22:01:57  <bnoordhuis>roxlu: btw, having branches in your inner loop is an absolute no no
22:02:20  <roxlu>you mean the % 2 ?
22:02:32  <bnoordhuis>yeah. gcc doesn't seem to be unrolling it so better do it manually
22:03:06  <roxlu>ok
22:03:46  <groundwater_>trevnorris: np, just want to follow along
22:04:25  <roxlu>oh nice, perf also shows code when compiled with -g3
22:06:56  * hzquit
22:09:05  <roxlu>it's doing a "jne" for what I think is the counter: https://gist.github.com/roxlu/1ab889f47b487ae51aad
22:09:28  <roxlu>can that be a "heave" operation?
22:10:17  <roxlu>"heavy" ^.^
22:10:53  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:10:56  * mikealquit (Quit: Leaving.)
22:11:53  <indutny>roxlu: try cachegrind ;)
22:12:01  <indutny>its another tool-of-choice IMHO
22:12:37  * mikealjoined
22:12:42  * AvianFluquit (Ping timeout: 246 seconds)
22:12:45  <bnoordhuis>problem with cachegrind is that its internal model of what a modern cpu is, is pretty outdated by now
22:12:52  <indutny>well
22:12:54  <indutny>it still works
22:12:56  <indutny>and that's good
22:13:08  <bnoordhuis>yeah, but it's no good if it produces bogus numbers :)
22:13:41  <bnoordhuis>roxlu: that jne is unavoidable (unless you want to unroll the entire loop, of course)
22:14:31  <roxlu>bnoordhuis: that that mean that the cpu 'moves' the "read pointer' ? (sorry if I'm using wrong terminology, but I'm rolling into this optimization thing)
22:16:16  <trevnorris>bnoordhuis: thought this might interest you, took perf trace of the http chunked test. don't completely understand why, but it's easy to see that sending chunked is doing way more: https://gist.github.com/trevnorris/7238286
22:17:22  <trevnorris>(I was having fun testing out perf now that I finally updated my kernel. though can't get -g dwarf to work. might have to compile the kernel myself, or just build with -fno-omit-frame-pointer)
22:17:58  <bnoordhuis>roxlu: i get what you mean :) yeah, that's what happens, conceptually at least
22:18:24  <MI6>nodejs-master: #659 UNSTABLE osx-x64 (2/655) smartos-ia32 (9/655) linux-x64 (2/655) smartos-x64 (11/655) osx-ia32 (2/655) linux-ia32 (2/655) http://jenkins.nodejs.org/job/nodejs-master/659/
22:18:37  <bnoordhuis>trevnorris: -g dwarf?
22:19:02  <trevnorris>bnoordhuis: yeah. allows you to get the frame pointers if you didn't compile with the -fno-omit-frame-pointer option.
22:19:22  <roxlu>bnoordhuis: do you have an idea why my code is sooo slowish for that loop counter? (and how to optimize)
22:20:00  <tjfontaine>don't do that, ricer :)
22:20:40  <bnoordhuis>roxlu: it's like -ggdb only it tells gcc to produce standard dwarf debug info
22:20:43  <bnoordhuis>er, trevnorris
22:21:10  <bnoordhuis>trevnorris: just don't worry about it, gcc usually does the right things on gnu toolchain systems
22:21:23  <trevnorris>bnoordhuis: cool. thanks.
22:21:51  <trevnorris>bnoordhuis: what i'm most confused about is the total processor time spent is like 1/5 or less than if you didn't use chunked.
22:22:20  <bnoordhuis>roxlu: if the counter keeps dominating, then you're probably not enough in your loop. maybe unroll by hand, e.g. process 8 elements per iteration
22:22:27  <bnoordhuis>*not doing enough
22:22:29  <bnoordhuis>damnit
22:23:01  <bnoordhuis>trevnorris: oh? let me guess, more wall clock time is spent kernel side?
22:23:07  <roxlu>ok that makes total sense :)
22:23:23  <roxlu>bnoordhuis: but then the big question, how to optimize that simple loop :)
22:23:28  <trevnorris>bnoordhuis: yeah. ton in epoll_wait. like a ridiculous amount.
22:24:03  <bnoordhuis>trevnorris: okay. will have to look into that someday. but today is not that day :)
22:24:31  <bnoordhuis>roxlu: unrolling, aligning your data, optimizing for cache line size, etc.
22:24:41  <roxlu>hehe yes :)
22:24:42  <bnoordhuis>roxlu: btw, you have a 96 byte stride currently which is a bit odd
22:24:55  <trevnorris>bnoordhuis: yeah. like I said. was having fun w/ the new perf options. have access to all the tracepoint events. the whole world just opened up. :)
22:25:03  <bnoordhuis>not 'odd' as in 'not divisible by two' but, you know, odd
22:25:21  <roxlu>bnoordhuis: would it be better to add some 'bogus' member to make sure the group_particle is a power of two?
22:25:51  <bnoordhuis>roxlu: it might help, yes. (then again, it might not.)
22:26:12  <roxlu>some people tell me divisble by 2, others power of 2 .. what is it?
22:26:23  <bnoordhuis>computers usually like powers of two
22:27:15  <bnoordhuis>alignment is another issue but gcc probably already takes care of that because you're using __m128
22:27:46  * piscisaureus_quit (Ping timeout: 256 seconds)
22:27:57  <bnoordhuis>roxlu: come to think of it, how did you end up at 96 bytes if you're using 128 bits data types?
22:28:18  <bnoordhuis>oh wait, that struct has six members, right?
22:28:31  <roxlu>yes
22:28:51  <bnoordhuis>seems the gist i'm looking at chopped off the last two lines of the struct :)
22:29:37  * st_lukequit (Read error: Connection reset by peer)
22:29:42  <roxlu>ah ok
22:29:59  <roxlu>there is no difference when I add 2 xtra dummy memberes
22:30:01  <roxlu>members
22:30:07  <MI6>joyent/node: Trevor Norris 011-isfinal * 4866658 : doc: add docs for AsyncListeners (+8 more commits) - http://git.io/d87j3A
22:30:15  <trevnorris>alright. time to see what's failing on windows.
22:30:15  * st_lukejoined
22:30:58  <tjfontaine>ALL THE THINGS
22:30:58  <LOUDBOT>WE SHALL DO IT WITH PLATE TECTONICS
22:31:05  <roxlu>bnoordhuis: I think that using just plain arrays like: __m128* positions_x; __m128* positions_y; __m128* vel_x; __m128* vel_y etc... seems to be a faster solution then using this struct in my code
22:31:38  <trevnorris>tjfontaine: seriously. that test shouldn've be able to fail the way it did.
22:34:49  <trevnorris>tjfontaine: that'll fire off jenkins build/test right?
22:35:03  <bnoordhuis>roxlu: if the operations on those arrays don't depend on one another then it'll probably be faster yes
22:35:39  <roxlu>yeah they kind of depend on each other, because it's a particle system where I need forces, velocity, position of a particle
22:36:13  <roxlu>but from this super basic test, it seems that this is way slower
22:36:25  * amartensjoined
22:37:37  <tjfontaine>trevnorris: hypothetically, presuming gyp hasn't eaten the queue
22:38:21  <trevnorris>tjfontaine: thanks. guess it takes a minute, or could it be that I had to force update the branch?
22:38:24  <MI6>libuv-v0.10: #123 ABORTED smartos (2/187) http://jenkins.nodejs.org/job/libuv-v0.10/123/
22:38:40  <MI6>libuv-v0.10-gyp: #88 ABORTED http://jenkins.nodejs.org/job/libuv-v0.10-gyp/88/
22:38:44  <MI6>node-review: #100 ABORTED osx-x64 (2/671) linux-ia32 (1/671) http://jenkins.nodejs.org/job/node-review/100/
22:38:52  <trevnorris>tjfontaine: and I can't believe those tests take a full second to run on windows. that must take forever to get through.
22:38:53  <MI6>libuv-master-gyp: #254 ABORTED smartos-ia32 (2/195) http://jenkins.nodejs.org/job/libuv-master-gyp/254/
22:39:07  <tjfontaine>who cares, it's just tests :)
22:39:28  <MI6>libuv-master: #312 FAILURE http://jenkins.nodejs.org/job/libuv-master/312/
22:39:28  <trevnorris>hah, yeah. I was just thinking of if I was building/testing on windows.
22:39:35  <MI6>libuv-master-gyp: #255 ABORTED http://jenkins.nodejs.org/job/libuv-master-gyp/255/
22:39:48  <MI6>libuv-v0.10-gyp: #89 ABORTED http://jenkins.nodejs.org/job/libuv-v0.10-gyp/89/
22:40:16  * abraxasjoined
22:40:17  <MI6>libuv-v0.10: #124 ABORTED smartos (2/188) http://jenkins.nodejs.org/job/libuv-v0.10/124/
22:40:33  * amartensquit (Ping timeout: 245 seconds)
22:41:30  <roxlu>bnoordhuis: I'm going to sleep... but I would love to talk a bit more about this micro optimization stuff
22:41:47  <roxlu>see ya later all, and thanks for all the help (you too indutny )
22:41:57  <MI6>libuv-master: #313 ABORTED smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/313/
22:41:58  <bnoordhuis>roxlu: sure. ping me tomorrow and we'll chat some more. sleep tight
22:42:46  <tjfontaine>trevnorris: it's building now
22:42:55  <trevnorris>tjfontaine++
22:44:52  * abraxasquit (Ping timeout: 264 seconds)
22:44:53  * sblomquit (Ping timeout: 248 seconds)
22:45:27  * TooTallNatejoined
22:46:34  * rendarquit (Quit: Leaving)
22:46:39  * dshaw_quit (Quit: Leaving.)
22:47:37  * Kakera_quit (Ping timeout: 272 seconds)
22:48:14  * trevnorris&
22:48:14  <LOUDBOT>AT FOX AREN'T LIKE THE FEMA DEATH CAMP EXTREMISTS. NEXT ON NBC:
22:51:28  <indutny>roxlu: you're welcome
22:52:10  * `3rdEdenchanged nick to `3E|ZZ
22:52:32  <othiym23>tjfontaine: what's my best source of a crisp, clean prebuilt node 0.8.3 that'll run on Mavericks?
22:52:51  <othiym23>it FTBFS, at least with the default OS X 10.9 toolchain
22:53:15  <othiym23>well, it builds, it just segfaults alla time
22:54:19  <tjfontaine>if you look at the stacktrace does it look like a clean exit?
22:54:25  <tjfontaine>also 0.8.3 ...
22:54:42  <othiym23>I have a customer who is running into an issue with async-listener and is stuck on 0.8.3
22:54:45  <othiym23>I do not know why
22:55:01  <tjfontaine>othiym23: https://github.com/joyent/node/issues/6427
22:55:28  <indutny>othiym23: gosh
22:55:33  <indutny>othiym23: another thing in my inbox :P
22:55:37  <indutny>I'll get to it soon
22:55:43  <indutny>sorry, but I had a lot of other stuff
22:56:10  * defunctzombiechanged nick to defunctzombie_zz
22:56:20  <tjfontaine>othiym23: though a clean version should be able to come from nodejs.org/dist right?
22:56:55  <tjfontaine>osx does an excellent job of being able to run old binaries, especially given who we build
22:58:25  * loladiroquit (Quit: loladiro)
23:00:17  <othiym23>tjfontaine: yeah, I just don't want to go through lsbom / BOM extract / whatever process, although I guess I could live with temporarily nuking my systemwide Node install
23:00:24  <tjfontaine>oh
23:00:32  <tjfontaine>we dont' have btars back then?
23:00:44  <othiym23>tjfontaine: it SIGSEGVs unless I run under gdb
23:00:46  <othiym23>of course
23:00:58  <tjfontaine>you should have a /cores/core
23:01:20  <othiym23>http://nodejs.org/dist/v0.8.3/ says there is no btar for OS X
23:01:27  <tjfontaine>indeed, I see that
23:01:33  <othiym23>oh yeah, I need to set the sysctl to allow cores all the time
23:01:35  <othiym23>keep forgetting that
23:01:37  <othiym23>but good call
23:01:44  <tjfontaine>yup /cores and ulimit
23:02:17  <othiym23>OS X cores are so huge
23:02:21  <othiym23>I do not understand why
23:02:28  <tjfontaine>and gdb sucks at loading them
23:02:31  <othiym23>do they like write every page the process might conceivably have touched?
23:03:00  <tjfontaine>GDB ALL THE THINGS
23:03:00  <LOUDBOT>THERE ISN'T ONE POSTED ANYWHERE
23:03:05  <tjfontaine>exactly
23:03:39  <MI6>nodejs-master-windows: #446 UNSTABLE windows-x64 (22/654) windows-ia32 (24/654) http://jenkins.nodejs.org/job/nodejs-master-windows/446/
23:04:38  <othiym23>tjfontaine: https://gist.github.com/othiym23/f3377398f5c6a78cb8c6
23:05:01  <tjfontaine>yup, you're int he clean exit path, and v8 is fucking itself over
23:05:09  <othiym23>wheee
23:05:14  <othiym23>I'mo do this in Linux
23:05:17  <othiym23>screw you OS X
23:05:25  <tjfontaine>so it's not my toolchain, that's good to know
23:05:42  <othiym23>orrrr I guess I could do it on.... SmartOS
23:05:44  <tjfontaine>or at least isaacs' old toolchain exhibits the same problem
23:05:59  <othiym23>does pkgin have a prebuild 0.8.3 kicking around somewhere?
23:06:09  * kellabytequit (Quit: Quit)
23:06:18  <tjfontaine>uh, no idea, I hope not :)
23:06:37  <tjfontaine>what sort of issue are they hitting?
23:06:47  <MI6>node-review: #101 UNSTABLE osx-x64 (1/671) linux-ia32 (3/671) smartos-x64 (9/671) centos-x64 (3/671) windows-x64 (31/671) linux-x64 (2/671) osx-ia32 (2/671) windows-ia32 (31/671) centos-ia32 (2/671) smartos-ia32 (7/671) http://jenkins.nodejs.org/job/node-review/101/
23:06:53  <tjfontaine>trevnorris: ^^
23:07:42  <othiym23>well, the part that's my problem is that _normalizeConnectArgs doesn't exist in Node < 0.8.4 and async-listener is monkeypatching that
23:08:10  <tjfontaine>othiym23: but is there any reason you need the "official" binaries?
23:08:16  <othiym23>the bigger problem is that they're running a hella old busted version of node
23:08:26  <othiym23>tjfontaine: nope, if it builds from source on SmartOS I don't care
23:08:41  <tjfontaine>ya, that's really old, and yes it should build fine on smartos (afaik)
23:10:09  * amartensjoined
23:13:31  <bnoordhuis>what ho, trevnorris? narcissus is dead? didn't know that
23:14:07  * superjoe30quit (Quit: Leaving)
23:14:20  <othiym23>I have tangled with the Narcissus codebase
23:14:26  <othiym23>if it is indeed dead, I'm not sure I'll miss it
23:14:33  <bnoordhuis>that bad?
23:19:05  * mikealquit (Quit: Leaving.)
23:19:07  * kellabytejoined
23:19:24  * mikealjoined
23:20:13  <bnoordhuis>[SECURITY] Fedora 19 Update: libuv-0.10.18-1.fc19 - aww fedora, the bug was in node, not libuv
23:21:09  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:21:16  <othiym23>bnoordhuis: it's just really hairy compared something like esprima
23:21:35  <othiym23>I mean, I know it's not just an AST parser, but I found it to be pretty crufty
23:22:41  <bnoordhuis>okay. never spent much time with it but what i saw didn't seem too bad
23:22:50  * kellabytequit (Changing host)
23:22:50  * kellabytejoined
23:22:50  * kellabytequit (Changing host)
23:22:50  * kellabytejoined
23:23:05  * dg_quit (Ping timeout: 272 seconds)
23:28:53  <othiym23>I really wish I could figure out how to tell my SmartOS VM to remember its default gateway
23:29:26  * rphillipsquit (Ping timeout: 240 seconds)
23:29:36  <tjfontaine>not sure why you have problems with that :/
23:30:04  * rphillipsjoined
23:31:27  * rphillipsquit (Excess Flood)
23:34:26  * brsonquit (Quit: leaving)
23:34:41  * brsonjoined
23:36:13  * rphillipsjoined
23:36:59  * rphillipsquit (Excess Flood)
23:37:53  * rphillipsjoined
23:38:37  <othiym23>it's not the default gateway, it's the resolver
23:38:46  <othiym23>I probably boned the zone configuration
23:38:50  <othiym23>which means I can probably fix it
23:38:54  <othiym23>and I probably will someday!
23:38:55  * st_lukequit (Remote host closed the connection)
23:39:26  * st_lukejoined
23:42:46  <othiym23>vmware and SmartOS are my friends
23:42:48  <othiym23>I like them
23:43:47  * st_lukequit (Ping timeout: 240 seconds)
23:43:49  <MI6>nodejs-master-windows: #447 UNSTABLE windows-x64 (26/655) windows-ia32 (25/655) http://jenkins.nodejs.org/job/nodejs-master-windows/447/
23:46:18  * AvianFlujoined
23:47:36  * paddybyersquit (Quit: paddybyers)
23:48:24  <isaacs>trevnorris: ping
23:48:29  <isaacs>trevnorris: so, last blocker on 6011, for me
23:48:33  <isaacs>trevnorris: i=0; while ./node test/simple/test-asynclistener-error.js; do echo $i; let i++; done
23:48:49  <isaacs>trevnorris: that'll eventually fail, and the numbers are really weirdly inconsistent (either 16, 17, or 18)
23:49:25  * loladirojoined
23:49:26  <othiym23>so uh tjfontaine / isaacs you guys got any suggestsions for a fallback for what I should do in the async-listener polyfill for versions of Node that predate the introduction of net._normalizeConnectArgs?
23:50:07  <othiym23>creationix used it to figure out which argument is the callback to wrap in the net.Socket.prototype.connect monkeypatch
23:50:22  <othiym23>I guess I could just copy the logic from .connect wholesale, but that feels... yucky
23:50:46  * TooTallNatejoined
23:51:42  <isaacs>othiym23: yeah
23:51:55  <isaacs>othiym23: it'd be better to copy the logic from _normalizeConnectArgs, if anything
23:52:11  <othiym23>isaacs: that is a good idea
23:52:17  <othiym23>I will polyfill in my polyfill
23:52:29  <isaacs>othiym23: yes!
23:52:34  <isaacs>othiym23: poly means "many" anyway
23:52:37  <othiym23>and then Xzibit will appear and just say "smh" at the tired meme and walk away
23:52:39  <isaacs>othiym23: it's only fair that you have more than one of them
23:52:51  <othiym23>hoo boy
23:53:04  <othiym23>I "can't wait" to get decent performance numbers for the polyfill
23:53:11  <othiym23>I won't show them to trevnorris
23:53:14  <othiym23>the shock might kill him
23:57:47  * pquernaquit (Ping timeout: 260 seconds)
23:58:15  * pquernajoined
23:58:15  * pquernaquit (Changing host)
23:58:15  * pquernajoined
23:59:34  * acrichtojoined