Index

Show enters and exits. Hide enters and exits.

00:01:40headiusI was afraid of that
00:22:54boyscoutQuick fixes to several debugger commands - a08f2f3 - Adam Gardiner
00:24:21boyscoutCI: a08f2f3 success. 1502 files, 7234 examples, 23646 expectations, 0 failures, 0 errors
09:20:53boyscoutFixed bigdecimal to not make assumptions about VALUEs. - 0d69f42 - Brian Ford
09:20:53boyscoutFixes for capi numeric conversions. - 8221f5b - Brian Ford
09:20:53boyscoutFixed bigdecimal divmod variants. - 44c8783 - Brian Ford
09:20:53boyscoutCorrectly mimic crazy MRI coerce functions. - 89423a1 - Brian Ford
09:20:53boyscoutUpdated CI tags for bigdecimal. - a3ebdd1 - Brian Ford
09:25:48boyscoutCI: a3ebdd1 success. 1503 files, 7142 examples, 23495 expectations, 0 failures, 7 errors
09:51:25boyscoutRecompile capi exts for specs if ruby.h changes. - ab57598 - Brian Ford
09:53:00boyscoutCI: ab57598 success. 1503 files, 7244 examples, 23658 expectations, 0 failures, 0 errors
15:49:00macournoyerevan: you there?
16:00:05rueProbably not quite yet
16:41:22evanmacournoyer: yo
16:41:37macournoyerhey!
16:41:39evanmacournoyer: what can I do ya for?
16:42:00rueWow, did I not miss reading MRI source
16:42:01macournoyerI just have a small Q re the raise thin we talked about
16:42:08macournoyerexception,non local return and break
16:42:21macournoyerworks pretty well for me btw
16:42:29macournoyerjust: how do you build the backtrace?
16:42:34evancool
16:42:37evanah ha
16:42:41evanthe all important question.
16:43:03macournoyerI don't see how this is done in VMMethod::run_interpreter
16:43:16evanthats because it's not done there
16:43:22macournoyerah :/
16:43:32rueParallel universe of CallFrames :)
16:43:38evancheck out system.cpp
16:43:43evanspecificly, vm_backtrace
16:43:50evanyou know that CallFrame argument you see passed down?
16:44:04evanthose for a linked list of CallFrame structures that live on the C stack
16:44:04macournoyeryes
16:44:09evanbecause they're allocated with alloca
16:44:24evanso they just have to be walked to generate a backtrace
16:44:37evanbasicly, you have to introduce some kind of simple data structure
16:45:02macournoyerbut where do you keep ref of the original calling frame, the one where the exception occured
16:45:09macournoyercause you're unwindinw in run_interpreter
16:45:13macournoyer*unwinding
16:45:30evanah.
16:45:34evanI don'.t
16:45:46evanin rubinius, backtraces are totally decoupled from exceptions
16:46:02rueAlthough, some fellow posited that by caller-allocating the stack it would be possible to do without a parallel frame structure
16:46:04evanrather, decoupled from the exception raising mechanism
16:46:32evanrue: parallel with what?
16:46:51macournoyerso you save it somewhere before unwindwing in VMMethod::run_interpreter?
16:47:06evanthe backtrace is generated, put into an Exception object
16:47:10evanthen than exception is raised
16:47:17macournoyeraaah
16:47:20macournoyerok ok
16:47:40evancheck out raise in kernel/delta/kernel.rb
16:47:43evanyou'll see we do
16:47:50evanexc.locations = Rubinius::VM.backtrace
16:48:10macournoyeraaaaaaaah!
16:48:15macournoyermakes sense now
16:48:37macournoyeralso, why you're allocating the call frames on the stack w/ alloca?
16:48:44macournoyerwhat's the advantages of this?
16:48:47macournoyerso you don't have to free?
16:48:51evanexactly
16:48:56evanif you allocate them in the heap
16:48:58evanyou have to free them
16:49:09evanwhich means management of them
16:49:11evanbut also
16:49:17evanthere are SO many of them
16:49:27macournoyeris alloca part of posix?
16:49:28evanit overwhelms the allocator
16:49:31evanyes.
16:49:42evani thought you were already using alloca
16:49:49evanhow do you allocate the register file?
16:49:50macournoyerno
16:50:13macournoyerI have a fixed size array of frame and registers
16:50:22rueHm, might add the option to get the VM backtrace when generating backtrace too
16:50:33evanrue: not a bad idea.
16:50:39rueNeed to futz with execinfo workarounds again I guess
16:51:02evanrue: check out libunwind
16:51:11evani've thought about how we could use that
16:51:13macournoyerstruct { TrFrame frames[MAX_FRAMES] } TrVm;
16:51:18macournoyeris what I have right now
16:51:23evanwell
16:51:24macournoyerI didn;t know about alloca
16:51:29evansur
16:51:40evanbut each method needs a different number of registers, yes?
16:52:12macournoyeryes, but can't be more the the max size of A,B,C registers in an instruction
16:52:15macournoyerwhich is 255
16:52:30evanso every frame gets 255 registers?
16:52:34macournoyeryeah :/
16:52:39evanyikes!
16:52:40macournoyerI have a TODO for that
16:52:45macournoyer:)
16:52:46evanlet me tell ya about alloca :D
16:53:04evanit's like malloc, but the pointer is on the current stack
16:53:10evanand when you return, it goes away.
16:53:28evancurrently, I use alloca to allocate the stk, CallFrame, and VariableScope
16:53:29evanon the C stack
16:53:39macournoyerwhat is alloca(0) for?
16:53:47macournoyerto get the address of the stack?
16:53:49evanthats a hack.
16:53:51evanyes.
16:54:07macournoyerok
16:54:40evanthats the same as
16:54:42evanint a;
16:54:45evanvoid* addr = &a;
16:54:53macournoyeris it efficient? like should I do this before each method call?
16:55:03evanit's very efficient
16:55:10macournoyerokok
16:55:14evanyes, you can do it before every method call
16:56:11macournoyerwell, how did I miss that
16:56:13macournoyerthx
17:09:45macournoyerallocation the stack before each call makes it almost twice slower
17:12:37evanmacournoyer: what did you change?
17:12:42evancould ya show me a diff?
17:13:31macournoyerhttp://gist.github.com/96496
17:13:43macournoyerf->stack is the pointer to the array
17:13:50macournoyerstack[MAX_REG]
17:14:23macournoyerw/ bm_vm2_method.rb I get 0m2.880s before and 0m4.002s w/ this
17:17:35evanhm.
17:17:35evanok.
17:17:48evanwell, i guess that makes sense a little
17:17:58evanthe old mechanism didn't require any extra work per method call
17:18:05evanbut it uses a lot of extra memory
17:18:08macournoyeryeah, probably
17:18:20macournoyertradeoffs, life is full of
17:18:23evan:D
17:19:13macournoyeron that note, I'm out for lunch
19:27:48rueevan: libunwind seems likely to be portable, I will poke it.
19:28:01evandope
19:28:06evannew jit awesomeness: http://gist.github.com/96579
19:28:12evancomplete call frame elimination
19:28:19evanfor the motherfucking win
19:28:52rueExcellent
19:29:01rueYou are pushing it through LLVM?
19:29:07evanyeah
19:29:17evanthat lowers my time to market for now.
19:29:26evanplus the macruby guys are pushing on the LLVM guys
19:29:34evanto fix some of the JIT slowness
19:29:35rueYep, sure
19:29:41evanthey've fixed it a bit actually
19:29:51evanplus, it's delayed, unlike our initial experiment
19:30:02rueI think the self-assembling did its job anyway
19:30:17evanwhich was?
19:30:39rueTo figure out how to restructure the rest of the VM
19:30:45evanyep
19:30:53rueForest, trees etc.
19:30:54evanthe JIT is now structured like you'd imagine
19:31:08evanie, the entire body of work to execute a method is JITd
19:31:19evanunlike our previous attempts
19:31:24rueExactly
19:31:33evanwhich means a lot more optimization can occur, intra-method
19:47:05rueHave you tested the primitive callpath with JIT?
19:49:31evannot yet
19:49:39evanthink we'll run into problems?
19:53:12rueProbably not, but there is likely some streamlining possible there
19:56:57rueAnd the "performance primitives" should migrate back to Ruby in that process
19:58:52evanagreed.
20:27:03evanwoop.
20:27:20evanwhy i've always wanted to be using LLVM: http://gist.github.com/96607
20:27:33evancontrived, yes
20:27:47evanbut it constant collapsed the fixnum comparison
20:27:50evandirectly into false
20:28:38tilmani guess it's time to get excited now? :D
20:28:44evanheh
20:36:54ruebreaks out the flag
20:37:04evanwoo
20:37:07evananother awesome thing
20:37:12evanthere are so many passes to do shit
20:37:55evanI added another pass, and here's what I got: http://gist.github.com/96607
20:37:57evanlast file
20:44:15rueGenerating by hand or transforming it?
20:44:24evantransformed
20:44:28evanno hand optimization
20:44:31evanjust added
20:45:38evan passes_->add(createDeadStoreEliminationPass());
20:45:42evanboom.
20:57:08rueBoom! or Ka-boom
21:12:36rueDelay indicative of ka-boom
21:21:48macournoyernice!
21:21:51macournoyerllvm is magic
21:27:29evan:D
22:21:10rueNo matter what we do, it always comes down to reading assembly
22:21:36evani know
22:29:38rueHm, LLVM uses assembly and IR interchangeably in doc?
22:30:27evaneh?
22:33:00rueAh, no, they do distinguish it, right at the top. The doc sometimes refers to IR and sometimes to assembly
22:33:07rue(LLVM assembly)
22:33:12evanah ah
22:33:17evanthe words, gotcha.
22:33:36rueYeh