Одним махом 100 миллионов убивахом. Или lock-free распределитель памяти

А запросто. Я просто скопипастил пример для new/delete и заменил их (надеюсь, что правильно)

// auto obj = new ObjectA();
auto obj = boost::fast_pool_allocator<ObjectA>::allocate();
...
// delete *jj; 
boost::fast_pool_allocator<ObjectA>::deallocate(*jj);

А вот результаты:
Allocation and deallocation 40000000 objects took 5.572+0.05 = 5.622sec
boost::pool-based allocation and deallocation 40000000 objects took 2.14+0.73 = 2.87sec

Насколько я понял, boost::fast_pool_allocator использует обычную синхронизацию через boost::mutex.
Да, компилировал для x86-32.

boost::object_pool делает в точности что нужно, но есть ньюансы… Он не многопоточен!

void func()
{
  boost::object_pool<X> p;
  for (int i = 0; i < 10000; ++i)
  {
    X * const t = p.malloc();
    ... // Do something with t; don't take the time to free() it.
  }
} // on function exit, p is destroyed, and all destructors for the X objects are called.

Loki::SmallObjAllocator не подходит идеологически — это аллокатор для классов типа std::list, std::map.

Мне требовалось чтобы объекты выделялись последовательно, без пропусков, каждому присваивался индекс, и этот индекс можно было использовать для быстрого обращения к самому объекту.

Конечно не против!

при таких объемах в .Net любая оплошность дает вагон и маленький состав тележек проблем:
— реализовали данные как класс = получили страшную нагрузку на GC и лаг при сборке (даже в серверном режиме, с blocking GC и такими объемами будет совсем грустно);
— сделали struct, но унаследовали от интерфейса = заимели головную боль с боксингом;
— использовали struct, но забыли ref при передаче данных в другую функцию и получили копирование на ровном месте;
— использовали string или любой массив в структуре и получили миллионы объектов (= субъектов для сборки);

Я уж не говорю о хранении пула таких данных, который иначе как в Linked Arrays не сделать (либо таки одним массивом в NNN элементов).

в Java структур нет вообще, потому сборка мусора для каждого объекта неизбежна, а значит надо руками подстраивать параметры сборщика (недавно была статья на эту тему).

В целом, нет ничего невозможного, не раз уже решались такие задачи для managed языков, но разумно было бы выбрать именно C++, чтобы держать руку на пульсе, а не надеяться на благосклонность сборщика мусора и 100% отсутствие ошибок.

Сначала было так:

auto index = curAtomicIndex_++;
uint32_t blocksCount = index >> 32;
uint32_t lastIndexInBlock = index & 0xffffffff;

Потом я начал искать способы оптимизации и вариант с union дал небольшой прирост. А вообще да, union — хак.

Про переполнение счётчика тоже не понял. Если после инкремента выясняется, что блок закончился, то нужно выделять новый внутри классической критической секции (с повторной проверкой внутри критической секции). А если есть вероятность, что переполнится 32-бит счётчик (что невероятно, так как нужно иметь порядка 2^32 потоков), то нужно ещё раз проверять счётчик на переполнение ДО инкремента.

Критических секций не хотелось по причинам:
1 хотелось обойтись без критических секций :-)
2 войти в критическую секцию первым мог как поток, первым наткнувшийся на нехватку места, так и остальные. Пришлось бы усложнять логику, на решение кто же выделяет следующий блок, хотя по чесному конечно ничего сложного в этом нет
3 переполнение может произойти потому что потоки не останавливаются, а непрерывано запрашивают через атомарную переменную новый индекс, и как только он станет валидным с радостью выделяют элемент

Во-первых, при ожидании имеет смысл не yield сразу вызывать, а раз от 5..30 цикл с проверкой прокрутить, так как современных процессорах велика вероятность, что другой поток исполняется на отдельном ядре. А Yield очень тяжёлая и длительная операция. Процентов 15% можно прироста скорости получить.

Делал и вообще без yield и с ним. Разницы в скоросте не заметил. Решил оставить вариант с yield, так как с ним ведем себя дружественнее по отношению к другим потокам, которые тоже хотят работать. Циклов ожидания в обоих случаях получалось в районе нескольких тысяч, с yield немного меньше.

Цикл while(true) {… } прогонятеся вхолостую в x64 примерно 6000 раз без yield и 4500 с yield.
В х86 примерно 2500-3000.