Entries in scalability (5)

Wednesday
Jan132010

Memory bloat makes me hate Firefox (regretfully)

This problem with memory bloat in Firefox (memory leaks) is well-known and Mozilla has been working on it for quite a while. I’ve been expecting some relief, but I’m about to give up on it and wait for real news of some improvement. I have pared down the plugins I use to a few essentials, so I doubt this can be blamed on extensions.

It is the only program I use that can render my machine so useless. It also seems fairly unpredictable, but perhaps it’s related to a combination of things I never think about in my frustration.

Here is an unwinding of a scenario where I was tempted to hit the power button. Instead, I patiently finished up, and documented the footprint the Firefox carcass left, and compared it to a fresh carcass.

Firefox locks out the GUI and the window management, because it is desperately writing memory to and from the disk… memory which has become hideously garbled, with tiny important pieces mixed in with useless stale stuff. Just look at the page fauts and VM size.

 

As you see in Fig. 2, the processor was very busy “cleaning up” the massively bloated program, so these can’t be “regular” memory leaks. Instead, they are “effectively” memory leaks — and don’t get cleaned up when you delete the tabs.  I’d be happy to help Mozilla find the culprit, but I’m unaware of an easy way to report this … since it’s not “technically” a bug. It could be as simple as me killing all the tabs, seeing the memory bloat still exists, and hitting a button “shut down Firefox and report memory bloat back to Mozilla”

 

I suppose one option is to forgo “virtual memory” (set page file size to a very low number) but that would affect every application and also prevent me from purposely overloading my machine — that is to say, purposely using more memory than I really have.

Chrome uses separate processes for each tab, which gives each tab a firewall against the others. One tab could have a massive leak, but could be killed independently and leave the others usable.

The 2nd and 3rd performance graphs just show that the system is indeed idle, especially after killing the zoom utility which I use to make the text more legible in the screen shots.

Monday
Oct052009

OMGWTFBBQ: if CONC trees replace CONS lists, then mapreduce can be parallel

Alternate title:  Mary had a little λ (kidding!)

Guy Steele: Organizing Functional Code for Parallel Execution

CONS (or “Lisp”) lists are inherently linear and sequential. One of CAR, CDR is constant-time, and the other is linear (on the length of the list). For a given list, there is only one CONS representation.

CONC primitives are null <>, singleton <42>, and “concatenation” a || b

CONC trees can represent CONS style lists, or balanced binary trees, or sparse trees, or other structures.



  • CAR CDR and CONS are compared to CONC primitives… and rather than use accessors left, right Guy prefers a SPLIT functional accessor which calls the second argument (a function) with the left and right parts as parameters.
  • Guy says this somewhere later on, and it’s easy to miss:

        “We are going to use CONC trees to optimize delay”
  • An important goal is a corollary to the equivalence 

    (cons (car xs (cdr xs)) = xs

  • It’s not this:

    (conc (left xs) (right xs)) = xs

  • but this functional gem:

    (split xs (λ (ys zs) (conc ys zs))) = xs

  • Think of the lambda λ as a continuation, and a way to keep the left and right together. In practice, split does not have to behave uniformly, but for the sake of this talk,  consider split to be purely functional with no side effects. You will notice we now have a corollary to the most low-level CONS equivalence, but one which is expressed functionally, recursively, by “binary decomposition and reassembly”

Having taken care of the basics, Guy breaks down the implementations of  MAP, REDUCE, MAPREDUCE, LENGTH, FILTER, QUICKSORT and MERGESORT for both CONS lists and the new CONC trees.

Heres the recursive mapreduce implementation with the Opportunity for Parallelism.

 

(define (mapreduce f g id xs)     ; Logarithmic in (length xs)??
  (cond ((null? xs) id)
            ((singleton? xs) (f (item xs)))
            (else (split xs (λ (ys zs)
                 (g (mapreduce f g id ys)       ; OMG Opportunity for
                     (mapreduce f g id zs))))))) ; WTF Parallelism
                                                             ; BBQ (mmmm, barbecue… <gurgle>)

 

…. Almost done! ….

 

RANT ON

If you are on Windows searching the Unicode characters looking for “LAMBDA”, you should STOP IMMEDIATELY. Search for “LAMDA” (no B). Microsoft doesn’t know how to spell “LAMBDA” much less describe its purpose in binding new variables dynamically, so the lambda (and its children) have a protected scope that hides variables in outer scopes, until the lambda completes and its scope goes away. Anyway HTML for the λ is ” &lambda; ” — that’s ampersand lambda semicolon  (no spaces)
RANT OFF

 

Sunday
Apr052009

Just Software Solutions series on concurrency in C++0x

Wednesday
Mar252009

Dr. Dobb's | Use Threads Correctly = Isolation + Asynchronous Messages | March 16, 2009

Where Threads Fit (and Thread Pools, Sometimes) In [1], I described the three pillars of concurrency. The first two pillars summarize the two main kinds of concurrency we need to be able to express: 1. Keep things separate, so that independent parts of the program can run asynchronously. 2. Use more cores to get the answer faster using data-parallel and similar techniques. (The third pillar is about controlling concurrency once it has been expressed, using tools like locks and atomics.) Table 1 summarizes these two pillars, and also summarizes how well each is served by four major tools at our disposal today for expressing concurrency: threads, thread pools, work stealing runtimes, and data-parallel facilities like OpenMP.

via Dr. Dobb’s | Use Threads Correctly = Isolation + Asynchronous Messages | March 16, 2009.

Friday
Mar132009

Suggested reading and topics for future discussion