Насколько крупные структуры могут быть эффективно переданы по значению? - PullRequest
9 голосов
/ 13 мая 2009

Эмпирическое правило заключается в том, что можно передавать небольшие структуры по значению, а более крупные - указатели.

Мой вопрос: где именно находится эта точка отсечения? Насколько большими могут быть структуры, прежде чем вам будет лучше передать их указателем.

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

Однако я сейчас нахожусь на Intel, и я ожидаю, что все могло быть по-другому. Поскольку в ЦП традиционно не так много регистров, но, может быть, в 64-битных или плавающих регистрах это отличается?

Ответы [ 6 ]

4 голосов
/ 14 мая 2009

Хорошо, поэтому я попытался следовать советам и профилировать свой код с помощью указателей и значений. Я также посмотрел на код сборки. Похоже, что характеристики производительности на x86 сильно отличаются от PPC. На PPC двоичный интерфейс к C указывал, что аргументы будут помещаться в регистры (их было так много для выбора), однако, похоже, что даже на 64-битной x86 требуется, чтобы аргументы помещались в стек.

Так что это объясняет, почему на x86 передача по указателю всегда кажется быстрее. Однако я заметил, что компилятор очень хочет встроить. Так что не важно, каким образом я это сделал. Поэтому я думаю, что вывод заключается в том, чтобы использовать любой способ, который вам удобен.

Я думаю, что предпочтение передается по значению, потому что работать с копиями значений несколько безопаснее. Мой тестовый пример представлял собой структуру, состоящую из 4 двойных (поэтому я думаю, что на большинстве платформ она составляет 32 байта)

3 голосов
/ 13 мая 2009

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

Профиль It

Это единственный способ на 100% узнать, что есть проблема.

Прежде чем скептики прыгнут. Да, есть несколько очевидных случаев. Например, я бы никогда не передал структуру по значению, если бы в ней было 100 членов. Но это было бы не из-за проблем с производительностью, а из-за проблем с пространством в стеке.

2 голосов
/ 13 мая 2009

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

  • элементарные типы (int и т. Д.),
  • указатели,
  • пустые типы (типы тегов),
  • функционально-подобные типы (функторы) и
  • итераторы.

Я не уверен, может ли это быть применено непосредственно к C (кроме очевидных типов, которых нет у C), но, возможно, применимо аналогичное руководство.

1 голос
/ 13 мая 2009

Некоторые компиляторы могут определить оптимальный размер для вас. Если я правильно помню, компилятор TI28xx автоматически преобразует передачу по значению в передачу по ссылке, если структура превышает определенный размер.

0 голосов
/ 13 мая 2009

Обычно примитивные типы я передаю по значению, все остальное по ссылке. Это мое правило большого пальца.

0 голосов
/ 13 мая 2009

Не пренебрегайте ролью, которую играет выравнивание в вашем тестировании. Если вы передаете плавающие числа или двойные числа, и ваши структуры не выровнены по соответствующим границам, процессор может завершить выборку части вашего значения, сдвинуть его, а затем ИЛИ остальное перед сохранением. Я думаю, что большинство современных компиляторов будут использовать DTRT (выравнивая структуру, когда она объявлена), но если вы оптимизируете пространство, это, вероятно, станет проблемой.

Хммм, теперь, когда я думаю об этом, возьмем это с крошкой соли, поскольку я не делал никакого низкоуровневого кодирования для арки x86 со времен Pentium Pro ...

...