Da
Show enters and exits. Hide enters and exits.
| 00:32:24 | dgtized | brixen: there are a couple of specs in the full set that either segfault or hang |
| 00:32:58 | dgtized | I guess switching to include them increases the likelyhood that enough testing will actually catch them |
| 00:33:35 | dgtized | it's just that the library spec set is a lot more flaky for standard spec runs |
| 00:36:19 | rue | Only one thing to do |
| 00:40:20 | brixen | dgtized: I tested it on the 3 systems that are readily available |
| 00:40:28 | brixen | if you have issues, I need information |
| 01:29:29 | brixen | sweet, 5 sec off of 60 on a spec run, I'll take that |
| 01:29:51 | evan | what did ya change? |
| 01:30:06 | brixen | recursion guard has no business being a stack |
| 01:30:10 | brixen | I changed it to a hash |
| 01:30:17 | brixen | lookuptable actually |
| 01:30:31 | brixen | I'm going to put it on Thread I think |
| 01:30:39 | brixen | Thread.recursion_guard(obj) |
| 01:30:49 | brixen | since in uses a Thread local |
| 01:31:27 | dgtized | wait I thought it was a lookuptable |
| 01:31:36 | evan | good plan |
| 01:31:38 | evan | dgtized: it was an Array |
| 01:31:40 | brixen | evan: ok |
| 01:31:43 | evan | that used include? to find things |
| 01:31:47 | brixen | yeah |
| 01:31:49 | brixen | terrible |
| 01:31:52 | evan | brixen: since we're hitting it a lot |
| 01:31:54 | evan | do a quick experiment |
| 01:32:01 | evan | drop it to a prim on Thread |
| 01:32:15 | evan | and add a LookupTable slot to Thread in C++ land |
| 01:32:21 | evan | see what that gives ya |
| 01:32:24 | brixen | ok |
| 01:32:31 | brixen | I was thinking that too |
| 01:32:39 | brixen | other thing is, it relies on object_id |
| 01:32:44 | evan | thats stupid. |
| 01:32:45 | brixen | how fast is that these days? |
| 01:32:48 | evan | ignore that. |
| 01:32:55 | brixen | well you need identity |
| 01:33:02 | evan | LookupTable keys ARE identity |
| 01:33:11 | evan | they use C's == |
| 01:33:18 | brixen | ah yes ok |
| 01:33:30 | brixen | it was using an object_id (fixnum) to access that |
| 01:33:32 | brixen | yeah, gotcha |
| 01:33:46 | evan | he used object_id so that the objects #hash wasn't needed |
| 01:33:51 | evan | and so it was the true identity |
| 01:33:56 | evan | LookupTable uses the true identity |
| 01:33:56 | brixen | k |
| 01:34:02 | evan | it doesn't allow for the class to override |
| 01:35:03 | brixen | evan: compare http://gist.github.com/103268 |
| 01:35:53 | brixen | pre-prim it's down to 1.41 self sec from 5.85 |
| 01:36:01 | evan | super rad |
| 01:36:08 | evan | looks like we should do 2 things |
| 01:36:17 | evan | 1) re-enable the Class#new compiler speedup |
| 01:36:22 | evan | 2) remove Module#clear_association |
| 01:37:11 | brixen | evan: a prim can take a block? |
| 01:37:24 | evan | umm |
| 01:37:26 | evan | no |
| 01:37:30 | evan | i don't think we ever wired that up |
| 01:37:46 | brixen | k, cus this adds the obj and yields |
| 01:37:49 | brixen | then removes the obj |
| 01:37:53 | brixen | for the guard |
| 01:37:53 | evan | brb |
| 01:37:56 | brixen | k |
| 01:38:41 | dgtized | brixen: is the costly bit calling inspecting, or inspecting? |
| 01:39:11 | dgtized | or sorry RecursionGuard.inspect is the guarded one right? |
| 01:49:41 | dgtized | brixen: also -- I'm not sure why the specs were failing earlier, that issue seems to have disappeared -- it was consistantly being inconsistant about crashing every couple of times, and now it's just running smoothly |
| 01:49:53 | dgtized | i'll let you know if it breaks again |
| 01:50:06 | brixen | k |
| 01:56:42 | dgtized | wow we are only down to 12 failing specs in language |
| 01:57:25 | dgtized | sorry delete the only from above |
| 01:57:50 | dgtized | or put it before the 12 |
| 01:58:06 | slava | my inline caches are working! |
| 01:58:19 | brixen | slava: sweet |
| 01:58:25 | evan | ok, going to get more stuff from the car |
| 01:58:30 | evan | i've got the last load in the car! yay! |
| 01:58:36 | evan | (man this moving shit sucks) |
| 01:58:39 | brixen | what percentage are pelymorphic |
| 01:58:43 | brixen | er poly* |
| 02:02:02 | evan | slava: i'd love to hear about your stats |
| 02:02:17 | evan | % polymorphic, what speedup you get, etc |
| 02:07:37 | slava | evan: I'm still debugging |
| 02:07:57 | brixen | ahh, for certain values of working :) |
| 02:08:22 | evan | it's working!! (see section 3.a for definiton of working) |
| 02:15:31 | brixen | evan: bt's are super sweet now, btw :) |
| 02:15:51 | brixen | took me a while to notice because they are just nice and not annoying |
| 02:16:29 | evan | :D |
| 02:16:33 | evan | hah |
| 02:16:36 | evan | i'm working on a weird bug |
| 02:16:41 | evan | the first line, when the path is broken up |
| 02:16:49 | evan | the indent is too far |
| 02:16:52 | evan | it's weird. |
| 02:18:26 | slava | I've been adding a ton of asserts to my vm lately |
| 02:18:35 | slava | and there's a compile flag to enable them |
| 02:18:39 | evan | oh der. |
| 02:18:58 | evan | the color control is throwing it off |
| 02:19:04 | brixen | man, #join on recursive arrays o/~ sucks o/~ |
| 02:19:08 | evan | haha |
| 02:19:12 | evan | finally! |
| 02:19:18 | evan | someone else using singing on IRC |
| 02:19:24 | brixen | hah |
| 02:19:25 | evan | i always feel like i'm the only one that does that |
| 02:19:28 | brixen | learned from you |
| 02:19:48 | evan | :D |
| 02:19:52 | evan | bingo, fixed the indent |
| 02:20:54 | brixen | sweet |
| 02:21:03 | brixen | I've got one damn spec failing |
| 02:21:19 | brixen | I fix it, another breaks |
| 02:21:56 | brixen | the fact that MRI allows recursive arrays in a File.join is so crazy |
| 02:22:06 | brixen | you ain't gonna find a file with the result |
| 02:24:26 | evan | haha |
| 02:24:41 | brixen | http://gist.github.com/103514 |
| 02:24:46 | brixen | that is fucking stupid |
| 02:24:48 | evan | raise NoSeriously, "No files available in the middle of a black hole" |
| 02:25:06 | brixen | if #join is going to do that |
| 02:25:10 | evan | man thats stupid |
| 02:25:30 | brixen | then #inspect should be [1,2,3,[1,2,3,[...]] |
| 02:27:03 | brixen | evan: perhaps I should file a bug on that? |
| 02:27:05 | evan | is it not? |
| 02:27:19 | brixen | the inspect is just above in the gist |
| 02:27:27 | brixen | #join is lame |
| 02:27:33 | evan | why the fuck does it list it TWICE before going recursive |
| 02:27:36 | evan | thats got to be a bug. |
| 02:27:40 | brixen | ok |
| 02:27:54 | brixen | we output "123[...]" |
| 02:27:59 | evan | thats fine |
| 02:28:00 | brixen | I'll file a bug |
| 02:28:03 | evan | stick with that. |
| 02:28:06 | brixen | k |
| 02:32:20 | evan | muhah |
| 02:32:27 | evan | ok, i've fixed it even more |
| 02:32:38 | evan | it now never outputs backtraces past 80 columns |
| 02:33:29 | evan | oh hot shit..... |
| 02:33:34 | evan | goes the extra mile. |
| 02:35:25 | brixen | hehe |
| 02:35:41 | evan | hm... |
| 02:37:22 | evan | damn. |
| 02:37:25 | evan | in a shell |
| 02:37:27 | evan | there is $COLUMNS |
| 02:37:35 | evan | but it's not a real env var |
| 02:39:24 | brixen | oh wtf |
| 02:39:27 | brixen | yes, it is a bugh |
| 02:39:32 | brixen | it was fixed |
| 02:39:42 | brixen | but originally not in 1.9 |
| 02:39:52 | brixen | so the specs for 1.9 are outdated |
| 02:40:03 | evan | sweet. |
| 02:40:05 | brixen | I need to sync our specs |
| 02:44:29 | brixen | oh man, but they did not fix it for File.join |
| 02:44:35 | brixen | *facepalm* |
| 02:44:47 | brixen | food |
| 02:45:47 | evan | muhah |
| 02:45:50 | evan | haws! |
| 02:45:52 | evan | damn! |
| 02:45:56 | evan | it's 6:45 |
| 02:45:58 | evan | this day is flying. |
| 02:53:00 | evan | muhhah |
| 02:53:01 | boyscout | Improve backtraces, dynamicly adjust to terminal width - 49b1b07 - Evan Phoenix |
| 02:55:29 | slava | evan: seems polymorphic call sites are pretty rare |
| 02:55:46 | brixen | slava: that's what we've seen too |
| 02:55:54 | brixen | I was curious what you'd see |
| 02:56:05 | slava | unfortunately in my case tail calls cannot call an IC stub |
| 02:56:10 | slava | so a tail call to a generic word is always megamorphic |
| 02:56:50 | evan | btw |
| 02:56:59 | evan | `tput cols` is sweet |
| 02:57:19 | brixen | nice |
| 03:00:24 | evan | brixen: so now backtraces never wrap |
| 03:01:01 | brixen | saweet |
| 03:01:23 | brixen | do they expand your terminal? :) |
| 03:01:29 | evan | hah |
| 03:01:49 | evan | "looks like you need a bigger viewport, let me get that for ya" |
| 03:01:55 | brixen | heh |
| 03:02:08 | evan | where does mspec print out the backtrace? |
| 03:02:52 | brixen | um.. |
| 03:03:04 | brixen | depends on the formatter |
| 03:03:26 | evan | the default |
| 03:03:28 | evan | i want to check something |
| 03:03:37 | brixen | see eg mspec/lib/mspec/runner/formatter/dotted.rb |
| 03:04:04 | brixen | in #finish |
| 03:04:05 | evan | ok, it's just calling |
| 03:04:09 | evan | print exc.backtrace |
| 03:04:11 | brixen | yeah |
| 03:04:13 | slava | its annoying that TCO makes backtraces somewhat useless |
| 03:04:15 | evan | k |
| 03:04:20 | evan | yep |
| 03:04:25 | evan | slava: very annoying |
| 03:05:08 | evan | thats interesting |
| 03:05:12 | evan | why is the nice backtrace shown then? |
| 03:05:24 | evan | since Exception#backtrace call to_mri |
| 03:06:43 | brixen | hm, good question |
| 03:11:28 | evan | any ideas? |
| 03:12:33 | brixen | not off hand, le'me look |
| 03:13:43 | brixen | heh um yeah |
| 03:13:55 | brixen | mspec/lib/mspec/runner/exception.rb |
| 03:14:03 | brixen | def backtrace :) |
| 03:14:25 | evan | oh der |
| 03:14:28 | evan | exc is not an Exception here |
| 03:14:32 | brixen | right |
| 03:14:41 | brixen | I was confused too |
| 03:15:03 | evan | interesting.. |
| 03:15:07 | evan | whats that line below there? |
| 03:15:13 | evan | rejecting lines |
| 03:15:18 | evan | i saw something like this earlier |
| 03:15:23 | evan | where when i was screwing up the output |
| 03:15:26 | evan | lines were disappearing |
| 03:15:29 | brixen | right |
| 03:15:45 | brixen | it's supposed to leave out mspec files |
| 03:15:59 | evan | i see lots of mspec files |
| 03:16:02 | evan | i'd rather see them. |
| 03:16:10 | brixen | well, there's a lot |
| 03:16:14 | evan | well |
| 03:16:17 | brixen | and they make the bt long |
| 03:16:19 | evan | now that I changed the output |
| 03:16:21 | evan | they show up |
| 03:16:23 | evan | all the time |
| 03:16:40 | brixen | yeah, cus the regexp is wrong |
| 03:16:58 | brixen | I can take it out |
| 03:17:04 | evan | lets take it out for now |
| 03:17:07 | brixen | rspec omits rspec files |
| 03:17:10 | evan | ah |
| 03:17:13 | evan | i prefer to see it |
| 03:17:16 | evan | because it's less magical |
| 03:17:23 | brixen | I kinda do |
| 03:17:30 | evan | i always get confused when those lines are left out of the backtrace |
| 03:17:31 | brixen | except that each bt is a screen |
| 03:17:37 | evan | because i go "um.. how did THAT get to there from THERE...." |
| 03:17:53 | brixen | and when I'm dealing with 100s of exceptions, it sucks |
| 03:18:03 | evan | hm |
| 03:18:20 | evan | the line splitting I added REALLY fucks this up. |
| 03:18:28 | evan | because you could reject partial lines |
| 03:18:41 | brixen | that's ok, it's a hack |
| 03:18:44 | evan | ok |
| 03:18:45 | brixen | I'll take it out |
| 03:20:02 | evan | well |
| 03:20:04 | evan | how about this |
| 03:20:11 | evan | add a -d option to mspec |
| 03:20:19 | evan | ala debug |
| 03:20:26 | evan | to not leave out lines |
| 03:20:41 | brixen | could |
| 03:20:46 | evan | and change the regexp to be what it is and also |^mspec/lib/mspec |
| 03:20:55 | evan | best of both worlds |
| 03:21:01 | brixen | sure |
| 03:21:07 | evan | crunchy outside, soft inside |
| 03:21:11 | brixen | hah |
| 03:21:23 | brixen | speaking of, dinner... bbiab |
| 03:21:24 | evan | like a lobster! |
| 03:21:25 | evan | mmm |
| 03:21:26 | evan | dinner. |
| 03:21:27 | evan | yes. |
| 03:37:16 | evan | ug |
| 03:37:23 | evan | the return specs are masking their own failure |
| 03:37:29 | evan | ie, if these LJE test fail |
| 03:37:32 | evan | the script returns |
| 03:38:00 | slava | so here are my initial observations |
| 03:38:01 | evan | oh hm |
| 03:38:02 | evan | maybe not. |
| 03:38:13 | slava | almost no speedup, buggy, too many tail calls that just become monomorphic :) |
| 03:38:17 | slava | s/mono/mega |
| 03:38:25 | evan | :D |
| 03:38:26 | evan | yeah |
| 03:38:29 | evan | thats why most stick with mono |
| 03:38:38 | evan | and disable it if the cache spins |
| 03:40:07 | slava | I haven't optimized much yet |
| 03:40:20 | slava | I expect to get a speedup once I start bumming instructions out of the hot paths |
| 03:42:23 | evan | ok, bbiab. |
| 04:01:19 | slava | evan: ok, so my code was broken and it wasn't installing pics in all the right call sites |
| 04:01:30 | slava | they would revert to megamorphic erronously |
| 04:01:45 | slava | also sometimes the asm generated was wrong and the cache would always miss hehe |
| 04:18:28 | evan | slava: so hows it working now? |
| 04:18:34 | slava | still debugging :) |
| 04:21:12 | slava | evan: I suck at debugging low-level code |
| 04:21:36 | evan | it's hard |
| 04:21:42 | slava | evan: my brain just freezes up when it encounters dangling pointers, corrupt data, etc |
| 04:21:43 | evan | you're using |
| 04:21:46 | evan | display /i $pc |
| 04:21:47 | evan | right? |
| 04:21:51 | slava | heh |
| 04:21:58 | slava | I'm not even that good with gdb ;) |
| 04:21:59 | slava | printf baby |
| 04:22:04 | evan | dude |
| 04:22:04 | slava | that's how I debug |
| 04:22:12 | evan | thats way too hard for lowlevel code |
| 04:22:19 | evan | use printf to figure out where to set breakpoints |
| 04:22:22 | evan | then use |
| 04:22:24 | evan | display /i $pc |
| 04:22:25 | evan | and si |
| 04:22:29 | slava | sure I use breakpoints |
| 04:22:30 | evan | to step one instruction at a time |
| 04:22:39 | evan | and have gdb disassemble as it moves |
| 04:27:44 | slava | thanks for the tip, I didn't know about the /i switch |
| 04:28:31 | slava | evan: does gdb work well for C++? |
| 04:31:27 | evan | very |
| 04:31:35 | evan | it's got some weird parts |
| 04:31:39 | evan | but is mostly fine |
| 04:31:47 | evan | it get confused by casts sometimes |
| 04:31:51 | evan | i haven't figured out why |
| 04:32:08 | evan | yeah |
| 04:32:10 | evan | display /i $pc |
| 04:32:12 | evan | is a lifesaver |
| 04:32:15 | evan | when you're down low |
| 04:32:36 | slava | still buggy, but I got a 33% improvement on one benchmark |
| 04:42:28 | brixen | evan: you should write a short cut pdf on gdb for pragprog |
| 05:42:24 | slava | evan: http://lhealy.livejournal.com/12721.html |
| 05:42:43 | slava | you might find his code useful to look at |
| 06:33:23 | evan | slava: structs by value I think requires the caller to pass in a pointer to stack memory |
| 06:33:27 | evan | to be used for the return value |
| 06:33:38 | slava | yeah |
| 06:36:26 | evan | my immix.hpp uses a interesting technique though |
| 06:36:37 | evan | there is an Address struct that is used only by value |
| 06:36:40 | evan | and return by value |
| 06:36:46 | evan | but it's only storage is a uintptr_t |
| 06:36:57 | evan | so gcc ends up optimizing the struct away entirely |
| 06:37:09 | slava | only on some architectures |
| 06:37:10 | evan | since the requires fields fit in one register |
| 06:37:23 | slava | yes, on some abis structs-by-value can be returned in registers if they're below a certin size |
| 07:29:35 | boyscout | Fixed Array#== to dispatch to other. - 57f1a88 - Brian Ford |
| 07:29:35 | boyscout | Pulled in Array#to_s and File.join specs for recursive arrays. - c9be299 - Brian Ford |
| 07:29:35 | boyscout | Step 1 of reworking recursion guard. - c4ae396 - Brian Ford |
| 07:29:51 | brixen | evan: I've isolated the recursion guard on Thread |
| 07:30:17 | brixen | but I cannat see how to do it without object_id, since LT hashes the object to a bin based on the pointer value |
| 07:30:32 | brixen | if that object moves, it won't find its bin |
| 07:32:03 | brixen | in other news, Hash methods are 8 of the top 16 methods in a profile of CI, and about 50% of the self seconds |
| 07:33:43 | evan | interestin.g |
| 07:33:46 | evan | in all accounts. |
| 07:33:54 | evan | your bin comment is right on |
| 07:33:57 | evan | totally forgot about that |
| 07:34:02 | brixen | ok cool |
| 07:34:06 | brixen | I tried it :) |
| 07:34:10 | evan | :D |
| 07:34:18 | slava | evan: so I'm resetting all call sites every major GC |
| 07:34:18 | evan | using object_id is fine. |
| 07:34:38 | brixen | oh yeah, it made little difference |
| 07:34:44 | evan | figured |
| 07:34:47 | brixen | 1.3 to 0.8 self seconds |
| 07:34:48 | slava | evan: my theory is that if a call site is serially monomorphic, resetting it once in a while is better than just having it go megamorphic at some point and never recover |
| 07:34:51 | evan | how about direct versus prim? |
| 07:34:53 | brixen | which is small for this |
| 07:34:56 | evan | 1.3 direct, 0.8 prim |
| 07:34:56 | evan | ? |
| 07:35:01 | evan | direct == ruby |
| 07:35:07 | brixen | no, for not using object_id |
| 07:35:10 | evan | ah. |
| 07:35:17 | brixen | I can't yield from a prim |
| 07:35:23 | brixen | so I didn't do that |
| 07:35:28 | evan | slava: thats very likely true |
| 07:35:41 | evan | slava: nice thing about ICs is you can clear them anytime you want |
| 07:35:42 | slava | evan: the downside is that you allocate a lot of pic stubs |
| 07:35:59 | evan | well, have you seen a MIC vs PIC performance improvement? |
| 07:36:01 | slava | I need to fix one more bug then I can start optimizing |
| 07:36:10 | slava | evan: I'm seeing about a 10:1 ratio of mono to polymorphic call sites |
| 07:36:14 | evan | brixen: why do you need to yield? |
| 07:36:21 | evan | brixen: oh, that thing takes a block |
| 07:36:21 | evan | gotcha |
| 07:36:25 | brixen | yeah |
| 07:36:38 | brixen | I tried a version that used ensure in the methods |
| 07:36:44 | brixen | that... didn't work |
| 07:36:49 | evan | heh. |
| 07:36:49 | evan | ok |
| 07:36:49 | brixen | not sure why |
| 07:36:51 | slava | evan: there's a performance regression over my method dispatch from 4 days ago |
| 07:36:59 | slava | evan: ICs have almost won back the loss :) |
| 07:37:31 | brixen | evan: so, to remove Module#clear_associations we need a global serial # for constants? |
| 07:37:51 | evan | brixen: so whats the final tally on performance improvement for the new guard code? |
| 07:37:58 | slava | evan: The fallback on cache miss is slower than the old method dispatch system (which did a full dispatch and had no caching of any kind) |
| 07:38:15 | slava | evan: but an IC hit is faster than a full dispatch used to be |
| 07:38:22 | brixen | evan: ~5 sec less out of 60, so I'm seeing ~55 sec on a compiled run now |
| 07:38:31 | slava | evan: so I have to speed up both the slow case and fast case |
| 07:38:32 | evan | brixen: yeah, using a global serial that is incremented whenever a constant is set |
| 07:38:37 | brixen | evan: ok |
| 07:38:38 | evan | brixen: sweet. |
| 07:38:50 | evan | brixen: we need to rework the code a little though |
| 07:38:59 | brixen | ok |
| 07:39:01 | slava | evan: I used to compile a decision tree which did method dispatch over a set of classes with the minimum number of branches possible |
| 07:39:07 | evan | since I wired the cache buckets into the LookupTables directly |
| 07:39:11 | evan | so they need to be unwired a little |
| 07:39:17 | evan | i'll take a crack right now |
| 07:39:21 | evan | it should be easy |
| 07:39:22 | brixen | ah ok |
| 07:39:39 | evan | slava: right, i recall |
| 07:39:56 | brixen | evan: I forget, did you have cuckoo hash code for LT or for our Ruby hash? |
| 07:40:05 | slava | evan: I finally decided to ditch that approach to cut down on compile time (generating the dispatcher code took a long time) |
| 07:40:08 | evan | it's completely independent |
| 07:40:13 | evan | brixen: hold on |
| 07:40:17 | evan | i need to stop sitting on this code |
| 07:40:20 | evan | where should I put it |
| 07:40:30 | slava | evan: basically by using ICs I'm moving some work from compile to run time. I'll see how much it pays off in the end |
| 07:40:37 | slava | the old method dispatch was also very fast |
| 07:40:52 | brixen | evan: anywhere |
| 07:40:54 | evan | slava: what was the comparison in the tree? |
| 07:41:19 | slava | evan: well the root checks the pointer tag, leaves check header fields |
| 07:41:40 | slava | evan: it would compile into the same code that a C compiler would generate for a bunch of switches and ifs that check a class pointer |
| 07:41:46 | evan | brixen: http://gist.github.com/103631 |
| 07:41:55 | evan | http://gist.github.com/103632 |
| 07:41:59 | slava | evan: addinga nd removing methods would rebuild dispatchers so at any given point in time they were optimal |
| 07:42:01 | evan | C++ and .rb |
| 07:42:29 | slava | but this doesn't scale as the number of methods in a generic word increases |
| 07:42:36 | slava | or equivalently in message-passing OO, the number of methods on the same selector |
| 07:42:38 | evan | slava: so before, the compiler would kick in to recompile the dispatcher |
| 07:43:09 | slava | yeah, now the IC miss fallback just looks in a hash essentially |
| 07:43:21 | slava | its slower than the old dispatchers because it involves loops and memory ops etc |
| 07:43:29 | evan | right |
| 07:43:36 | evan | before you had a nice, linear search |
| 07:43:48 | evan | now you've got some math and then a few memory accesses |
| 07:44:01 | slava | and a call into C |
| 07:44:23 | slava | method lookup is now done in C instaead of generated machine code |
| 07:45:23 | evan | makes sense |
| 07:50:07 | slava | evan: http://paste.factorcode.org/paste?id=623 |
| 07:51:23 | slava | evan: looks like ICs eliminate 4 out of 5 full dispatches |
| 07:51:49 | slava | that's really great considering the compiler gets a good ratio too |
| 07:51:59 | evan | yeah |
| 07:52:05 | evan | congrats on seeing PIC lower than MIC |
| 07:52:08 | evan | time wise |
| 07:52:14 | evan | that means that you've bottlenecked in dispatch |
| 07:52:16 | slava | nah, I can't find a benchmark where it makes a measureable idfference |
| 07:52:18 | evan | and the rest of the system is humming along |
| 07:52:39 | evan | slava: well, richards is the one that stress polymorphism |
| 07:53:04 | evan | basically one class that calls a method on a list of objects |
| 07:53:12 | evan | and that list is 1 of 5 times |
| 07:53:20 | evan | a lot |
| 07:53:22 | slava | yeah, I've seen that benchmark, its kind of silly :) |
| 07:53:25 | evan | thats where the PIC shows up |
| 07:53:28 | evan | it's silly |
| 07:53:36 | evan | but it's not the work it does persay |
| 07:53:38 | evan | but how it does it :) |
| 07:54:52 | slava | evan: wow, binary-trees: 59165033 megamorphic calls w/o ICs and only 1078 with |
| 07:55:10 | evan | hah |
| 07:55:11 | evan | nice |
| 07:55:20 | evan | yeah, probably because the tree's values are diverse |
| 07:55:27 | slava | ooh, binary-trees shows a big speedup with PICs |
| 07:55:42 | slava | with MICs, you still have 58808739 megamorphic calls |
| 07:56:04 | slava | actually, seems bimorphic is enough |
| 07:56:36 | slava | yup. in binary-trees, the child of every node is either another node, or a null value |
| 07:58:52 | slava | evan: http://paste.factorcode.org/paste?id=624 |
| 07:59:36 | slava | evan: notice how its a matter of 8 callsites going full mega instead of poly. that's the only difference in the pic stats |
| 07:59:50 | slava | those 8 call sites contribute a lot of calls to the megamorphic tally and that makes .6 seconds of difference |
| 08:02:44 | brixen | evan: can these numbers be right? http://pastie.org/462176 |
| 08:02:57 | brixen | rbx is faster than mri running the cuckoo hash code? |
| 08:03:17 | brixen | I had to disable unprof to get #s for mri |
| 08:07:03 | evan | pastie is down |
| 08:07:06 | slava | evan: do you have ICs for ivar access? |
| 08:07:30 | evan | brixen: could ya put that somewhere else |
| 08:07:31 | evan | slava: no |
| 08:07:44 | evan | because what would you cache? |
| 08:07:59 | slava | the slot offset |
| 08:08:04 | evan | it's not fixed |
| 08:08:07 | brixen | evan: http://gist.github.com/103636 |
| 08:08:08 | slava | ah |
| 08:08:10 | evan | so there is no slot offset to cache |
| 08:09:01 | brixen | I guess I should write a set of hash method benches |
| 08:09:12 | evan | yeah |
| 08:09:15 | evan | those numbers are right |
| 08:09:17 | slava | evan: I think I'll add something like that at some point |
| 08:09:22 | evan | since MRI has hash all in C |
| 08:09:24 | slava | evan: I want to speed up polymorphic code as much as possible |
| 08:09:25 | brixen | if this is generally 75% faster than the existing, that's a good gain |
| 08:09:31 | evan | this shows off how much better our tech is for running ruby code |
| 08:09:38 | brixen | I guess so |
| 08:09:42 | brixen | makes me happy |
| 08:09:44 | brixen | :) |
| 08:09:59 | evan | oh, me too :D |
| 08:10:26 | evan | slava: we're working to eventually fix the layout of instances so there are slots |
| 08:10:34 | slava | good plan |
| 08:10:59 | evan | in which case, there will be an IC and a fast path in JITd code |
| 08:11:19 | evan | if(obj->klass == last_klass) val = OFFSET_AT(obj, 10); |
| 08:11:31 | slava | yup |
| 08:11:32 | evan | else val = slow_ivar(obj) |
| 08:12:02 | slava | in my case, ivar accessors are methods, so slow_ivar would be another PIC :) |
| 08:12:20 | slava | but I want to special-case the auto-generated ones, that just load from a slot |
| 08:12:32 | slava | the PIC doesn't have to jump into the body at all |
| 08:12:52 | evan | right |
| 08:12:53 | evan | you should |
| 08:12:59 | evan | have special MICs and PICs |
| 08:13:05 | evan | that, when they hit, just run some code right there |
| 08:13:09 | evan | rather than doing a call |
| 08:13:14 | slava | yeah |
| 08:37:49 | brixen | yay http://redmine.ruby-lang.org/repositories/diff/ruby-18?rev=23306 |
| 08:38:59 | evan | ha ha! |
| 08:39:02 | evan | victory is ours! |
| 08:39:08 | evan | and speedy victory too wow |
| 08:39:13 | evan | i wish they were all that fast :/ |
| 08:40:03 | brixen | yeah |
| 08:47:07 | brixen | evan: http://gist.github.com/103650 |
| 08:48:31 | evan | ha |
| 08:48:32 | evan | nice |
| 08:48:38 | brixen | yeah |
| 08:48:56 | brixen | I'm torn between working on this tomorrow and fixing bugs :P |
| 08:49:04 | evan | it's just so much easier to retrieve bugs |
| 08:49:08 | brixen | heh |
| 08:49:13 | evan | er. |
| 08:49:14 | evan | man |
| 08:49:16 | evan | it's late |
| 08:49:18 | evan | retrieve keys |
| 08:49:19 | brixen | yeah |
| 08:49:51 | brixen | well, I'm crashing |
| 08:49:56 | evan | nite |
| 08:50:02 | brixen | nite! |
| 09:50:14 | ngty | hi, i'm new to rubinus, when i run rake build on my ubuntu jaunty, i get error @ http://pastie.org/462229 |
| 09:50:39 | ngty | got it also in intrepid, not sure how to get around this issue |
| 11:03:18 | rue | Strange, a typedef issue, maybe |
| 14:01:06 | rue | Could be worked around by using a pointer, but still... |
| 14:15:38 | ieok | Invalid switch '-B' |
| 14:28:03 | rue | ieok: For `rake`? |
| 14:28:11 | ieok | yep |
| 14:33:09 | rue | Was the compile otherwise successful? I think you posted about an error earlier? |
| 14:34:35 | rue | It is running OK here off HEAD |
| 14:34:55 | ieok | the compilation is fine |
| 14:35:15 | ieok | it runs 726 tests. |
| 14:35:31 | ieok | error was raised after that |
| 14:36:36 | rue | OK |
| 14:36:45 | rue | The -B is to run library specs too |
| 14:36:55 | rue | ieok: Actually--which shell are you using? |
| 14:37:17 | ieok | bash under ubuntu 9.04 |
| 14:38:08 | rue | Hm. Double-check with `git pull && rake clean && rake` |
| 14:38:19 | rue | Could be something stale, although it seems unlikely |
| 14:38:22 | ieok | i do a clean git pull |
| 14:38:32 | ieok | git clone |
| 14:38:34 | ieok | sorry |
| 14:41:21 | ieok | same error for bin/mspec ci -B full |
| 14:42:51 | rue | What does `bin/mspec ci -h` say, see the option there? |
| 14:43:59 | ieok | -B is not included. |
| 14:56:04 | rue | Is it in mspec/lib/mspec/utils/options.rb ? |
| 14:56:17 | rue | If so, maybe you have a separate (very old) mspec installation somewhere? |
| 14:57:19 | ieok | let me check |
| 14:59:30 | ieok | def configure(&block) ;on("-B", "--config", "FILE", "Load FILE containing configuration options", &block);end |
| 14:59:37 | ieok | this one? |
| 15:02:14 | rue | That one, yes |
| 15:02:42 | rue | So maybe it is loading some other [utils/]options.rb ? |
| 15:05:15 | ieok | i don't have other mspec installed, this is weired |
| 15:14:25 | rue | See if you can verify which file it loads |
| 15:15:14 | ieok | okay |
| 15:16:07 | ieok | it loads that file |
| 15:16:24 | ieok | i write 'p 1' at the top |
| 15:17:13 | ieok | this maybe a platform issue |
| 15:17:19 | ieok | thanks rue! |
| 15:28:42 | rue | Weird. |
| 16:16:19 | rue | "Expected Resolv::ResolvError but got ThreadError (Not owner)" |
| 17:08:24 | tilman | rue: same here |
| 17:51:42 | dgtized | brixen: it hung again running specs, but it only seems to do it while just using rake to run them -- if I use bin/mspec directly it doesn't seem to happen |
| 17:51:57 | dgtized | making it particularly difficult to diagnose |
| 17:52:07 | brixen | it's not that difficult |
| 17:52:14 | brixen | ps ux | grep rbx |
| 17:52:22 | brixen | gdb vm/vm <pid> |
| 17:52:35 | brixen | fr # to where there is a call_frame |
| 17:52:45 | brixen | p call_frame->print_backtrace(state) |
| 17:52:50 | brixen | diagnosed |
| 17:52:58 | dgtized | k, next time it happens i will let you know |
| 17:53:56 | evan | good morning |
| 17:54:43 | brixen | morning |
| 17:58:43 | dgtized | morning |
| 17:59:19 | rue | Bad morning, bad! |
| 17:59:54 | dgtized | evan: we still fail around 5 specs in language for reasons related to scope -- throw, and return don't throw the right exception if they are escaping a Thread or a block outside of a method |
| 18:00:49 | dgtized | and our scoping for "for" is slightly off |
| 18:02:15 | evan | yep |
| 18:02:19 | evan | i looked at them all last night |
| 18:02:33 | evan | i'm going to ignore the error cases for throw and return |
| 18:02:46 | evan | for needs to be fixed though |
| 18:02:50 | evan | i was going to poke at that today |
| 18:02:53 | dgtized | k |
| 18:04:13 | dgtized | brixen: ok, it's bin/mspec is frozen again, but fr just gives me: #0 0xb7f41e05 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 |
| 18:04:33 | dgtized | and then p call_frame doesn't work because there isn't one in the current context |
| 18:04:45 | brixen | dgtized: bt |
| 18:04:47 | brixen | or bt 10 |
| 18:04:53 | brixen | fr # to where you see call_frame |
| 18:06:10 | dgtized | oh 0 is Rb_tree_increment, but 1 is VMManager::prune, and 2 is VM::colect_maybe |
| 18:07:13 | tilman | dgtized: valgrind reports invalid reads/writes at that spot for me in a long mspec run, too |
| 18:07:34 | evan | there is a thread race there |
| 18:07:41 | evan | i've been meaning to look into it |
| 18:07:43 | evan | i'll do that now. |
| 18:08:26 | brixen | sweet http://tinyurl.com/cjsq5y |
| 18:08:39 | brixen | and it's at powells, I'm going to go buy it today |
| 18:08:40 | dgtized | k, the weird thing is just that I can't seem to trigger this by running bin/mspec ci -B full, it only happens when I run rake directly |
| 18:09:01 | evan | brixen: :D |
| 18:09:40 | brixen | there's also debugging with gdb by rms himself |
| 18:09:45 | brixen | but that's from 2002 |
| 18:09:48 | brixen | ancient :P |
| 18:09:56 | evan | gdb hasn't changed since then |
| 18:10:03 | evan | just don't get the 1982 edition |
| 18:10:05 | evan | and you'll be fine. |
| 18:10:17 | brixen | heh |
| 18:10:56 | dgtized | that does sound pretty useful |
| 18:13:02 | dgtized | actually the gdb frontend in emacs is pretty good too, but I always forget about it |
| 18:15:33 | evan | DDD is pretty nice |
| 18:15:41 | evan | i use it once every 7 years |
| 18:15:49 | evan | because it's SO ugly |
| 18:16:47 | brixen | soon we'll have macruby to write all our pretty os x software and rubinius to make our servers fast :) |
| 18:19:15 | evan | heh |
| 18:23:07 | evan | incoming! |
| 18:23:10 | boyscout | Remove LookupTableAssociation, add GlobalCacheEntry - 025b132 - Evan Phoenix |
| 18:23:16 | evan | boom, roasted. |
| 18:23:20 | brixen | awesome |
| 18:23:42 | evan | I didn't expose it as a prim, but we could expose the creation of GCE's |
| 18:23:50 | evan | to be used for other things |
| 18:24:00 | brixen | running rails -h calls 87,990,094 method, running full CI calls 130,239,282 |
| 18:24:05 | evan | they're all invalidated when Rubinius.inc_global_serial is called |
| 18:24:05 | brixen | caraaazy |
| 18:24:11 | evan | dude |
| 18:24:14 | evan | we need to get a billion |
| 18:24:49 | brixen | how can rails -h need nearly as many calls as 32361 expectations? |
| 18:24:51 | brixen | how? |
| 18:25:07 | evan | hah |
| 18:25:10 | evan | it's crazy. |
| 18:36:08 | brixen | evan: rock, I'm seeing ~50sec now for full CI |
| 18:36:22 | evan | sweet |
| 18:36:33 | brixen | that's ~15% better in 2 days |
| 18:36:35 | brixen | yay |
| 18:36:37 | evan | i'm still getting 2 spec failures btw |
| 18:36:40 | evan | on socket |
| 18:36:41 | brixen | hm |
| 18:36:45 | evan | should I just tag them? |
| 18:36:53 | brixen | as unstable yes |
| 18:37:05 | brixen | I'm not seeing any failures on many runs |
| 18:37:06 | evan | they're |
| 18:37:07 | evan | Resolv#getaddress resolves localhost FAILED |
| 18:37:07 | evan | Expected Resolv::ResolvError but no exception was raised |
| 18:37:08 | evan | and |
| 18:37:15 | evan | Socket::IPSocket#getaddress raises an error on unknown hostnames FAILED |
| 18:37:15 | evan | Expected SocketError but no exception was raised |
| 18:37:19 | evan | I know exactly why |
| 18:37:22 | evan | those are crappy specs |
| 18:37:41 | evan | my nameserver here returns an address for any host |
| 18:37:50 | brixen | ah |
| 18:37:53 | evan | so the specs try things they think don't exist |
| 18:38:02 | evan | but my system returns IPs for them |
| 18:38:19 | brixen | gotcha |
| 18:38:28 | brixen | ideas on how to write them better? |
| 18:38:39 | evan | there is really not a way |
| 18:38:49 | evan | I tried changing them |
| 18:39:11 | brixen | we need a fake nameserver for the specs |
| 18:39:29 | brixen | I'll have to think about that |
| 18:39:32 | evan | well, it's using gethostbyname, the libc function |
| 18:39:42 | evan | which i don't think lets you specify a nameserver |
| 18:39:46 | brixen | hm |
| 18:39:54 | evan | anywho |
| 18:40:00 | evan | consider it |
| 18:40:12 | brixen | yeah, just tag them |
| 18:40:26 | evan | k. |
| 18:40:32 | tilman | is it considered sane style to use masgn to set locals? :o |
| 18:40:45 | brixen | tilman: why not? |
| 18:41:03 | tilman | brixen: just wondering.. i find that hard to read :o |
| 18:41:14 | brixen | a, b = b, a is the quintessential case for masgn |
| 18:41:23 | tilman | ofc |
| 18:41:42 | tilman | brixen: see enumerable.rb:622 for a less fun example |
| 18:41:57 | tilman | and 628 |
| 18:42:15 | brixen | looks fine to me |
| 18:42:21 | tilman | ok |
| 18:42:23 | brixen | my brain slurps that right up |
| 18:43:30 | brixen | granted, they could be on 2 lines, but that ranks a 0 on the scale of omgwtf code I've been looking at |
| 18:43:33 | brixen | :) |
| 18:44:55 | evan | thats like -1 on the scale |
| 18:45:21 | boyscout | CI: 349411c success. .................................................................................................... .................................................................................................... .................................................................................................... ............................................................................... |
| 18:45:35 | brixen | boyscout: you're back! |
| 18:45:39 | brixen | and wet all over |
| 18:45:52 | evan | he was hung |
| 18:45:57 | evan | not sure why |
| 18:46:00 | evan | killed it and restarted |
| 18:46:19 | brixen | evan: is the CI checking $! ? |
| 18:46:27 | brixen | CI report rather |
| 18:46:40 | brixen | wait $? |
| 18:46:43 | brixen | that one |
| 18:47:27 | evan | i'm not sure |
| 18:47:29 | evan | i'll have to check |
| 18:54:51 | brixen | evan: yes, excellent change, ~9,000,000 fewer calls and Thread.recursion_guard is no longer in the top 45 |
| 18:54:55 | brixen | http://gist.github.com/103924 |
| 18:55:29 | evan | is that the spec run? |
| 18:55:33 | brixen | yeah |
| 18:55:44 | evan | k |
| 18:58:02 | evan | i'm seperating SharedState from VM |
| 18:58:06 | dbussink | brixen: some large array that is sorted in the specs? |
| 18:58:09 | boyscout | CI: 025b132 success. 2647 files, 10133 examples, 32373 expectations, 1 failure, 3 errors |
| 18:58:10 | evan | and i'm going to redo VMManager I think |
| 18:59:08 | evan | success? I think not. |
| 18:59:11 | evan | weird |
| 19:00:23 | tilman | it refers to the build only, doesn't it? |
| 19:00:31 | tilman | not the spec run |
| 19:00:41 | evan | it should be both |
| 19:00:52 | evan | but maybe it's not, true. |
| 19:02:40 | brixen | hm, it ran clean for me on elle yesterday, except for socket specs that tried to open a socket own by you |
| 19:02:55 | evan | ok |
| 19:03:02 | evan | a couple are some bad unix socket specs |
| 19:03:09 | evan | that didn't clean up i'm guessing |
| 19:03:16 | brixen | are they EPERM errors |
| 19:03:27 | brixen | yeah, the socket specs need a serious review |
| 19:03:58 | brixen | evan: maybe you should run CI under a user I can su to |
| 19:08:19 | dgtized | brixen: did it run clean as bin/mspec ci -B full or, under the rake run? |
| 19:11:30 | brixen | it ran the same |
| 19:14:47 | dgtized | just got a "rbx: vm/vm.cpp:81: void rubinius::SharedState::remove_vm(rubinius::VM*): Assertion `i != vms_.end()' failed." from a bin/mspec ci -B full |
| 19:15:15 | evan | ok |
| 19:15:19 | evan | dgtized: i'm working on that now. |
| 19:20:37 | dgtized | k, sorry it was just the first time it actually reported a reason why it was failing, just thought I'd let folks know |
| 19:24:49 | brixen | heh, suggested caption above github issues "We gladly accept coffee, donuts, code patches. No bugs please, we have better things to do." |
| 19:25:20 | evan | hah |
| 19:46:03 | rue | Is the "success" for vm:test? |
| 19:46:53 | evan | no |
| 21:57:23 | evan | well, i'm sad to say that it took me almost 2 years before I had my first experience riding my bike in LA traffic |
| 21:57:27 | evan | it was kinda fun |
| 21:59:32 | brixen | kinda, like white knuckles on the grips, fun? |
| 21:59:53 | evan | kinda |
| 21:59:58 | evan | it wasn't on a super busy street |
| 22:00:03 | brixen | ahh |
| 22:00:19 | evan | but I could blow by rows of cars |
| 22:00:26 | evan | and fly through stop signs |
| 22:00:33 | evan | pretty sure I made it over faster than I do in a car |
| 22:00:53 | brixen | yes, well be careful in those intersections :P |
| 22:00:53 | evan | stop lights are clearly the great equalizer |
| 22:01:01 | evan | :) |
| 22:01:02 | brixen | yes, they are |
| 22:01:14 | evan | don't tell anyone at EY i'm engaging in reckless behavior |
| 22:01:17 | evan | :) |
| 22:01:22 | brixen | heh yeah |
| 22:01:25 | evan | ah crap, public channel. |
| 22:01:26 | evan | :D |
| 22:01:57 | brixen | sees a tweet come through "EY banned me from my bike today" |
| 22:01:57 | brixen | heh |
| 22:02:04 | evan | hah |
| 22:02:07 | evan | i hope not |
| 22:02:10 | evan | i need to ride it more |
| 22:02:19 | evan | first I need to get a decent pump though |
| 22:02:24 | evan | i've got street wheels on it |
| 22:02:28 | evan | and they need a really high PSI |
| 22:02:39 | evan | higher than my crappy hand pump can get in easily |
| 22:14:03 | rue | You should wear a mask if you bike in LA |
| 22:17:29 | evan | for long rides, yeah |
| 22:17:36 | evan | I was only going a mile |
| 22:19:07 | ezmob | hows rbx going these days guys? |
| 22:19:46 | brixen | ezmob: very well |
| 22:19:55 | brixen | ezmob: but keep a lid on that :P |
| 22:20:00 | ezmob | ;) |
| 22:20:30 | brixen | ezmob: I'm on the edge of my seat for the blow minds demo btw :) |
| 22:21:47 | brixen | evan: ok, I went with the crunchy, spicy, *and* grilled option |
| 22:21:53 | brixen | pushing in a sec |
| 22:22:03 | dbussink | bikes ftw! |
| 22:22:33 | brixen | basically, the filtering is done with a regexp, omitted if you pass -d, and customized in your own ~/.mspecrc file if you wish |
| 22:22:39 | dbussink | when i was in la i walked faster than the cars :) |
| 22:22:51 | evan | dbussink: :D |
| 22:23:10 | evan | brixen: it's a gordita crunch wrap! |
| 22:23:14 | brixen | heh |
| 22:23:30 | brixen | dbussink: those kids in pedal cars don't count ;) |
| 22:24:11 | dbussink | hehe, we were walking with a few guys and there was this convertable with some women we overtook at each trafic light, so we had excuse to wave each time :P |
| 22:24:24 | brixen | heh |
| 22:24:48 | brixen | you europeans always get attention :P |
| 22:26:05 | boyscout | Updated MSpec source to ef112bbe. - 63f7c37 - Brian Ford |
| 22:26:05 | boyscout | Filter mspec files from spec failure backtraces. - d6244df - Brian Ford |
| 22:28:29 | boyscout | CI: d6244df success. 2647 files, 10133 examples, 32373 expectations, 1 failure, 3 errors |
| 22:29:56 | brixen | at least boyscout seems to be deterministic |
| 22:30:52 | brixen | evan: see the full msg for d6244df |
| 22:31:28 | brixen | if you want, we can even take the filter setting out of default.mspec and only have it be a personal thing |
| 22:43:37 | evan | brixen: rad |