Show enters and exits. Hide enters and exits.
| 02:15:27 | headius | http://jira.codehaus.org/browse/JRUBY-3714 |
| 02:15:30 | headius | rbx fails it too |
| 02:15:33 | headius | stupid cvars |
| 02:16:37 | rue | Well, technically we have a 2:1 advantage over MRI then ;) |
| 02:17:11 | devinus | is there a daily benchmarker like pypy has? i'm really beginning to dig rubinius and most every package i throw at it is working now, i just wish i could see some hard data somewhere |
| 02:17:25 | headius | rue: time to gang up! |
| 02:18:53 | rue | devinus_: Which data? |
| 02:19:25 | devinus | rue: some type of graph or table benchmarking MRI and rubinius |
| 02:20:06 | devinus | rue: something akin to http://tuatara.cs.uni-duesseldorf.de/benchmark.html |
| 02:20:16 | rue | Need to find something to benchmark, then, other than the specs |
| 02:21:32 | slava | how about the shootout benchmarks? |
| 02:23:27 | sandal | evan, brixen, rue : Terribly crappy mockup of my RubySpec idea |
| 02:23:29 | sandal | http://is.gd/IDOO |
| 02:24:22 | rue | Mm, the shootouts might work, although some real apps would be better |
| 02:31:07 | sandal | devinus_: feel free to run Prawn's example set |
| 02:31:24 | sandal | Rubinius does it perfectly, and it should hit a wide range of Ruby features |
| 02:58:35 | rue | Heh |
| 02:58:52 | rue | Running the specs multiple times in the same run does not work so good |
| 03:40:01 | rue | Well, running some library code, about 3.5x the time 1.8.7 is taking |
| 03:40:25 | rue | Core code is more like 5.5-6x |
| 03:44:04 | slava | sounds like you have some catching up to do :) |
| 03:44:25 | slava | when you're 10x faster than MRI I'll buy you all a big case of beer |
| 03:52:03 | rue | JIT is not making much of a difference...and the specs collapse before enough code can be run to determine if really aggressive inlining helps any more |
| 03:54:00 | slava | rue: more work on the JIT should give you a speedup even without type feedback |
| 03:54:15 | slava | the V8 and SFX guys just riced the fuck out of the JITted forms of various bytecodes and got good speedups |
| 03:54:24 | slava | eg, you can do a fastpath for arithmetic ops so that the fixnum case is inline |
| 03:54:27 | slava | not sure if evan did this yet or not |
| 04:06:17 | rue | Dun think so |
| 04:06:32 | rue | I am sure there are plenty of low hangers |
| 04:07:29 | rue | Right now the plain JIT is about a 13% reduction over a full spec run |
| 04:13:43 | ddub | speedups are so overrated |
| 04:33:21 | devinus | slava: i know your name somewhere. :-) Slava Pestov? |
| 04:48:52 | sandal | evan: so, does this look interesting? http://is.gd/IDOO |
| 04:48:56 | sandal | (if ugly) |
| 04:49:31 | sandal | sweet. It will definitely happen. I'll at least try, anyway |
| 04:49:43 | sandal | My work is talking about maybe even pulling our designer in on this |
| 04:50:22 | sandal | <shrugs> I really don't know. |
| 04:50:39 | sandal | I sort of need to data drive the UI, and I need to get familiar with the data first |
| 04:50:55 | sandal | It'd be nice to see both a class and method level spec |
| 04:51:16 | sandal | the class level report might be abridged |
| 04:51:32 | sandal | to show what functions have specs and what is missing |
| 04:51:45 | sandal | and then clicking through would give you this method-level view |
| 04:52:18 | sandal | but this is why I asked my work to get involved. It's not so much the paid time that will help (as that'll be a few hours per week, tops), it's the fact that they will volunteer hours |
| 04:52:39 | sandal | I don't really do any of this web stuff, I mostly hack on building backend support |
| 04:52:58 | sandal | Yeah, I will probably start with something much lighter than this and see where it takes me |
| 04:53:13 | sandal | and hopefully progress to something more featureful than the mockup |
| 04:53:47 | sandal | I've been itching to do something that's challenging but stands to help the Ruby community at large |
| 04:53:51 | sandal | this seems like a good project for that |
| 04:55:19 | sandal | it also seems like something that you, and headius, and all the other implementers would be doing yourselves if you didn't have so much work to do already |
| 04:55:54 | sandal | I think it might be a good idea to have a layperson try to bring together all this awesome work you guys are doing. |
| 05:22:59 | sandal | ahaha, reading the 1.8.7 NEWS file is sort of like reading an April fools joke |
| 06:05:52 | ddub | evan: I think you might want to reword this |
| 06:05:57 | ddub | it gives the impression that rubinius isn't dead |
| 06:05:59 | ddub | ;-) |
| 06:07:09 | headius | harsh |
| 06:07:30 | headius | I thought I was the only one mean enough to make that joke |
| 06:08:40 | ddub | headius: is it still mean if I put a ;-) after it? |
| 06:09:02 | headius | I think it becomes black comedy then |
| 06:09:18 | ddub | but yeah evan, more communication is always good, and it reads fine to me |
| 06:10:19 | ddub | don't worry headius, as soon as I think of a good rude comment re: java + ruby + oracle, you will be first to know |
| 06:10:33 | headius | I've heard most of them, so you'll have to dig deep |
| 06:10:42 | ddub | any good ones? |
| 06:10:47 | ddub | I've had a tough time coming up with anything |
| 06:11:17 | headius | mostly people just trying to take down jruby by insulting sun's dumb decisions |
| 06:12:31 | scoopr | when you introduce yourself, would you insist that you work for sun, or confess that you work for oracle? ;) |
| 06:12:44 | ddub | yeah, but thats easy. I'm trying to figure out how to work oracle into the mix |
| 06:13:38 | ddub | I still like jwz and his interview comment about his friends ridiculing him for his new jwz@aol.com email address |
| 06:14:08 | ddub | apparently that wasn't appreciated by all of his new management after the netscape acquisition |
| 06:14:29 | headius | I've started to use my headius.com email for most things, if that tells ya something |
| 06:14:38 | ddub | so larry ellison, matz, and duke walk into a bar... |
| 06:15:24 | ddub | I've always thought duke would sound like a cross between alvin and the chipmunks and john wayne |
| 06:15:59 | ddub | it leaves me a large area to work within :) |
| 06:16:29 | ddub | but I mean more like, john wayne two octaves higher |
| 06:17:42 | ddub | headius: the way I figure it, I like java except for the language and the standard libraries... |
| 06:17:57 | ddub | so since jruby keeps me from having to deal with those, hoorah :) |
| 06:18:29 | headius | hey, we aim to please |
| 06:19:03 | headius | if someone can use jruby and never know they're using java, that's a good day |
| 06:21:50 | sandal | if I document this change in RubySpec, where should it go? |
| 06:21:51 | sandal | http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/337791 |
| 06:22:02 | sandal | language/array_spec.rb ? |
| 06:22:27 | sandal | where is that? |
| 06:22:54 | sandal | ah, element_set_spec. |
| 06:23:00 | sandal | Didn't know that was the name for that :) |
| 06:23:16 | sandal | agreed |
| 06:23:20 | sandal | though I might call it |
| 06:23:24 | sandal | bracket_equals_spec |
| 06:23:38 | sandal | Not because that sounds good, but because I'd recognize it immediately |
| 06:23:48 | headius | it's called "aset" in jruby |
| 06:23:53 | headius | or op_aset |
| 06:24:35 | headius | I think jruby's compiler mangling turns it into leftbracket_rightbracket_equals |
| 06:25:25 | sandal | oh hmm, I think it's already specified. |
| 06:27:50 | sandal | yep: |
| 06:27:51 | sandal | http://pastie.org/493649 |
| 06:28:20 | sandal | cool, I don't need to do any work then :) |
| 06:28:40 | sandal | But I'm already wishing for my web interface. |
| 06:29:00 | sandal | User types in Array#[], sees the list of spec names, and which versions do what clearly in a list. |
| 06:29:34 | sandal | #[]= err |
| 06:32:01 | sandal | Honestly, I'm just amazed at what an awesome resource these specs are. |
| 06:32:12 | sandal | You guys have done a terrible job of getting them appreciated ;) |
| 15:48:06 | rue | sandal: Heh, I see Matz actually read the question this time :) |
| 15:48:15 | rue | Did not respond to my query, though... |
| 15:48:29 | sandal | rue: hah, his response makes more sense now, though |
| 15:48:45 | rue | headius: Would you be of the opinion that Rubinius is not allowed to rely on Module#name being correct? |
| 15:49:32 | headius | rue: yes |
| 15:49:41 | rue | I am not in favour of any kind of _actual_ prevention, I think...just decreeing that if the user fucks with Core methods/ivars, they do so at their own risk |
| 15:49:48 | headius | just last night I found another class that defined its name as something weird |
| 15:50:07 | rue | headius: But not its *real* name, right? |
| 15:50:17 | headius | it should probably be expected that people are overloading Class#name and Module#name for other purposes |
| 15:50:26 | headius | well, it's Class#name |
| 15:50:29 | headius | its |
| 15:50:57 | rue | But then I think there should be some alternative mechanism for getting the real name...I do not see the point of Module#name if it is not inviolable |
| 15:51:25 | sandal | is there any reason why FFI presents things in a different order than what's natural in C? |
| 15:51:36 | sandal | I sort of would like to be able to do |
| 15:51:50 | rue | sandal: Ha! I wrote an alternative API for a C-like declaration but was shot down.. |
| 15:52:21 | sandal | ffi_build_interface { f.int :MyFunc, [:int, :string, :int]; f.string :MyFunc2 } |
| 15:52:39 | sandal | |f| |
| 15:52:48 | headius | most things could be added atop what's there now, so it's worth proposing |
| 15:52:57 | headius | or release an ffi_builder gem :) |
| 15:53:04 | sandal | Sure, I know it's easy to add, just wanted to see if you liked it :) |
| 15:53:39 | rue | http://github.com/evanphx/rubinius/commit/3be9a9143961ecd48f7c4e6c017197f98a485977 |
| 15:54:16 | headius | if it were instance_eval'ed (I know, boo hiss) it could be { int :my_func, [int, string, int]; string my_func2 } |
| 15:54:39 | sandal | headius: I would probably do what I did with Prawn |
| 15:54:48 | sandal | without block arg, instance eval |
| 15:54:55 | sandal | with, normal closure and param passing |
| 15:55:20 | rue | `attach_foreign :int, 'foo', [:string, :string]` or something, I think it was |
| 15:55:25 | headius | the other option would be to get a full-featured C signature parser and just do ffi_blah "int my_func(char*, uint)" |
| 15:55:42 | headius | where the signature is defined in terms of FFI type names |
| 15:56:07 | rue | Nah...although assuming a subset of valid C it is pretty simple |
| 15:56:17 | rue | I like the pseudo-C better still :) |
| 15:56:56 | sandal | I could give it a really overblown name for a 10 line gem |
| 15:56:57 | sandal | sexy_ffi |
| 15:57:06 | rue | sandal: cexy_ffi |
| 15:57:12 | sandal | ahaha |
| 15:57:16 | headius | secksy |
| 15:57:53 | sandal | http://gist.github.com/119989 |
| 15:57:54 | headius | other than rubygems sucking I am totally in favor of lots of tiny gems to build APIs on top of APIs |
| 15:58:10 | headius | sucking = excessive nonsense on require 'rubygems' every time |
| 15:58:12 | sandal | Just toying with syntax here using a small sample of my real FFI code |
| 15:58:26 | sandal | a DSL could also give you something like |
| 15:58:47 | sandal | ptr = memory_pointer(type) |
| 15:58:59 | rue | But I think overall it would just lead to undue multiplication...I would probably prefer to just use the standard version even if it sucks ;) |
| 15:59:18 | sandal | Well I'm thinking this is something I can whip up on a gist |
| 15:59:20 | headius | sandal: you should try to start up a conversation on ffi list at any rate |
| 15:59:33 | headius | heh, there needs to be a way to have a gist auto-gemify |
| 15:59:35 | sandal | Sure, let me try building it and see how it improves my code |
| 15:59:45 | sandal | and then if it's convincing I'll provide a before and after |
| 15:59:46 | headius | like a gist with a .gemspec file |
| 16:01:29 | rue | headius: Haha, that is a horrifying idea |
| 16:01:37 | rue | "Release a Gem of this Gist" |
| 16:01:40 | headius | :) |
| 16:01:56 | headius | it seems like the GitHub Way |
| 16:01:58 | rue | Another GSoC project for next year... |
| 16:03:41 | sandal | evolving this idea a little... |
| 16:03:43 | sandal | http://gist.github.com/119989 |
| 16:05:00 | rue | sandal: The thing that most bothers me personally about the current API is defining the alternate name |
| 16:05:08 | sandal | oh |
| 16:05:12 | sandal | in this API it could just be |
| 16:05:20 | rue | I used `:as => "someothername"` with .attach_foreign |
| 16:05:25 | sandal | { :OldName => :NewName } |
| 16:05:31 | sandal | or sure |
| 16:05:42 | sandal | func, args, :as => "Other" |
| 16:06:03 | sandal | I'll try both of those and see how it goes |
| 16:06:50 | rue | I do like the block form for the lib rather than setting the lib without apparent scope |
| 16:14:52 | sandal | I'd probably build this on top of something like class MyClass < FFI::Builder; end |
| 16:15:22 | sandal | So that there is a less magic way to get at it, and it's all self contained |
| 16:15:57 | rue | In addition to defining the lib, I would see about just getting it in ruby-ffi |
| 16:16:48 | sandal | Sure, I'll try that before releasing anything of my own, it's just good manners |
| 16:17:00 | sandal | Hah, this is so funny. |
| 16:17:11 | sandal | The easiest way to access a C library from Ruby on Windows is JRuby |
| 16:17:25 | sandal | I don't know whether that's hilarious or sad or both |
| 16:41:15 | ddub | sandal: I vote both |
| 17:13:39 | brixen | sandal: I think you will want to stick with a mixin rather than inheritance for that |
| 17:13:52 | brixen | MyClass is not really an FFI::Builder |
| 17:14:11 | brixen | unless you plan on making a variant of FFI::Builder |
| 17:14:56 | brixen | sandal: one reason it works the way it does is because we attach FFI functions very early in our bootstrap process |
| 17:15:05 | brixen | the simpler the code, the better |
| 17:15:19 | brixen | which doesn't mean you can't have a fancy mechanism |
| 17:15:29 | brixen | but we won't use it in core lib |
| 17:18:35 | headius | evan: I was going to show you the invokedynamic bytecode the other day, but realized it was pretty trivial |
| 17:18:38 | headius | INVOKEDYNAMIC java/lang/dyn/Dynamic.fcall (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/ IRubyObject;Ljava/lang/String;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRu byObject; |
| 17:18:57 | slava | that's so dynamic |
| 17:19:17 | sandal | brixen: oh sorry, I didn't know FFI builder existed |
| 17:19:41 | headius | fcall there is just being used as a marker to know which kind of call it is; I assume all indy ops pass the method name to invoke as an argument |
| 17:19:45 | headius | (atm) |
| 17:20:06 | headius | it also allows me to install call site logic that doesn't do visibility checks, etc |
| 17:20:17 | headius | slava: it is! |
| 17:22:10 | slava | I wonder how much better hotspot would be if they could get rid of a lot of the legacy stuff, like the bytecode, and just expose the IR directly |
| 17:22:43 | brixen | sandal: I don't know about FFI builder, I was just commenting on this.. |
| 17:22:44 | brixen | 08:14 sandal >> I'd probably build this on top of something like class MyClass < FFI::Builder; end |
| 17:24:56 | headius | slava: well, I'm hoping that the methodhandle stuff gets us part of the way there |
| 17:25:36 | cremes | is it still true that java classes can't inherit from jruby classes? |
| 17:25:58 | headius | not without ruby2java, which is still early prototype |
| 17:26:13 | headius | I'm still not exactly sure what it means to extend a static type from a dynamic type though |
| 17:26:33 | cremes | true... |
| 17:26:44 | headius | er, extend a dynamic type from a static type, I guess |
| 17:27:02 | cremes | i build most of my classes using modules; i have a class that needs java performance but i'd like it to be able to "include" the ruby parent stuff |
| 17:27:39 | cremes | iow, i only want to write the performance critical subclass in java while the inherited bits remain in ruby |
| 17:28:07 | slava | sounds like you should go for a more traditional compositional design rather htan using inheritance here |
| 17:28:27 | cremes | not really doable unless i forward/delegate calls from the ruby subclass to the java subclass |
| 17:28:34 | cremes | yeah, compositional |
| 17:28:55 | cremes | i'll go that route for now since it is quickest |
| 17:30:15 | headius | cremes: it will be possible in the future |
| 17:30:27 | cremes | most excellent! |
| 17:30:40 | headius | getting ruby2java shaped up is up for the summer, which would then give you a way to have a "real" Java type to extend |
| 17:30:50 | headius | but we should probably move this to #jruby for further discussion :) |
| 17:30:58 | enebo | really :) |
| 17:31:12 | cremes | oops, i thought i was in that channel! :) |
| 17:47:31 | sandal | brixen: yeah, I recognize that problem. It wouldn't be too hard to do something like this |
| 17:48:16 | sandal | Create a module for mixin |
| 17:48:21 | sandal | and maybe automatically mix it in |
| 17:48:46 | sandal | but this really would just be for lazy people. :) |
| 17:48:55 | sandal | I'm not necessarily suggesting it for core |
| 17:49:15 | sandal | it could be something like |
| 17:49:27 | sandal | API = ffi_builder() { ... }; include API |
| 17:49:40 | sandal | I'll have to play with it and see how it goes |
| 17:59:09 | rue | sandal: Do you have perf numbers for running the Prawn examples under Rubinius (in contrast with MRI)? |
| 18:03:16 | sandal | I will get them soon, I'm writing that part of my pres now |
| 18:03:29 | rue | Cool |
| 18:03:42 | rue | Oh, yeah, the conf is tomorrow, right? |
| 18:03:47 | sandal | man, I hope the people like this picture of an old rusty truck |
| 18:03:56 | sandal | Because I show it whenever i talk about MRI |
| 18:04:00 | sandal | and I talk about MRI a lot |
| 18:04:07 | rue | If you can do a profile run, too, 't helps |
| 18:04:24 | brixen | sandal: maybe slice the pic up and show different parts |
| 18:04:29 | sandal | I definitely don't want to get involved in performance analysis |
| 18:04:39 | brixen | build up to the full pic of the rusty truck :) |
| 18:04:41 | sandal | Otherwise people will throw tomatos |
| 18:04:51 | headius | ugh test perf numbers |
| 18:05:03 | rue | headius: No, *example* perf numbers |
| 18:05:04 | headius | the worst possible test of runtime-optimizing vms |
| 18:05:12 | sandal | brixen: holy cow, I wish I thought of that. |
| 18:05:13 | headius | same diff |
| 18:05:19 | rue | Um, no |
| 18:05:19 | sandal | It'd be too hard to work it in now |
| 18:05:20 | brixen | sandal: a simple 'time command' is a good number to know though |
| 18:05:27 | brixen | most of the perf stuff is gaming |
| 18:05:28 | sandal | brixen: I've got that |
| 18:05:32 | sandal | That's what I'm reporting |
| 18:05:33 | brixen | it's hard to game a time command |
| 18:05:41 | sandal | time to run all the examples across implementations |
| 18:05:46 | sandal | there are a lot of them |
| 18:05:51 | rue | sandal: To be clear, I am not suggesting you include that in your presentation :) Just in general |
| 18:06:08 | sandal | rue: feel free to grab Prawn's source and profile it |
| 18:06:15 | sandal | and if you find anything interesting, let me know :) |
| 18:06:30 | rue | Hrm, I wanted you to do all the work |
| 18:06:36 | rue | Gem OK? |
| 18:06:43 | sandal | brixen: I really, really want to avoid lying to the audience. This talk came out way different as a result of sticking to my guns on that |
| 18:06:57 | brixen | sandal: beautiful :) |
| 18:06:58 | sandal | I gem unpacked 0.4.1 for this test |
| 18:07:25 | sandal | It's really hard. I would have needed to research this for a year to give people solid numbers and compatibility notes, etc |
| 18:07:46 | sandal | So instead I'm trying to present what it's like to get your feet wet (good and bad), in hopes others will do it as well |
| 18:08:04 | brixen | very cool |
| 18:08:14 | sandal | I just hope that message is appreciated |
| 18:08:28 | sandal | People tend to prefer graphs and statistics and demo-driven examples :) |
| 18:08:45 | brixen | be true to your message and those that appreciate it are your audience ;) |
| 18:10:16 | sandal | I think the key thing that I discovered is that defining Ruby is really hard right now based on what we have out there, and because of that, it's hard to make decisions |
| 18:10:51 | sandal | So I think that outside of the core community of implementers, the thing every Ruby hacker could do is try to help form that definition by learning more about the state of things |
| 18:10:51 | slava | do you think ruby is headed down the same road as common lisp, with multiple incompatible implementations and lots of per-implementation porting work? |
| 18:11:10 | brixen | slava: we're trying to ensure that doesn't happen |
| 18:11:12 | sandal | slava: that's my fear. It may well be inevitable |
| 18:11:24 | sandal | But I don't want it to happen by surprise, or by accident |
| 18:11:25 | brixen | if it happens despite our best effort, perhaps it was inevitable |
| 18:11:39 | brixen | I don't think it's so hard to be compatible |
| 18:11:58 | sandal | brixen: I don't want to keep sniffing vapor, but I really think a user accessible rubyspec will make a big difference |
| 18:11:59 | headius | it's not |
| 18:12:11 | sandal | I'm just going to need a lot of help from you guys to make that work right |
| 18:12:13 | headius | it's hard to define ruby when impls start "extending" it though |
| 18:12:13 | brixen | no one has anything to gain by making the ruby pool smaller |
| 18:12:41 | sandal | heh, why do I not feel the love of MacRuby among Rubinius/JRuby devs? ;) |
| 18:12:43 | brixen | sandal: I like your proto interface |
| 18:13:02 | headius | hey, I didn't say anything about MacRuby! :) |
| 18:13:03 | brixen | I'm excited for macruby |
| 18:13:09 | headius | yeah, me too |
| 18:13:10 | brixen | I can't wait |
| 18:13:18 | brixen | I used to write desktop apps |
| 18:13:32 | brixen | I'd have loved to write them in ruby rather than C |
| 18:13:39 | headius | I just have a certain view of ruby purity that up to now all implementers have held sacred |
| 18:14:10 | brixen | btw, macruby has a rubyspec evangelist too, his nick is alloy |
| 18:14:16 | brixen | and we should support/help him |
| 18:14:23 | sandal | For sure. |
| 18:14:40 | brixen | he's having beers in the sun right now :) |
| 18:14:42 | headius | brixen: you should post something about ffi => rubyspec on ruby-ffi mailing list |
| 18:14:44 | brixen | (he told me so) |
| 18:14:45 | sandal | I think the thing that's bugging me about MacRuby is the hype |
| 18:15:01 | headius | I know we'd talked about it briefly but I don't think wmeissner knows anything abou tit |
| 18:15:05 | sandal | I actually think that the *lack* of hype about JRuby really is what kept it lean |
| 18:15:08 | brixen | headius: yeah, I will, but I haven't started looking at it in detail yet |
| 18:15:09 | sandal | and impressive |
| 18:15:47 | headius | brixen: ok, I wasn't sure how far along it was, and then alloy posted to macruby list about it |
| 18:15:51 | headius | kinda caught me off guard |
| 18:16:23 | headius | sandal: all impls get this sort of excitement early on...I think it will pass when it takes them more than a few months to get it done |
| 18:16:35 | headius | the roar about rubinius last spring was practically deafening :) |
| 18:16:41 | sandal | yeah, I was thinking about that.... |
| 18:16:45 | brixen | headius: yeah, the last convo with you and wmeissner ended without a clear plan |
| 18:16:57 | sandal | MacRuby at this point really reminds me of JRuby a couple years ago |
| 18:17:02 | brixen | headius: you, me, and wmeissner I mean |
| 18:17:11 | headius | brixen: yeah |
| 18:17:16 | sandal | there is so much promise there, but it's hard to see if you're not right at the center, unless you just trust the noise |
| 18:17:44 | evan | morning. |
| 18:17:53 | brixen | morning |
| 18:18:01 | headius | sandal: I was initially insecure about macruby because of two things: 1. I didn't know how they were getting their performance on the new branch, and 2. I thought they were a lot further along on compatibility |
| 18:18:24 | rue | Evening |
| 18:18:25 | headius | now I know where there perf comes from and I think I know how far it will take them, and I know they've just started to scratch the surface of rubyspec |
| 18:18:38 | sandal | headius: I feel like 0.4 compat is smoke and mirrors |
| 18:18:48 | rue | headius: Well, I am sorry, but the merbist article contradicts you so you lose ;) |
| 18:18:53 | sandal | Since it's still basically YARV |
| 18:19:02 | headius | rue: I hear it will be 5x faster than C |
| 18:19:02 | sandal | even if it has been gutted to run on ObjC |
| 18:19:12 | sandal | A million times faster than FORTRAN |
| 18:19:14 | headius | sandal: yeah, I think it was really accidental compatibility |
| 18:19:34 | headius | I know from experience it gets harder and harder as you go too |
| 18:19:52 | headius | getting String#[] basically working is easy |
| 18:19:53 | sandal | Though, it is really sort of cool that if someone wanted to build a desktop app that pooped out a PDF, it'd be really easy to do with Prawn |
| 18:19:57 | rue | sandal: Were the M17N examples running for you? |
| 18:20:04 | headius | sandal: Write Once, Run Anywhere! |
| 18:20:22 | sandal | rue: yes. |
| 18:21:16 | sandal | but probably not sjis, just run rake examples |
| 18:22:09 | rue | On Rubinius, getting an invalid UTF-8 error |
| 18:22:53 | evan | headius: have you tried using $1 on macruby experimental? |
| 18:22:56 | rue | In the chinese, specifically |
| 18:22:56 | evan | i wonder if it works |
| 18:23:14 | headius | no, but I tried backref...it's still global |
| 18:23:32 | sandal | rue: I'll check it |
| 18:24:17 | headius | yep, still global, a field on RoxorVM |
| 18:24:40 | headius | that's the sort of thing they're going to try to fix at some point and say "oh, darn" |
| 18:25:01 | sandal | rue: no problems |
| 18:25:01 | headius | I know I've said it several times |
| 18:25:04 | sandal | on prawn-0.4.1 |
| 18:25:20 | sandal | $ rbx -v |
| 18:25:20 | sandal | rubinius 0.11.0-dev (ruby 1.8.6) (1ef0d03be 12/31/2009) [i686-apple-darwin9.6.0] |
| 18:25:42 | sandal | But I just built this from github on master |
| 18:25:55 | tilman | headius: hah, i thought you were poking fun at them when you mentioned roxorvm, before i hit google :] |
| 18:26:05 | evan | headius: you think they'll say "oh darn" and just never fix it? |
| 18:26:13 | evan | because they'll run into a lot of troubles |
| 18:26:16 | evan | running code |
| 18:26:44 | sandal | rue: built from: 080585... Teach JIT properly about all manner of argument passing |
| 18:26:44 | headius | evan: they can't avoid it, I guarantee |
| 18:26:57 | headius | there's way too many string and regexp methods that pass information via $~ and code out there that expects it |
| 18:28:45 | evan | yep |
| 18:28:49 | evan | we hit it early and often |
| 18:28:58 | evan | because there is some kernel code that depends on it's behavior |
| 18:29:00 | evan | as I recall |
| 18:30:02 | rue | Mm. About 9x |
| 18:31:46 | evan | slava: poke |
| 18:31:53 | rue | On the upside, our startup time is less than JRuby's :) |
| 18:32:00 | slava | evan: hi |
| 18:32:36 | evan | slava: whats the code path for calling a quotation look like? |
| 18:32:46 | evan | there is a data structure around a quotation, yes? |
| 18:33:11 | rue | Well, actually, I lie, startup time + doing a glob and a loop |
| 18:33:11 | slava | evan: it jumps to the machine code stored at the address in the 'xt' slot |
| 18:33:24 | slava | evan: if it hasn't been compiled yet, this slot points at the vm function which compiles it and patches the xt |
| 18:33:28 | evan | wanna point me to the place where that happens in the code? |
| 18:33:44 | slava | the actual call? |
| 18:34:04 | slava | basis/cpu/x86/bootstrap.factor line 248 |
| 18:34:09 | slava | its not very interesting, just a handful of insns |
| 18:34:43 | slava | remember that most quotations are optimized out completely so this is only used for the handful of 'dynamic' ones that remain at run time |
| 18:35:25 | evan | sure |
| 18:35:54 | slava | are you implementing JIT support for blocks? |
| 18:36:07 | evan | yep |
| 18:36:14 | slava | so every block will cache its machine code? |
| 18:36:23 | evan | yeah |
| 18:36:32 | slava | btw there is an associated data structure, every quotation has an array; its used for compiling and printing |
| 18:36:36 | evan | i recently refactored BlockEnvironment so there is a function pointer it stores |
| 18:36:44 | evan | which is called to do the work |
| 18:36:45 | slava | that sounds reasonable |
| 18:36:49 | slava | what's the calling convention? |
| 18:36:54 | evan | right now, that always points to one that runs it in the interpreter |
| 18:37:07 | evan | so just need to have that one keep a call count |
| 18:37:15 | evan | and do a substitution |
| 18:37:25 | evan | call convention is simple |
| 18:37:28 | slava | yeah, that sounds reasonable |
| 18:37:31 | evan | C style |
| 18:37:37 | evan | always with 4 arguments |
| 18:37:40 | slava | when I do a dynamic quotation call, I put the quotation in EAX |
| 18:37:49 | rue | Hih, a profile run is "slightly" slower |
| 18:37:54 | slava | compiled quotations ignore EAX (they don't need a pointer to themselves) but if the xt is a pointer to the shared 'compile me' stub, it looks at EAX |
| 18:38:03 | evan | slava: gotcha |
| 18:38:09 | evan | yeah, i haven't gotten that low yet |
| 18:38:10 | evan | soon though. |
| 18:38:21 | evan | there is still too much code between 2 JITd functions |
| 18:38:48 | evan | hm, i could play with implementing my own call convention in LLVM |
| 18:38:53 | evan | that is actually supported |
| 18:38:54 | evan | :D |
| 18:38:58 | slava | I also have some dynamic type checking; the (call) primitive defined in bootstrap is not called directly, the user uses the call word which won't crash if you pass a string for example |
| 18:39:08 | slava | EAX is just the first argument for fastcall functions on x86 |
| 18:39:24 | slava | so its just void lazy_jit_compile(cell quot); |
| 18:39:49 | slava | also in some cases dynamic calls have to check that the quotation's stack effect is what you want; so it can get quote expensive too |
| 18:40:02 | slava | the ruby equivalent would be checking if a block has the right number of args |
| 18:40:06 | slava | you can optimize it out sometimes |
| 18:40:30 | evan | yep |
| 18:40:36 | evan | i actually did that recently |
| 18:40:47 | evan | there is an Arguments object that is passed down |
| 18:40:49 | sandal | Ut oh, I think I've been spreading some lies about Prawns examples :-/ |
| 18:40:53 | slava | or if the block is literal, inline the body of the bloc at the call site; this is what eliminates 90% of quotations at run time for me |
| 18:41:00 | evan | and 4 bytecodes that are emitted to handle blocks args |
| 18:41:34 | evan | slava: you inline them since the compiler can see what the person they're passed to is doing with them, yes? |
| 18:41:34 | slava | you probably can't do this until you have type feedback |
| 18:41:50 | slava | evan: I just let the user declare words 'inline' explicitly because I'm cheap |
| 18:41:59 | evan | [ blah ] 100 times |
| 18:42:02 | evan | for instance |
| 18:42:08 | slava | and times has an inline declaration |
| 18:42:18 | evan | what if it doesn't? |
| 18:42:19 | rue | sandal: What'cha find? |
| 18:42:20 | slava | its early-bound |
| 18:42:27 | slava | evan: if it doesn't, then it uses the dynamic quotation calling sequence |
| 18:42:31 | evan | ah! |
| 18:42:33 | sandal | an embarassing mistake, let me check |
| 18:42:33 | slava | which entails a check and an indirect jump |
| 18:42:38 | evan | so you're doing inlining based on pragma |
| 18:42:42 | slava | yes |
| 18:43:46 | evan | slava: so, do users of libraries mark their functions as inline? |
| 18:44:04 | slava | generally only those that take quotation parameters |
| 18:45:03 | slava | evan: this optimization is pretty essential since even 'if' is implemented as a higher-order function, as well as all loops, etc |
| 18:45:17 | slava | it would really suck if everything had to check and indirect jump all the time |
| 18:45:48 | evan | oh sure |
| 18:45:51 | evan | just curious |
| 18:45:51 | slava | evan: in the Joy language, quotations are lists, there's no inlining, and everything is interpreted; the interpeter just traverses these lists |
| 18:45:59 | slava | I used to think it was impossible to implement this model efficiently |
| 18:46:10 | slava | turns out its possible, but there's a few compromises along the way that have to be made |
| 18:46:54 | sandal | rue: I need to re-run the whole prawntest |
| 18:47:06 | sandal | Turns out using backticks in rake files and forgetting about that is evil |
| 18:47:08 | evan | slava: interesting |
| 18:47:22 | sandal | The good news, Rubinius does render all the examples perfectly |
| 18:47:24 | evan | slava: don't tell me nothing was running for rubinius :/ |
| 18:47:28 | evan | er. |
| 18:47:28 | sandal | the bad news, is it took 139s |
| 18:47:32 | evan | sandal: ^^ |
| 18:47:47 | sandal | where I get times around 15s on MRI |
| 18:47:48 | evan | sandal: well, thats not outside the realm of possibility |
| 18:47:51 | evan | sure |
| 18:47:59 | sandal | Sure, I think it's what I would have initially expected |
| 18:48:02 | evan | we know people are getting resuls like that |
| 18:48:09 | evan | we're working hard to fix that. |
| 18:48:17 | sandal | But I didn't know by what magic Rubinius was getting around to the same speed of MRI |
| 18:48:22 | sandal | when I was testing earlier |
| 18:48:39 | sandal | it was misleading because my tests were getting run through right |
| 18:48:55 | evan | were they doing `ruby ... ` |
| 18:48:59 | sandal | Hahaha, yes |
| 18:49:02 | evan | hah |
| 18:49:04 | evan | ah well |
| 18:49:09 | sandal | facepalms |
| 18:49:09 | evan | at least you caught it now |
| 18:49:19 | sandal | Right, I think people would call bullshit if I said |
| 18:49:27 | slava | evan: so dynamic quotations get compiled with the shit compiler, and words do too initially, during bootstrap the real compiler is loaded and it replaces the word compilation hook with the non-shit compiler hook |
| 18:49:34 | sandal | "Amazingly Prawn runs as fast MRI on Rubinius" |
| 18:49:49 | sandal | I should have done that myself, I just wasn't thinking about the times earlier |
| 18:49:52 | sandal | at all |
| 18:49:56 | evan | sandal: yes, so long as in rubinius, it's |
| 18:50:02 | evan | exec "ruby", *ARGV |
| 18:50:05 | sandal | I've been in a haze the last couple days. |
| 18:50:35 | sandal | yeah, I thought I had used something safer for running those files |
| 18:50:36 | evan | slava: so dynamic quotations are always slow? |
| 18:50:45 | sandal | anyway, headius now I'll find out if I have good or bad news for you :) |
| 18:50:56 | slava | evan: relatively speaking, yeah. any words they call are still optimized, though |
| 18:51:03 | sandal | I'm pretty sure it'll be good news because the tests do pass there |
| 18:51:25 | evan | slava: sure, but if a no inlining into a quoation then, for instane |
| 18:51:27 | headius | sandal: should be at least close to MRI, modulo startup and warmup |
| 18:51:53 | sandal | based on the tests, that's what I'd expect |
| 18:52:28 | rue | Here is a profile of a .load run http://gist.github.com/120095 |
| 18:53:01 | rue | sandal: Those times are around what I see |
| 18:55:01 | sandal | headius: takes 26s, MRI 1.8.6 13s |
| 18:55:12 | sandal | but 26s was what I was getting on MRI before I optimized it |
| 18:55:30 | sandal | so it may be skewed do to something like pthreads or something else |
| 18:55:55 | evan | wow |
| 18:56:05 | evan | Prawn must really be leaning on String#pack |
| 18:56:09 | evan | and String#unpack |
| 18:56:18 | sandal | yeah, before toying with MRI: 33.949722 seconds |
| 18:56:21 | sandal | evan: very heavily |
| 18:56:26 | sandal | Because of TTFunk |
| 18:56:34 | evan | thats why it's crazy slow |
| 18:56:44 | sandal | http://github.com/sandal/ttfunk |
| 18:56:47 | evan | our pack hasn't been touched, performance wise |
| 18:56:59 | sandal | Yeah, obviously binary extraction will be faster in a non-ruby language :) |
| 18:57:27 | evan | sandal: righto |
| 18:57:38 | sandal | I'll point that out in my talk. |
| 18:59:32 | brixen | sandal: oh btw, element_referenc_spec.rb comes from ri Array#[], the docs call it Element Reference |
| 18:59:44 | brixen | sandal: just a trivia fyi |
| 18:59:44 | sandal | ahh, okay |
| 19:00:08 | sandal | Cool, we do a lot of weird search stuff in my work, so I may provide aliases in both directions |
| 19:00:42 | brixen | sandal: there's a name_map.rb in mspec that converts the names |
| 19:00:42 | sandal | I feel like I keep writing "Parse this no matter what the fuck you call it" again, and again, and again :) |
| 19:00:52 | brixen | we could probably make it bi-dir |
| 19:00:53 | sandal | brixen: Awesome! very helpful, thanks |
| 19:01:39 | sandal | headius: yeah, my guess is that whatever java I'm using just isn't optimized well |
| 19:01:42 | sandal | headius: http://blog.majesticseacreature.com/archives/2009.02/lies_and_statistics.html |
| 19:02:40 | headius | sandal: what java version? |
| 19:02:58 | headius | java 5 is slower, all java versions are slower unless you specify --server flag to jruby |
| 19:03:08 | sandal | whatever is on my mac |
| 19:03:12 | headius | java 6+ with --server |
| 19:03:15 | headius | mac |
| 19:03:18 | headius | probably java 5 |
| 19:03:22 | headius | you could try passing --server |
| 19:03:26 | headius | jruby --server -S rake examples |
| 19:03:42 | headius | if you have java 6 it would be another 20-30% faster than that |
| 19:04:08 | rue | sandal, evan: Updated with self/s sorting |
| 19:04:11 | headius | sandal: http://gist.github.com/23190 |
| 19:04:22 | headius | source that and you'll be able to easily switch command-line "java" versions |
| 19:04:39 | headius | adds a "pickjdk" command |
| 19:05:23 | sandal | headius: it's java 5 |
| 19:05:42 | sandal | I'm not going to game it by switching what I have installed here, but I'll make a note of it. I will try the --server option |
| 19:06:00 | headius | from java 5 client to java 6 server it will be easily 2x once warmed up |
| 19:06:01 | sandal | I'll mention to folks that Java 6 performs better |
| 19:07:14 | sandal | this kills the startup cost? |
| 19:07:40 | headius | no, startup will be about the same, but "server" is the optimizing JVM JIT |
| 19:07:56 | headius | makes a very large perf difference for jruby |
| 19:08:09 | rue | evan: On the upside, getting the unpacking straightened would be an instant 30-40% improvement :) |
| 19:08:48 | evan | yep! |
| 19:08:59 | evan | JIT'ing blocks will help too |
| 19:09:04 | evan | those use a lot of blocks. |
| 19:10:11 | headius | I need to add block jitting one of these days |
| 19:11:03 | rue | The kerning method taking that long is weird |
| 19:11:27 | rue | Though I suppose it is a lot of data? |
| 19:12:29 | sandal | rue: Yeah, it need to parse out kerning data for CJK fonts from a binary file |
| 19:12:37 | rue | Seeing if not JITting makes much difference |
| 19:12:42 | rue | Profile-wise |
| 19:12:52 | evan | rue: oh oh |
| 19:13:05 | evan | it's very possible profiling with the JIT on is busted |
| 19:13:40 | evan | I need to put the calls to start and stop profiling in |
| 19:14:07 | headius | sandal: you could also try passing --fast to jruby, though I'd be surprised if it fully functions |
| 19:14:11 | headius | it's not quite there yet |
| 19:15:04 | rue | evan: Yeah, the comparison should shed some light there |
| 19:15:51 | sandal | ? examples.each { |file| `jruby --server -Ilib #{file}` } |
| 19:15:58 | sandal | headius: why wouldn't that work? |
| 19:16:12 | evan | rue: i'll see if i can get it wired back in today |
| 19:16:15 | evan | yes, we need it. |
| 19:16:45 | rue | sandal: It reloads the server each time |
| 19:17:03 | rue | sandal: For what it is worth, I am doing an -e glob and loading all the files |
| 19:17:30 | headius | sandal: ick, is that how you're loading them? |
| 19:17:36 | sandal | hehehe |
| 19:17:40 | headius | that means JVM + jruby startup every time |
| 19:17:40 | sandal | I know |
| 19:17:47 | headius | like an extra .5-1s every time |
| 19:17:51 | sandal | Yeah, I should be doing better |
| 19:17:58 | headius | you could use nailgun |
| 19:18:11 | sandal | I really don't have time for all this infrastructure |
| 19:18:15 | sandal | (right now) |
| 19:18:20 | headius | run jruby --ng-server & and then use jruby --ng for your client :) |
| 19:18:25 | headius | all will use one JVM then |
| 19:18:30 | headius | ok |
| 19:18:37 | headius | you can prod me when you want all the details |
| 19:18:51 | sandal | Sure, and I almost certainly will because I have a real JRuby based project now |
| 19:18:54 | sandal | but Prawn isn't it :) |
| 19:19:34 | rue | evan: Updated |
| 19:19:36 | sandal | I'm just going to report the stock results without any extra stuff. I'll point out that there are many ways to optimize it |
| 19:19:38 | rue | Significantly different |
| 19:19:46 | evan | rue: with what? |
| 19:20:02 | headius | sandal: nice, I'd like to hear about that when you have time (on #jruby of course) |
| 19:20:36 | evan | rue: hm. I don't think any JITd methods will show up in here |
| 19:20:39 | rue | evan: Without -Xjit.enabled (but built with LLVM) |
| 19:20:51 | evan | i'm confused. |
| 19:21:17 | sandal | headius: it's just my FFI wrapper + a Sinatra web service for some windows truck routing sofwtware |
| 19:21:22 | sandal | The web service is not yet built |
| 19:21:32 | evan | rue: what did you change? |
| 19:21:39 | sandal | As I mentioned before, I think it's funny, awesome, and sad, that JRuby is the best platform on windows for that |
| 19:22:07 | evan | rue: just the sorting? |
| 19:22:12 | rue | evan: Top one is with -Xjit.enabled, middle one without |
| 19:22:23 | rue | Last one is % sort, with more data |
| 19:22:50 | sandal | You know what, I'm not reporting times for the example runs, just order. I'm more interested in the fact that they run |
| 19:22:56 | evan | using the profiler with JIT on is likely not going to give you accurate results |
| 19:23:17 | rue | I did see Array#index there in the bottom one...so it is only counting the ones before it is compiled? |
| 19:23:22 | sandal | Right now it looks like Rubinius < JRuby < MRI and I need to test REE |
| 19:23:34 | sandal | and MacRuby 0.4 ~= YARV |
| 19:23:38 | evan | rue: yes, very likely |
| 19:23:43 | evan | once they are compiled |
| 19:23:46 | evan | they don't show up anymore |
| 19:23:56 | evan | rue: what about raw time |
| 19:23:57 | sandal | but i'll put a little (*) on both JRuby and Rubinius |
| 19:24:02 | sandal | Rubinius due to pack() |
| 19:24:03 | evan | with and without -Xjit.enabled |
| 19:24:07 | sandal | JRuby due to config |
| 19:24:27 | sandal | examples and tests are what I care about |
| 19:24:50 | sandal | JRuby won the Prawntest because it's the only implementation to go green on the tests :) |
| 19:25:00 | evan | sandal: not even MRI? |
| 19:25:12 | sandal | MRI and YARV are benchmarks |
| 19:25:17 | headius | sandal: ahh, yeah, there's a lot of people using simple sinatra services to wrap jruby stuff |
| 19:25:17 | sandal | They're excluded |
| 19:25:40 | rue | evan: With JIT, about 132s...running without now |
| 19:25:50 | sandal | The best implementation to run Prawn on is likely YARV for Ruby 1.9 / m17n, and JRuby for 1.8 |
| 19:26:17 | rue | So yeah, that Array#index in that presumably huge Array is probably a bit slow |
| 19:26:21 | sandal | Prawn does encoding coercion on 1.9, so the reusts are not comparable |
| 19:26:28 | sandal | *results |
| 19:27:38 | sandal | Time to check macruby again |
| 19:28:01 | evan | rue: interesting |
| 19:28:08 | evan | rue: did the no jit run finish? |
| 19:28:23 | rue | evan: About 162s |
| 19:28:49 | sandal | fire up good old MacRake |
| 19:28:56 | evan | rue: ok, thats good |
| 19:28:56 | rue | That last_match thing, too.. |
| 19:28:57 | sandal | with some MacRibs |
| 19:29:04 | evan | we're staying in the + column for the JIT |
| 19:29:06 | evan | thats good |
| 19:30:28 | headius | MacRibs, mmm |
| 19:31:38 | rue | I wonder if it would be worth it to sort a huge array and binary search for index :) |
| 19:32:00 | evan | heh |
| 19:32:09 | evan | well, for index |
| 19:32:25 | evan | hm |
| 19:32:31 | evan | yeah, i guess you need it to be sorted to do binary search |
| 19:32:53 | sandal | whoa, this is MacFail |
| 19:34:21 | sandal | http://pastie.org/494274 |
| 19:35:55 | sandal | looks like almost all the stuff associated with image processing failed |
| 19:36:34 | evan | yikes |
| 19:36:47 | sandal | and M17n |
| 19:36:53 | sandal | (aside from UTF-8) |
| 19:37:19 | sandal | I think open-uri segfaults |
| 19:37:53 | rue | Nope, not a big Array...it *is* pretty slow, and getting called a lot |
| 19:38:42 | headius | sandal: that's 0.4 I assume |
| 19:38:44 | headius | ? |
| 19:38:51 | sandal | MacRuby 0.4, yes |
| 19:39:09 | sandal | oh wait |
| 19:39:11 | evan | rue: ah! |
| 19:39:12 | sandal | I may be lying again |
| 19:39:22 | sandal | Man... I really hate this stuff |
| 19:39:22 | evan | rue: if you change index to use |
| 19:39:27 | evan | @tuple.at(@start + i) |
| 19:39:30 | evan | rather than at(i) |
| 19:39:35 | evan | the JIT will do a better job |
| 19:39:35 | sandal | How do you guys keep track of all these details? |
| 19:39:41 | evan | because it will inline Tuple#at |
| 19:39:57 | rue | evan: Yeah...I think the #at was a part of the API layer effort |
| 19:40:07 | evan | i believe so |
| 19:40:08 | sandal | I don't consider myself very sloppy, but when it comes to doing anything with sys-admin, I fail epic |
| 19:40:43 | evan | rue: we can teach the JIT about Array#at too |
| 19:40:47 | evan | i think we use a prim for it |
| 19:41:00 | evan | anything thats a prim is pretty easy to teach the JIT about |
| 19:41:15 | rue | The default is the primitive, yes |
| 19:41:41 | evan | we should definitely teach the JIT about Array#at then |
| 19:41:46 | evan | because it's used a lot. |
| 19:41:46 | sandal | oh waitwait, maybe false alarm |
| 19:41:52 | sandal | I think these are the results for macruby 0.4 |
| 19:41:53 | evan | it's the workhorse of the Array code |
| 19:43:27 | sandal | $ which macruby |
| 19:43:28 | sandal | /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/bin//macruby |
| 19:43:36 | sandal | does that look like it should be 0.4? |
| 19:43:44 | sandal | that is what which macruby returns now |
| 19:44:01 | rue | ? |
| 19:44:07 | rue | `macruby -v` ? |
| 19:44:24 | sandal | yeah, gives 0.4 |
| 19:44:25 | sandal | but I wasn't sure if 0.5 version# was updated yet |
| 19:44:33 | sandal | okay, generating the same giant stream of WTF |
| 19:44:44 | sandal | so I need to retract my statement about MacRuby |
| 19:44:56 | rue | 0.5 does not run much yet |
| 19:45:57 | sandal | I know that much |
| 19:46:11 | sandal | But I previously reported that 0.4 ran all the examples |
| 19:46:13 | rue | evan: "Inlining" the #at call makes pretty much no difference...figured I would try it |
| 19:46:24 | sandal | it's actualy only running some successfully |
| 19:46:33 | evan | rue: ie, doing @tuple.at(@start + i) |
| 19:46:40 | evan | mmmzers |
| 19:46:41 | evan | ok |
| 19:46:51 | rue | Right |
| 19:47:26 | rue | Looks like the biggest Array is <300 elements...so it is still kind of odd |
| 19:48:46 | evan | hm. |
| 19:48:47 | evan | yeah |
| 19:49:37 | sandal | Okay, so Prawn is not really usable on MacRuby yet |
| 19:49:51 | sandal | Because it only renders the basic stuff |
| 19:50:00 | sandal | built-in fonts and line drawings and stuff |
| 19:50:46 | sandal | Basically, sounds like they've got a messed up pack/unpack, or weird m17n issues that are warping my binaries |
| 19:51:18 | sandal | aha! |
| 19:51:20 | sandal | irb(main):001:0> File.binread |
| 19:51:20 | sandal | NoMethodError: undefined method `binread' for File:Class |
| 19:51:46 | sandal | because of this, Prawn will provide a binread method that just does, File.open("foo", "rb") { |f| f.read } |
| 19:52:01 | sandal | so my guess is that the majority of these errors come from treating binary files like they're UTF-8 |
| 19:56:26 | rue | The b really should not matter on non-Winders |
| 20:11:15 | sandal | rue: this is not true for 1.9 |
| 20:11:16 | sandal | at all |
| 20:11:37 | sandal | The b sets external encoding to BINARY |
| 20:11:42 | sandal | That's in my talk :) |
| 20:11:54 | sandal | you can of course do this explicitly |
| 20:12:01 | sandal | but "b" implicitly does |
| 20:12:10 | sandal | but if MacRuby doesn't do that, it's not 1.9.1 compatible |
| 20:12:35 | rue | Hm, weird. |
| 20:12:43 | sandal | you'll have all sorts of fun playing with binary files on Ruby 1.9.1 if you forget to set this, since Ruby will just check your locale for settings |
| 20:13:01 | sandal | Mine is UTF-8, so... it'd think a binary was made out of UTF-8 |
| 20:13:08 | sandal | and access it accordingly |
| 20:13:25 | sandal | but yours may be different |
| 20:13:26 | rue | Really wish they had made a library out of it |
| 20:13:33 | sandal | that's why portable code must be explicit |
| 20:13:37 | sandal | the m17n stuff? |
| 20:13:41 | rue | Yes |
| 20:13:43 | sandal | It'd be way too hard |
| 20:13:49 | sandal | it's a very complicated system |
| 20:14:22 | sandal | Though it'd be interesting to see what 1.9 (YARV based) would look like with all that stripped out |
| 20:24:54 | rue | Well, I am not sure about the entire M17N thing to begin with, but perhaps it is too intractable |
| 20:37:32 | rue | brixen: OK to change the precision for the ms figures? Or is that beyond accuracy anyway? |
| 20:42:43 | evan | rue: likely beyond accuracy |
| 20:46:23 | rue | Wtf...my spec runtime log is gone :/ |
| 20:48:18 | rue | Well, it purports to have data...dunno how accurate |
| 20:48:42 | rue | Enumerable#inject => 0.003ms/call |
| 20:50:29 | evan | rue: well, is data that tiny useful though? |
| 20:52:15 | rue | Well, 's kind of better than half the stuff having 0.00 there |
| 20:52:23 | rue | But I will leave it up to brixen to change |
| 20:52:33 | evan | yeah |
| 20:52:41 | evan | we talked about not even showing ones with 0.00 |
| 20:53:05 | rue | The number of calls is significant, though |
| 20:53:19 | evan | maybe thats why he left it in |
| 20:53:49 | rue | String#[] is 0.00 but it is called 3,4m times so its total time is almost 14s |
| 20:54:13 | evan | ah ah |
| 20:54:15 | evan | i see what ya mean |
| 20:54:18 | evan | right |
| 20:55:31 | rue | So it is something like 0.004ms/call |
| 20:56:08 | evan | it's nice to have the .'s lined up |
| 20:56:16 | evan | but isn't strictly necessary |
| 20:56:26 | evan | for the ones that are like 20154.32 |
| 20:56:31 | evan | the .32 is insignificant |
| 20:57:10 | evan | so maybe if it's over 100, leave off the decimal places |
| 20:57:32 | evan | and if it's under 0.1, add an extra |
| 20:57:40 | evan | so 20134.32 becomes 20134 |
| 20:57:44 | evan | and 0.00 becomes 0.003 |
| 20:58:18 | evan | anyway, i need a lunch! |
| 20:58:26 | rue | Yep yep |
| 20:58:49 | sandal | http://pastie.org/494392 |
| 20:58:52 | sandal | Results of Prawn test |
| 20:59:01 | sandal | Totally ridiculous |
| 20:59:37 | rue | Aww, no tests? |
| 20:59:51 | sandal | Because of the Module#name issue |
| 21:00:05 | sandal | If I got a patch to test-spec working in time it could be different |
| 21:00:19 | evan | sandal: we'll fix than in rubinius today |
| 21:00:25 | evan | likely right after lunch |
| 21:00:28 | evan | so you can run them |
| 21:00:33 | sandal | evan: Okay, well I'll give it a try |
| 21:00:50 | sandal | Even if it fails some, you can at least pick up half a point :) |
| 21:01:26 | rue | evan: @__name__ ? |
| 21:01:30 | sandal | Basically, I'm excited about all this stuff, the stories behind the scores are more interesting |
| 21:01:41 | sandal | and the prawntest itself is mostly a joke |
| 21:01:46 | evan | no no |
| 21:01:49 | sandal | though I'm glad that something productive has come out of it |
| 21:01:50 | evan | @module_name |
| 21:02:10 | evan | ok, lunch time. |
| 21:02:12 | rue | Then someone will just use that as their accessor name :/ |
| 21:02:19 | sandal | evan: I'll check it late tonight |
| 21:02:21 | evan | we'll deal with that then. |
| 21:02:23 | sandal | so if you fix it, I'll re-run |
| 21:02:40 | evan | ok really lunch |
| 21:02:44 | rue | Underscores would follow the __send__ etc. policy |
| 21:03:01 | headius | new tagline: JRuby is XXX according to sandal |
| 21:03:14 | rue | headius: And no mention of Java ;) |
| 21:04:28 | headius | JRuby: Ruby EXXXTREME |
| 21:04:55 | rue | Alright now, let us not get carried away |
| 21:24:09 | rue | From #ruby-lang, someone noticed that Class.new calls inherited after executing the body |
| 21:57:43 | dgtized | evan: out of curiousity why is it we are storing the module name in an instance variable, and not simply installing a name method that returns the constant value? |
| 21:59:32 | evan | because it seems silly to generate all those methods |
| 22:00:46 | rue | If the method gets overridden, there is no recourse |
| 22:00:46 | dgtized | hmm -- I guess I'm not quite following why it's silly in this case |
| 22:01:30 | evan | why generate 1000 methods that return a symbol because there are 1000 modules |
| 22:01:39 | dgtized | rue: but in mri you can override name |
| 22:02:11 | dgtized | module Foo; def self.name; return "blah"; end; end |
| 22:02:54 | evan | dgtized: whats your point? |
| 22:03:01 | evan | i don't get where you're going |
| 22:03:40 | dgtized | my point with the example was simply I didn't follow why an override bothered rue |
| 22:04:32 | headius | have to store the name somewhere |
| 22:04:41 | headius | unless you generate a new name method that returns a literal for every class |
| 22:04:48 | dgtized | headius: that's what I was suggesting |
| 22:04:59 | evan | thats just super wasteful |
| 22:05:01 | headius | ok :) and I think evan doesn't like that |
| 22:05:14 | headius | I tend to agree, since there's thousands of classes in rails |
| 22:05:14 | evan | and if thats the only place the name lives |
| 22:05:24 | evan | and someone changes .name |
| 22:05:31 | evan | you've lost the ability to find out the real name of thing |
| 22:05:34 | evan | which is needed. |
| 22:05:35 | headius | plus that wouldn't be semantically right |
| 22:05:47 | headius | it would have name methods defined on every class, which changes the overriding behavior |
| 22:05:56 | evan | yep |
| 22:06:00 | headius | rather than a single name defined on Module |
| 22:06:13 | evan | so, in name's case |
| 22:06:15 | evan | it's actually a slot |
| 22:06:33 | evan | the VM lowers the @name syntax to access the proper slot |
| 22:06:43 | evan | i could, instead, have it use __slotname__ |
| 22:06:49 | evan | i think we discussed that at one point |
| 22:07:18 | evan | so it would still be Module::name_ in the VM, but would be accessed as @__name__ in ruby code |
| 22:08:32 | evan | thats a little strange, but not the end of the world |
| 22:09:08 | dgtized | I guess partially perhaps I don't quite follow the conditions that are actually setting @name in the kernel code since we have this set_name_if_necessary method |
| 22:09:39 | evan | ignore that method |
| 22:09:50 | evan | it has no relation to this discussion |
| 22:09:55 | dgtized | ok |
| 22:10:06 | dgtized | it's only in VM code that we really care about this then? |
| 22:10:15 | evan | exactly the opposite |
| 22:10:25 | evan | it's in ruby code |
| 22:10:37 | evan | dgtized: did you follow the discussion from the last few days about this? |
| 22:11:03 | dgtized | I follow that in ruby code that's where we can override and it messes things up, but I'm not following where in the Kernel code we depend heavily on the value of Module.name |
| 22:11:25 | evan | thats not the issue |
| 22:11:34 | evan | you've got the reasoning for this problem wrong |
| 22:12:06 | evan | 1) Rubinius stores the name of a Module in @name |
| 22:12:17 | evan | 2) Module#name is an accessor for that ivar |
| 22:12:48 | evan | 3) test/spec used attr_accessor :name and then tried to do Blah.name = "fun times" |
| 22:13:00 | evan | 4) This caused a TypeError because the VM needs @name to be a Symbol |
| 22:13:10 | evan | THATS the problem. |
| 22:13:21 | evan | so we've been discussing solutions to this |
| 22:13:26 | evan | one being, change @name in Module |
| 22:13:45 | evan | so that test/spec can happily do attr_accessor :name |
| 22:14:04 | evan | anyway, this discuss is largely over |
| 22:14:11 | evan | i'm going to just change it to be @module_name for now. |
| 22:14:26 | evan | discussion |
| 22:15:18 | headius | evan: I have an idea for a library that monkey-patches attr_accessor :module_name into Module, what do you think? |
| 22:15:38 | headius | hey, macruby experimental status update |
| 22:15:39 | headius | nifty |
| 22:16:12 | evan | headius: yes, i know it's a kludge. |
| 22:16:20 | evan | sue me. |
| 22:16:46 | headius | add a compiler plugin that turns @int_name into some impossible-to-access name |
| 22:17:01 | headius | like __name__ without the @, internal variables like MRI |
| 22:17:34 | headius | or an opcode for accessing internal variables |
| 22:17:45 | evan | i've got the opcode |
| 22:17:45 | headius | intvar_get, intvar_set |
| 22:18:11 | evan | it's always been a question of how it's accessed in ruby |
| 22:18:12 | headius | kludge is fine for now, of course :) |
| 22:18:29 | headius | with your compiler transforms that should be easy now though |
| 22:18:41 | headius | recognize fcalls to intvar_get and intvar_set as the opcode |
| 22:18:54 | evan | whats intvar |
| 22:19:22 | dgtized | internal variable |
| 22:19:28 | evan | so what |
| 22:19:32 | evan | intvar_get :name |
| 22:19:35 | evan | ew. |
| 22:19:49 | evan | no thankyou. |
| 22:20:33 | dgtized | I guess the problem is that there are places where we have nice cleanly delimited turtles, and we have other places where the turtles are mutant half turtle, half vm |
| 22:20:43 | evan | not really |
| 22:20:59 | evan | the whole point is that the code, no matter where the data is stored, is accessible like normal ruby data |
| 22:21:06 | evan | which, as we see, has it's ups and downs. |
| 22:22:08 | headius | and you know I don't hold that as sacred, so feel free to ignore me :) |
| 22:22:24 | headius | no pure-ruby solution is going to be unbreakable |
| 22:22:50 | evan | i'm fine with it not being unbreakable |
| 22:23:11 | evan | the code in the kernel would be so fucking gross if we have to use some ugly indirection to access the common data |
| 22:23:18 | evan | it's in every method |
| 22:23:35 | evan | yes yes, put it behind accessors, i've heard that before. |
| 22:23:45 | evan | then there are a zillion crap methods. |
| 22:24:39 | headius | no, just two: intvar_get and intvar_set :) |
| 22:24:49 | headius | for most of these cases you could just use internal vars and be done with it |
| 22:25:06 | headius | you could even do the transformation against the full name |
| 22:25:10 | dgtized | which disappear in a flash of JIT inlining? -- anyway, I mostly agree, I'm just trying to think about likely issues in places like Array.tuple |
| 22:25:26 | headius | intvar_get_name => opcode intvar_get "name" |
| 22:25:42 | evan | would you do that to your java code? |
| 22:26:35 | headius | our java code isn't breakable by ruby dweebs |
| 22:26:40 | evan | if it was |
| 22:26:46 | headius | yes ;) |
| 22:26:46 | evan | i'm saying |
| 22:26:58 | headius | because there's very few internal variables that would need it |
| 22:27:03 | evan | i'm not, at this point, willing to deal with it being so ugly. |
| 22:27:12 | headius | so do a prettier version :) |
| 22:27:13 | evan | headius: thats not true |
| 22:27:22 | evan | you don't use ivars for any internal data on any class |
| 22:27:39 | evan | so every data member on every class had to be accessed via some side entrace |
| 22:28:18 | evan | dgtized: as for inlining, since i'm the only one working on that, i'm not going to hang my hat on inlining to do future work |
| 22:28:27 | evan | by cluttering it up even more now. |
| 22:28:34 | evan | with extremely limited payoff |
| 22:29:21 | evan | we all have to draw lines somewhere |
| 22:29:27 | evan | and i'm drawing a line here. |
| 22:30:59 | evan | I should note |
| 22:31:14 | evan | that this problem exists for all class we implement in pure ruby |
| 22:31:19 | evan | Method, for instance |
| 22:31:30 | evan | and no manner of internal variable hacks will save us there |
| 22:31:34 | evan | because there are no internal variables |
| 22:35:22 | dgtized | yuck, what's with this @subclasses on Class for ObjectSpace |
| 22:36:19 | evan | so that ObjectSpace.each_object(Class) works |
| 22:36:49 | boyscout | Move Module::name_ to Module::module_name_ to decrease conflicts - f2f4fa8 - Evan Phoenix |
| 22:37:11 | evan | problem solved, for now. |
| 22:37:12 | dgtized | evan: we don't keep around a list of all classes in one of the TypeRoot's? |
| 22:37:37 | evan | no |
| 22:38:10 | evan | well i guess |
| 22:38:13 | evan | but why |
| 22:38:22 | evan | why is that better than @subclasses |
| 22:40:44 | dgtized | Array.instance_variables |
| 22:40:55 | dgtized | I dunno it just surprised me mostly |
| 22:41:48 | evan | so you're arguement is it's not hidden? |
| 22:42:31 | dgtized | when do you garbage collect module definitions? |
| 22:42:44 | dgtized | if they are referenced in __subclasses__ they can't can they? |
| 22:42:59 | evan | a very good point |
| 22:43:03 | evan | we need fix that |
| 22:43:04 | headius | evan: did we ever make @subclasses weak? |
| 22:43:07 | evan | subclasses should be weakrefs |
| 22:43:13 | headius | it's weak in JRuby but I think you had me punt on it when I implemented that |
| 22:43:27 | evan | yep |
| 22:43:35 | evan | someone added it at one point in rubinius |
| 22:43:43 | headius | I did |
| 22:43:51 | headius | maybe someone re-added it, but I did the original impl |
| 22:44:04 | evan | I need to write WeakArray |
| 22:44:19 | headius | yeah, on jruby it's a WeakHashSet |
| 22:44:42 | evan | yeah, or WeakHash |
| 22:45:21 | dgtized | question, is it actually that you need to keep track of all subclasses, or is that we need to keep track of all Classes, because at the very least if it's the second we could just have an ivar on ObjectSpace to deal with that |
| 22:45:37 | dgtized | and then iterate that array checking if it's a subclass of X that you are searching for |
| 22:46:33 | evan | thats just 2 ways of storing the same data |
| 22:46:39 | evan | having @subclasses is faster. |
| 22:47:23 | dgtized | but then we need an extra ivar on every Class def |
| 22:47:49 | evan | so |
| 22:47:53 | evan | why is that bad |
| 22:48:36 | dgtized | my metaclass understanding is weak, but doesn't that increase the cost of metaclasses? |
| 22:48:57 | dgtized | or rather singleton I mean, or eigenclass or whatever the standard nomenclature is |
| 22:49:12 | evan | there is no increased cost |
| 22:49:20 | evan | they perhaps use an extra 4 bytes |
| 22:50:21 | dgtized | alright, I guess it just seemed like better seperation of concerns to have it on objectspace or objectspace walk the actual class definition graph |
| 22:50:31 | dgtized | but maybe I am just splitting hairs |
| 22:51:03 | dgtized | anyway, do you want me to file an issue on the GC problem for @subclasses? |
| 22:51:12 | dgtized | so we don't forget? |
| 22:52:59 | evan | yes please |
| 22:56:29 | dgtized | also, so I gather now we only use the github issue tracker and ignore lighthouse? |
| 22:59:10 | evan | i'm pushing people to the github issue tracker |
| 22:59:15 | evan | it's a bit easier to manage with the code |
| 22:59:45 | headius | @subclasses will be useful for other things |
| 23:00:19 | dgtized | headius: so you just think it should be included in general? |
| 23:13:57 | headius | dgtized: I don't see that it hurts anything |
| 23:15:14 | evan | at this point, probably 90% of each_object usage is to find subclasses |
| 23:15:18 | evan | the other 10% is memory debugging |
| 23:23:02 | rue | I still think it would be simplest to just say that users always fuck with Core classes at their own risk, make it a library issue. Or, alternatively, decree that said rule applies for all methods and variables with double underscores |
| 23:24:11 | rue | Forcing some internal scheme is just ugly |
| 23:55:15 | rue | termtter gets an upvote from me |
| 23:57:00 | rue | Hrm. #10 is a bit iffy |
| 23:58:07 | evan | eh? |
| 23:58:23 | rue | http://github.com/evanphx/rubinius/issues/#issue/10 |
| 23:59:02 | evan | ah |
| 23:59:04 | evan | yes, thats wrong |
| 23:59:12 | evan | I need to use the proper 64bit version |
| 23:59:37 | rue | evan: Which GCC are you running? |
| 23:59:51 | evan | 4.0.1 |