std::vector доступ по индексу vs доступ по итератору

oxotnik · Регистрация: 21.08.2008

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    std::vector<int> tmp;
    int i = 0;
    tmp.resize(1000000);
    std::vector<int>::iterator it = tmp.begin();
    for (int m = 0; m < 10000; ++m)
    {
        for(; it != tmp.end(); ++it)
        {
            (*it) = i + 1;
            ++i;
        }
        it = tmp.begin();
        for(; it != tmp.end(); ++it)
            i = (*it);
    }

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    std::vector<int> tmp;
    int j = 0;
    tmp.resize(1000000);
    for (int m = 0; m < 10000; ++m)
    {
        size_t i = 0;
        for (; i < 1000000; ++i)
        {
            tmp[i] = j + 1;
            ++j;
        }
        i = 0;
        for (; i < 1000000; ++i)
            j = tmp[i];
    }

В дебаге доступ по индексу работает в 2-2.5 раза быстрее, нежели итераторы,
в релизе картина с точностью до наоборот - итераторы в 2 раза быстрее.
Как сие можно объяснить?

DiffEreD · 15.04.2013, 15:16

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

for(; it != tmp.end(); ++it)

не эффективный цикл, на каждой итерации идет обращение к tmp.end().

Добавлено через 2 минуты
Заменить на

C++
1
for(auto stop = tmp.end(); it != stop; ++it)

и попробовать снова.

@abit · 15.04.2013, 15:20

и во втором цикле можно взять const_iterator, в теории обещают преимущества

oxotnik · 15.04.2013, 15:34 **[ТС]**

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

не эффективный цикл, на каждой итерации идет обращение к tmp.end().

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

и во втором цикле можно взять const_iterator, в теории обещают преимущества

В рамках указанного количества итераций - монопенисуально, т.е. в пределах погрешности.
PS: а вопрос все же открыт.

@ForEveR · 15.04.2013, 16:35

oxotnik,

В дебаге доступ по индексу работает в 2-2.5 раза быстрее, нежели итераторы,

MSVC небось? http://msdn.microsoft.com/en-u... 80%29.aspx

oxotnik · 15.04.2013, 16:39 **[ТС]**

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

MSVC небось?

gcc под линуксом...
а MSVC вообще говнокомпилятор, я с ним не работаю, после того, как ловил 2 дня баг в его реализации stringstream

@ForEveR · 15.04.2013, 18:15

oxotnik, Ну ок... Вообще в debug версии вполне возможны некие проверки и для gcc. Собрано с флажком -D_GLIBCXX_DEBUG? А вообще в чем вопрос? Вполне резонно, что в debug версии итераторы будут более тормозные.

@Kastaneda · 15.04.2013, 18:45

Про дебаг написали выше, а про релиз

в релизе картина с точностью до наоборот - итераторы в 2 раза быстрее.

нужно конечно ассембреный код глянуть, но можно предположить, что итератор в релизе реализован как простой указатель и прямой доступ по указателю быстрее, чем через вызов оператора [].

oxotnik · 15.04.2013, 22:08 **[ТС]**

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

Вполне резонно, что в debug версии итераторы будут более тормозные.

Меня и интересует почему...

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

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

В принципе он и в дебаге так же реализован.

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

чем через вызов оператора [].

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

@diagon · 15.04.2013, 22:48

Зависит от компилятора и ключей оптимизации. На ассемблерном-то уровне понятно, что обход через указатели быстрее обхода через индексы, но нормальный компилятор в таких вещах разбирается лучше.
И даже если ваш компилятор ничего не оптимизировал, я никогда не поверю в то, что способ получения адреса элемента ускорит обход в 2 раза - доступ к памяти никуда не делся, а ведь он пожирает ~200 процессорных тактов. Мелкая арифметика на фоне этой операции вообще ни на что не влияет.

Обновил страничку :)

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

вызов оператора []

Да, слона то я и не приметил. Если не использовать магические ключики оптимизаций, то [] не заинлайнится. Хотя, такое таки маловероятно - сложно представить себе человека, который задумывается о перформансе и при этом не включил хотя бы -O1.

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

gcc под линуксом...

Тогда, если оптимизация таки использовалась, дело в том, что компилятор предпринял разные оптимизации для этих циклов.

Добавлено через 2 минуты
Кстати, мне лень вникать в логику второго кода, но на лвс он работает более 10 секунд. Таки есть подозрение, что циклы немного неэквивалентны.

oxotnik · 15.04.2013, 23:08 **[ТС]**

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

Кстати, мне лень вникать в логику второго кода, но на лвс он работает более 10 секунд. Таки есть подозрение, что циклы немного неэквивалентны.

