Разное время выполнения одного и того же кода

Здравствуйте!

Есть код реализации получения контурного препарата изображения (фильтр Собеля):

Код (Text):

1.  mov edi,ppvBitsS;
2.   mov esi,ppvBits1;
3.  mov ecx,3840;
4.  
5.  metka3:
6.  xor edx,edx;    
7.  mov eax,ecx;
8.  lea eax,[eax+esi-1920];
9.  movzx ebx, byte ptr [eax+3];
10.  lea edx,[edx+ebx];
11.  
12.  lea eax,[eax+1920];
13.  movzx ebx, byte ptr [eax+3];
14.  shl bx,1;
15.  lea edx,[edx+ebx];
16.  
17.  lea eax,[eax+1920];
18.  movzx ebx, byte ptr [eax+3];
19.  lea edx,[edx+ebx];
20.  
21.  mov eax,ecx;
22.  lea eax,[eax+esi-1920];
23.  movzx ebx, byte ptr [eax-3];
24.  sub edx,ebx;
25.  
26.  lea eax,[eax+1920];
27.  movzx ebx, byte ptr [eax-3];
28.  shl bx,1;
29.  sub edx,ebx;
30.  
31.  lea eax,[eax+1920];
32.  movzx ebx, byte ptr [eax-3];
33.  sub edx,ebx;
34.  shr dx,2;
35.  
36.  m1:
37.  neg edx;              
38.  jl m1
39.  mov ResX,edx;
40.  
41.  mov edx,0;
42.  mov eax,ecx;
43.  lea eax,[eax+esi-1920];
44.  movzx ebx, byte ptr [eax-3];
45.  lea edx,[edx+ebx];
46.  
47.  movzx ebx, byte ptr [eax];
48.  shl bx,1;
49.  lea edx,[edx+ebx];
50.  
51.  movzx ebx, byte ptr [eax+3];
52.  lea edx,[edx+ebx];
53.  
54.  mov eax,ecx;
55.  lea eax,[eax+esi+1920];
56.  movzx ebx, byte ptr [eax-3];
57.  sub edx,ebx;
58.  
59.  movzx ebx, byte ptr [eax];
60.  shl bx,1;
61.  sub edx,ebx;
62.  
63.  movzx ebx, byte ptr [eax+3];
64.  sub edx,ebx;
65.  shr dx,2;
66.  
67.  m2:
68.  neg edx;                
69.  jl m2
70.  add edx,ResX;
71.  
72.  mov eax,ecx;
73.  lea eax,[eax+edi];
74.  
75.  mov [eax],edx;
76.  mov [eax+1],edx;
77.  mov [eax+2],edx;
78.  cmp ecx,679680;
79.  jz metka4
80.  lea ecx,[ecx+3];
81.  jnz metka3
82.  metka4:

Время исполнения данного кода на AMD Athlon 64X2 Dual Core 4600+ 2.4 ГГц колеблется от 0.0057 до 0.006 секунды. То есть, скажем так, дисперсия небольшая и неудивительная.

