Ключи оптимизации практически не имеют значения при измерении скорости работы памяти, поскольку используются довольно большие буфера (несколько мегабайт) и практически все время процессор проводит внутри библиотечных функций (memcpy/memset) либо функций, полностью написанных на ассемблере (memsetXX/memcpyXX), т.е. оптимизатору там влезть негде. В последних дополнительных тестах идет работа с блоками памяти маленького размера (до 16 и до 512 байт соответственно), поэтому там работа оптимизатора видна, но эти тесты нужны лишь для того, чтобы убедиться, что новые оптимизированные функции и на маленьких блоках работают по крайней мере не хуже (хотя там не все честно - новые функции инлайнятся ).geometer писал(а):А кстати, как его нужно было компилировать? В смысле, с какими ключиками?
Судя по всему, в новой прошивке тут ничего не изменилось и стандартные функции все еще не выжимают максимум из железа, хотя представители нокии и обещали что попробуют что-нибудь сделать. Но с другой стороны, получается еще есть резервы по улучшению быстродействия
Маленькое лирическое отступление, с чего все это собственно началось. Я пытаюсь портировать UFO2000 на Nokia 770. UFO2000 использует библиотеку Allegro для работы с графикой. Для тех архитектур, для которых нет оптимизированного кода на ассемблере, используется универсальный, но медленный код на C, что-то вроде:
Код: Выделить всё
while (size--) { *dst++ = *src++; }
В частности, для UFO2000 все это приводит к росту FPS с 10-11 до 18-20, что должно заметно сказаться на играбельности. Для самой Nokia 770 быстрая работа с памятью наверное совсем не помешала бы в коде GTK (при очистке/копировании областей экрана).
PS. Судя по всему, эти оптимизации копирования памяти полезны только для OMAP, для XSCALE все наоборот. Хотя, возможно и для XSCALE можно добиться нормального быстродействия, если поэкспериментировать с командой PLD - software prefetch (на нокии от нее нет никакого эффекта).