Da
Show enters and exits. Hide enters and exits.
| 03:40:21 | evan | man |
| 03:40:30 | evan | strongtalk has some fucking twisty logic. |
| 03:40:47 | slava | heh |
| 03:44:41 | evan | slava: do you have any logic for deciding if a word should be inlined? |
| 03:46:06 | slava | evan: manual declaration, size of definition being inlined, size of definition being inlined into, and precision of type info for input parameters |
| 03:46:25 | slava | if you have runtime profiling though, you'll be able to do much better |
| 03:46:36 | evan | i'm runtime profiling |
| 03:46:39 | evan | just trying to get a handle |
| 03:46:43 | evan | i guess i should just give it a try |
| 03:47:00 | evan | and say something like "let the method increase by 3x only" |
| 03:47:25 | slava | oh yeah, I also make sure I don't inline the same word too many times |
| 06:36:14 | evan | rad. |
| 06:36:20 | evan | i've got accessors inlining |
| 06:45:57 | brixen | sweet! |
| 06:47:14 | evan | it's doing slot vs hash table lookup detection at JIT time |
| 06:47:20 | evan | and only the relevent code is output |
| 06:47:32 | evan | so doing [].size |
| 06:47:46 | evan | ends up just accessing the position in Array where size_ is |
| 06:48:26 | tmornini | Hey all. I get a Bus error with HEAD Rubinius and LLVM. Is my environment broken, or does this seem reasonable? |
| 06:49:06 | tmornini | It happens when I run this: |
| 06:49:07 | tmornini | RBX_LLVM=1 rake build; bin/mspec ci -B full -T -Xjit.enabled |
| 06:49:47 | brixen | hrm, I can try running it |
| 06:50:07 | tmornini | Again, this is HEAD LLVM and HEAD Rubinius |
| 06:50:30 | tmornini | Bus error happens when VM tests normally run. |
| 06:50:31 | brixen | ah well, I'm not going to compile llvm atm |
| 06:50:47 | evan | tmornini: wait |
| 06:50:49 | evan | where is the error? |
| 06:50:54 | evan | running rake or running mspec |
| 06:51:02 | tmornini | Let me double check. |
| 06:51:28 | tmornini | Christ, every time I try this, LLVM has new revs. Incredible! |
| 06:51:38 | evan | heh |
| 06:51:42 | evan | i generally don't update LLVM. |
| 06:51:51 | evan | i've got it checked out and built |
| 06:51:54 | brixen | we should probably have the build task use a specific version of llvm |
| 06:51:56 | evan | and I leave it at the rev it's at. |
| 06:51:59 | brixen | yeah |
| 06:52:03 | evan | yeah |
| 06:52:09 | tmornini | I lied. :-( |
| 06:52:10 | tmornini | ~/Desktop/rubinius: bin/mspec ci -B full -T -Xjit.enabledBus error |
| 06:52:13 | brixen | otherwise we could be continually chasing stuff |
| 06:52:22 | evan | tmornini: no dots, nothing? |
| 06:52:26 | tmornini | No. |
| 06:52:44 | evan | i actually suspect something in LLVM. |
| 06:52:48 | evan | i know they changed some stuff with the JIT |
| 06:52:50 | tmornini | It take a while. |
| 06:52:55 | tmornini | takes, that is. |
| 06:52:57 | tmornini | 1-2 seconds. |
| 06:53:02 | evan | thats a while? |
| 06:53:07 | evan | not for me it's not. |
| 06:53:10 | tmornini | Actually, about 4 secons. |
| 06:53:11 | tmornini | seconds |
| 06:53:37 | evan | tmornini: lets try something. |
| 06:53:37 | tmornini | My point is that it isn't instantaneous. Clearly some work happening before the bus error. |
| 06:53:41 | tmornini | Sure. |
| 06:53:50 | evan | update your LLVM to rev 73074 |
| 06:53:52 | evan | thats what i'm on |
| 06:54:04 | evan | so go back |
| 06:54:20 | evan | build that, do a rake vm:clean of rubinius |
| 06:54:22 | evan | build and try |
| 06:54:36 | evan | i can update my local LLVM and see if it blows up |
| 06:55:20 | tmornini | Doing this now. |
| 06:55:32 | tmornini | Will that rebuild LLVM too? |
| 06:55:53 | evan | no |
| 06:55:55 | evan | you need to do that. |
| 06:55:59 | tmornini | ok |
| 06:57:07 | tmornini | New 13" MacBook Pro with SSD, 2.53 GHz: This thing is quick! |
| 06:57:31 | evan | nice |
| 06:58:17 | tmornini | I been disappointed with my Mac since I "upgraded" my black MacBook 13" to a MacBook Pro 15" |
| 06:58:26 | tmornini | But this one seems like a keeper. :-) |
| 06:58:54 | brixen | the 13" is an awesome size for taking with you |
| 06:59:05 | evan | yeah, the 13" is a definite sweet spot |
| 06:59:29 | tmornini | Agreed. Since I started walking to work every day, rather than walk down the stairs, the 15" was doomed. |
| 06:59:56 | tmornini | The new unibody makes this thing a BRICK. |
| 07:00:11 | tmornini | (in a good sense) |
| 07:00:44 | evan | hah |
| 07:00:44 | evan | yeah |
| 07:00:52 | evan | the daily commute really puts it into perspective |
| 07:01:18 | tmornini | I had some hands on with Ed's iPhone 3GS, and that thing is wonderful! |
| 07:01:25 | tmornini | Apps open *instantly*. |
| 07:01:49 | evan | yeah, i've been playing with Abby's |
| 07:01:51 | evan | i'll probably upgrade |
| 07:02:19 | tmornini | I think it's funny that I've been buying faster computers for 31 years, and they're always finally fast enough. |
| 07:02:47 | evan | hehe |
| 07:02:48 | evan | yeah |
| 07:02:55 | evan | humans a pain that way. |
| 07:03:04 | tmornini | They're literally something like 100,000x faster than my first. Crazy how software has grown in complexity. |
| 07:03:06 | evan | are a poin, rather. |
| 07:03:50 | tmornini | LLVM is a beast. I rarely need to compile it from scratch. :-) |
| 07:04:06 | evan | yeah |
| 07:04:33 | tmornini | What are the [1-3] indicative of? Any idea? |
| 07:05:05 | tmornini | i.e. llvm[2] |
| 07:05:07 | evan | huh? |
| 07:05:08 | evan | oh |
| 07:05:10 | evan | thats make |
| 07:05:11 | evan | i dunno. |
| 07:05:13 | evan | make is crazy. |
| 07:05:19 | tmornini | :-) |
| 07:06:15 | scoopr | I think it's nth-sub-make |
| 07:06:23 | tmornini | Thx! |
| 07:07:15 | evan | looks like slot access inlining improves access by 12% |
| 07:07:21 | evan | testing table ivars now |
| 07:07:59 | tmornini | I'm watching the really disturbing scene in Pearl Harbor where sailors are drowning inside ships inches away people on the outside. |
| 07:08:09 | evan | yeah, thats fun. |
| 07:08:17 | evan | watch that on high volume right before bed |
| 07:08:22 | evan | just to see what kind of weird dreams you have |
| 07:09:05 | tmornini | Poignant way to say "war sucks". |
| 07:09:39 | tmornini | Surprisingly effective for a big budget Hollywood film. |
| 07:11:07 | tmornini | Man, X86ISelDAGToDAG.cpp is a monster. |
| 07:25:25 | evan | about 9% improvement for table ivars. |
| 07:27:05 | brixen | compactlookuptable or lookuptable? |
| 07:27:29 | evan | for this, it would have been compact |
| 07:27:33 | brixen | k |
| 07:27:43 | evan | should be the same no matter which though |
| 07:27:49 | evan | i'm doing the lookup via a function call |
| 07:28:06 | evan | so the inlining is just removing the mechanics of method lookup and dispatch |
| 07:28:17 | brixen | I see |
| 07:28:35 | evan | slot inlining uses no functions |
| 07:28:53 | evan | so that helps |
| 07:29:02 | evan | one interesting thing |
| 07:29:18 | evan | seems slot access un-inlined is slower than table ivars! |
| 07:29:26 | evan | i'm looking into why now. |
| 07:29:27 | brixen | no way |
| 07:29:40 | evan | i think it's because it goes via the generic mechanism |
| 07:29:47 | brixen | ahh |
| 07:29:49 | evan | which uses STL to detect the ivar is at a slot |
| 07:30:03 | evan | i've got AccessVariable doing specialization |
| 07:30:06 | evan | perhaps it's not working |
| 07:30:10 | evan | i'll know shortly. |
| 07:31:14 | evan | oh good |
| 07:31:16 | evan | nevermind! |
| 07:31:24 | evan | specialization is working. |
| 07:31:32 | evan | i must have inverted the numbers |
| 07:31:38 | evan | measure twice, cut once! |
| 07:31:45 | brixen | hah indeed |
| 07:31:57 | brixen | learn that is shop class? |
| 07:32:00 | brixen | did |
| 07:32:03 | evan | yep |
| 07:32:10 | evan | tech ed was what I took |
| 07:32:14 | evan | it was like shop |
| 07:32:24 | evan | but we also used the computer milling machine |
| 07:32:31 | brixen | 'tech ed' sounds cooler |
| 07:32:39 | evan | we still did stuff like take apart a 2 stroke engine |
| 07:32:42 | evan | and put it back together |
| 07:32:55 | evan | that seemed very "shop" |
| 07:33:04 | brixen | the metal shop/small engine repair were separate from woodshop |
| 07:33:07 | brixen | I did woodshop |
| 07:33:11 | evan | ah |
| 07:33:23 | evan | so tech ed was not much wood working |
| 07:33:35 | evan | the milling machine would etch plastic |
| 07:33:45 | brixen | sounds fun |
| 07:33:58 | evan | you'd design a design and load it via floppy into the machine |
| 07:34:01 | evan | it was pretty cool |
| 07:38:20 | scoopr | cnc? |
| 07:38:30 | evan | yeah! |
| 07:38:31 | evan | thaht was it. |
| 07:38:36 | evan | way to kick my brain into gear |
| 07:38:53 | evan | i can hear my tech ed teacher saying "ok, who's on the CNC machine today?" |
| 07:39:33 | scoopr | =) |
| 07:45:21 | tarcieri | can't wait until self-replicating CNC machines are common place |
| 07:45:21 | tarcieri | heh |
| 07:46:10 | tmornini | hmmm. LLVM won't build for me. |
| 07:46:39 | tmornini | If I ./configure, it sets up for a debug build, whereas rake build sets up for a release build. |
| 07:46:57 | tarcieri | omfg another t.{6}i nickname! |
| 07:47:10 | tmornini | Is debug -vs- release important? |
| 07:47:14 | evan | you can build it release with ./configure by passing it options |
| 07:47:21 | evan | yes |
| 07:47:22 | evan | tmornini: just do |
| 07:47:25 | evan | make clean |
| 07:47:26 | evan | in llvm |
| 07:47:32 | evan | and let rake fully rebuild it then |
| 07:47:38 | tmornini | OK, doing now. |
| 07:48:19 | tmornini | tarcieri: We should get together and eat some pasta sometime. :-) |
| 07:48:31 | tarcieri | haha |
| 07:48:33 | tarcieri | pasta rules |
| 07:51:31 | tmornini | tarcieri: Are the self-repl CNC machines black monoliths? |
| 07:53:59 | tmornini | Boom! Undefined symbols: |
| 07:53:59 | tmornini | "llvm::sys::AtomicIncrement(unsigned int volatile*)", referenced from: |
| 07:54:41 | evan | ug. |
| 07:54:43 | tmornini | svn info: Last Changed Rev: 73074 |
| 07:55:00 | tarcieri | tmorini: they look like big cubes of chinsy plastic, actually |
| 07:55:08 | tmornini | I'll check out fresh. |
| 07:55:12 | evan | tmornini: ok |
| 07:55:14 | evan | sorry :( |
| 07:55:31 | tmornini | tarcieri: I think they moved manufacturing from Germany to China. :-) |
| 07:57:36 | tarcieri | more like joe's garage |
| 07:58:57 | tmornini | LLVM guys need to move to Git. |
| 07:58:57 | tarcieri | http://reprap.org/bin/view/Main/WebHome |
| 08:00:49 | tmornini | Wow, that's very cool. |
| 08:01:18 | tarcieri | yeah pretty crazy idea |
| 08:05:40 | scoopr | that's even *sweeter* http://www.candyfab.org/ ! |
| 08:29:18 | tmornini | OK, that built and runs fine. |
| 08:29:27 | tmornini | Just for fun, I'll update to LLVM head. |
| 08:29:47 | evan | why? |
| 08:29:50 | evan | do you love pain? |
| 08:30:03 | tmornini | To make sure it doesn't work. :-) |
| 08:32:34 | evan | okey dokey |
| 08:44:49 | boyscout | Refactor in prep for inlining work - 805f827 - Evan Phoenix |
| 08:44:49 | boyscout | Add ability to inline ivar accessors - 3cee96d - Evan Phoenix |
| 08:44:50 | evan | woop |
| 08:45:10 | brixen | nice |
| 08:52:07 | tmornini | OK, original issue confirmed repeatable. :-) |
| 08:52:27 | boyscout | CI: 3cee96d success. 2709 files, 10776 examples, 33796 expectations, 0 failures, 0 errors |
| 08:52:44 | evan | heh |
| 08:57:02 | evan | how I know we're on the right track: http://gist.github.com/135078 |
| 08:58:12 | brixen | evan: what's the top? |
| 08:58:15 | evan | MRI |
| 08:58:21 | brixen | ah der |
| 08:58:22 | brixen | heh |
| 08:58:29 | tmornini | Nice |
| 09:07:09 | tmornini | evan: Can you gist the ruby code for that test? |
| 09:12:59 | boyscout | Rename Class::direct_superclass to true_superclass - acac5e3 - Evan Phoenix |
| 09:12:59 | boyscout | Fix a return key alergy - 42abd5a - Evan Phoenix |
| 09:19:16 | boyscout | CI: 42abd5a success. 2709 files, 10776 examples, 33796 expectations, 0 failures, 0 errors |
| 14:01:19 | sbryant_work | Morning |
| 18:17:56 | evan | brixen: did you change syck to not use RHASH then? |
| 18:18:10 | brixen | yes |
| 18:18:14 | brixen | there was only one place |
| 18:18:14 | evan | k. |
| 18:18:19 | brixen | it needed rb_hash_size |
| 18:18:28 | evan | someone wants to use this rjb gem |
| 18:18:28 | brixen | but, there is that RVALUE struct |
| 18:18:35 | evan | which is a ruby/java bridge |
| 18:18:42 | brixen | ahh |
| 18:18:49 | brixen | wants to use in rbx? |
| 18:18:58 | evan | which uses st internally, and RHASH a few places |
| 18:19:04 | brixen | hm |
| 18:19:12 | evan | so we could provide st.c/h for them to use |
| 18:19:23 | evan | but that doesn't solve the RHASH issue |
| 18:19:24 | brixen | yeah, I pulled st into syck |
| 18:19:40 | brixen | well, it probably uses RHASH because rb_hash_xxx are static |
| 18:19:49 | brixen | tell 'em to file a bug report with MRI |
| 18:19:50 | evan | nope |
| 18:19:56 | evan | it seems to manually manipulate one |
| 18:20:01 | brixen | hm |
| 18:20:06 | evan | using st_foreach, st_delet, and st_insert |
| 18:20:15 | brixen | well, what's it doing? |
| 18:20:24 | evan | checking now |
| 18:20:40 | evan | ug. |
| 18:20:47 | evan | well, the foreach is just clearing the hash |
| 18:20:53 | brixen | cool |
| 18:20:57 | brixen | there is rb_hash_clear |
| 18:21:21 | evan | st_insert is just doing an insert |
| 18:21:52 | evan | i guess thats it. |
| 18:21:57 | brixen | sweet |
| 18:22:15 | brixen | I could try getting it running if you want |
| 18:22:18 | evan | so we should advise the gem author to change what they're doing? |
| 18:22:24 | brixen | wrangling loader.rb atm |
| 18:22:26 | evan | nah, i'm about done with it. |
| 18:22:39 | brixen | yes, advise them to file a bug report with mri |
| 18:22:41 | evan | just wanted to investigate a little |
| 18:22:48 | evan | why with MRI? |
| 18:22:56 | evan | shouldn't the gem author change the gem? |
| 18:22:56 | brixen | well le'me check |
| 18:23:20 | brixen | static VALUE |
| 18:23:20 | brixen | rb_hash_clear(hash) |
| 18:23:26 | brixen | what's the author to do? |
| 18:23:33 | evan | damnit |
| 18:23:33 | brixen | write their own rb_hash_clear |
| 18:23:35 | evan | stupid MRI |
| 18:23:36 | evan | geez. |
| 18:23:36 | brixen | using st |
| 18:23:39 | brixen | yes |
| 18:24:09 | evan | we should put together a .h file |
| 18:24:12 | evan | that has those things in it |
| 18:24:15 | evan | call it compat.h |
| 18:24:26 | evan | and point people to it to use |
| 18:24:35 | brixen | well, how would that help here? |
| 18:24:45 | brixen | it won't link with MRI |
| 18:24:51 | evan | could have the gem author copy compat.h into their project |
| 18:24:53 | evan | sure it will |
| 18:24:58 | evan | we'll provide a rb_hash_clear in compact.h |
| 18:25:01 | evan | comat.h |
| 18:25:04 | evan | GR. compat.h |
| 18:25:30 | brixen | well, I suppose |
| 18:25:50 | brixen | seems a painful workaround to just removing those static specifiers |
| 18:25:56 | evan | it is. |
| 18:26:02 | evan | but it's something we've got control over |
| 18:26:05 | evan | unlike MRI. |
| 18:26:25 | brixen | well, I'd rather file the bug, if they refuse, we can |
| 18:26:33 | brixen | but these gem authors should be bitching |
| 18:26:35 | evan | well, that will only work going forward |
| 18:26:39 | evan | gem authors won't change |
| 18:26:48 | evan | because they'll say "now my gem doesn't work on 1.8.6" |
| 18:27:19 | brixen | yes |
| 18:28:16 | evan | i'm going to wipe up a compat.h now. |
| 18:28:18 | evan | it's easy. |
| 18:34:53 | evan | hm, are there any thing else I should throw in here? |
| 18:35:28 | brixen | the RSTRING() => RSTRING_PTR(), RSTRING_LEN() |
| 18:36:25 | evan | ok, done. |
| 18:36:47 | evan | we'll call this the missing header file :D (like the missing manual book series) |
| 18:36:56 | brixen | heh |
| 18:38:26 | brixen | the fact that the hash functions are static when stuff like rb_iterate is not (and was used in syck) is mind-boggling |
| 18:38:31 | evan | in addition to rb_hash_size, i'm going to put RHASH_SIZE() |
| 18:38:45 | evan | since people actually seem to want the size as a long |
| 18:38:46 | evan | not a VALUE |
| 18:39:34 | evan | yeah. |
| 18:45:14 | evan | ha |
| 18:45:29 | evan | i guess that 1.8 svn has macros to access the fields of RHASH already |
| 18:45:31 | evan | good for them. |
| 18:47:59 | brixen | a couple |
| 18:48:13 | brixen | I don't see the advantage over making rb_hash_xx an api |
| 18:48:31 | evan | none. |
| 18:48:35 | evan | just interesting. |
| 18:48:45 | brixen | yeah |
| 18:57:23 | brixen | evan: did you notice the rdoc interp time dropped quite a bit the past couple days |
| 18:57:31 | evan | hm, nope |
| 18:57:37 | brixen | the jit time dropped quite a bit last night too |
| 18:58:05 | brixen | you'll have to zoom the upper right of the graph to see it |
| 18:58:21 | evan | ah! |
| 18:58:23 | evan | i can't see it! |
| 18:58:36 | evan | can you move the legend to the upper left? |
| 18:58:42 | evan | the upper right is where all the action is! |
| 18:59:20 | brixen | heh |
| 18:59:29 | brixen | I can look if there's an option |
| 19:00:58 | evan | please do |
| 19:01:03 | evan | i'd never have noticed |
| 19:02:26 | brixen | would you prefer to remove the legend completely? with hover you can easily find out which line is which |
| 19:03:13 | brixen | it's easy enough to move it too |
| 19:04:56 | brixen | ok, top left it is |
| 19:09:57 | evan | o/~ have I ever told you your my heeeeroooo o/~ |
| 19:18:06 | brixen | hah |
| 19:18:44 | brixen | you meant http://www.youtube.com/watch?v=FKTDSfbcbBU right? |
| 19:24:10 | evan | that made me think of that song |
| 19:24:16 | evan | and you moving the legend made me happy |
| 19:24:19 | evan | so thusly. |
| 19:24:27 | evan | so, i'm copying st.c INTO st.h |
| 19:24:41 | evan | and namespacing all the internal functions and macros |
| 19:24:51 | evan | so we can throw this st.h into capi/ for people to use |
| 19:24:56 | brixen | cool |
| 19:25:01 | evan | then they'll get all the st_* functions directly via the header |
| 19:25:11 | evan | and we don't have to worry about symbol conflicts. |
| 19:31:16 | evan | ok, i'm giving up on this gem |
| 19:31:17 | evan | it does |
| 19:31:21 | evan | RBASIC(obj)->klass |
| 19:32:43 | brixen | yuck |
| 19:39:10 | dgtized | does it bother anyone else that when you add a complete new file in a commit, the github commit display doesn't display the contents of the added file unless you click on that file? |
| 19:40:42 | evan | nope |
| 19:42:01 | dgtized | I guess I just expect that you should be able to view all the new code, and not just code that changed -- oh well I guess different people view the use of that differently |
| 19:42:20 | dgtized | why are these bench graphs discontinous? |
| 19:42:34 | dgtized | at least for the mspec ci runs with jit? |
| 19:43:38 | dgtized | are those instances where mspec ci failed, no timing value was reported, but the graph isn't smart enough to connect the dots? |
| 19:46:32 | tmornini | If the benchmark doesn't complete, why would you connect the dots? |
| 19:47:09 | brixen | yeah, if the bench fails, I insert a 'null', which is what flot expects for 'no value' |
| 19:47:22 | brixen | the discontinuity is on purpose |
| 19:48:22 | dgtized | ok, was just curious that's all -- does it insert a null if all of the runs fail, or if just one of the runs fails? |
| 19:48:55 | brixen | they are all separate graph lines |
| 19:50:00 | tmornini | brixen: weren't many of the discontinuities related to build issues? |
| 19:50:19 | dgtized | brixen: I meant each of the runs that you are collecting the median from |
| 19:50:22 | brixen | tmornini: no, if it's a build issue, all the benches fail |
| 19:50:39 | brixen | and I remove that file, since it's just noise |
| 19:51:23 | dgtized | ie if 4/5 succeed does it just calculate median from the 4 that were a success or does it mark the whole point as null? |
| 19:51:31 | brixen | dgtized: the data is only valid if all trials succeed |
| 19:51:33 | dgtized | ok |
| 19:52:29 | boyscout | Start work on compat.h header, add st.h - 1403324 - Evan Phoenix |
| 19:52:42 | sbryant_work | brixen: I was looking at flot the other day and you can move legend to be anywhere. |
| 19:52:55 | sbryant_work | I was actually going to write a patch to move it for you :D |
| 19:54:00 | brixen | sbryant_work: it's already moved, but thanks :) |
| 19:54:19 | sbryant_work | oh |
| 19:54:24 | sbryant_work | yeah flot is crazy |
| 19:54:36 | sbryant_work | Is there a way to zoom out? |
| 19:55:03 | brixen | if you use two views of the graph, you can have an index view |
| 19:55:07 | brixen | there's an example |
| 19:55:22 | brixen | or you could use a zoom out button that just redraws the full graph |
| 19:55:48 | sbryant_work | I was going for the later. |
| 19:55:59 | brixen | sbryant_work: send me a patch to embed a google maps type control in the graph :) |
| 19:56:26 | boyscout | CI: 1403324 success. 2709 files, 10776 examples, 33796 expectations, 0 failures, 0 errors |
| 19:56:28 | sbryant_work | brixen: how about I start with the reset zoom button and then cannibalize the control? |
| 19:56:36 | brixen | sbryant_work: and if you could put street view on the graph line so it'll display in perspective and you can walk in both directions |
| 19:56:43 | sbryant_work | shudders at gwt. |
| 19:56:45 | evan | YES |
| 19:56:48 | evan | streetview! |
| 19:56:51 | sbryant_work | hahah |
| 19:56:58 | sbryant_work | brixen: I have an idea for that! |
| 19:56:59 | brixen | I'd like a terrain overview as well |
| 19:57:06 | evan | yes, lets do a 3d flyover |
| 19:57:08 | evan | of the data. |
| 19:57:15 | sbryant_work | It'd be purely superficial but the different streets could be the different plots |
| 19:57:17 | evan | be sure to put people waving on the peeks of the graph |
| 19:57:25 | brixen | and, could the graph line have address info (ie, click to show me the commit in github) |
| 19:57:42 | sbryant_work | haha |
| 19:58:00 | sbryant_work | Is anyone putting this on a gist or on the wiki? |
| 19:58:15 | brixen | what's 'this'? |
| 19:58:26 | sbryant_work | this super awesome google maps benchmark idea |
| 19:58:39 | brixen | it's just between us |
| 19:58:46 | brixen | well, between you and us |
| 19:58:51 | brixen | since you are going to deliver :) |
| 20:01:24 | sbryant_work | Some lofty features for a benchmark graph |
| 20:01:36 | dgtized | brixen: so if it's a sporadic spec failure during benchmark, does that get flagged somewhere? |
| 20:02:19 | brixen | you can file a ticket, or fix it |
| 20:03:16 | dgtized | I wasn't saying anything was broken, I was inquiring how things worked |
| 20:03:33 | brixen | well some as anything |
| 20:03:43 | brixen | what's special about this situation? |
| 20:04:28 | brixen | are you running the benches or are you asking about the nightly bench run? |
| 20:04:37 | dgtized | I'm asking about the nightly bench run |
| 20:04:47 | brixen | ok |
| 20:04:56 | brixen | well, I have the stdout from the run |
| 20:05:07 | brixen | they are mostly there as a signpost |
| 20:05:16 | brixen | if an issue appears, we'll look at it |
| 20:06:16 | dgtized | so we know that the discontinuities in the graph are do to deterministic failures that invalidated the whole run? |
| 20:06:39 | brixen | hm, no |
| 20:06:54 | brixen | we know that there was no valid data for that day |
| 20:06:59 | brixen | could be several things |
| 20:10:01 | dgtized | well perhaps now the jit is still unstable enough that it's not worth worrying about, but at some point we might want to use the nightly benchmarking to track down non-deterministic bugs in spec runs |
| 20:11:54 | evan | dgtized: "now that the jit is still unstable enough" |
| 20:11:56 | evan | that doesn't parse. |
| 20:13:49 | dgtized | sorry it should have read "well perhaps for now the jit" |
| 20:14:43 | brixen | you're assuming it has anything to do with the jit |
| 20:14:58 | dgtized | the graph that has lots of discontinous points is when the jit is enabled |
| 20:15:04 | brixen | yes |
| 20:15:11 | brixen | correlation is not causation |
| 20:15:27 | brixen | it's a stretch to even assume correlation |
| 20:15:40 | brixen | it happened during a run with the jit enabled |
| 20:15:44 | brixen | that's all we know |
| 20:16:13 | brixen | the benchmarks are for tracking time, let's leave it at that |
| 20:16:29 | brixen | if you think the jit is an issue, pull a rev for that day and run the specs |
| 20:17:11 | brixen | the bench runs at 3:30 am pst, so you can know precisely which rev is being run |
| 20:18:07 | dgtized | ok there are two things here, and apparently by accident I hit a button presuming that it was related to the jit so I apologize |
| 20:18:25 | brixen | it's not a button, no apology necessary |
| 20:18:40 | brixen | I'm clarifying what you are assuming |
| 20:18:54 | brixen | does no good to chase your tail on assumptions |
| 20:19:14 | dgtized | thing 1) we periodically have non-deterministic bugs that don't show up on every spec run, which means the automated build bot either catches it the first time, or it doesn't ever |
| 20:19:30 | brixen | sure |
| 20:20:07 | dgtized | given that the nightly benchmark runs mspec ci several times, it seemed reasonable to me that perhaps we could leverage that to detect those non-deterministic bugs |
| 20:20:22 | brixen | well, it's leveraged |
| 20:20:25 | brixen | it has a graph |
| 20:20:38 | brixen | but you'll have to investigate to get any more info |
| 20:20:58 | dgtized | are those logs accessable without logging into elle or whatever box it's on? |
| 20:21:05 | brixen | no |
| 20:21:39 | brixen | probably wouldn't be hard to put a link to them |
| 20:21:46 | evan | woop! |
| 20:21:48 | brixen | if evan wants to set up a route |
| 20:22:00 | brixen | evan: what'cha woopin about |
| 20:22:05 | evan | got the class checking guard setup to not use any functions |
| 20:22:12 | brixen | swee |
| 20:22:14 | brixen | +t |
| 20:22:21 | evan | one cool thing i've realized here |
| 20:22:24 | dgtized | ok, that would be awesome -- because then we would at least be able to check to see if it's just a random spec failure or something serious that is blocking that graph point |
| 20:22:32 | evan | with type feedback |
| 20:22:40 | evan | we KNOW if the object should be a ref or an immediate |
| 20:22:43 | evan | so checking the class is easier |
| 20:22:48 | brixen | nice |
| 20:22:54 | evan | because we can check if it's a ref object, and bail right away if not |
| 20:23:08 | evan | then pulling out the class (and then class_id) is easy |
| 20:23:23 | evan | that creates a nice predictable branch |
| 20:23:31 | evan | because the ref check is going to almost always be true |
| 20:23:33 | brixen | very cool |
| 20:47:36 | evan | looks like the class guard is 7 instructions |
| 20:47:49 | evan | well, really 6 |
| 20:48:09 | evan | actually no |
| 20:48:17 | evan | there is delay slot code here... |
| 20:49:00 | evan | 5 |
| 20:49:46 | evan | test, jnz, mov, cmp, jz |
| 20:50:11 | brixen | not too shabby |
| 20:50:15 | sbryant_work | nifty |
| 20:50:36 | evan | thats for a reference object |
| 20:50:44 | evan | the class guard for an immediate is 2 |
| 20:52:15 | brixen | evan: grabbing some lunch and running an errand, bbiab |
| 20:52:19 | evan | k |
| 21:12:54 | evan | hm, ok, so if an method has been inlined |
| 21:13:03 | evan | and someone goes off and changes that method in the class |
| 21:13:10 | evan | the inlined version shouldn't run anymore |
| 21:13:49 | dbussink | evan: are you also adding tests for stuff like that? |
| 21:13:57 | sbryant_work | evan: makes sense. |
| 21:14:09 | evan | dbussink: i will |
| 21:14:29 | dbussink | because it seems too easy to me to forget something at some moment :0 |
| 21:14:30 | evan | so what should happen in that case? |
| 21:14:30 | dbussink | :) |
| 21:14:58 | dbussink | whether it should reinline the new method you mean? |
| 21:15:01 | evan | could add anothe flag check to the guard, but then we'd never inline again |
| 21:15:27 | sbryant_work | what are the qualifications for method inlining? |
| 21:15:29 | evan | i suppose the thing to do is go around and set all the methods that inlined the old version back to use the interpreter |
| 21:15:53 | evan | and dump the JITd version, an reset the call counters |
| 21:15:59 | evan | so that it can be watched and JITed again |
| 21:16:20 | dbussink | that would be best solution probably, dunno how often something like this happens in for example rails |
| 21:16:20 | evan | sbryant_work: well, i'm writing those as well right now :) |
| 21:16:52 | evan | sbryant_work: it's related to likely hood (how many classes were seen at a call site) |
| 21:16:58 | dbussink | evan: what are the current limitations for inlining? no returns / or something else? |
| 21:17:05 | evan | size of method to be inlined (to control balloning) |
| 21:17:26 | evan | dbussink: well, the way I'm organizing it |
| 21:17:38 | evan | i'm going to lean on LLVMs inliner a little at first |
| 21:17:50 | evan | so techniquely it should be able to inline anything |
| 21:18:09 | evan | we'll see how that goes |
| 21:18:32 | evan | doing this will mean nested CallFrame objects in one C stack frame |
| 21:18:34 | evan | but thats ok |
| 21:19:43 | evan | dbussink: i'll probably step carefully into this pool though |
| 21:19:51 | evan | ie, i'll restrict the form of methods to be inlined |
| 21:19:59 | evan | to see how it behaves |
| 21:20:16 | sbryant_work | What kind of savings do you think will be seen? |
| 21:20:28 | dbussink | evan: btw, did you find some time to look at the Object#dup issue? |
| 21:20:41 | evan | dbussink: nope, not yet |
| 21:20:46 | evan | LazyArray sucks |
| 21:20:48 | evan | is the issue. |
| 21:21:05 | evan | i have to code some parts of the kernel defensively for it to run |
| 21:21:13 | evan | sbryant_work: well, thats where having LLVM comes into play |
| 21:21:26 | evan | sbryant_work: the more code exposed to LLVM, the fast that code is. |
| 21:21:39 | evan | and inlining is a great way to expose code. |
| 21:22:44 | sbryant_work | ahh I was wondering how that'd come into play |
| 21:22:58 | evan | consider something like |
| 21:22:59 | evan | o = 1 |
| 21:23:00 | sbryant_work | I didn't know if you were going to throw things at LLVM or do things before LLVM and let LLVM do them better |
| 21:23:03 | evan | def foo(a) |
| 21:23:06 | evan | return a + 1 |
| 21:23:06 | evan | end |
| 21:23:08 | evan | foo(o) |
| 21:23:23 | evan | if foo is inlined |
| 21:23:31 | evan | then LLVM will constant prop the addition |
| 21:23:42 | evan | and it will just become 2 at compile time |
| 21:24:00 | evan | another big one is alias analysis |
| 21:24:11 | sbryant_work | what is that? |
| 21:24:21 | sbryant_work | I have a guess but sometimes they're wrong |
| 21:24:40 | evan | thats the ability to answer "is x the same as y" |
| 21:24:49 | evan | with answers being yes, no, and maybe |
| 21:24:58 | sbryant_work | that's a tricky thing |
| 21:25:11 | evan | yep, and LLVM does a great job it. |
| 21:25:16 | sbryant_work | Nice. |
| 21:25:17 | evan | a great example is |
| 21:25:19 | evan | def foo(a) |
| 21:25:20 | evan | a |
| 21:25:21 | evan | end |
| 21:25:33 | evan | we feed LLVM all the ruby semantics |
| 21:25:50 | evan | so a is read in as an argument, stored as a locals |
| 21:25:55 | evan | then that local is read and returned |
| 21:26:11 | evan | if you look at the code post optimization though, i'll see that LLVM just turns that into |
| 21:26:15 | evan | read argument 0, return |
| 21:26:24 | evan | it forgoes the whole manipulation of the locals |
| 21:26:30 | sbryant_work | saves a lot of time. |
| 21:26:35 | evan | because it can reason that the value in the locals is the same as the argument |
| 21:26:57 | sbryant_work | That makes sense with an identity function |
| 21:27:06 | sbryant_work | but something more complex? |
| 21:27:29 | evan | at the ruby level, it can help, sure |
| 21:27:36 | evan | but it's more about the data movement required to implement ruby |
| 21:27:38 | evan | that it helps with |
| 21:27:47 | sbryant_work | ahh |
| 21:28:54 | sbryant_work | How about Procs or blocks? |
| 21:29:32 | evan | they're another unique place |
| 21:29:57 | evan | given something like |
| 21:30:05 | evan | 10.times { puts "sbryant loves ruby" } |
| 21:30:28 | evan | inlining should be able to do a couple things |
| 21:31:51 | evan | 1) inline the code for Integer#times into the caller |
| 21:32:04 | evan | 2) inline the code for the block into the inlined version of Integer#times |
| 21:32:18 | evan | and poof |
| 21:32:22 | evan | the closure is gone. |
| 21:32:39 | evan | it's been turned into a while loop running at he call site |
| 21:32:46 | evan | s/he/the/ |
| 21:32:58 | sbryant_work | yeah, makes sense. |
| 21:35:27 | sbryant_work | evan: you're teaching LLVM about ruby? |
| 21:35:42 | evan | in a manner of speaking, yes. |
| 21:35:46 | sbryant_work | What does that mean, like grammar and calling conventions? |
| 21:38:30 | evan | well, rubinius is long tail from the grammar |
| 21:38:41 | evan | our internal bytecode is our bread and butter |
| 21:39:15 | evan | as for call conventions, ruby has them, but they're not like C's at all |
| 21:39:26 | evan | they don't say "the arguments go in memory relative to this thing" |
| 21:39:47 | evan | so i had to create a call convention |
| 21:39:55 | evan | that can be used by the VM |
| 21:44:05 | sbryant_work | ahh. |
| 21:44:21 | sbryant_work | So you taught it about rubinius bytecode? |
| 21:44:53 | evan | in a manner of speaking again :) |
| 21:44:59 | evan | what I do is walk the bytecode |
| 21:45:24 | evan | and for each instruction, use LLVM's API to create IR that does the same thing as the bytecode would do |
| 21:45:26 | sbryant_work | hah, sorry if I'm bugging you. Language design is not my strongest skill. So these are actually helpful for me. |
| 21:45:32 | evan | no prob |
| 21:46:14 | sbryant_work | So then you let LLVM take over and do its thing because it has all it needs to know? |
| 21:46:22 | evan | right |
| 21:46:34 | evan | so now i've got the method as LLVM IR |
| 21:46:41 | evan | which LLVM can optimize |
| 21:46:44 | evan | and turn into machine code |
| 21:47:04 | evan | by that stage, the original ruby code has gone through these transforms |
| 21:47:19 | evan | text / node tree / sexp / AST / bytecode / IR |
| 21:47:50 | evan | i guess really |
| 21:47:54 | evan | text / node tree / sexp / AST / bytecode / IR / machine code |
| 21:47:57 | sbryant_work | IR is the intermediate representation? |
| 21:48:00 | evan | yeah |
| 21:48:18 | sbryant_work | okay |
| 21:48:21 | evan | LLVM's API has you build a datastructure (IR) of the work to be done |
| 21:48:28 | sbryant_work | I was trying to see how rubinius leveraged LLVM. |
| 21:52:11 | sbryant_work | thanks evan. |
| 21:52:53 | evan | no prob |
| 21:57:40 | sbryant_work | Someone asked me about the LLVM integration and now I have answers! |
| 21:57:48 | evan | there ya go! |
| 21:57:53 | sbryant_work | yeah it was quite a while. |
| 22:05:35 | evan | slava: you around? |
| 22:05:41 | evan | by your tweet, i'm guessing not |
| 22:52:06 | dgtized | evan: with the example of inlining, you still have to push at least one form of closure context though right? |
| 22:54:12 | evan | depends |
| 22:54:13 | evan | why? |
| 22:55:09 | dgtized | 10.times {|x| a = x }; x = a + 1 still needs to throw because a only exists inside the scope of the times |
| 22:56:01 | dgtized | (and yes I know it's a stupid example, but if I remember correctly there are more useful ones) |
| 22:56:34 | evan | "throw" what? |
| 22:56:43 | evan | thats a parsing issue |
| 22:56:53 | evan | thats decided LONG before inlining |
| 22:58:46 | dgtized | i'm trying to remember the example that headius pointed out when we were inlining all instances of loop as a while(1) |
| 22:59:00 | evan | thats totally different. |
| 22:59:18 | evan | because we flattening the local scope there |
| 22:59:42 | evan | this inlining would handle that the vars for the block are sepearte from the vars of the method |
| 23:00:14 | dgtized | by pushing some sort of block context just before entering the inlined loop? |
| 23:01:12 | dgtized | my terminology is wrong here, but I guess I'm asking if we basically treat it as 10.times {|x| x } has an enter/leave block on each call for that example, but inlined it would have an enter_block, while loop, x, exit_block |
| 23:01:40 | evan | it's really not about the block |
| 23:01:53 | evan | but about what data structure is used to store the locals. |
| 23:02:18 | evan | if a block is inlined, the var access that was inlined uses a data structure that is just for those inlined block vars |
| 23:02:27 | evan | there is no more block context |
| 23:02:34 | evan | i did away with it awhile back |
| 23:02:44 | evan | there is just CallFrame and VariableScope |
| 23:03:18 | dgtized | ok, and CallFrame takes care of giving exceptions the right list of methods to bubble out of? |
| 23:04:29 | evan | no |
| 23:04:47 | evan | exceptions are entirely flattened into execution logic |
| 23:05:08 | evan | CallFrame doesn't even have to know. |
| 23:05:17 | evan | to pass an exception to your caller, you return NULL |
| 23:05:31 | evan | who sees the null, and runs it's handlers. |
| 23:06:02 | evan | because we use dynamic exception handlers now |
| 23:06:12 | evan | the JIT can see the rescue "stack" at compile time |
| 23:06:29 | evan | and figure out how to run through the handlers by just jumping to code |
| 23:06:45 | dgtized | ok, so it flattens it, but the exception still thinks that it was fired within unflattened code |
| 23:06:47 | evan | unwind an exception through a method with no handlers is ultra fast as a result |
| 23:06:58 | evan | it ends up being |
| 23:07:02 | evan | if(!res) return NULL; |
| 23:07:13 | evan | that equiv in machine code |
| 23:07:36 | evan | dgtized: why would the exception have to reason about who was handling it? |
| 23:07:49 | dgtized | I just meant for correct backtraces |
| 23:08:10 | evan | the backtrace is created when the exception is raised now. |
| 23:08:13 | evan | it's not lazy like before. |
| 23:08:16 | evan | which is good actually |
| 23:08:22 | evan | lazy backtraces were commonly wrong |
| 23:08:45 | ddub | I just come back from idling to ask whats going on |
| 23:08:49 | ddub | and someone's busy writing a novel |
| 23:09:00 | evan | heh |
| 23:10:00 | dgtized | evan: alright, I think I follow -- anyway I'll think on the inlining -- there is some example that is nibbling around at the back of my brain, I'll come back when it actually bites on something |
| 23:12:40 | evan | ok |
| 23:19:52 | brixen | it would be hard to argue there is any worse code in all of rubinius than loader.rb |
| 23:20:06 | brixen | but I am close to having an improvement I would say |
| 23:20:06 | evan | oh thats sad. |
| 23:20:12 | evan | thats good. |
| 23:20:14 | brixen | heh |
| 23:20:22 | evan | i'm adding deoptimization |
| 23:20:29 | brixen | sweet |
| 23:30:00 | ddub | is rubinius so fast now that you have to deoptimize it? |
| 23:30:11 | brixen | yes |
| 23:30:17 | brixen | we are making the others look bad |
| 23:30:26 | brixen | which has social consequences |
| 23:31:11 | ddub | just move those optimizations on the robots_on_unicorns branch |
| 23:31:22 | ddub | you can merge them into mainline over the next 3-4 years |
| 23:32:00 | evan | hehe |
| 23:32:19 | brixen | we have ponies prancing on turtles atm, which is a rather apt metaphor |
| 23:32:31 | brixen | the robots are vaporware |
| 23:33:04 | ddub | of course, they vaporized the software |
| 23:33:07 | ddub | with their laser eyes |
| 23:33:12 | brixen | heh |