Распределение памяти в Windows и Linux / производительность конструктора std :: list - PullRequest
5 голосов
/ 26 января 2012

Я портирую код C ++ с Linux на Windows. В ходе этого процесса я обнаружил, что следующая строка работает под Windows примерно в 10 раз медленнее (на том же оборудовании):

list<char*>* item = new list<char*>[160000]; 

В Windows это занимает ~ 10 мс, а в Linux - ~ 1 мс. Обратите внимание, что это среднее время. 100-кратный запуск этой строки в Windows занимает ~ 1 секунду.

Это происходит как на win32, так и на x64, обе версии компилируются в Release, а скорость измеряется с помощью QueryPerformanceCounter (Windows) и gettimeofday (Linux).

Компилятором Linux является gcc. Компилятор Windows - VS2010.

Есть идеи, почему это могло произойти?

Ответы [ 2 ]

10 голосов
/ 26 января 2012

Это может быть больше проблемой реализации библиотеки.В большинстве случаев я бы ожидал одного выделения, при этом конструктор по умолчанию для list ничего не выделяет.Итак, вы пытаетесь измерить стоимость конструктора по умолчанию list (который выполняется 160000).

Я говорю «пытаюсь измерить», потому что любые маленькие измерения измеряют джиттер тактового сигнала и разрешение больше, чем измерения времени выполнения кода.Вы должны поместить это в цикл, чтобы выполнять его достаточно часто, чтобы получить время выполнения в пару секунд.И когда вы делаете это, вы должны принять меры предосторожности, чтобы компилятор ничего не оптимизировал.

А в Linux вы хотите измерять, используя clock(), как минимум;время, которое вы получаете от gettimeofday, зависит от того, что еще происходит одновременно.(Однако не используйте clock() под Windows. Реализация Windows нарушена.)

2 голосов
/ 26 января 2012

Я думаю, что эта инструкция занимает меньше времени в обеих ОС (независимо от чего-либо). В этом случае может потребоваться так мало времени, чтобы вы могли фактически измерить разрешение ваших таймеров.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...