Show enters and exits. Hide enters and exits.
| 03:04:12 | BrianRice | where would I find the kernel of the printf logic? |
| 03:08:53 | BrianRice | ok: kernel/common/sprintf.rb |
| 06:39:09 | boyscout | Use bin/rbx compile instead of bin/rbx describe. - b6a07a7 - Brian Ford |
| 06:39:09 | boyscout | Rewrote the defined? specs. - f6bea18 - Brian Ford |
| 06:39:10 | boyscout | Fixed defined? for various literals. - 90c2de2 - Brian Ford |
| 06:39:10 | boyscout | Fixed defined? for assignments. - 9ce8d8d - Brian Ford |
| 06:39:10 | boyscout | More defined? specs. - 8c41860 - Brian Ford |
| 06:39:10 | boyscout | Fixed defined? for method receivers. - 7bdae03 - Brian Ford |
| 06:39:10 | boyscout | Some defined? specs for back_ref, nth_ref and stuff. - 6402910 - Brian Ford |
| 06:39:11 | boyscout | Fixed defined? for nth_ref and back_ref. - f9f2d0c - Brian Ford |
| 06:39:11 | boyscout | Specs for defined? with constants. - 47bd56f - Brian Ford |
| 06:39:12 | boyscout | Load gem_prelude from loader.rb. - 538f489 - Brian Ford |
| 06:39:12 | boyscout | Refactored defined?() for when values are needed. - 459b14c - Brian Ford |
| 06:39:13 | boyscout | Fixed defined?() for constants. - 44e40c0 - Brian Ford |
| 06:39:13 | boyscout | Updated CI tag for description change. - c107015 - Brian Ford |
| 06:39:14 | boyscout | Fixed wrong conflict resolution on rebase. - 2c55bfa - Brian Ford |
| 06:40:08 | brixen | looks like boyscout gets in trouble for more than 14 or so |
| 06:49:27 | boyscout | CI: rubinius: 738cd1a successful: 3037 files, 12133 examples, 36493 expectations, 0 failures, 0 errors |
| 15:26:57 | luislavena | hey guys, a quick question. |
| 15:27:23 | luislavena | libev on the repo is 3.8, any blocker to move it to 3.9? |
| 16:22:46 | rue | luislavena: I do not think libev is used for anything anymore |
| 16:23:11 | luislavena | rue: hmn, an orphaned dependency then in vm/external_libs ? |
| 16:25:15 | rue | In that case it would be. I am not 100%, but it is definitely not used for most purposes it was at the time |
| 16:27:14 | luislavena | rue: I'm looking at all the external_libs to see the ones that do not compile under mingw32 |
| 16:29:00 | luislavena | rue: so far libev only required update to 3.9 and patch, libtommath required minor change to makefile (hardcoded stuff) and libffi just works |
| 16:35:52 | rue | Cool. MIght as well leave it then, hope to make use of it at some point again |
| 16:37:22 | luislavena | rue: I'm cheating since I'm cross compiling right now, but so far deps compile ;-) |
| 17:20:19 | evan | yes, we should remove libev |
| 17:20:22 | evan | we're not using it anymore |
| 17:20:46 | evan | luislavena: thanks! |
| 17:33:51 | dbussink | luislavena: cool work on the getting it to build :) |
| 17:34:14 | dbussink | luislavena: do you know if llvm is possible? could also try without it for starters, might be easier |
| 17:49:34 | luislavena | dbussink: llvm just works, and there are llvm binaries/libs for windows already. |
| 17:50:07 | luislavena | dbussink: the thing I see more and more is that it may be easier to cross-compile than build everything from scratch under windows :P |
| 18:08:53 | dbussink | luislavena: that would be really awesome, so we could create binaries ourselves easily :) |
| 18:09:48 | brixen | yeah, I'm a big fan of x-compiling for windows :) |
| 18:10:03 | brixen | I'll compile it, you run it... win! |
| 18:11:00 | luislavena | brixen: but someone needs to run the tests and see it crash until we reach nirvana. |
| 18:11:18 | brixen | luislavena: do I hear a volunteer? :D |
| 18:11:20 | luislavena | brixen: I still owe you something, 100mb for drop.io attach is a nightmare |
| 18:11:40 | brixen | luislavena: no worries, maybe we can get evan to let you upload it to us |
| 18:11:49 | luislavena | thinks can volunteer soon, once RubyInstaller is out for good :) |
| 18:11:56 | brixen | I'll ask him about it tomorrow when we're in SF |
| 18:12:25 | luislavena | brixen: cool, I'm paris right now but can FTP/S3 without issues if you want |
| 18:12:32 | brixen | ok |
| 18:17:46 | luislavena | should all the patches for the changes in the external_libs sent upstream? |
| 18:24:19 | brixen | yes |
| 18:41:48 | luislavena | brixen: ok, was hard to find the contact and details of some of the libs, will try to reach them :P |
| 18:42:41 | brixen | luislavena: you mean the libs in vm/external_libs? |
| 18:42:57 | luislavena | brixen: yes, those. |
| 18:44:26 | brixen | ahh |
| 18:44:39 | brixen | der, I just realized what you meant by upstream |
| 18:44:40 | brixen | heh |
| 18:45:39 | brixen | I don't think libtommath is maintained officially anymore |
| 18:45:58 | brixen | luislavena: if it's a pain to submit upstream, no worries |
| 18:46:41 | luislavena | brixen: ok, thank you :) |
| 18:47:14 | brixen | maybe just add a doc/external_libs.txt that notes what we should be aware of if we update a modified lib in the external_libs dir |
| 18:47:35 | luislavena | brixen: one question thought, afaik minimal version requirement of GCC is 4.1, right? |
| 18:48:28 | brixen | I'm still using 4.0.1 on os x 10.5.8 |
| 18:49:15 | luislavena | brixen: i386-mingw32-gcc --version from macports tell me 3.4.5, the same I use on Windows :P |
| 18:50:43 | brixen | hmm |
| 18:50:46 | brixen | you can try it |
| 19:41:33 | dbussink | luislavena: anything you've experienced to be problematic in the past with pre 4.0? |
| 19:46:18 | luislavena | dbussink: no, getting > 4.0 on MinGW is a challenge, there is no official and stable releases |
| 19:53:29 | dbussink | luislavena: isn't something like this doable? http://sourceforge.net/projects/mingw-cross/files/ |
| 19:53:58 | dbussink | all rpm stuff though |
| 19:55:15 | dbussink | luislavena: or this? http://crossgcc.rts-software.org/doku.php |
| 20:00:40 | luislavena | dbussink: I meant to say that official builds from mingw.org ppl don't pushed newer versions that they consider "stable" |
| 20:01:14 | dbussink | luislavena: ah, well, maybe rubinius will need more adventure :P |
| 20:02:06 | luislavena | dbussink: definitely ;-) |
| 20:12:32 | dbussink | luislavena: i'm trying to test that build with rake-compiler, any way i could try that? |
| 20:16:48 | luislavena | dbussink: what thing you want to test? |
| 20:17:06 | dbussink | luislavena: just some binary gems for windows i make to see whether that 4.3 version works |
| 20:18:13 | luislavena | dbussink: can you email me the gem and I can give a try? using the mac at work right now, but have a VM with XP |
| 20:30:09 | kstephens | String#% appears to be very slow. |
| 20:30:21 | kstephens | I have a benchmark if someone wants to try it. |
| 20:33:39 | brixen | kstephens: could you open a ticket? |
| 20:33:44 | kstephens | sure |
| 20:33:46 | brixen | include the benchmark |
| 20:34:15 | brixen | we could probably add it to evan's tier benchmarks |
| 20:34:35 | kstephens | BTW: I'm working on a bunch of benchmarks that compare low-level common ruby idioms against different Ruby implementations. |
| 20:35:06 | kstephens | I'm planning to do a talk at Chicago Ruby Group about it. |
| 20:35:27 | kstephens | So far it will be good "publicity" for Rubinius :) |
| 20:36:11 | brixen | cool |
| 20:37:26 | kstephens | I can give you guys a preview if you want. |
| 20:37:26 | kstephens | s/preview/preview of the slides/ |
| 20:37:36 | brixen | sure |
| 20:37:57 | brixen | evan will be back after lunch |
| 20:38:19 | brixen | kstephens: did you run our tier benchmarks? |
| 20:38:26 | kstephens | no didn't know about them |
| 20:38:32 | brixen | I'm curious if your results are consistent with what we see |
| 20:38:53 | brixen | in our repo, benchmark/tiers |
| 20:39:02 | brixen | where is wayne |
| 20:39:35 | kstephens | Overall rubinius "kick ass", but I think I'm seeing performance problems related to local variables (as compared to JRuby and MRI) |
| 20:39:58 | brixen | http://rvm.beginrescueend.com/benchmarks/2010-01-06/ |
| 20:39:59 | kstephens | The slides should be more illustrative of what I'm seeing |
| 20:40:13 | brixen | the rvm author has a setup to run various impls against the tiered benchmarks |
| 20:40:31 | brixen | local variables huh? hmm |
| 20:40:39 | brixen | those should be screaming fast |
| 20:41:24 | kstephens | My research for this presentation is two fold: 1) some common ruby idioms have MTOWTDI. 2) Different Ruby implementations perform differently. |
| 20:41:47 | kstephens | So its about what code techniques perform best across implementation and on specific impls. |
| 20:41:55 | brixen | http://rvm.beginrescueend.com/benchmarks/2010-01-05/ |
| 20:48:29 | dbussink | kstephens: any specifics on the benchmark that was slower for you? |
| 20:48:40 | dbussink | the local variables is probalby the most interesting |
| 20:51:36 | kstephens | http://kurtstephens.com/priv/ruby/ruby_code_tweaks/slides/#45 |
| 20:52:13 | kstephens | I'll have a new version up there shortly that has links to the individual benchmark files and results. |
| 20:53:05 | kstephens | In the meantime: http://kurtstephens.com/priv/ruby/ruby_code_tweaks/slides/measurement/string_formatting-Rubinius.r b |
| 20:53:26 | kstephens | http://kurtstephens.com/priv/ruby/ruby_code_tweaks/slides/problem/string_formatting.rb |
| 20:54:27 | kstephens | The local variable issue is just a speculation on my part. |
| 20:54:54 | kstephens | The benchmarks where I introduced local variables in a loop appear to be a contributing factor. |
| 20:55:10 | dbussink | could also very well turn out to be a gc benchmark |
| 20:55:15 | kstephens | that too |
| 20:55:43 | kstephens | There does appear to be a threshold were GC is active enough to be a contribution. |
| 20:55:54 | kstephens | s/were/where/ |
| 20:56:24 | kstephens | I haven't done any digging into rbx, I'm just measuring simple blocks of code in tight loops. |
| 20:56:46 | kstephens | purely comparative analysis. |
| 20:57:59 | kstephens | I'll be adding more Problems/Solutions. Trying to despell some myths about the tradeoffs of idomatic ruby. |
| 20:58:31 | brixen | kstephens: our profiler lists GC activity |
| 20:58:32 | kstephens | Maybe rails could clean up some sloppy low-level code that is killing all of us :) |
| 20:58:41 | brixen | you could profile the code you are benchmarking to see if it's GC heavy |
| 21:00:03 | kstephens | We're still on Rails 1.2 here at work, so we can't just yet take advantage of wycats excellent rails 3.0 work. :( |
| 21:00:53 | brixen | kstephens: well, hopefully it won't be too hard to transition |
| 21:01:16 | brixen | cus not sure any amount of knowledge is going to actually clean up Rails 1.2 code ;) |
| 21:01:17 | kstephens | Our code base is *enormous*. |
| 21:01:53 | kstephens | I've patched the fuck out of 1.2 for performance reasons. |
| 21:02:11 | brixen | fun |
| 21:12:48 | evan | i'm back! |
| 21:15:56 | dbussink | evan: wooohoo |
| 21:15:59 | kronos_vano | kstephens, why jruby 1.2 ? |
| 21:16:29 | evan | man, M for String#unpack is so wacky. |
| 21:19:53 | kstephens | jruby 1.2 was quick to install via apt-get :) |
| 21:20:11 | dbussink | kstephens: also pretty much outdated already |
| 21:20:12 | kstephens | I'll probably build everything from latest soruce. |
| 21:20:40 | kstephens | yea I figured it already was. |
| 21:20:51 | dbussink | kstephens: are you using stock ruby? because pthreads disabled / enabled can also make a lot of difference for 1.8 |
| 21:21:15 | kstephens | 1.8.7 is debian stock. |
| 21:21:54 | kstephens | 1.8.6 and 1.9 are built from source. But I have not enabled pthreads, and I'm not doing any Threads in the benchmarks. |
| 21:22:05 | kstephens | 1.9 is built from trunk. |
| 21:22:17 | dbussink | well, 1.8.7 debian stock has them enabled afaik |
| 21:22:35 | kstephens | good point, I was planning on building 1.8.7 from trunk. |
| 21:22:53 | kstephens | I really don't want to build jruby :) |
| 21:22:58 | kstephens | but I will. |
| 21:29:40 | dbussink | kstephens: you don't have to, you can just download a binary from the website for 1.4 |
| 21:31:46 | kstephens | I'll do that, tnx. |
| 21:33:41 | kronos_vano | evan, I think we was wrong this moving array#hash to C++ layer. This way is faster only on array with size around 500 or less. On big arrays: http://gist.github.com/327133. I think it is because map :( |
| 21:33:57 | evan | I didn't say to |
| 21:34:21 | evan | oh, you did it the way I said |
| 21:34:23 | evan | a different method |
| 21:34:37 | evan | well |
| 21:34:43 | evan | leave it as is. |
| 21:34:49 | kronos_vano | hash_ and hash__ just for benchmarking |
| 21:34:52 | evan | I said we didn't need to do it now |
| 21:35:01 | evan | ie, leave it ruby only |
| 21:35:07 | kronos_vano | ok |
| 21:37:06 | evan | ug. |
| 21:37:27 | evan | man, i'd prefer these "method X is very slow" tickets at least also had some fixes or profiling output or SOMETHING |
| 21:37:41 | evan | otherwise I feel like it's just someone pointing out a pothole on the street. |
| 21:40:27 | dbussink | evan: well, there's the crash ticket to investigate ;) |
| 21:40:39 | evan | yep |
| 21:40:41 | evan | i know. |
| 21:41:26 | kstephens | evan: what would you like for the String#% is slow ticket? |
| 21:41:34 | evan | a fix? :D |
| 21:42:05 | evan | some profiling would be good, use - Xint -P <script> to get some profiling output |
| 21:42:14 | evan | -Xint -P <script> |
| 21:42:18 | kstephens | Ok |
| 21:42:31 | evan | kstephens: thanks for the ticket also |
| 21:42:36 | evan | didn't mean to bitch :P |
| 21:42:44 | kstephens | no, I get it. |
| 21:42:54 | evan | we've given no optimization time to the printf code |
| 21:49:30 | kronos_vano | kstephens, what is "E!" for example in http://kurtstephens.com/priv/ruby/ruby_code_tweaks/slides/#108 near rubinius |
| 21:49:53 | kstephens | Means it errored out |
| 21:49:58 | kstephens | see my other ticket |
| 21:50:18 | kstephens | thats the SEGV I reported in the GC. |
| 21:50:55 | evan | ok |
| 21:50:58 | evan | i've got your ticket |
| 21:51:01 | evan | i need to dig into it |
| 21:51:08 | evan | could you update the ticket with your platform info |
| 21:51:10 | evan | if it's not already there |
| 21:51:14 | kstephens | sure |
| 21:53:07 | kstephens | done |
| 21:55:29 | kstephens | evan: I can generate rbx profile results for all my slides if you want. |
| 21:55:47 | evan | surely |
| 21:56:04 | evan | i'll bet with some tuning |
| 21:56:18 | evan | we can shave at least 10x off String#% |
| 21:56:44 | evan | that's the kind of success i've had with tuning stuff that has never been touched optimization wise |
| 21:56:51 | kstephens | I hope at least 100x :) |
| 21:57:11 | kstephens | http://kurtstephens.com/priv/ruby/ruby_code_tweaks/slides/#45 |
| 21:57:35 | kstephens | I wish I had more time to contribute a fix. |
| 21:59:04 | evan | is your scale for slide 46 right? |
| 21:59:12 | evan | perhaps it's like that to make a point |
| 22:02:59 | kstephens | the scale is correct :( |
| 22:03:11 | evan | no, for 46 |
| 22:03:20 | evan | for 46 they're all below like 20 it looks like |
| 22:03:26 | evan | i can barely see the bars |
| 22:03:50 | evan | oh, you use the same scale for all of them |
| 22:03:56 | kstephens | Yea, I gotta tweek some of graph generation. |
| 22:04:06 | kstephens | Some of the graphs are too illustrative. |
| 22:04:12 | kstephens | and not useful. |
| 22:05:37 | kstephens | I'll annotate them with real numbers for clarity |
| 22:19:36 | evan | for those in the SF area: http://www.sdforum.org/index.cfm?fuseaction=Page.ViewPage&PageID=622 |
| 22:19:48 | evan | i'll be on a panel tomorrow |
| 22:26:56 | kronos_vano | Is spec ok? http://gist.github.com/327212 |
| 22:30:27 | evan | kronos_vano: i'd make the title be |
| 22:30:48 | evan | it "depends on the order of elements in the Array" |
| 22:31:40 | kronos_vano | evan, tnx |
| 22:42:59 | boyscout | Update spec for Array#hash: Add cases for same arrays with diffrent order - 8dbf339 - Ivan Samsonov |
| 22:42:59 | boyscout | Improve Array#hash - 6625ff5 - Ivan Samsonov |
| 22:46:22 | brixen | kronos_vano: just for reference, in specs like that, you should probably indicate whether the case with 2 fixnums is a boundary condition relative to the one with 4 fixnums |
| 22:46:33 | brixen | kronos_vano: otherwise, what's the point of both those? |
| 22:46:42 | brixen | fixnums vs strings I understand |
| 22:47:08 | brixen | but even in that case, you should have 2 example blocks |
| 22:47:17 | brixen | one with fixnums, one with strings |
| 22:48:16 | boyscout | CI: rubinius: 6625ff5 successful: 3037 files, 12134 examples, 36496 expectations, 0 failures, 0 errors |
| 22:56:10 | matthewd | So... per my rambling to myself over the weekend, Kernel.rand is broken, because it can return values higher than it should |
| 22:56:35 | matthewd | Easy fix is to check the result and loop on the (very unlikely) event it has done so |
| 22:56:59 | evan | matthewd: sure |
| 22:57:04 | evan | submit a patch and i'll apply it. |
| 22:57:09 | matthewd | At the other end of the spectrum, would it be worth implementing MT or so in ruby? |
| 22:57:18 | evan | MT? |
| 22:57:21 | evan | no. |
| 22:57:36 | evan | it wouldn't. |
| 22:57:51 | matthewd | Not really as a solution to this, so much as just because I noticed we're using the posix call atm |
| 22:57:54 | matthewd | k |
| 22:58:34 | matthewd | My reading of the docs suggests RAND_MAX isn't always 0x7fffffff, too... is that just not relevant on platforms we care about? |
| 23:00:38 | evan | thats not what 0x7ffffff means actually |
| 23:00:55 | evan | oh wait |
| 23:01:00 | evan | where do you see that value? |
| 23:01:12 | evan | ug. |
| 23:01:15 | evan | who wrote this? |
| 23:01:19 | evan | this needs to be changed. |
| 23:01:28 | matthewd | So, you obviously found it. :) |
| 23:01:44 | evan | we need to remove all that reading from urandom |
| 23:01:54 | evan | no, i don't see the 0x7ff... |
| 23:02:12 | evan | but i do some some code in entirely the wrong place. |
| 23:02:22 | evan | oh, in rand |
| 23:02:23 | evan | got it. |
| 23:02:27 | evan | i was looking in srand |
| 23:02:28 | evan | um. |
| 23:02:36 | evan | no clue why we use 0x7f... there |
| 23:02:42 | evan | feel free to do anything you want |
| 23:02:51 | evan | barring a full MT implementation |
| 23:03:07 | evan | we should still use srand(2) and rand(2) |
| 23:03:12 | matthewd | Well, that's RAND_MAX on current platforms, so is presumably to adjust to a more appropriate range |
| 23:03:16 | matthewd | k |
| 23:03:57 | matthewd | I think half the problem (of overage) goes away if you make it 0x80000000... but that's obviously still assuming the value of RAND_MAX. |
| 23:04:20 | evan | i dislike the idea of a random platform constant in there |
| 23:04:23 | matthewd | But even then, there are rounding issues, I believe |
| 23:05:04 | matthewd | Yeah, I assume I'll find an example of how to actually get RAND_MAX somewhere (as in, an example of a different such constant) |
| 23:05:26 | evan | you... might not. |
| 23:05:43 | evan | i guess the code that gets the F_* values |
| 23:05:44 | matthewd | I'd hoped for a clue in platform/posix.rb, but was not rewarded |
| 23:07:13 | evan | check out rakelib/platform.rake |
| 23:08:23 | matthewd | Okay, cool |
| 23:15:55 | matthewd | Just to complete my earlier reasoning, I was only considering MT for the rather dubious advantage of seed-compatibility with MRI |
| 23:24:32 | evan | a pox on the house of quoted-printable! |
| 23:24:48 | evan | matthewd: feel free to do a seed mix |
| 23:24:59 | evan | using Time.now and Process.pid, etc. |
| 23:25:05 | evan | thats what MRI does, I believe. |
| 23:27:47 | matthewd | Yup |
| 23:28:42 | evan | if you wanna implement MT for the seed |
| 23:28:45 | evan | thats probably fine |
| 23:28:58 | evan | i'd prefer to not put a MT mixer pass into #rand though |
| 23:29:01 | evan | it would slow it way down. |
| 23:29:11 | matthewd | While I'm asking stupid questions... should we be aware of the timing attack against the top bit of the result (because of bignum vs fixnum)? |
| 23:29:13 | evan | i'd expect, but i'm happy to be proven wrong. |
| 23:29:50 | evan | probably. |
| 23:30:01 | evan | #rand should clamp all values to Fixnum |
| 23:30:08 | matthewd | Yeah, I suspected as much. By seed compat, I mean having `srand(3);rand` return the same in both impls... but yeah, I highly doubt anyone would care |
| 23:30:31 | evan | either via an explicit clamp (might sacrifice the data quality) or by just redoing |
| 23:30:47 | evan | aah |
| 23:30:52 | evan | i'm not sure we need that level of compat |
| 23:31:08 | evan | since i think that MRI still just passes the srand value to srand(2) |
| 23:31:12 | evan | so it's still dependent on the system |
| 23:31:24 | matthewd | The only possible reason I could think of wanting it was so any random benchmarks'd be doing the same thing :P |
| 23:31:36 | evan | heh |
| 23:31:36 | evan | yeah |
| 23:31:56 | evan | i'd leave it up to the random impl |
| 23:31:57 | kstephens | looks around guilty |
| 23:32:08 | evan | if they have variance based on clamping, etc, thats fine. |
| 23:34:41 | matthewd | FWIW, in a quick glance at http://ruby-doc.org/doxygen/1.8.4/random_8c-source.html, I don't think it touches the platform srand or rand |
| 23:36:01 | evan | aah ok |
| 23:36:27 | matthewd | I can't put C between Kernel.rand and rand(3), can I? In an ideal world, I'd keep the full 31 bits, and just use the top one as -ve, to stay within fixnum bounds |
| 23:41:05 | evan | well, you could write it as a primitive |
| 23:41:11 | evan | then you can write it anyway |
| 23:45:09 | matthewd | Hrmm... I guess I'll start by writing it in ruby... the extra bit would only really be relevant when max is a bignum |