Board.KolibriOS.org

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

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

Хотелось бы иметь бинарник, чтобы посмотреть и сравнивать самому. К тому же я не оптимизировал максимально по скорости, так что еще есть чем меряться.
Еще хотелось бы заметить, что в моем варианте в замер включено выделение памяти под буфер, и таки да никакого FPU в принципе не использовано.

SoUrcerer
Я не знаю условий замеров, которые ты проводил на eduBook, но вот что получилось у меня:
1) eBox

Spoiler:

eBox.png

2) Roverbook U800 (500 МГц, частота даже ниже eBox)

Spoiler:

rb_u800.png

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

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

Чтобы грубости замера были заметны не так сильно, я в обоих программах вызываю процедуру отрисовки 100 раз. Бинарник сейчас выложу. Динамическое выделение памяти добавлю, и выложу.

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

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

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

Открывает core/taskman.inc, находим строку меняем EFL_IOPL1 на EFL_IOPL3, компилируем ядро, правим измеряемый код:

А можно подробнее (специально для таких деревенских лузеров типо меня) что при этом изменяется в обработке rdtsc на уровне ядра? И как будет функционировать кофемолка если два потока вызовут rdtsc.

Там cli стоит, двух потоков не будет. Маскируем прерывания в приложении и считаем чистые такты. cpuid нужно чтобы синхронизировать конвеер, чтобы rdtsc правильно записал такты.
EFL_IOPL3 нужно чтобы cli в приложении не привело к general protection fault.

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

Mario
Это нехороший финт ушами. Для замеров чистых тактов самое то, а в общем ставит защищённость системы на уровень MS-DOS.

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

Nable, доставляющее обсуждение предварительных результатов эксперимента - в чате.

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

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