SmartHeap for SMP
Does your app not scale because of heap contention?
The problem: Compiler runtime libraries allow only one thread at a time to be active in the heap. So on SMP systems, when multiple threads make concurrent heap requests, all but one will be blocked by the heap manager, nullifying the benefit of the extra CPUs. Worse yet, each time a thread is blocked, the OS invokes a context switch. The result: adding processors results in a vicious cycle of context switching that can prevent your app from scaling.
The solution: SmartHeap™ for SMP for Windows, Solaris, Linux, HP-UX, IBM-AIX, DEC OSF Tru64, and SGI-IRIX.
Evaluation Units Available. Call 425 827 7200 or email
to info@microquill.com
It might if you're not using SmartHeap for SMP!
Find out how firms like Fidelity, Microsoft, IBM, Lucent, Goldman Sachs, HP, Veritas, Merrill Lynch, MicroStrategy, NASDAQ, i2, BMC, Computer Associates, Xilinx, Deutsche Bank, NEON, Palm, Barclays, Autodesk, DoubleClick, Credit Suisse First Boston, E.piphany, Cognos, Allaire, Openwave, Ericsson, UPS, and others are achieving 100%-1000% performance improvement.
Compiler heap managers weren't designed for SMP systems.
Todays compiler runtime libraries were designed for single-processor environments.
They allow only one thread at a time to be active in a key resource that is constantly
used by all threads: the heap. On single CPU systems this is not a problem since only one
thread executes at any given time. But on multi-CPU systems where multiple threads make concurrent
heap requests, all but one will be blocked by the heap manager, effectively nullifying
the benefit of the extra CPUs.
Heap contention can actually make your app run slower on two CPUs
than on one.
To make matters worse, each time a thread is blocked, it loses its time slice and causes
an immediate (and very expensive) OS context switch that chews up otherwise useful cycles.
Adding processors increases the number of concurrent threads, thus increasing the
likelihood of heap blocking and the consequential context switches The result: extra CPUs
can actually cause a vicious cycle of OS context switching overhead to slow your
app's overall performance to below single processor levels.
This performance-numbing problem can occur on any app that has two or more threads calling the heap, regardless of heap size or time spent in heap operations. So nearly every app is vulnerable.
SmartHeap for SMP eliminates heap contention so your app scales
with additional processors.
Unlike compiler heap managers, SmartHeap for SMP allows multiple threads
to proceed with no blocking and true concurrency, eliminating heap contention
and associated OS overhead. The result: with SmartHeap for SMP your app
will scale when it is run on SMP boxes. More info!
You don't have to change your code to take advantage of
SmartHeap for SMP.
SmartHeap for SMP can improve your app's performance without
requiring any modifications to your code. You don't have to use special APIs or
reconfigure your app to call multiple pools. You simply relink with SmartHeap and your
code continues to call generic malloc or operator new.
SmartHeap for SMP will even speed up your app on uniprocessor
boxes.
SmartHeap for SMP will work just fine on uniprocessor boxes. In fact, as our benchmarks
show, it is substantially faster than the compiler supplied libraries in such
environments. So you can ship one .exe that works well regardless of the machines your
customers run on.
SmartHeap for SMP is available for NT, Solaris, HP-UX, AIX, IRIX, Linux and Digital UNIX
- SmartHeap for SMP Benchtest! Source code you can use to benchtest SmartHeap for SMP on your platform (most UNIX platforms and Win NT supported).
- Download the SmartHeap for SMP Getting Started Guide (pdf) which shows how easy it is to relink your app with SmartHeap for SMP.