6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 138
|
|
1 | |
Проверка скорости кода. Обмен опытом09.04.2016, 16:14. Показов 1341. Ответов 16
Метки нет (Все метки)
Вводные данные:
- C++ стандарта 11 - gcc Работаю над ускорением кода для работы со строками. К примеру, сравниваю между собой скорость работы: -strncpy -strcpy -через ассемблер movs -memcpy Что делаю. Чтобы результаты были правдоподобны, замеряю общее время работы каждой функции за N итераций цикла (например 1 млн) и подсчитываю среднее время. С чего начал. Начала с простого. Запуск функций на готовых переменных типа char[10]. Чем больше итераций, тем быстрее работает функция (кроме ассемблерной вставки). Понятно что компилятор оптимизирует код. К пример единичный запуск показывает время работы 3000 нано сек, второй запуск уже 1500 нано сек. Опции компилятора -O не помогает. Чем продолжил. Генерирую массив на N строк. Забиваю его random символами. Запускаю. По прежнему ассемблерная вставка показывает постоянный результат, все остальные функции от кол-во итераций ускоряются, но уже меньше. Стали влиять так же опции компилятора -O. Вопрос. Как вычислить истинное значение времени работы функции? Поделитесь опытом.
0
|
09.04.2016, 16:14 | |
Ответы с готовыми решениями:
16
Обмен опытом и сотрудничество Обмен опытом по программированию на С++ Обмен опытом или как бы это сделали бы Вы!! Обмен данными по COM порту на нестандартной скорости |
Модератор
3386 / 2158 / 352
Регистрация: 13.01.2012
Сообщений: 8,371
|
|
10.04.2016, 08:30 | 2 |
Что меня удивило - порядок цифр - ЧЕМ вы меряете нс? На вин я мерил ну никак не точнее мкс
0
|
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 138
|
|
10.04.2016, 10:15 [ТС] | 3 |
вчера я нашел сам ответ на свой вопрос и достаточно корректно замерил.
для времени использую gettimeofday речь идет о десятке - паре десятков нано сек.
0
|
Модератор
3386 / 2158 / 352
Регистрация: 13.01.2012
Сообщений: 8,371
|
|
10.04.2016, 10:46 | 4 |
Если речь о таких промежутках замер на единичном вызове не имеет смысла так как не хватит разрешающей способности
0
|
1473 / 1392 / 238
Регистрация: 19.02.2010
Сообщений: 3,894
|
|
10.04.2016, 21:35 | 5 |
Ради интереса гляньте на старую презенташку https://kldp.org/files/gdc_2002_amd.pdf - там видно, что скорость реализаций memcpy может отличаться в разы. Но! Только при условии заточки под вполне определённые особенности данных (размеры блоков памяти, неиспользование массива-реципиента сразу же после копирования, или что ещё).
0
|
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 138
|
|
11.04.2016, 10:23 [ТС] | 6 |
Добавлено через 11 часов 50 минут Кстати исходя из своего опыта ассемблера, я понял, почему memcpy дает очень разные результаты на разных кусках памяти.
0
|
Модератор
3386 / 2158 / 352
Регистрация: 13.01.2012
Сообщений: 8,371
|
|
11.04.2016, 11:41 | 7 |
0
|
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 138
|
|
11.04.2016, 12:02 [ТС] | 8 |
Извините, у меня на форуме не получается комментировать в ответе чужое сообщение.
Мое мнение такое. Я его частично проверил, частично не успел. Я был удивлен, что memcpy обгоняет мой код ассембелера. И после экспериментов понял почему. Для процессора, типы данных делятся на: 1,2,4,8,10 байт. memcpy скорее всего перекидывает из памяти в память по большему значению (например 10 байт) и потом остаток побайтно (или по 2 байта или 4 байта, в зависимости от остатка). Кстати на ассм я делал по 4 байта, поэтому проиграл. Получается, если тип данных хорошо кратен данным цифрам, то кол-во операций процессора (особенно связанные с записью в регистр) минимально. Например если мы будем перекидывать строки длиной 10 байт, memcpy тут просто будет идеален, а если 13, то уже будет работать медленней. Я его не диззасемблировал еще, но скорее всего он перекинет 10 + 2 + 1. Это как минимум еще 2 обращения к регистру ecx. КАк то так мое мнение, я его чуть позже проверю окончательно.
1
|
2924 / 1274 / 114
Регистрация: 27.05.2008
Сообщений: 3,465
|
|
12.04.2016, 13:24 | 9 |
Открою тебе маленький секрет: компиляторы пишут весьма неглупые люди. И они отлично представляют себе, что функции типа memcpy будут вызываться не просто часто, а оочень! часто. И поэтому оптимизируют их по самые.... короче, по эти самые
0
|
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 138
|
|
12.04.2016, 13:31 [ТС] | 10 |
Честно говоря, я думаю, что я ее обгоню в нестандартной ситуации. Я еще не до конца дотестил.
Например если мне надо будет перегнать 32 байта, думаю, что быстрее будет сделать на ассм 4 по 8 байт, чем memcpy сделает 10 + 10 +10 + 2. Но мне это еще предстоит изучить.
0
|
2924 / 1274 / 114
Регистрация: 27.05.2008
Сообщений: 3,465
|
|
12.04.2016, 16:09 | 11 |
Да, обгонишь. Вне всякого сомнения. На твоей машине (с твоим CPU и твоими кэшами). А что будет при переносе на соседнюю машину - с другим CPU, кэшами и так далее? А на третью, двадцатую...?
1
|
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 138
|
|
12.04.2016, 16:27 [ТС] | 12 |
Замечание верное. Но я/мы затачиваем под конкретную задачу на конкретном сервере на конкретной ОС.
0
|
1473 / 1392 / 238
Регистрация: 19.02.2010
Сообщений: 3,894
|
|
18.04.2016, 12:34 | 13 |
karat39, кстати, ещё вариант поглядеть - библиотечка от Агнера Фога, брать на agner.org
Там memcpy и strcpy есть - может, в их исходниках найдётся что-то интересное. Заодно там же на сайте лежат справочники по растактовке процессорных команд у разных процессоров и мануалы по оптимизации программ на ассемблере и С. Ну и у Интела взять тамошний Intel 64 and IA-32 Architectures Optimization Reference Manual.
1
|
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 138
|
|
19.04.2016, 08:55 [ТС] | 14 |
VTsaregorodtsev, спасибо, заинтересовала растактовка.
Кстати по прежнему уверен, что при умелом подходе, все таки надо ассм вставлять. Хотя memcpy крайне сложно обогнать. Чуть позже дизассемблирую ее и гляну что там. Добавлено через 8 минут VTsaregorodtsev, спасибо огромное за сайт.
0
|
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 138
|
|
12.05.2016, 22:40 [ТС] | 15 |
Если кому будет интересно. boost классно замеряет скорость. Можно спуститься до наносекунд.
0
|
Модератор
3386 / 2158 / 352
Регистрация: 13.01.2012
Сообщений: 8,371
|
|
13.05.2016, 08:23 | 16 |
karat39, слайды слайды! Если честно про нано - не верю
0
|
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 138
|
|
13.05.2016, 11:15 [ТС] | 17 |
чуть позже (на выходных) я расскажу весь свой полученный опыт.
0
|
13.05.2016, 11:15 | |
Помогаю со студенческими работами здесь
17
Проверка скорости работы своего list Поиск Пифагоровых троек: оптимизация кода по скорости Замер скорости выполнения участка кода Обмен опытом об iptables Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |