Index

Show enters and exits. Hide enters and exits.

04:55:03evangotta love living in an active earthquake zone.
04:55:16evanon the upside, the new loft survived the 5.0 earthquake test!
05:03:37scoopr:D
05:04:25slavahi evan
05:10:18slavaevan: so I've started an overhaul of my code generator so that it keeps values in registers between basic blocks
05:10:28slavaevan: should give a big speed boost for low-level loops and such
13:49:47scooprjust wow.. http://chris-lamb.co.uk/2008/01/24/can-you-get-cp-to-give-a-progress-bar-like-wget/
13:53:21ruescoopr: Get the shotguns, I will find book a flight
13:53:49scoopr=)
15:35:18dbussinkhttp://timetobleed.com/fixing-threads-in-ruby-18-a-2-10x-performance-boost/
15:51:57zinfwonders what the current state of the art is for rubinius
18:56:47evangood morning
19:00:29brixenmorning
19:00:45dgtizedmorning
19:00:50brixenany more rumblings down there?
19:01:08brixenand I don't mean did you have breakfast :)
19:01:18evanhah
19:01:20evanno
19:01:24evanthere was a 3.1 aftershock
19:01:31evanbut I didn't feel it
19:01:45brixenwhat was the 5.0 like?
19:02:10evanit's hard to explain what it's like when the whole room begins to shake independent of you
19:02:25brixenwere you at the loft when it happened?
19:02:27evanbecause we're so used to things like rooms being stationary
19:02:29evanyep
19:02:34evansitting on the couch, watching TV
19:02:44brixenso everything is ok with the building?
19:02:49evanyep!
19:02:52brixencool!
19:02:56evanit survived it's first 5.0!
19:02:57tarcieriheh crazy
19:03:09evannothing fell down
19:03:12evanwhich is the usual worry
19:03:15evanbook cases, etc.
19:03:40evanso yeah, i'm trying to compare it to something...
19:03:45evanbut i've got no frame of reference
19:03:50evanother than previous earthquakes
19:04:09brixenwell good news the building weathered it well
19:04:12evanyou hear the building creek as it moves
19:04:51tarcieribeing in an earthquake sounds pretty absurd
19:05:12evanit is
19:05:19evanyou know how humans are used to the ground being well, the ground.
19:05:37evanthis flys in the face of millions of years of thought
19:05:56tarcieriheh
19:06:01evansorta like being on a roller coaster, you have to be in one to know what it's like
19:06:14tarcieriearth moves, humans stay still instead of vice versa?
19:06:24evanyeah
19:06:37evanall of a sudden, things are moving underneith you
19:06:39evanand beside you
19:06:48evanbecause they all pick up the momentum before you do
19:06:57evanin a 10 second one, your body never picks up the momentum
19:07:40evanin LA though, whenever there is an earthquake, everyone things "uh oh, is this the BIG one?"
19:07:54evanthinks
19:08:08evanbecause we've overdue for a 7+ earthquake
19:08:19evanwhich, when it happens, will last up to 10 minutes
19:09:33tarcierithis is like the second time I've visited somewhere and a few weeks later there was a major earthquake
19:10:03evanyou were just in LA?
19:10:12tarcierierr, just in San Fran I guess :/
19:10:31evanwell, thats close but no cigar
19:10:40evanSF is a different zone
19:10:58tarcieriyeah apparently I'm confused as to the location of the earthquake
19:11:43evanLA is built over the edge of the Pacific and North American plates
19:11:50evanlike literally right on the edge
19:11:58evanabout 30 miles of LA is moving north
19:12:11tarcieriyeah there's that little chunk of California that's gonna slide into the ocean some day
19:12:13evanif you've seen "Escape from LA", you know what I mean :D
19:12:17tarcieriheh
19:14:50evanso, i'm working on the background compiler thread
19:15:03evanwhich means i'm doing what will become the first stages of removing the GIL
19:15:20evanbecause there are some VM structures that need to be protected, so they can be used from both places
19:15:26evanat the same time
19:15:30evanlike the SymbolTable
19:32:43brixenevan: ah cool
19:37:28evani've added a SpinLock to symbol lookup
19:37:54evani'm really glad I added all those nice C++ classes for dealing with locks
19:55:48evanhm, I wonder if I should track the module a CompiledMethod belongs to
19:56:20brixenwhat advantage is there?
19:56:43brixenI can't remember why we don't track it
19:56:53evanwell, you can ask a CompiledMethod for it's full name then.
19:56:59evani think i'm going to make that change
19:57:03evanbut in a wider context
19:57:03brixenah sure
19:57:27evani've mentioned refactoring the Compiler to generate CodeBlock objects
19:57:31evanrather than CompiledMethod's
19:57:48evansince thats what they actually are
19:58:04evanie, using a CompiledMethod for a block is, meh.
19:58:11evanit's a lot of needless info
19:58:11brixenyeah
19:58:26evanI think i'll look at this shortly.
20:24:10brixenI heard adium has twitter support too
20:24:17brixenhow's the irc?
21:03:07lypanovum
21:03:20lypanovevan: adium fucking rocks
21:05:08lypanovwonders how rubinius is doing as jruby got all exciting again
21:06:01evanwhat ya doing in jruby?
21:06:58evanlypanov: things are good here
21:07:05evanworking on the LLVM JIT again
21:07:31evanabout to push the ability to run the JIT in the background
21:08:12lypanovyay!
21:08:19lypanovwas so sad when i heard you wouldn't be using llvm
21:08:56lypanovevan: ahhh neat. so you can use a background low prio thread for the code gen and interpret if native isn't available?
21:09:29evannot sure what ya mean by interpret if native isn't availabel
21:09:30evanbut yeah
21:09:38evanyou can request a CompiledMethod to be JIT'd
21:09:50evanand a request is sent to a waiting thread
21:11:36lypanovif not already jitted i mean
21:11:42lypanovyou do mixed mode already?
21:11:45lypanovor only jitted?
21:11:46evanyep
21:11:48lypanovcool
21:11:48evanmixed mode
21:11:52evanwill always do mixed mode
21:12:02evanhaving the interpreter is just too valuable
21:12:04evanto fall back on
21:12:26lypanovimpossible without i think
21:12:34lypanovyou can't do anything interesting if you don't have a slow path
21:12:59lypanovevan: how are benches?
21:13:06lypanovevan: what sort of optz already in place?
21:13:54evannot many optz yet
21:14:02evanworking mainly to get the JIT understanding all the bytecodes
21:14:06evangetting close to that now.
21:14:19evanone optz I did do is IC spying for primitives
21:14:23evanie, type feedback
21:14:24lypanovdid you end up doing the neat trick with llvm instrinsics for ops?
21:14:44evanso the JIT will read an IC, and if the method there is the Tuple::at primitive
21:14:52evanit inlines the code to perform Tuple::at at the call site
21:15:04evanso calling Tuple#at is nearly free
21:15:04dgtizedevan: so is JIT auto enabled now, or what is the new flag?
21:15:09evanit's like accessing a C array
21:15:15evandgtized: no, not auto enabled
21:15:35evanyou have to pass some build flags
21:15:46evanand it's not automatically invoked yet by the VM either
21:15:49evanyou have to do
21:15:53evanRubinius.jit method(:blah
21:15:54evan)
21:16:02evanor, coming shortly
21:16:09evanRubinius.jit_soon method(:blah)
21:16:31dgtizedok, but the automatic decision to jit a method after it runs > 50 times is not currently enabled?
21:17:29evancorrect.
21:17:41evanthat will be added maybe today
21:17:43evanwe'll see
21:17:53boyscoutOnly use the JIT calling debug trampoline in debug mode - 9de05c7 - Evan Phoenix
21:17:53boyscoutAdd background compiler thread to speed up performing JIT - 7469cc5 - Evan Phoenix
21:18:12lypanovevan: how is speed?
21:18:20boyscoutCI: Build 7469cc5 failed. http://ci.rubini.us/rubinius/builds/7469cc54faa2169257a836744998577f17896d50
21:18:20evanso far, good.
21:18:24evanbah!
21:18:35evanle sigh.
21:18:40lypanovla
21:18:46lypanov( :P )
21:19:05boyscoutRemove extra qualifier - 51b8034 - Evan Phoenix
21:19:22evanat the beginning of the work, the Array#each benchmark took 8s with 5k iterations
21:19:29evanit currently takes 3.5s
21:19:36evanMRI takes 4.9s
21:19:40lypanovand interp?
21:19:41evanand it implements Array#each entirely in C
21:19:50evanours is entirely in ruby
21:20:08lypanovwhere is the cost?
21:20:17evanwhich cost?
21:20:19lypanovas in why so slow?
21:20:31lypanovhow is yarv?
21:20:32evanya think 3.5s is still slow?
21:20:54lypanovi think it would probably be much faster in java, yes
21:21:17evanwell, it calls out to a closure
21:21:23evanwhich is not inlined or viewed into at all.
21:21:24lypanoveven mri?
21:21:27evanof course
21:21:29lypanovk. yeah. that'd be why
21:21:39evanas does yarv and jruby
21:21:44evanno one does block inlining
21:21:46evani'm aware of.
21:21:50lypanovyeah. they all suck
21:21:57evanif you can do it
21:22:00headiussome blocks will inline to some level in jruby
21:22:01evanplease add it to rubinius :D
21:22:12evanheadius: oh? like?
21:22:17lypanovheadius: how does invoke fit into this?
21:22:36lypanovis the dispatch semantic enough for it to opt?
21:22:44headiusblocks can inline into java-based #each impls, for example, if it's not polymorphic
21:22:45lypanovhopes that makes ANY sense
21:23:15headiusand they could easily inline into the yield point if I did a little more work on it
21:23:27headiusparts of them do already, but not all the way to the block body
21:23:27evanheadius: well, thats kind of the wrong place to inline
21:23:34evanyou don't want the block inlined into the #each method
21:23:34lypanovheadius: so simple things like "sum" implementations for example?
21:23:40evanyou want the #each method + block inlined into the caller.
21:23:53headiuswell, the problem is that the intervening method is going to be poly or megamorphic in almost every case
21:23:59evanyes
21:24:09evanblock invoking is like 100% poly
21:24:11headiusso unless you can inline across megamorphic calls, it's not a simple case
21:24:23evanwell
21:24:29evanit's monomorphic if you inline into the caller
21:24:43evanbut thats a much more complicated inline strategy
21:24:45headiusbut that means you need to inline and then re-profile and then inline again
21:25:05lypanovthis is another time when i think i had the right idea and want to kick myself for not haing the motivation / pragmatism to pull it off
21:25:06headiushotspot doesn't even do that for static java code
21:25:18dgtizedweird question, could you special case inline each by injecting the logic into the block, instead of trying to inline the each and the block into the caller?
21:25:28dgtizedsorry the each logic into the block
21:25:45evandgtized: how do you know what logic to put into the block?
21:26:00evanBUT i think you're onto something there
21:26:08lypanovdgtized: for some simple hardcoded cases eg homogenous array each yes
21:26:19headiusdgtized: a better strategy may be to have a separate path in the code that assumes it's a specific kind of each, so the block can inline there
21:26:23evanthe JIT could see that Array#each is being called
21:26:23lypanovbut while cute, its kinda not really what is needed in long term
21:26:40evanand take the code for the block + the code for Array#each
21:26:42evanto create a new block
21:26:51dgtizedright
21:26:56evaninsert a guard
21:27:02lypanov(yay guards)
21:27:02evanthen the new block is invoked once
21:27:04evanand looped within
21:27:08evanthat actually is a great idea
21:27:12headiusunless you're going to regenerate that for every each encountered by the block, I don't see how it's any better
21:27:15evanbecause that fixes the problem i've run into
21:27:23evanie, variable scoping when inlining blocks
21:27:36lypanovheadius: every each?
21:27:41evanheadius: no no, other side of the coin
21:27:55evanyou're generating methods at the call site for #each
21:28:06evanwhere, likely, #each is monomorphic
21:28:10headiusthat's what I was talking about
21:28:11lypanovright
21:28:11evanand the block is definitely monomorphic
21:28:21lypanovwhy would you need to regen?
21:28:26lypanovand whats "every each"?
21:28:36lypanovthere is a variant for every inline block yes
21:28:40lypanovbut whats the issue with that?
21:28:50headiusthere's potentially many each impls
21:28:56boyscoutCI: 51b8034 success. 2683 files, 10323 examples, 32868 expectations, 0 failures, 0 errors
21:29:01lypanovbut not exponential so don't see the issue
21:29:03headiusand the block needs to pass into them, and then they need to do their invocation
21:29:13lypanovof course block inlining adds code mem
21:29:17evanheadius: you're saying that the call to #each might not invoke Array#each everytime?
21:29:21evanthats what the guard is for
21:29:37lypanovum
21:29:40lypanovwait a sec
21:29:42headiusyeah, and then this is either only useful for Array#each or you have to generate new for all the other eaches too
21:30:09dgtizedthis is trace jitting special cased for each
21:30:12lypanovi think its an interesting hardcoded case
21:30:24headiussure, the hardcoded case was exactly what I was trying to describe
21:30:28lypanovdgtized: my vm design is trace jitting. i hope rubydium gets there some day
21:30:36dgtizedI think you could do it for anything that takes a block though
21:30:45dgtizedit's just each is the easy one to think about
21:30:47lypanovbut i guess it more likely that rubinius will :P
21:30:59lypanovdgtized: fully agree
21:31:14evanyou're still having to invoke a block
21:31:15headiuswell, inlining across multiple levels is back to the polymorphic case again
21:31:16lypanov"once you've written it twice, then refactor it / make it a method"
21:31:17lypanovso
21:31:20evanbut you're only having to do it once
21:31:21lypanovdo two hardcoded opts
21:31:22evanwhich is nice.
21:31:24lypanovthen abstract it
21:31:33headiuseven with a tracing jit you need to be able to guard/bail
21:31:42evanok smart guys
21:31:46evanif i'm to continue
21:31:48lypanovheadius: of course but that doesn't mean its not worthwhile :)
21:31:49evani need food first :D
21:32:01headiuslypanov: well, maybe and maybe not :)
21:32:16headiussome of us have to balance production support against spending weeks working on inlining each + block :)
21:32:22headiusthere's only so many resources available
21:32:56headiusnow invokedynamic has an alternative solution to this
21:33:21dgtizedsupports the idea of food for evan to continue
21:34:19evanfor jruby this idea matters less
21:34:20headiusinvokedynamic may allow specifying that particular frames in the call path are just intermediaries
21:34:26evanbecause hotspot is already doing so much
21:34:32evanfor me, it could potentially matter a lot.
21:34:34headiusand so they'll inline wheever they're called and profile
21:34:42headiusevan: sure, or you could just not use blocks in core :D
21:34:58dgtizedheadius: mostly we aren't using blocks in core actually
21:35:03evanyeah hm. no. :/
21:35:04lypanovmake ruby useless to anything that needs speed
21:35:14lypanovits the reason why i'm probably gonna end up using scala no matter what happens ;)
21:35:22evanok lunch.
21:36:06lypanovheadius: i like invoke dynamic. don't get me wrong
21:36:22lypanovheadius: if you can get that working its a far better option than messing around doing it all yourself
21:36:35lypanovjust talking about rubinius
21:38:05headiuslypanov: you should look at wycats' scala_ext project
21:38:16headiusit's a set of nice DSLish stuff to define JRuby extensions in Scala
21:38:49lypanovwonders sometimes if wycats is a collective
21:40:30headiusit works pretty well so far...though since scala can't define static methods we need to add a better way to define module methods (which are normally static right now)
21:41:15lypanovhow does "object" make it into bytecode?
21:48:35headiuslypanov: "object"?
21:49:25lypanovheadius: shortcut in scala for singleton classes.
21:49:33headiusahh
21:49:39headiusit's friggin weird
21:50:01lypanovread the artima interview with odersky on orthogonality of the design
21:50:07lypanovvery good interview
21:50:42lypanov(http://www.artima.com/scalazine)
21:50:56headiusit essentially gets turned into a singleton object accessible through a static accessor and then methods are called on that
21:51:03headiusthere's no way to create a normal static method in scala
21:51:46lypanovsurely you can still use it? pretend the static accessor is a kind of proxy?
21:51:54lypanovsounds like a good way to do the mapping to me
21:52:44headiuslypanov: the problem is that it hides that stuff
21:52:54headiusyou can't actually go after the static methods without a bunch of reflection tricks
21:53:08headiusyou don't get to see all that stuff, basicaly
21:53:15lypanovbut don't you control both sides?
21:53:30headiusno
21:53:33lypanovas in you can just say staticMethodProxy().myMethod() and pretend its static?
21:53:34lypanovahhhh okay
21:53:38headiusthe singleton side is generated magically for you by scala compiler
21:53:52headiusand calls to the object are calls through that singleton behind the scenes
21:53:54lypanovno i mean. you control the scala. you control the ruby. sounds like enough to make a mapping
21:53:58headiusthere's *lots* of that kind of magic
21:54:15headiuswell scala generates weird mangled classes and method names for that backend stuff
21:54:27headiusthey would be diffcult to use, if it's possible at all
21:54:45lypanovonce used mono's system reflection emit to write a baby monomorphic ruby interpreter back when the ruby mono bindings only allowed for static method calling
21:54:47headiusthe way I would propose to handle this in JRuby is that we need a nice scala API for defining method objects directly
21:55:01headiuswhich is fine...it's just that the autowiring stuff we have now depends on class/module methods being static
21:55:12lypanovmany things are changing in scala 2.8.0
21:55:21lypanovto the way .class files are generated
21:55:58headiuswhat, scala changing major things in a minor release? you're kidding!
21:56:17headiusI was amazed that 2.7.3 to 2.8 meant they added things like keyword args in constructors
21:56:19lypanovyeah, cus java never did that lol
21:56:21headiusI don't really get their cycle
21:56:48lypanovi am getting told off by my girlfriend for not being a productive lil boy. so. i have to go code
21:56:49headiusthe scala backend class stuff is really kinda gross, when you know what it's doing
21:56:54lypanov(i love my fiancee)
21:57:02headiusseeya!
21:57:15lypanovcya :)
21:57:21lypanovi used java back in 1.1 days btw
21:57:22lypanov:)
21:57:34lypanovso... yeah. minor release ;)
21:58:01lypanovused ruby in the 1.6.x days, which was probably the stupidest thing ever to do, he's still scarred
21:58:06lypanovgone :)
22:22:12evanyay!
22:22:17evanmy LLVM patch was accepted
22:22:21evanno need to apply it manually anymore
22:22:27evanif you use SVN HEAD of LLVM
22:30:55brixensweet
22:40:14dgtizeddo we have a benchmark that hits Regexp.escape nicely?
22:40:32evanbrixen: so, you can now do
22:40:38evanRubinius.jit_soon meth
22:40:42dgtizedoh nm, I see we have one with a fixed string
22:40:48evanand it will be JIT'd in the background
22:41:21brixenevan: awesome
22:47:02evanok, it's new chair day
22:47:15evanstaples has some decent mesh chairs in stock up the road
22:58:48boyscoutmodified regexp benchmark to vary string length in addition to iterations - e2aa247 - Charles Comstock
22:58:48boyscoutswap Regexp::ESCAPE_TABLE from Hash to Tuple for >2x speedup - 9c2dae4 - Charles Comstock
23:01:06boyscoutCI: 9c2dae4 success. .................................................................................................... .................................................................................................... .................................................................................................... ...............................................................................
23:01:12brixenor not
23:02:23brixeninteresting assertion failure
23:02:28dgtizedI've been getting that same random LinkList failure locally at random intervals
23:02:37dgtizedbut I was getting before that patch so I don't think it's related
23:02:50brixenprobably not
23:02:57brixenI've never seen it on os x
23:03:22dgtizedit's happened at least twice here on an mspec run today, I don't think I saw it before this weekend
23:03:34dgtizedbut it wasn't reproduceable
23:03:48dgtizedor particularly frequent
23:05:37dgtizedwhoops happened again, alright I will try and get it to happen under gdb
23:06:33evanif we can get the backtrace from it
23:06:35evanit should be easy
23:06:42evanlooks like the LinkedList is getting corrupted
23:10:02dgtizedwait how do we get gdb to run mspec these days?
23:10:50dgtizedjust --spec-debug or do those require -K -S options?
23:10:55evan--gdb
23:10:56evani believe
23:11:07evani have a special file I specify with -t
23:11:16evanthat runs gdb --args bin/rbx "$@"
23:13:49dgtizedtrying --spec-gdb, --gdb is listed as option but appears to be broken
23:14:04dgtizedhmm, and that hit the error but wasn't running gdb
23:17:20brixen--gdb was an option to work with shotgun
23:17:25dgtizedhmm with -fs the "describe a running thread" specs seem to pause a lot, and the spec that triggers the failure is in conditionvariable
23:19:54evanah
23:19:57evanuse the -t method then.
23:20:13evankendall :: git/rbx ยป cat bin/rbx-debug
23:20:13evan#!/bin/sh
23:20:13evanexec gdb --args bin/rbx "$@"
23:20:20evanchmod a+x bin/rbx-debug
23:20:28evanbin/mspec -t bin/rbx-debug ...
23:21:49evanoh der.
23:21:51evani see it
23:21:55evanthere is a bug in LinkedList
23:22:33evanoh hm.
23:22:51dgtizedok it's triggered in the conditionvariable specs, and I have a backtrace into it right now
23:23:09evanpastie it
23:23:40dgtizedhttp://gist.github.com/113788
23:24:00evanyep
23:24:00evanok
23:24:03evanit's in the RootSet
23:24:08evanok, one sec...
23:25:18evanoh der.
23:25:22evanit's the change cezarsa did yesterday.
23:25:33evanthe fix is easy.
23:26:31boyscoutinitialize the thread with the GIL held - 54c12c6 - Evan Phoenix
23:26:41evandgtized: that should fix it.
23:27:05evanprobably need to move the root set to be per Thread
23:28:39dgtizedI wonder why it was only triggering on linux
23:29:31dgtizedthat seems to have fixed it though
23:29:32boyscoutCI: 54c12c6 success. 2683 files, 10323 examples, 32868 expectations, 0 failures, 0 errors
23:30:27evanah
23:30:39evanbecause of the vastly different thread scheduler
23:30:53evanso the timing is completely different on linux
23:31:18dgtizedwhich means rubinius threading errors are going to be more system dependent then?
23:31:35evanall threading errors are system dependent
23:31:47evandepends on what you call a rubinius threading error
23:31:54dgtizedI'm not sure if they were with green threading is all I mean
23:32:19headiusdiggity
23:32:19evanif who were?
23:32:22evani'm not following.
23:33:13dgtizedI'm just curious how many race conditions will be exposed as people try their threaded code on platforms other then MRI's green threading
23:34:26dgtizedlikewise, since our scheduling is less consistant across systems, it's more likely to expose race conditions
23:35:21dgtizedit's a good thing, but it's going to be unexpected for some folks
23:36:52evandgtized: none that will cause VM crashes
23:37:12evanif people are dumb out their code and their code depends on the behavior of MRIs threading model
23:37:17evanthen it could behave differently
23:37:25evanthankfull, jruby has sussed a lot of that out already
23:38:22evanok
23:38:22evanbbiab.
23:38:49headiusI don't mean this to sound discouraging, but mapping all the green threading nonsense to parallel threads is frigging hard
23:39:01headiuseven on top of making a VM that can do parallel threading
23:39:13headiushotspot does 95% of the hard stuff for us and it's still really hard
23:40:52evanheadius: you mean the uniquely Green thread features
23:40:53evanyes?
23:40:58evanThread#stop, etc.
23:41:13evanor do you mean timing issues
23:41:22headiuswell both really, since they're interrelated
23:41:39headiusso the bad thread operations are one half, but then just memory model concerns are even trickier
23:42:06headiuswe have various guarantees from the JVM about when threads will see each others updates, etc, but it means we have to cause certain reads/writes to flush caches
23:42:30headiusgetting that end right in the VM is obviously really hard, but doing it right in the impl on top of that VM is almost as tricky
23:43:04evanah
23:43:04evani see
23:43:13evanyou mean like the idea that String has no lock
23:43:28evanin MRI, that doesn't matter, since String's operations are atomic by threading nature
23:43:36headiuswell that we just punt on...it's not thread-safe and shouldn't be expected to be
23:43:50headiusno sane parallel-threaded impl would force you to use mutexed collections for everything
23:43:58headiusbut the sneakier ones are things like call sites
23:44:14headiusdo you know that when thread B invalidates a method or a call site when thread A will see that?
23:44:26headiusif it's in cache it may not get flushed...ever...for thread A
23:44:42evanah.
23:44:43evangotcha
23:44:47headiusthread A would continue blissfully unaware that another thread on another core has invalidated something
23:44:50headiusthat stuff is all over the place
23:45:04headiuswe still struggle with it
23:45:19headiusright now we pay the cost of making a lot of fields volatile and forcing cache flushes on almost all calls
23:45:37headiuswe're trying to find ways to coarsen that by defining what concurrency you should actually be able to expect from a parallel ruby
23:45:53headiusin essence, we need to define what ruby's memory model is supposed to be in the presents of parallel execution
23:46:13headiuspresence
23:46:19evansure
23:46:31evanthose are definitely issues
23:47:09evanwell, new chair time!
23:47:16evanso i can sit and work on these issues!
23:47:21headiusjohn rose told us that our first doubling of performance might come from inlining, but a second double might come from addressing that "too much volatility" issue