Mario79 - Спасибо за замечания.
1) Подпись сделаю - забыл, но я думаю что это не проблема
2) Я не знаю что быстрее выполняется прорисовка прямоугольника или линии. Может прорисовка точки ? Как ты сам знаешь документации нет. Вот и приходится экспериментировать. Я с завтрашнего дня хотел занятся этим вопросом т.е. нарисовать рамку с помощью линий и проверить что быстрее. Ты меня укрепил в этом решении.
Я только положительно отношусь к замечаниям - для меня это профессиональный рост.
Хочу сказать - если вы заметили ошибку или у вас есть метод или алгоритм, код, который позволит улучшить данную статью - поделитесь!
Эффективное программирование в KOLIBRI OS
Спасибо всем кто мне помог в написании статьи советами предложениями и критикой! Без вас всех ее бы просто не было! Статья более чем завершена, но все же продолжает быть в разработке и нуждается в ваших коментариях и предложениях. Адрес ее размещения прежний - добавил метод рисования прямыми - этот метод более оптимальный.
http://www.test-kolibri.narod.ru/d/less1.7z
http://www.test-kolibri.narod.ru/d/less1.7z
<Lrz>
Вот теперь статья будет более востребована.
Теперь можно писать исследование на тему: Рисование круга различными методами.
Дальше можно будет расширить тему: Рисование круга с заполнением.
Есть еще две смежные темы: Рисование многоугольников и оно же с заполнением.
В принципе круг это и есть многоугольник. И его можно рисовать различными методами: точками и прямыми.
Причем прямыми опять таки быстрей. А количество опорных точек при рисовании можно вычислять как квадратный корень от радиуса. Так вообще быстро рисуется, но получается малость коряво.
А вот с заполнением сложней, этим вопросом я не занимался.
Вот теперь статья будет более востребована.
Теперь можно писать исследование на тему: Рисование круга различными методами.
Дальше можно будет расширить тему: Рисование круга с заполнением.
Есть еще две смежные темы: Рисование многоугольников и оно же с заполнением.
В принципе круг это и есть многоугольник. И его можно рисовать различными методами: точками и прямыми.
Причем прямыми опять таки быстрей. А количество опорных точек при рисовании можно вычислять как квадратный корень от радиуса. Так вообще быстро рисуется, но получается малость коряво.
А вот с заполнением сложней, этим вопросом я не занимался.
Круг - кривая второго порядка и рисуется соотвествующими методами (алгоритм Брезенхема). Круг с заполнением рисовать еще легче - поскольку доля вычислений по сравнению с рисованием уменьшается и можно использовать менее эффективные алгоритмы (для вычислений).
Немного переделал компонент от Maxxxx32 CheckBox описания пока нет, но уже доступен для скачивания
http://www.test-kolibri.narod.ru/docs.html.
Теперь при проверке и рисования чекера, нет вычисления длины символов надписи. Это значительно экономит процессорное время. Работа еще на закончена, планируются дальнейшее совершенствование.
http://www.test-kolibri.narod.ru/docs.html.
Теперь при проверке и рисования чекера, нет вычисления длины символов надписи. Это значительно экономит процессорное время. Работа еще на закончена, планируются дальнейшее совершенствование.
Немного переделал компонент от Maxxxx32 Editbox, произведена оптимизация. Доступен для скачивания пример http://www.test-kolibri.narod.ru/d/EDITBOX.7z
Кстати про оптимизацию.
1. Я твёрдо убеждён, что команды
исполняются медленнее, чем банальный mov. В то время как и этот код, и mov занимают 5 байт. Уж если оптимизировать, то надо писать
(как это делается в стандартном macros.inc).
Или, если есть уверенность, что на момент вызова некоторой сисфункции eax=0,
то можно писать
- это ещё на байт короче и несколько быстрее.
2. В коде компонентов активно используется 16-битная арифметика. Но 16-битный код в 32-битном режиме больше на байт и медленнее на такт. Почему бы не использовать 32-битные параметры в макросе? Да, при этом несколько увеличивается область данных, но это с избытком окупается размером и скоростью кода.
3. Ещё раз повторяю, что
длиннее и медленнее, чем
1. Я твёрдо убеждён, что команды
Code: Select all
xor eax,eax
add eax,12
Code: Select all
push 12
pop eax
Или, если есть уверенность, что на момент вызова некоторой сисфункции eax=0,
то можно писать
Code: Select all
mov al,12
2. В коде компонентов активно используется 16-битная арифметика. Но 16-битный код в 32-битном режиме больше на байт и медленнее на такт. Почему бы не использовать 32-битные параметры в макросе? Да, при этом несколько увеличивается область данных, но это с избытком окупается размером и скоростью кода.
3. Ещё раз повторяю, что
Code: Select all
bt word [a], 1
jc @f
Code: Select all
test byte [a], 1
jnz @f
diamond На счет push и pop
Согласно справочнику Юрова по Ассемблеру (стр 476)
------------
push r16/32 - занимает 3 микрооперации.
pop r16/32 - занимает 2 микрооперации.
-------------
команада xor -занимает 1 микрооперацию
mov r16/32,i16/32 - 2 микрооперации
add r16/32,i16/32 - 1 микрооперация.
Производить оптимизацию следует только для микропроцессоров Pentium Pro/II/III/IV
Учитывая особенности конвейеров данных процессоров, то для достижения наибольшей производительности необходимо подавать команды, декодируемые в микрооперации в последовательности 4+1+1.
Мы не можем сказать в какой последовательности попадут в конвейер команды, следовательно их нужно сделать такими, что бы попав туда они максимально быстро выполнились. Мой вариант более универсален, т.к. в любом случае в коде
------------
xor eax,eax
add eax,12
------------
не будет задержке в конвейере. То что ты предлагаешь, короче, но и выполняться он будет дольше. С командой mov почти та же история, тут как повезет.
Согласно справочнику Юрова по Ассемблеру (стр 476)
------------
push r16/32 - занимает 3 микрооперации.
pop r16/32 - занимает 2 микрооперации.
-------------
команада xor -занимает 1 микрооперацию
mov r16/32,i16/32 - 2 микрооперации
add r16/32,i16/32 - 1 микрооперация.
Производить оптимизацию следует только для микропроцессоров Pentium Pro/II/III/IV
Учитывая особенности конвейеров данных процессоров, то для достижения наибольшей производительности необходимо подавать команды, декодируемые в микрооперации в последовательности 4+1+1.
Мы не можем сказать в какой последовательности попадут в конвейер команды, следовательно их нужно сделать такими, что бы попав туда они максимально быстро выполнились. Мой вариант более универсален, т.к. в любом случае в коде
------------
xor eax,eax
add eax,12
------------
не будет задержке в конвейере. То что ты предлагаешь, короче, но и выполняться он будет дольше. С командой mov почти та же история, тут как повезет.
Смысл оптимизации по скорости есть только в циклах, где код выполняется сотни и тысячи раз. В остальных случаях это только делает код неудобочитаемым. Смысла оптимизации по размеру команд тоже нет, если нет цели запихнуть всё на одну дискету
Иван Поддубный - пожалуй ты прав, как говориться на современных процессорах +/- 100 тактов погоду не сделает
В общем выбирать программистам, но я думаю что люди смогут понять что написано.
В общем выбирать программистам, но я думаю что люди смогут понять что написано.
<Lrz>
Не следует путать скорость декодирования и скорость исполнения команд. По скорости декодирования - всё, как ты сказал. По скорости исполнения - команда mov имеет гораздо более простую логику и вроде бы исполняется быстрее (извините, соответствующих таблиц под рукой нет), чем имеющие сложную логику xor и add. Причём время работы в основном определяется именно скоростью выполнения. Юров приводит только таблицу скорости декодирования.
Код, оптимальный по скорости на одном процессоре, запросто может оказаться хуже неоптимизированного варианта на другом. Код, оптимальный по размеру на одном процессоре, остаётся оптимальным по размеру на любом совместимом на уровне команд процессоре.
P.S. А вообще в технике оптимизации по скорости на современных процессорах чёрт ногу сломит. Кстати, рекомендую почитать книгу Криса Касперски
http://kpnc.opennet.ru/0.zip
http://kpnc.opennet.ru/1.zip
http://kpnc.opennet.ru/2.zip
http://kpnc.opennet.ru/3.zip
- очень интересные вещи пишет, хотя и не совсем на обсуждаемую тему.
Не следует путать скорость декодирования и скорость исполнения команд. По скорости декодирования - всё, как ты сказал. По скорости исполнения - команда mov имеет гораздо более простую логику и вроде бы исполняется быстрее (извините, соответствующих таблиц под рукой нет), чем имеющие сложную логику xor и add. Причём время работы в основном определяется именно скоростью выполнения. Юров приводит только таблицу скорости декодирования.
Код, оптимальный по скорости на одном процессоре, запросто может оказаться хуже неоптимизированного варианта на другом. Код, оптимальный по размеру на одном процессоре, остаётся оптимальным по размеру на любом совместимом на уровне команд процессоре.
P.S. А вообще в технике оптимизации по скорости на современных процессорах чёрт ногу сломит. Кстати, рекомендую почитать книгу Криса Касперски
http://kpnc.opennet.ru/0.zip
http://kpnc.opennet.ru/1.zip
http://kpnc.opennet.ru/2.zip
http://kpnc.opennet.ru/3.zip
- очень интересные вещи пишет, хотя и не совсем на обсуждаемую тему.
diamond - спасибо за замечания к статье, я их учел и исправил. Частично удалось отказаться от 16 битной арифметики. Спасибо за книжку.
Переписал компонент editbox пока демо версия добавил insert
скачать можно тут http://lrz.land.ru/
скачать можно тут http://lrz.land.ru/
Обновил компонент + добавил выделение по shift. Версия текущая, рабочая. Скачать можно с сайта указаного выше.
Обновил компонент теперь ведет себя как виндовый editbox. Скачать можно с svn или с http://lrz.land.ru/
Who is online
Users browsing this forum: No registered users and 0 guests