Медленный ~20-24 с, быстрый ~10-12c. (на виртуалке).
Почему они не эквивалентны? По логике они абсолютно эквивалентны, а логика в данном случае - определяющий фактор.

@diagon · 15.04.2013, 23:21

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

Почему они не эквивалентны? По логике они абсолютно эквивалентны, а логика в данном случае - определяющий фактор.

Потому что первый на гцц с оптимизациями выполняется за 0.1 секунду, второй - более 10 секунд.
Хотя, во втором цикле действительно не так то просто отследить, что не будет выхода за границы или чего-то подобного.
Посмотрел на асмовыхлоп гцц на первом цикле - лол, да и только.

@grizlik78 · 15.04.2013, 23:34

Внутри цикла по m во втором коде я вижу обнуление индекса в строках 6 и 12, а в первом коде итератор обнуляется только в строке 12 (ну и один раз до цикла). А второй раз что? Не нужно? Или это я настолько "с наскока", что ничего не понял?

@ForEveR · 16.04.2013, 07:46

grizlik78, А ведь действительно. Получается этот цикл:

C++
1
2
3
4
5
        for(; it != tmp.end(); ++it)
        {
            (*it) = i + 1;
            ++i;
        }

Выполнится единожды.

oxotnik · 16.04.2013, 09:11 **[ТС]**

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

Внутри цикла по m во втором коде я вижу обнуление индекса в строках 6 и 12, а в первом коде итератор обнуляется только в строке 12 (ну и один раз до цикла). А второй раз что? Не нужно? Или это я настолько "с наскока", что ничего не понял?

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

@SatanaXIII · 16.04.2013, 10:15

Тема ~~сисек~~ противостояния раскрыта не полностью. Так что же получается можно забыть про все эти итераторы и работать с индексами и не париться? Зачем два одинаковых механизма?

oxotnik · 16.04.2013, 10:20 **[ТС]**

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

раскрыта не полностью

Что не раскрыто?

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

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

Выходит что так...

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

Зачем два одинаковых механизма?

У любого индивидуума должен быть выбор, таков принцип демократии.

@AC-93 · 16.04.2013, 10:23

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

не эффективный цикл, на каждой итерации идет обращение к tmp.end().

Добавлено через 2 минуты
Заменить на

C++
1
for(auto stop = tmp.end(); it != stop; ++it)

и попробовать снова.

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

@SatanaXIII · 16.04.2013, 10:26

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

У любого индивидуума должен быть выбор, таков принцип демократии.

Лады. Тогда где остальные дублирующие механизмы всего остального?

oxotnik, а как вы вообще замеряли скорость работы?

oxotnik · 16.04.2013, 10:28 **[ТС]**

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

Тогда где остальные дублирующие механизмы всего остального?

Чего конкретно?
К примеру есть указатели, и есть ссылки.

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

а как вы вообще замеряли скорость работы?

Каюсь, замерял немного кривовато, с помощюб QTime::elapsed(), но в принципе для теста хватит.

Новые блоги и статьи Все статьи Все блоги /
MVC фреймворк в PHP Jason-Webb 19.04.2025 Архитектурный паттерн Model-View-Controller (MVC) – это не просто модный термин из мира веб-разработки. Для PHP-программистов это фундаментальный подход к организации кода, который радикально меняет. . .	Dictionary Comprehensions в Python py-thonny 19.04.2025 Python славится своей выразительностью и лаконичностью, что позволяет писать чистый и понятный код. Среди множества синтаксических конструкций языка особое место занимают словарные включения. . .	Шаблоны и протоколы для создания устойчивых микросервисов ArchitectMsa 19.04.2025 Микросервисы — архитектурный подход, разбивающий сложные приложения на небольшие, независимые компоненты. Вместо монолитного гиганта, система превращается в созвездие небольших взаимодействующих. . .	Изменяемые и неизменяемые типы в Python py-thonny 19.04.2025 Python славится своей гибкостью и интуитивной понятностью, а одна из главных его особенностей — это система типов данных. В этом языке все, включая числа, строки, функции и даже классы, является. . .	Интеграция Hangfire с RabbitMQ в проектах C#.NET stackOverflow 18.04.2025 Разработка современных . NET-приложений часто требует выполнения задач "за кулисами". Это может быть отправка email-уведомлений, генерация отчётов, обработка загруженных файлов или синхронизация. . .
Построение эффективных запросов в микросервисной архитектуре: Стратегии и практики ArchitectMsa 18.04.2025 Микросервисная архитектура принесла с собой много преимуществ — возможность независимого масштабирования сервисов, технологическую гибкость и четкое разграничение ответственности. Но как часто бывает. . .	Префабы в Unity: Использование, хранение, управление GameUnited 18.04.2025 Префабы — один из краеугольных элементов разработки игр в Unity, представляющий собой шаблоны объектов, которые можно многократно использовать в различных сценах. Они позволяют создавать составные. . .	RabbitMQ как шина данных в интеграционных решениях на C# (с MassTransit) stackOverflow 18.04.2025 Современный бизнес опирается на множество специализированных программных систем, каждая из которых заточена под решение конкретных задач. CRM управляет отношениями с клиентами, ERP контролирует. . .	Типы в TypeScript run.dev 18.04.2025 TypeScript представляет собой мощное расширение JavaScript, которое добавляет статическую типизацию в этот динамический язык. В JavaScript, где переменная может свободно менять тип в процессе. . .	Погружение в Kafka: Концепции и примеры на C# с ASP.NET Core stackOverflow 18.04.2025 Apache Kafka изменила подход к обработке данных в распределенных системах. Эта платформа потоковой передачи данных выходит далеко за рамки обычной шины сообщений, предлагая мощные возможности,. . .

