Производительность операций

@CEBEP · Регистрация: 21.03.2010

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

Не уверен в своих силах для самостоятельной оценки сабжа. Где можно найти информацию о производительности стандартных операций с++ (гуглением не справился, нашел только сравнение реализации на с++, джаве и на нескольких интерпретируемых языках)?
То есть интересует информация плана << : * как 1:15 или <= : == как 25:24... То есть, чрезвычайно интересно знать, какие операции выбирать если есть альтернатива.

@CEBEP · 21.11.2011, 18:27 **[ТС]**

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

результат rdtsc помещается в пару edx:eax на ia32, а на intel64

кстати да,ведь у меня 32х-разрядное приложение сейчас запускается...

@~~LosAngeles~~ · 21.11.2011, 18:28

taras atavin,
хаха lol! Ещё один эксперт по вопросам оптимизации объявился...

C++

    i = i + 1;
011E14BC  mov         eax,dword ptr [i]  
011E14BF  add         eax,1  
011E14C2  mov         dword ptr [i],eax  
    i++;
011E14C5  mov         eax,dword ptr [i]  
011E14C8  add         eax,1  
011E14CB  mov         dword ptr [i],eax  
    ++i;
011E14CE  mov         eax,dword ptr [i]  
011E14D1  add         eax,1  
011E14D4  mov         dword ptr [i],eax

@fasked · 21.11.2011, 18:29

Много всего неразумного

[QUOTE=taras atavin;2196816]Например,

C++

x=x+1;

медленнее, чем

C++

x++;

C++

x++;

медленнее, чем

C++

++x;

,

C++

x=x+b;

вроде бы медленнее, чем

C++

x+=b;

,

C++

x=x-1;

медленнее, чем

C++

x--;

C++

x--;

медленнее, чем

C++

--x;

,

C++

x=x-b;

вроде бы медленнее, чем

C++

x-=b;

C++

x=x*b;

медленнее, чем

C++

x*=b;

,

C++

x*=2;

медленнее, чем

C++

x+=x;

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

C++

1	x=ab+ad;

медленее, чем

C++

1	x=a*(b+d);

,

C++

x=x/b;

медленнее, чем

C++

x/=b;

. Сдвиги быстрее, чем деление/умножение на степени двойки.

Знатоки подтягиваются

@~~Bers~~ · 21.11.2011, 18:29

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

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

У вас там добавление в конец:

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

vec.push_back(i);

Везде - просто оператор=, а в случае с вектором - не факт что нет реалока.

Что касается указателя вместо итератора - для критичного к скорости места вполне себе приемлемо.

Можно тайпдефом замаскировать под итератор для особо привередливых

@fasked · 21.11.2011, 18:30

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

Что касается указателя вместо итератора - для критичного к скорости места вполне себе приемлемо.

Некрасиво же

У вас там добавление в конец:

Надо reserve добавить.

@taras atavin · 21.11.2011, 18:30

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

@ForEveR · 21.11.2011, 18:31

Bers, Есть реаллок. Ну если одним куском памяти примерно одинаковая скорость будет.

C++

   auto now = chrono::time_point_cast<chrono::milliseconds>(chrono::system_clock::now());
   std::vector<int> vec(size);
   for (size_t i = 0; i < size; ++i)
   {
      vec[i] = i;
   }
   std::cout << "Vector time: " << (chrono::time_point_cast<chrono::milliseconds>(chrono::system_clock::now())
            - now).count() << std::endl;

forever@pterois:~/My_pro1/cpp_pro$ ./file
Vector time: 4
Array time: 3
Pointer time: 1

@~~Bers~~ · 21.11.2011, 18:32

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

Bers, Есть реаллок. Ну если одним куском памяти примерно одинаковая скорость будет.

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

@CEBEP · 21.11.2011, 18:35 **[ТС]**

Сообщение от taras atavin

од C++
x*=2;
медленнее, чем
x+=x;

а если отчебучить что-нибудь типа x = x << 1? Я к тому, что просто список что быстрее а что нет и так ясен - я расставил операции в эксперименте так, что всегда отношение или больше или близко к 1 с первого раза. Хочется знать именно отношение

Сообщение от taras atavin

Итераторы бывают разные.

Да, я видел в официальных источниках упоминания о том, что иногда они - просто T*, а иногда - вспомогательный класс. Дело в том, что мы практически наверняка будем компилировать всё на VisualStudio ещё очень долгое время, знание того, как поведёт себя именно она - в принципе достаточно. Да и тема такая, что для всех компиляторов её не исчерпать да и вряд ли это разумно.

