Monday Feb 24, 2014

If Your Processor Stalls From a Read After Writer Operation ...

... rewrite your code. Better yet, write code that avoids this problem in the first place. The problem can occur when an application wants to load a value that it has just stored in memory. Read After Write (RAW) operations are common, so most chips are designed with hardware that makes that happen fast. But in some cases, you can write code that stumps the hardware. And so it stalls.

And you tumble to earth in horror, screaming for your life and clawing at the controls.

And you smack into the a pile of rocks. Or, to the horror of young mothers in minivans, the freeway during rush-hour traffic. Or worse, the middle of the ocean, so that if you somehow survive the impact, you drown. And nobody finds your body. And your loved ones can never move on.

Unless you're wearing a parachute. Like the one we just published from Darryl Gove.

Tech Article: Avoid Performance Loss (And a Fiery Death) from RAW Hazards

by Darryl Gove

Darryl explains exactly how a processor can stall from a bad RAW operation, and the common situations that cause this problem. Then he shows you how to identify, fix, and avoid writing that kind of code. Examples included. Help your loved ones move on. Read Darryl's article.

About the Author

Darryl Gove is a senior principal software engineer in the Oracle Solaris Studio team, working on optimizing applications and benchmarks for current and future processors. He is also the author of the books Multicore Application Programming, Solaris Application Programming, and The Developer's Edge.

Read Darryl Gove's blog on blogs.oracle.com/d.

Picture of radial engine taken by Rick Ramsey at Bay Area Aerospace Museum

- Rick

Follow me on:
Blog | Facebook | Twitter | YouTube | The Great Peruvian Novel

Thursday Mar 15, 2012

How to Unlock the Performance of Your Multithreaded Applications

Does the memory allocation of your multi-threaded application look like this?

That's probably because you're using a memory allocator designed for single-thread, single-CPU applications. Those memory allocators use malloc() and free() to reserve a portion of memory for your application, and then release it.

That type of memory allocator can continue to work in an application that ventures timidly into the possibilities of a multi-core, multithread-capable system. However, as the thread count begins to increase, different threads will start to request access to memory at the same time, and the traditional memory allocator won't be able to keep up.

Article: How Memory Allocation Affects Performance in Multithreaded Applications

Rick Weisner explains how memory allocation has evolved over the years, then shows you how to recognize a performance deficiency in your multithreaded application. Then he describes how to use three MT-aware memory allocators to take advantage of the performance promises of multi-core systems:

  • mtmemlock shipped with Oracle Solaris
  • libumem shipped with Oracle Solaris
  • the hoard allocator, publicly available

Stop the madness. Read Rick Weisner's article.

- Rick (Ramsey)

Website

Newsletter

Facebook

Twitter

About

Contributors:
Rick Ramsey
Kemer Thomson
and members of the OTN community

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Blogs We Like