Память процессора... Как обратиться? Заполнить? Освободить?

[iskander]

Как TaskMeneger считает загруженность процессора

http://www.rsdn.ru/forum/alg/3245020.flat.aspx

[vitaly_l]

http://www.rsdn.ru/forum/alg/3245020.flat.aspx

Если TaskMeneger - работает так как там описано, то существует функция, которая дискретно возвращает значение загружен процессор или нет...

Как такая функция вызывается(называется) (поиск умалчивает)
Однако более правильно будет получить, как предложил vada:
Количество ассемблеровских обращений к процессору или строк... (в процессе исполнения...) Как узнать



.

[iskander]

Виталий, а Вы до конца прочитали?

Т.е. процессор занят, даже если он ничего не делает и ожидает загрузки данных из памяти?

[vitaly_l]

Т.е. процессор занят, даже если он ничего не делает и ожидает загрузки данных из памяти?

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

Тоже самое говорил vada про приоритеты...

Вывод: Можно выставить программе самый высокий приоритет, на момент замеров... и тогда мерить... будет очень точно... если потом поделить на кол-во тактов... А как узнать кол-во тактов??? Ответ замерить за 1 секунду... и потом умножать на время... в ответе будет кол-во потраченных тактов... затем вернуть приоритет обратно...

Однако вопрос об ассемблере остаётся в силе (вдруг кто знает...):
Количество ассемблеровских обращений к процессору или строк... (в процессе исполнения...) Как узнать



.

[iskander]

Вывод: Можно выставить программе самый высокий приоритет,

Система может заглючить.

Ответ замерить за 1 секунду.

Если тактовая частота 2 ГГц, то получим 2*10^9 тактов.
Это то, что вам нужно?

Количество ассемблеровских обращений к процессору или строк

Нет ничего проще. Посмотрите в окне дизассемблера.

[alexey38]

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

Код: Выделить всё

Function GetSystemTimeAsFileTime64():int64;//Получение системного времени в 100 нс. интервалах
Var
   tmp_FTime:TFileTime;
Begin
     GetSystemTimeAsFileTime(tmp_FTime);
     Result:=Int64(tmp_FTime);
End;


Соответчвенно получаем разницу между вдумя вызовами GetSystemTimeAsFileTime64(). Получаете разницу в сотых наносекунды.
Чтобы получить более-менее надежный результат, измеряемый код должен иметь время выполнения примерно 1 милисек. Учитывайте, что GetSystemTimeAsFileTime64() сама требует процессорного времени. Так что сколько будет выполняться 2+2 Вы не узнаете. Нужно эту операцию повторить миллон или миллиард раз, учитывая, что бы оптимизатор компилятора все это не выбросил как излишниый код.

Вы лезете в детяли ремесла. Этим деталя нельзя научиться за 5 минут. Можно быть художником по духу. Но техника нанесения красок определенного типа на холст определенного типа требует умения. Это не просто тяп/ляп. Чтобы оптимизировать нужно знать много. Мало знать не получится. Либо просто делайте несколько вариантов и выбирайте тот, который работает быстрее.

[vitaly_l]

Чтобы оптимизировать нужно знать много.

Я предлагаю GetSystemTimeAsFileTime заменить на QueryPerformanceCounter - это более точно отображает, точнее чем rdtsc...
тогда будет более точный ответ и ничего перемножать не потребуется...

Посмотрите в окне дизассемблера.

Нет... мне нужно именно в процессе выполнения программы... PS: Тактовая частота пр-ра - производителем указывается примерно... Реальную нужно вычислять... а я хочу посмотреть разницу количества выполняемых операций...


Количество ассемблеровских обращений к процессору или строк... (в процессе исполнения...) Как узнать ?
У любого процессора обязательно есть счётчик... Должен быть...



.

Добавлено спустя 10 часов 45 минут 51 секунду:
Re: Память процессора... Как обратиться? Заполнить? Освободить?
УРА!

Художники нашли чёрную кошку в тёмной комнате; и изловили её при помощи валерианки...

В смысле:

Код: Выделить всё

    for i := 0 to 1000000 do arrX[i] := i;
    for i := 0 to 1000000 do arrY[arrX[i]] := Random(arrX[i]);
    for i := 0 to 1000000 do arrZ[arrY[arrX[i]]] := Random(arrX[i]+arrY[arrX[i]]); 


в 7 тестах из 10 работает на 10000 тактов медленнее чем:

Код: Выделить всё

  for i := 0 to 1000000 do arrX[i] := i;
  for i := 0 to 1000000 do
      begin
        x := arrX[i];
        arrY[x] := Random(x);
      end;
  for i := 0 to 1000000 do
      begin
        x := arrX[i];
        y := arrY[x];
        arrZ[y] := Random(x+y);
      end; 


Это 0,0040959031138694 секунды... если умножить на 24, то получится уже 0,0983016747328652, а если на 30(NTFS), то медленнее на 0,122877093416082 секунд в секунду... Согласитесь: 0,123 секунды в секунду - весьма ощутимая цифра, для оптимизации.

ВСЕМ СПАСИБО!

[vada]

vitaly_lФигней маетесь Какой прикладной смысл ваших изысканий?
Или для художника главное процесс а ни его результат

[vitaly_l]

Какой прикладной смысл ваших изысканий?

