Работает в 3-4 раза быстрей стандатного operator new и malloc. Однопоточный, если надо — сами заворачивайте в CriticalSection (и даже в этом случае он работает гораздо быстрей)
Ускоряет STL, например со строками, раза в два, (если не STLport, который использует свой аллокатор)
STL VC71 + мой аллокатор — быстрее чем просто STLport

http://rsdn.ru/File/23256/winnie_alloc.rar

Здравствуйте, _Winnie, Вы писали:

_W>Работает в 3-4 раза быстрей стандатного operator new и malloc. Однопоточный, если надо — сами заворачивайте в CriticalSection (и даже в этом случае он работает гораздо быстрей)
_W>Ускоряет STL, например со строками, раза в два, (если не STLport, который использует свой аллокатор)
_W>STL VC71 + мой аллокатор — быстрее чем просто STLport

_W>http://rsdn.ru/File/23256/winnie_alloc.rar

Добавлена поддержка многопоточности. (опционально)
operator new стал более удобно настраиваемым. Много всяких заливок и гвардов в Debug mode(опционально)

http://rsdn.ru/File/23256/winnie_alloc03.rar
http://www.gamedev.ru/download/?id=1406

Здравствуйте, _Winnie, Вы писали:

_W>>STL VC71 + мой аллокатор — быстрее чем просто STLport

_W>Добавлена поддержка многопоточности. (опционально)
_W>operator new стал более удобно настраиваемым. Много всяких заливок и гвардов в Debug mode(опционально)

А если не секрет на сколько быстрее чем STLport?
Есть ли возможность брякнуться на заданном выделении памяти?
wbr

Здравствуйте, SleepyDrago, Вы писали:

Все качаем новую версию
http://www.rsdn.ru/File/23256/winnie_alloc04.rar
http://www.gamedev.ru/download/?id=1414


SD>А если не секрет на сколько быстрее чем STLport?
SD>Есть ли возможность брякнуться на заданном выделении памяти?
Да. Вообще,

/**returns pointer( "iterator" ) to the first block */
void *OpNewBegin();
/**returns pointer ( "iterator" ) to fake last block, which followed (see OpNewNextBlock)after real last block. */
void *OpNewEnd();
/**returns next block*/
void *OpNewNextBlock(void *p_user_memory);

/** converts ANY valid pointer to memory, allocated whith new/delete to 
beggining of the block. 
WARNING: GetBlockPointer can take much of time, because it searchs for 
block in entire list of allocated blocks. If p is NULL, returns NULL. If there is no 
such block, returns NULL. */
void *OpNewGetBlockPointer(void *p);

/** apply OpNewAssertIsValid to each block in list of blocks */
void OpNewValidateHeap();

/**Gets header of block */
DebugHeader *OpNewGetHeader(void *p_user_memory);

/**Gets block of header*/
void *OpNewGetHeadersBlock(DebugHeader *p_header);

/** asserts that p_user_memory is valid allocated block with uncorrupted guards. */
void OpNewAssertIsValid(void *p_user_memory);


/** Break in to debuger, if allocation block has number OpNewBreakAlloc. 
You can change this variable from watch window, for example. */
extern unsigned op_new_break_alloc; 

SD>wbr

Здравствуйте, SleepyDrago, Вы писали:

SD>А если не секрет на сколько быстрее чем STLport?


Ну, вообще-то у меня цель не опустить STLport и поднять Vc71STL, а просто показать что мой аллокатор запобеждает медленность Vc71STL
Естественно, это проявляется при сверхчастых аллокациях маленьких объектов, для тестирования чего очень пригоден медленный Vc71STL(с вызовом new на каждую ноду).
Но не все в этом мире — STL, там где нужен просто new/delete для маленьких объектов/массивчиков/строк, мой аллокатор топчет стандартный (топчет, а затем
прыгает).

Вопрос "во сколько раз" не совсем корректен. Зависит от теста, включен ли OP_NEW_MULTITHREADING.

Как видим, STLport пофиг на все — на аллокаторы, на многопоточность и тд. Он сам по себе. Поэтому для тестирования он непригоден
На некоторых других таких же тупых тестах на выделение памяти выигрывал Vc71STL даже в multithreading режиме.

void TestSTL2()
{
  
  clock_t time= clock();

  for (int sample = 0; sample < 10; ++sample)
  {
    std::list<std::list<char> > llc;

    for (int i=0; i<1000; ++i)
    {
      std::list<char> lc;
      for (int j=0; j<1000; ++j)
      {
        lc.push_back('w');
      }
      llc.push_back(lc);
    }
  }

  clock_t time2= clock() - time;
  std::cout <<"TestSTL2: " << time2 <<'\n';

};