Выполняя данный код на ноутбуке с одноядерным Athlon`ом 2.2 ГГц получаю различные значения времени выполнения от 0.009 до 0.02 секунды.
Почему один и тот же код периодически выполняется в два раза медленнее??

Время замеряю с помощью функции QueryPerformanceCounter

Спасибо!

 

NT не система реального времени. Для точных измерений замеры времени исполняются с замаскированными прерываниями, тоесть в ядре. В юзермоде необходимо поднять приоритет и выполнять измеряемый код достаточно долго, в пределах секунд/десятков секунд.

 

То есть дело ТОЛЬКО в том, что система на ноутбуке регулярно отжирает ресурсы в момент выполнения кода более "заметно", чем на более мощной машине ?
А я подумал, может надо какие-нибудь выравнивания меток/данных делать...

 

Randel
Там много что сказывается. Но в первую очередь можно обратить внимание на то, что больший разброс получен на 1-ядерном процессоре, а на 2-ядерном -- намного меньше. Можно предположить, что на 2-ядерном данная задача всё время крутилась на одном из ядер, в то время как другие задачи (системе ж тоже процессор время от времени нужен -- хотя б прерывания от таймера обрабатывать) работали на втором ядре. На одноядерном же выбора нет, и система периодически снимала этот код с процессора. Если такое часто происходило, время выполнения резко возрастало.

 

Спасибо большое за ответы. Для меня в общем-то главное было определить - неизбежна ли эта периодическая задержка...То есть "систематическая" ли она, или связана с моим плохим кодом...Просто сейчас пытаюсь увеличить быстродействие, вот и бьюсь за каждую секунду...
В ассемблере я новичок - может кто подскажет чего-нибудь с точки зрения оптимизации данного кода? Вдруг что-то очевидное не замечаю? Сам уже не знаю, как его еще можно "ускорить". Буду очень признателен...

 

насколько помню movzx, оптимизирован под eax и лучшее будет:

movzx eax, byte ptr [bla-bla]

1. Замерий пожалста скорость выполнения в лифте - при движении в низ и в верх
2. Поставь рядом с ноутом кружку с горячим чаем, и замерий скорость,
есть данные, что процесс изменения энтропии влияет на окружаюсчее пространство.


Оптимизация:

 

Спасибо большое за информацию! Пишу из лифта! =)

 

Randel
Насчёт условных переходов, помнится, был общий совет: пока предсказатель переходов процессора не набрал статистику, он считает, что переход назад вероятнее, чем нормальное выполнение (без перехода; это связано с циклами: там же переход назад идёт), а переход вперёд -- менее вероятен, чем нормальное выполнение. Хотя не уверен, очень давно не занимался оптимизацией...

 

SII
Фуфло это в прямом смысле. Если код выполняет миллиарды итераций тогда задержки будут заметны. Иначе абсолютно не имеет значения инструкция. За квант простоя поток могбы выполнить миллионы подобных инструкций.

 

Randel

Не замечаешь:
1) кучи ненужных операций lea по вычислению адреса для каждого movzx
2) загрузки 6+6=12 значений вместо 8 необходимых
3) вычисления модуля с переходом по jl вместо известного безбранчевого варианта на cdq\xor\sub
4) загадочные манипуляции с bx и dx вместо ebx и edx, и не менее загадочные сохранения 3-х edx вместо (видимо) dl
5) супер-опус с проверкой завершения цикла и переходом к началу

 

2 leo
Хотелось бы услышать не очевидные замечания по неоптимизированности кода, а конкретные соображения - из-за чего данный код на одном ядре имеет больший разброс времени выполнения,чем на двух. Мне видятся 2 возможные причины - отличия в архитектурах между одноядерником и двухядерником(топикстартер не уточнил), либо влияние ОС. Второе самое вероятное

 

medstrax1

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

 

medstrax1

Во-первых, эти замечания высказаны по просьбе ТС, который как раз это "что-то очевидное" и не замечает
Во-вторых, и Clerk и SII уже в общем объяснили ситуацию. Остается только обратить внимание, что в первом случае время выполнения составляет "всего" 6 мс, что раза в два меньше величины кванта времени потока, поэтому вероятность вклинивания ОС в этот интервал сама по себе ниже, а на двухядернике тем более. Во втором же случае время составляет порядка 10 мс, что уже сравнимо или равно кванту потока и соотв-но вероятность переключения на другой поток сильно возрастает, особенно на одноядернике.

Как с этим можно бороться при измерениях - вполне очевидно, и Clerk уже об этом сказал - поднять приоритет процесса\потока до реал-тайм\тайм-критикал. Второй существенный момент - это время измерения. Тут есть два подхода. Первый, пропагандируемый Clerk'ом - это "выполнять измеряемый код достаточно долго, в пределах секунд/десятков секунд". Поскольку прерывания ОС по любому неизбежны, то чем дольше мы проводим измерения, тем соотв-но больше вероятность и кол-во этих прерываний. Поэтому увеличение времени ес-но не устраняет "тлетворного влияния" прерываний, а лишь усредняет их вклад и тем самым уменьшает разброс результатов. Однако для "ловли блох" и выявления "тонких" различий в скорости этот способ малоприменим, и для этого юзается прямо противоположный подход - уменьшение времени измерения до величин, существенно меньших размера кванта, плюс проведение серии из 4-8 таких измерений с выбором минимального значения (а не среднего, поэтому если и нарвешься на 1 прерывание в серии, то это завышенное значение будет просто отброшено)

 

А вообще, учите матчасть по метрологии.
Замерить время старта кода, время конца кода и вычесть одно из другого - бессмысленное занятие.

 

Сколько мудрецов, столько и мнений

 

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

 

drmad
Мне вчера человек пиво проспорил. Спор был в том, что можно использовать обычную линейку с разрешением в 1мм вместо микрометра при измерении сечения проволоки. Единицы измерения это отношение двух велечин, одна из которых принята единичной. Тогда можно ввести коэффициент, который может быть сокращён. Тоесть например 0.2мм/1виток = 10мм/50витков. Аналогично и со временем. Если событие длится время, которое измерено не может быть, тогда вводится большее число событий.

 

По правилам метрологии тебе нужно было либо сделать порядочное количество измерений, высчитать среднее время задержки и дисперсию с погрешностью, либо сделать несколько замеров на на достаточно длинном промежутке времени, посчитать среднее время срабатывания кода, потом опять же дисперсию и погрешность.
Но программеры обычно дисперсию и погрешность не считают (ибо она нафиг не сдалась), а вот средние величины - почти всегда.

 

SadKo

Бред - правила о которых ты говоришь придуманы совсем для других измерений. А здесь leo неоднократно объяснял почему нужно не среднее, а минимальное время из серии замеров и почему отклонения от этого минимального времени характеризуют не производительность исследуемого кода, а разнообразные вмешательства системы и вспомогательных действий процессора.

 

SadKo
Тебе бы самому не помешало матчасть повторить, чтобы освежить в памяти понятие грубых погрешностей (промахов, выбросов), которые нужно не усреднять, а выявлять и исключать из результатов измерений - иначе можно получить никому не нужную среднюю температура по больнице, включая морг