История изменений
Исправление a--, (текущая версия) :
Тебе надо для начала две реализации. На интрузивных списках и на массивах. И для начала выполнить грубые тесты на случайной нагрузке. И если мы увидим разницу в пользу массивов в единицы процентов, то игра не стоит свечь.
Она может не стоить свеч прямо сейчас. У тебя там unordered_map, который тормозит (до какой-то степени). И если я ускорю QueueT прям до бесконечности, то тормоза unordered_map останутся.
Я-то предполагал, что дизайн будет без unordered_map. Т.е. роль unordered_map играет TLB и адреса объектов в памяти. Вот в таком дизайне ускорение QueueT имело бы явный смысл.
Еще раз: я преполагал свою оптимизацию для случая, когда у нас все объекты (элементы кэша 2Q) лежат прямо в памяти (или в арене, или в контейнере с прямой адресацией), и мы обращаемся к ним по их адресам, а не по ключу в unordered_map. Или для чего-то похожего в смысле высоких требований по скорости.
UPDATE: может это и стоит забенчить для начала. Насколько unordered_map торомзит intrusive_list (или наоборот).
Исправление a--, :
Тебе надо для начала две реализации. На интрузивных списках и на массивах. И для начала выполнить грубые тесты на случайной нагрузке. И если мы увидим разницу в пользу массивов в единицы процентов, то игра не стоит свечь.
Она может не стоить свеч прямо сейчас. У тебя там unordered_map, который тормозит (до какой-то степени). И если я ускорю QueueT прям до бесконечности, то тормоза unordered_map останутся.
Я-то предполагал, что дизайн будет без unordered_map. Т.е. роль unordered_map играет TLB и адреса объектов в памяти. Вот в таком дизайне ускорение QueueT имело бы явный смысл.
Еще раз: я преполагал свою оптимизацию для случая, когда у нас все объекты (элементы кэша 2Q) лежат прямо в памяти (или в арене, или в контейнере с прямой адресацией), и мы обращаемся к ним по их адресам, а не по ключу в unordered_map. Или для чего-то похожего в смысле высоких требований по скорости.
Исправление a--, :
Тебе надо для начала две реализации. На интрузивных списках и на массивах. И для начала выполнить грубые тесты на случайной нагрузке. И если мы увидим разницу в пользу массивов в единицы процентов, то игра не стоит свечь.
Она может не стоить свеч прямо сейчас. У тебя там unordered_map, который тормозит (до какой-то степени). И если я ускорю QueueT прям до бесконечности, то тормоза unordered_map останутся.
Я-то предполагал, что дизайн будет без unordered_map. Т.е. роль unordered_map играет TLB и адреса объектов в памяти. Вот в таком дизайне ускорение QueueT имело бы явный смысл.
Еще раз: я преполагал свою оптимизацию для случая, когда у нас все объекты (элементы кэша 2Q) лежат прямо в памяти (или в арене), и мы обращаемся к ним по их адресам, а не по ключу в unordered_map. Или для чего-то похожего в смысле высоких требований по скорости.
Исправление a--, :
Тебе надо для начала две реализации. На интрузивных списках и на массивах. И для начала выполнить грубые тесты на случайной нагрузке. И если мы увидим разницу в пользу массивов в единицы процентов, то игра не стоит свечь.
Она может не стоить свеч прямо сейчас. У тебя там unordered_map, который тормозит (до какой-то степени). И если я ускорю QueueT прям до бесконечности, то тормоза unordered_map останутся.
Я-то предполагал, что дизайн будет без unordered_map. Т.е. роль unordered_map играет TLB и адреса объектов в памяти. Вот в таком дизайне ускорение QueueT имело бы явный смысл.
Еще раз: я преполагал свою оптимизацию для случая, когда у нас все объекты (элементы кэша 2Q) лежат прямо в памяти (или в арене), и мы обращаемся к ним по их адресам, а не по ключу в unordered_map. Или для чего-то похожего в смысле высоких запросов по скорости.
Исправление a--, :
Тебе надо для начала две реализации. На интрузивных списках и на массивах. И для начала выполнить грубые тесты на случайной нагрузке. И если мы увидим разницу в пользу массивов в единицы процентов, то игра не стоит свечь.
Она может не стоить свеч прямо сейчас. У тебя там unordered_map, который тормозит (до какой-то степени). И если я ускорю QueueT прям до бесконечности, то тормоза unordered_map останутся.
Я-то предполагал, что дизайн будет без unordered_map. Т.е. роль unordered_map играет TLB и адреса объектов в памяти. Вот в таком дизайне ускорение QueueT имело бы явный смысл.
Еще раз: я преполагал свою оптимизацию для в основном случая, когда у нас все объекты (элементы кэша 2Q) лежат прямо в памяти (или в арене), и мы обращаемся к ним по их адресам, а не по ключу в unordered_map.
Исходная версия a--, :
Тебе надо для начала две реализации. На интрузивных списках и на массивах. И для начала выполнить грубые тесты на случайной нагрузке. И если мы увидим разницу в пользу массивов в единицы процентов, то игра не стоит свечь.
Она может не стоить свеч прямо сейчас. У тебя там unordered_map, который тормозит (до какой-то степени). И если я ускорю QueueT прям до бесконечности, то тормоза unordered_map останутся.
Я-то предполагал, что дизайн будет без unordered_map. Т.е. роль unordered_map играет TLB и адреса объектов в памяти. Вот в таком дизайне ускорение QueueT имело бы явный смысл.
Еще раз: я преполагал свою оптимизацию для случая, когда у нас все объекты (элементы кэша 2Q) лежат прямо в памяти (или в арене), и мы обращаемся к ним по их адресам, а не по ключу в unordered_map.