Интересные нюансы с производительностью

← →
Zergg (2003-07-02 12:22) [0]

Привет дельфяне.
Проблема в следующем:
Написал программу, которая в потоке производит некоторые вычисления. Каждая итерация вычислений увеличивает значение внутреннего счетчика. По таймеру 1 раз в секнду считывается значение счетчика и он обнуляется. Т.е. грубо говоря меряем производительность процессора. Но....
Если курсор мыши находится вне пределов окна приложения, то производительность возрастает процентов на 20!!!!
Это почему? Кто может аргументировано объяснить?

← →
Семен Сорокин (2003-07-02 12:26) [1]

м.б. не обрабатываются события от мыши в приложении

← →
Digitman (2003-07-02 12:46) [2]

> меряем производительность процессора

а причем здесь процессор ? у него при заданной тактовой частоте всегда одна и та же производительность.

← →
Zergg (2003-07-02 13:24) [3]

Я ожидал что она действительно будет одинакова, не зависимо от перемещения мыши.
Но увы производительность скачет очччень ощутимо, в зависимости от положения мыши.
Мож потому что выполняется в отдельном потоке?
Хотя приоритет выставил Higest.
Не ставить же TimeCritical?

← →
Skier (2003-07-02 13:31) [4]

>Zergg (02.07.03 12:22)
А не путаешь ли ты производительность CPU
и его загруженность ?

← →
Smashich (2003-07-02 13:33) [5]

2 Skier © (02.07.03 13:31)

путает:)

← →
panov (2003-07-02 13:35) [6]

1. Твой вопрос непонятно сформулирован. Лучше напиши, что ты получить хотел.
2. Не приведены куски кода.

Вывод: помочь никто не сможет, если 2 пункта не будут освещены в ветке.

← →
Digitman (2003-07-02 13:39) [7]

> Zergg

> Не ставить же TimeCritical?

именно timecritical, если уж на то пошло.
но это все равно не даст возможности оценить производительность CPU, ибо оценивается она в кол-ве выполненных машинных инструкций за единицу времени. А не Паскаль-операторов. И тем более - не в многозадачной среде на 3-м кольце привелегий. И уж совсем не при разрешенных прерываниях.

← →
Zergg (2003-07-02 13:45) [8]

Куски кода дома!
примерно следующее:

procedure TMyThread.Execute;
begin
while not Treminated do begin
//вычисления с локальными переменными
Syncronize(IncCounter); // типа увеличиваем счетчик
end;
end;

В основной программе:

procedure TMainForm.OnMyTimer...
begin
Label1.Caption:=IntToStr(MyThread.Counter);
MyThread.Counter:=0;
end;

Таймер виндовый, сробатывает 1 раз в секнду.

← →
Zergg (2003-07-02 13:47) [9]

Мнея не интересует теоретическая производительность процессора!
Мне интересна реальная производительность на реальных задачах.
Получается что счетные задачи зависят от положения крсора мыши?!?!?!?!?!?!
Бред!

← →
Radionov Alexey (2003-07-02 13:50) [10]

Мышь обрабатывается. Тебе сообщения про мышь сыпятся. Вот часть времени на них и идет. Когда мышь убежала - ей занимаются другие, если capture не поставил

← →
Radionov Alexey (2003-07-02 13:53) [11]

Либо только в основном потоке с timecritical делай все. Тогда у него не будет времени "на мелочи"

← →
Zergg (2003-07-02 13:54) [12]

Как этого избежать?
Прятать мышь?
Я же речь веду о реальной счетной задаче, которая выполняется в фоне (отдельном потоке).
Пример: На Athlon XP2000+ выполняет ~57000 таких циклов в секунду если курсор находится в окне приложения и ~82000 таких же циклов если курсор переведен на панель задачь Windows...
ИМХО это слишком большая разница для современных процессоров!

← →
Radionov Alexey (2003-07-02 14:07) [13]

Распаралеливать задачу по потокам имеет смысл, если работать оно будет на многопроцессорных системах. Причем рулить процессорами "автоматически" Windows может начиная с линейки NT. Если в потоке нет цикла обработки сообщений, то проблем нет. Если же гложет то, что основной поток растрачивается "на мелочи" - подними приоритет процесса и убавь приоритет основного потока. Просто тормознуть обработку сообщений - некрасиво.

← →
Digitman (2003-07-02 15:05) [14]

> Zergg (02.07.03 13:47)
> Мне интересна реальная производительность на реальных задачах.

В связи с чем ты ее собрался измерять-то ? Я никак не пойму...
И почему ты считаешь, что "производительность" зависит ТОЛЬКО от CPU ?

> Получается что счетные задачи зависят от положения крсора
> мыши?!?!?!?!?!?!
> Бред!

Разумеется, бред.

А позволь полюбопытствовать, не в "Статьях" ли на этом сайте ты взял "печально знаменитый" шаблон-пример использования класса TThread ?

Тогда вопрос к тебе : содрать-то содрал ты его, а вот мыслью не проникся ли насчет того, что и как происходит при вызове метода Synchronize() ?

Я к тому, что строчка

Syncronize(IncCounter); // типа увеличиваем счетчик

могла бы выглядеть и гораздо проще

