[racket-dev] [plt] Push #24367: master branch updated

On 02/28/2012 01:56 PM, Robby Findler wrote:
> On Tue, Feb 28, 2012 at 2:43 PM, Ryan Culpepper<ryan at 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