@taras atavin · 21.11.2011, 18:35

Сообщение от Сыроежка

То есть поднятый вами вопрос и то, как вы подощли к его решению, не представляет никакого интереса для профессиональных программистов..

Этим ты показал свой непрофессионализм. Вопрос как раз актуален при ручной оптимизации, сомнителен же только подход.

@fasked · 21.11.2011, 18:36

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

что-нибудь типа x = x << 1

Ну что же Вы так... временная копия же создается

C

x <<= 1;

@~~Bers~~ · 21.11.2011, 18:37

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

Некрасиво же

Просто есть два типа людей:

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

2. Вторые, вместо индексов массивов начинают юзать указатели, а вместо i++ писать ++i

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

У вторых ничего не получается в принципе. Потому что вся эта хрень - экономия на спичках.

@CEBEP · 21.11.2011, 18:38 **[ТС]**

Сообщение от taras atavin

время исполнения отдельных операторов?

кладу в а время перед исполнением первого, исполняю первый, сразу после кладу время в b, потом выполняю второй, кладу время в c. теперь b - a = время выполнения первого, c - b = второго.

@~~LosAngeles~~ · 21.11.2011, 18:39

Сообщение от taras atavin

x=a*b+a*d;
медленее, чем
x=a*(b+d);

только без оптимизации разумеется, в дебаг версии да, на то оно и дебаг, компилятор прямолинеен. С -O3 и это утверждение будет неверным разумеется, а скорее всего и с -О1
Вобщем всё что ты написал неверно

@CEBEP · 21.11.2011, 18:41 **[ТС]**

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

экономия на спичках

первый пункт неиллюзорно сложен а книжки по математическим методам в нашей теме уже прочитаны. выдумывать своё - чуть менее чем защитить кандидатскую.

@taras atavin · 21.11.2011, 18:44

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

и вообще странное противопоставление сложения и умножения...

Это ты странный.

C++

x+x

и

C++

x*2

- дают один результат за разное время, и выгоднее

C++

x+x

, чем

C++

x*2

. Но

C++

x+x+x

и

C++

x*3

тоже дают один результат, а выгоднее

C++

x*3

, чем

C++

x+x+x

.

@~~Сыроежка~~ · 21.11.2011, 18:47

Сообщение от taras atavin

Этим ты показал свой непрофессионализм. Вопрос как раз актуален при ручной оптимизации, сомнителен же только подход.

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

@taras atavin · 21.11.2011, 18:48

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

Точно не имеющих?

Ну ка найди в бусте решение для системы 1000*1000. Так вот, это ещё малыш. Я решал 17000*17000.

@~~Bers~~ · 21.11.2011, 18:48

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

первый пункт неиллюзорно сложен

Не нужно изобретать новые паттерны-алгоритмы.

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

@taras atavin · 21.11.2011, 18:50

Сообщение от Сыроежка

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

Серией? Или заменять удвоение одним сложением? А если выбор между

C++

1	x-ab+ac;

и

C++

1	x=a*(b+c);

?

@fasked 5043 / 2622 / 241 Регистрация: 07.10.2009 Сообщений: 4,310 Записей в блоге: 1
	21.11.2011, 18:30	45
	Сообщение от Bers Что касается указателя вместо итератора - для критичного к скорости места вполне себе приемлемо. Некрасиво же У вас там добавление в конец: Надо reserve добавить. 0

@taras atavin 4226 / 1795 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	21.11.2011, 18:30	46
	Кстати, CEBEP, как ты вообще измеряешь время исполнения отдельных операторов? Ведь без точного времени исполнения непосредственно сравниваемых операторов нельзя получить коэффициенты. 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	21.11.2011, 18:35 [ТС]	49
	Сообщение от taras atavin од C++ x=2; медленнее, чем x+=x; а если отчебучить что-нибудь типа x = x << 1? Я к тому, что просто список что быстрее а что нет и так ясен - я расставил операции в эксперименте так, что всегда отношение или больше или близко к 1 с первого раза. Хочется знать именно отношение Сообщение от taras atavin* Итераторы бывают разные. Да, я видел в официальных источниках упоминания о том, что иногда они - просто T*, а иногда - вспомогательный класс. Дело в том, что мы практически наверняка будем компилировать всё на VisualStudio ещё очень долгое время, знание того, как поведёт себя именно она - в принципе достаточно. Да и тема такая, что для всех компиляторов её не исчерпать да и вряд ли это разумно. 0

