Index

Show enters and exits. Hide enters and exits.

03:56:15evanbrixen: so, having now done C++ for a while
03:56:19evani can read the strongtalk code
03:56:34brixensweet
03:56:46brixenwhat's it whispering in your ear? :)
03:56:53evanheh
03:56:59evani'm reading through it's logic for inlining
03:57:06brixenahh!
03:57:08brixenexcellent
03:57:09evani haven't yet found where it inserts a guard
03:57:15brixenfeel free to point me to code
03:57:25evanbut it appears to construct a sea-of-nodes from the bytecode
03:57:44evanand it simply splices the callee's start node into the call site in the caller
03:58:07evanso the call appears to disapper, being replaced with the callee code
03:58:10brixenI thought SoN was cliff click's construction? did that idea exist before jvm hotspot?
03:58:18evanyeah
03:58:21brixenahh
03:58:23evanwell
03:58:36evansea-of-nodes is just a fancy word for a tree based IR
03:58:38evanin my opinion
03:58:42brixenI see
03:59:02evancliff defined, as I recall, a bunch of optimization that work well when it's a tree
03:59:12evanbut having the IR being a tree is nothing new
03:59:13evanLLVM does it.
03:59:27brixengotcha
03:59:53evanLLVM even has
03:59:59brixenso, does it rewrite locals, etc?
04:00:00evanValue::replaceAllUsesWith
04:00:10brixenhow do you just splice in the callee node?
04:00:20evanthats what i'm trying to figure out still
04:00:25brixenok
04:01:12evanstrongtalk also simulates the stack inside the compiler
04:01:18evanthe operand stack
04:01:21brixeninteresting
04:01:32brixenlike the stack depth calculator?
04:01:42evanwith the elements of the stack being Expr objects
04:01:52evanand Expr objects can be hinted with their type
04:02:16evanyeah, like the stack depth calculator
04:02:28evani tried to this in LLVM, but found out LLVM will do it for me
04:02:42evanrather, i tried to do this in the LLVM generation code
04:03:44brixenman, I spent all afternoon trying to get my dir on elle to build with llvm
04:03:50brixenI still have no idea what was up
04:03:54evan:/
04:03:55evanleave it
04:03:57evani'll poke at it.
04:04:07brixenit was getting tons of link errors
04:04:18evanoh oh
04:04:18brixenI finally did another distclean and it worked
04:04:22evani think dgtized was getting that
04:04:25evanweird.
04:04:28brixenyeah
04:04:31evanis it working now?
04:05:04brixenoh yeah, I did svn update -r to the rev I'm using locally
04:05:18evanah ok
04:05:28brixen*but* I just co'd llvm trunk to my ubuntu 32bit vbox
04:05:31brixenand it worked fine
04:05:32tarcieridid you guys end up capping your stack depth to match MRI?
04:05:33brixenno idea
04:05:40evanweird
04:05:43evantarcieri: no
04:05:43brixentarcieri: different stack
04:05:48evantarcieri: well, sort of.
04:05:56evanwe check the depth
04:05:57tarcieriok on: different stack
04:06:01tarcieriheh
04:06:01evanbecause we're on the C stack
04:06:14evanbut the check is adjusted for how big the stack for the current thread is
04:06:21evanso if you use ulimit to change your stack
04:06:23evanit will honor that
04:06:28evani think MRI will do
04:09:00evanthe strongtalk code is funny to read
04:09:12evanthey had a habit of putting their initials and then the date after larger comments
04:09:21evanlike this one is from
04:09:27evangri 10/2/96
04:09:53evanand they reference Dave (Dave Unger) and Urs (Urs Holzle)
04:10:15brixenheh, neat
04:10:17brixenhistory
04:10:56brixenso, you haven't found the "ok, son, have a seat, here's the secret to speed..." long comment yet?
04:11:14evannot yet.
04:11:15evan:D
04:11:23evanwhats another word for guard..
04:11:33brixen"ok son, now we open a can of wupass..."
04:12:08brixenshield, police, cover
04:12:18evan:/
04:12:28brixenlookout, jailer, screw
04:12:28evani'm trying to figure out what to search for to find the inline guards
04:12:32brixenheh
04:12:35brixenum..
04:12:41evanit seems like they just go "sweet inline now"
04:12:43evanwith no guard
04:12:45evanbut that can't be right.
04:12:51brixenhm
04:13:11tarcieriheh, sorry, we're doing some live code refactoring
04:13:26brixentarcieri: don't touch the red wire :)
04:13:34evanZAP
04:13:35brixener line
04:13:40brixendamn, I messed it up
04:13:44evannah
04:13:45evango with it
04:13:47evanyou meant that!
04:13:53evanhaha good one brixen!
04:13:55brixenI meant *line*
04:13:57evan(i'm trying to help)
04:14:00brixenI know
04:19:33evanor stuff like this
04:19:34evan //fatal("Urs thinks this shouldn't happen");
04:19:38evanawesome
04:19:48evanit's like a fucking time machine!
04:20:02evanhah
04:20:03evanthe next line
04:20:09evan ShouldNotReachHere(); // added instead of the fatal (gri 11/27/01)
04:20:15brixenheh
04:20:41brixen"warning: you should not be in this room, you should leave immediately"
04:20:57brixenUrs said so
04:21:34evanhehe
04:21:42evanbut that comment out, and then
04:22:03evan GoDirectlyToPrincipal(); // send them out of the room nicely (emp, the future)
04:22:23brixenheh, yeah
04:23:20evani think i might have found the guards
04:29:18evanok, ps3 time.
04:30:38tarcieriheh
04:30:47tarcierido you have Worms for PS3, evan?
04:30:55tarcieriit's like the coolest turn based strategy game ever
04:31:14tarcierilike, if Go is Lisp, and Chess is Java, Worms is Ruby :)
04:32:15brixenheh, interesting comparisons
08:15:25evani feel like there are some good reasons for parrot
08:15:44evanbut i really hope that allison had a bunch more than the ones in: http://www.linux-mag.com/id/7373
08:20:47tarcieriParrot just seems too abstract, and after opening by whining about the "basics like garbage collection", doesn't Parrot just use mark sweep?
08:20:53brixenyeah, I'm glad you can implement lolcode in a 5 min lightning talk
08:21:02brixennow that is pushing the state of the art forward
08:21:25brixenthe abstraction drug is soo tempting
08:21:41brixenthat's why there is only one good implementation of a GC anywhere
08:21:56brixenit's so easy to get good perf out of a complete abstraction
08:22:07tarcierithe description language for Parrot's PEG was fugly as fuck
08:22:15brixenoh, where do you start with the logic errors
08:22:20evanshe talks about how register VMs are better than stack VMs because stack VMs always use a global data stack and you can stack smash them
08:22:29evanwhich is.. pretty much entirely false.
08:22:33tarcieridurr k
08:23:22evanstack based VMs are pretty much identical to register VMs
08:23:23tarcieriIsn't the main argument for register-based VMs that more research has gone into them because CPUs are register-based so most compilers target a register machine?
08:23:37evanexcept that stack VMs don't require you to enumerate where you want data
08:24:07evanthe register allocator for a register VM would look a lot like a stack VM
08:24:24evankeeping track of who's using what register as they're used, so they can be reused
08:24:37evantarcieri: thats the typical reason i've heard
08:24:40evanbut it's bollox too
08:24:51evansince parrot gives you an infinite register stream
08:24:56evanmap that directly to hardware!
08:25:01brixenheh
08:25:08evanyou have the same challenges as a stack VM for that
08:25:09tarcieriheh
08:25:12evani think it's a wash
08:25:15maharghow is an infinite register stream actually any different from a stack?
08:25:18brixenabstractions are grand, until they aren't
08:25:19tarcieridoesn't LLVM give you infinite registers?
08:25:27evanesp. when you consider that a register VM requires about 3x as much time to recode operands as a stack VM
08:25:44evantarcieri: it gives you infinite named variables.
08:25:52tarcieriheh
08:25:57evanregister is a platform abstraction
08:26:18evanfor a chunk of static ram
08:26:53evani'd find it quite funny if parrot did restrict themselves to an x86-32 number of registers
08:27:06evanthey'd be running their register spill opcodes constantly!
08:27:28evanbecause x86 doesn't just have registers
08:27:37evanit's got stack that it can reason about and use actively
08:27:42evananywho.
08:27:58tarcieriit's got... 4 general purpose registers?
08:28:43evanesi, edi, ebx, ecx, eax, ebp, esp
08:28:56evanmy 7 little friends
08:29:15evanesp is out
08:29:27evanebp can be used if you organize your function that way, but is normally out
08:29:46evaneax is always the return value, so you can use it as scratch between calls
08:30:02evanebx is usually used for PIC, so many times it's not available
08:30:19evanthats why I added -mdynamic-no-pic to our build
08:30:25evanit frees up ebx to be used by gcc
08:31:50tarcierioof
09:41:37evanWOOOOOOOOOOO
09:41:37evanFinished in 49.883222 seconds
09:41:43evansub 50 baby!
09:41:58evanjust barely squeaked in!
09:49:17boyscoutPrune the global method cache much more intellegently - 64943ac - Evan Phoenix
09:49:43brixenheh
09:49:48brixenI had a sub 50 last night
09:49:57evanyou have a faster machine
09:50:00brixenahh
09:50:11brixenwell, sub 40 march is on then :)
09:50:23evanthats sub 50, with the fact that i untagged more specs
09:50:28brixenbtw, I don't think running the benches in the past is realistic
09:50:44evanbecause of the fewer specs?
09:50:46brixenI tried to run some, got segfaults, different #s of specs, etc
09:50:56evanok then
09:51:00brixenI think we should just go from now on
09:51:01evanforward only then
09:51:03brixenok
09:51:05evani'm ok with that.
09:51:18evani got everything compiled on the mac mini
09:51:20brixenI have to fix something in the data, but it should be running nightly now
09:51:25brixencool
09:51:26evani'll get it burning some benchs tomorrow
09:51:41brixenyou'll have to add some code to that script to fetch and build
09:51:58brixenI have my aliases: git com; git purr; get co bench; get rem
09:52:10brixenbut I figured you didn't have those
09:52:47brixenthe benchmark/utils/cron_daily script that is
09:52:52evanok
09:52:56evani'll take a look in the morning
09:52:58evanyou should get some sleep
09:53:01brixenyeah
09:53:04evanyou've got the presentation tomorrow
09:53:11brixenfinding good images is a pain
09:53:17brixenI've got some funny ones
09:53:20evanheh
09:53:23scoopraww, 'purr' sounds cute
09:53:27brixenhttp://www.flickr.com/photos/pedrosimoes7/1319951752
09:53:37brixenscoopr: heh, it's git pull --rebase
09:53:56brixenthat portugese police car is my image for talking about mspec :)
09:54:17brixenI'm sure we'll see a comedy police chase with those someday
09:54:23brixenprobably already on film actually
09:54:32evanhehe
09:54:33evansounds fun
09:54:35brixenit will capture a ferari or something
09:54:41evanwell, bed for me
09:54:49evanthey're not filming them tomorrow, are they?
09:54:51brixennite!
09:54:59brixenno, just sound
09:55:08evanah well
09:55:09brixena couple rooms are videotaped
09:55:12evangood luck!
09:55:15brixenthanks!
09:55:23boyscoutCI: 64943ac success. 2709 files, 10767 examples, 33781 expectations, 0 failures, 0 errors
09:55:24evansleeps
14:31:28nemerle_mDoes anyone else have problems with thread related specs ( resource exhaustion ) ?
16:06:31nemerle_mok, i think this thread resources thing is related to threads beeing created with 4mb stack each, which is not freed without join/detach ?
16:06:48nemerle_mhere's the process map of rbx: http://pastie.org/516455
16:07:14nemerle_m300+ instances of thread stack
16:11:38nemerle_meither each native thread should be pthread_detach'ed on creation, or pthread_join'ed when finished
16:19:09sbryant_worknemerle_m: interesting.
16:22:24sbryant_worknemerle_m: what are the circumstances for you creating 300 threads?
16:25:05sbryant_worknemerle_m: can you show me an example application?
16:26:50nemerle_msbryant_work: this 300+ thread stackks in rbx memory map is from running ./bin/rbx ./mspec/bin/mspec-ci spec/frozen/core/thread
16:26:52nemerle_m:P
16:27:35sbryant_workOOps
16:27:48sbryant_work:P totally missed the first line
16:28:04sbryant_workThis might not be anything.
16:28:54nemerle_mwell it asserts on thread creation because my mem is exhausted :P
16:29:46nemerle_mbut i think i fixed it
16:30:12sbryant_workwhat spec did it assert on?
16:30:29sbryant_workand what did you do to fix it?
16:30:31nemerle_mexit
16:30:52nemerle_mdetached_native_thread was not calling native_thread_->detach();
16:31:03nemerle_m*detach_native_thread
17:05:14nemerle_mI've put the thread patch here: http://www.nemerle.eu/thread_leak_fix.diff
17:13:45brixennemerle_m: awesome
17:13:54brixennemerle_m: will you be around for a bit?
17:14:08brixenI'm leaving to give a talk but you should ping evan for a commit bit
18:03:43nemerlebrixen: yes, i'll be around
18:20:28dgtizedanyone else see this: http://www.igvita.com/2009/06/13/profiling-ruby-with-googles-perftools/
18:20:47evanyeah, it's interesting
18:20:55evani looked through googles profiler
18:39:46dgtizedhuh, ruby-prof with a patched mri tracks GC calls
18:40:14dgtizedI wonder how much trouble it would be to fix the ruby-prof extension to hook into rbx?
22:13:14evanla la
22:13:17evanrewriting inline caches
22:13:18evanla la
22:13:23brixenreeeallly?
22:13:27brixenhow so?
22:13:41evan3 things
22:14:06evan1) to fix the memory leak problem (selectors holding on to SendSites forever, which keeps everything the SS references alive)
22:14:30evanthats a biggy, it effects eval bigtime
22:15:11brixenahh yeah
22:15:20brixenhadn't thought of eval
22:15:21evan2) seeing if the trampoline cache validator setup works better (i'm thinking it will)
22:16:18evan3) allow for caches on the meta_* instructions
22:16:43evansomething thats falling out of this so far is I might get rid of the SendSite class
22:17:01evanthe semantics of the caches are sensitive enough that they need to be managed specially
22:17:08brixenI see
22:17:33evanand I can make them faster by keeping the caches at certain addresses in memory
22:17:48brixenwe'd just need a primitive to get data from the sendsites for Ruby, a la profiler
22:18:00brixenyeah, that makes sense
22:18:03evanso atm, what i'm doing is having VMMethod hold an C array of InlineCache objects
22:18:16evanso that they can be directly referenced
22:18:23brixencool
22:18:38evanyeah, then we can write some prims to mine that info
22:18:49brixenthat actually makes a lot of sense (native objects)
22:18:56brixenwe don't use them in any ruby machinery
22:18:58evanone cool thing i've realized is that i can now make the caches smarter
22:19:02evanyeah
22:19:17evanbecause, when building the cache, i can look at the instruction stream to know how the cache is used
22:19:26evanlike, a cache is told at build time it's for a private send
22:19:42brixenahh indeed
22:19:43evanand then it's lookup and such only use the method lookup and validation for private sends
22:19:50brixengotcha
22:19:59evani've got 2 method lookup methods now
22:20:06evanone for public, one for private
22:20:16evanprivate just ditches some of the logic
22:20:33brixenevery little bit helps
22:20:38brixenthis is some cool stuff
22:20:42evanyeah
22:20:49evanit should be cool
22:20:49brixenspecialization ftw
22:20:54evanexactyl
22:20:57brixenI wonder how parrot handles that :D
22:21:02evaninterpreter ICs are interesting
22:21:11evanbecause most ICs have to do with leveraging the call instruction
22:21:19evanwhich you can't do in an interpreter
22:21:33evani look at how strongtalk does it
22:21:51evanthey use bytes IN the bytecode stream for the cache
22:22:04brixenah interesting
22:22:07brixenhow do they mark that?
22:22:13evani dunno
22:22:19evani think they require their mature objects
22:22:22evanso maybe they leverage that
22:22:28brixenhmm
22:22:29evans/their/they're/
22:22:48evan1.9 has a get_inline_cache instruction
22:22:52evanso it's kind of similar
22:23:03evanwith ours
22:23:21evani'm making the 1st operand to each send instruction actually be a pointer to a Cache object
22:23:44evanwhich is setup when the CompiledMethod is internalized
22:24:02brixenis Cache managed?
22:24:12evanno
22:24:23evanit's a pointer into the InlineCache array
22:24:25brixenhow is it different than InlineCache?
22:24:27brixenahh ok
22:24:30evansame
22:24:37evanCache == InlineCache
22:24:39evani'm just lazy.
22:24:42brixenok
22:24:56brixenI thought Cache was like CompiledMethod
22:25:08evanah!
22:25:12evani considered that
22:25:17evanmight do that eventually
22:25:29evanbasically, allocate a proxy for the InlineCache C++ object
22:25:31evanto access it's data
22:25:36brixenok
22:33:56evanbrixen: how did the talk go?
22:37:09brixengood
22:37:19brixensmall conf, ~10 attendees :)
22:37:31brixenonly 2 were not getting paid to write ruby code
22:37:58brixenI just realized, github guys are supposed to be doing a panel in about an hour
22:38:26evani think they're in pdx
22:38:35evanatduskgreg tweeted about seeing them
22:38:37brixen~10 attendees to my talk that is, the conf is small but probably couple hundred people
22:38:46evanoh, defunkt just said he's at a lift presentation
22:38:51brixencool
22:39:03brixenit was a toss up between machine learning and lift
22:39:06evanwell, 10 people, thats intimitate
22:39:11brixenI picked machine learning
22:39:16evanaah
22:39:18brixenyeah, it was good
22:39:29brixenI knew 1/2 the audience
22:39:32brixenheh
22:39:38evanhehe
22:39:42evanis jim there?
22:40:01brixennah, said he couldn't make it
22:40:08brixenyou mean jim deville right?
22:40:15evanyep
22:40:17evanthats too bad
22:41:19brixenI think I'll go check out lift, bbiab
22:41:23evank
22:41:57nemerlehere's a little patch to fix packing negative numbers ('n' 'N' pack specifiers ) : www.nemerle.eu/pack_negative_fix.diff
22:42:07evannemerle: you've got commit rights
22:42:09evanpush it!
22:42:42nemerleboth patches ?
22:42:54evanwhich is the other?
22:43:00nemerlei'm not 100% sure about the fix to the thread issue
22:43:14evancould ya show me the thread one?
22:43:26nemerlewww.nemerle/eu/thread_leak_fix.diff
22:43:33nemerle* www.nemerle.eu/thread_leak_fix.diff
22:44:21evanhm
22:44:23evanwhats the bug it fixes?
22:45:31nemerleok, i recounted my findings earlier today, basically threads exited, but weren't detached/joined -> stacks were not beeing freed
22:45:48nemerle*thread -> in native sense
22:46:14evanhm.
22:46:22evanif the thread specs run with your fix
22:46:23evanit's fine.
22:46:40nemerleplease take a look at this: http://pastie.org/516455
22:46:57evanah
22:46:59evanlots of stacks!
22:47:04nemerleindeed :)
22:47:58evanand with your fix, Thread#join still works properly, yes?
22:48:55nemerleI would assume it does, at least no mspec-ci spec failures would indicate so ?
22:49:46evanyeah, it would
22:49:49evanso both are fine
22:49:58evango ahead and commit them
22:50:58nemerleok, is there some tutorial for commiting to master on github ? :)
22:53:31brixennemerle: indeed, doc/using_git.txt :)
22:53:53brixenle'me browse it to see if anything is outdated..
22:54:31evanbrixen: you getting Liftified?
22:54:50brixenheh, I'm getting githubified
22:54:58brixeninducted into the secret order
22:55:51evanheh
22:56:31nemerlebrixen: since receiving commit rights i should re-clone from git@github.com:evanphx/rubinius.git, is that about right ?
22:56:51brixenjust run rake git:committer
22:57:14brixenit'll switch the config url for you
22:57:49brixenthen if you're on master, git commit; git pull --rebase; rake (to run the specs); git push (if specs run clean)
22:59:59evanmarcandre: hello sir!
23:05:30brixenevan: can you see if there was an error running my crontab last night
23:05:48brixenI ran the script manually with no issues
23:08:03boyscoutFix for Array#pack for packing of negative values ('n' and 'N' specifiers) - 75ab637 - nemerle
23:08:03boyscoutFix for leaking of native thread stacks. - 2475441 - nemerle
23:08:15nemerlephew
23:09:17brixennemerle: woot!
23:09:31evanhehe
23:09:32brixennemerle: boyscout CI has yet to bless it though :)
23:09:34evansee, that was fine!
23:09:38evanbrixen: hm. ok.
23:09:45brixenjump in, the water is fine :)
23:12:03boyscoutCI: 2475441 success. 2709 files, 10767 examples, 33781 expectations, 0 failures, 0 errors
23:12:49nemerletommrrow i'll try to tackle that hang in all specs doing 'describes a running thread'
23:13:25brixennemerle: awesome, thanks for helping out!
23:14:02brixenevan: check this out http://gist.github.com/132239
23:14:16brixenI wonder why running the specs is so sporadic
23:14:51evanhuh.
23:14:52evanweird.
23:14:53brixenupdated the gist with the rdoc times
23:15:06brixensd for rdoc is 0.6
23:15:07evanWEIRD
23:15:10evanthey're pretty close
23:15:13brixenyeah
23:15:14dgtizedI've noticed that too -- I'm guessing non-determinism in thread specs and stuff like that?
23:15:15evanso it's just the specs...
23:15:19brixenyeah
23:15:29brixenand it's just running ci :core
23:15:31evan40s of nondeterminism?
23:15:32evanthats odd.
23:15:39brixenit is
23:15:58nemerleI would venture a guess that it might have to do with those hang-ups i've mentioned :P
23:16:07brixenheh, I was just thinking that
23:16:12brixensince it's on linux
23:16:12evanwhat hangups?
23:17:03nemerlerunning mspec-ci -f spec usually goes well, untill it checks '- describes a running thread' at which points it can hang upto 50s
23:17:56evanthat must be it.
23:18:35brixenevan: http://bench.rubini.us/ :)
23:18:52brixenof course, we'll have to see the trends over time
23:19:22evanhehe
23:19:23evanyeah
23:19:37brixenI'm going to make the top graphs zoom and put some info about the benches in there
23:19:45brixenwhat they are and why we run them
23:20:09evanrad.
23:20:23brixenin 2 weeks we'll have 14 data points
23:20:29brixenif I can get the damn cron to run
23:22:16brixenevan: actually, can you look at my cron? I added env var set lines, maybe I f'd something up
23:22:24evansounds that way.
23:23:32evanhm.
23:23:42evanyou know..
23:23:49evanthe example cron doesn't have the user field
23:23:54evanfucking cron.
23:24:02brixenbut we fixed that
23:24:02evano/~ i hate you... o/~
23:24:13evanno, we ADD a user
23:24:25evanadded.
23:24:28brixenyeah
23:24:45brixenbut man 5 crontab shows an example
23:25:02brixenthe only thing I'm missing is a blank line
23:25:08brixenI wonder if it needs that
23:25:34evancron is so fucking stupid
23:25:34evanARG
23:25:55brixenwe could install god :)
23:26:19evanhas this ever run?
23:27:04evanok
23:27:12evani found crons logs
23:27:12evanJun 18 03:30:01 elle /USR/SBIN/CRON[16693]: (brixen) CMD (brixen /home/brixen/bin/cron_daily)
23:28:02evanso it gave it the college try
23:28:04brixencool
23:28:09evanredirect the output to a log file
23:28:10evanso you can see
23:28:11brixenyeah, right time
23:28:13brixenok
23:28:16brixenthat't be great
23:28:24evanput > /home/brixen/cron.log 2>&1
23:28:25evanon the end
23:28:28brixenk