108 / 108 / 23
Регистрация: 21.03.2010
Сообщений: 445
|
|
1 | |
Производительность операций20.11.2011, 06:34. Показов 13779. Ответов 135
Метки нет (Все метки)
Не уверен в своих силах для самостоятельной оценки сабжа. Где можно найти информацию о производительности стандартных операций с++ (гуглением не справился, нашел только сравнение реализации на с++, джаве и на нескольких интерпретируемых языках)?
То есть интересует информация плана << : * как 1:15 или <= : == как 25:24... То есть, чрезвычайно интересно знать, какие операции выбирать если есть альтернатива.
0
|
20.11.2011, 06:34 | |
Ответы с готовыми решениями:
135
Вставить между цифрами 1, 2,..., 8, 9 в данном порядке, знак одной из 4-х арифметических операций так, чтобы результат восьми послед-х операций =100 Производительность Заменить в данной строке знаки арифметических операций названиями противоположных им операций Доказать равенства, используя свойства операций над множествами и определения операций |
108 / 108 / 23
Регистрация: 21.03.2010
Сообщений: 445
|
||||||
21.11.2011, 16:31 [ТС] | 2 | |||||
Мою тему просмотрело 39 человек и всем нечего было сказать. Я решился сам.
Код
Усреднение №2620000: Инициализация в 1.09377 раз быстрее, чем обявление+присвоение. Префиксный инткримент в 0.998926 раз быстрее, чем постфиксный. Разименование указателя в 19.9195 раз быстрее, чем итератора. Обращение к элементу массива в 8.17944 раз быстрее, чем к элементу вектора. Целочисленное сложение в 1.02781 раз быстрее, чем умножение. Вещественное сложение в 2.49602 раз быстрее, чем умножение. Умнжение в 2.49602 раз быстрее, чем извлечение корня. Указатель в 1.18523 раз быстрее, чем индекс. Итератор в 1.04466 раз быстрее, чем индекс. Неравно в 0.424205 раз быстрее, чем меньше. Я уверен, что тема интересна не только мне, и буду рад, если кто-то проявит интерес и дополнит мой список сравнений своим. Очень надеюсь, что найдётся человек, имеющий хорошее понятие об оптимизации в какой-либо среде разработки, и сможет сформулировать правило написания объективного теста сабжа.
0
|
108 / 108 / 23
Регистрация: 21.03.2010
Сообщений: 445
|
|
21.11.2011, 16:42 [ТС] | 4 |
Во время правки, обнаружил явное свидетельство, что в таком виде результат не верен: если поменять местами порядок выполнения в последнем тесте( x < y; и x != y; ), не изменится ничего. Хотя, это можно объяснить тем, что операции выполняются одинаково долго, сопоставимо с затратами на засечение времени.
Добавлено через 1 минуту Да, кстати. У меня sony Vaio с intel core i3 по моему. 4 ядра (виртуальное удвоение) Добавлено через 1 минуту Возможно, именно из-за этого у меня при небольшом количестве проходов (менее десяти) результаты сильно другие... Да и вообще, постоянно разные. В идеальном тесте соотношение должно быть постоянным.
0
|
Заблокирован
|
|
21.11.2011, 16:43 | 5 |
Не стал разбираться в вашем коде, так как сразу столкнулся с вызывающими вопросы конструкциями.
Например, в С++ (если имеется в виду стандарт 2003, как в 2011 я не знаю) нет такого типа, как long long. Или такая вычурная конструкция, как while ( true || false ). Очевидно, что true || false всегда равно true , поэтому почему бы просто не написать while ( true ), если вы имеете в виду бесконечный цикл. Кроме того ваши выводы по поводу постинкремента и прединкоремента некорректные, так как обычно если значение постинкремента не присваивается другой переменной, то для функдаментальных типов компилятор генерирует один и тот же код для прединкремента и постинкремента. Если же речь заходит о пользовательских типах, то тем более ваш вывод некорректен, так как все зависит от сложности реализации пользовательских типов, и нельзя с определенностью указать разницу во времени исполнения. То есть поднятый вами вопрос и то, как вы подощли к его решению, не представляет никакого интереса для профессиональных программистов..
2
|
В астрале
8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
|
|
21.11.2011, 16:45 | 6 |
А еще советую собрать программу в режиме релиза, врубить -O3 и попробовать еще раз.
0
|
108 / 108 / 23
Регистрация: 21.03.2010
Сообщений: 445
|
|
21.11.2011, 16:50 [ТС] | 7 |
процессор Core i5 2530 МГц в яндексмаркете написано
Добавлено через 3 минуты Уходи из моего топика в раздел для профессионалов, злой человек. У страуструпа, в его великом толмуде написано, что префиксный лучше. Как вы упомянули, для вас очевидно, что компилятор учтёт, что для встроенного типа в данном контектсе разницы нет, и сгенерирует одинаковый код. Мне же, такие вещи, не дают покоя день и ночь. Я мало читал и не уверен, поведёт ли себя компилятор безупречно в таком контексте.
0
|
108 / 108 / 23
Регистрация: 21.03.2010
Сообщений: 445
|
|
21.11.2011, 17:00 [ТС] | 10 |
Переключил на релиз, результаты изменились! Что такое -ОЗ, не понял... что это?
Код
Усреднение №2900000: Инициализация в 1.22925 раз быстрее, чем обявление+присвоение. Префиксный инткримент в 4.56375 раз быстрее, чем постфиксный. Разименование указателя в 1.07129 раз быстрее, чем итератора. Обращение к элементу массива в 2.59468 раз быстрее, чем к элементу вектора. Целочисленное сложение в 2.56498 раз быстрее, чем умножение. Вещественное сложение в 2.54113 раз быстрее, чем умножение. Умнжение в 2.54113 раз быстрее, чем извлечение корня. Указатель в 2.53189 раз быстрее, чем индекс. Итератор в 2.50638 раз быстрее, чем индекс. Неравно в 2.58332 раз быстрее, чем меньше. Добавлено через 2 минуты Нет, там подробный коментайрий. префиксный в с++ выполняется до каких-либо других операций. таким образом не нужно заводить копию переменной. А при выполнении постфиксного инкремента/декремента создаётся копия переменной, передаваемая для остальных операций, а значение соответствующее идентификатору к которому применена операция меняется независимо от копии. Добавлено через 1 минуту Просто ваша бескомпромиссность не располагает. Ведь уже сейчас, я продемонстрировал, что ваше утверждение о инкрементах/декрементах не верно в абсолютном смысле.
0
|
Заблокирован
|
|
21.11.2011, 17:04 | 11 |
едва ли это так
Код
int e = 0; __asm { rdtsc 010A1251 rdtsc mov a, eax 010A1253 mov dword ptr [esp+1Ch],eax } e++; __asm { rdtsc 010A1257 rdtsc mov b, eax 010A1259 mov dword ptr [esp+18h],eax } ++e; __asm { rdtsc 010A125D rdtsc mov c, eax 010A125F mov dword ptr [esp+20h],eax }
0
|
21.11.2011, 17:04 | 12 |
Максимальный уровень оптимизации.
Современные компиляторы, как уже говорилось выше, будут поумнее многих программистов и в состоянии определить когда надо делать копию, а когда нет. Поэтому - исключительно эстетика. Не по теме: И не надо мне объяснять почему префиксный лучше, это лишнее ;)
0
|
Заблокирован
|
||||||
21.11.2011, 17:05 | 13 | |||||
Я вам уже все написал, только вы из-за своего гонора дилетанта не внимательно читаете, что вам пишут другие!
Повторю еще раз, если с первого раза до вас не доходит. Если результат посинкрементной операции для фундаментального типа не присваивается другой переменной, то компилятор генерирует один и тот же код для прединкремента и постинкремента. Например, в следующих двух примерах никакой разницы нет
Заранее предвижу вашу реакцию, так как дилетанты всегда агрессивны, поэтому убедительная просьба, перечитать мой ответ по крайнней мере два раза, прежде чем, что-то возражать.
0
|
385 / 229 / 12
Регистрация: 06.07.2011
Сообщений: 512
|
|
21.11.2011, 17:12 | 15 |
имеется ввиду, что разница в производительности в большинстве случаев настолько несущественна с современными мощностями и компиляторами, что никакого отношения к серьезной оптимизации оно не имеет и чаще всего интересна из чистого любопытства. и когда пишется код, правильнее выбирать то, что очевидно в данной ситуации и наиболее понятно при чтении кода.
и вообще странное противопоставление сложения и умножения... не проще сравнить ассемблерные команды операций для оценки производительности?
0
|
108 / 108 / 23
Регистрация: 21.03.2010
Сообщений: 445
|
|
21.11.2011, 17:20 [ТС] | 17 |
Но ведь я же продемонстрировал, что в текущем состоянии мой код выдаёт результаты, расходящиеся с тем, что прогнозируете вы (кстати, я доверительно отнёсся к вашему посылу, ведь в первоначальном варианте результаты польностью ему соответствовали). Если расхождение есть, объясните, откуда оно а не говорите что сделает компилятор, если очевидно обратное.
Я недавно изучал алгоритм построения гладкой линии, в википедии был приведёт вариант реализации, тщательно избегавший операции умножения. Мне хотелось понять, насколько это оправданно. Боюсь, это приведёт к тому, что выполнение части моих операций будет отключено вовсе. Было бы хорошо добиться того, чтобы компилятор делал какую-то оптимизацию, скажем, по обращению к элементу вектора, но в то же время, не на столько грубую, чтобы отключать операции, в которых нет явной необходимости. Отказываюсь понимать, почему производительность кого-то не интересует. Если я планирую не уходить от разработки простых интерфейсов, возможно. Но по моей специальности (не програмирование), мне в ближайшее время придётся писать максимально эффективные коды (в частности, решение специфичных СЛАУ, не имеющих эффективной реализации в библиотеках типа boost).
0
|
В астрале
8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
|
|
21.11.2011, 17:22 | 18 |
CEBEP, Точно не имеющих? http://www.boost.org/doc/libs/... /index.htm
0
|
108 / 108 / 23
Регистрация: 21.03.2010
Сообщений: 445
|
|
21.11.2011, 17:24 [ТС] | 20 |
0
|
21.11.2011, 17:24 | |
21.11.2011, 17:24 | |
Помогаю со студенческими работами здесь
20
Доказать равенства, используя свойства операций над множествами и определения операций Сколько нужно провести операций, чтобы 13 операций подряд были успешными? Доказать равенства, используя свойства операций над множествами и определения операций Напечатать все знаки арифметических операций и операций отношения Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |