Медленнее ли индексация массива, чем работа с указателем?

@Lyosha12 · Регистрация: 02.04.2016

Студворк — интернет-сервис помощи студентам

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

Вопрос 1: Как проверить, что индексация действительно медленнее, чем работа с указателями? Ведь a[i] эквивалентно i[a] и эквивалентно *(a+i). Разве компилятор не способен проводить такие простые оптимизации по-умолчанию даже при уровне -O0?

Вопрос 2: Если предположение в вопросе 1 истинно, то как доказать ей этот факт и не гробить себе глаза этим обилием звёздочек?

Хочу ещё уточнить, что она не знала финта типа i[a] == *(i + a);

nimazzzy · 14.11.2016, 22:58

Не медленнее, это просто два разных способа записать одно и то же.

@Lyosha12 · 14.11.2016, 23:01 **[ТС]**

Сообщение от nimazzzy

Не медленнее, это просто два разных способа записать одно и то же.

Как мне это доказать преподавателю? Её главный аргумент: "В этих вшивых лаболаторках ты не увидишь разницы, но в большооооом проекте тебе это аукнется!"

nd2 · 14.11.2016, 23:01

Сообщение от Lyosha12

то как доказать ей этот факт

Может так?

@Lyosha12 · 14.11.2016, 23:02 **[ТС]**

Сообщение от nd2

Может так?

Отлично, благодарю. Какой это уровень оптимизации?

nimazzzy · 14.11.2016, 23:04

Сообщение от Lyosha12

Как мне это доказать преподавателю? Её главный аргумент: "В этих вшивых лаболаторках ты не увидишь разницы, но в большооооом проекте тебе это аукнется!"

Ткнуть носом в дизассемблерный листинг.
Большинство тестов производительности это не большииииииие проекты, а мелкие программы, с большой нагрузкой на вычисления, или память. И на них куда лучше будет заметна разница (или ее отсутствие), чем на большооооооом проекте.

@gray_fox · 14.11.2016, 23:05

Сообщение от Lyosha12

Как проверить, что индексация действительно медленнее, чем работа с указателями? Ведь a[i] эквивалентно i[a] и эквивалентно *(a+i)

a[i] - это по определению *(a + i), так что проверять, что из этого быстрее довольно бессмысленно.

nd2 · 14.11.2016, 23:05

Сообщение от Lyosha12

Какой это уровень оптимизации?

Отключена.

@TheCalligrapher · 14.11.2016, 23:13

Сообщение от Lyosha12

Ведь a[i] эквивалентно i[a] и эквивалентно *(a+i).

Вы уточните, о чем именно идет речь.

По определению, []-индексация "самого массива" ничем не отличается от []-индексации от указателя на нулевой элемент и от доступа через *(a+i). Тут даже от каких-то "уровней оптимизации" ничего не зависит. Тут нечего обсуждать.

Но обычно споры на тему доступа по индексу и доступа по указателю подразумевают рассмотрение разницы между такими двумя вариантами

C++
1
2
3
4
5
6
7
8
9
int a[N];
 
// Вариант 1
for (unsigned i = 0; i < N; ++i)
  a[i] = 0;
 
// Вариант 2
for (int *p = a, *p_end = a + N; p != p_end; ++p)
  *p = 0;

Но я не уверен, что вы ведете речь именно об этом.

@gray_fox · 14.11.2016, 23:19

Сообщение от Lyosha12

Как мне это доказать преподавателю?

Есть стандарт языка. Там это определено грубо говоря как "a1[a2] идентично *((a1) + (a2))" (или аналогичным образом). Тут и спорить не о чём.

@Lyosha12 · 14.11.2016, 23:36 **[ТС]**

Сообщение от TheCalligrapher

Но я не уверен, что вы ведете речь именно об этом.

Да, Вы правы. Можете поподробнее рассказать об этих случаях? В чём разница?

Предполагаю, процессору для смещения указателя на единицу нужно меньше тактов, чем на i позиций каждый цикл?

@nonedark2008 · 14.11.2016, 23:51

Сообщение от Lyosha12

Предполагаю, процессору для смещения указателя на единицу нужно меньше тактов, чем на i позиций каждый цикл?

Сомневаюсь, можно считать, что всякие примитивные операции выполняются за одинаковое время.
Тут стоит отметить, что прежде чем выполнять какие-либо операции над переменными, их нужно поместить в регистры.
Первый вариант требует хранить одновременно переменные i, a, N. А второй только p, p_end. Если регистры заняты, то пришлось бы что-нибудь выгружать в память, а это лишние такты.

П.С. Компилятор умный, он все покроет. И да, не стоит заниматься бессмысленными оптимизациями.

@Avazart · 14.11.2016, 23:57

Оптимизировать нужно только то что нужно, иначе код превратиться в нечитаемое, неподдерживаемое уг.

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

@gray_fox · 15.11.2016, 00:12

Сообщение от Lyosha12

Предполагаю, процессору для смещения указателя на единицу нужно меньше тактов, чем на i позиций каждый цикл?

Что и как эффективнее зависит от архитектуры набора инструкций процессора.
Например на x86-64 есть как загрузка в регистр из памяти по прямому адресу (аналогично разыменованию указателя - *p), так и загрузка по базовому адресу + смещение * размер элемента (аналогично индексации a[i]), и второе действительно может быть менее эффективным (за счёт длинны инструкций, там они с переменной длинной и размер может так же зависеть от размера аргументов). Но это может сыграть свою роль разве что в "очень простых" циклах (там, где время выполнения тела цикла не на порядок больше, чем время, занимаемое на все остальное (счетчики, загрузка из памяти)).