@~~Bers~~ Заблокирован
	21.11.2011, 18:37	52
	Сообщение от fasked Некрасиво же Просто есть два типа людей: 1. Первые, если нужно увеличить производительность, находят самые упоротые алгоритмы, и заменяют их на более быстрые. 2. Вторые, вместо индексов массивов начинают юзать указатели, а вместо i++ писать ++i Если у первых не получается улучшить производительность, то они начинают смотреть на дата-ориентированное программирование, и в сторону таких языков, как СИ. У вторых ничего не получается в принципе. Потому что вся эта хрень - экономия на спичках. 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	21.11.2011, 18:38 [ТС]	53
	Сообщение от taras atavin время исполнения отдельных операторов? кладу в а время перед исполнением первого, исполняю первый, сразу после кладу время в b, потом выполняю второй, кладу время в c. теперь b - a = время выполнения первого, c - b = второго. 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
		1
	Производительность операций 20.11.2011, 06:34. Показов 13788. Ответов 135 Метки нет (Все метки) Не уверен в своих силах для самостоятельной оценки сабжа. Где можно найти информацию о производительности стандартных операций с++ (гуглением не справился, нашел только сравнение реализации на с++, джаве и на нескольких интерпретируемых языках)? То есть интересует информация плана << : * как 1:15 или <= : == как 25:24... То есть, чрезвычайно интересно знать, какие операции выбирать если есть альтернатива. 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	21.11.2011, 18:27 [ТС]	41
	Сообщение от LosAngeles результат rdtsc помещается в пару edx:eax на ia32, а на intel64 кстати да,ведь у меня 32х-разрядное приложение сейчас запускается... 0

@~~Bers~~ Заблокирован
	21.11.2011, 18:29	44
	Сообщение от ForEveR Bers, Скорость работы с вектором. Не считаю я что получать указатель на первый элемент и работать с ним это правильно. У вас там добавление в конец: Сообщение от ForEveR vec.push_back(i); Везде - просто оператор=, а в случае с вектором - не факт что нет реалока. Что касается указателя вместо итератора - для критичного к скорости места вполне себе приемлемо. Можно тайпдефом замаскировать под итератор для особо привередливых 0

@~~Bers~~ Заблокирован
	21.11.2011, 18:32	48
	Сообщение от ForEveR Bers, Есть реаллок. Ну если одним куском памяти примерно одинаковая скорость будет. но если примерно одинаковая скорость будит, значит вектор работает примерно одинакова 0

@taras atavin 4226 / 1795 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	21.11.2011, 18:35	50
	Сообщение от Сыроежка То есть поднятый вами вопрос и то, как вы подощли к его решению, не представляет никакого интереса для профессиональных программистов.. Этим ты показал свой непрофессионализм. Вопрос как раз актуален при ручной оптимизации, сомнителен же только подход. 0

@~~LosAngeles~~ Заблокирован
	21.11.2011, 18:39	54
	Сообщение от taras atavin x=ab+ad; медленее, чем x=a*(b+d); только без оптимизации разумеется, в дебаг версии да, на то оно и дебаг, компилятор прямолинеен. С -O3 и это утверждение будет неверным разумеется, а скорее всего и с -О1 Вобщем всё что ты написал неверно 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	21.11.2011, 18:41 [ТС]	55
	Сообщение от Bers экономия на спичках первый пункт неиллюзорно сложен а книжки по математическим методам в нашей теме уже прочитаны. выдумывать своё - чуть менее чем защитить кандидатскую. 0

@~~Сыроежка~~ Заблокирован
	21.11.2011, 18:47	57
	Сообщение от taras atavin Этим ты показал свой непрофессионализм. Вопрос как раз актуален при ручной оптимизации, сомнителен же только подход. Я вам советую сначала почитать Герба Саттера "Решение сложных задач на С++", где он как раз говорит про оптимизацию и проходится по таким "профессионалам", как вы, которые занимаются "ручной оптимизацией". Я могу вам на ушко сказать, где "ручная оптимизация" может вам пригодиться! 0

@taras atavin 4226 / 1795 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	21.11.2011, 18:48	58
	Сообщение от ForEveR Точно не имеющих? Ну ка найди в бусте решение для системы 10001000. Так вот, это ещё малыш. Я решал 1700017000. 1

@~~Bers~~ Заблокирован
	21.11.2011, 18:48	59
	Сообщение от CEBEP первый пункт неиллюзорно сложен Не нужно изобретать новые паттерны-алгоритмы. Нужно просто поменять кусок упоротой архитектуры на другой, более быстрый. Смотришь, какой кусок программы выполняется дольше всех. и думаешь, как его можно оптимизировать. Например, скорость теряется из-за многочисленных левых расчетов - можно на таком участке закэшировать часть данных. 1