Inc(IncCounter); // а почему бы и нет ? ведь типа тоже самое, но без непонятных мне фокусов с каким-то Syncronize()

Прокомментируй, коль не трудно)

← →
Zergg (2003-07-02 15:29) [15]

Уважаемый Digitman...
О простите...
ГЛУБОКОуважаемый Digitman...
Попытаюсь так сказать оправдаться... ;-/
У меня возникла идея написать код, который не будет сильно нагружать память, будет только выполнять расчеты и все...
Ужель это нагрузка на память? Или на винт? Мож на дисковод?
Прогу накидал за 30 минут, из интереса...
В статьи не заглядывал...
Легче всего обвинить человека...
Syncronize нужен для того чтобы не получить Access Violation из основного тела программы в асинхронном режиме... Поправь если не прав...
Надеюсь прокоментировал, мне не трудно...
Могу даже исходники выложить, не жалко, они ценности не представляют...
Кстати по скорости операций с памятью тоже есть вопросы...

← →
Smithson (2003-07-02 15:36) [16]

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

← →
Radionov Alexey (2003-07-02 15:40) [17]

>Syncronize нужен для того чтобы не получить
>Access Violation из основного тела программы
>в асинхронном режиме

Если занимаешься визуализацией - то разумно.
Иначе - просто ждешь когда основной поток соизволит занятся твоими проблемами. А оно всегда ли нужно?
Для доступа к общим данным обычно используют критические секции, мьютексы или семафоры. Synhronize - для рисовки.

← →
Digitman (2003-07-02 15:49) [18]

> Syncronize нужен для того чтобы не получить Access Violation
> из основного тела программы в асинхронном режиме

где это написано ? на основании чего такие умозаключения ?

← →
Bel (2003-07-02 15:57) [19]

> Zergg

У тебя увеличение счётчика происходит в контексте основного потока (на это тебя пытался навести Digitman), там же происходит и обработка событий мыши. Они как бы "мешают" друг другу.
Если тебя интересует, сколько и какие события посылает мышка, запусти делфийский WinSight.

← →
Digitman (2003-07-02 15:57) [20]

> Radionov Alexey

в случае с Inc(IntegerValue) даже никаких объектов синхронизации не требуется, ибо в авторском случае inc-инструкция, инкрементирующая блок памяти под сч-к, и mov-инструкция, считывающая сч-к, ни сколь не помешают друг-другу при прерываниях в мультизадачной среде. О DMA не говорим - здесь им тоже не пахнет.

← →
Radionov Alexey (2003-07-02 16:05) [21]

>Digitman © (02.07.03 15:57)
Конечно. Но я кода не видел. Бог его знает где этот "внутренний" счетчик живет и кто до него домагается кроме потока-владельца.

← →
Digitman (2003-07-02 16:14) [22]

> Radionov Alexey © (02.07.03 16:05)
> >Digitman ©

как же не видел ? автор же код привел.. два потока - основной и один дополнительный ... а зачем для его сомнительной задачи более одного дополнительного ?

← →
Radionov Alexey (2003-07-02 16:21) [23]

← →
Romkin (2003-07-02 16:25) [24]

Счетчик, прошу заметить, он еще и обнуляет из основного потока, это во-первых. Во-вторых, какая версия Delphi? Начиная с D6 synchronyze пользуется критической секцией, а не сообщениями

← →
Romkin (2003-07-02 16:27) [25]

В третьих, InterlockedExchangeAdd подходит в любом случае больше, чем synchronize

← →
Digitman (2003-07-02 16:29) [26]

> Romkin

"обнуляет".. а какая разница ?
мое imho - для такой пусть даже и сомнительной задачи обойдется безо всякой синхронизации

← →
mrcat (2003-07-02 16:38) [27]

>Romkin © (02.07.03 16:25)
>Начиная с D6 synchronyze пользуется критической секцией, а не
>сообщениями

случаем, не знаете с чем это связано?

← →
Romkin (2003-07-02 17:07) [28]

С мультиплатформностью. И это гораздо лучше, чем сообщения

← →
Zergg (2003-07-02 17:29) [29]

Мужикиииии!!!
Попробую вечерком без Syncronize.
Да. Правильней обнулять Coutner из потока в котором он инкрементируется. Тож переделаю...
Всем спасиб за идеи...
Завтра чо-нить расскажу!

PS:
Я не ругался с господином Digitman-ом.
Я отвечал в том-же тоне...

← →
Zergg (2003-07-03 12:43) [30]

Господа, всем большое спасибо...
Убрал Syncronize и все работает ОКи.
Еще раз сасиб за коментарии и наставления...

← →
Digitman (2003-07-03 12:56) [31]

> Zergg

для пущей корректности следует сделать так :

function TMainForm.GetCounterAndClearIt: Integer;
asm
sub eax, eax
xchg ecx, MyThread.Counter
end;

procedure TMainForm.OnMyTimer...
begin

Label1.Caption:=IntToStr(GetCounterAndClearIt);

end;

подразумевается, что MyThread - статическая переменная, а не поде класса TMainForm.

← →
Digitman (2003-07-03 12:57) [32]

пардон,

function TMainForm.GetCounterAndClearIt: Integer;
asm
sub eax, eax
xchg eax, MyThread.Counter
end;

Интересные нюансы с производительностью Найти похожие ветки