Some performance numbers with different Allocators

[Stefan Olsson]

Hi Abhi!

Very interesting since I did a similar test with Hoard about a year ago 
with very different results - thus the development of mt_allocator...

Please let us know how you compiled the testprogram (optimization levels 
and other flags).

Brgds

/Stefan

Abhi wrote:

> Hi,
>     I ran some performace tests using different allocators.
>     The sample code is pretty simple,
>     - it creates 4 threads
>     - Each thread creates a list of string using an allocator
>     - Adds 1000000 strings to the list in a for loop
>     - Reads all these strings in a for loop
>     - Modifies all these strings in a for loop
>
> I ran this code 4 times (using 4 different allocators )
> malloc = An allocator that uses malloc
> malloc_hoard = An allocator that uses malloc with hoard (using
>            LD_PRELOAD, www.hoard.com)
> STL = Default STL allocator that comes with gcc 3.4
>         (pool allocator)
> STL MT = MT STL allocator that comes with gcc3.4
>
> Test Machine
> Dual CPU, Linux Redhat 7.3, GCC3.4 snapshot
>
> Here are the numbers
> #CPU malloc         malloc_hoard    STL                STL MT
>
> 1  31.280u 1.500s     19.670u 0.900s  26.510u 13.470s    23.010u 4.330s
> 2  40.850u 2.270s     38.630u 0.710s  103.820u 148.150s  51.600u 
> 23.660s   
>
> Seems like for this case hoard behaves the best, although a dual CPU
> machine still performs worse that a single CPU machine for a MT
> application. Does this seem surprising?
>
> Also I guess this code is MT-safe, especially the malloc 
> allocators...right? Just want to be sure!
>
> Heres the code
> ----------------------------------------------------------------------
> #include <list>
> #include <pthread.h>
> #include <errno.h>      // ETIMEDOUT
> #include <string>
> // For malloc
> // #include <ext/malloc_allocator.h>
> // #include <bits/allocator_traits.h>
> // For MT
> // #include <ext/mt_allocator.h>
> // #include <bits/allocator_traits.h>
>
>
> using namespace std;
>
> // For Malloc
> // typedef __allocator<char, __gnu_cxx::__malloc_alloc<0> >    MyAlloc;
> // typedef basic_string<char, char_traits<char>, MyAlloc>      MyString;
> // typedef std::list<MyString, __gnu_cxx::__malloc_alloc<1> >  List1;
>
> // For MT
> // typedef __allocator<char, __gnu_cxx::__mt_alloc<0> >    MyAlloc;
> // typedef basic_string<char, char_traits<char>, MyAlloc>      MyString;
> // typedef std::list<MyString, __gnu_cxx::__mt_alloc<1> >  List1;
>
>
> // For Default STL
> typedef string MyString;
> typedef std::list<MyString> List1;
>
>
>
> extern "C" void* Run(void *)
> {
>    List1 List;
>    for ( int i=0; i<1000000; ++i )
>    {
>     MyString s;
>     s.append("Hoiiiiiii");
>     List.push_back( s );
>    }
>
>    for (List1::iterator j = List.begin(); j != List.end(); ++j)
>    {
>     MyString s = *j;
>    }
>
>    for (List1::iterator j = List.begin(); j != List.end(); ++j)
>    {
>     MyString s("Hiiiiiii");
>     *j = s;
>    }
>
>
> }
>
>
> using namespace std;
>
> int main ()
> {
>    pthread_t  t1, t2, t3, t4;
>    pthread_create(&t1,  // Thread Id for new thread
>            NULL,          // Thread attributes
>            Run,        // Function
>            NULL);
>
>    pthread_create(&t2,  // Thread Id for new thread
>            NULL,          // Thread attributes
>            Run,        // Function
>            NULL);
>
>    pthread_create(&t3,  // Thread Id for new thread
>            NULL,          // Thread attributes
>            Run,        // Function
>            NULL);
>
>    pthread_create(&t4,  // Thread Id for new thread
>            NULL,          // Thread attributes
>            Run,        // Function
>            NULL);
>
>    int errNum = pthread_join(t1, NULL);
>    errNum = pthread_join(t2, NULL);
>    errNum = pthread_join(t3, NULL);
>    errNum = pthread_join(t4, NULL);
> }
>
> ----------------------------------------------------------------------
>
> Any Insights/Ideas
> Thanks
> ....Abhi
>
>
>


-- 
Winning isn't everything, but losing isn't anything.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4664 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030723/23719276/attachment.bin>