Index

Show enters and exits. Hide enters and exits.

00:00:27evanbrixen: ok, so the GIL patch is improving things
00:00:27evangood.
00:00:31brixenyeah
00:00:37bougymanno GIL now?
00:01:00brixenbougyman: a fix for the existing GIL
00:01:06bougymanah
00:01:08brixenbougyman: the no gil is on the hydra branch
00:04:34evanlots of GIL work in general lately it seems.
00:04:41evanhydra isn't ready for primetime yet.
00:14:14evanbrixen: i like that I can remove the timer thread with this new GIL algo
00:17:16evanif any of you want to really dig into the GIL tradeoffs, check out http://bugs.python.org/issue7946
00:17:25evanand specificly http://bugs.python.org/file17504/bfs.patch
00:17:33evanwhich is really quite interesting
00:31:49brixenevan: yeah, that's cool about the timer thread
00:32:12brixenI read both beazley's presentation slides yesterday
00:32:24brixenmakes a lot more sense now
00:32:43brixenreads up on the bugs
00:33:55evanthe python "bugs" are behavior changes from going from their opcode counter based model to a wall clock timer model
00:34:03evanlargely
00:34:16evanhe talks about the fact that a hot loop of
00:34:20evanwhile True: pass
00:34:35evanhits the counter ever like 2 microseconds
00:34:47evanie, ever 2 microseconds it would give up the GIL.
00:35:12evanthats because the counter defaults to 100
00:35:17evanso every 100 instructions, give up the GIL
00:35:30evanyou can see how with that hot loop, 100 instructions would only take 2 microseconds
01:00:07evanok, i like this patch enough i'm going remove the timer thread code and throw it on a public branch
01:09:15brixencool
01:10:23evanman the thread specs make me cry.
01:10:43evanthey serve as thread torture tests atm
01:10:52evanthread and human torture
01:28:49boyscoutImplement a new GIL algorithm to prevent starvation - 512c054 - Evan Phoenix (newgil)
01:31:00brixenevan: testing on ubuntu and fedora
01:31:13brixenand leopard I guess
01:31:18evank
10:28:22dbussinkyou can always try ;)
10:28:30dbussinkthere's also #ruby-lang for general ruby questiobs
10:28:32dbussinkquestions
10:37:05kronos_vano|--|, 5 > size of the array
11:56:19alissonwhat is the newgil branch
12:10:53dbussinkit contains an improved version of the gil
12:10:57dbussinkglobal interpreter lock
12:15:24alissonahhh understood :)
14:59:56Tasserdbussink, still didn't get rid of that?
17:31:51dbussinkTasser: the gil isn't something you "just get rid of" :)
17:32:00dbussinkbut it's coming along in the hydra branch
17:32:13dbussinkbut that's not ready for 1.1
17:35:54scoopr"Rule number one of the GIL club is, that you don't 'just' get rid of the GIL club." .. or uhh, something ;)
17:39:39brixenevan: ubuntu 10.04 32bit: 322s after gil patch, 394s before running specs
17:39:52brixenbefore, while running specs
17:40:04evanthats under a VM i'm assuming
17:40:09evani see about 109s normally.
17:40:12brixenthat's vbox yes
17:40:13evank
17:40:24evanso so far, so good.
17:40:28brixenI'm going to fix the Net::HTTP and Net::FTP specs
17:40:38brixenyeah, looks to be going well
17:41:43brixenthe kernel in 10.04 is 2.6.32-24 and in fedora 13 it's 2.6.33.8
17:41:55evank
17:42:01brixeninteresting that the 2.6.32 seems to show more improvement from the patch
17:42:27evangotta be related to kernel scheduler changes
17:42:38brixenyeah, I would expect
17:42:53brixenperhaps the 2.6.33 scheduler is slightly better at dealing with this condition
17:43:06evancertainly possible.
17:43:09evanalso, don't forget
17:43:14evanbeing on a VM effects this
17:43:21brixensure
17:43:31evanbecause the core-ness and timing
17:44:48scoopr'effects' or 'affects'? =)
17:46:12evanboth.
17:47:31dbussinkthe effects affect :P
18:30:29rueAffected effect
18:30:48dbussinkevan: do you think it would be possible to perhaps write rbx specific extensions that use primitives to bind to other libraries?
18:30:58dbussinkevan: so as an alternative to the c api with less overhead?
18:31:14evanum
18:31:14evanno.
18:31:18evani'd prefer not.
18:31:29evani'd rather we have another mechanism
18:31:36evanprimitives are controlled
18:31:42evanthey're the VM exported data to ruby land
18:31:42dbussinktrue yeah
18:31:51evanthey're not the wild west.
18:31:55dbussinkhehe
18:31:57rueBe better if the C API were less crazy but I am not getting the vibe that it can be changed for 2.0
18:32:22dbussinkjust wondering if there would be anything non wild west for people writing sane extensions :P
18:32:41evani've thought about that
18:32:51evani'd prefer to work on a 3rd mechanism for those people to use
18:32:53ruedbussink: I would really, really prefer to push FFI.
18:33:20evanrue: we need to come up with a solution to the FFI struct layout problem.
18:33:34evannamely, that it's incredibly trial and error to get it right by most users
18:33:35rueYef
18:34:00evanthats one place where a C extension shines
18:37:34rueBut the subset that really *needs* an extension as opposed to FFI is very small. Assuming a sufficiently fast Ruby and sufficiently capable FFI
18:38:59evanwell, lots of C libraries require you to read a struct
18:39:11evanand when a user hits that, they hit a bunch of pain in FFI
18:39:26evannot that it's not solvable by the user, but it's not trivial.
22:37:03boyscoutImplement a new GIL algorithm to prevent starvation - 6d55328 - Evan Phoenix
22:37:03boyscoutOnly add -lruby if MRI was compiled with shared - 7646d69 - Evan Phoenix
22:37:56_ko1seems interesting... > 6d55328
22:38:23evan_ko1: yep!
22:38:28evan1.9 has the same problem
22:38:36_ko1any description>?
22:38:45_ko1or Python 3.1 algorithm?
22:38:45evanthe commit details the problem
22:38:47evanand my fix
22:38:56evanlots of comments in that commit
22:39:02evanto explain the situatino
22:39:27evanthe main bug is pthread_unlock(gil); sched_yield(); pthread_lock(gil);
22:39:34evancan easily starve all other threads on the system
22:41:01_ko1http://www.dabeaz.com/python/GIL.pdf
22:41:05_ko1same as this issue?
22:41:55_ko1i made a patch for CRuby, but not verified (and leave it ...)
22:42:32evanyes, check out the newgil.pdf
22:42:37evanthats the one that details the fix
22:43:01evan_ko1: there are 3 urls in that commit
22:43:03evanat the top
22:43:05evanthat discuss it
22:43:17_ko1can I check via web?
22:43:22evanyep
22:43:26evanone sec, i'll get you a url.
22:43:36_ko1i'm very newbe on git :(
22:43:42evanhttp://github.com/evanphx/rubinius/commit/6d55328ca73092b2d89491e25c2f0c078048e716
22:43:44evanno problem.
22:43:45evanthere you go.
22:44:11_ko1ah, great
22:44:14_ko1thank
22:44:15_ko1s
22:44:20evanthis is a little easier to read: http://github.com/evanphx/rubinius/blob/master/vm/global_lock.cpp
22:45:30evan_ko1: i'm going to go for a run
22:45:36evani'll be back in an hour or so
22:45:43evanand we can discuss if you'd like
22:45:44evanok?
22:45:44_ko1OK
22:45:57_ko1but i have no time because today is RubyKaigi!
22:46:04evanno problem!
22:46:09evanyou know where I always am
22:46:12_ko1this is morning here.
22:46:13evananytime to discuss is fine.
22:46:16evanyep!
22:46:29evansay konichiwa to everyone at rubykaigi for me!
22:46:52_ko1ok
22:46:53evan(i wonder if i spelled that right)
22:47:15_ko1correct
22:47:33evanok, i'll be back in about an hour
22:52:43boyscoutCI: rubinius: 7646d69 successful: 3520 files, 15244 examples, 43093 expectations, 0 failures, 0 errors
23:46:42duncanmvyo
23:47:33brixensup
23:49:42duncanmveveryone sleeping, trying to move my struct c api forward :-)
23:52:54brixendid you file a ticket?
23:53:11duncanmvfor?
23:53:21brixenyour patch?
23:53:32duncanmvfor the rb_hash function I did a pull request
23:53:42duncanmvfor the struct part, I am not done yet
23:54:02brixenwell, we prefer a git fp in a ticket
23:54:34duncanmvfp?
23:54:59brixenformat-patch
23:55:45brixena ticket is a sure way not to lose something
23:55:58brixengithub message spam is a pain