SmartHeap for SMP

Does your app not scale because of heap contention?

SmartHeap

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