Da
Show enters and exits. Hide enters and exits.
| 00:36:35 | fynn | evan, brixen: did you guys see the Unladen Swallow JIT link I posted last night? |
| 00:36:45 | evan | nope. |
| 00:40:10 | fynn | evan: http://www.python.org/dev/peps/pep-3146/#performance-retrospective - specifically, the part where they explain why the failed to meet their performance gain goals: |
| 00:41:15 | fynn | "(Our hypothesis is that we hit these problems [that prevented Unladen Swallow from reaching anything close to their original x5 performance gain goals] -- problems other projects [including Rubinius mentioned specifically in a previous paragraph] had avoided -- because of the complexity and thoroughness of CPython's standard library test suite.)" |
| 00:42:15 | fynn | These are problems in the LLVM JIT tools. |
| 00:42:48 | BrianRice-work | huh |
| 00:44:38 | evan | yeah, i work with the US guys |
| 00:45:51 | BrianRice-work | the binary size changes are prohibitive |
| 00:46:19 | evan | the changes in the python binary itself? |
| 00:47:20 | fynn | BrianRice-work: yeah, the upshot is that what US offers now is a huge cost in terms of implementation complexity (and memory usage) in exchange for very modest time-efficiency gains. |
| 00:48:03 | BrianRice-work | well, darn. we have an in-progress LLVM JIT plugin for slate. |
| 00:48:07 | fynn | was wondering what people here would say, given that Rubinius is probably the most similar effort going on right now. |
| 00:48:26 | BrianRice-work | (or bytecode at least is SSA and similar to LLVM's) |
| 00:48:31 | BrianRice-work | s/or/our/ |
| 00:49:21 | BrianRice-work | in that case, I'll have us keep focussing on high-level changes that don't rely on LLVM as a backend. bytecode-to-bytecode transforms might serve us well for a while. |
| 00:50:58 | evan | BrianRice-work: don't back off the LLVM JIT. |
| 00:51:04 | evan | we're doing fine. |
| 00:51:07 | evan | as is MacRuby. |
| 00:51:13 | BrianRice-work | I see. |
| 00:51:20 | BrianRice-work | well presumably US is paving our way |
| 00:51:27 | evan | why? |
| 00:51:38 | evan | they've the newest user |
| 00:51:44 | evan | macruby and rubinius are quite a bit older. |
| 00:51:51 | BrianRice-work | oh, I assume that these bugs being fixed are going into LLVM |
| 00:51:54 | evan | they're the newest user, rather. |
| 00:51:59 | evan | they are |
| 00:52:09 | evan | but I should note that I haven't ever hit the bugs they're talking about. |
| 00:52:22 | BrianRice-work | ok. I guess I'm reading too much into it |
| 00:52:49 | BrianRice-work | thanks |
| 00:52:53 | fynn | evan: so how come their encountering those problems, while Rubinius doesn't? |
| 00:52:58 | evan | no prob |
| 00:53:03 | evan | happy to pull you back from the cliff |
| 00:53:10 | evan | fynn: *shrug* |
| 00:53:10 | fynn | heh |
| 00:53:14 | evan | different usage patterns |
| 00:53:18 | evan | different requirements |
| 00:53:24 | evan | hard to say |
| 00:53:33 | evan | US has a very particular requirement |
| 00:53:41 | evan | that all the interpreter features work even though it's JITd |
| 00:53:49 | evan | that complicates things considerably in some cases. |
| 00:53:54 | evan | rubinius doesn't have that problem. |
| 00:53:56 | BrianRice-work | both rubinius and slate have very simple implementations by comparison with CPython |
| 00:54:07 | fynn | evan: yeah, Collin also mentioned that he "envies" Rubinius for the kind of decisions you guys can make, wasn't sure what he was referring to. |
| 00:54:16 | fynn | evan: why does US need that why you don't? |
| 00:55:09 | fynn | (afaik both projects are about getting an interpreted dynamic language working with LLVM + JIT, including a legacy C API - i.e. don't see a significant difference there) |
| 00:55:10 | evan | because they want US to not break anything |
| 00:55:22 | evan | Rubinius is my green field playground |
| 00:55:27 | fynn | interesting, what is Rubinius breaking? |
| 00:55:43 | evan | well, Rubinius doesn't support set_trace_func at any level |
| 00:55:47 | evan | and if I do support it |
| 00:55:53 | evan | it will just turn the JIT off if you use it. |
| 00:56:05 | fynn | I guess you can better afford breaking C api compatibility, since C extensions are way less prominent in Ruby vs. Python. |
| 00:56:15 | evan | it's almost never used, so it's no biggy. |
| 00:56:34 | evan | fynn: actually not true at all. |
| 00:56:41 | evan | there are a shitton of ruby extensions. |
| 00:57:02 | evan | and we've worked hard to not break their API interface |
| 00:57:26 | evan | that means we startup a emulation/handler layer between our core and the extension |
| 00:57:36 | evan | so they can continue to do the weird things that they did under MRI |
| 00:57:38 | evan | and not break anything. |
| 00:57:45 | fynn | cool, though a huge number of users out there are just using pure-Ruby web frameworks. |
| 00:57:55 | evan | Ruby not using refcount is a big part of the ability to do that. |
| 00:58:17 | fynn | evan: are you planning to support a different low-level extension API? |
| 00:58:19 | evan | because that means that all extensions are written to support a basic liveliness via reachability scheme. |
| 00:58:37 | evan | fynn: it's been discussed, but we haven't had the time or need for such a thing. |
| 00:58:51 | evan | better that we make the MRI compat layer better and better. |
| 00:58:57 | evan | that serves multiple interests. |
| 00:59:05 | fynn | yeah, and if the JIT really delivers, it becomes much less of a concern |
| 00:59:11 | fynn | and the MRI C-API is not bad. |
| 00:59:29 | evan | yeah, there are only a few ugly parts (most of the R* macros) |
| 00:59:39 | evan | we've been able to work around most of that, save for RHASH() |
| 00:59:43 | fynn | anyways, I was just sort of concerned, because at this point the U-S JIT sub-project is emerging as failurish |
| 00:59:53 | evan | it is? |
| 00:59:56 | evan | thats not how I read this |
| 01:00:05 | fynn | which sort of endangers the viability of the entire project, at least for now |
| 01:00:14 | evan | i read it as "we were overambisious, but things are still going well" |
| 01:00:20 | evan | glass half full! |
| 01:00:32 | fynn | evan: few objective observers are going to support merging U-S into Python3 based on those stats :) |
| 01:00:37 | BrianRice-work | I'm sure it's successful by google's investment measures |
| 01:00:42 | evan | overambitious |
| 01:00:43 | evan | rather. |
| 01:01:27 | fynn | the stats boil down to "we offer this huge overhead in complexity, memory consumption and binary size, in exchange for ~1.5x time performance gain" |
| 01:01:59 | evan | imho, the memory consumption is the only one to be worried about. |
| 01:02:20 | evan | the complexity is hidden inside a vendored library |
| 01:02:24 | BrianRice-work | yeah, and it's similar to the Self-92 situation which they cite |
| 01:02:44 | evan | people will argue that python's complex grows just by using that library |
| 01:02:45 | BrianRice-work | although not entirely so |
| 01:03:10 | evan | and thats valid, but i guess it's a question of whether or not that matters. |
| 01:03:22 | evan | i can't say i'm in tune with "the python way" |
| 01:03:26 | evan | so i don't really know. |
| 01:04:15 | fynn | evan: it seems like the major problem is the disappointing performance gains. |
| 01:04:33 | evan | thats probably true |
| 01:04:52 | evan | sadly though, thats because they came out of the gate saying "10x speed improvement in one year! weee!" |
| 01:04:54 | fynn | "python way" or not, the entire community would be willing - nay, thrilled! - to merge a monstrous complexity for a 5x gain. |
| 01:05:00 | evan | i underhype rubinius. |
| 01:05:04 | evan | and try to over deliver. |
| 01:05:13 | fynn | that's a good approach in life! |
| 01:05:15 | evan | keeps everyone happy. |
| 01:05:53 | fynn | and yeah, claiming 5x performance increase didn't make it better for them, although a merge would be a problem anyway with those stats. |
| 01:06:25 | evan | I don't see why they're pushing for a merge now. |
| 01:06:30 | evan | i guess I could ask. |
| 01:07:13 | evan | i did and collin said they wanted to do it |
| 01:07:27 | evan | i guess i don't get why you push it hard when you've just realized you've underdelivered. |
| 01:07:33 | evan | but i suck at marketing. |
| 01:08:02 | fynn | maybe just because they think they can still push it through. |
| 01:08:51 | evan | i guess so. |
| 02:03:09 | rue | 1.5 is nothing to scoff at |
| 02:03:18 | rue | Unless you were expecting 5x ;) |
| 02:08:25 | evan | excatly |
| 02:08:28 | evan | exactly. |
| 03:04:00 | Defiler | huh; http://llvm.org/bugs/show_bug.cgi?id=5201 |
| 04:09:26 | evan | Defiler: yes, thats a fun bug. |
| 04:09:36 | evan | i've been working with the US guys on a final solution. |
| 08:02:33 | dbussink | morning! |
| 08:24:29 | slava | hi dbussink |
| 08:38:54 | dbussink | slava: morning for you too? |
| 08:43:17 | dbussink | slava: oh wait, it was like a 12 hours diff :) |
| 08:45:07 | slava | evening here |
| 13:44:19 | duncanmv | evan: ping |
| 14:44:01 | rue | Morning |
| 16:56:29 | evan | duncanmv: sup? |
| 17:03:14 | slava | hi evan |
| 17:04:14 | evan | hi hi |
| 17:12:38 | tenderlove | evan: pew pew pew |
| 17:12:39 | tenderlove | good morning |
| 17:13:21 | evan | pew pew pew! |
| 17:13:25 | evan | how are you? |
| 17:13:53 | tenderlove | oh, not bad |
| 17:14:06 | tenderlove | trying to motivate myself to do my job |
| 17:14:13 | tenderlove | but failing miserably |
| 17:14:27 | tenderlove | futzing with sqlite3 bindings seems much more interesting |
| 17:14:57 | tenderlove | know what I'm saying? |
| 17:24:17 | rue | YES |
| 18:26:03 | jvoorhis | evan: hi |
| 18:32:14 | jvoorhis | i changed the api for functions slightly and hacked in support for global variables :) |
| 18:32:39 | jvoorhis | starting to approach completeness |
| 19:13:38 | evan | jvoorhis: cool |
| 21:30:25 | lypanov | is sad and searching for a new job :( |
| 21:45:29 | rue | Aww! Where are you searching? |
| 21:53:30 | evan | lypanov: oh noes! |
| 21:59:47 | lypanov | rue: like um. cool stuff? |
| 21:59:50 | lypanov | evan: aye :( |
| 22:00:16 | lypanov | is like, totally bummed out, as he has like, a wife and a house and stuffs, and its the only income *sad sad* |
| 22:01:02 | evan | :( did you get laid off? |
| 22:01:47 | lypanov | still got a bit to go. but mid feb i'm salaryless |
| 22:02:22 | lypanov | i can always sort some other random shit out... but i kinda liked my job and don't want something that sucks :( |
| 22:40:54 | botanicus | evan: Are you here? You still haven't merged my commits & I asked you for commit access. I have some more stuff now. And also, I still have no clue what the ideal workflow with rubyspec should be, you told me last time that you have to discuss it with others, but then I haven't got any response regarding this issue. |
| 22:41:43 | evan | ah crap. |
| 22:41:45 | evan | sorry about that. |
| 22:45:05 | evan | botanicus: your git repo looks a bit weird. |
| 22:45:24 | botanicus | evan: what do you mean by 'weird'? |
| 22:45:44 | evan | why are there a whole bunch of commits with the author of brixen and you as the commiter |
| 22:46:32 | botanicus | evan: git pull --rebase did it ... seems weird, you're right |
| 22:46:34 | botanicus | However |
| 22:46:45 | evan | oh |
| 22:46:50 | botanicus | Don't worry about these commits, they're not mine, they already are in rubinius |
| 22:46:53 | evan | you never use pull --rebase when you've pushed commits |
| 22:47:18 | evan | pull --rebase is only for when you have commits only locally |
| 22:47:19 | evan | anyway |
| 22:47:29 | evan | your commits are for 1.9 |
| 22:47:41 | botanicus | I've been doing fetch && rebase before manually and I thought that pull --rebase is just a shortcut |
| 22:47:45 | evan | so i talked with brixen about this briefly |
| 22:47:55 | botanicus | I see, thx for info |
| 22:48:10 | evan | so we need some rubyspecs for your changes |
| 22:48:20 | evan | they should be in the form of commits to the rubyspec repo |
| 22:48:27 | evan | with version guards for 1.9 |
| 22:48:44 | evan | search for "ruby_version_is" and you'll see how the guards are used. |
| 22:50:11 | botanicus | evan: I see. So how should I use it locally? It seems rubinius/spec is synced from rubyspec, is it? |
| 22:50:32 | evan | you should fork the rubyspec repo |
| 22:50:35 | evan | and make commits to it |
| 22:50:57 | botanicus | OK, I'll take a look, thanks |
| 22:50:59 | evan | the 1.9 workflow isn't as smooth as the 1.8 for now |
| 22:51:14 | botanicus | It seems I have some hiccups on the last rubinius, just updated from one_nine branch http://pastie.org/790567 ... |
| 22:51:15 | evan | so i'm not going to say that on the 1.9 branch spec/ruby is sync'd |
| 22:51:42 | evan | is that ruby ruby 1.9 |
| 22:51:46 | evan | because you still need 1.8 |
| 22:53:45 | botanicus | evan: you mean run rake with 1.8? |
| 22:53:51 | evan | yes |
| 22:54:37 | botanicus | I see |
| 23:01:01 | botanicus | evan: yeah, it works now, thanks |
| 23:01:41 | evan | k |
| 23:39:15 | rue | lypanov: /Where/ were you searching, .nl? |