Если рендер повторяется 30 раз в секунду, то 0,123 секунды, на такую простую операцию - это гипер много... т.к. 10 таких операций приведут к сокращению fps с 30 до 25, а то и меньше... А если там: умножение и деление - добавить... то...

Так что - знание таких мелочей, равноценно знанию по удалению неиспользуемых в цикле переменных из цикла. Рано или поздно сталкнётесь с быстродействием, вспомните про художников добрым словом...

PS: Потом, мы умеем готовить чёрных кошек на http.GET... просто мы их готовим иначе чем программисты



.

[Sergei I. Gorelkin]

Экономия в десять тысяч тактов при количестве итераций цикла миллион?
Если бы ты сэкономил хотя бы один такт в цикле, разница была бы в этот самый миллион. А десять тысяч являются как раз погрешностью измерения.

Примененный прием называется "устранение общих подвыражений" (CSE - common subexpression elimination), когда одинаковые части выражения выделяются и помещаются в отдельные переменные. Это действительно способствует ускорению выполнения. Только фишка в том, что компилятор умеет делать это сам.

[vitaly_l]

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

Нет - это не погрешность... Возможно это не 10000 тактов, а "некое время"... Однако в описании функции говорят что это таты... Но это уже не имеет значения т.к. разница постоянная, даже если менять варианты местами... а погрешность действительно бывает, примерно в 3-х из 10 попытках...

Только фишка в том, что компилятор умеет делать это сам.

Я разве сказал, что он не умеет это делать??? Я сказал, что есть разница во времени исполнения и она равна 0,0040959031138694 секунды за 1000000*3 указанных в примере итераций... Судя по всему: компилятор - это делает иначе и получается дольше...


PS: Спасибо за CSE - common subexpression elimination, более подробно: http://www.hardline.ru/1/5/875/


.

[SAK]

    for i := 0 to 1000000 do arrZ[arrY[arrX[i]]] := Random(arrX[i]+arrY[arrX[i]]); 

в 7 тестах из 10 работает на 10000 тактов медленнее

И неужели не видно повторного обращения к одним и тем же ячейкам arrX и arrY? Вот во втором примере это повторное обращение убирается, отсюда и выигрыш в несколько тактов. Открытия неизведанного не заметил и так всё очевидно.

[vitaly_l]

Открытия неизведанного не заметил и так всё очевидно.

Возможно для Вас всё очевидно, я же изначально задавался этим вопросом, т.к. для меня:
между x и arrX[arrX[arrX[i] ] ] - разницы не было, я раньше думал берётся адрес из памяти и всё, поэтому и спрашивал...


PS: зато шишек насобирал... все мои...


.

[alexey38]

Я предлагаю GetSystemTimeAsFileTime заменить на QueryPerformanceCounter - это более точно отображает, точнее чем rdtsc...
тогда будет более точный ответ и ничего перемножать не потребуется...

http://www.devdoc.ru/index.php/content/view/queryPerformanceCounter.htm

Добавлено спустя 7 минут 25 секунд:
Re: Память процессора... Как обратиться? Заполнить? Освободить?
Те крохи которые Вам удалось соптимизировать - это мелочь. Ради нее стоит гнаться только если другие средства исчерпаны.

В реальных задачах веачале перебираются методы решения задачи. Например, в матричной математике есть такое понятие как разряженные матрицы. Есть нужна сортировка, то ее можно сделать разными методами, в зависимости от вида данных. Для поиска строк есть хэши. Для рендеринга можно использовать ресурсы видеокарты. И т.п.
Применение разных методов может ускорить выполнение задач в десятки, сотни, тысячи или даже миллионы раз.

Вы же сразу ухватились за выигрышь в 10%.

[vitaly_l]

http://www.devdoc.ru/index.php/content/view/queryPerformanceCounter.htm

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

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

Я учусь... Безусловно я как программист слабее любого т.к. я изначально художник, а у художников более развиты иные навыки... Например: Математика для меня не самый сложный, но к сожалению давно забытый навык, а некоторые уравнения я просто не могу идентифицировать, т.к. не знаю как их читать... Например изучил: преобразование Фурье - любезно предоставленное добрым GrayEddy на первой странице топика... То что написано в коде я понимаю... а математические формулы - нет... Безусловно - я знаю меньше программистов, однако, постепенно (по мере необходимости) - узнаю нужные мне ресурсы... Например теперь я, из интереса, идентифицирую понятия: "хэши для поиска строк", "разряженные матрицы", и особенно "ресурсы видеокарты" - раз они могут увеличить быстродействие...

Те крохи которые Вам удалось соптимизировать - это мелочь. Ради нее стоит гнаться только если другие средства исчерпаны.

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

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

Для этого я и завёл этот топик... В надежде, что программисты поделятся секретами великой магии по превращению клацания по клавишам в произведения программного искусства...

Изучаю предложенную добрым kipar, книгу "Совершенный Код"- ужасно много воды... При этом автор книги, действительно много знает: и о метафорах, и о майевтических машинах, и о методологии; но в книге(пока что) он делится с читателем - лишь результатами этих наук, а не самими науками..., которые он использует... А о программировании пока говорит мало(меньше чем программисты дали в данном топике)... Уже 1/4 книги прочёл... PS: Я очень жёсткий и неблагодарный читатель: "да-простят меня - все писатели"...



.