Index

Show enters and exits. Hide enters and exits.

00:00:11evandoing so puts my dup benchmark on terms with 1.8
00:00:13evanwhich is good.
00:00:22brixennice
00:03:13goyox86brixen: knock, knock
00:05:16brixengoyox86_: who's there?
00:05:32goyox86brixen: goyox86
00:05:39brixengoyox86 who?
00:06:04brixenwonders what the punch line is...
00:07:04goyox86brixen: I don't know i think is mi ic client, it adds a _, i think i just left my session opened at home
00:08:39goyox86brixen: I just started to look for something where i can help, so i've started with an easy one, making a soec pass
00:09:43goyox86brixen: i've created a patch, when you have some free time just check issue 392 :-)
00:12:52brixensure
01:00:14boyscoutFix File#size to conform to specs. Closes #392. - c628090 - Jose Narvaez
01:00:14boyscoutSpec that File.size and .size? try to convert argument to an IO. - 9f688ec - Brian Ford
01:00:14boyscoutFixed File.size and .size?. - 8dc7322 - Brian Ford
01:00:14boyscoutUpdated CI tags for File. - 2e334b5 - Brian Ford
01:00:23brixengoyox86_: there ya go :)
01:02:46goyox86brixen: sweet
01:08:35boyscoutCI: rubinius: 2e334b5 successful: 3457 files, 13668 examples, 41247 expectations, 0 failures, 0 errors
01:42:38postmoderndbussink, ping
01:42:50postmoderndbussink, I have the profiler graph for Bundler.setup
01:43:11postmoderndbussink, snusnu/dm-core/tree/postmodern
01:43:12postmoderner
01:43:20postmoderndbussink, http://fpaste.org/D9QP/
01:43:41evanpostmodern: the flat graph would be useful too.
01:44:09postmodernevan, would that be the output of just -Xprofile ?
01:44:15evancorrect.
01:57:56postmodernevan, to recap, the loading rubygems did slow down startup a bit
01:58:07postmodernevan, but Bundler.setup is extremely slow, compared to other implementations
01:58:28evanok
01:58:33evanwell, we'll have to dig in and figure out why.
01:58:47evanI profiled rubygems a bit today
01:59:03evanwe take a pretty big hit because it eval's the gemspecs on startup
01:59:13evani need to discuss with the rubygems guys about that
01:59:24postmodernyouch
02:09:32boyscoutSpeed/foolproof Kernel#dup. Add custom object_class inline logic. - 110b9b6 - Evan Phoenix
02:12:18postmodernevan, here's the flat graph http://fpaste.org/UOOo/
02:18:00boyscoutCI: rubinius: 110b9b6 successful: 3457 files, 13668 examples, 41247 expectations, 0 failures, 0 errors
03:58:43seydarbrixen: i'm looking through some old code and i just found this: http://pastie.org/1024533
04:00:07seydaralso i have a laptop now
04:00:13seydarwith over 512MB of RAM
04:00:22seydarand get this – an INTEL CPU
04:00:47seydari have 8 times as much ram as I used to
14:18:56goyox86evan: sweet, About Rails performance?
14:19:17goyox86even: the screencast?
14:19:51goyox86evan: the screencast?*
15:46:57cremesthis might be interesting to evan, brixen and slava: http://etoileos.com/news
16:10:53brixencremes: cool, so Obj-C is catching up to rbx :)
16:14:02evani've followed etoile a bit.
16:14:13evanthey're sort a cousin now because of LLVM usage.
16:24:57wyhainesSo, it looks like rbx more or less fails on the same BigDecimal rubyspec tests that 1.8.6 fails on, except for one that rbx passes that 1.8.6 fails on. It fails on a couple more than 1.8.7 fails on.
16:26:18brixenwyhaines: that's not surprising since we are using BigDecimal from MRI
16:26:19wyhainesSo, it begs a question. I've fixed all of the 1.8.6 failures (they are all fixed with some bugfix backports from 1.8 trunk), so I'm going to suggest that these be fixed for 1.8.6 and 1.8.7. Would you all like me to make the same fixes to rbx?
16:26:31brixenwyhaines: we just need to port the fixes, yes
16:26:47brixenwyhaines: if you want to do that, wonderful :)
16:29:04wyhainesCool. I'll do so, then. Just seems like 1.8.x should all do the same reasonable stuff with BigDecimal, and rbx should, likewise.
16:33:07evancremes: we can actually do a lot better than etoile
16:33:15evanbecause we don't have to speculatively inline
16:33:21evanwe can do it based on profiling
17:14:39cremesevan: glad to hear it; i'm looking forward to *more* cool compiler tricks for rbx 1.1 and later :)
17:15:18evan:D
19:09:15boyscoutImprove write barrier performance - 1df37d9 - Evan Phoenix
19:11:55dbussinkevan: turned up from profiling?
19:12:09evanyeah
19:12:18evanreading zone() is more expensive than it used to be
19:12:22evandue to inflated headers
19:12:36evanso i got a method working that uses just pointer comparisons on the object address
19:12:52evanand inlined a bunch of the conditions in a C++ inline method
19:15:58dbussinkevan: ah, nice trick for the pointer math :)
19:16:54slavayo evan
19:16:58evanyeah, i grouped all the young object spaces in one contigious section of memory
19:17:02evanfor easy checking.
19:17:17evanslava: allo.
19:17:37evanwell, lunch time.
19:20:36dbussinkevan: it wasn't in one zone before?
19:21:31boyscoutCI: rubinius: 1df37d9 successful: 3457 files, 13668 examples, 41247 expectations, 0 failures, 0 errors
19:52:18evandbussink: eden and the 2 survivor zones were allocated seperately with malloc
19:52:22evanso no, they weren't contigious
19:53:15dbussinkevan: ah yeah, i see, full is now eden and a en b
19:53:17dbussinka and b
19:53:21evanyep
19:53:34evanfull isn't allocated directly into either
19:53:39evanit's just split up for the young zone
19:53:54evanand actually, walking to lunch, i got an idea
19:54:00evani'm going to make Class#allocate a GC point
19:54:07evanand start the process of making allocation thread safe
19:54:17evanby using slabs
19:56:05slavamaking allocation a GC point makes total sense
19:58:35evanyeah
19:58:50evanbut i'm going to allow for allocaitons that aren't GC points either.
19:58:57slavawhat for?
19:59:01evanso that I don't have to fixup all the internal allocations
19:59:06slavalazy :)
19:59:12evanpragmatic.
20:01:31evanbesides
20:01:38evanthose types of allocations are very useful.
20:01:46slavabecause of C extensions and such?
20:01:49evanyep
20:02:12evanI think i'm going to do slab'ing of the young space
20:02:38evanthe main allocation point, Class#allocate with use a thread-local slab and be able to run the GC if there is no more space
20:02:57evana global slab will be used by the internal allocations
20:03:06slavaah
20:03:10slavaand you can phase the latter out over time
20:03:28evanright
20:03:29slavaI must admit making all my allocations GC-safe was a bit of a pain but it was worth it in the end
20:03:35slavabut I don't have legacy issues to contend with
20:03:49evanthe slab'ing is how to make allocations fast and threadsafe anyway
20:03:54evanso doing the work now will pay off.
20:06:23dbussinkyay to more thread safeness :)
20:23:32dbussinkevan: one step at a time for getting rid of the gil :)
20:23:39evanyep
20:24:25dbussinkevan: what are other big steps that need to be taken?
20:24:36evanwell, there are a lot of steps.
20:24:57evanfor instance, we need to iron out a good object locking strategy
20:25:06evanwe need that now
20:25:10evanso thats high on my list
20:25:36evani'm leaning toward the JVM "every object is a lock" strategy
20:26:07evanbut i'll probably write some atomic operation stuff first
20:26:31dbussinkextensions are also probably tricky with this right>
20:27:04evansomewhat tricky
20:27:09evanbut not as tricky as you might think
20:27:11evanbecause of the handles.
20:27:25dbussinkah ok, it's easier than to make those safe
20:27:35dbussinkand we don't allow the most nasty things anyway
20:27:41evanright
20:27:47evanthe uglyness is isolated in handles
20:28:02evanand the boundary between handles and GC memory is guarded by a 3 headed dog.
20:29:18dbussinkevan: there are no cerberus references in the code yet :P
20:29:24evanwe shall change that.
20:30:21dbussinkevan: there was this nice article on how to do fast locking right?
20:30:28dbussinkwhere no contention is the common case
20:31:45evancliff has a good blog post on it, yeah.
20:32:29evanyou use a CAS instruction (compare-and-swap) which is atomic to test lock an object
20:32:36evanif it works, great, you go on
20:32:41evanif not, then you go down a slow path.
20:34:41slavaI'm realer than a hundred dollar bill with the line across
20:35:37evanfor reals?
23:46:40pjb3I get the following error when trying to use datamapper, sqlite and rubinius
23:46:41pjb3http://pastie.org/1025933
23:47:05pjb3Any chance of datamapper / sqlite working?
23:49:39parndtpjb3: what happens if you use http://rubygems.org/gems/sqlite3-ruby
23:51:48pjb3same problem
23:52:11pjb3There must be something I need to do to make dm use sqlite3-ruby
23:52:45cremespjb3: you may want to ping dbussink; i think he is working on getting DM to pass all specs on rubinius