8 тестов: STL, аллокатор, включен ли OP_NEW_MULTITHREADING в моей библиотеке. Если включен, то одновременно запускается для теста еще и два потока.

STLPort, my_allocator, multithreding
Run allocation test in one thread:
TestSTL2: 2375
TestSTL2: 2343
testing 2 concurrent threads...
TestSTL2: 4218
TestSTL2: 5172
TestSTL2: 4172
TestSTL2: 4265
2 concurrent threads stopped
Press any key to continue

//вот здесь связка Vc71STL + my_allocator получилась медленней
Vc71STL, my_allocator, no multithreding
Run allocation test in one thread:
TestSTL2: 2984
TestSTL2: 2984
testing 2 concurrent threads...
TestSTL2: TestSTL2: 5922
5594
TestSTL2: 5672
TestSTL2: 5922
2 concurrent threads stopped
Press any key to continue

STLPort, my_allocator, no multithreding
TestSTL2: 2468
TestSTL2: 2375
Press any key to continue

Vc71STL, my_allocator, no multithreding
TestSTL2: 1484
TestSTL2: 1469
Press any key to continue

//А это без моего аллокатора.

//ух, долго ждать пришлось. Пришлось пойти на кухню перекусить.
Vc71STL, standart new/delete, multithreding
Run allocation test in one thread:
TestSTL2: 13359
TestSTL2: 13891
testing 2 concurrent threads...
TestSTL2: 65063
TestSTL2: 71968
TestSTL2: 82656
TestSTL2: 78453
2 concurrent threads stopped
Press any key to continue

STLPort, standart new/delete, multithreding
Run allocation test in one thread:
TestSTL2: 2421
TestSTL2: 2391
testing 2 concurrent threads...
TestSTL2: 4063
TestSTL2: 4922
TestSTL2: 5187
TestSTL2: 4359
2 concurrent threads stopped

Vc71STL, standart new/delete, no multithreding
TestSTL2: 12781
TestSTL2: 13203

STLPort, standart new/delete, no multithreding
TestSTL2: 2375
TestSTL2: 2359

PS.
Не будите спящего дракона...

Здравствуйте, _Winnie,

Ну раз уж все стало так серьезно ( я про мультитред и дебуг)
тогда хочецца _все_и_сразу

Недавно я "открыл" для себя SSE и сразу напоролся на то что
new из мсвс71 _кладет_ на выравнивание структур данных _в_принципе_
лекарство от головы идет как обычно через ж
__alignof, _aligned_malloc, _aligned_free, __declspec(align(xxx))

в общем идея понятна — вопрос звучит так "как на счет выравнивания?"

wbr

Здравствуйте, _Winnie, Вы писали:

_W>Работает в 3-4 раза быстрей стандатного operator new и malloc. Однопоточный, если надо — сами заворачивайте в CriticalSection (и даже в этом случае он работает гораздо быстрей)
_W>Ускоряет STL, например со строками, раза в два, (если не STLport, который использует свой аллокатор)
_W>STL VC71 + мой аллокатор — быстрее чем просто STLport

_W>http://rsdn.ru/File/23256/winnie_alloc.rar


Интересно сделать тест с вашим аллокатором и yasli::vector

Автор: alnsn
Дата: 06.07.04

против вектора от VC7.1

P.S.
Я немного не понял насчет использование аллокатора, возможно ли в программе полностью сменитьа ллокатор от VC на ваш и чтобы все работало как надо ?

Здравствуйте, SleepyDrago, Вы писали:

SD>Здравствуйте, _Winnie,

SD>Недавно я "открыл" для себя SSE и сразу напоролся на то что
SD>в общем идея понятна — вопрос звучит так "как на счет выравнивания?"


/*
Выравнивание.
Буду иметь в виду. Сейчас этому мешают две вещи:
. заголовки у new/delete в отладочном режиме.
. Winnie::Alloc может быть настроен так, что бы вызывать malloc для очень больших блоков(по умолчанию отключено)
И еще одно:
. Тогда выделение памяти будет выровнено для всех типов, даже для которых выравнивание на 16 байт не нужно. (если говорить про SSE)
А оно того стоит, спрашивается?
Когда дело касается низкоуровневой оптимизации, то выровнять ручками выделенную память — не самая большая проблема. Там много часов уходит на колупание с профайлером.
*/


не тестировал, вроде от чтения невыровненных адресов не падает.

#include <xmmintrin.h>

template <size_t align> void *Align(void *p)
{
  struct AlignShouldBePowerOfTwo { char static_assert[  align&(align-1) ? -1 : 1  ]; };
  ptrdiff_t p_as_int = reinterpret_cast<ptrdiff_t>(p);
  return (char*)p + (-p_as_int & (align - 1));
}

template <class T>
struct AlignedArray
{