@abit 690 / 468 / 143 Регистрация: 03.02.2013 Сообщений: 1,482
	15.04.2013, 15:20
	и во втором цикле можно взять const_iterator, в теории обещают преимущества 0

oxotnik 1665 / 1134 / 80 Регистрация: 21.08.2008 Сообщений: 4,734 Записей в блоге: 1
	15.04.2013, 15:34 [ТС]
	Сообщение от yuron_477 не эффективный цикл, на каждой итерации идет обращение к tmp.end(). Сообщение от abit и во втором цикле можно взять const_iterator, в теории обещают преимущества В рамках указанного количества итераций - монопенисуально, т.е. в пределах погрешности. PS: а вопрос все же открыт. 0

@ForEveR В астрале 8049 / 4806 / 655 Регистрация: 24.06.2010 Сообщений: 10,562
	15.04.2013, 16:35
	oxotnik, В дебаге доступ по индексу работает в 2-2.5 раза быстрее, нежели итераторы, MSVC небось? http://msdn.microsoft.com/en-u... 80%29.aspx 0

oxotnik 1665 / 1134 / 80 Регистрация: 21.08.2008 Сообщений: 4,734 Записей в блоге: 1
	15.04.2013, 16:39 [ТС]
	Сообщение от ForEveR MSVC небось? gcc под линуксом... а MSVC вообще говнокомпилятор, я с ним не работаю, после того, как ловил 2 дня баг в его реализации stringstream 0

@ForEveR В астрале 8049 / 4806 / 655 Регистрация: 24.06.2010 Сообщений: 10,562
	15.04.2013, 18:15
	oxotnik, Ну ок... Вообще в debug версии вполне возможны некие проверки и для gcc. Собрано с флажком -D_GLIBCXX_DEBUG? А вообще в чем вопрос? Вполне резонно, что в debug версии итераторы будут более тормозные. 0

@Kastaneda 5232 / 3204 / 362 Регистрация: 12.12.2009 Сообщений: 8,143 Записей в блоге: 2
	15.04.2013, 18:45
	Про дебаг написали выше, а про релиз в релизе картина с точностью до наоборот - итераторы в 2 раза быстрее. нужно конечно ассембреный код глянуть, но можно предположить, что итератор в релизе реализован как простой указатель и прямой доступ по указателю быстрее, чем через вызов оператора []. 0

oxotnik 1665 / 1134 / 80 Регистрация: 21.08.2008 Сообщений: 4,734 Записей в блоге: 1
	15.04.2013, 22:08 [ТС]
	Сообщение от ForEveR Вполне резонно, что в debug версии итераторы будут более тормозные. Меня и интересует почему... Сообщение от Kastaneda что итератор в релизе реализован как простой указатель и прямой доступ по указателю быстрее В принципе он и в дебаге так же реализован. Сообщение от Kastaneda чем через вызов оператора []. Только непонятно в чем между ними различие. 0

