Slashdot Mirror

← Back to Stories (view on slashdot.org)

Memory Management Technique Speeds Apps By 20%

Posted by kdawson on from the rememberance-of-data-past dept.

Dotnaught writes "A paper (PDF) to be presented later this month at the IEEE International Parallel and Distributed Processing Symposium in Atlanta describes a new approach to memory management that allows software applications to run up to 20% faster on multicore processors. Yan Solihin, associate professor of electrical and computer engineering at NCSU and co-author of the paper, says that using the technique is just a matter of linking to a library in a program that makes heavy use of memory allocation. The technique could be especially valuable for programs that are difficult to parallelize, such as word processors and Web browsers." Informationweek has a few more details from an interview with Solihin.

10 of 252 comments (clear)

  1. Beware the key term there: by Estanislao+Mart�nez · · Score: 5, Insightful

    Beware the key term there: "up to."

    --

    Are you adequate?

    1. Re:Beware the key term there: by Spatial · · Score: 4, Insightful

      I like to mentally replace that with the actual meaning: "between 0 and".

      It could allow software applications to run between 0 and 20% faster!

    2. Re:Beware the key term there: by Georules · · Score: 4, Insightful

      You might consider mentally replacing it with the sad reality that it might be between 0 and x faster AND it could also be infinitely slower.

    3. Re:Beware the key term there: by mswhippingboy · · Score: 4, Insightful

      What you are missing (as are most of the posters so far) is that there is considerable overhead involved in the actual management of the memory in terms of keeping track of what memory is free or allocated. This is outside the issue of maintaining locks. Moving this management overhead to a separate thread allows the otherwise single threaded app to take advantage of additional cores without any code changes. This does not appear all that novel however as modern garbage collectors do this today.

      --
      Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
  2. Nothing to see here.... by Ancient_Hacker · · Score: 5, Insightful

    Nothing to see here...

    Moving malloc() to a separate thread does not do a thing for the putative word processor.

    They might get some speedup if they take a lousy old malloc() and have one thread hold onto the locks.

    But of course the *right* way would be to write a new malloc() that can from the get-go run re-entrantly and not require a bevy of slow locks.

    1. Re:Nothing to see here.... by wealthychef · · Score: 3, Insightful

      But how much of your time is spent allocating memory? If you spend 5% of your time in malloc(), doubling its speed saves you 2.5% of your execution time.

      --
      Currently hooked on AMP
  3. 20%?! by temojen · · Score: 5, Insightful

    If most programs are spending 20% of their time on memory management, something is wrong.

  4. It's programmers that need parallelization by w0mprat · · Score: 5, Insightful

    Because we learnt to program for a single threaded core with it's single processing pipeline since way back, using high level languages that pre-date the multi-threaded era, and it involves re-thinking how things are done on a fundamental level if we're ever to make proper use of 32, 64, 128 cores. Oh and we all know how many programmers are 'get off my lawn' types, myself included.
     
    If I still coded much anymore it would drive me to drink.

    --
    After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
  5. Re:Wow, this is pretty clever by nxtw · · Score: 3, Insightful

    Well, the Intel AES instructions would benefit even more from parallelized AES CTR mode pre-computation than straight multiple cores, so that doesn't invalidate what I'm saying at all. :-)

    Are your storage and network devices that fast?

  6. Re:Does it matter anymore? by jasmusic · · Score: 3, Insightful

    Those developers can hold the rest of the software industry hostage for mad income. OS kernels don't write themselves.