  char *p_real_memory;
  T *p_array;

  AlignedArray(size_t size)
  {
    p_real_memory = new char[(size+1)*sizeof(T)-1];
    p_array = (T*)Align<sizeof(T)>(p_real_memory);
  }

  ~AlignedArray()
  {
    delete[] p_real_memory;
  }

  
  AlignedArray(const AlignedArray&); //конструктор копирования писать лень.
  void operator=(const AlignedArray&); 
};



#include <iostream>

int main()
{
  AlignedArray<__m128> 
    my_array1(55), 
    my_array2(55);

  for (int i=0; i< 100; ++i)
  {
    _mm_add_ps(my_array1.p_array[i], my_array2.p_array[i]);
  }

}

SD>wbr

Здравствуйте, _nn_, Вы писали:

__>Здравствуйте, _Winnie, Вы писали:

_W>>Работает в 3-4 раза быстрей стандатного operator new и malloc. Однопоточный, если надо — сами заворачивайте в CriticalSection (и даже в этом случае он работает гораздо быстрей)
_W>>Ускоряет STL, например со строками, раза в два, (если не STLport, который использует свой аллокатор)
_W>>STL VC71 + мой аллокатор — быстрее чем просто STLport

_W>>http://rsdn.ru/File/23256/winnie_alloc.rar


__>Интересно сделать тест с вашим аллокатором и yasli::vector

Автор: alnsn
Дата: 06.07.04

против вектора от VC7.1

__>P.S.
__>Я немного не понял насчет использование аллокатора, возможно ли в программе полностью сменитьа ллокатор от VC на ваш и чтобы все работало как надо ?

Да, переопределены operator new/delete. malloc/free — нет, так как из переопределить невозможно(или я неправ?)

В библиотеке 2 layers:
1)
Реализация 2-x функций Winnie::Alloc(size_t) Winnie::Free(void*).
2)
В качестве "sample" к ней идет, как вокруг него можно накрутить new/delete — коротрые в Release режиме явлюются просто редиректами на Winnie::Alloc(size_t) Winnie::Free(void*), а в Debug mode там добавляется куча ASSERTов + всякие отладочные функции.

Соответственно, std::allocator<T> из vc71 вызывает мои new/delete, и таким образом резко ускоряется. Что там внутри yasli::vector, я не знаю

Здравствуйте, _Winnie, Вы писали:

_W>Да, переопределены operator new/delete. malloc/free — нет, так как из переопределить невозможно(или я неправ?)
Можно перегрузить, используя соответствующие функции работы с памяться из API операционной системы.

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, _Winnie, Вы писали:

_W>>Да, переопределены operator new/delete. malloc/free — нет, так как из переопределить невозможно(или я неправ?)
LVV>Можно перегрузить, используя соответствующие функции работы с памяться из API операционной системы.

Это как?
malloc -> _malloc_base -> _nh_malloc_base -> HeapAlloc
Можно как то сделать так, что бы HeapAlloc вызывал мою переопределенную функцию? Можно подробней? Или это можно сделать на более раннем этапе?

У меня, кстати, Alloc/Free настолько легковесны, что со включенным ключем Whole Program Optimaztion operator new/delete инлайнятся. А вот что HeapAlloc лишнего добавит, пока вызывает мою CALLBACK функцию...

Здравствуйте, _Winnie, Вы писали:

_W>Здравствуйте, SleepyDrago, Вы писали:

SD>>Здравствуйте, _Winnie,

SD>>Недавно я "открыл" для себя SSE и сразу напоролся на то что
SD>>в общем идея понятна — вопрос звучит так "как на счет выравнивания?"


_W>/*
_W>Выравнивание.
_W>Буду иметь в виду. Сейчас этому мешают две вещи:
_W>. заголовки у new/delete в отладочном режиме.
_W>. Winnie::Alloc может быть настроен так, что бы вызывать malloc для очень больших блоков(по умолчанию отключено)
_W>И еще одно:
_W>. Тогда выделение памяти будет выровнено для всех типов, даже для которых выравнивание на 16 байт не нужно. (если говорить про SSE)
_W>А оно того стоит, спрашивается?
_W>Когда дело касается низкоуровневой оптимизации, то выровнять ручками выделенную память — не самая большая проблема. Там много часов уходит на колупание с профайлером.
_W>*/

В общем вопрос не понят
попробуем еще раз
имеем следующий плохой код набранный ручками по мотивам — не обязан компилиться

__declspec(align(16))
struct mat4
{
    _m128 V[4];
};
mat4& operator*(const mat4&, const mat4&);
class GameObject
{
public:
    virtual ~GameObject(){}
    mat4& GetLocalTM(){return m_Local;}
protected:
    mat4 m_Local;
};

