Da
Show enters and exits. Hide enters and exits.
| 00:59:01 | evan | what |
| 00:59:02 | evan | the |
| 00:59:03 | evan | fuck. |
| 00:59:18 | evan | somone please run http://gist.github.com/277671 |
| 00:59:20 | evan | under MRI |
| 00:59:31 | evan | and tell me the time |
| 01:01:22 | brixen | sec.. |
| 01:03:21 | brixen | about 17s under os x 1.8.6 |
| 01:03:29 | evan | ok, change the 3 to s |
| 01:03:34 | evan | and run it again |
| 01:03:45 | brixen | k |
| 01:04:06 | brixen | ~4s |
| 01:04:20 | evan | do you realize how fucking bizarre that is? |
| 01:04:26 | brixen | yes |
| 01:04:36 | jvoorhis | i played along too |
| 01:04:39 | evan | if you RETAIN all those Floats |
| 01:04:41 | brixen | any idea why? |
| 01:04:43 | evan | it's 4x faster. |
| 01:04:45 | jvoorhis | that's incredibly weird |
| 01:04:47 | evan | no fucking clue. |
| 01:04:52 | brixen | so weird |
| 01:05:02 | evan | well |
| 01:05:13 | jvoorhis | 1.8.7 and 1.9.1 behave the same way |
| 01:05:16 | evan | it could be because MRI's object cleanup is slower than it's allocation |
| 01:05:27 | evan | this ends up being a GC benchmark |
| 01:05:30 | brixen | oh, so the gc is running |
| 01:05:33 | brixen | gotcha |
| 01:05:37 | evan | it's gotta be |
| 01:06:00 | brixen | that actually makes sense |
| 01:06:01 | evan | rbx shows the behavior i'd expect more |
| 01:06:07 | evan | it's slower when they're retained |
| 01:06:11 | evan | a little too slow |
| 01:06:13 | evan | honestly |
| 01:06:39 | brixen | wow |
| 01:07:00 | jvoorhis | evan: MRI behaves the same way in both cases if i call GC.disable first |
| 01:07:04 | brixen | 7.4 retaining, 2.1 not |
| 01:07:07 | brixen | in rbx |
| 01:07:12 | evan | yeah |
| 01:07:23 | evan | it's not just the retaining |
| 01:07:28 | evan | it's running write barriers, etc. |
| 01:07:35 | evan | but still |
| 01:07:44 | evan | jvoorhis: where did you put the GC.disable? |
| 01:08:07 | jvoorhis | evan: after require 'benchmark' |
| 01:08:14 | evan | k |
| 01:08:16 | evan | yep |
| 01:08:27 | evan | this is because MRI's object cleanup is so much slower |
| 01:08:30 | evan | i guess |
| 01:08:38 | evan | so retaining them is faster than cleaning them up |
| 01:08:47 | jvoorhis | 1.9.1 flies without GC |
| 01:09:00 | jvoorhis | 1.76sec |
| 01:09:44 | evan | such a wierd behavior. |
| 01:10:05 | jvoorhis | not if you expect a slow GC :) |
| 01:10:21 | evan | well, i expect it to be constantly slow |
| 01:10:34 | evan | this is showing that one particular phase is a lot slower than another |
| 01:11:54 | jvoorhis | i'm just glad allocation isn't as slow as collection :) |
| 02:56:49 | rue | Huh, 1.9.1 has issues with Time Ranges |
| 10:04:35 | khaase | http://github.com/evanphx/rubinius/commit/49d87b85918171a201c306923e5353f57ada9e2f#comments |
| 10:06:32 | dbussink | khaase: it's a special compiler construct |
| 10:07:28 | dbussink | khaase: a special value that be used in the kernel |
| 10:07:37 | khaase | dbussink: so, is it only available when compiling kernel? |
| 10:07:38 | khaase | ok |
| 10:07:42 | dbussink | khaase: yeah |
| 10:07:57 | dbussink | khaase: should also not be necessary anywhere else |
| 10:08:39 | khaase | dbussink: was just curious. thx. |
| 10:09:42 | dbussink | khaase: it's only used for arguments, you often need to distinguish there between for example a nil value and not getting passed in parameter at all |
| 10:09:53 | dbussink | khaase: so a default argument is not enough |
| 10:13:41 | khaase | dbussink: that's kinda what i guessed. it is handled by the compiler? what happens if it is returned? |
| 10:14:08 | khaase | "special compiler construct" of course it is |
| 10:14:11 | dbussink | khaase: returned from a method you mean? |
| 10:14:17 | khaase | dbussink: yeah |
| 10:14:43 | dbussink | khaase: dunno what happens then, but you probably shouldn't do it ;) |
| 10:15:01 | khaase | mkay |
| 10:17:03 | dbussink | khaase: it compiles into a special vm code, you could look at lib/compiler/ast/transforms.rb |
| 10:18:42 | khaase | dbussink: thx, i'll take a look |
| 17:01:33 | rue | ~68s for a -B full run, not shabby |
| 17:16:11 | brixen | sweet |
| 17:17:31 | rue | 45ish for plain ci |
| 17:22:23 | rue | Although, ci runs almost 600ex/sec, full "only" 550ex/sec, so cannot draw too many conclusions there.. |
| 17:23:28 | brixen | library spec have more that cause pauses |
| 17:23:42 | brixen | some literally for sleep and stuff like making socket connections |
| 17:38:15 | rue | Yep |
| 17:38:33 | rue | Though there are some in the basics, too. The Process specs take noticeably longer on rbx |
| 17:38:47 | Defiler | That's a lot better than 10 minutes |
| 17:39:33 | rue | Also, oddly all of a sudden I started getting errors from spec/default.mspec trying to require "spec/custom/or/something"...seems the lib path changed |
| 17:43:28 | brixen | rue: gist? |
| 17:44:34 | rue | Rebuilding...it started when I tried on 1.9.2, see if I can reproduce it |
| 17:53:10 | rue | Nope, cannot reproduce it. Oddity |
| 18:05:26 | scoopr | rue, there was some arm-talk lately, yes, I do have an arm box, linkstation live.. lately I haven't been able to test rbx on it, as I can't compile llvm *on* the device (128megs of ram is totally not enough for that x86idagsel.cpp or whatever it was called) |
| 18:06:07 | scoopr | also, in work I have couple of n900 that I could try testing, for that I have a cross-compiler env, even if it's a bit odd environment |
| 18:23:37 | rue | How is it that apparently everyone has an n900? :P |
| 18:26:17 | BrianRice-work | or an iphone... because they get excited and noisy about it. (I have one of the first N770's, of course) |
| 18:26:21 | scoopr | hey, it's for work stuff :P (and besides probably actually nokia's) |
| 18:49:21 | Zoxc | How fast is the rubinius interpreter vs. 1.9? |
| 18:49:58 | brixen | Zoxc: benchmark/tiers |
| 18:50:06 | brixen | give it a whirl and let us know what you find |
| 18:50:47 | brixen | also wayneeseguin has some recent #s running those |
| 19:06:54 | wayneeseguin | Zoxc: http://rvm.beginrescueend.com/benchmarks/2010-01-06/ |
| 19:07:06 | wayneeseguin | Most recent ones, next set hopefully out this weekend including MagLev |
| 19:07:54 | brixen | thanks wayneeseguin |
| 19:08:00 | wayneeseguin | Absolutely |
| 19:08:06 | wayneeseguin | Like I said I'll have another set out asap |
| 19:08:10 | wayneeseguin | I've been working on adding MagLev first |
| 19:14:52 | evan | hi wayneeseguin! |
| 19:16:30 | wayneeseguin | evan: hihi!!!! |
| 19:16:43 | wayneeseguin | One more 'breakage' and rvm 0.1.0 is out! |
| 19:16:44 | wayneeseguin | w00t |
| 19:16:46 | wayneeseguin | MagLev is done |
| 19:16:54 | evan | woop! |
| 19:17:10 | wayneeseguin | So now I'm going to move the rubies install path from ~/.rvm/ to ~/.rvm/rubies/ so that users can change it to anywhere they want |
| 19:18:07 | brixen | cool |
| 19:19:21 | evan | wayneeseguin: i'd like to discuss GEM_HOME before you release 1.0.0 |
| 19:19:22 | evan | if possible |
| 19:32:49 | wayneeseguin | evan: absolutely |
| 19:32:58 | wayneeseguin | evan: whenever you want |
| 19:33:10 | evan | basically, if someone has rvm installed |
| 19:33:16 | evan | and they try and use rbx not via rvm |
| 19:33:18 | evan | they're screwed. |
| 19:33:24 | wayneeseguin | ok? |
| 19:33:45 | wayneeseguin | wouldn't they use it by switching back to sysetm ? |
| 19:33:53 | evan | because rvm sets GEM_HOME to (likely) MRI's gem home |
| 19:33:55 | wayneeseguin | rvm system ; # now commands are without rvm loaded |
| 19:33:59 | evan | ah! |
| 19:34:02 | evan | ok, thats what I wanted to know |
| 19:34:06 | wayneeseguin | yeah |
| 19:34:08 | evan | does that remove all the env vars in the current shell? |
| 19:34:10 | wayneeseguin | 'rvm system' unsets GEM_HOME / etc |
| 19:34:14 | wayneeseguin | path back to normal |
| 19:34:14 | wayneeseguin | etc |
| 19:34:25 | evan | back to normal being not set? |
| 19:34:26 | wayneeseguin | all the rvm planted ones yes |
| 19:34:29 | evan | they're not normally set. |
| 19:34:33 | wayneeseguin | yes |
| 19:34:42 | wayneeseguin | the first time rvm loads it takes a 'system' snapshot |
| 19:34:51 | wayneeseguin | records the settings for GEM_HOME, GEM_PATH, etc... |
| 19:34:59 | wayneeseguin | when you switch to system it loads those values |
| 19:35:11 | evan | ok, thats exactly what I needed to know |
| 19:35:20 | wayneeseguin | And to have rvm re-load the system settings you do 'rvm system ; rvm reset' then open a new shel and do a rvm action |
| 19:35:26 | evan | people have been using the OS X installer for rubinius |
| 19:35:32 | evan | so thats why they didn't have rbx via rvm |
| 19:35:39 | wayneeseguin | ok? |
| 19:35:49 | wayneeseguin | Yeah rvm is used to 'select' your environment |
| 19:35:51 | evan | just giving you the context |
| 19:35:55 | wayneeseguin | That's about all |
| 19:35:56 | evan | for my query |
| 19:36:01 | wayneeseguin | gotcha |
| 19:36:05 | wayneeseguin | That makes sense. |
| 19:36:14 | evan | so in that case, they need to do "rvm system" before they can use "rbx" |
| 19:36:18 | wayneeseguin | yes |
| 19:36:22 | wayneeseguin | and that's only per-shell |
| 19:36:28 | wayneeseguin | (unless they have a default ruby specified) |
| 19:36:54 | evan | sounds good |
| 19:36:55 | evan | thanks! |
| 19:36:59 | evan | you're free to release 1.0 |
| 19:36:59 | evan | :D |
| 19:37:23 | wayneeseguin | lol |
| 19:37:28 | wayneeseguin | 0.1.0 and Thanks :) |
| 19:38:50 | evan | ooh |
| 19:38:51 | evan | 0.1 |
| 19:38:52 | evan | hah |
| 19:38:57 | evan | i thought you had said 1.0 before |
| 19:39:00 | evan | :) |
| 19:39:29 | brixen | wayneeseguin is conservative with his versions |
| 19:39:35 | brixen | rvm is rockin' |
| 19:39:40 | wayneeseguin | ::grin:: |
| 19:40:17 | wayneeseguin | I just want to make sure that I'm done changing the internals before releasing 0.1.0 so it's quite literally a 'limiting' process ::grin:: |
| 19:40:24 | wayneeseguin | (ran out of double digits ;)) |
| 19:40:36 | wayneeseguin | rvm 0.0.9999999 |
| 19:48:23 | evan | hm, i wonder if it's worth while to add allocation-less Float's |
| 19:55:35 | brixen | pools or immediates? |
| 19:56:57 | evan | immediates |
| 19:57:39 | brixen | sure, could |
| 19:58:26 | evan | i probably wont |
| 19:58:33 | evan | it would solve this one, silly, benchmark |
| 19:58:40 | evan | but not the real reason for the benchmark being slower |
| 19:58:58 | evan | ie, if you use Object.new rather than Math::PI * i |
| 19:59:04 | evan | then i'm back at square one |
| 19:59:06 | evan | so nevermind. |
| 19:59:12 | brixen | yeah, makes sense |
| 19:59:36 | brixen | running to appt, back after lunch! |
| 19:59:59 | evan | k |
| 20:23:07 | seydar | greetings, y'all |
| 20:25:43 | evan | hi hi |
| 20:26:58 | seydar | good news: i'm getting an intel machine in 6-9 months |
| 20:27:13 | seydar | which means i can use rubinius! |
| 20:28:06 | evan | sweet! |
| 21:38:11 | rue | That boy is fast in his moves |
| 21:46:26 | PierreY | Hi guys. You know what ? You just rock ! 3024 files, 11748 examples, 35951 expectations, 0 failures, 0 errors. Happy new year :-) |
| 21:46:40 | evan | :) |
| 21:46:45 | evan | well thanks! |
| 21:49:19 | rue | You too! |
| 21:49:23 | rue | Just sobered up? :) |
| 21:50:58 | PierreY | yes, that was hard this year |
| 21:53:45 | PierreY | note that here, in france, we use to wish an happy new year all january month long |
| 21:58:25 | PierreY | bm_so_concatenate.rb has eaten all my ressources, seems that something killed it with a SIGSERV |
| 22:28:54 | PierreY | how long should benchmarks normally run ? |
| 22:34:49 | brixen | depends on the benchmark |
| 22:34:55 | brixen | what are you running? |
| 22:42:30 | PierreY | rake bench |
| 22:56:36 | Zoxc | wayneeseguin: those numbers uses the JIT right? |
| 23:06:25 | evan | brixen: ooh http://groups.google.com/group/bahaskell/browse_thread/thread/faef5110e126921f |
| 23:07:47 | evan | haskell group meeting at the office on monday |
| 23:14:48 | brixen | sweet |
| 23:15:33 | brixen | those presentations look interesting |
| 23:17:11 | brixen | splitty split ditty |
| 23:24:52 | evan | maybe i should figure out what monad is |
| 23:24:52 | evan | if i'm going to sit in |
| 23:24:57 | alexsuraci | evan: have fun with that. :P i started digging in to all kinds of people's monad metaphors, but I ended up just looking at their definitions and how they *actually work*. |
| 23:29:10 | brixen | this is pretty good http://book.realworldhaskell.org/read/monads.html |
| 23:29:53 | alexsuraci | which i found much more productive |
| 23:29:58 | alexsuraci | most peoples' monad "guides" seem to me like they're just written down for the author |
| 23:31:22 | evan | probably. |
| 23:31:22 | alexsuraci | but once you treat them as what they are - just a set of functions like any other ones, using language facilities just like any others would - it's a bit easier to grasp, at least at an objective level |
| 23:36:37 | evan | brixen: i think i need to know more haskell to get it |
| 23:36:53 | brixen | that book is pretty good |
| 23:37:23 | alexsuraci | there's also http://learnyouahaskell.com/ which is great |
| 23:37:28 | brixen | hah |
| 23:37:36 | brixen | that is... fun |
| 23:37:44 | brixen | I found real world haskell more useful |
| 23:38:33 | brixen | anyone know why we have both #load and #require? |
| 23:38:35 | alexsuraci | LYAH doesn't have a chapter on monads yet unfortunately |
| 23:38:40 | brixen | MRI really failed at the whole objectifying code loading |
| 23:39:59 | alexsuraci | i don't think you'd really need to know what monads are to sit in on a haskell presentation anyway. the only reason it's so talked about is because it confuses so many people, and the only reason it confuses so many people is because so many people hear other people are confused by it :P |
| 23:40:09 | brixen | evan: the pres sounds interesting more for the experiences with a non-trivial haskell app |
| 23:40:56 | evan | yeah |