Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вт ноя 21, 2017 4:26 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 14 сообщений ] 
Автор Сообщение
 Заголовок сообщения: Func tester
СообщениеДобавлено: Ср авг 03, 2005 10:17 pm 
Программа тестирования скорости выполнения заднного кода.
Тестирует как системный функции так и все остальное, наглядные результаты:
1. количество проходов. Для объективности код проганяется заданное количетсво раз, все результаты сохраняются и
2. выводятся данные тактов для каждого прохода
3. размер тестируемого кода. Определяется тоже автоматически
Все настройки в исходнике, который пока выкладывать небуду потому что мне интересны ваши идеи, что еще можно сделать.

В собарнном варианте тестируется функция 48 перерисовки фона.
У меня сразу возникла мысль. нужно везде в описаниях системных функций написать что либо все блокирующие либо какие-то такие другие сякие...
http://meos.ru/files/software/system/FuncTest.7z


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 04, 2005 9:03 am 
1. Можно считать как такты, так и время.
2. Для коротких процедур можно учитывать переключение задач (если счетчик тиков не изменился, то переключения задач не было, а по частоте возникновения таких ситуаций расчитывать среднее время выполнения короткой процедуры). Но это достаточно сложный подход.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 04, 2005 11:18 am 
Проблема правильного подсчета времени выполнения заданного кода лежит как раз в переключениях контекстов.

Счетчик тиков может изменится без переключения контекста на пару тиков благодаря суперскалярной архитектуре, поэтому чтобы проверить переключался ли контекст нужно задать число тиков которые бы говорило: тиков прошло больше чем указано, да было переключение, тиков прошло меньше - переключения небыло.
Поэтому для того чтобы посчитать среднее время переполнения процедуры нужно учесть
1. overhead пустой проверки, присутсвует только код сохранения параметров.
2. "чистый" (без вычетов) o. заданного кода
3. как реализовать проверку переключения контекста я непонимаю. Скорее всего это даже невозможно в силу того что процессор по разному рабоатет с одинм и тем же кодом, я считаю что проверять "уход" tsс неправильно, посколько он может сильно менятся и без переключения контекста. Может быть добавить в планировщик функцию которая бы инкрементировала бы счетчик переключений контекста? Т.е. Мы вызываем эту функцию и говорим ядру - нам нужно чтобы для этой программы работал счетчик переключений конеткста, ответ - 1 в случае согласия. И тогда мы можем проверять начальное положение счетчика переключений контекста, т.е. проверки будут на границах тестируемого кода.(конечное значение счетчика CSC (-con text swwitch counter) должно считатся после последнего rdtsc). В случае инкрементирования значения повторяем тест пока переключений небудет.
Пусть в данном вызове будет параметр куда (?) сохранять счетчик. Это обязательно должен быть регистр, чтобы планировщик не терял время на обращение к памяти тормазя при этом все процессы. Если будет функция с указанием регистра то мы можем вставить допустим тот же алгаритм с учетом того что регситр такой-то изменять категорически нельзя, т.е. при переключении быдует просто команда inc [r16/32]-(для контекста нашего патока) тем самым производительность системы практически не изменится.
Все сумбурно, но мысль вроде изложил.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 04, 2005 6:28 pm 
Цитата:
Счетчик тиков может изменится без переключения контекста ...

Это как? Счетчик ([timer_ticks]) изменяется только в процедурах irq0 и change_task. irq0 всегда увеличивает его на 1, а change_task уменьшает его на 1 перед прямым вызовом irq0. Поэтому его значение никак не может изменится в обход переключения процессов. А multithreading MenuetOS не поддерживает. Счетчик тиков может не изменится при переключении процессов только при вызове функций задежки, ожидания событий, создания потоков/процессов, завершения процессов, и, возможно, обращения к файлам (код работы с файлами я еще не изучал, поэтому не знаю) - больше строка change_task нигде не встречается.
Цитата:
планировщик не терял время на обращение к памяти тормазя при этом все процессы

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

У планировщика свой набор регистров (по крайней мере пока он вызывается через шлюз вызова) и чтобы изменить регистр программы ему нужно лезть в память для изменения ее сегмента tss, в котором все эти регистры сохранены. Учитывая, что размер tss программы не степень двойки...
Проще всего сделать просто счетчик переключений, всегда увеличивающийся на 1 при вызове irq0. Осталось выбрать номер функции и подфункции для получения доступа к нему. ;)
Кстати, ядро сообщает о количестве тиков, потраченных программой (эту информацию выводит, например, cpu) - это можно использовать.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Пт авг 05, 2005 4:27 pm 
Нашел вот это творение http://os-menuet.narod.ru/cor_task.htm
Но требуется подробное объяснение.

