Da
Show enters and exits. Hide enters and exits.
| 00:15:50 | brixen | evan: nope, running just rails -h it doesn't not seem to have an effect |
| 00:16:03 | brixen | over 5 runs precompiled |
| 00:16:14 | evan | ok |
| 00:16:19 | evan | just curious |
| 00:16:22 | brixen | the compilation run was slightly less but I only ran one each |
| 00:16:33 | brixen | so could be flutter |
| 00:16:37 | evan | sure |
| 00:16:40 | brixen | I will test it with hash |
| 00:16:52 | brixen | since this is what I was essentially asking the other day |
| 00:17:08 | brixen | #each_item can yield a single object, instead of key, value |
| 00:17:15 | brixen | so I'll see what effect that has |
| 00:17:31 | evan | right |
| 00:17:43 | brixen | gonna head to a coffee shop, bbiab.. |
| 00:17:54 | evan | k |
| 00:18:01 | slava | brixen: you live in amsterdam? |
| 00:18:08 | brixen | slava: yes :D |
| 00:18:22 | brixen | no, unfortunately, I do not |
| 00:18:33 | slava | ah, ok, so your 'coffee shop' is not the real thing, then |
| 00:18:38 | brixen | but for coffee, I live in one of the top 2 places in the US :) |
| 00:18:51 | brixen | no, it's a real coffee shop heh |
| 00:18:56 | slava | I thought you were going to kick rbx dev up a notch with a 3 gram lebanese hash bomber |
| 00:19:11 | brixen | you knowz it yo |
| 00:20:13 | evan | I think that the StackDepthCalculator is going to prove to be a good benchmark |
| 00:20:32 | slava | you determine the max operand stack depth statically now? |
| 00:20:35 | brixen | ahh good point |
| 00:20:38 | evan | yep |
| 00:20:46 | slava | evan: nice |
| 00:21:00 | evan | I removed all instructions that had an unbound effect on the stack |
| 00:21:04 | evan | like push_array |
| 00:21:17 | slava | now you can convert stack values to LLVM IR registers very easily! |
| 00:21:29 | evan | yep! |
| 00:21:31 | evan | i'm not yet |
| 00:21:34 | evan | but, awesomely |
| 00:21:36 | evan | I don't have to |
| 00:21:42 | evan | LLVM is so fucking smart, it does it for me. |
| 00:21:53 | evan | ie, emit code that manipulates a stack pointer |
| 00:21:56 | slava | the alias analysis pass picks up on your stack locations? |
| 00:22:01 | evan | and it tracks the usage and removes it |
| 00:22:04 | evan | and uses the static locations |
| 00:22:09 | slava | cool, that's what factor's codegen does |
| 00:54:04 | evan | hehehehe |
| 00:54:04 | evan | http://gist.github.com/112499 |
| 00:57:54 | headius | cute :) |
| 00:58:03 | slava | whatdoes the benchmark do? |
| 00:58:10 | evan | call Array#each in a loop |
| 00:58:28 | slava | how big is the array? |
| 00:58:36 | evan | mmm |
| 00:58:47 | evan | 5k |
| 00:59:09 | slava | and how many times do you call each on it? |
| 00:59:11 | evan | so calling Array#each 5k times on an array with 5k elements |
| 00:59:19 | slava | and the block does nothing? |
| 00:59:23 | evan | yep |
| 00:59:28 | slava | is the array allocated once? |
| 00:59:30 | headius | how much of that is actually jitting? |
| 00:59:36 | evan | headius: zero in this case |
| 00:59:40 | evan | it's stupid |
| 00:59:45 | headius | oh, what does --fast do then? |
| 00:59:50 | evan | --fast has a list of methods to compile |
| 00:59:51 | evan | :D |
| 00:59:55 | evan | and it does them up front |
| 01:00:03 | evan | it's totally dumb |
| 01:00:13 | evan | i don't have any metrics hooked up yet |
| 01:00:15 | headius | oh, so it's jitting at startup then |
| 01:00:28 | evan | thought it might be fun to play with picking some methods to jit up front |
| 01:00:29 | headius | so what portion of that is jitting at startup? :) |
| 01:00:32 | evan | yeah, jit at startup |
| 01:00:40 | evan | none |
| 01:00:44 | slava | evan: factor iterates over a 5k array 5k times in 0.07 seconds :-P |
| 01:01:00 | evan | but the jit is taking no time |
| 01:01:00 | headius | ok, I don't get it then |
| 01:01:03 | evan | since it's just one method |
| 01:01:25 | evan | well, I wanted to make Array#each fast |
| 01:01:27 | evan | so I did |
| 01:01:40 | evan | by having it compiled up front |
| 01:01:43 | headius | so each is compiling |
| 01:01:53 | evan | is compiled |
| 01:01:53 | evan | yes |
| 01:01:57 | headius | compiled when |
| 01:02:08 | evan | in loader.rb |
| 01:02:11 | headius | so at startup |
| 01:02:12 | evan | before it loads a script |
| 01:02:14 | headius | isn't that what I said? |
| 01:02:15 | evan | yes.. |
| 01:02:18 | evan | yes |
| 01:02:20 | evan | and I answered |
| 01:02:22 | evan | didn't I? |
| 01:02:32 | headius | I asked what portion of this is jitting at startup and you said none |
| 01:02:35 | evan | yeah |
| 01:02:37 | evan | virtually none |
| 01:02:41 | headius | except each |
| 01:02:44 | evan | it's not measurable |
| 01:02:44 | headius | which would not be none |
| 01:02:51 | evan | huh? |
| 01:02:59 | headius | each is compiled before you start up or when you start up? |
| 01:03:01 | slava | headius: I doubt compiling one method would take long enough to measure |
| 01:03:13 | evan | when I start up |
| 01:03:17 | headius | I was just wondering how much of this bench was running as compiled code |
| 01:03:23 | evan | oh |
| 01:03:25 | evan | just Array#each |
| 01:03:26 | evan | only. |
| 01:03:27 | headius | compiled to asm |
| 01:03:28 | headius | ok |
| 01:03:34 | evan | literally I'm doing |
| 01:03:40 | evan | Rubinius.jit Array.instance_method(:each) |
| 01:03:45 | evan | no really, literally that. |
| 01:03:48 | headius | so basically the part that would be in C for MRI |
| 01:03:50 | evan | hardcoded |
| 01:03:54 | headius | ahh sure |
| 01:03:55 | evan | right |
| 01:04:23 | headius | ok, I understand now :) |
| 01:04:51 | evan | ok |
| 01:04:59 | evan | it's pretty stupid |
| 01:05:02 | evan | it's SO stupid |
| 01:05:05 | evan | it's hard to get |
| 01:05:06 | evan | :D |
| 01:05:37 | headius | nah, it makes sense |
| 01:05:58 | headius | if we had more of core in ruby we'd precompile all of it to jvm bytecode, obviously |
| 01:06:07 | headius | this is similar to that, but you have to compile at startup |
| 01:06:28 | evan | well |
| 01:06:42 | slava | hotspot compiles everything on startup too |
| 01:06:44 | evan | i might make a mode where I can dump out the compiled code |
| 01:08:41 | slava | I looked at the array_each benchmark in the source |
| 01:08:55 | slava | its not a very good benchmark, because you can optimize it down to nothing |
| 01:09:02 | evan | if you can |
| 01:09:05 | evan | awesome for you! |
| 01:09:12 | evan | then the benchmark shows how studly you are |
| 01:09:18 | evan | grab a cold one and hit the couch! |
| 01:09:59 | slava | since the actual elements are not used, the array lookup is optimized away, and then the only thing that's done to the array is taking its length, but the length is known since its allocated right there, so the array allocation is eliminated entirely |
| 01:10:01 | headius | heheh |
| 01:10:07 | headius | we can't inline blocks yet, but in theory it could optimize away if we did |
| 01:10:07 | slava | and it becomes a counted loop |
| 01:10:29 | headius | slava: that's exactly my concern about a lot of the super-micro benchmarks being run on macruby |
| 01:10:41 | headius | with their optimistic LLVM stuff, most of those benchmarks are probably not doing anything at all |
| 01:11:03 | headius | which is cool, but obviously...optimistic |
| 01:11:05 | headius | :) |
| 01:11:22 | slava | that's why the factor version of the benchmark runs 40x faster, because most of the benchmark gets deleted by the optimizer |
| 01:11:25 | evan | slava: please write me an optimizer to do that for ruby! :D |
| 01:12:04 | slava | if I deleted empty loops then it would boil down to a no-op |
| 01:12:07 | evan | slava: it's not really fair, since you're doing it entirely staticly |
| 01:12:16 | evan | and we have to use a lot of dynamic feedback to do it |
| 01:12:19 | slava | I typed it in the REPL and ran it |
| 01:12:56 | headius | slava: if I wrote it in java it would probably not even be measurable |
| 01:13:02 | evan | sure |
| 01:13:07 | headius | here, i'll write it in bitescript :) |
| 01:13:13 | evan | if it weren't a closure, it would be easier too |
| 01:13:21 | headius | yeah |
| 01:13:23 | headius | fo' sho' |
| 01:13:38 | evan | but thems not how we does it here in the ruby wild west. |
| 01:13:46 | slava | headius: well ,the only difference in machine code would be that java keeps values in registers between basic blocks |
| 01:13:51 | slava | so the loop counter doesn't have to be loaded and stored |
| 01:14:18 | slava | once I eliminate this restriction factor should be as fast as hotspot on integer and FP code that doens't dispatch |
| 01:15:28 | slava | evan: your job is easier actually, because you're using llvm for codegen |
| 01:15:44 | slava | so you're writing similar to my high-level optimizer, but the low-level optimizer is just llvm |
| 01:16:07 | evan | right |
| 01:16:21 | evan | it's just running late stage |
| 01:16:28 | evan | to use type feedback to make decisions |
| 01:16:34 | evan | rather than upfront |
| 01:18:29 | slava | if I move the array allocation outside of the word, then it doesn't optimize as much |
| 01:18:46 | slava | 0.2 seconds |
| 01:18:57 | slava | now its doing a method dispatch on every iteration |
| 01:20:10 | evan | now move it so that the optimizer can't see the body of the loop |
| 01:20:51 | slava | that won't compile |
| 01:21:00 | evan | why not? |
| 01:21:05 | evan | you can't make a loop that does a method dispatch? |
| 01:21:11 | evan | and the method is the loop body |
| 01:21:30 | slava | the optimizer always inlines blocks |
| 01:21:34 | slava | at their call site |
| 01:21:49 | slava | higher-order functions are more like macros than real functions |
| 01:22:12 | evan | right |
| 01:22:17 | evan | so make it so that it can't inline it. |
| 01:22:22 | evan | make it suck |
| 01:22:23 | evan | in other words. |
| 01:22:24 | slava | I can disable the optimizer |
| 01:22:38 | slava | 1.7 seconds |
| 01:22:58 | evan | is that calling out to the block now? |
| 01:23:02 | evan | as a function? |
| 01:23:05 | slava | yeah |
| 01:23:17 | slava | this is with the non-optimizing compiler, that compiles everything as a string of subroutine calls |
| 01:24:12 | slava | evan: I disabled PICs. 2.3 seconds :-) |
| 01:24:29 | evan | keep going |
| 01:24:30 | slava | its officially starting to suck |
| 01:24:31 | evan | make it really bad |
| 01:24:36 | evan | i want you to get up to 5s |
| 01:24:59 | evan | then reverse it all, and put each step in a blog post |
| 01:25:22 | slava | haha |
| 01:25:29 | slava | 2.6 seconds if the optimzier is disabled for the library too |
| 01:25:38 | slava | oh I have an idea |
| 01:25:49 | slava | recompiles the VM with assertions enabled |
| 01:26:08 | evan | now we're talking! |
| 01:27:30 | mvr | (btw, had to do http://gist.github.com/112513 to compile with LLVM, dunno if it makes sense) |
| 01:28:01 | slava | evan: damn, didnt make a difference. I geuss not enough time is spent running C code to matter |
| 01:28:15 | evan | mvr: oh |
| 01:28:15 | evan | yeah |
| 01:28:21 | evan | mvr: thanks, i'll throw that in. |
| 01:29:13 | evan | oh damn! |
| 01:29:17 | evan | where's boyscout?! |
| 01:30:08 | headius | huh, bitescript bug |
| 01:30:14 | evan | boyscout: stop slackin'! |
| 01:30:16 | headius | can't construct primitive array |
| 01:30:22 | boyscout | sorry boss :/ |
| 01:30:44 | boyscout | CI: 04c99ba success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 01:32:33 | headius | heh |
| 01:32:37 | headius | ok yeah... |
| 01:33:10 | boyscout | Add extra -D for newer LLVM - 9379ed0 - Evan Phoenix |
| 01:33:11 | headius | I have to go to nanoseconds to time this |
| 01:34:28 | headius | http://gist.github.com/112518 |
| 01:34:41 | headius | but yeah, basically doesn't do anything |
| 01:35:22 | boyscout | CI: 9379ed0 success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 01:42:47 | mvr | hrm. getting a segfault running bin/rbx? http://gist.github.com/112522 |
| 01:44:29 | evan | weird |
| 01:44:32 | evan | WAY at the begining too |
| 02:35:52 | boyscout | Use the proper VMMethod - 739a3e8 - Evan Phoenix |
| 02:35:53 | boyscout | Add support for long returns into JITd code - bea33b3 - Evan Phoenix |
| 02:38:13 | evan | next I think i'm going to have to add exception handlers to the JIT |
| 02:41:15 | slava | evan: sweet |
| 02:42:14 | boyscout | CI: bea33b3 success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 02:44:35 | kli | are there any new performance updates on FFI vs regular extensions? |
| 02:45:53 | evan | mmm |
| 02:46:01 | evan | non that are performance related |
| 02:46:18 | evan | there are some FFI enhancements to the JIT on the roadmap |
| 02:46:30 | evan | performance enhancements |
| 02:46:40 | slava | you should be able to make FFI calls as fast as C calls with the JIT, just by generating machine code stubs |
| 02:46:44 | slava | and then you can ditch libffi |
| 02:46:49 | evan | thats the plan |
| 02:47:00 | evan | both inline and callable stubs |
| 02:47:02 | slava | will you still support non-JITted execution? |
| 02:47:12 | evan | yeah |
| 02:47:17 | evan | don't see a reason to ditch it |
| 02:47:22 | slava | less code to maintain |
| 02:47:28 | evan | plus the interpreter is what generates all the data to make the JIT good. |
| 02:48:00 | slava | you can use LLVM to generate the interpreter |
| 02:48:09 | slava | then you can do direct threading without gcc extensions |
| 02:48:17 | evan | not really |
| 02:48:23 | evan | LLVM doesn't support label-as-value properly. |
| 02:48:35 | slava | oh? damn |
| 02:48:43 | evan | yeah, i've asked about it a number of times. |
| 02:49:51 | kli | so umm |
| 02:50:05 | kli | you guys are saying in the future, that FFI will == native? |
| 02:50:16 | evan | native what? |
| 02:50:25 | slava | evan: so llvm has no way to generate a jump to an address stored in a register at all? |
| 02:50:31 | slava | evan: how are function pointers implemented then? |
| 02:50:40 | evan | it can do that |
| 02:50:40 | kli | native C extension |
| 02:50:59 | evan | you can do "call *%eax" |
| 02:51:05 | evan | well, the HL equiv |
| 02:51:06 | slava | evan: can it geerate a jmp *%eax ? |
| 02:51:15 | evan | if you structure it to be a tailcall, yes. |
| 02:51:19 | evan | otherwise no |
| 02:51:20 | slava | then you can do direct threading |
| 02:51:30 | evan | ah |
| 02:51:38 | evan | tailcall through function pointers as the blocks |
| 02:51:40 | slava | you don't need labels as values, that's only if you wanted to express dtc in terms of C semantics |
| 02:52:00 | evan | kli: well, they're different beasts |
| 02:52:02 | slava | at the end of each instruction, you advance the instruction pointer, load from it, and jump |
| 02:52:08 | evan | kli: FFI will be a bunch faster than native |
| 02:52:19 | evan | and it already is now somewhat faster |
| 02:52:20 | slava | evan: does rbx have a C extension API other than the MRI compat? |
| 02:52:30 | evan | slava: no, but i've considering adding one |
| 02:52:35 | slava | evan: what for? |
| 02:52:40 | evan | haven't out of dicipline |
| 02:52:51 | slava | I don't think you need it, FFI should be sufficient |
| 02:52:54 | kli | ah, you're comparing it to the compat performance? |
| 02:53:08 | evan | compat performance? |
| 02:53:13 | kli | i have this big library for MRI right now |
| 02:53:17 | kli | that i'm considering porting to ffi |
| 02:53:26 | evan | it would be faster under rubinius if you use FFI |
| 02:53:27 | evan | most likely |
| 02:53:33 | kli | k |
| 02:53:35 | evan | because of the semantics of the extensions |
| 02:53:36 | slava | kli: in theory FFI should be jsut as fast, in practice it depends on the implementation of FFI and how inefficient it is |
| 02:53:41 | evan | we have to copy data back and forth a lot. |
| 02:53:48 | evan | FFI is more straight forward |
| 02:53:52 | evan | but you'll end up doing more in ruby |
| 02:54:02 | evan | so as we get ruby faster and faster |
| 02:54:15 | evan | FFI will overtake native extensions more |
| 02:54:33 | evan | ok.. |
| 02:54:33 | evan | bye |
| 02:54:35 | evan | geez. |
| 02:54:48 | slava | heh |
| 03:09:31 | dkubb | I'm trying to convince dbussink to port DataObjects to FFI, at least the do_sqlite3 driver. the biggest unknown right now is the performance it'll have in MRI |
| 03:10:13 | brixen | dkubb: ah that's cool |
| 03:10:21 | brixen | could have both C ext and FFI |
| 03:10:28 | brixen | let the user select |
| 03:10:30 | dkubb | part of the benefit of DataObjects (DO) is that alot of the work is done in C, and nicely formed Ruby objects are returned.. rather than just an Array of strings that need to be coerced in Ruby |
| 03:10:55 | brixen | hm, yeah, that's the use case for C ext |
| 03:12:15 | dkubb | the other benefit of DO is a uniform API across all the DB drivers, which still holds regardless of whether it's FFI or a C ext |
| 03:15:51 | dkubb | as far as rubinius goes, dbussink said that DO should run on it soon-ish |
| 03:16:13 | dkubb | I don't have any dates, he just said it was a possibility soon |
| 03:17:51 | evan | hm |
| 03:17:54 | evan | i should explore dinner. |
| 03:21:17 | evan | perhaps the In and the Out.. |
| 03:32:22 | evan | woo |
| 03:32:28 | evan | exception handlers! |
| 06:37:56 | boyscout | Hook up exception handling - 6338aa5 - Evan Phoenix |
| 06:38:02 | evan | woot. |
| 06:38:05 | evan | i figured that would take longer. |
| 06:51:12 | boyscout | CI: 6338aa5 success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 07:50:24 | tmornini | brixen: Do you know how to build and enable JIT on the llvm-jit branch? I see references to -DENABLE_LLVM and RBX_JIT environment var. |
| 07:51:12 | brixen | 3 steps |
| 07:51:24 | brixen | get llvm from svn |
| 07:51:27 | tmornini | got it |
| 07:51:32 | tmornini | oh, not release? |
| 07:51:37 | brixen | apply this patch http://github.com/evanphx/llvm-patches/blob/master/jit-info.diff |
| 07:51:52 | brixen | which will require some manual work |
| 07:51:58 | brixen | or at least it did for me |
| 07:51:59 | evan | tmornini: the llvm-jit branch has been merged back into master |
| 07:52:04 | evan | brixen: really? |
| 07:52:09 | tmornini | evan: Ah, very cool. |
| 07:52:10 | evan | let me redo the patch then |
| 07:52:13 | brixen | evan: yeah |
| 07:52:18 | brixen | sec.. |
| 07:52:18 | evan | so it's clean against svn |
| 07:52:25 | tmornini | This is really exciting to watch! |
| 07:52:30 | evan | I might be behind a little |
| 07:52:48 | brixen | lib/ExecutionEngine/JIT/JIT.h |
| 07:52:55 | brixen | that file has changed a bit |
| 07:53:00 | evan | ok, one sec. |
| 07:53:05 | tmornini | So I need LLVM HEAD? |
| 07:53:05 | evan | i'm updating and i'll commit a new patch |
| 07:53:14 | brixen | tmornini: yes |
| 07:53:16 | tmornini | OK |
| 07:53:38 | slava | all this JIT action makes me jealous, I've been working on docs all day |
| 07:54:56 | evan | ok, my patch has ported forward |
| 07:55:02 | evan | gimme a sec to make sure it's still clean |
| 07:55:15 | evan | i'm trying to get this patch accepted to llvm |
| 07:55:16 | evan | to avoid this. |
| 07:55:34 | evan | I guess i could conditional the functionality the patch uses... |
| 07:55:45 | tmornini | We need to get on the LLVM Users page... |
| 07:56:08 | headius | evenin tmornini |
| 07:56:21 | tmornini | headius: Howdy! |
| 07:58:40 | tmornini | headius: How are things at Oracle? :-) |
| 07:58:58 | headius | beats me, I don't work there yet |
| 07:59:02 | evan | ouch |
| 07:59:22 | tmornini | No ouch intended, honestly, just checking which way the wind is blowing. |
| 07:59:43 | headius | I'm not really sure how things are at Sun most days :) I pretty much work for JRuby, Inc |
| 08:00:00 | tmornini | headius: That's cool. |
| 08:01:23 | tmornini | headius: You guys are rockin' on JRuby. Congrats. |
| 08:01:58 | tmornini | llvm checked out. |
| 08:02:06 | evan | ok |
| 08:02:07 | evan | one sec. |
| 08:02:07 | headius | thanks! hopefully for 1.4 we'll move to an optimizing compiler and rock a bit more |
| 08:02:22 | evan | well, i'll just push the patch |
| 08:03:05 | evan | tmornini: ok, grab the newest jit-info.diff |
| 08:05:21 | evan | haha yes! |
| 08:05:41 | evan | the governor got in a dig at UCLA during his commencement speech today |
| 08:08:24 | tmornini | OK, all patched. |
| 08:08:46 | evan | ok, now link the check out directory to vm/external_libs/llvm |
| 08:08:58 | tmornini | I just checked it out there. :-) |
| 08:09:05 | brixen | and configure && make |
| 08:09:11 | evan | a quick aside: it might be worth it to "vendor" a compiled version of LLVM for OS X |
| 08:09:29 | tmornini | In the future, sure |
| 08:09:54 | brixen | tmornini: I'm guessing you haven't built llvm because I heard no complaints about your machine melting |
| 08:10:11 | tmornini | I think rake makes LLVM if it's in place, right? |
| 08:10:29 | tmornini | I've built it recently trying to see what's happening. I know it takes a while. |
| 08:10:33 | headius | evan: does llvm have anything that would help with dynamic deoptimization? |
| 08:11:37 | evan | tmornini: yeah, rake should do it if llvm is in the right place |
| 08:11:50 | evan | headius: not really |
| 08:11:54 | tmornini | Cool. it's building now. |
| 08:11:57 | evan | it's at a layer below that kind of thing |
| 08:12:10 | headius | mm ok |
| 08:12:25 | evan | but, given that I have an interpreter, it's easy enough to insert into it's IR something like |
| 08:12:28 | headius | that's kinda what I was thinking..doesn't preclude you doing that, but doesn't help you do it |
| 08:12:30 | tmornini | So what is the LLVM JIT status now? |
| 08:12:38 | tmornini | Merged, but still being worked on? |
| 08:12:47 | evan | ret call rbx_start_interpreter(state, call_frame, <some ip>) |
| 08:13:08 | evan | ie, tailcall to a function that starts the interpreter at a particular point |
| 08:13:11 | slava | what about on-stack replacement? :) |
| 08:13:19 | evan | slava: thats like a 3.0 feature |
| 08:13:36 | evan | slava: YOU don't even have that :D |
| 08:13:51 | evan | didn't john rose say he thought not having on-stack replacement was a good thing? |
| 08:13:55 | evan | i thought he did |
| 08:14:12 | evan | headius: dynamic deopt makes a lot of assumptions |
| 08:14:19 | evan | about the infrastructure the code is running in |
| 08:14:31 | evan | it's really a layer above the optimizing compiler |
| 08:14:31 | headius | I don't recall what he said about on-stack replacement |
| 08:14:41 | evan | it was at lunch one of the days |
| 08:14:42 | headius | sure |
| 08:14:46 | evan | i think you were at a different table |
| 08:14:57 | evan | slava and I were picking his brain :D |
| 08:15:01 | headius | mmm perhaps so :) |
| 08:15:23 | headius | yeah, I know deopt makes a lot of assumptions |
| 08:15:29 | evan | thought I really need to cyphone his brain |
| 08:15:31 | evan | not just pick at it |
| 08:15:42 | headius | that's obvious...it would have to know how to deopt and what to deopt to, which presumably would be different for each language |
| 08:15:53 | slava | evan: you could just port rbx to jvm :) |
| 08:15:53 | evan | right |
| 08:16:07 | headius | huzzah, HotRubinius |
| 08:17:13 | evan | DING DING DING |
| 08:17:17 | evan | COME AND GET IT! |
| 08:18:34 | headius | that's JRuby 1.5 |
| 08:19:01 | evan | hows the invokedynamic stuff coming? |
| 08:19:34 | headius | I think it's merged into openjdk mainstream now |
| 08:19:43 | headius | I'm going to try to give it a shot this weekend |
| 08:19:50 | headius | too much to do |
| 08:19:56 | evan | I keep forgetting it's friday |
| 08:20:02 | evan | abby went to Cleveland yesterday |
| 08:20:07 | evan | so my bachlor weekend started a day early |
| 08:20:15 | evan | which really just meant staying up to 3am coding |
| 08:20:44 | brixen | funny how not having wife/gf around tends to encourage that :) |
| 08:21:01 | evan | she doesn't nag me or anything |
| 08:21:35 | evan | just having her around i'm like "well, bed time." |
| 08:21:47 | evan | i guess I revert to college Evan when i'm alone at night |
| 08:24:29 | tmornini | If you're saying you work less when Abby is around, EY may be able to send her on vacation. :-) |
| 08:24:48 | evan | I love her to death, and i'm sure she'd agree to that. |
| 08:24:48 | evan | :D |
| 08:25:48 | tmornini | Evan wins employee of the month, May, Abby gets 4 week vacation! |
| 08:25:57 | evan | hah |
| 08:26:16 | slava | as ESR said, sex and programming don't mix |
| 08:26:24 | slava | all the great programmers like RMS are virgins |
| 08:26:24 | tmornini | Wow, LLVM does take a while. |
| 08:26:33 | evan | yeah |
| 08:26:37 | evan | go get a drink. |
| 08:26:57 | evan | slava: *facepalm* |
| 08:27:25 | tmornini | I always thought I was a great programmer. Now I know where I went wrong. Pity! |
| 08:27:42 | slava | he didn't really say that. in fact, he wrote http://www.catb.org/~esr/writings/sextips/ which is one of the all-time lamest things ever |
| 08:27:56 | headius | tmornini: my machine must be faster than yours, just finished |
| 08:28:07 | evan | i'd say i'm surprised this is the discussion we're having at 12:30am on a friday, but i'm not surprised. |
| 08:30:56 | tmornini | I got a late start, had to back up and redo with "RBX_LLVM rake" |
| 08:37:35 | headius | so RBX_LLVM=true rake? |
| 08:37:46 | evan | sure |
| 08:37:51 | evan | set it to anything |
| 08:37:57 | headius | then what to run it? |
| 08:37:58 | evan | it's jsut it's presence that matters |
| 08:38:17 | evan | it's not on-demand |
| 08:38:22 | evan | i haven't hooked up any metrics |
| 08:38:24 | evan | so you have to do |
| 08:38:34 | evan | Rubinius.jit Blah.method(:foo) |
| 08:38:41 | headius | ahh |
| 08:38:43 | evan | it takes Method and UnboundMethod objects |
| 08:38:47 | headius | okee |
| 08:44:17 | tmornini | Congrats on the merge. I'm going to start counting sheep. :-) |
| 08:44:46 | evan | say hi to the sheeps for us. |
| 08:47:13 | evan | MAN I love LLVM seeing through the stack manipulations |
| 08:47:49 | slava | its a pretty trivial optimization to implement anyway |
| 08:48:04 | tmornini | Would this be expected behavior? http://gist.github.com/112614 |
| 08:48:18 | evan | yeah |
| 08:48:21 | evan | it's takes a Method object |
| 08:48:23 | evan | change that to be |
| 08:48:31 | evan | String.method(m) |
| 08:48:35 | evan | you're brave. |
| 08:48:36 | evan | :D |
| 08:48:40 | tmornini | :-) |
| 08:50:00 | tmornini | http://gist.github.com/112615 |
| 08:50:28 | evan | hah ha! |
| 08:50:34 | evan | thats.. actually expected! |
| 08:50:44 | tmornini | Cool. :-) |
| 08:51:00 | evan | i should have Rubinius.jit just fail quietly |
| 08:51:03 | evan | i'll do that in a sec. |
| 08:51:30 | tmornini | If you cannot JIT Rubinius::AccessVariable, JIT probably isn't worth it! :-) |
| 08:51:39 | tmornini | <ducks> |
| 08:51:42 | tmornini | Goodnight! |
| 08:51:45 | evan | quack! |
| 08:57:46 | boyscout | Handle breaking out of a block, enhance rbx.jit.dump_code - 0de71f8 - Evan Phoenix |
| 08:59:04 | evan | for those interested: http://gist.github.com/112617 |
| 08:59:26 | evan | rbx.jit.dump_code now takes 3 bit values |
| 08:59:34 | evan | 1 for simple (and long) IR |
| 08:59:39 | evan | 2 for optimized IR |
| 08:59:45 | evan | 4 for machine code |
| 08:59:57 | evan | thus, 7 prints out all of them. |
| 09:03:42 | boyscout | CI: 0de71f8 success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 09:08:44 | headius | hmmm |
| 09:08:53 | headius | "not supported yet" means it won't compile I presume? |
| 09:08:59 | evan | correct. |
| 09:09:13 | evan | what were you trying to compile? |
| 09:09:34 | headius | just fib |
| 09:09:40 | headius | I thought it would be simple enough |
| 09:09:44 | evan | which version? |
| 09:09:46 | evan | pastie the code |
| 09:09:51 | evan | yeah, i'd think it would be simple enough |
| 09:09:51 | headius | recursive one |
| 09:10:02 | evan | pastie it |
| 09:10:08 | evan | so i don't chase my tail at 1am |
| 09:10:09 | evan | :D |
| 09:10:24 | headius | bench_fib_recursive in jruby/bench |
| 09:10:32 | headius | I can pastie in a minute |
| 09:10:52 | headius | hmm |
| 09:11:10 | headius | http://gist.github.com/112619 |
| 09:11:26 | evan | huh.. |
| 09:11:28 | evan | let me try. |
| 09:11:44 | headius | do I need to pass anything to make Rubinius.jit work? |
| 09:11:53 | headius | I just did RBX_LLVM=1 rake to build |
| 09:12:20 | evan | that should be enough. |
| 09:12:28 | evan | huh |
| 09:12:29 | evan | i got it too... |
| 09:12:34 | evan | ok, one sec. |
| 09:12:53 | evan | oh |
| 09:12:55 | evan | the minus meta op |
| 09:12:58 | evan | i thought I did that one.. |
| 09:13:00 | evan | one sec. |
| 09:13:31 | headius | iterative seems to compile, but of course the bottleneck there is bignum |
| 09:13:42 | headius | oh, and it blows up memory too, must still be a leak in bignum |
| 09:13:51 | evan | gah. |
| 09:13:54 | headius | ate up 1GB in just a couple seconds |
| 09:13:58 | evan | probably the same one as before |
| 09:14:02 | evan | yeah, |
| 09:14:07 | evan | bignum's internal heap is growing |
| 09:14:13 | evan | and not advising the rubinius GC to run |
| 09:14:20 | evan | i'm guessing that old bug came back in |
| 09:14:50 | slava | you don't do a GC check when allocating? |
| 09:15:02 | evan | yeah |
| 09:15:04 | evan | i do |
| 09:15:08 | evan | this is a more complicated problem |
| 09:15:17 | evan | because we use an external lib for bignum support |
| 09:15:20 | evan | that uses malloc internally |
| 09:15:29 | slava | ah |
| 09:17:38 | headius | hmm, many of the benchmarks I have just aren't suited to testing something like llvm |
| 09:17:45 | headius | they end up not doing any work |
| 09:18:33 | headius | erg, or testing jruby with peephole optz apparently |
| 09:18:46 | evan | whats a number i should try with fib? |
| 09:18:50 | evan | 100? |
| 09:18:58 | headius | the arg is just number of iterations |
| 09:19:02 | headius | it defaults to fib(30) |
| 09:19:15 | headius | second arg would be what fib to calculate |
| 09:20:16 | evan | ok |
| 09:20:18 | evan | pretty sure it's working |
| 09:20:19 | evan | i'll push |
| 09:20:21 | evan | and dobule check |
| 09:20:27 | evan | i need to recompile not in DEV mode |
| 09:20:40 | headius | ok |
| 09:20:56 | boyscout | Add meta_send_op_minus - ff5ea90 - Evan Phoenix |
| 09:21:20 | evan | huh. |
| 09:21:25 | evan | in Activity Monitor |
| 09:21:32 | evan | Tweetie shows up as a 64bit program |
| 09:21:38 | evan | using 3G of virtual memory |
| 09:21:46 | evan | and 52M of real |
| 09:22:25 | headius | they're rather pessimistic about how much memory they'll need, perhaps |
| 09:22:52 | evan | heh |
| 09:23:04 | evan | i think it's a by-product of it being a 64bit binary |
| 09:23:22 | headius | bleh, I keep forgetting jruby can't build rbx anymore |
| 09:23:34 | evan | no? |
| 09:24:33 | headius | in this case it seems rubypp fails |
| 09:24:49 | evan | weird |
| 09:24:57 | evan | the build process needs work. |
| 09:25:44 | headius | a local var bench seems to get the expected speedup from llvm |
| 09:25:49 | headius | mostly because it doesn't actually do any work |
| 09:25:59 | evan | yep |
| 09:26:02 | headius | bunch of a = a lines |
| 09:26:05 | evan | it sees the stack movement |
| 09:26:16 | evan | and says "hey now, i know this story" |
| 09:26:32 | boyscout | CI: ff5ea90 success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 09:27:29 | headius | yeah, fib looks more like it did with your other jit |
| 09:27:30 | headius | jit number 2 |
| 09:27:37 | evan | yeah |
| 09:27:40 | evan | here i'm getting |
| 09:27:44 | evan | 4.6s for interpreter |
| 09:27:50 | evan | this is with fib(35) |
| 09:27:57 | evan | 2.09s with the JIT |
| 09:28:24 | evan | being a recursive algo |
| 09:28:31 | evan | makes sense between the 2 jits |
| 09:28:34 | evan | there isn't a lot to optimize. |
| 09:28:47 | evan | since i'm not spying types for LLVM in this case |
| 09:28:48 | headius | yeah |
| 09:29:08 | evan | whats jruby? |
| 09:29:30 | headius | here with jit, rbx is 1.6s |
| 09:29:38 | headius | checking jruby |
| 09:29:41 | evan | i've got a faster machine :D |
| 09:29:42 | evan | er. |
| 09:29:44 | evan | you've got! |
| 09:29:52 | evan | i'm running fib(35) under MRI |
| 09:29:55 | evan | it's still going.... |
| 09:29:56 | slava | 35 fib => 0.4 seconds with generic arithmetic |
| 09:29:59 | evan | been about 20 seconds |
| 09:30:02 | headius | jruby is 2s without --fast and 1.35s with --fast |
| 09:30:11 | evan | there we go |
| 09:30:13 | evan | geez. |
| 09:30:15 | headius | slava: do I have to run duby numbers again? |
| 09:30:15 | evan | 48s |
| 09:30:24 | slava | headius: duby doesn't have generic arithmetic semantics |
| 09:30:36 | headius | duby knocks the pants off factor and looks nicer |
| 09:30:38 | headius | so there |
| 09:30:45 | headius | :) |
| 09:30:46 | evan | hah |
| 09:30:54 | slava | headius: don't make me code recursive fib in asm :) |
| 09:30:59 | evan | slava: are you type splitting? |
| 09:31:06 | slava | no |
| 09:31:12 | headius | slava: that *might* beat duby by a bit |
| 09:31:22 | headius | less guards |
| 09:32:05 | headius | macruby is about 0.53s on this |
| 09:32:12 | evan | hey guess what, you want fib(35)? it's 9227465 |
| 09:32:15 | evan | see how fast I was?! |
| 09:32:16 | headius | about the ratio I see for them on most fixnum math |
| 09:32:20 | evan | i'm better than all the rest. |
| 09:32:27 | evan | AND I tell jokes! |
| 09:32:32 | headius | now my cheer-me-up tweak |
| 09:32:37 | headius | make fib use floats |
| 09:33:03 | evan | headius: i should see what else they're doing in there |
| 09:33:10 | evan | it should be about the same as i'm doing. |
| 09:33:10 | headius | it's the recursive optz |
| 09:33:14 | headius | it's not a generally useful one |
| 09:33:16 | evan | oh right. |
| 09:33:18 | slava | you guys need to make your math ops dispatch faster |
| 09:33:19 | evan | that silly thing. |
| 09:33:26 | evan | headius: do this |
| 09:33:28 | headius | if you make it self.fib_ruby their performance falls way off |
| 09:33:29 | evan | alias your fib method to |
| 09:33:32 | evan | fib1 ond fib2 |
| 09:33:35 | evan | and call those inside fib |
| 09:33:43 | evan | to defeat the tailcall opt |
| 09:33:52 | evan | yes, i believe it's that stupid. |
| 09:33:53 | headius | just self along defeats it |
| 09:33:55 | headius | alone |
| 09:34:02 | headius | they don't do it for call, only for fcall/vcall |
| 09:34:07 | slava | wait, are you guys doing recursive fib here? |
| 09:34:11 | evan | whats the performance if you throw self. in there? |
| 09:34:13 | evan | slava: course |
| 09:34:15 | headius | but I've done the alias things too |
| 09:34:16 | evan | slava: did you do iterative? |
| 09:34:17 | slava | the only tail call there is the call to + |
| 09:34:19 | slava | evan: no haha |
| 09:34:23 | headius | macruby's not hard to defeat on most of these |
| 09:35:12 | headius | so macruby goes from 0.53s to longer than I care to wait with floats |
| 09:35:22 | evan | what about with self. ? |
| 09:35:24 | slava | my fib(35) is 14930352 |
| 09:35:26 | headius | patience |
| 09:35:28 | slava | something's wrong |
| 09:35:33 | evan | HAHAH |
| 09:35:40 | evan | thats fucking perfect |
| 09:35:41 | slava | fib(34) = 9227465 |
| 09:35:54 | slava | that takes 0.27 seconds |
| 09:35:59 | evan | maybe this algo is wrong. |
| 09:36:16 | headius | ok, 23s for fib(35.0) in macruby |
| 09:36:30 | headius | but both cores at solid 100% for that whole time |
| 09:36:41 | headius | no idea what they're doing |
| 09:36:41 | evan | slava: nope |
| 09:36:45 | evan | i'm right! |
| 09:36:45 | evan | http://www.wolframalpha.com/input/?i=fib%2835%29 |
| 09:36:53 | slava | 0.46 for fib 35 with floats in factor |
| 09:37:18 | slava | less than 2x slower than the fixnum version |
| 09:37:24 | evan | headius: what was the time with self. on fixnums? |
| 09:37:38 | slava | I WIN |
| 09:37:48 | headius | jruby is about 4.9s with float fib 35 |
| 09:37:56 | headius | ok, checking self now |
| 09:38:44 | slava | are we going to benchmark ackermann and tak soon? |
| 09:39:00 | evan | sure, if ya like. |
| 09:39:14 | headius | ok, so it was 0.53s with self-recursion optz, 23s without |
| 09:39:16 | evan | and after than, a rube goldberg machine simulator |
| 09:39:17 | headius | so basically what float was |
| 09:39:31 | headius | float would probably be unbearably slow without recursion optz |
| 09:39:37 | evan | I think I must have a GC bug |
| 09:39:44 | evan | doing 35.0 blew up the memory footprint |
| 09:39:48 | evan | so someting is a miss. |
| 09:39:49 | headius | I mentioned this on macruby list and I think I made an enemy out of laurent |
| 09:40:02 | headius | I was just curious |
| 09:40:12 | evan | which? |
| 09:40:14 | slava | headius: just detect recursive fib in your compiler and convert it to iterative |
| 09:40:16 | headius | it's a drastic change just adding self |
| 09:40:36 | evan | that they're optz doen't really translate into application performance? |
| 09:41:05 | headius | no, just that it seems like a lot of the benchmarks people are running are dependent on very specific things like self-recursion |
| 09:41:13 | headius | and wondering if they have some other benchmarks that would be better |
| 09:41:28 | headius | obviously fib is worthless for comparison because of things like this |
| 09:41:37 | headius | how often do you have a ton of self-recursion in a ruby app? |
| 09:42:00 | evan | personally thats all I do in ruby |
| 09:42:08 | headius | heheh |
| 09:42:17 | evan | write self recursive madlib geeraters |
| 09:42:21 | evan | didn't I tell you that? |
| 09:42:27 | evan | thats why I'm working on rubinius |
| 09:42:30 | evan | better, faster madlibs. |
| 09:42:38 | headius | if you write your entire program in a single method, the whole thing could be self recursive |
| 09:42:40 | headius | then macruby would win |
| 09:43:11 | headius | so I shouldn't try rbx with the float version? |
| 09:43:15 | evan | headius: what if you store the results in locals |
| 09:43:17 | evan | and then add them |
| 09:43:25 | evan | so there is no call at the very end |
| 09:43:31 | evan | does it realize that? |
| 09:43:33 | headius | there would be a call to add |
| 09:43:42 | headius | that's not really any different than current algorithm |
| 09:44:02 | evan | i just mean it seems like they're spying on the direct AST form |
| 09:44:06 | headius | hmmm |
| 09:44:09 | headius | I could try it |
| 09:44:10 | evan | so any small change changes things radically |
| 09:44:17 | evan | yeah, the float is messed up for rubinius |
| 09:44:19 | evan | have to look at it |
| 09:44:22 | headius | I didn't see any spying for the most part |
| 09:44:30 | headius | just the recursion optimization |
| 09:44:39 | evan | it's them doing it though |
| 09:44:42 | evan | not LLVM |
| 09:44:44 | headius | and I figured out how I could do it too, but it seems like it's only useful for benchmark arm-wrestling |
| 09:44:45 | evan | thats not an LLVM opt |
| 09:45:08 | headius | yeah, they're just looking at every call to see if it's a call to the same exact method |
| 09:45:16 | headius | and then having llvm skip dispatch logic |
| 09:45:28 | evan | but only if it's at the very end |
| 09:45:31 | slava | if you have inline caching a self call should be fast anyway |
| 09:45:32 | evan | or no? |
| 09:45:39 | headius | basically call_directly if lookedup_method == current method |
| 09:45:39 | evan | are they still doing a call |
| 09:45:42 | headius | doesn't have to be at end |
| 09:45:45 | evan | ah ah |
| 09:45:50 | headius | it's a static dispatch if it's the same method object |
| 09:45:52 | headius | that's all |
| 09:45:52 | evan | so they're just bypassing lookup |
| 09:45:56 | evan | i thought tehy turned it into a loop |
| 09:46:06 | evan | gotcha |
| 09:46:07 | slava | evan: a self tail call is the same as a loop |
| 09:46:07 | headius | they still check if the lookup produces the same method object though |
| 09:46:12 | evan | hey |
| 09:46:14 | evan | i could do that |
| 09:46:16 | headius | yeah |
| 09:46:19 | headius | it's not hard |
| 09:46:19 | evan | and not have it based on any forms |
| 09:46:25 | evan | i've got all that data from the ICs |
| 09:46:35 | headius | I don't understand why they only do it for fcall and vcall myself |
| 09:46:47 | headius | maybe something about how objc dispatches |
| 09:46:50 | evan | *shrug* |
| 09:46:53 | slava | what is fcall and vcall? |
| 09:47:00 | headius | for me it would be just another method wth a different receiver passed |
| 09:47:02 | evan | slava: a call without a receiver |
| 09:47:07 | evan | it means send it to self |
| 09:47:11 | evan | implicitely |
| 09:47:13 | slava | you guys and your jargon :) |
| 09:47:17 | headius | they all have receivers :) |
| 09:47:24 | headius | that's why I don't understand why it's any different |
| 09:47:30 | evan | no programmer typed receiver |
| 09:47:37 | evan | agreed. |
| 09:48:15 | headius | huh |
| 09:48:27 | headius | you're right |
| 09:48:46 | headius | assigning to locals and assigning separately does tank perf too |
| 09:49:22 | headius | I don't understand why |
| 09:49:27 | evan | because |
| 09:49:45 | evan | i'm pretty sure they're turning it into a loop |
| 09:49:58 | evan | if they see a self call at the end |
| 09:50:05 | evan | they just loop back to the top |
| 09:50:05 | headius | oh wait |
| 09:50:10 | headius | erg, I'm still running floats |
| 09:50:11 | evan | i thought I saw that in there |
| 09:50:17 | headius | nevermind everything I said for the past 15 minutes |
| 09:50:27 | evan | expunges his memory |
| 09:50:35 | headius | rough to_f |
| 09:50:38 | headius | rouge |
| 09:50:41 | headius | rogue |
| 09:50:42 | headius | whatever |
| 09:50:48 | headius | ok |
| 09:50:53 | headius | assigning to locals has no effect |
| 09:51:00 | headius | that's what I expected to see |
| 09:51:10 | evan | ok |
| 09:51:22 | evan | so ya think it's turning it into a direct call |
| 09:51:26 | headius | removing recursion optz puts it in the neighborhood of jruby --fast |
| 09:51:35 | headius | around 1.44 for them, 1.35 for us |
| 09:51:41 | headius | yes |
| 09:51:46 | evan | i wonder.... |
| 09:51:57 | headius | scan for NODE_FCALL in roxor and you'll find it |
| 09:52:21 | headius | it's basically doing if incoming_selector = current_selector; please LLVM call the function directly instead |
| 09:52:39 | headius | which causes llvm to skip the dispatch pipeline entirely if it's the same method |
| 09:52:46 | evan | right |
| 09:52:56 | evan | ok, i'm going to give myself 5 minutes |
| 09:53:00 | evan | and see if i could do the same |
| 09:53:01 | evan | just for fun. |
| 09:53:06 | headius | that's basically the cheat I did when I got fib(30) down to 0.05, which is surprisingly enough exactly what they get for fib(30) |
| 09:53:32 | headius | see I'm only insecure about this stuff when I don't know *why* someone's faster, or why they might be faster in the future |
| 09:53:38 | headius | because i've looked at this stuff inside and out |
| 09:54:06 | headius | knowing why fib is faster in macruby made me a lot more comfortable with the world :) |
| 09:54:35 | evan | :D |
| 09:55:16 | headius | my only fear right now is that I don't know how to write enough of LLVM to make jruby + JVM compete :) |
| 09:55:25 | headius | but time heals all wounds |
| 09:55:30 | evan | um... |
| 09:55:31 | evan | wtf. |
| 09:55:42 | evan | headius: try running the float bench |
| 09:55:52 | evan | see if your memory goes.. |
| 09:55:53 | headius | ok |
| 09:55:53 | evan | oh wait |
| 09:55:54 | evan | nm. |
| 09:55:56 | headius | no? |
| 09:55:58 | evan | I JUST DID THE SAME THING AS YOU |
| 09:56:01 | evan | le sigh. |
| 09:56:30 | headius | hah |
| 09:56:42 | headius | the perils of editing in place |
| 09:57:04 | headius | yeah, I wish I could get an asm dump from macruby |
| 09:57:14 | headius | it would help me sleep at night |
| 09:57:23 | headius | because I know exactly what asm is coming out of jruby |
| 09:57:37 | evan | huh |
| 09:57:45 | evan | i wonder how wolframalpha does fib |
| 09:58:13 | slava | haha |
| 09:58:15 | evan | it's near instant for any number |
| 09:58:34 | evan | http://www.wolframalpha.com/input/?i=fib%2812010%29 |
| 09:58:46 | headius | oh, is it live? |
| 09:58:48 | evan | yep |
| 09:58:55 | headius | cool, wasn't a couple days ago |
| 09:59:01 | evan | went live today |
| 09:59:35 | slava | evan: you take the matrix (1 1; 1 0) and raise it to a power n |
| 09:59:39 | slava | then the top left entry is fib(n) |
| 09:59:55 | slava | there are fast algorithms for matrix exponentiation |
| 10:00:06 | evan | to get math problems done |
| 10:00:13 | evan | i like to take matrix (42; 1; 1; 0) |
| 10:00:19 | evan | and raise it BY THE POWER OF GREYSKULL! |
| 10:00:35 | evan | thats more fun that homework |
| 10:01:00 | headius | best line in hot fuzz |
| 10:01:03 | slava | you can also do (phi^n - (1 - phi)^n)/sqrt(5) |
| 10:01:18 | slava | where phi is (1+sqrt(5))/2 |
| 10:01:25 | headius | wait, is this the math phi or the ssa phi |
| 10:01:30 | headius | I'm all confused now |
| 10:01:34 | slava | but this will have roundoff errors for large values of n |
| 10:01:47 | headius | maybe we should use klingon to clarify |
| 10:01:53 | evan | yes |
| 10:01:59 | evan | it's more poetic in the original klingon |
| 10:02:21 | headius | I guess that's actually a line from nazi germany, goebbels or something |
| 10:02:30 | headius | "shakespeare in the original german" |
| 10:03:17 | headius | wolfram doesn't know what jruby is |
| 10:03:35 | headius | and how important it is to holisitic computology |
| 10:03:42 | evan | nor rubinius |
| 10:03:44 | evan | don't feel bad. |
| 10:04:31 | evan | ok, no |
| 10:04:34 | evan | i'm not going to try to do this |
| 10:04:50 | evan | i verified that, yes, the JIT can easily detect from the ICs it's making a self recursive call |
| 10:04:59 | headius | I don't see how wolfram can ever scale |
| 10:05:01 | evan | it's a plumbing exercise after that |
| 10:05:22 | headius | maybe if it has a huge datacenter and caches like mad |
| 10:05:32 | evan | i've wondered the same thing |
| 10:05:59 | evan | http://www.wolframalpha.com/input/?i=wolfram+alpha |
| 10:06:08 | evan | I thought maybe it would tell me |
| 10:06:17 | evan | wouldn't that be awesome of them |
| 10:06:21 | headius | maybe they just want to get bought by google |
| 10:07:10 | headius | it doesn't know my salary |
| 10:07:13 | headius | what good is it to me |
| 10:07:20 | headius | even I know that |
| 10:07:48 | headius | "charles" is on a steady decline in popularity |
| 10:08:08 | evan | evan is on the up tick |
| 10:08:15 | evan | and i guess i'm one of the older ones |
| 10:09:33 | headius | wow, the curve for oliver is wacky |
| 10:09:49 | headius | my son is oliver...we did it because it was my grandfather's name |
| 10:09:56 | headius | in about 2000 |
| 10:10:08 | headius | maybe all the olivers were finally dead then and it became popular again |
| 10:10:15 | evan | hah |
| 10:11:50 | evan | that is weird |
| 10:11:50 | headius | ok, late for me |
| 10:11:51 | headius | nite |
| 10:12:05 | evan | nite |
| 18:16:22 | ddub | sometimes I get excited while reading an IRC channel's history and forget that it isn't active conversation |
| 18:16:44 | ddub | luckily, in many cases (including this one) I catch myself before I type something that makes me feel stupid |
| 18:20:09 | malumalu | ddub: you're not alone with that :) |
| 19:11:58 | evan | ddub: something from last night you want to discuss? |
| 19:18:47 | slava | hi evan |
| 19:18:53 | slava | I want to discuss something from last night |
| 19:18:54 | slava | YOUR MOM |
| 19:18:55 | evan | morning |
| 19:19:03 | evan | oh? are you reading her books? |
| 19:19:24 | evan | let me suggest some: http://www.amazon.com/s/ref=nb_ss_gw?url=search-alias%3Daps&field-keywords=lise+mcclendon& x=0&y=0 |
| 19:23:10 | slava | cool |
| 19:23:30 | evan | theres swearing and murder in them |
| 19:23:34 | evan | if you're into that kind of thing |
| 19:41:06 | evan | headius: morning |
| 19:41:14 | headius | howdy |
| 19:41:16 | evan | headius: i'm poking around in the macruby code |
| 19:41:22 | evan | found some pretty funny stuff |
| 19:41:23 | headius | oh? |
| 19:41:35 | evan | i'm sure it's just "we need this to work now" stuff |
| 19:41:38 | evan | but funny none the less |
| 19:41:48 | evan | like, when it looks up to call a method |
| 19:42:00 | evan | it looks in the ObjC method tables |
| 19:42:26 | evan | and then passes the result to be looked up in a STL map! |
| 19:42:34 | evan | to find out if it's a ruby method of an ObjC method |
| 19:42:49 | evan | so the more methods the system gets, the slower lookup becomes |
| 19:42:51 | headius | that's on latest experimental branch stuff? |
| 19:42:55 | evan | yep |
| 19:43:36 | evan | they're dispatch to method_missing is buried behind a whole bunch of code too |
| 19:43:45 | evan | so anything that uses it is going to be taking the slow boat to china |
| 19:44:23 | headius | yeah, I guess my biggest curiousity is how they're going to continue along this path |
| 19:44:39 | evan | oh actually, this code is only being run when the cache is empty |
| 19:44:40 | evan | ok, nm. |
| 19:44:50 | evan | so they really need the caches |
| 19:44:58 | evan | because they've had to inject a lot more work in refilling them |
| 19:44:59 | headius | for polymorphic calls performance really goes down |
| 19:45:05 | evan | bigtime |
| 19:45:21 | headius | and basically anything that has real objects is much slower |
| 19:46:06 | evan | weird |
| 19:46:13 | evan | they've got a lot of strange workarounds |
| 19:46:28 | evan | like the spy on calling #new inside the dispatch function |
| 19:46:50 | evan | er. #class, not #new |
| 19:47:23 | evan | funny. |
| 19:48:34 | headius | yeah, I have been watching their updates for a while |
| 19:49:21 | headius | obviously their compiler is promising, but they're really going to have to speed up all the core types |
| 19:50:02 | evan | I guess the upside for them is that when they find ObjC is in their way |
| 19:50:06 | evan | they just schedule a meeting |
| 19:53:45 | evan | I guess I hope the macruby guys don't think we're picking on them. |
| 19:56:34 | headius | they do |
| 19:56:49 | headius | but there's also rampant fanboyism going on over there |
| 19:57:11 | headius | experimental branch barely runs and it's become the second coming of Ruby for a bunch of people |
| 19:57:32 | evan | i'm still mostly ignoring taht |
| 19:57:42 | evan | i'm just interested in their approach |
| 19:57:49 | evan | and how they're tackling certain problems |
| 19:58:26 | evan | I think that that post by the macruby intern rubbed you (and I) the wrong way |
| 19:58:34 | evan | saying that there was no way we'd ever beat MacRuby |
| 19:59:22 | headius | yeah, like I mentioned last night, the macruby perf numbers only bothered me when I didn't know how they achieved them |
| 19:59:39 | evan | right |
| 19:59:42 | headius | they don't bother me as much now, except where they mean we'll need to do more work to actually optimize our compiler |
| 19:59:47 | evan | they're the shiny spot welds in a half finished plain |
| 19:59:48 | headius | which will be fun anyway |
| 19:59:49 | evan | plane |
| 20:00:17 | evan | i guess i'd hope they'd adopt the attitude you and I have |
| 20:00:28 | evan | which is a healthy rivalry :D |
| 20:00:42 | headius | I guess what bugged me about rbx in the beginning, what bugged me about maglev in the beginning, what bugged me about macruby experimental in the beginning, is the early belittling of other efforts |
| 20:00:49 | evan | combined with comrodery |
| 20:00:57 | headius | like "oh, they must not have known how to make things fast...I'm going to do so much better" |
| 20:01:08 | evan | right |
| 20:01:11 | headius | that just seems insulting to me |
| 20:01:20 | evan | well, i've never meant to bilittle any other efforts |
| 20:01:32 | headius | no, most of the time it's unintentional |
| 20:01:47 | headius | underestimating how much work will actually be necessary based on early successes |
| 20:01:49 | headius | I do the same too |
| 20:02:01 | evan | thats part of the rivalry |
| 20:02:12 | evan | if we didn't think we were doing something worthwhile |
| 20:02:15 | headius | "I got fib running fast, I'll probably have Rails running that fast in a couple months" |
| 20:02:16 | evan | we wouldn't be doing it :) |
| 20:02:22 | evan | hah |
| 20:02:26 | evan | yeah, wouldn't THAT be great. |
| 20:02:43 | headius | crosstwine was another new entry, but he's been really mild about it |
| 20:02:51 | headius | I even tried to bait him |
| 20:03:11 | evan | oh? |
| 20:03:12 | evan | looks |
| 20:03:50 | evan | so, should we publish our fib results? |
| 20:03:54 | evan | saying we're 10x faster? |
| 20:03:55 | evan | :D |
| 20:04:10 | headius | yeah, I don't remember what I said, but he was pretty accepting that there was a lot more work, not all apps would optimize so well, his stuff did nothing to improve core classes and so on |
| 20:04:23 | headius | hah |
| 20:04:34 | headius | I suppose it's techies failing too |
| 20:04:52 | headius | that they extrapolate from the specific to the general almost immediately |
| 20:05:06 | evan | right |
| 20:05:12 | evan | techies have big imaginations |
| 20:05:17 | evan | and VM/compiler work is hard |
| 20:05:38 | evan | big improvements to small forms of code does not scale automatically |
| 20:05:52 | evan | like making fib fast != rails fast |
| 20:05:55 | headius | heheh |
| 20:06:17 | headius | I suppose what I've been trying to do recently is latch on to what makes jruby unique, since it's obvious it won't always be performance |
| 20:06:36 | headius | like the fact that our core classes are way faster than anyone else's, JVMs are everywhere, etc |
| 20:06:49 | headius | not particularly flashy stuff, not as flashy as a ruby-based core, for example |
| 20:06:51 | evan | i'm sure thats good for your sanity |
| 20:06:55 | headius | yeah |
| 20:06:59 | evan | since i'm never going to say "JVM intergration!" |
| 20:07:10 | evan | but then you have to deal with the groovy/scala crowds |
| 20:07:10 | headius | nobody will be able to provide the full jruby story, so no matter what we'll be ok |
| 20:07:13 | headius | yeah |
| 20:07:18 | headius | so many battles :) |
| 20:07:24 | headius | scala guys are less of an issue |
| 20:07:31 | headius | most people I know that use scala use jruby too |
| 20:07:41 | headius | groovy on the other hand seems to be an island |
| 20:08:19 | headius | anyway...bbl |
| 20:56:46 | ddub | evan: you should just hardwire functions named 'fib' in rubinius |
| 20:57:08 | ddub | have a fib opcode |
| 20:58:16 | ddub | maybe just build in a lookup table for the first 4k numbers in the fib sequence :) |
| 21:01:56 | brixen | ddub: you should just prove that SSA <-> CPS <-> fib(n) for the space of all relevant programs |
| 21:02:16 | brixen | then well compose fib() and just have one opcode |
| 21:02:32 | brixen | we'll* |
| 21:51:12 | evan | sounds good! |
| 21:51:22 | evan | ok, so lets pick the top 10 trivial benchmarks |
| 21:51:29 | evan | and reimplement them as bytecodes |
| 21:51:56 | evan | --ultra-benchmark mode |
| 21:52:06 | brixen | heh, win! |
| 21:53:42 | evan | we'll have it pop up a window with the ultra bencmark assistant |
| 21:53:51 | evan | "It looks like you're trying to write fib(), let me help with that." |
| 21:54:48 | brixen | oh man, that would make a sweet screencast |
| 21:55:06 | brixen | "rubinius helps you write performant code..." |
| 21:56:22 | evan | "It looks like you're trying to sort an array, might I suggest a log(n) algorithm?" |
| 22:11:26 | ddub | "You appear to be trying to write a web 2.0 app, shall I help you find VC funding?" |
| 22:12:48 | evan | hah |
| 22:13:42 | evan | yay |
| 22:13:47 | evan | fixed the memory runaway |
| 22:14:18 | boyscout | Check interrupts at the top of every JITd function - 16524e9 - Evan Phoenix |
| 22:14:33 | evan | fib(35.0) in 13s |
| 22:16:22 | brixen | rockin |
| 22:16:40 | evan | now for another tweak... |
| 22:21:16 | boyscout | CI: 16524e9 success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 22:21:23 | evan | hm, darn |
| 22:21:42 | evan | need to reorganize a little to add an IC to send_op_plus |
| 22:23:18 | brixen | ok, meter is up, bbiab.. |
| 22:24:24 | evan | time to clean up the condo a bit. |