Index

Show enters and exits. Hide enters and exits.

08:02:46dbussinkevan: ping?
08:17:15halorgiumdbussink: got it "fixed" :P
15:42:32jerryontwitterrunning my cucumber tests on rubinius takes nearly twice as long as it did on 1.8.7-p249 - I am guessing this is a "me" problem. Are there configurations I can tune to pick up that pace?
15:45:10cremesjerryontwitter: i suggest opening a github issue and marking it as a performance problem
15:45:37cremesinclude the output from running it with these options: -Xint=1 and -Xprofile=1
15:45:55sbryantIs this from a recent checkout of rubinius/
15:46:23jerryontwitter1.0.1 - should I try it with HEAD?
15:47:01jerryontwitterbefore I submit an issue, I bet I should...
15:47:14sbryantYeah.
16:08:44brixenmorning
16:08:57brixenjerryontwitter: we know there are some perf issues with rspec
16:09:32brixenjerryontwitter: it would be excellent if you could take some core functionality in your app and benchmark that too
16:09:56jerryontwitterWill do that as well.
16:10:00brixenjerryontwitter: for profiles, just do -Xprofile, which runs rbx in interpreter mode only
16:10:19brixenjerryontwitter: sweet, thanks for looking at it
16:13:30jerryontwitterI am guessing I have some more reading to do - I am getting a "Error: signal SIGSEGV" when I try to install rails
16:13:42jerryontwitterusing rbx-head
16:15:33brixenhrm, that should not happen
16:15:43brixenwhat version?
16:16:19brixenjerryontwitter: when did you last pull/build?
16:16:38jerryontwitterrails 2.3.8 - I have a jumbled gem setup - I am guessing it is related to an MRI sqlite3 library being linked
16:16:55brixenthat would be a problem
16:16:58jerryontwitterperhaps through my passenger install?
16:17:01brixenare you using rvm with gemsets?
16:17:06jerryontwitteryep.
16:17:33brixenso, I believe wayneeseguin fixed this, but you cannot use MRI ext gems with rbx
16:17:36jerryontwitterrvm - but installing separate gems for each ruby
16:17:40brixenbut, rbx should reject those on load now
16:17:46evanyou're probably on an old version of rvm that had gemsets totally broken for native extensions
16:18:16brixenyeah, so 2 things, update rvm, and use rbx-head
16:18:35brixenproblem is, if you have rbx-head installed in rvm, I don't know how to tell rvm to do a clean build
16:18:38jerryontwitterwill do - updating rvm now
16:19:03brixenyou could cd to the .rvm rbx dir and run rake clean
16:19:25brixenbut wayne probably has a command for that too
16:35:00evanI wonder how hard it would be to put perl6 on top of Rubinius...
16:36:11brixenheh
16:36:22brixenI thought about trying that
16:36:50brixenbut I couldn't think of a good project name :P
16:37:01brixensuggested Toe but I got very disapproving looks
16:38:41brixenanyway, a lot of Perl should map quite easily, like this pack/unpack insanity
16:39:22evanToe seems good
16:39:27brixenhah
16:39:46evanor Humps
16:40:28brixensure
16:40:33brixenLumps
16:40:58brixenyou know, in honor of all the pain Perl has caused me in Ruby
16:41:44evanhah
16:42:11evanthe motto can be "Taking your lumps."
16:42:19brixenheh, nice
16:42:33jerryontwitterhmm, got rvm 0.1.41, tried "rvm install rbx-head --reconfigure" and still got the same result, then tried "rvm remove rbx-head" and now reinstalling
16:42:54brixenjerryontwitter: what platform are you on?
16:43:12jerryontwittermac os 10.6.3
16:45:37evanug. really 1.9? really? "It now passes more than 99% of RubySpecs"
16:45:42brixencrap, I have a segfault too
16:45:51evanbrixen: backtrace?
16:46:08brixenevan: yes, with the caveat that we don't really know what 99% of rubyspec means :/
16:46:11brixensec..
16:46:49brixenhttp://gist.github.com/472701
16:47:47evancan you try under gdb and see if you still get it?
16:48:18evanpretty sure it's capi handle related.
16:48:37brixenyeah, building debug
16:48:52evanno no
16:48:55evanany backtrace
16:48:56evandamn
16:48:59evanyou might not get it now.
16:49:08evannext time, try to get an optimized backtrace first.
16:49:15evanthen move to debug.
16:49:33brixenI can get an optimized one
16:50:32brixenwhy would the gdb bt be different than the one from the segv?
16:55:15brixenok, it's sporadic, for one
16:56:31brixenhttp://gist.github.com/472701
16:57:34evanyeah, i figured it was sporadic
16:57:47evanthats why trying to get it optimized is better at first
16:57:48brixenso, Data object...
16:57:50evanless change
16:57:57brixenthis is optimized
16:57:59evanyeah, it's Data/handle/finalizer related.
16:59:06evanwell, maybe/maybe not finalizer
16:59:08brixenobj is #<YAML::Syck::Parser:0x22663f8>
16:59:29brixenI figured syck would come to haunt us
17:00:36evandamnit!
17:00:42evan:( :( :(
17:00:48evanit's the samet hing I was working on before
17:00:52evanthat I thought I fixed.
17:00:59evanfinalizer wise.
17:01:12evanI have a hunch
17:02:24evanah ah ah
17:02:25evanyes
17:02:27evani know what it is.
17:02:33evanmy 3am fix wasn't enough
17:02:36evanSURPRISE!
17:03:09sbryantis surprised.
17:03:14sbryantShocked and elated.
17:03:27evangives sbryant an icecream cone to calm him down
17:03:51sbryanthah
17:04:48evananyone else need an icecream cone?
17:06:15jerryontwittermorbidly obese people always like icecream cones - I'll take 2.
17:06:43sbryantevan: Anyway I can get some froyo instead?
17:06:49sbryantIt's a texture thing.
17:09:29evansbryant: if it will calm you down, sure.
17:09:44evanabby and I almost had yogurtland twice this weekend.
17:15:02sbryantNice.
17:55:16evanbrixen: fix incoming.
17:55:21boyscoutInvalidate handles for finalized objects properly - 9fc6ae3 - Evan Phoenix
17:58:58brixenpulls
17:59:14evanthe issue was that I did free_data() on the Data handle
17:59:45evanbut the next time through, the code tried to check the handles and ended up using an empty RData
18:00:17evanI need to add a little more code to help prevent that usage
18:00:18evandoing that now.
18:02:27dbussinkevan: btw, why is that specialization code in kernel/delta/struct.rb? performance reasons?
18:02:34evanyes
18:02:44evanit's about 20x faster than using Struct#initialize directly.
18:03:46dbussinkah ok, was wondering, since removing it kept all specs passing :)
18:03:52dbussinkbut that explains then
18:04:35evanwell yeah.
18:04:41evanthat was the other fix
18:04:42brixenhmm
18:04:43boyscoutCI: rubinius: 9fc6ae3 successful: 3481 files, 14071 examples, 41804 expectations, 0 failures, 0 errors
18:04:46evanit's entirely performance related.
18:05:01brixenponders whether this is a build issue
18:05:06brixenevan: http://gist.github.com/472825
18:05:49evanoh cool.
18:05:53evantry a rake clean
18:05:58evansee if it is still there.
18:06:04evanthats why I added some extra code.
18:06:04evan:)
18:06:35dbussinki have it too :)
18:06:47evanwell now, that was easy.
18:06:47evan:)
18:12:16evanweird that i'm not getting it..
18:12:32brixenwell hooray for kernel panics
18:12:40brixenI wonder if I need to run disk defrag...
18:12:45evanah haha
18:12:48brixenheh
18:12:49evangot it!
18:12:55evanyou guys probably have ~/.gemrc files
18:12:56evandon't you
18:12:59brixenyes
18:13:01evanbingo.
18:13:02evan:D
18:13:04evani'm on it.
18:13:20dbussinkevan: https://gist.github.com/dab0ab84823a00e6b5e5
18:13:27evandbussink: i got it here :)
18:13:46dbussinkand yes, i have a gemrc
18:13:52evanfigures :)
18:17:44dbussinkactually collecting these objects does expose a bunch of issues :P
18:18:31evanyep!
18:18:33evanthats good though.
18:18:40evanwe're getting good exercise out of the GC now.
18:18:48evanI just forgot to do some homework :)
18:28:54dbussinkevan: easy issue or something nasty?
18:29:02evan*shrug*
18:29:03evanlooking now.
18:45:02dbussinkevan: what would be the best way to fix http://github.com/evanphx/rubinius/issues#issue/403
18:45:11dbussinkadd a method to test whether an object has a metaclass?
18:45:42evanwe have that
18:45:48evanobj.kind_of? ImmediateValue
18:46:06dbussinkwell, true, false and nil do give back a metaclass
18:46:11dbussinkwhich is the class itself
18:46:18evan:/
18:46:36dbussinkonly ones where it gives an error is for symbols and fixnums
18:46:58evani'm checking what MRI does
18:47:47dbussinkclass << true; end doesn't blow up
18:47:51dbussinkbut class < 1; end does
18:49:46evanok
18:49:53evanso, MRI uses rb_class_of
18:50:01evanwhich for the immediates
18:50:08evanreturn the normal class
18:50:13evan1 => Fixnum, :blah => Symbol
18:50:14evanetc.
18:50:20evanand for references, returns the metaclass
18:54:52dbussinkyeah, but there's still a difference between fixnum and symbol and true, false and nil :/
18:55:17evanwell, no.
18:55:28evanthere isn't as for as Kernel#methods is considered.
18:55:34dbussinkthat's true yeah
18:55:38dbussinkbut there is for metaclasses
18:55:44dbussinkwhich is what Kernel#methods uses now
18:55:54evanour method to get the metaclass raises a TypeError because other things expect that
18:56:16evanwe should go ahead and special case the code for Fixnum, Symbol for now.
18:56:41evanwe also need to do "grep CLASS_OF *.c" in MRI
18:56:52evanand check out all the places that this behavior exists
18:57:05evanie, where is class_of(1) => Fixnum allowed
18:58:41dbussinkevan: special case the code in Kernel#methods you mean?
18:58:47evanyes
19:05:28cremesmatz is the man... he's pushing for evan's gem patch to be added to 1.9.2
19:08:17brixenheh, yeah
19:09:58goyox86matz said: "Don't be bureaucratic" :]
19:12:53dbussinklet's hope this doesn't end up to be another disaster..
19:16:00evanyes, lets hope.
19:16:20evani'm being a good semaritan by helping
19:16:26evanif 1.9.2 is a total fuck up
19:16:34evanthe ruby brand will be dealt some serious damage.
19:20:28sbryantya?
19:23:48cremestime to fork!
19:32:52boyscoutQuick fix for Data/handle/finalizer assert failure - 8f3eba0 - Evan Phoenix
19:32:56brixencremes: no, bad cremes
19:33:55evanbrixen / dbussink: that should fix your assert
19:34:02evanI need to ponder a better fix.
19:34:08brixenk
19:34:14evanwhich i'll be doing at lunch.
19:36:10dbussinkevan: yay, it runs now again
19:37:18evancool.
19:41:15boyscoutCI: rubinius: 8f3eba0 successful: 3481 files, 14071 examples, 41804 expectations, 0 failures, 0 errors
19:43:34dbussinkevan: did you already look at that nice exit exception issue in 395? :P
19:57:03cremesheh heh heh...
20:08:57cremesi haven't heard anything lately about maglev; are they still working on that or did the acquisition kill that project?
20:09:47Defilerhttp://github.com/MagLev/maglev
20:10:08Defilerhttp://twitter.com/maglev
20:10:21Defilerhttp://groups.google.com/group/maglev-discussion
20:10:31cremesheh...
20:10:54DefilerLooks like it is still active, just no website updates since March
20:11:22cremesi'm gonna join their channel...
20:14:37cremesbrixen: how's pack/unpack progressing? no updates on rapa for a few days...
20:14:38brixencremes: yes...
20:14:42brixenoh
20:14:47brixenI'm working on specs
20:14:57cremesdamn those specs
20:14:58brixenthen I'll implement some more
20:15:17cremesare the specs too tied to the current implementation or something?
20:15:19brixenI'm checking an a 64bit le platform now
20:15:31brixenI wish I had a 64bit be platform to check on
20:15:46brixenthe specs are just pretty terrible
20:16:02cremesdoes EY have an old G5 sitting around somewhere? that can do 64-bit be
20:16:18brixendunno
20:16:28cremesor ask seydar to donate his old PPC box...
20:16:39cremesor was that a g4...? can't remember
20:17:08brixenI think that was like an iBook or something
20:17:29cremesanyway, i imagine the pack/unpack specs are pretty much just doing output checking, right?
20:17:46brixenum yeah
20:17:47cremesthat is, [1,2,3].pack('some chars').should == 'expected'
20:17:48brixen:)
20:17:54brixenpretty much
20:18:42cremesi promise to take a look at implementing the directives that mongodb uses for packing/unpacking BSON stuff
20:18:54cremesi'm eager to see how rbx performs after this gets some love
20:18:55brixenwhich ones does it use?
20:19:07brixenI'm giving priority to the ones Rails uses
20:19:24brixenQ H M m U C n
20:19:28cremesdon't know off hand but i will check
20:21:22cremesV, E, U, C, N, G, c
20:21:34cremessome overlap there
20:21:49brixenok
20:22:15cremesyou tackle rails and i'll try to tackle some of these others
20:22:26cremesmaybe i'll take a whack tonight...
20:38:39matschafferso what's the new hotness for 'Rubinius::VM::debugger' ?
20:39:31brixenmatschaffer: http://gist.github.com/450160
20:39:39brixenyou can set a br and c
20:39:45brixenbut no stepping or nexting yet
20:40:51matschafferbrixen: any docs on it anywhere?
20:41:24brixennot yet, sorry
20:44:26matschaffers'cool
20:44:31matschafferthat explains why I couldn't google it :)
20:45:53brixenit's on the short list for 1.1
20:50:53matschaffersweet!
20:51:13matschafferI'm sure you hear this all the time, but I love the stack traces
20:51:52evan:D
20:52:01evanwe love hearing it :)
20:52:49matschaffereven more than the coloring, centering them on the at was a great call
20:52:53matschaffersooooo much easier to scan
20:54:07evanyeah
20:54:20evanthat code really evolved quickly
20:54:24evanbecause we debug a lot of ruby.
20:54:39evanand I found that the at centering made a huge difference visually
21:01:09dbussinkevan: only downside is that it mangles it some if you have deeper gem paths
21:01:18dbussinkand want to select a path across multiple lines to open
21:01:24dbussinkbut that's me using it :p
21:01:41evanwell, i've played with different ideas to deal with that.
21:01:52evanwe could turn off the code that breaks up the path
21:02:05evanthen it wraps and discrupts, visually, the next line.
21:02:09evandisrupts, rather.
21:02:17evani'm not happy with the current solution
21:02:24evanso i'm open to suggestions
21:03:44dbussinkhaven't come up with a good solution either
21:03:51dbussinkit's a tricky thing
21:09:09evanyep.
21:36:07evani'm going to simplify the finalizers for now
21:36:15evanwhich should solve this problem better.
21:37:01slavahi evan
21:37:04slavawhat's changing with finalizers?
21:37:07evanhey slava!
21:37:14evani have question to ask you about write barriers
21:37:21slavashoot
21:37:25evanchanging when C finalizers are run
21:37:35evanto eliminate an edge case
21:37:46evanyou have tagged fixnums
21:37:53evanso when you store a tagged fixnum into an object
21:38:00evanto you mark the card of the object?
21:38:09evanie, are cards market for all writes
21:38:13slavayeah
21:38:17evanor only writes there whe value written is a reference?
21:38:26evans/market/marked/
21:38:32evanso all writes
21:38:33evan?
21:38:33slavaalthough I've never measured if the overhead of a conditional branch in writes is lower than the overhead of unnecessarily scanning cards where fixnums were stored into
21:38:37slavaso YMMV
21:38:42evanok, cool.
21:38:43evanjust curious
21:38:49evanhey did I see you're going to work for GOOOOGLE?
21:38:53slavaif I can statically determine that the thing being stored is a fixnum, I omit the write barrier
21:39:03slavaalso if I can statically determine that the object is freshly allocated
21:39:12slavaevan: maybe :)
21:39:43evanmaybe eh?
21:39:46evan:)
21:40:15brixenslava: do you have a 64bit be machine I could have an acct on?
21:40:16slavaI don't comment on twitter rumors :)
21:40:20slavabrixen: x86-64?
21:40:32brixenslava: big endian
21:40:48slavabrixen: I sold my g5, sorry
21:40:54brixenno worries
21:40:57slavayou could ask erg in #concatenative, he has one
21:40:57brixenjust asking around :)
21:41:01brixenah ok
21:41:08evanslava: cool, no comment necessary. I didn't know it was a rumor.
21:41:08slavahe'll give you an account for sure
21:41:19brixenok
21:41:19slavaevan: well, yeah, I'll be working there
21:41:59brixenslava: are you going to work on dalvik?
21:42:17slavabrixen: my guess is as good as yours
21:42:23brixenheh
21:42:34brixenwell, I know where I'd assign you
21:42:43slavanot web frontend stuff I hope :)
21:42:47brixenbut I'm sure google could give a X what I think :)
21:42:54brixenheh, no way man
21:43:57evanslava: when do you start? will you be in the bay area?
21:44:04slavaevan: august, yes
21:44:26evancool!
21:44:50slavaevan: are you changing your write barrier?
21:44:59evanpondering them
21:45:19evantrying to figure out what I can do without a contigious heap
21:45:33slavayou can have a card array that covers teh entire address space
21:45:34evanI might do an experiment with write buffers
21:45:43slavaonly scan the cards corresponding to allocated heap chunks
21:45:48slavathe other pages won't even be committed
21:45:59evanhm, thats a good point.
21:46:05slavalet's see
21:46:32slavaon 32-bit, if you have 256 byte cards, with one byte per card, that's a 16mb card array
21:46:49slavathat's not bad at all, especially since most of it won't be wired
21:47:00evanwith write buffers, i'd bump store the address of each written to object
21:47:03slavaon 64-bit, your address space is actually 48 bits big
21:47:19evanif it's full, put the buffer into a queue, get a new buffer
21:47:36slavaor better yet, if its full, call a routine which marks those cards
21:47:37evana background thread then emptys the buffer and keeps a remember set up to date
21:47:39slavaand empties the buffer
21:48:04evanthat would be one conditional
21:48:08evanto check if there is buffer space
21:48:08slavaanother option is hardware write barriers using memory protection, like sbcl
21:48:22evaneverything I read about them talks about how slow they are
21:48:33slavawhat if you use a guard page to detect when the write buffer is full?
21:48:48slavathen you have one protection fault for every N stores
21:49:03evanthats possible
21:49:09slavaso many possibilities, so little time, eh?
21:49:12evanbut i don't know which would be faster
21:49:18evandeal with the page fault as a signal etc, etc
21:49:22evanor the rare conditional
21:50:27evani'm guessing the conditional would be faster actually
21:50:35evanbecause the guard page would require me to put a guard page on the end of every buffer
21:50:40evanof which there would be N of
21:50:49evanbecause a buffer would be put into a queue and a new one grabbed
21:51:05evananyway, just brain storming.
21:52:10slavagetting a buffer from the queue still involves conditionals
21:52:25slavaalso, it will be a well-predicted branch since in most cases the buffer will not be full
21:53:25evanyes
21:53:29evanbut that code would be done rarely
21:53:35evansay, once every 1024 writes
21:53:52evanso that it's the slow case is fine
21:54:01evanyes, the well predicted case is what i want to optimize
21:54:12evanheck, it could be 32k
21:54:53evanon GC, i'd have to wait for the queues to be emptied
21:55:07evanso i'd need enough buffer space for writes between GCs
22:35:06boyscoutRun C finalizers right away, rather than queueing - 40b9978 - Evan Phoenix
22:45:32boyscoutCI: rubinius: 40b9978 successful: 3481 files, 14071 examples, 41804 expectations, 0 failures, 0 errors