int main()
{
    GameObject* p = new GameObject();
    mat4 _modelview;

    mat4 m = _modelview * p->GetLocalTM(); // Здеся УПАДЕМ

    delete p;
    return 0;
}

Мелкий софт разводит руками — мол нефиг делать new
Лечится так переопределяем операторы в классе

void* GameObject::operator new(size_t n)
{
    return _aligned_malloc(n, __alignof(GameObject));
}
void GameObject::operator delete(void*p, size_t)
{
    _aligned_free(p);
}

А как у Вас решить проблеммку ?

wbr

Здравствуйте, _Winnie, Вы писали:

_W>Здравствуйте, LaptevVV, Вы писали:

LVV>>Здравствуйте, _Winnie, Вы писали:

_W>>>Да, переопределены operator new/delete. malloc/free — нет, так как из переопределить невозможно(или я неправ?)
LVV>>Можно перегрузить, используя соответствующие функции работы с памяться из API операционной системы.

_W>Это как?
_W>malloc -> _malloc_base -> _nh_malloc_base -> HeapAlloc
_W>Можно как то сделать так, что бы HeapAlloc вызывал мою переопределенную функцию? Можно подробней? Или это можно сделать на более раннем этапе?
А почему не сделать проще :

// stdafx.h

#define malloc(n) Winnie::Malloc(n)
#define free(n) Winnie::Free(n)

_W>У меня, кстати, Alloc/Free настолько легковесны, что со включенным ключем Whole Program Optimaztion operator new/delete инлайнятся. А вот что HeapAlloc лишнего добавит, пока вызывает мою CALLBACK функцию...

Здравствуйте, _nn_, Вы писали:

__>А почему не сделать проще :
__>

__>// stdafx.h

__>#define malloc(n) Winnie::Malloc(n)
__>#define free(n) Winnie::Free(n)
__>

Ну батенька вы даете.
и как по вашему поведут себя программы например с подключенным в виде длл StlPort ?
или у Вас весь проект _явно_ вызывает malloc? а CRT strdup ?

Здравствуйте, SleepyDrago, Вы писали:

SD>Здравствуйте, _nn_, Вы писали:

__>>А почему не сделать проще :
__>>

__>>// stdafx.h

__>>#define malloc(n) Winnie::Malloc(n)
__>>#define free(n) Winnie::Free(n)
__>>

SD>Ну батенька вы даете.
SD>и как по вашему поведут себя программы например с подключенным в виде длл StlPort ?
SD>или у Вас весь проект _явно_ вызывает malloc? а CRT strdup ?

Это имелось ввиду если программа небольшая и есть возможность переопределить malloc и free
А так конечно не пойдет...

А как насчёт чтобы добавить туда Realloc?
Тогда вообще цены не будет.

Здравствуйте, Chez, Вы писали:

C>А как насчёт чтобы добавить туда Realloc?
C>Тогда вообще цены не будет.

В принципе, он уже давно сделан в моей домашней версии. Завтра наверное библиотечку домучаю и выложу.

Здравствуйте, _Winnie, Вы писали:

_W>Работает в 3-4 раза быстрей стандатного operator new и malloc. Однопоточный, если надо — сами заворачивайте в CriticalSection (и даже в этом случае он работает гораздо быстрей)
_W>Ускоряет STL, например со строками, раза в два, (если не STLport, который использует свой аллокатор)
_W>STL VC71 + мой аллокатор — быстрее чем просто STLport

_W>http://rsdn.ru/File/23256/winnie_alloc.rar


http://rsdn.ru/File/23256/winnie_alloc.rar — The page cannot be found

Здравствуйте, BkmzBIN, Вы писали:

BBI>Здравствуйте, _Winnie, Вы писали:
BBI>http://rsdn.ru/File/23256/winnie_alloc.rar — The page cannot be found

Дело в том, что rsdn форум не позволяет редактировать свои сообщения, поэтому ссылка из поста 1 уже устарела.
Я скоро исправлю это. В данный момент последняя версия — http://files.rsdn.ru/23256/winnie_alloc04.rar
Скоро выложу свой домашний winnie_alloc05.rar
Наверное, я также буду выкладывать и под ссылкой из первого поста, что бы народ не смущать. Спасибо.

Здравствуйте, _Winnie, Вы писали:
_W>Ускоряет STL, например со строками, раза в два, (если не STLport, который использует свой аллокатор)
_W>STL VC71 + мой аллокатор — быстрее чем просто STLport

_W>http://rsdn.ru/File/23256/winnie_alloc.rar

Уфф, обновил. Текущая версия — 0.5. Качаем, тестируем, и не боимся, что new/delete — медленные операции, а dinkumware STL — тормоз.
http://rsdn.ru/File/23256/winnie_alloc05.rar