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.
TinyGL
-
Ушёл к умным, знающим и культурным людям.
У меня в Колибри FPS в 2 раза больше,чем в XP при аппаратном ускорении.
При использовании VC++2005 результат, я думаю, будет ещё лучше, т.к. в 2005-ом компилятор оптимизирует заметно агрессивнее, чем в 2003-ем.iadn wrote:TinyGL написана на Cи для GCC. Для сборки библиотеки и компиляции примеров использовались для сравнения два компилятора GCC и VC++ 2003.
В результате Cubeline
GCC 59Kb 297 fps
VC++ 2003 37Kb 398 fps
Главное, всегда помнить, что эффект от алгоритмической оптимизации заметно выше, чем от тупого "переписывания на ассемблере".andrew_programmer wrote: Я незнаю,что за НЕУЧ составлял эту статистику.Элементарное измерение скорости кода при помощи комагды RDTSC,которая позволяет измерять скорость кода в тактах(я всегда измеряю скорость ей),показывает,что ассемблерный код быстрее от 10%(но не как не 2%) и выше.Реально это выше может достигать 5000%
НЕ ДОВЕРЯЙТЕ НЕУЧАМ ! Они ВСЕГДА ерунду пишут.
>Главное, всегда помнить, что эффект от алгоритмической оптимизации заметно выше, чем от тупого "переписывания на ассемблере".
Согласен с тобой на 100%.Программируя на ассемблере мы сразу "убиваем двух зайцев".Тоесть максимально упрощаем алгоритм(сокращается колическтво промежуточных команд) и заменяем переменные регистрами,ускоряя вычисления.Ну и как результат - получаем быстрый код.
К примеру я сравнивал мой код,производящий нормирование вкектора, и код макгаба(вродебы так читается ник нашего польского товарища ?).Разница между моим кодом и его была всего в 2 командах,которые повторялись 3 раза(для каждой координаты).И его код и мой написаны на ассемблере.Но мой 1.6 раза быстрее.
Измерение скорости при помощи RDTSC помогает понять какие команды работают быстрее,а какие медленнее.Это помогает написать алгоритм с наибольшим возможным быстродействием.
Согласен с тобой на 100%.Программируя на ассемблере мы сразу "убиваем двух зайцев".Тоесть максимально упрощаем алгоритм(сокращается колическтво промежуточных команд) и заменяем переменные регистрами,ускоряя вычисления.Ну и как результат - получаем быстрый код.
К примеру я сравнивал мой код,производящий нормирование вкектора, и код макгаба(вродебы так читается ник нашего польского товарища ?).Разница между моим кодом и его была всего в 2 командах,которые повторялись 3 раза(для каждой координаты).И его код и мой написаны на ассемблере.Но мой 1.6 раза быстрее.
Измерение скорости при помощи RDTSC помогает понять какие команды работают быстрее,а какие медленнее.Это помогает написать алгоритм с наибольшим возможным быстродействием.
Звучит как слова из рекламы... Алгоритмическая оптимизация не есть сокращение количества промежуточным команд. Сокращение комнанд это скорее оптимизация по размеру и возможно по скорости
Настоящая оптимизация возможна только под конкретный процессор. Разница в устройстве кеша и декодеров может давать неожиданные результаты. Даже то что хорошо для Нортвудов не всегда хорошо для Прескотов. Всё это сильно снижает ценность такой ассемблерной оптимизации.
Виктор,ты думаеш,что я незнаю что такое алгоримическая оптимизация ?
Геометрические примитимвы можно нарисовать по разному,но алгоритмы Брезенхема самые быстрые.Алгоритмы брезенхема являются примером алгоритмической оптимизации.
>Настоящая оптимизация возможна только под конкретный процессор.
Согласен.Я как то читал статью для AMD-шных процессоров,где были реализованы алгоритмы быстрого копирования.Когда я стал их проверять на своём celeron2000 ,то эти алгоримы(MMX копирования) приводили только к ухудшению скорости.Все алгоритмы обогнала стандартная rep movsd.
Геометрические примитимвы можно нарисовать по разному,но алгоритмы Брезенхема самые быстрые.Алгоритмы брезенхема являются примером алгоритмической оптимизации.
>Настоящая оптимизация возможна только под конкретный процессор.
Согласен.Я как то читал статью для AMD-шных процессоров,где были реализованы алгоритмы быстрого копирования.Когда я стал их проверять на своём celeron2000 ,то эти алгоримы(MMX копирования) приводили только к ухудшению скорости.Все алгоритмы обогнала стандартная rep movsd.
andrew_programmer
Не знаю знаешь ты или не знаешь ) , но слова
Не знаю знаешь ты или не знаешь ) , но слова
как то меня задели..Тоесть максимально упрощаем алгоритм(сокращается колическтво промежуточных команд)
andrew_programmer
Интересно. Интел тоже рекомендует MMX или SSE для быстрого копирования но они дают хороший результат если данные выравнены на 8 или 16 (для SSE) байт и еще объём копируемых данных должен быть больше килобайта. Вообще в Pentium 4 есть быстрое копирование строк если источник и приёмник выравнены на 16 байт. Данные копируются сразу строками кеша.
Интересно. Интел тоже рекомендует MMX или SSE для быстрого копирования но они дают хороший результат если данные выравнены на 8 или 16 (для SSE) байт и еще объём копируемых данных должен быть больше килобайта. Вообще в Pentium 4 есть быстрое копирование строк если источник и приёмник выравнены на 16 байт. Данные копируются сразу строками кеша.
И пропал...iadn wrote:На сайте пока одни примеры. Исходники примеров, библиотеки и способ компиляции скоро будут.
Привет . Приношу свои извинения за столь долгое отсутствие . Выложил все тут.
заставляю view3ds открыть 2меговый файл под эмулятором) пока жду реакции =)
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
все жду) эмуль зохавал 50% проца..
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
и 6мб оперативки..
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Who is online
Users browsing this forum: No registered users and 1 guest