This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Some performance numbers with different Allocators


I ran these tests without any gcc optimization flags.
I will try with -O2 -funroll-loops and post results later today.
Do you want me to try with some other flags?

I do believe my test is quite simplistic, It would be interesting to see some results with more elaborate/complicated test cases.

I will also posts results using Redhat 9 (with NPTL).

Thanks
....Abhi



--On Wednesday, July 23, 2003 7:18 AM +0200 Stefan Olsson <stefan@snon.net> wrote:

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.






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]