Board.KolibriOS.org

KCEOH
Какие-то очень странные цифры для FPS...
У меня на компе (1.2 ГГц): для cubeline:
Kolibri: 164-168
98: 163-172
XP без ускорителя: 69-73
XP с ускорителем: 72-75
kiwntf ускоряет системные вызовы. Поскольку существенного повышения скорости после запуска kiwntf не наблюдается, скорее всего, на собственно вывод расходуется довольно мало времени. Для сравнения: для trantest из K0600 после запуска ускорителя FPS подскакивает с ~8800 до ~18600.
P.S. Сравнивать полноэкранный FPS некорректно, поскольку в Колибри я работаю со стандартным разрешением 800*600, а в Windows - 1024*768.

_________________
Ушёл к умным, знающим и культурным людям.

У меня в Колибри FPS в 2 раза больше,чем в XP при аппаратном ускорении.

При использовании VC++2005 результат, я думаю, будет ещё лучше, т.к. в 2005-ом компилятор оптимизирует заметно агрессивнее, чем в 2003-ем.

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

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


Согласен с тобой на 100%.Программируя на ассемблере мы сразу "убиваем двух зайцев".Тоесть максимально упрощаем алгоритм(сокращается колическтво промежуточных команд) и заменяем переменные регистрами,ускоряя вычисления.Ну и как результат - получаем быстрый код.

К примеру я сравнивал мой код,производящий нормирование вкектора, и код макгаба(вродебы так читается ник нашего польского товарища ?).Разница между моим кодом и его была всего в 2 командах,которые повторялись 3 раза(для каждой координаты).И его код и мой написаны на ассемблере.Но мой 1.6 раза быстрее.

Измерение скорости при помощи RDTSC помогает понять какие команды работают быстрее,а какие медленнее.Это помогает написать алгоритм с наибольшим возможным быстродействием.

Звучит как слова из рекламы... Алгоритмическая оптимизация не есть сокращение количества промежуточным команд. Сокращение комнанд это скорее оптимизация по размеру и возможно по скорости

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

Виктор,ты думаеш,что я незнаю что такое алгоримическая оптимизация ?
Геометрические примитимвы можно нарисовать по разному,но алгоритмы Брезенхема самые быстрые.Алгоритмы брезенхема являются примером алгоритмической оптимизации.


>Настоящая оптимизация возможна только под конкретный процессор.

Согласен.Я как то читал статью для AMD-шных процессоров,где были реализованы алгоритмы быстрого копирования.Когда я стал их проверять на своём celeron2000 ,то эти алгоримы(MMX копирования) приводили только к ухудшению скорости.Все алгоритмы обогнала стандартная rep movsd.

andrew_programmer
Не знаю знаешь ты или не знаешь ) , но слова как то меня задели..

andrew_programmer
Интересно. Интел тоже рекомендует MMX или SSE для быстрого копирования но они дают хороший результат если данные выравнены на 8 или 16 (для SSE) байт и еще объём копируемых данных должен быть больше килобайта. Вообще в Pentium 4 есть быстрое копирование строк если источник и приёмник выравнены на 16 байт. Данные копируются сразу строками кеша.

И пропал...

_________________

Привет . Приношу свои извинения за столь долгое отсутствие . Выложил все тут.

заставляю view3ds открыть 2меговый файл под эмулятором) пока жду реакции =)

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

все жду) эмуль зохавал 50% проца..

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

и 6мб оперативки..

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!