Index

Show enters and exits. Hide enters and exits.

01:09:32boyscoutFixing rb_yield in capi and adding specs. - 7bd4f48 - Cezar Sa Espinola
01:17:25boyscoutCI: 7bd4f48 success. 2684 files, 10338 examples, 32883 expectations, 0 failures, 0 errors
01:34:20evancezarsa: you around?
01:34:36cezarsaevan: yep
01:34:43evanyour last fix has a nasty bug
01:34:44cezarsaevan: did i screw anything up?
01:34:52evancurrent_block_ is hidden from the GC
01:35:29evaneasiest fix is to make it a TypedRoot<Object*>
01:35:30cezarsabut it's just holding a reference, i don't instanciate anything
01:35:41evanthat doesn't matter
01:35:54evanbecause if the GC runs while there is an objcet referenced there
01:36:00evanthe GC won't see it, and thus can't update it
01:36:04evanif/when the object moves
01:36:25cezarsahm, ok
01:36:46cezarsaso just change from Object* to TypedRoot<Object*> is enough?
01:36:55evanyou have to initialize the TypedRoot
01:37:09evanand you'll need to use .set and .get on it
01:37:15evanto retrieve the true Object*
01:37:42evanTypedRoot can be initialized by passing state to it
01:38:03evanwhich you'd do in the NativeMethodEnvironment constructor
01:39:18cezarsak, i'll do it right now
01:39:22evank
01:39:39evanyou really have to be careful when with declaring Object*s
01:40:06cezarsathx for pointing out, i'm just starting to dig into the new VM, i'll be more careful
01:40:11evanrule of thumb: either they're a // slot or a TypedRoot
01:40:23evanand if you're unsure
01:40:27evanmake it a TypedRoot
01:40:31evanit's better to have too many roots
01:40:37evanand fix that later
01:40:50evanthan crash because the GC missed an object
01:41:50evanthe next level is using OnStack<>
01:43:02cezarsaOnStack objects won't be visited by the GC?
01:43:59evanthey are
01:44:00evanthats the point
01:44:27evanit's a way of advising the GC there are Object*s elsewhere
01:44:40evanit's a little more efficient than TypedRoot for a bunch of objects
01:44:48evanand is designed to be used like
01:44:56evanOnStack<1> os(state, obj);
01:45:00evanblah blah, use obj;
01:45:05evanreturn whatever;
01:45:13evanOnStack's destructor unregisters it
02:05:42cezarsaevan: just to be sure, is this the right way: http://pastie.org/480445
02:06:30evanyep
02:06:32evanthats exactly it.
02:06:37slavayo
02:07:06cezarsathx
02:07:09evanyo
02:07:22evanslava: i'm looking at the Handle code in v8
02:08:35slavais it any good?
02:08:41evanit's interesting
02:09:00slavais it better than what you and I do for gc roots?
02:09:03evani'm thinknig of perhaps using something a little similar rather than OnStack<>
02:09:09evanit's pretty much the same
02:09:12slavacan you explain the genera idea?
02:09:15evansure
02:09:27evanthey've got a single tracking structure
02:09:34evanthat the GC is aware of
02:09:46evanit handles out pointers to internal slots
02:10:04evanand the slot is a pointer to the real GC'd object
02:10:15evanso to get the real object, they then just do
02:10:18evan*location_;
02:10:45evanthe reason they do that is that makes their Handle class simple and trivially copable
02:10:50evancopyable
02:11:04evansince you can then have multiple Handle's that reference the same location_
02:11:16evanand they then can pass around Handle's as values
02:11:25slavaso the handle has a ctor/dtor that registers it with a global list?
02:11:26evancombine that with a implicit constructor
02:11:53evanand a proper copy constructor
02:12:03boyscoutFixing bug in NativeMethodEnvironment, making the GC happy. (Thanks Evan) - b68ab89 - Cezar Sa Espinola
02:12:05evanyeah, so what they do to unregister handles is that they're scoped
02:12:27slavasure
02:12:28evanso, at some highlevel, before entering a bunch of code that needs handles, they'll do
02:12:32evanHandleScope::Enter
02:12:36slavahmm
02:12:40evanrun the code
02:12:40evanthen
02:12:47evanHandeScope::Leave
02:12:50evanbasicly
02:12:56slavahow do the actual handles get used?
02:13:08evanas normal objects
02:13:09slavaI guess I'll look at the code at some point
02:13:12evanvia operator overloading
02:13:23evanso like
02:13:33evanHandle<Object> obj = blah();
02:13:37evanwhere blah returns Object*
02:13:58evanwell, they actually wrap it with a macro to create the handle
02:14:01evanbut it's the same diff
02:14:07evanthen they do
02:14:10evanobj->whatever();
02:14:26evanHandle<>::operator->() does the deref from the stored location
02:15:01evanone nice thing about using the implicit constructor is that you can add usage incrementally
02:15:59slavasounds good
02:16:06boyscoutCI: Build b68ab89 failed. http://ci.rubini.us/rubinius/builds/b68ab89ca48f2e9398f9bc0ee3515459da351188
02:16:09evan:/
02:16:30evancezarsa: did you run that code?
02:16:43evanyou didn't run the tests
02:16:44cezarsai did, and specs also
02:17:01evanyou didn't run the VM tests
02:17:18cezarsaouch
02:17:26evanare you running jsut "rake"
02:17:30evanthat runs the VM tests by default
02:18:04evanslava: so it comes down to 2 questions:
02:18:08cezarsai just did rake build and then bin/mspec ci
02:18:10evan1) where to put scope enter/leave
02:18:17evan2) whats the cost of creating a new scope
02:18:21evancezarsa: thats why
02:18:25evanuse
02:18:26evanrake
02:18:26cezarsasorry, will fix the vm tests now
02:18:33evanthat runs the vm tests
02:23:39brixenevan: I've *finally* got some data processing stuff in place
02:23:42brixencheck this out http://gist.github.com/112880
02:23:51brixenthat's just starting up irb precompiled
02:24:01brixen1500 hash instances created
02:24:15brixenthe distribution running specs is super flat
02:24:25brixenwhich is why I added the quartiles for Q3
02:24:36brixenwaiting for spec run to finish right now
02:25:34brixenI added the max object inspect too because the max # for eg :[] was so large compared to even Q3's Q3
02:25:39evani'm not smart enough to follow what Q1, Q2, and Q3 mean
02:25:49brixenread that comment at the top
02:25:52evani did
02:25:53evan:/
02:26:01boyscoutFixing NativeMethod VM tests. - 59f25b0 - Cezar Sa Espinola
02:26:14brixenbasically the value under Q1 means that 25% of the values are <= that value
02:26:23brixenunder Q2 it's 50% of the values
02:26:31brixenQ3 is 75%
02:26:40brixenso...
02:26:54brixen75% of hashs had <= 6 calls to :[]
02:26:59evanthat value == ?
02:27:17brixenthe number listed in the Qx column
02:27:27brixenit's a little confusing at first
02:27:33brixenI've been staring at it for 2 days
02:27:35brixenheh
02:27:43evani still don't get it
02:28:01evan25% of Hash's had a size of 2.0?
02:28:06brixenyes
02:28:09evaner 2
02:28:15brixenless than or equal to 2
02:28:25brixen75% <= 5 elts
02:28:49evanok, so for [], 75% of Hash,s used 6 as a key?
02:28:53evani don't get what the numbers actually mean
02:28:58brixenthe # of calls
02:29:01boyscoutCI: 59f25b0 success. 2684 files, 10338 examples, 32883 expectations, 0 failures, 0 errors
02:29:06evanwait
02:29:11evanso are they all the number of calls?
02:29:17brixenexcept for size
02:29:24evani need units
02:29:25brixenthat's probably confusing
02:29:30evanyeah, ya think? :D
02:29:36brixenI'll add units to size
02:29:40brixenthe rest are calls
02:29:43evanadd units to them all
02:29:56brixenum, they're calls
02:30:05brixenthat's the main data point
02:30:19evanok
02:30:21evanso say that somewhere
02:30:32evanthe word call appears nowhere
02:30:50evanexcept in "Emperically"
02:30:58brixenyeah
02:31:00brixengot it
02:31:07evani'm slow on the math.
02:31:15evani'm an arty CS guy
02:31:50evanprobably better would be to describe myself as a CS cartographer
02:32:02brixenwell, the point of the data is to have usage characteristics to link to benchmarks
02:32:10slavaa web 2.0 CS personality
02:32:20brixenif no hash is called 50 million times, a benchmark for that is of dubious value
02:32:37brixenif no hash is ever bigger than 1k elements, hash perf for 1M is irrelevant
02:32:43brixenexcept as an academic exercise
02:32:53brixenin whose number is bigger ;)
02:33:13evanoh totally
02:33:18evanyou did all this work
02:33:21evan i want to enjoy it!
02:33:35evanwhich means i gotta be in the right head space
02:34:29brixenyeah
02:34:52brixenthe spec run overfilled my term buffer so I have to rerun it
02:35:01evanhah
02:35:04evansilly iterm
02:35:09evanthat never happens to Terminal.app
02:35:28brixenbut check this out http://gist.github.com/112883
02:35:43brixenmost calls to :[]
02:35:51evanwoo class variables in rbyaml! :/
02:36:09brixenmost calls to :each and :keys was on an empty hash
02:36:19evanweird.
02:37:02evani guess that means a quick empty check at the top would pay off
02:37:43evanesp. since we construct a block, pass it to each_item, which makes an iterator
02:37:50evanonly to find that entry is nil the first time
02:38:33brixenyeah
02:39:01brixenI'm going to run this with rdoc on kernel/ and lib/
02:39:14evannice
02:39:15evanyeah
02:39:40brixenand make the max object inspect optional
02:40:30evangood plan
02:40:51brixenI'm trying to find that max :[] hash
02:41:13brixenyup, figured
02:41:20brixenkernel/common/regexp.rb
02:41:29brixenescape table
02:41:52brixenthat thing is accessed like 130,000 times
02:42:45evanthis is really interesting
02:42:47evaneven as a profiler
02:42:56evanah
02:42:57evanyeah
02:42:58evanthat thing.
02:42:59evanyou know
02:43:02evanthat should be an Array
02:43:06evansince the keys are numbers.
02:43:16evanand there is only table.
02:43:26evanoh hell, a Tuple
02:44:05brixena sparse 125 entry tuple
02:44:51evansparsely populated, yeah.
02:45:03evandon't forget, coming soon to a method near you
02:45:08evanTuple#at is almost free
02:45:24brixenheh, yes
02:45:29brixenI'm excited
02:45:52brixenfib move over, Tuple#at is the new sheriff in town
02:46:54evanfor comedic effect, lets say Tuple#at is the black sheriff from blazing saddles
02:47:25brixenheh
02:47:39brixenso, did you see this part: 99513 Hash instances (274 with mixed keys)
02:47:54brixennot sure what else we could tease out of the mixed keys
02:48:10evanno no
02:48:11evanthats fine
02:48:17evanthe ratio is the best part
02:48:37brixenyeah, so not very common in this case
02:49:02evan99.7% are homogenous
02:49:27evanso opts based on Hash's being homogenous would have a big pay off
02:49:35evanbrixen: ok, how about this for data
02:49:41evanfor the homo key hashs
02:49:54evanhow many of those are Symbol, how many are String, how many are Fixnum
02:50:49brixenso, for the mixed keys or total?
02:50:58brixenie, how would it be different than http://gist.github.com/112880
02:51:04brixenKey classes
02:51:27evanah ah
02:51:28evanit's not
02:51:31brixenok
02:51:33evani just can't read!
02:51:45brixenI'm going to change Qx to the actual percentage
02:51:48brixen25% etc
02:51:51evank
02:53:17brixenthis is a previous run with incorrect median, so ignore that http://gist.github.com/112386
02:53:22brixenbut you can see the key counts
02:53:55brixenseems weird to have 1700 Array instance keys
02:54:03evanyeah
02:54:10evan*shrug*
02:54:14brixenbut symbol and string are the vast majority
02:54:18evanright
02:54:19brixensymbol the top
02:54:31evanso making Hash fast for symbol is high on the list
02:54:38brixenyeah
02:54:41evaneven if it slows down the other key types
02:55:32brixenand since :[] is used the vast majority of these calls, that means making this test fast: key.equal?(@key) or (@key_hash == key_hash and key.eql? @key)
02:56:02brixenfor symbol, it should shortcut with key.equal?
02:56:25evanabsolutely it should
02:56:35brixencan we jit #equal? yet? :)
02:56:42evani can add that RIGHT NOW.
02:56:45evanif you'd like
02:56:45brixenheh
02:56:45evan:D
02:56:55brixenandale pronto
02:57:04evanariba!
02:57:11brixen:D
02:57:57evani'm reading the vmkit code atm.
02:58:12evani love that i've actually got other places to look at to find out how people use LLVM
02:58:19brixennice
03:00:25brixenvmkit could probably be a good resource for enhancing rbx to be an alternative jvm :)
03:00:32evanheheh
03:00:33brixenI'll have to look at this
03:00:49evani guess vmkit runs eclipse now
03:00:57brixenwow, sweet
03:01:19brixenplots his 2010 oscon talk :D
03:01:59evanwe could run eclipse on a rbx based jvm and call it "obscure"
03:02:08brixenheh
03:02:44brixenarmageddon
03:02:46evanheh
03:02:58brixenwhat primitive people think when an eclipse happens
03:03:06evaninterestingly
03:03:16evanvmkit passes arguments to methods as a struct
03:03:40brixenany idea why?
03:03:47evanwell
03:04:03evani'm pretty sure it's because then what they do is alloca that same struct type on the caller stack
03:04:11evanand pass that pointer down to the callee
03:04:30evanwhen all that is reduced to machine code
03:04:37evanit looks almost exactly like the normal C convention
03:04:42evanbut they've got full control over it
03:04:50brixeninteresting
03:04:50evanwhich gives them a bit more flexibility
03:04:59evani'm basically doing the same
03:05:37evanall arguments are passed out of the a JIT'd method by passing the address in the callers operand stack of the receiver and the number of args
03:05:44evanso the signature is always
03:05:55evan(STATE, CallFrame* prev, int argc, Object** args)
03:05:59evanoutgoing
03:06:06evanincoming it's
03:06:14evan(STATE, CallFrame* prev, Arguments& args)
03:06:17evanbecause of splat
03:06:23brixenahh
03:06:39evani could construct an Arguments object on the callee stack
03:06:48evanperhaps i'll do that eventually
03:06:58evanthe Arguments object on the stack is almost nothing
03:07:03evanso its probably a wash
04:01:33brixenman, my poor CPU
04:01:35brixenhttp://gist.github.com/112901
04:01:45brixentook like 25 min to do the compiling run
04:03:43evanwow.
04:04:34evanack, dinner.
04:05:51evanbrixen: awesome data.
04:06:01brixencool
04:06:17brixenI'm gonna generalize this a bit to run on String and Array
04:06:25brixenruby is such a sweet language
05:23:13evanMUHAHA
05:23:32evanhttp://gist.github.com/112919
05:23:35evannote line 13
05:23:46evanoh ack, it's one off.
05:25:23evanthere we go!
05:25:24evan:D
05:26:02brixensweet
05:26:23brixenthat is so nice
05:26:56evanreload
05:27:05evanthe bottom one is when rec is JIT compiled
05:27:21evan6x more stack space available :D
05:28:26brixenhah, sweet
06:35:15boyscoutCollapse recursive calls into one line with the recursion count - 0e084aa - Evan Phoenix
06:35:15boyscoutDo the stack depth check for the JIT - b8945bf - Evan Phoenix
06:40:54boyscoutCI: b8945bf success. 2684 files, 10338 examples, 32883 expectations, 0 failures, 0 errors
07:55:10ddubweee
07:55:15ddubflight of the conchords was fun
10:08:04boyscoutShort round of refactoring - 248fa7e - Evan Phoenix
10:08:04boyscoutBegin refactoring Signatures to be created once - cf370fd - Evan Phoenix
10:08:04boyscoutBit more refactoring - e33c35d - Evan Phoenix
10:15:22boyscoutCI: e33c35d success. 2684 files, 10338 examples, 32883 expectations, 0 failures, 0 errors
15:13:54rueheadius: Um, it seems that those benchmarks are just all-around bad if optimisations can effectively nullify them (and assuming that it is not a valid result for the benchmark)
16:20:56scooprso, who here likes and knows about parsers? ;)
16:28:31malumaluscoopr: i would like to know :P
16:30:02scooprI have dangling-else problem ..
16:30:08scooprand I'm not sure how to go around it with lemon
16:51:45headiusrue: probably
16:51:47headiusbut benchmarking is hard on any optimizing runtime
19:30:20rueWell, I just do not understand how it can be that optimising away code that you try to benchmark is somehow invalid, but simultaneously the benchmark is valid if no optimisation -- or /some limited degree/ -- occurs
19:32:21rueEither you should just delete the benchmark, or accept that optimising it away is a valid result
23:21:18boyscout1.8.7: Kernel#__method__, __callee__ (created new methods) - 68c566a - Marc-Andre Lafortune
23:21:18boyscoutHash== won't call to_hash anymore (as per rubyspecs) - ad3727f - Marc-Andre Lafortune
23:21:18boyscoutArray == and Hash == now handle recursion correctly - 067e28f - Marc-Andre Lafortune
23:21:18boyscoutMissing bang in private method names qsort!, qsort_block!, etc... - 01dea76 - Marc-Andre Lafortune
23:21:18boyscoutNuked unused private method Array#remove_outer_arrays - b52e481 - Marc-Andre Lafortune
23:25:00boyscoutCI: b52e481 success. 2683 files, 10323 examples, 32868 expectations, 0 failures, 0 errors