Da
Show enters and exits. Hide enters and exits.
| 00:00:03 | evan | need to just introduce a simple way to do the check |
| 00:01:23 | evan | MRI is 2.77 for this |
| 00:01:28 | evan | I should note. |
| 00:07:12 | HaPK | brixen: it didn't help... installed ruby 1.8.7-p160 from ports and it still behaves improperly |
| 00:09:00 | brixen | HaPK: not sure how to solve it, rbx is behaving correctly when invoked correctly |
| 00:10:20 | HaPK | brixen: did a simple test ruby file that just calls "exec" with proper params to call mspec/bin/mspec-run and it works ok |
| 00:10:55 | dgtized | evan: which benchmark is that, on bm_array_each I'm seeing we were already faster then MRI |
| 00:10:58 | HaPK | brixen: so, the problem seems to be in mspec runner code |
| 00:12:20 | brixen | HaPK: could be, but I can't repro it, so you'll have to dig some more |
| 00:13:25 | brixen | I wonder why no one else has reported this |
| 00:13:38 | brixen | I'm sure folks have custom installs of mri |
| 00:14:41 | brixen | HaPK: you should try to trace the exec args through |
| 00:16:08 | HaPK | brixen: I have commented out entire spec/default.mspec and run "bin/mspec ci -B full"... Many tests fail because of some libraries weren't found, but profiler doesn't show up |
| 00:16:26 | HaPK | brixen: seems like the problem is in that settings file |
| 00:16:45 | HaPK | brixen: or the spec/custom/util/script.rb |
| 00:17:24 | headius | brixen, evan: that guy updated http://jira.codehaus.org/browse/JRUBY-3646 with information about where he ran into the clone/uniq/etc issue |
| 00:17:26 | headius | fyi |
| 00:17:42 | HaPK | brixen: ah.. no.. it's just rbx wasn't called |
| 00:17:45 | evan | dgtized: hm, one sec. |
| 00:20:20 | rue | HaPK: By the by, that is not exactly _vanilla_ :P |
| 00:20:32 | rue | (Not that Apple's is, but hey) |
| 00:20:45 | brixen | headius: ah cool, thanks |
| 00:26:09 | dgtized | evan: also I just remembered, we are still doing two array bounds checks for every call to Array#at, one in the Array primitive, and then a second one in the Tuple primitive |
| 00:29:41 | evan | probably |
| 00:30:01 | evan | but it's never been shown that that is a reason we're slow |
| 00:31:39 | dgtized | no I suppose not -- if you profile an array#each benchmark though Array#at is still pretty high on the list |
| 00:32:01 | dgtized | so since it's a multiplier on the cost of the access ... |
| 00:32:17 | evan | but that doesn't say anything about the cost of checking the bounds |
| 00:32:34 | evan | i've changed Array#each locally here to get at @tuple directly |
| 00:32:38 | evan | rather than going through Array#at |
| 00:32:41 | dgtized | k |
| 00:32:52 | dgtized | that would help too |
| 00:32:55 | evan | because then I can have the JIT inline the code for Tuple#at directly into each |
| 00:33:14 | evan | the code for Tuple#at, btw, is one x86 instruction :D |
| 00:33:32 | dgtized | at present or in the JIT? |
| 00:33:35 | slava | evan: now try to get it down to 0 in some cases |
| 00:33:37 | evan | in the JIT |
| 00:33:44 | evan | slava: :D |
| 00:33:50 | dgtized | ok, well then that means the JIT is addressing my concerns on this |
| 00:34:24 | dgtized | because presently it's a bounds check followed by the dereference |
| 00:34:58 | evan | i don't yet have the JIT performing the bounds check |
| 00:35:01 | evan | so i still need to add that |
| 00:35:11 | evan | but by inlining, it should be able to it better |
| 00:35:14 | slava | planning on doing bounds check elimination? |
| 00:35:27 | evan | we'll see |
| 00:35:29 | evan | it's low on the list |
| 00:35:35 | evan | we'll see what LLVM can do without me trying |
| 00:35:42 | evan | it's pretty fucking smart |
| 00:45:49 | HaPK | Have figured out some facts about problems with mspec: mspec calls rbx with absolute path to mspec-ci or mspec-run files. And rbx complains (exceptions, etc). If change it to pass path relative to rubinius directory, then exceptions are not raise, but the profiler is still active. |
| 00:46:19 | HaPK | brixen: any ideas ? |
| 00:46:59 | headius | I'm curious how well llvm will help cases that aren't obviously monomorphic or that are polymorphic |
| 00:47:09 | HaPK | brixen, seems it still a problem with rbx, not mri |
| 00:47:13 | headius | macruby does great on monomorphic call performance, but it's slower than 1.9 on things like richards |
| 00:47:58 | HaPK | brixen: tried manually running "bin/rbx /full/path/to/mspec/bin/mspec-ci" - exceptions... if run like "bin/rbx mspec/bin/mspec-ci" - no exceptions |
| 00:54:47 | HaPK | evan: I have traced a problem |
| 00:55:11 | evan | oh? |
| 00:55:14 | HaPK | evan: seems that rubinius doesn't like directories with capital letters |
| 00:55:24 | evan | thats weird |
| 00:55:32 | evan | whats the directory in question? |
| 00:55:34 | HaPK | evan: I started with "bin/rbx mspec/bin/mspec-ci" |
| 00:55:51 | evan | whats the whole directory? |
| 00:55:58 | HaPK | evan: that worked... then I did "bin/rbx ../rubinius/mspec/bin/mspec-ci" |
| 00:56:03 | evan | smells a facepalm upcoming |
| 00:56:32 | HaPK | evan: that worked too... but when I went one directory upper (which is Projects) - it blowed |
| 00:56:55 | evan | i need the EXACT cli you used. |
| 00:56:58 | HaPK | evan: when I renamed Projects to projects, it began to work |
| 00:57:18 | HaPK | evan: "bin/rbx ../../Projects/rubinius/mspec/bin/mspec-ci" |
| 00:57:28 | HaPK | evan: that didn't work |
| 00:57:36 | evan | brixen brixen brixen |
| 00:57:47 | evan | you're gonna slap yourself in the face. |
| 00:57:59 | evan | i see the exact problem. |
| 00:58:00 | HaPK | evan: this worked: "bin/rbx ../../projects/rubinius/mspec/bin/mspec-ci" (after renaming to lowercase projects) |
| 00:58:06 | evan | and it's pretty funny. |
| 00:58:18 | evan | ok |
| 00:58:19 | evan | hold on |
| 00:58:22 | evan | pushing a fix. |
| 01:00:15 | evan | ok, compiling to double check. |
| 01:00:22 | evan | shouldn't be but another minute |
| 01:00:56 | HaPK | evan: so, what was the problem ? |
| 01:01:03 | evan | you'll see |
| 01:01:07 | evan | i don't want to ruin the surprise! |
| 01:01:12 | HaPK | =) |
| 01:01:39 | HaPK | evan: did you have a chance to get a repro ? |
| 01:01:49 | evan | no |
| 01:01:50 | evan | but no need. |
| 01:01:52 | HaPK | ok |
| 01:01:59 | evan | you'll see why. |
| 01:02:14 | HaPK | I'm excited =) |
| 01:02:14 | evan | this underscores another issue that we need to fix soon |
| 01:02:27 | evan | INCOMING |
| 01:02:28 | boyscout | Only check for P if it's followed by - at the beginning - e737ebe - Evan Phoenix |
| 01:02:34 | evan | check that diff |
| 01:02:37 | evan | it's pretty hilarious. |
| 01:03:39 | HaPK | huh =)))) |
| 01:04:01 | HaPK | so, my profiler problems should automagically go away ? |
| 01:04:12 | evan | yep |
| 01:04:46 | boyscout | CI: e737ebe success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 01:05:15 | HaPK | evan: does rubinius' build system support incremental builds ? |
| 01:05:25 | evan | sure |
| 01:05:27 | HaPK | evan: or should I do disclean ? |
| 01:05:27 | evan | rake build |
| 01:07:23 | dgtized | evan: do we do custom command parsing for a reason or would it be worthwhile to switch that to OptParse or the like? |
| 01:07:55 | evan | you can't use optparse there |
| 01:07:59 | evan | it's too early |
| 01:08:06 | evan | you can't load anything in there. |
| 01:08:13 | evan | thats why. |
| 01:09:47 | dgtized | we do requires in the options, I guess it would clober our namespace though |
| 01:10:10 | evan | in the options? |
| 01:10:36 | dgtized | the first thing that happens in the task you just fixed is a require 'profile' |
| 01:10:50 | evan | oh that |
| 01:11:02 | evan | well, thats actually late enough to do a require |
| 01:11:19 | dgtized | oh late enough in listing of options? |
| 01:11:25 | evan | using optparse or some big, heavy library to parse the options is out of the question |
| 01:11:29 | evan | sorry. |
| 01:11:37 | evan | a small, light library, perhaps. |
| 01:12:54 | dgtized | I was just thinking something a little more robust, and perhaps something that generated the doc string side by side |
| 01:13:09 | evan | no frameworks. |
| 01:13:09 | dgtized | cause i think our doc string keeps getting slightly out of tune with the list of options |
| 01:13:20 | evan | this is at a level where we must have simplicity. |
| 01:13:31 | HaPK | evan: yay, it works! |
| 01:13:46 | evan | HaPK: yay! |
| 01:13:53 | dgtized | not even just walking through a list of [name, doc_string, block] tuples? |
| 01:14:18 | evan | that might be ok. |
| 01:15:15 | dgtized | also, shouldn't technically all of the match operators check to make sure they are at the beginning of the match? |
| 01:15:26 | evan | there are no others |
| 01:15:38 | dgtized | oh i see |
| 01:15:47 | dgtized | nm, I wasn't catching that was the only regex |
| 01:16:16 | dgtized | I guess I should change emacs to make regex's a different color then string constants |
| 01:16:24 | dgtized | that would help the regex stand out a little |
| 01:17:25 | evan | :D |
| 01:27:01 | headius | hmm |
| 01:27:07 | headius | #rubyspec is dead quite |
| 01:27:10 | headius | quiet |
| 01:27:15 | headius | what's with these specs with "hash_class" in them |
| 01:27:22 | headius | like core/hash/allocate_spec.rb |
| 01:27:33 | headius | they don't work in MRI |
| 01:27:35 | headius | there's dozens of them |
| 01:27:38 | evan | they're so brixen could test multiple classes that ack like Hash together |
| 01:27:46 | headius | is this some mspec update required? |
| 01:27:55 | evan | perhaps |
| 01:28:06 | headius | I don't get how to run these |
| 01:28:42 | evan | i think brixen made it pretty easy |
| 01:28:45 | evan | not sure where he's at atm. |
| 01:28:46 | headius | must be mspec update, that seemed to get them to run |
| 01:28:54 | headius | weird though...mspec is defining things like "hash_class" now? |
| 01:29:05 | evan | *shrug* |
| 01:30:36 | headius | it's always jarring when I go to update specs and there's 100 failures suddenly |
| 01:31:08 | evan | me too |
| 01:31:14 | evan | but i don't see them as often |
| 01:31:17 | evan | because of the CI set |
| 01:31:20 | evan | it's a blessing and a curse. |
| 01:31:23 | headius | we have a CI set as well |
| 01:31:36 | headius | but it includes almost everything in core |
| 01:31:48 | headius | well, it includes everything in core |
| 01:31:58 | headius | so anything new I have to examine and tag |
| 01:32:04 | evan | mmm |
| 01:32:10 | evan | this code is looknig sweet. |
| 01:32:38 | evan | the JIT now inlines the Tuple#at primitive and uses a proper guard |
| 01:32:40 | evan | yay yay |
| 01:32:50 | ezmob | swanky |
| 01:34:06 | headius | evan: how are you deciding to inline it? |
| 01:34:23 | evan | personal knowledge atm. |
| 01:34:28 | evan | it's NOT sophisticated. |
| 01:34:38 | evan | 0x2b8020c cmp $0x36, %edx 0x2b8020f jnz 0x242 ; 0x2b80252 0x2b80215 and $0x7ffffffe, %ecx 0x2b8021b mov 0x10(%eax,%ecx,2), %eax |
| 01:34:40 | headius | can you elaborate on that? |
| 01:34:41 | evan | ack. |
| 01:34:47 | evan | sure |
| 01:34:59 | evan | we've got a number of core types |
| 01:35:03 | evan | Tuple, ByteArray, etc. |
| 01:35:23 | evan | with all the highlevel classes using them |
| 01:35:38 | evan | so it follows that the highlevel class performance is derived directly from the lowlevel class performance |
| 01:35:52 | evan | plus, the lowlevel classes only have a small number of fundemental operations |
| 01:36:02 | evan | in Tuple's case, #at, #put, #size |
| 01:36:25 | evan | for ByteArray, #get_byte, #set_byte, #size |
| 01:36:32 | headius | sure |
| 01:36:39 | evan | that being a small, very frequently used set |
| 01:36:49 | evan | it's easy to make the JIT knowledge about those 6 operations |
| 01:37:21 | evan | so the contents of inline caches provide type feedback |
| 01:37:45 | evan | allowing the JIT to, in those 6 methods cases, put the code to perform them directly in the calling stream |
| 01:38:23 | headius | ahh, so you're using the inline cache to know if it's the core version |
| 01:41:47 | evan | yep |
| 01:41:55 | headius | so it still has a guard then, what are you guarding? |
| 01:41:55 | evan | trixy huh |
| 01:41:56 | evan | :D |
| 01:42:11 | evan | in these 6 cases |
| 01:42:12 | headius | yeah, I have some of that in our compiler too, but not turned on |
| 01:42:14 | headius | it helps a little |
| 01:42:16 | evan | the type_id of the object |
| 01:42:34 | headius | so not checking for override because you assume nobody will ever do such a thing |
| 01:42:34 | evan | which means you can't change those 6 things |
| 01:42:35 | evan | but thats ok |
| 01:42:45 | evan | right |
| 01:43:00 | evan | if we want to allow for changing, that can be in the guard too |
| 01:43:25 | headius | yeah, just more overhead |
| 01:44:00 | evan | yep |
| 01:45:16 | headius | well cool |
| 01:45:39 | headius | that ought to help some of the lower-level operations a lot |
| 01:45:43 | evan | yep |
| 01:45:52 | evan | from talking with john rose |
| 01:46:05 | evan | i'm pretty sure this is what hotspot does for a number of things to |
| 01:46:13 | evan | basically, intrinsic methods |
| 01:46:22 | headius | there's quite a few intrinsics, yes |
| 01:46:31 | headius | System.arraycopy for example |
| 01:46:57 | headius | but it also aggressively inlines jitted java bodies the same way of course |
| 01:47:09 | evan | course |
| 01:47:18 | evan | but, nicely, i can do this in phases |
| 01:47:30 | headius | yeah |
| 01:47:32 | evan | carving out performance in phases |
| 01:48:09 | headius | I saw MRI equivalent performance is the current target on the roadmap |
| 01:48:11 | headius | is that for 1.0? |
| 01:48:12 | evan | i'm going to add a background compiling thread |
| 01:49:10 | evan | to reduce the compiler interfering with perfromance too much |
| 01:49:18 | evan | ironically, now is a great time to do that |
| 01:49:24 | evan | since almost everyone has multiple cores |
| 01:49:58 | headius | yeah, JVM has a compiler thread |
| 01:50:26 | headius | plus some metrics for how much time you want it to spend compiling |
| 01:50:50 | headius | generally you don't see any perf hit when it compiles as a result |
| 01:51:09 | headius | my compiler is still in line...I suppose I could shunt it to another thread but it's pretty fast |
| 01:51:26 | headius | maybe it will be slow enough we'll want to do that once we start optimizing |
| 01:51:59 | evan | thats quite interesting |
| 01:52:08 | evan | that the interpreter performance doesn't dip when the compiler kicks in |
| 01:52:16 | headius | at least I've never noticed |
| 01:52:20 | evan | sure |
| 01:52:25 | evan | thats good enough for me! |
| 01:52:37 | headius | it's hard to tell when it does the compile |
| 01:52:54 | headius | if you turn on assembly dumping there's shit streaming out from the start |
| 01:52:57 | evan | do you know what metrics it uses to determine when it should compile a method? |
| 01:53:10 | headius | not all of them....there's a lot |
| 01:53:17 | evan | ah |
| 01:53:35 | evan | i suspect i'll need at least 2 to begin with |
| 01:53:39 | evan | # of invocations |
| 01:53:45 | evan | and # of backward of branches |
| 01:54:25 | evan | on the long term roadmap is side entrace/exit |
| 01:54:32 | evan | to allow for on-stack replacement |
| 01:54:41 | evan | but i highly doubt that will happen any time soon |
| 01:55:31 | headius | yeah, I understand that's a bit trickier |
| 01:56:11 | headius | any more thoughts on removing the GIL yet? I didn't see it on the roadmap |
| 01:56:28 | evan | yeah, that didn't make the roadmap |
| 01:56:34 | evan | i'm guess we'll wait until after 1.0 |
| 01:56:52 | evan | because removing now won't make performance better |
| 01:56:59 | evan | and will only make our 1.0 timeline longer |
| 02:01:38 | evan | atduskgreg: hey there greg |
| 02:01:56 | atduskgreg | evan: hey |
| 02:01:59 | evan | and nicksieger |
| 02:02:35 | nicksieger | hey |
| 02:02:37 | evan | atduskgreg: hows the AVR port going? |
| 02:03:02 | atduskgreg | evan: haven't done too much on it since railsconf, but hoping to put some hours in this weekend |
| 02:03:12 | evan | nice |
| 02:03:29 | evan | been doing a lot of LLVM |
| 02:03:35 | atduskgreg | cool |
| 02:04:12 | atduskgreg | evan: in the meantime I've been working on an epic blog post introducing the avr-gcc/arduino internals for noobs |
| 02:04:29 | evan | can't wait to read it |
| 02:04:32 | evan | i saw your tweet about it |
| 02:04:42 | atduskgreg | cool |
| 02:05:04 | atduskgreg | I'll ping you when I put it up |
| 02:05:53 | atduskgreg | I want to get smarter-than-me eyes on it to make sure I'm not sending people down wrong avenues at whatnot |
| 02:06:57 | evan | sure |
| 02:07:13 | evan | not that i'm smarter-than-you :) |
| 02:08:14 | atduskgreg | I'm pretty sure :) |
| 02:16:56 | boyscout | Add flow control instructions and a bunch more - 6a660c1 - Evan Phoenix (llvm-jit) |
| 02:16:56 | boyscout | Inline cache, Tuple#at snooping - a3fcc31 - Evan Phoenix (llvm-jit) |
| 02:37:19 | evan | http://gist.github.com/112016 |
| 02:37:25 | evan | Running the JIT on Array#each |
| 02:37:29 | evan | dgtized: ^^ |
| 02:37:38 | evan | i have our Array#each almost 2x slower currently than MRI |
| 02:42:02 | slava | room for improvement :-) |
| 02:49:08 | tarcieri | weird |
| 02:49:15 | tarcieri | stackless python's channels are synchronous |
| 02:49:26 | tarcieri | sending to a channel on Rubinius won't ever block the sender, right? |
| 02:49:38 | evan | tarcieri: nope |
| 02:49:44 | evan | tarcieri: the channel buffers values |
| 02:49:46 | tarcieri | yeah, in stackless python it does |
| 02:49:49 | tarcieri | strange |
| 02:49:50 | evan | so the sender never blocks |
| 02:49:58 | tarcieri | asynchronicity ftw |
| 02:49:59 | tarcieri | heh |
| 03:19:50 | ddub | evan: does a channel have a max buffer size or does it infinitely buffer? |
| 03:22:33 | evan | infinite |
| 03:25:24 | ddub | building llvm and rubinius at the same time |
| 03:25:31 | ddub | I'm surprised my notebook still lets me type :) |
| 03:28:30 | ddub | oh wait, now the heat is stopping me |
| 03:32:43 | headius | Rubinius and LLVM: So Hot Together! |
| 03:37:58 | ddub | apple makes their new machines out of aluminum so that the heat won't discolor and warp them |
| 03:38:46 | ddub | well, thats interesting |
| 03:38:46 | ddub | Resolv#getaddresses resolves localhost FAILED |
| 03:39:17 | slava | why did they name a class Resolv? |
| 03:40:00 | ddub | the E is silent? |
| 03:40:23 | ddub | /etc/resolv.conf |
| 03:41:32 | headius | I've always wondered why there's no e |
| 03:41:40 | tarcieri | slava: pretty much everything dealing with I/O or networking kinda sucks in Ruby |
| 03:45:34 | headius | the new MBP stays pretty cool no matter what |
| 03:48:18 | ddub | I've been told my 28 month old MBP is 'ancient' |
| 03:50:29 | tarcieri | heh |
| 03:50:41 | tarcieri | my macbook is about that old |
| 04:27:23 | ddub | I've put all technology purchases (other than replacements for broken devices) on hold until USB 3 is out |
| 04:29:13 | slava | I'm waiting for itanium to take off |
| 04:32:49 | ddub | I also want to skip SSD and go straight to holographic storage |
| 04:37:44 | tarcieri | lol slava |
| 04:52:30 | ddub | whats this roadmap task to split the compiler nodes out into files? won't that be like eighty files? |
| 06:27:33 | evan | slava: poke |
| 10:09:44 | evan | ha ha! |
| 10:09:46 | evan | success! |
| 10:09:57 | evan | dropped 2 seconds off the Array#each benchmark |
| 10:10:05 | evan | it's now a full second below MRI |
| 10:24:21 | danlucraft | evan: woo! |
| 10:24:35 | danlucraft | evan: is that with llvm? |
| 10:24:53 | evan | partly, yes. |
| 10:25:05 | evan | partly reorganizing how blocks get their arguments |
| 10:25:37 | danlucraft | maybe I'll try and build again today |
| 10:36:17 | kronos_vano | evan, where I can find this benchmark? |
| 10:36:26 | boyscout | Add config option to control JIT debug output - 6cd5d3d - Evan Phoenix (llvm-jit) |
| 10:36:26 | boyscout | Minor Array#each refinement - ea9fb94 - Evan Phoenix (llvm-jit) |
| 10:36:26 | boyscout | Remove redundent ways of calling a Block - ef3dc0c - Evan Phoenix (llvm-jit) |
| 10:36:26 | boyscout | Remove generating a function per opcode - 4bce6a1 - Evan Phoenix (llvm-jit) |
| 10:36:26 | boyscout | Remove cruft - 827b0e3 - Evan Phoenix (llvm-jit) |
| 10:36:26 | boyscout | Rework how blocks get their arguments - 33ffdf3 - Evan Phoenix (llvm-jit) |
| 10:36:28 | boyscout | Further revise block arg protocol - 49572e8 - Evan Phoenix (llvm-jit) |
| 10:36:31 | evan | it's benchmark/rubinius/bm_array_each.rb |
| 10:37:03 | evan | you'll need svn llvm, soft linked into external_libs |
| 10:37:14 | evan | and applied with http://github.com/evanphx/llvm-patches/blob/master/jit-info.diff |
| 10:37:18 | evan | if you wanna try it |
| 10:37:29 | evan | tomorrow and try and clean up the build process in this branch |
| 11:13:41 | rue | The patch does not apply to trunk SVN |
| 11:13:48 | rue | Unless you changed it since yesterday |
| 11:39:49 | rue | Or, well, HEAD |
| 17:31:01 | rue | Hm, actually, it does not apply cleanly on that revision either o.O |
| 17:34:49 | rue | What is gen/types.cpp? |
| 18:40:28 | marcandr | brixen: do you know the reason why Array.== uses "i = 0, while (i<size) cur =at (i); ...; i+=1" instead of each_with_index? |
| 18:41:17 | dgtized | marcandr_: I do |
| 18:41:34 | dgtized | try doing a benchmark on each_with_index versus a manual loop |
| 18:41:47 | marcandr | Oh, ok. |
| 18:42:05 | dgtized | now that said we may be able to switch them back if evan's fancy JIT stuff inlines all that |
| 18:42:10 | marcandr | A manual loop will aslo win against a for loop? |
| 18:42:22 | dgtized | for just calls each last I checked |
| 18:42:31 | dgtized | well not quite, but essentially |
| 18:42:34 | marcandr | k |
| 18:42:43 | marcandr | Thanks. I'll leave them as is then. |
| 18:43:04 | dgtized | it's because there is an performance hit from use of yield |
| 18:43:18 | marcandr | I'll just change what I know for sure can be optimized. |
| 18:43:30 | dgtized | well run the array specs on them |
| 18:43:39 | dgtized | and see if it makes it better or worse |
| 18:43:45 | dgtized | sorry, not specs, the benchmarks |
| 18:44:00 | marcandr | Nah, I'll just fix the recursive stuff. |
| 18:45:19 | dgtized | just check to see if running benchmark/rubinius/bm_array is slower or faster on a given change |
| 18:45:31 | dgtized | speaking of which that needs to be seperated into 186 / 187 as well i think |
| 18:46:06 | marcandr | Well, not really. I mean the old behavior (and the current one too!) is more a bug than a feature. |
| 18:46:25 | marcandr | rbx is already using recursion guards which are not present in MRI 1.8.6 |
| 18:47:24 | marcandr | I'm just applying my MRI patch to rbx. It doesn't change anything for non-recursive arrays and hashes. |
| 18:53:44 | rue | Just a quick note: I am of the opinion that Array method implementations should not be using any Enumerable methods |
| 18:53:53 | rue | I think there was disagreement about the matter then |
| 18:54:44 | evan | thats probably a sensible statement |
| 18:54:50 | marcandr | rue: Haven't thought of that, but I think I see your point. I'm not changing anything major, just the way recursive guards are applied |
| 18:54:55 | evan | it's more performant, and more stable |
| 18:55:30 | evan | using too many enumerable methods internally easily breeds strange behaviors when people get crazy |
| 18:55:34 | evan | and they will get crazy |
| 18:55:42 | brixen | evan: nice um catch on that regexp :) |
| 18:55:47 | evan | brixen: :D |
| 18:55:51 | evan | thought you'd like that |
| 18:55:54 | brixen | yeah |
| 18:55:57 | marcandr | Yeah, I can imagine. |
| 18:56:31 | marcandr | I'm porting http://redmine.ruby-lang.org/issues/show/1448 to rbx is all. I won't change much, promised :-) |
| 18:58:51 | rue | Waaaait |
| 18:58:56 | dgtized | rue: each is not technically enumerable it's what enables enumerable to operate on array, but in general for the base classes, simple and in class is sometimes perferable to a slow DRY solution |
| 18:59:59 | marcandr | rue: me? |
| 19:00:23 | rue | dgtized: I am just philosophically opposed to Array relying on Enumerable |
| 19:00:39 | rue | marcandr_: Well, sort of you. That bug is what I am trying to figure out |
| 19:00:52 | marcandr | lol |
| 19:01:04 | dgtized | rue: yea I agree with that |
| 19:01:49 | marcandr | rue: What do you mean? You are trying to figure out how to solve recursive comparison or what I've done? |
| 19:02:10 | rue | So it is saying that `x.should == [[x]]`? |
| 19:02:36 | marcandr | rue: Yep. Can you point me to a difference? |
| 19:03:15 | marcandr | By difference I mean x[0][2] being different than y[0][2], for example. |
| 19:04:05 | marcandr | Or x[0][0] not having the same length as y[0][0] or something. If you can't find any difference, then I claim they are == |
| 19:04:40 | evan | perhaps we should have an easter egg |
| 19:04:43 | evan | if you do |
| 19:04:49 | evan | x = []; x << x; p x |
| 19:04:53 | evan | it displays |
| 19:04:59 | evan | #<Blackhole> |
| 19:04:59 | rue | GFOOH? |
| 19:05:18 | rue | Hm, OK, maybe #<Blackhole> is more polite |
| 19:05:29 | evan | well, we could have it run |
| 19:05:32 | evan | system("nethack") |
| 19:05:33 | evan | too |
| 19:05:50 | brixen | heh, #<I have taken your computer and your are not getting it back> |
| 19:06:02 | brixen | -r |
| 19:06:36 | evan | >> p x |
| 19:06:44 | evan | Calculating answer, get some coffee... |
| 19:07:11 | rue | evan: No--we should implement it *iteratively* :D |
| 19:08:03 | evan | how about pop up a picture of someone taking a picture into a mirror with a mirror behind them |
| 19:08:31 | evan | I wonder what humanity thought the first time they saw that |
| 19:08:41 | evan | OMG INFINITY |
| 19:09:35 | marcandr | Xenon thought it was funky as hell |
| 19:11:23 | rue | marcandr_: There is no access difference if there is only a single element |
| 19:14:59 | marcandr | rue: access difference? |
| 19:17:26 | rue | `x = [1]; x << x; y = [[x]]; y[1] != x[1]` |
| 19:17:49 | marcandr | Indeed. And in those cases, x != y |
| 19:18:50 | marcandr | It's quite cute actually: if there is a difference, then x != y. If there is no difference, i.e. no "path" you can give so that x[...path...] != y [...path...] then they are ==, otherwise they are != |
| 19:19:45 | marcandr | It works for h = { :foo => [h] } too, BTW. |
| 19:20:28 | marcandr | I've put some pretty examples in rubyspecs/core/array/shared/eql and /core/hash/shared/eql |
| 19:32:37 | dgtized | evan: I wonder what happens when you show an animal like a parrot that is aware enough to recognize a mirror images a mirror with a mirror behind it |
| 19:33:48 | evan | it's probably too complex of an idea for them to grasp |
| 19:36:27 | dgtized | probably, but I wonder ... it's not much of a switch on the mirror test, but definitely would be interesting |
| 19:36:41 | evan | yep |
| 19:54:38 | rue | marcandr_: Hm. I have kind of a gut-level dislike of the semantic |
| 20:03:45 | marcandr | rue: what semantic exactly? |
| 20:05:37 | rue | That equality |
| 20:06:12 | rue | Plus it has the somewhat dubious property that adding the exact same object to both makes them not equal any longer |
| 20:06:31 | marcandr | Can you give me an example? |
| 20:07:41 | marcandr | Oh, you mean x=[x], y=[[[x]]] |
| 20:08:06 | marcandr | x == y, but x << 1 != y << 1 ? Is that what you mean? |
| 20:08:55 | rue | Yes |
| 20:09:34 | marcandr | You would rather have x != y ? |
| 20:09:50 | rue | Probably |
| 20:10:10 | rue | What I would _really_ like is to be able to stop worrying about silly corner cases like this :) |
| 20:10:50 | marcandr | Well, I'm certainly not forcing you to :-) |
| 20:10:54 | rue | Do away with RecursionGuard, the user will figure out they have a recursive structure soon enough |
| 20:11:25 | marcandr | Well, that's certainly not much of an improvement! |
| 20:11:36 | rue | Bet it will run much faster |
| 20:11:55 | rue | And users will have less silly code ;) |
| 20:12:34 | marcandr | Well, you realize that some mathematicians might be glad to be able to compare structures like this. |
| 20:12:58 | evan | then they should likely write their own inspect. |
| 20:13:03 | rue | ^^ |
| 20:13:19 | brixen | well, == is the bigger issue |
| 20:13:22 | brixen | not inspect |
| 20:13:27 | evan | i'd agree with that. |
| 20:13:37 | brixen | it is unfortunate that this is not a pay-per-use feature |
| 20:13:42 | brixen | everyone pays for it |
| 20:13:57 | marcandr | But in any case, I understand it's a matter of opinion if recursive handling should be done or not (I vote Yes), but if it does, I feel the best way is to have == to behave properly |
| 20:13:57 | rue | marcandr_: I mean, in this particular case, your solution is at least equally valid than making them inequal |
| 20:15:22 | rue | brixen: Hm, I suppose it is a slightly more valid use case |
| 20:15:59 | rue | #==, that is. But is there really anyone who purposefully has recursive Arrays and simultaneously /does not know which/? |
| 20:17:11 | marcandr | I would think that array comparison is not done that frequently, actually. |
| 20:17:43 | marcandr | I was talking to a friend about my patch and he told me that C# doesn't even have a native array comparison method, for instance. |
| 20:18:11 | rue | evan: Oh--what is gen/types.cpp? |
| 20:18:38 | evan | rue: rake jit:generate_header |
| 20:18:42 | evan | i'm cleaning that all up right now |
| 20:18:56 | evan | if wanna wait another few minutes |
| 20:18:58 | evan | i'm at the tail end |
| 20:21:15 | rue | Sure |
| 20:21:28 | rue | evan: --enable-bindings=none |
| 20:21:40 | evan | i'm conditionalizing LLVM usage atm |
| 20:21:41 | rue | Probably do not need the OCaml :) |
| 20:21:56 | evan | so it's a cleaner build for people once I merge this back in |
| 20:22:13 | evan | rue: ha, no probably not. |
| 20:22:15 | evan | also |
| 20:22:23 | evan | you can build it only for x86 |
| 20:22:30 | evan | that saves like 45 minutes |
| 20:25:28 | brixen | coool datas http://gist.github.com/112386 |
| 20:26:12 | ddub | brixen, evan: what are the compiler tasks? anything I could help with? |
| 20:26:33 | evan | brixen: something else that would be really interesting |
| 20:26:37 | evan | brixen: mixed use keys |
| 20:26:43 | evan | ie, thone Hashs that have symbols for keys |
| 20:26:45 | brixen | ddub: depends what you mean by help |
| 20:26:47 | evan | are ALL the keys symbols? |
| 20:26:57 | brixen | evan: so per instance stats? |
| 20:27:07 | evan | no, thats too much data |
| 20:27:18 | evan | perhaps just the number of hashs with mixed use keys |
| 20:27:19 | brixen | or just see if all the keys in an instance are homogeneous? |
| 20:27:25 | brixen | ok |
| 20:27:50 | evan | ddub: we need a type feedback JIT compiler, could ya get that to me by tuesday? kthxbye |
| 20:27:56 | ddub | brixen: toward the roadmap, as opposed to causing harm :) |
| 20:28:07 | brixen | ddub: :) |
| 20:28:22 | evan | brixen: whats the stats on the methods name? |
| 20:28:30 | evan | what are the units? |
| 20:28:33 | brixen | evan: calls |
| 20:28:59 | evan | ok, what is the median calculated over? |
| 20:29:08 | evan | calls / ?? |
| 20:29:18 | brixen | calls / instance |
| 20:29:24 | brixen | hash instance |
| 20:29:53 | evan | so, on average, a Hash gets called [] on it 24 times |
| 20:29:58 | evan | yes? |
| 20:30:13 | brixen | yes |
| 20:30:24 | evan | k |
| 20:30:42 | ddub | anyway, lemme know if there is anything I could look at |
| 20:30:50 | brixen | ddub: the compiler tasks are rather linked |
| 20:30:53 | ddub | (I think evan was joking) |
| 20:31:03 | evan | ddub: what do ya want to do? |
| 20:31:04 | brixen | the sexp elimination is related to generating the AST |
| 20:31:59 | evan | that would require working mostly in C land |
| 20:32:05 | evan | not that ddub minds C land |
| 20:32:12 | brixen | yeah |
| 20:32:34 | brixen | ddub: the core idea is having a single source ext that can be used in rbx and mri |
| 20:33:00 | rue | brixen: The median/mean relation is interesting |
| 20:33:08 | brixen | evan's idea was to look at Ripper and see if we can do a call-back pattern while visiting the MRI parse tree nodes |
| 20:33:20 | brixen | ddub: ^^ |
| 20:33:35 | evan | a slightly simpler option |
| 20:33:42 | evan | is to rewire add_to_parse_tree entirely |
| 20:33:47 | brixen | rue: yeah, I should break those into percentiles |
| 20:33:56 | evan | to call back out to ruby code rather than building the sexp |
| 20:35:20 | brixen | evan: what metric do you hope to see by looking at the hash-key-homogeneity? |
| 20:35:24 | ddub | is the AST generation still based around a yacc grammar? |
| 20:35:32 | brixen | because I'd need to track those per instance |
| 20:35:36 | ddub | has that stuff changed over.. well I guess the last year? :) |
| 20:35:52 | evan | brixen: i'd hope to see a high number of homogenious hashs |
| 20:36:14 | brixen | evan: because we can optimize for that? |
| 20:36:39 | evan | likely, yes. |
| 20:36:44 | evan | it's an interesting vector for us to consider |
| 20:36:46 | brixen | ddub: AST generation is done in ruby from the sexp generated in C using a ParseTree copy |
| 20:36:58 | brixen | evan: ok, I'll switch it up |
| 20:38:12 | evan | ok, i've got LLVM conditionalized now. |
| 20:38:21 | evan | i'm going to leave it off and merge this branch in |
| 20:38:42 | evan | interested parties can turn it on manually |
| 20:38:59 | evan | step 1 incoming |
| 20:39:08 | boyscout | Add proper build steps for new JIT code - f7cb6ca - Evan Phoenix (llvm-jit) |
| 20:39:08 | boyscout | Conditionalize using LLVM - 0356ed3 - Evan Phoenix (llvm-jit) |
| 20:39:15 | evan | on to step 2 |
| 20:43:31 | ddub | so the idea is to instead have a C library (usable by multiple ruby implementations) that directly builds an AST of ruby objects and exposes it? |
| 20:43:59 | brixen | yeah |
| 20:44:11 | ddub | and this will be changes onto the existing grammer.y? |
| 20:44:21 | evan | no |
| 20:44:32 | evan | the easier route is to change grammar_runtime.c |
| 20:44:47 | evan | ie, let grammar.y build it's NODE tree the way it wants |
| 20:44:49 | ddub | sorry, the same 'package' right? |
| 20:44:50 | evan | then walk the tree |
| 20:59:06 | evan | yippy! |
| 20:59:21 | evan | glances around nervously |
| 20:59:42 | evan | hrm. :/ |
| 20:59:48 | evan | not sure why boyscout didn't say anything |
| 20:59:49 | evan | oh oh |
| 20:59:54 | evan | github doesn't push merge commits to the hooks |
| 20:59:57 | evan | well anyway |
| 21:00:00 | evan | llvm-jit is merged in |
| 21:00:34 | evan | if you link your llvm build dir to vm/external_libs/llvm (remove the empty dir structure there) |
| 21:00:43 | evan | and set LLVM_ENABLE to true in rakelib/vm.rake |
| 21:00:50 | brixen | sweeet |
| 21:00:58 | evan | then it will build the new LLVM JIT |
| 21:01:15 | evan | that merge also includes the new block arg handling code |
| 21:01:24 | evan | so we should see a performance improvement |
| 21:01:52 | evan | 8s to 5.7s for Array#each benchmark, with TOTAL set to 5000 |
| 21:03:13 | evan | now, lunch. |
| 21:03:29 | brixen | moi aussi |
| 21:38:56 | marcandre | Huh? Is it just me, or is return nested in two blocks not working properly? |
| 21:38:59 | marcandre | def f; 1.times { 1.times { p "Bye!"; return false } }; true; end |
| 21:39:12 | marcandre | f prints "bye" but returns true... |
| 21:39:28 | marcandre | Or did I screw up my rbx somehow? |
| 21:44:12 | rue | Should be false, yes |
| 21:44:27 | rue | I can check if LLVM ever builds :) |
| 21:46:32 | marcandre | Oh, looks I was not quite up to date. pulling right now. |
| 21:54:47 | marcandre | Wow. The current head doesn't behave properly either. |
| 21:55:03 | marcandre | I've added that somewhat trivial test to rubyspecs. |
| 21:59:55 | seydar | aloha fellas |
| 22:01:59 | seydar | will rubinius manage its own symbol table for the new JIT, or is that unnecessary? |
| 22:05:22 | rue | marcandre: There was nothing for it in the language specs? |
| 22:06:21 | marcandre | rue: Not sure, but what I know is that 'rake' on the current head doesn't produce any error... |
| 22:08:54 | marcandre | On the rubyspecs head, rbx is failing 3 tests + my new one, and none of the 3 seem related to nesting blocks/method class |
| 22:16:58 | marcandre | rue: so yeah, apparently there was no equivalent for it in the current specs. |
| 22:23:18 | rue | Probably a regression from the block change |
| 22:24:27 | seydar | fades for din din |
| 22:26:14 | evan | did I break something? |
| 22:28:02 | boyscout | Allow the CXX environment variable. - 27a0f6d - Eero Saynatkari |
| 22:28:02 | boyscout | Check RBX_LLVM env to enable LLVM. Minor fixes to build. - 555a397 - Eero Saynatkari |
| 22:29:30 | rue | evan: Looks return in a block only returns through one block upwards |
| 22:29:41 | evan | yeah, i see |
| 22:29:46 | evan | going to work on it now. |
| 22:30:15 | rue | Getting a segfault somewhere in Float running full CI, dunno if that is expected? |
| 22:30:23 | evan | no |
| 22:30:25 | evan | not expected. |
| 22:30:36 | rue | I will look at it when I get home, then |
| 22:30:51 | evan | i'm going to fix the return problem now |
| 22:33:49 | slava | evan: you got something to say to me? |
| 22:33:53 | slava | THEN SAY IT TO MY FACE, BIYAATCH |
| 22:34:23 | evan | HELLO SLAVA |
| 22:34:25 | evan | NICE BREATH YOU HAVE |
| 22:36:26 | slava | so what's up? you poked me earlier |
| 22:38:48 | evan | ummzors |
| 22:38:49 | evan | oh |
| 22:38:57 | evan | after your optimizing compiler runs |
| 22:39:06 | evan | you dump all the IR, yes? |
| 22:39:12 | evan | just keeping the output |
| 22:39:15 | slava | yeah |
| 22:39:20 | evan | k, figured. |
| 22:39:22 | evan | just wanted to double check. |
| 22:42:16 | slava | evan: why, are you thiking of doing something fancy? |
| 22:42:37 | evan | yeah, i'm thinking about sending the IR via email to India |
| 22:42:46 | evan | and having it transcripted on stone tablets in Tamil |
| 22:42:47 | evan | for all to see. |
| 22:43:01 | slava | outsource the optimization? |
| 22:43:14 | evan | do a future branch of humanity, yes. |
| 22:43:17 | evan | so it might take a while. |
| 22:43:19 | evan | s/do/to/ |
| 22:43:30 | boyscout | CI: 555a397 success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 23:03:47 | boyscout | If return in a block to return to the correct depth - 56e77ac - Evan Phoenix |
| 23:07:57 | seydar | returns from the dead |
| 23:08:39 | brixen | wb seydar |
| 23:08:55 | seydar | w3rd to your mom, i'm here to drop bombs |
| 23:09:00 | brixen | seydar: re your earlier question, the jit should not need to manage symbols |
| 23:09:11 | brixen | but feel free to have evan correct me on that :) |
| 23:09:15 | seydar | brixen: thanks. talking about that right now with evan |
| 23:09:20 | brixen | ahh |
| 23:09:26 | brixen | you and your side channels :P |
| 23:09:42 | seydar | i prefer dark alleyways, but whatever floats your boat |
| 23:10:24 | brixen | my boat is floating on smiles and sunshine lad |
| 23:10:31 | brixen | we have no rain today |
| 23:10:49 | seydar | heh, me too, for the first time in about forever |
| 23:10:58 | brixen | no doubt |
| 23:12:13 | boyscout | CI: 56e77ac success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 23:46:13 | evan | brixen: could you ran your rails -h test |
| 23:46:15 | evan | and see if it's any faster |
| 23:46:21 | evan | after my block arg change |
| 23:48:34 | brixen | yep |
| 23:48:38 | brixen | I'll run it |