Добавлено через 13 минут
Кстати, сейчас компиляторы достаточно умны и, скорее всего, сделают все микрооптимизации кода лучше нас с вами, так что, в общем случае, не стоит заморачиваться о подобных деталях.

@Lyosha12 · 15.11.2016, 00:17 **[ТС]**

Сообщение от gray_fox

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

О, если бы я, никчёмный ученик второго курса, смог бы это передать преподавателю... Можно конкретную ссылку на авторитетный источник, который точно убедит преподавателя, что в 2016 году микрооптимизации бессмысленны? Книга, статья авторитетного автора - что угодно.

Вы-то откуда-то это узнали?

@Avazart · 15.11.2016, 00:32

Так вам же подсказали сослаться на асм код, в чем проблемы?

Что мешает сослаться на эту тему? Ну и стандарт языка...

Кстати а почему вы должны передавать, доказывать ? Пусть препод приведет ссылку на источник где говорится обратное...
При чем на актуальный источник, а не времен dos.

@gray_fox · 15.11.2016, 00:36

Lyosha12, ну, можно например сослаться на Дональда Кнута с его статьёй с известным выражением "преждевременная оптимизация - корень всего зла" ("premature optimization is the root of all evil").

Надо концентрироваться в первую очередь на эффективном решении задач и не тратить время на то, что приносит сомнительную пользу. Сначала надо решить задачу. Потом думать о том, что и где стоит оптимизировать.

Например, та же "оптимизация индексации" - стоит ли этим заниматься? Это первый вопрос, который надо себе задать, и обосновывать выводы. Если это "бутылочное горлышко" (bottleneck), то возможно, если нет, то вряд ли на такое стоит вообще обращать внимание.

@nonedark2008 · 15.11.2016, 00:37

Сообщение от Lyosha12

в 2016 году микрооптимизации бессмысленны?

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

@Lyosha12 · 15.11.2016, 00:51 **[ТС]**

Сообщение от Avazart

Так вам же подсказали сослаться на асм код, в чем проблемы?

Сошлюсь на следующей встрече.

Сообщение от Avazart

Что мешает сослаться на эту тему?

Тема для неё не авторитет. Даже хабр для неё не авторитет и исследования, которые там публикуют. Только какие-то научные журналы или книги от авторитетных источников.

Сообщение от Avazart

Кстати а почему вы должны передавать, доказывать ? Пусть препод приведет ссылку на источник где говорится обратное...

Тоже вариант, спасибо. Просто считал, что дополнительную информацию я должен искать сам - так говорят преподаватели, каждый. Но, когда я ищу информацию и предоставляю что нашёл конкретно преподу по C++, он считает, что всё, что я нашёл, есть бред. Не обоснованный.

@gray_fox · 15.11.2016, 01:00

Не по теме:

Сообщение от Lyosha12

Вы-то откуда-то это узнали?

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

Новые блоги и статьи Все статьи Все блоги /
Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .
Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .

Медленнее ли индексация массива, чем работа с указателем?

Решение

Решение

@Lyosha12 41 / 41 / 11 Регистрация: 02.04.2016 Сообщений: 313

	Медленнее ли индексация массива, чем работа с указателем? 14.11.2016, 22:51. Показов 2988. Ответов 24 Метки нет (Все метки) Преподаватель донимает меня, что я использую индексацию для работы с массивами, вместо того, чтобы использовать смещение и разъименовывание указателя на нулевой элемент. Вопрос 1: Как проверить, что индексация действительно медленнее, чем работа с указателями? Ведь a[i] эквивалентно i[a] и эквивалентно (a+i). Разве компилятор не способен проводить такие простые оптимизации по-умолчанию даже при уровне -O0? Вопрос 2: Если предположение в вопросе 1 истинно, то как доказать ей этот факт и не гробить себе глаза этим обилием звёздочек? Хочу ещё уточнить, что она не знала финта типа i[a] == (i + a); 0

nimazzzy Заблокирован
	14.11.2016, 22:58
	Не медленнее, это просто два разных способа записать одно и то же. 0

@Avazart 8484 / 6151 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	14.11.2016, 23:57
	Оптимизировать нужно только то что нужно, иначе код превратиться в нечитаемое, неподдерживаемое уг. Совсем другое дело что с указателями иногда работать удобнее. Например что бы иметь возможность задать диапазон элементов который нужно обрабатывать, как это в STL с итераторами. 0

@Avazart 8484 / 6151 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	15.11.2016, 00:32
	Так вам же подсказали сослаться на асм код, в чем проблемы? Что мешает сослаться на эту тему? Ну и стандарт языка... Кстати а почему вы должны передавать, доказывать ? Пусть препод приведет ссылку на источник где говорится обратное... При чем на актуальный источник, а не времен dos. 2

@gray_fox What a waste! 1610 / 1302 / 180 Регистрация: 21.04.2012 Сообщений: 2,733
	15.11.2016, 00:36
	Lyosha12, ну, можно например сослаться на Дональда Кнута с его статьёй с известным выражением "преждевременная оптимизация - корень всего зла" ("premature optimization is the root of all evil"). Надо концентрироваться в первую очередь на эффективном решении задач и не тратить время на то, что приносит сомнительную пользу. Сначала надо решить задачу. Потом думать о том, что и где стоит оптимизировать. Например, та же "оптимизация индексации" - стоит ли этим заниматься? Это первый вопрос, который надо себе задать, и обосновывать выводы. Если это "бутылочное горлышко" (bottleneck), то возможно, если нет, то вряд ли на такое стоит вообще обращать внимание. 0