On 02/28/2012 01:56 PM, Robby Findler wrote:
On Tue, Feb 28, 2012 at 2:43 PM, Ryan Culpepper<r...@cs.utah.edu> wrote:
On my machine before the change, "raco setup -D" took 8m13s real, 13m52s
user; after the change, it takes 4m0s real, 9m3s user.
I guess you have a faster machine than I do. (Are you running the 64
bit build or 32?)
64
FWIW, the times I'm reporting are after your commit.
Yes, I got that. I just wanted to add one before/after comparison. If
anyone sees radically different before/after results, I'd like to hear
about it.
It's useful to look at the progress output, particularly the place that a
particular collection is scheduled on. Before, progress would stop on the
"macro-debugger" collection for a long time. Now, you can still see
individual places blocking for long periods of time by looking for long runs
where a place number is absent.
On my machine, the "images" collection is scheduled on place 0, and it keeps
0 occupied for a long time---until around when setup hits "scribblings".
Then place 2 is occupied by "gui-debugger", then 1 is occupied by
"macro-debugger". CPUs utilization drops to around 75% when it hits
"gui-debugger" and then to around 50% at "macro-debugger". Both of those
collections depend on "images". It drops again, briefly, around "scribble",
which is also around when "images" finishes---I'm not sure what that means.
It also takes a while to climb back to around 100%, and I'm not sure why
that happens either (possibly related to "scribble"/"scribblings"?).
It seems like it should help to issue more collections while those few
block, but doing it naively (-j 5 or -j 6) doesn't work.
I've put together something that reads .dep files and does a
topological sort of the collections based on the dependencies (after
breaking links to get rid of the cycles) and uses that to schedule the
collections. I'm running some timing tests now.
I worry that a topologically-sorted list might actually result in worse
scheduling. It may place dependencies close together and they might get
scheduled on different places.
If B depends on A, then B should be *started* only after A is
*completed*. But the current interpretation of the worklist is just the
order in which to *start* collections.
Ryan
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
