Эффективность индекса массива (в частности, временные переменные)

Question

Я прочитал довольно много материала об эффективности индексов массивов по сравнению с указателями, и о том, как это на самом деле не имеет значения, если вы не делаете много.Тем не менее, я делаю это много.

В рассматриваемом коде есть массив структур.(Два разных, для двух разных типов на самом деле, но что угодно).Поскольку мой фон в основном на языках более высокого уровня, я по умолчанию использовал стандартный формат particles[i].whatever.Однако я не уверен, что это хорошая идея.Для одиночного доступа я знаю, что это не имеет большого значения, но в настоящее время одна из двух моих основных функций вызывает particles[i].something 8 раз и boxes[boxnum].something 4 раза на частицу за каждую итерацию.

В настоящее время для выполнения 5000 частиц и 5000 итераций требуется примерно секунда.Это означает, что я имею дело с этими доступами выше [включая другую функцию] 200 миллионов раз в секунду.На этой частоте имеет значение каждый маленький кусочек (тем более, что я в конечном итоге буду запускать этот код вовремя на чужом кластере).

Так что мой вопрос, стоит ли делать что-то вроде использованияуказатель на структуру вместо доступа к массиву, если gcc сделает это магически для меня, или если это действительно не имеет значения.

Спасибо ~~ Zeb

РЕДАКТИРОВАТЬ: ОК, так что компилятормагия означает, что я не должен беспокоиться об этом.Спасибо.

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

Answer 1

Если вы последовательно выполняете итерацию по массиву, то может выиграть от использования указателя, который увеличивается на каждый цикл.Есть немного меньше арифметики, чем разыменование массива.Однако компиляторы довольно хороши в оптимизации вещей, поэтому вы можете не увидеть никакой выгоды.

Лучше всего запустить профилировщик, чтобы увидеть, где на самом деле заключается проблема.Вы можете быть удивлены тем, как далеко вы отгадываете узкое место.

Answer 2

Если вы хотите улучшить время выполнения вашего алгоритма, вам, вероятно, следует попытаться улучшить алгоритм как таковой , а не вашу реализацию (если вы явно не оптимизировали что-то).

Например: есть ли какие-нибудь шаги, которые вы могли бы пропустить? Есть ли какие-либо значения, которые вы можете сохранить для следующей итерации? Это заняло бы больше памяти, но могло бы сэкономить много времени!

Answer 3

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