Насчёт 1: в пред. комментарии я указал, что мой код может использовать кто угодно, в том числе в комм. приложениях с закрытым исходным кодом (хотя могу указать BSD или MIT лицензию, шутки ради). Насчёт 2:
может быть, «мощь» tbbmalloc и впрямь велика, но насколько часто она действительно нужна? Стоит ли она того, чтобы за неё платить в описанной ситуации (прим: использовал прив. код в комм. софте)? Приведенный код прекрасно себя чувствует при работе в 8 потоков, но это, как мне кажется, не предел. Плюс его легко портировать на другие платформы, поддерживающие работу с приватными кучами и аналогами TLS (хотя передо мной такая задача не стояла). И ещё: вы пропустили вопрос насчёт аппаратных акцентов (хотя про такое обычно и не говорят).
Дискуссия — громко сказано. Назначение scalable_allocator, пожалуй, сходное, хотя вдумчиво прочитать док пока нет возможности. Но есть одна большая разница — код, приведенном в данной статье, может использовать любой желающий совершенно задаром, можно ли то же самое сказать про Intel-овский? В нём нет никаких акцентов на аппаратную платформу, что насчёт Intel-овского (просто предположение)? Ещё такой вопрос: scalable_allocator тоже использует приватные кучи?
Хм, интересно. Каким образом достигается такой эффект? Мне приходят на ум приходят 2 варианта: патч msvcrt и патчи IAT в других библиотеках. Вы писали, что
мы переопределяем маллос и в всех студийных рантаймах, приложения (msvcrt*.dll), которые подняты при старте подмены аллокатора
, из чего я склоняюсь ко второму варианту. Что насчёт библиотек, загруженных после старта (LoadLibrary и аналоги)?
Объясняю: Вы переопределяете malloc только в своём модуле (например library.dll) и выделяете память с её помощью. Затем в другом модуле (например, test.exe, в котором она не переопределена) её освобождаете с помощью free (плохой стиль, но тем не менее это возможно). Что произойдёт?
Я не ставил целью глобальное переопределение new / malloc / delete /free, а в Вашем случае происходит именно это (Ваше «одностроковое решение» в общем случае потребует модификации других библиотек, что не всегда возможно). В случае Intel Threading Building Blocks мне бы идеально подошёл вариант phprus-а.
На самом деле статья описывает «идеальные» PE, точно соответствующие документации от MS. В «живой природе» обитает множество PE-шников, этой документации соответствующих лишь частично, но при этом работоспособных. Наиболее распространённый пример: OriginalFirstThunk == NULL (результат упаковки UPX-ом). Подобные случаи, пожалуй, наиболее интересны.
На Windows при выделении фрагмента размером около allocation granularity HeapAlloc почти напрямую переходит в VirtualAlloc (оверхед небольшой). Аllocation granularity обычно равен 64КБ.
Согласен, идея один поток <-> одна куча не нова (это справедливо не только для MS), вопрос лишь в том, когда это действительно необходимо. В моём случае это оказалось именно так. Насчёт пулов фрагментов памяти — Вам не кажется, что Вы изобретаете велосипед (куча, по сути, как раз и является таким пулом)? Насчёт поисков кусков подходящего размера — LFH куча и так справится с этим на ура. Неоспоримый факт, что усложнение кода такими «оптимизациями» приведёт к дополнительным багам, а вырастет ли быстродействие — вопрос. Насчёт несериализуемой кучи — полезное замечание. Ещё один нюанс — в сумме небольшой и хорошо читаемый исходник моего решения, который реально работает.
может быть, «мощь» tbbmalloc и впрямь велика, но насколько часто она действительно нужна? Стоит ли она того, чтобы за неё платить в описанной ситуации (прим: использовал прив. код в комм. софте)? Приведенный код прекрасно себя чувствует при работе в 8 потоков, но это, как мне кажется, не предел. Плюс его легко портировать на другие платформы, поддерживающие работу с приватными кучами и аналогами TLS (хотя передо мной такая задача не стояла). И ещё: вы пропустили вопрос насчёт аппаратных акцентов (хотя про такое обычно и не говорят).