Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Jul 20, 2019 11:05 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 76 posts ]  Go to page Previous 1 2 3 4 5 6 Next
Author Message
PostPosted: Sun Oct 02, 2011 9:41 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Итак, результаты эксперимента.
QEMU:
В самых жестких условиях алгоритм Марата справлялся за 3-7 сотых долей секунды. Как я понимаю, он не использует FPU. Моя тестовая программа на Си давала такой же результат за 1-8 сотых долей секунды.
eduBook: алгоритм Марата отрабатывает за 2-3 сотые доли секунды. Моя программа на Си - за 1-2.

p.s. Чуть не забыл. Скомпилированный бинарник без сжатия занимает 13308 байт (со сжатием 6822 байта).
Время на разработку точных аналогов - около четырех часов чистого времени.


Top
   
PostPosted: Sun Oct 02, 2011 10:09 pm 
Хотелось бы иметь бинарник, чтобы посмотреть и сравнивать самому. К тому же я не оптимизировал максимально по скорости, так что еще есть чем меряться. :lol:
Еще хотелось бы заметить, что в моем варианте в замер включено выделение памяти под буфер, и таки да никакого FPU в принципе не использовано.


Top
   
PostPosted: Mon Oct 03, 2011 1:35 am 
SoUrcerer
Я не знаю условий замеров, которые ты проводил на eduBook, но вот что получилось у меня:
1) eBox
Spoiler: Show
eBox.png

2) Roverbook U800 (500 МГц, частота даже ниже eBox)
Spoiler: Show
rb_u800.png


Значений выше чем 1 - 0 - 1, я не наблюдал

cs_1 - это оригинальный файл, который я выкладывал
cs_2 - попытка некоторой оптимизации, но из-за грубости инструмента замера (1/100 секунды) разница не заметна.


Top
   
PostPosted: Mon Oct 03, 2011 7:31 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Чтобы грубости замера были заметны не так сильно, я в обоих программах вызываю процедуру отрисовки 100 раз. Бинарник сейчас выложу. Динамическое выделение памяти добавлю, и выложу.

upd: сравнил точнее. Мой алгоритм более грубый, поддерживает определение высоты лишь с точностью 6px. :(


Top
   
PostPosted: Mon Oct 03, 2011 1:36 pm 
Offline
Just Flooding

Joined: Sat Jan 06, 2007 2:30 pm
Posts: 269
Меряйтесь с помощью rdtsc, точнее некуда будет, правда, для этого надо чтобы код выполнялся менее 1/100 сек, а то переключение задач наложит свой отпечаток. Под qemu меряться неинтересно, опять же, ибо его бинарная трансляция наложит ещё немалый отпечаток и перекорёжит весь код. Так что реальное железо или bochs.
А fpu тут как раз не нужен, ибо fixed-point math рулит в таких задачах. Другое дело - использовать всякие SIMD инструкции, но и их лучше как fixed-point (т.е. с integer операндами), а не floating point использовать.


Top
   
PostPosted: Mon Oct 03, 2011 2:01 pm 
Сомневаюсь что rdtsc спасет, нужно универсальное показание относящееся именно к этому потоку приложения, чтобы исключить влияние других задач - мы же не в однозадачной среде.


Top
   
PostPosted: Mon Oct 03, 2011 3:16 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Открывает core/taskman.inc, находим строку
Code:
       mov [ebx+REG_EFLAGS], dword EFL_IOPL1+EFL_IF
меняем EFL_IOPL1 на EFL_IOPL3, компилируем ядро, правим измеряемый код:
Code:
cli
xor eax, eax
cpuid
rdtsc

измеряемый код

xor eax, eax
cpuid
rdtsc
sti


Top
   
PostPosted: Mon Oct 03, 2011 3:24 pm 
А можно подробнее (специально для таких деревенских лузеров типо меня) что при этом изменяется в обработке rdtsc на уровне ядра? И как будет функционировать кофемолка если два потока вызовут rdtsc.


Top
   
PostPosted: Mon Oct 03, 2011 3:30 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Там cli стоит, двух потоков не будет. Маскируем прерывания в приложении и считаем чистые такты. cpuid нужно чтобы синхронизировать конвеер, чтобы rdtsc правильно записал такты.
EFL_IOPL3 нужно чтобы cli в приложении не привело к general protection fault.


Top
   
PostPosted: Mon Oct 03, 2011 3:42 pm 
Спасибо сейчас допер, но ведь получается в таком случае это как-бы реалтайм и можно такой финт ушами использовать для специфических задач, например когда нужно непрерывно обрабатывать критический код на уровне ядра, на протяжении короткого промежутка времени.


Top
   
PostPosted: Mon Oct 03, 2011 4:00 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario
Это нехороший финт ушами. Для замеров чистых тактов самое то, а в общем ставит защищённость системы на уровень MS-DOS.


Top
   
PostPosted: Mon Oct 03, 2011 4:03 pm 
Так ведь я не говорю это про trunk ядро. Я это применительно к специфическим задачам которые можно решать с измененным и перекомпилированным ядром. К примеру, art_zh очень любит реал-тайм и в его задачах такое может потребоваться.


Top
   
PostPosted: Mon Oct 03, 2011 7:33 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Nable, доставляющее обсуждение предварительных результатов эксперимента - в чате.


Top
   
PostPosted: Mon Oct 03, 2011 7:34 pm 
Offline
Just Flooding

Joined: Sat Jan 06, 2007 2:30 pm
Posts: 269
На тему "мы не в однозадачной системе" я как раз и сказал о том что надо тогда чтобы код выполнялся не длиннее, чем квант времени у планировщика. Тогда если время намеряли длиннее, то сразу понятно что попали на переключение и надо мерять ещё раз. В винде таким образом прекрасно получается мерять время различных участков кода. Да и в никсах получается, хотя лично не пробовал.
to Serge Можно, пожалуйста, глупый вопрос? Для чего нужно вызывать cpuid(0) после cli и перед sti?


Top
   
PostPosted: Mon Oct 03, 2011 7:34 pm 
Имхается мне полного счастья надо, чтобы у каждого процесса свой счетчик времени по rdtsc велся, но кажется это ляжет тяжким бременем на производительность системы.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 76 posts ]  Go to page Previous 1 2 3 4 5 6 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited