станд.:: пара <интервал, интервал> по сравнению со структурой с двумя интервалами
Если хит производительности конструктора по умолчанию не является проблемой, из любви к богу, пойдите с более читаемой версией.
:)
5 ответов
std :: pair конструктор инициализирует поля значениями по умолчанию (ноль в случае int ) и ваш struct Cell не работает (так как у вас есть только автоматически сгенерированный конструктор по умолчанию, который ничего не делает).
Инициализация требует записи в каждое поле, что требует большого количества обращений к памяти, что занимает относительно много времени. С struct Cell вместо этого ничего не делается, и ничего не делать немного быстрее.
Думаю, так создается std :: pair. При вызове конструктора пар 1001x1001 раз возникает больше накладных расходов, чем при простом выделении диапазона памяти.
это действительно хороший пример того, что нужно писать C ++ и осторожно использовать STL. есть какие-то мысли?
мой проект работает над инструментом тестирования производительности на уровне кода C и C ++, в котором мы сделаем множество примеров кода, чтобы выяснить, что такое «хороший» код, а что - «плохое». см. http://effodevel.googlecode.com , чтобы узнать больше о C9B.M. планирование. кто угодно, если у вас было много таких случаев,
Ответы до сих пор не объясняют всей величины проблемы.
Как указал Sharptooth, парное решение инициализирует значения до нуля. Как заметил Лемурик, парное решение - это не просто инициализация непрерывного блока памяти, вместо этого он вызывает конструктор пары для каждого элемента в таблице. Однако даже это не учитывает 1,5 секунды. Происходит что-то еще.
Вот моя логика:
Предположим, вы использовали древнюю машину, скажем, работающую на частоте 1,33 ГГц, тогда 1,5 секунды - это 2e9 тактовых циклов. У вас есть 2e6 пар, поэтому каким-то образом каждый конструктор пары занимает 1000 циклов. Не требуется 1000 циклов для вызова конструктора, который просто устанавливает два целых числа в ноль. Я не могу понять, как промахи в кеше заставили бы это длиться так долго Я бы поверил, если бы количество циклов было меньше 100.
Я подумал, что было бы интересно посмотреть, куда еще идут все эти циклы ЦП. Я использовал самый дрянный компилятор C ++, который смог найти, чтобы проверить, смогу ли я достичь требуемого уровня потерь. Этим компилятором был VC ++ v6. В режиме отладки он делает что-то, чего я не понимаю. У него есть большой цикл, который вызывает конструктор пар для каждого элемента в таблице - достаточно справедливо. Этот конструктор устанавливает два значения равными нулю - достаточно справедливо. Но непосредственно перед этим он устанавливает для всех байтов в 68-байтовой области значение 0xcc. Этот регион находится прямо перед началом большого стола. Затем он перезаписывает последний элемент этой области на 0x28F61200. Каждый вызов конструктора пары повторяет это. По-видимому, это своего рода бухгалтерский учет компилятора, поэтому он знает, какие области инициализируются при проверке ошибок указателя во время выполнения. Я хотел бы точно знать, для чего это.
В любом случае, это объяснило бы, на что уходит дополнительное время. Очевидно, другой компилятор может быть не таким уж плохим. И уж точно не будет оптимизированной сборки выпуска.
Все это очень хорошие предположения, но, как всем известно, предположения ненадежны.
Я бы сказал, просто случайным образом приостановите его в течение этих 1,5 секунд, но вам нужно будет действовать довольно быстро. Если вы увеличите каждое измерение примерно в 3 раза, вы можете сделать это более чем на 10+ секунд, так что будет легче сделать паузу.
Или вы можете получить его в отладчике, разбить его в конструкторе пар код, а затем один шаг, чтобы увидеть, что он делает.
В любом случае вы получите твердый ответ на вопрос, а не просто предположение.