Странность производительности C ++ с OpenGL

Question

Я переписываю код рендеринга C на C ++.Старый код C в основном вычисляет все, что ему нужно, и отображает его в каждом кадре.Вместо этого новый код C ++ предварительно вычисляет то, что ему нужно, и сохраняет его в виде связанного списка.

Теперь фактические операции рендеринга - это переводы, изменение цвета и вызовы списков GL.

При выполненииОперации в связанном списке должны быть довольно простыми, может показаться, что результирующий вызов метода занимает больше времени, чем старая версия (которая вычисляет все каждый раз - я, конечно, убедился, что новая версия не пересчитывается).

Странная вещь?Он выполняет меньше операций OpenGL, чем старая версия.Но это становится страннее.Когда я добавил счетчики для каждого типа операций и старый добрый printf в конце метода, он стал быстрее - и gprof, и ручные измерения подтверждают это.

Я также потрудилсявзгляните на ассемблерный код, сгенерированный G ++ в обоих случаях (с трассировкой и без нее), и никаких существенных изменений не произошло (что было моим первоначальным подозрением) - единственное отличие состоит в том, что для счетчиков выделяется еще несколько слов стека, увеличивая указанные счетчикии подготовка к printf с последующим переходом к нему.

Кроме того, это относится и к -O2, и к -O3.Я использую gcc 4.4.5 и gprof 2.20.51 в Ubuntu Maverick.

Наверное, мой вопрос: что происходит?Что я делаю неправильно?Что-то скинуло и мои измерения и gprof?

Answer 1

Проводя время в printf, вы можете избежать срывов при следующем вызове OpenGL.

Answer 2

Без дополнительной информации трудно понять, что здесь происходит, но вот несколько советов:

• Вы уверены, что вызовы OpenGL одинаковы? Вы можете использовать какой-либо инструмент для сравнения звонков. Убедитесь, что изменения состояния не были внесены, возможно, в другом порядке.
• Вы пытались использовать профилировщик во время выполнения? Если у вас много объектов, простой факт погони за указателями во время циклического перемещения по списку может привести к отсутствию кэша.
• Определили ли вы конкретное узкое место, как на стороне процессора, так и на стороне графического процессора?

Вот мое собственное предположение о том, что может пойти не так. Вызовы, которые вы отправляете на ваш GPU, занимают некоторое время: предыдущий код, смешивая операции процессора и вызовы GPU, заставил CPU и GPU работать параллельно; напротив, новый код сначала заставляет процессор вычислять много вещей, пока графический процессор работает на холостом ходу, а затем передает графическому процессору всю работу, которую нужно выполнить, в то время как процессору ничего не остается.