Index

Show enters and exits. Hide enters and exits.

00:29:25devinushttp://bench.rubini.us/ -- wait so rubinius is only 10% as fast as MRI?
00:29:39devinus10-15%?
06:34:42boyscoutSet the proper type for a MethodTableBucket - 5c6ba6e - Evan Phoenix
06:34:42boyscoutReenable accessor inlining - eb153b9 - Evan Phoenix
06:34:42boyscoutRemove unused Kernel#breakpoint - 2ccf2ce - Evan Phoenix
06:42:24boyscoutCI: 2ccf2ce success. 2733 files, 10853 examples, 33893 expectations, 0 failures, 0 errors
10:00:51boyscoutHash performance improvements. - eb3e7f5 - Brian Ford
10:00:51boyscoutUpdate Hash specs. - 6e7b26d - Brian Ford
10:00:51boyscoutUpdated 1.8.7 Hash methods. - 636e37b - Brian Ford
10:03:05boyscoutCI: 636e37b success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
17:24:25evanwoop. reader and writer accessor inlining
17:35:39boyscoutInline accessor writers as well - fd67de0 - Evan Phoenix
17:38:40boyscoutCI: fd67de0 success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
17:38:46evandanku boyscout
17:59:58cremesanyone having success running this stuff on snow leopard?
18:00:17cremesmy build hasn't worked for at least a week; it doesn't even finish compiling: http://pastie.org/526481
18:06:25evannot that I know of
18:06:30dbussinkcremes: it's a known issue with apple's gcc 4.2.1
18:06:56cremesdbussink: i see... any known workarounds or wait for an updated seed?
18:07:12dbussinkcremes: but it fails differently for me on my snow leopard test machine
18:07:20dbussinkcremes: and there are no known workarounds afaik
18:07:43dbussinkbut it's on an old macbook which isn't 64 bit
18:07:45evancremes: you need to force release libudis
18:07:55evaner.
18:07:57evanforce rebuild
18:07:58dbussinkthat probably explains the difference in issues
18:08:09cremeshow do i force it? is there a rake task?
18:08:15evanum.
18:08:16dbussinkcremes: if you get passed by this, it will fail later on ;)
18:08:17evanshould be..
18:08:43evancremes: otherwise, just rm libudis86.a in assembler
18:08:47dbussinkevan: did you even look into the gcc 4.2.1 issue?
18:08:49dbussinkever
18:08:57evanand go into assembler/udis86-1.7 and make clean
18:09:07evandbussink: no, i need to
18:09:12evanrue was, but he's not really in here anymore i guess.
18:09:19evani don't think he had time anyway
18:09:33evanthe error is seeing a nil or something, yels?
18:09:43cremesrebuilding now...
18:10:05dbussinkevan: you, it goes wrong when compiling readline
18:10:19cremesdbussink: snow leopard also has gcc 4.0; have you tried compiling with it instead of 4.2.1?
18:10:21evancould ya pastie the error again?
18:10:26evani've got a little time
18:10:31evani'll see if I can't slay it.
18:11:40dbussinkhttp://gist.github.com/137049
18:12:45dbussinkevan: probably some bug in the compiler, there's no issue if i use gcc 4.2.4 from macports
18:12:54dbussinkor the 4.3 or 4.4 series
18:12:54evanreally?
18:12:56evanha
18:13:01evanwell, i guess thats "good"
18:13:31dbussinkevan: i thought it was also reproducable by using 4.2 on regular leopard
18:13:42evanit might be
18:13:49evanbut i need to get validation of the error from you
18:13:55evanso i can know if i'm reproing the same thing here :D
18:14:02dbussinkhehe, that's true yeah
18:15:23evanyears of debugging has taught me to ask stupid questions up front
18:15:26evanso i don't chase my tail for days
18:16:18dbussinkyeah, i agree, that's definitely true
18:17:15evanyay! i got methods that just return a number inlining
18:17:19evanhow silly!
18:17:22cremesdbussink: yeah, i fail on readline too though mine segfaults instead of giving any kind of backtrace
18:20:26dbussinkevan: all great things start small :)
18:20:33evanheh
18:22:47dbussinkevan: ok, compiling with 4.0 on snow leopard works
18:22:52evanyay
18:23:15dbussinkevan: and compiling on regular leopard gives the same error with the available 4.2 as on snow leopard
18:23:21evanok, i'm adding inlining for methods that return symbols
18:23:23evanthen i'll check this out.
18:23:28dbussinknp :)
18:23:40dbussinkevan: does it also inline when you have returns / blocks etc.?
18:23:57evanatm, i'm doing form detection
18:24:02evanit's not inlining any method yet
18:24:04evansoon though :)
18:24:13evani mean, it's not inlining just any method
18:24:25evani added support for it to inline accessors (attr_reader, attr_writer)
18:24:36evannow i'm adding support for detecting trivial methods and inlining them
18:24:43dbussinkah, cool
18:24:47evannext is small but non-trivial methods
18:24:48dbussinkfor what definition of trivial?
18:24:55evansmall == no blocks, no exception handlers
18:25:09evantrivial is pretty much on expression on one line
18:25:11evandef foo; 1; end
18:25:15evandef foo; :blah; end
18:25:16evanetc.
18:25:28evans/on expr/an expr/
18:26:16evanhehe
18:26:16evanword
18:26:19evansymbols work now.
18:26:20evan:D
18:28:27dbussinkw00t :)
18:29:05evanok, now on to 4.2.1
18:29:12boyscoutInline methods that just return a number - e697744 - Evan Phoenix
18:29:12boyscoutAdd inlining of methods just returning symbols - c9abaaa - Evan Phoenix
18:29:39cremesdbussink: how did you recompile with gcc-4.0? i tried "GCC=gcc-4.0 rake build" but it didn't pick up the change
18:29:46evancremes: CC=
18:29:48evannot GCC
18:29:51cremesoops
18:31:24boyscoutCI: c9abaaa success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
18:32:15dbussinkevan: does the ruby core have a lot of trivial methods?
18:32:38evanno, not alot.
18:32:56evanthese are the low hanging fruit of inlining though
18:32:59evanthe accessors make a difference
18:33:01evanso they're heavily used.
18:33:07evans/so/since/
18:33:35evanand we're at the stage where every little bit helps
18:36:50evanoh, i've got the blow up here.
18:37:18evanlets poke.
18:39:07evanhm hm, ok.
18:39:33evanthat masgn, for some reason, is get confused.
18:40:56evanyep!
18:40:56evanok
18:41:03evanrather than [], [], nil, nil, []
18:41:07evanthat rhs is coming out as
18:41:12evan[], nil, nil, [], []
18:43:57evanheh
18:44:04evan a, b, c, d, e = :a, :b, :c, :d, :e
18:44:04evan p [a, b, c, d, e]
18:44:12evanwhat do I get under gcc 4.2 though?
18:44:16evan[:b, :d, :c, :a, :e]
18:44:22evanhah
18:44:26evanit's completely jumbled
18:44:46evanso weird.
18:45:16evani'm on it though.
18:48:47cremeshmmm, i see that there is now a snow leopard seed update available through software update; maybe that includes a fixed compiler :)
18:49:07evani've isolated it to the rotate bytecode
18:49:11evani'm working on it now.
18:51:17evanshould be easy
18:51:25evannow that i've got a minimal test case
18:52:00cremesevan, as usual you rock!
18:52:13dbussinkcremes: it doesn't :(
18:52:20dbussinkcremes: already installed it and no help
18:52:53cremestoo bad; i should open a radar ticket on this; a rubinius compilation failure should be a showstopper bug for snow leopard!!
18:53:27evanwell
18:53:29dbussinkhold the presses, no release before it compiles!
18:53:30dbussink:P
18:53:43evanit's possible the code in rotate is using an undefined behavior
18:53:46evani'm simplifying it
18:53:57evanto see if i can't figure out where the undefined behavior is
18:54:10cremesevan: what file are you working on (and line no); I want to follow along if i may
18:54:33evansure
18:54:37evanit's easy
18:54:38evanhere
18:54:53evanhttp://gist.github.com/137060
18:54:57evanrun
18:55:12evanruby lib/compiler/mri_compile.rb scratch/masgn.rb scratch/masgn.rbc
18:55:13evanthen
18:55:19evanbin/rbx scratch/masgn.rb
18:55:32evanyou should see that the locals don't have the correct values
18:55:41cremescool; will do
18:57:48cremesof course, i can't do that last part because i don't have bin/rbx successfully compiled on this box
18:58:26evanit should be compiling
18:59:54dbussinkcremes: just curious, is it creating a 32 or 64 bit binary for you?
19:00:16cremesdbussink: i'm recompiling now; when done i'll check
19:00:34cremesi'm pretty sure it is outputting mach-o x86_64 but I
19:00:36cremesll confirm
19:02:33cremesdbussink: 64-bit
19:04:01cremesi get a segfault when running "bin/rbx scratch/masgn.rb"
19:04:44dbussinkcremes: hmm, that might be a 64 bit related issue
19:05:04cremesyeah? is there any easy way to force 32-bit compilation?
19:05:27dbussinkexport RC_ARCHS="i386"
19:05:31dbussinkthat might help
19:05:36dbussinkdunno for sure though
19:05:42dbussinkevan: i see the weird order too yeah
19:06:08evanok
19:06:09evangood.
19:17:50dbussinkevan: already able to determine whether it's a compiler bug or not?
19:19:28evanworking on that now
19:19:32evani'm moving the logic into a .c file
19:19:41evanand trying to observe it in isolation
19:26:09dbussinkcremes: did that work btw?
19:26:17mernencremes: rbx segfaults on my (ubuntu) 64-bit builds too
19:26:20cremesnope
19:26:29dbussinkmernen: ah, probably the same issue then
19:27:19cremesmaybe i'll try running it under the debugger to see where it dies
19:27:49mernenI've got two or three different problem points
19:28:01mernenbut it's always related to stack_push
19:28:38mernentried to figure it out yesterday, but so far that seems to be beyond my abilities
19:29:38evanmernen: if you've got some backtraces
19:29:42evanfeel free to put them into a github issue
19:29:45evanas points of data
19:29:47mernenit's been like that since 9bdf2fa, btw
19:30:04mernenthe VMMethod::interpreter refactor
19:30:19mernenevan: I have a few core dumps here
19:31:20dbussinkmernen: you git bisected it?
19:31:25mernenyep
19:32:02mernenbisected until `rbx -rFAIL -e ''` didn't crash
19:33:10mernenI mean, didn't segfault
19:34:19evanhm. ok.
19:38:56evanha!
19:39:03evani think i got a version that gcc likes!
19:39:10evanbingo!
19:41:58dbussinkevan: can you show me the c repro?
19:42:23dbussinkevan: or do you already have a workaround?
19:43:11evani never got a C repro
19:43:38evani think because the interpreter has different alias semantics that a trivial C program
19:43:43evanso it's hard to get the bug to appear
19:43:54evani'm retesting the new rotate code
19:44:21dbussinkevan: but is it an obvious gcc bug or is there undefined behavior involved too?
19:45:32evani can't see an undefined behavior in the current one
19:45:47evanit's just moving data in-place in an array
19:46:08evanbut i've redo it using pointer access and pointer math
19:46:14evanwhich seems to solve it
19:48:09evanrunning the specs now (which run!)
19:53:10evaninteresting!
19:53:27evangcc 4.2 results in in what appears to be a bit faster code
19:53:31evan43.8s for a spec run
19:53:38evani'm going to clean and recompile under gcc-4.0
19:54:03dbussinkevan: it's inside the rotate instruction?
19:56:35evanthe bug is, yes.
19:56:39evanit's fixed
19:56:46evani'm testing on gcc 4.0 now
20:01:25evanweird!
20:01:32evanthis change makes the interpreter faster
20:01:43evanmaybe the old code was confounding gcc's optimizer
20:01:53dbussinkyeah, just wanted to say that too :P
20:02:37brixenevan: btw, with the new hash code, I'm getting just a hair over 40sec full spec runs
20:03:02evanhey! why are you online!
20:03:03evan:D
20:03:06brixenI'm playing with an optimizer pass in the bytecode compiler
20:03:07brixen:)
20:03:29brixenI'm just sitting here in a coffee shop and *felt* all the activity here :D
20:03:37brixencute place http://thumpcoffee.com/
20:03:43evanhah
20:04:13brixenbut seriously, I'll have sub 40sec full CI runs shortly I think
20:04:18evanyay!
20:04:42evanand to think, i was all excited about the first sub 50s time not long ago
20:04:48evanand now I just saw 43s!
20:04:54brixenhttp://gist.github.com/137080
20:05:02brixenI'm lazily poking at Array#|
20:05:11brixenit's the biggest user of Hash in the spec runs
20:05:16evanyeah, so
20:05:25evani'm going to have to come up with a solution for Class#new
20:05:34evani had to take the check_serial code out when I changed the ICs
20:05:45evani think i'm going to have new to ba a meta opcode like _call
20:05:47brixenbtw, this is the only place in Bend that serves stumptown coffee
20:05:56evanthat can check if new is Class#new
20:06:05brixenthat would be cool
20:06:05evanand do the allocation and call initialize
20:06:18evanwithout boxing the arguments
20:06:27evanthe only thing about that, it's got crappy IC semantics
20:06:41evanat the call site, i really want to get an IC for allocate and initilaize
20:06:45evanseperately
20:06:50evanso I need to think about this
20:07:12brixenhmm
20:08:38boyscoutRework the rotate instruction (gcc 4.2 fix) - cc26edb - Evan Phoenix
20:08:41evanok, gcc 4.2 people
20:08:43evangive that a shot.
20:11:24evanso, something i was thinking about
20:11:30evanfor Kernel methods
20:11:41cremeswell, it *might* be better but i still get segfaults probably due to it being 64-bit
20:11:51evanthe inliner could inline them without a guard
20:11:53cremesso i can't actually make sure this other problem is fiexed
20:12:14cremesdbussink: work for you?
20:12:19evanand the deoptimizer just needs to find out if adding a new method causes masking of a Kernel method
20:13:01dbussinkcremes: compiling
20:13:12boyscoutCI: cc26edb success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
20:13:31brixenevan: like at method def time, do a method lookup and see if you hit a Kernel method, if so, set a flag for those inlined methods somehow?
20:14:06slavahi
20:14:29evanbrixen: yes, do the lookup and if you find a Kernel method
20:14:34brixengutten tag herr slava
20:14:44evanthen you tell all inliners of that Kernel method to deoptimize
20:14:49brixenmakes sense
20:14:50evanthat cuts deep
20:15:04evanso if we can reason that certain inliners won't see the newly defined method
20:15:07evanwe don't need to deoptimize them
20:15:20evancould do that with hierarchy analysis
20:17:24mernenhah!
20:17:30evan"tell all inliners of a method to go back to using the interpreter" == dynamic deoptimization
20:17:36evandon't let jargon get in your way!
20:17:44mernenevan: I see sometimes UnwindInfo::stack_depth has a value of 0xffffffff (-1)
20:17:48mernenis that right?
20:17:57evanlikely no.
20:18:08evanwel
20:18:15evanlets see...
20:18:20mernenI mean, is that expected?
20:18:28evanyeah, i'm checking
20:18:32evanat one point, I believe it was.
20:18:33mernenanyway, trouble is stack_depth is a uint32_t
20:18:42evanoh.
20:18:43evanhehe
20:18:44mernenon a 32-bit machine, that value is just -1
20:18:54mernen(for all that matters)
20:18:58evanbut on 64bit
20:18:59evanthats 4b!
20:19:01mernenbut on 64-bit it throws the stack pointer waaay off
20:19:04evanprobably not the intended value.
20:19:16evanok, let me check-a-poo
20:19:32evanok, yes
20:19:56evanstack_calculate_sp() can return -1
20:19:59evanthats valid
20:20:08evanso stack_depth should be just an int
20:20:31evanthe reason -1 is valid, btw
20:20:32mernencompiling now, let's see if that solves it
20:20:47evanis because the stack pointer starts live pointing to one BELOW the stack
20:20:58evanbecause the stack pointer is expect to be pointing at the current stack top
20:21:02evanand if there is nothing on the stack
20:21:06evanit points one below the stack
20:21:11brixenthe stack is topless!
20:21:17evanSPRING BREAK!
20:21:23brixenheh
20:21:32mernenthat explains why `def f() end` with no body segfaults, I guess
20:21:52evanah! probably.
20:22:50mernenlooking good, so far
20:23:20mernenall tests pass
20:23:24evanyay!
20:23:33evanmernen: good job sherlock!
20:31:37boyscoutInline methods which return self - af009db - Evan Phoenix
20:32:40evananother trivial case
20:32:51evanand, happily, that only require 3 lines of code to do
20:33:44boyscoutCI: af009db success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
20:36:21brixenFinished in 40.635683 seconds
20:36:25brixensoo close!
20:38:01evanoooh
20:38:33dbussinkcremes: fixed it for me (32 bit snow leopard)
20:39:04evanyay
20:39:20boyscoutChange type of UnwindInfo::stack_depth to int - 570217f - Daniel Luz
20:40:23mernencremes: see if it still segfaults on 64-bit
20:43:33boyscoutCI: 570217f success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
20:44:53boyscoutPush down entries on rehash/redistribute. - 4bfc246 - Brian Ford
20:47:06boyscoutCI: 4bfc246 success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
20:52:49dbussinkmernen: hmm, i'm still seeing a segfault on 64 bit when compiling readline
20:53:25mernenweird, it works fine here
20:53:43mernenreadline and all
20:54:27mernendid you try a clean build?
21:06:42dbussinkmernen: hmm, did a rake clean and still the same issue
21:07:51dbussinkmernen: are you compiling with RBX_LLVM=1 ?
21:10:38radarekdbussink: I have the same problem
21:16:26mernennope, no LLVM here
21:20:07mernenI'll try LLVM now, but that'll take a while
21:21:42dbussinkevan: looks like there's a segfault in the compile thread when using llvm or something like that
21:21:47dbussinkevan: for 64 bit systems that it
21:22:23mernenI just have to place LLVM 2.5 source into vm/external_libs/llvm and build with RBX_LLVM=1, right?
21:22:32dbussinkevan: http://gist.github.com/137107
21:23:04mernendbussink: even with a segfault on readline, the rbx binary should be there
21:23:18mernencan you test for other segfaults?
21:23:40mernenin my case, stuff like rbx -rINVALID_FILE and rbx -e 'def f; end' were sure ways to segfault
21:28:17slavaevan: can you tell me more about your type feeback?
21:31:41radarekradarek@ruby:~/opt/src/rubinius(master)$ ./bin/rbx -e "def f; end"
21:31:41radarekSegmentation fault
21:31:41radarekradarek@ruby:~/opt/src/rubinius(master)$ ./bin/rbx -rFOO
21:31:41radarekSegmentation fault
21:32:11mernenradarek: what about def f; 1 end?
21:32:27radarekmernen: works
21:32:31mernenseems to be the exact same problem, then
21:32:33radarekmernen: -e "puts 1" also works
21:33:12dbussinkmernen: ok, i should pull before complaning :P
21:33:28dbussinkhaving a rubinius clone on 3 machines is bound to confuse oneself :)
21:34:07radarekok, I'll pull and rebuild it
21:36:13radarekmernen: after pulling and rebuilding -e "def f; end" works fine but it still can't compile readline
21:38:36mernenare you using LLVM too?
21:40:00radarekmernen: yes
21:48:18dbussinkmernen: did you try running with llvm too?
21:48:30mernenI'm compiling LLVM now
21:48:45dbussinkgoing to try without llvm and see whether it goes away
21:49:25mernenvm/llvm/jit.hpp:15:42: error: llvm/CodeGen/MachineCodeInfo.h: No such file or directory
21:49:58dbussinkmernen: did you get llvm from svn trunk?
21:50:11dbussink2.5 is too old
21:50:11mernenno, 2.5 release
21:50:14mernenoh
21:54:42dbussinkmernen: ok, without llvm it compiles succesfully, but there are a bunch of test failures
22:03:33boyscoutUse the correct number of digit bits on 64 bit - 5c7d56a - Dirkjan Bussink
22:09:58dbussinkmernen: that fixes the failures i saw on 64 bit without llvm
22:10:33boyscoutCI: 5c7d56a success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
22:13:07boyscoutFix compile time warning in syck on 64 bit - 5da02ef - Dirkjan Bussink
22:15:20boyscoutCI: 5da02ef success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
22:18:19mernenhmm
22:18:46mernendbussink: now several C++ tests are failing
22:21:28dbussinkmernen: they were for me, but they were fixed with my last commits
22:21:38dbussinkevan: you there?
22:21:57mernenweird, I was in fact getting one spec failure before
22:22:12mernenbut rubinius' tests themselves were all okay
22:22:12dbussinkmernen: that's what i'm seeing now
22:22:23dbussinkmernen: did you rebuild libtommath?
22:22:35mernenI rake-clean'd… I think
22:22:51dbussinkmernen: you can do a make clean and then make in vm/external_libs/libtommath
22:23:00mernennow, on the llvm copy
22:23:20mernenvm/external_libs/llvm/include/llvm/ExecutionEngine/JIT.h:33: undefined reference to `LLVMLinkInJIT'
22:23:51mernenI'm getting hundreds of references to LLVMLinkInJIT
22:24:48mernenany ideas?
22:27:06mernencommand not found: vm/external_libs/llvm/Release/bin/llvm-config --cflags
22:27:10mernenthat might have something to do with it!
22:30:07mernendbussink: ok, rebuilt libtommath, tests now pass
22:37:33dbussinkmernen: hmm, you did a svn checkout of llvm?
22:38:01mernenyeah, but apparently rake didn't finish building LLVM
22:38:14mernenI'm running make manually now
22:46:31mernenok, llvm done, readline now segfaults here too
22:48:51mernenA problem internal to GDB has been detected, further debugging may prove unreliable.
22:50:46dbussinkmernen: auch, that's a nasty on
22:50:47dbussinkone