@diagon Higher 1953 / 1219 / 120 Регистрация: 02.05.2010 Сообщений: 2,925 Записей в блоге: 2
	15.04.2013, 22:48
	Зависит от компилятора и ключей оптимизации. На ассемблерном-то уровне понятно, что обход через указатели быстрее обхода через индексы, но нормальный компилятор в таких вещах разбирается лучше. И даже если ваш компилятор ничего не оптимизировал, я никогда не поверю в то, что способ получения адреса элемента ускорит обход в 2 раза - доступ к памяти никуда не делся, а ведь он пожирает ~200 процессорных тактов. Мелкая арифметика на фоне этой операции вообще ни на что не влияет. Обновил страничку :) Сообщение от Kastaneda вызов оператора [] Да, слона то я и не приметил. Если не использовать магические ключики оптимизаций, то [] не заинлайнится. Хотя, такое таки маловероятно - сложно представить себе человека, который задумывается о перформансе и при этом не включил хотя бы -O1. Сообщение от oxotnik gcc под линуксом... Тогда, если оптимизация таки использовалась, дело в том, что компилятор предпринял разные оптимизации для этих циклов. Добавлено через 2 минуты Кстати, мне лень вникать в логику второго кода, но на лвс он работает более 10 секунд. Таки есть подозрение, что циклы немного неэквивалентны. 0

oxotnik 1665 / 1134 / 80 Регистрация: 21.08.2008 Сообщений: 4,734 Записей в блоге: 1
	15.04.2013, 23:08 [ТС]
	Сообщение от diagon Кстати, мне лень вникать в логику второго кода, но на лвс он работает более 10 секунд. Таки есть подозрение, что циклы немного неэквивалентны. Медленный ~20-24 с, быстрый ~10-12c. (на виртуалке). Почему они не эквивалентны? По логике они абсолютно эквивалентны, а логика в данном случае - определяющий фактор. 0

@diagon Higher 1953 / 1219 / 120 Регистрация: 02.05.2010 Сообщений: 2,925 Записей в блоге: 2
	15.04.2013, 23:21
	Сообщение от oxotnik Почему они не эквивалентны? По логике они абсолютно эквивалентны, а логика в данном случае - определяющий фактор. Потому что первый на гцц с оптимизациями выполняется за 0.1 секунду, второй - более 10 секунд. Хотя, во втором цикле действительно не так то просто отследить, что не будет выхода за границы или чего-то подобного. Посмотрел на асмовыхлоп гцц на первом цикле - лол, да и только. 0

@grizlik78 2382 / 1666 / 279 Регистрация: 29.05.2011 Сообщений: 3,402
	15.04.2013, 23:34
	Внутри цикла по m во втором коде я вижу обнуление индекса в строках 6 и 12, а в первом коде итератор обнуляется только в строке 12 (ну и один раз до цикла). А второй раз что? Не нужно? Или это я настолько "с наскока", что ничего не понял? 2

oxotnik 1665 / 1134 / 80 Регистрация: 21.08.2008 Сообщений: 4,734 Записей в блоге: 1
	16.04.2013, 09:11 [ТС]
	Сообщение от grizlik78 Внутри цикла по m во втором коде я вижу обнуление индекса в строках 6 и 12, а в первом коде итератор обнуляется только в строке 12 (ну и один раз до цикла). А второй раз что? Не нужно? Или это я настолько "с наскока", что ничего не понял? Твоя правда. Если обнулять в обоих случаях, тогда одинаково примерно работают. Можно закрывать тему. 0

@SatanaXIII Почетный модератор 5851 / 2862 / 392 Регистрация: 01.11.2011 Сообщений: 6,906
	16.04.2013, 10:15
	Тема ~~сисек~~ противостояния раскрыта не полностью. Так что же получается можно забыть про все эти итераторы и работать с индексами и не париться? Зачем два одинаковых механизма? 0

oxotnik 1665 / 1134 / 80 Регистрация: 21.08.2008 Сообщений: 4,734 Записей в блоге: 1
	16.04.2013, 10:20 [ТС]
	Сообщение от SatanaXIII раскрыта не полностью Что не раскрыто? Сообщение от SatanaXIII Так что же получается можно забыть про все эти итераторы и работать с индексами и не париться? Выходит что так... Сообщение от SatanaXIII Зачем два одинаковых механизма? У любого индивидуума должен быть выбор, таков принцип демократии. 0

@SatanaXIII Почетный модератор 5851 / 2862 / 392 Регистрация: 01.11.2011 Сообщений: 6,906
	16.04.2013, 10:26
	Сообщение от oxotnik У любого индивидуума должен быть выбор, таков принцип демократии. Лады. Тогда где остальные дублирующие механизмы всего остального? oxotnik, а как вы вообще замеряли скорость работы? 0

oxotnik 1665 / 1134 / 80 Регистрация: 21.08.2008 Сообщений: 4,734 Записей в блоге: 1
	16.04.2013, 10:28 [ТС]
	Сообщение от SatanaXIII Тогда где остальные дублирующие механизмы всего остального? Чего конкретно? К примеру есть указатели, и есть ссылки. Сообщение от SatanaXIII а как вы вообще замеряли скорость работы? Каюсь, замерял немного кривовато, с помощюб QTime::elapsed(), но в принципе для теста хватит. 0