Цитата:
Это как?

Это параллельное выполнение инстркций.

Цитата:
Счетчик ([timer_ticks]) изменяется только в процедурах irq0 и change_task. irq0 всегда увеличивает его на 1, а change_task уменьшает его на 1 перед прямым вызовом irq0. Поэтому его значение никак не может изменится в обход переключения процессов.

Ты, насколько я понял, говоришь о программируемом таймере который выставлен на 100 Гц. А я говорю про счетчик tsc, счетчик количества выполненных инструкций процессором.

Цитата:
А multithreading MenuetOS не поддерживает.

Так получается что планировщик переключает только процессы? Сомнительно. Я почему-то думаю что потоки.

Если я напишу delay,0 произойдет ли task_switch?

Цитата:
Проще всего сделать просто счетчик переключений, всегда увеличивающийся на 1 при вызове irq0. Осталось выбрать номер функции и подфункции для получения доступа к нему

Я и имел ввиду общее число переключений. Только как его реализовать я пока незнаю. но буду думать\пробовать. Например куда его писать в памяти, ведь сейчас много зарезервированных областей насколько я понимаю.

Цитата:
это можно использовать.

посматрю, подумаю


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Пт авг 05, 2005 9:29 pm 
Цитата:
Так получается что планировщик переключает только процессы? Сомнительно. Я почему-то думаю что потоки

Я ошибся, имелся в виду hyperthreading. Параллельно могут выполняться без hyperthreading'а только несколько последовательных команд.
Цитата:
Только как его реализовать я пока незнаю. но буду думать\пробовать.

Это очень просто. Объясняю по шагам.
1. Выбираем место, где-нибудь перед или после irq0 (shed.inc).
2. Пишем:
Код:
iglobal
  context_switch dd 0
endg

Мы объявили глобальную переменную в ядре.
3. В обработчике irq0 вставляем команду inc [context_switch] (например перед jmp irq0)
4. Теперь нужно добавить системную функцию. Пусть это будет функция 68, подфункция 0 (для примера).
5. Открываем файл syscall.inc и добавляем туда новый обработчик: dd sys_contextswitch после dd sys_window_move. (если используешь существующий номер, но в этой таблице ищешь адрес существующего обработчика и немного изменяешь его код)
6. В каком-нибудь файле пишем:
Код:
sys_contextswitch:
cmp eax,0 ;проверка номера подфункции
jnz   .not_supported
mov eax,[context_switch]  ;вот и все тело нашей функции
mov  [esp+36],eax ;возврат результата программе из обработчика системного вызова.
;программа получит результат в eax.
.not_supported:
ret


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Сб авг 06, 2005 2:27 pm 
Цитата:
Я ошибся, имелся в виду hyperthreading. Параллельно могут выполняться без hyperthreading'а только несколько последовательных команд.

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


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Вс авг 07, 2005 10:40 am 
Есть синхронизирующие команды - cpuid например. Они гарантируют, что к моменту их выполнения все предыдующие команды будут считаны.
Забыл ответить на вопрос:
Цитата:
Если я напишу delay,0 произойдет ли task_switch?

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


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Вс авг 07, 2005 10:53 am 
А какие системные функции блокирующие неблокирующие? Или все блокирующие?


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Пт авг 12, 2005 6:32 pm 
Дописываю прогу осталось только разобратся с двумя багами.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Сб авг 13, 2005 4:40 pm 
По идее, все системные функции не блокирующие. Но функции создания процесса, потока и перераспределения памяти блокируют переключение задач (командой cli) почти все время. Может еще есть функции надолго блокирующее переключение задач - я код всех функций менуета еще не изучил :)


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Сб авг 13, 2005 4:49 pm 
Не в сети
Site Founder
Аватара пользователя

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 689
Все функции в моём видеодрайвере обрамлены CLI/STI. Сейчас посмотрю, насколько это необходимо. Естественно, что без них работать будет быстрее, однако могут появиться глюки в отрисовке.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб авг 13, 2005 6:42 pm 
ПОЭТОМУ предлагаю вынести как отдельный проект строго стандартизированную документацию по ядру, функциям и прочему.
http://forum.meos.ru/index.php?t=15


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Сб авг 13, 2005 10:30 pm 
Предлагаю следующую схему: в начале выкладывается предварительный вариант (по странице на каждую функцию). Затем, по мере обнаружения не точностей те, кто их обнаружил, посылают новую версию документации к этой функции тебе на мыло. А тебе остается проверять разумность изменений и выкладывать на сервере. Так же разумно держать архив, в котором находится документация ко всем функциям - для тех, кто хочет скачать все сразу.


Вернуться к началу
   
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 14 сообщений ] 

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB