Comments 11
Неплохо было бы перенести сие добро в тематический раздел. Заранее спасибо тем кто поможет :)
я не программер, и но с удовольствием почитал. Умеют же некоторые люди сложные вещи понятно объяснить :)
Прямо какое то исследование.
Спасибо, хороший анализ. Надеюсь не понадобится. ;)
Спасибо, хороший анализ. Надеюсь не понадобится. ;)
Насчет «исследование» это наверно влияние университета :)
А вообще эплы сделали замечательную среду разработки под iPhone. В этом конкретном случае мне было достаточно открыть инструменты (CPU Sampler) да глянуть что у меня больше всего грузит процессор…
З.Ы. Вообще armv6 очень хорош для обработки звука.
А вообще эплы сделали замечательную среду разработки под iPhone. В этом конкретном случае мне было достаточно открыть инструменты (CPU Sampler) да глянуть что у меня больше всего грузит процессор…
З.Ы. Вообще armv6 очень хорош для обработки звука.
Не сильно понимаю в различиях между процессарами. Каким образом он подходит больше остальных? Ну или в чем удобсвта?
Набор комманд. У armv6 (по сравнению с armv5) есть целый класс комманд, который сильно ускоряет обработку аудио данных. Яркий пример (то чего в этой статье я забыл упомянуть) — сложение с насыщением.
Вот такой код сделает сумму 2-х пар 16-ти битных чисел.
Причем если результат сложения не будет вмещатся в 16 бит — будет происходить насыщение а не переполнение. Т.е. не надо делать 32 битное сложение с 2-мя последующими проверками (или еще какие подобные выкрунтасы).
Вот такой код сделает сумму 2-х пар 16-ти битных чисел.
inline volatile int SignedSaturatedAddDual(SInt32 x, SInt32 y)
{
register int32_t result;
asm volatile("qadd16 %0, %1, %2"
: "=r"(result)
: "r"(x), "r"(y)
);
return result;
}
Причем если результат сложения не будет вмещатся в 16 бит — будет происходить насыщение а не переполнение. Т.е. не надо делать 32 битное сложение с 2-мя последующими проверками (или еще какие подобные выкрунтасы).
>> Кстати, почитав документацию я с удивлением обнаружил отсутствие целочисленного деления.
Почему с удивлением? Деление противоречит RISC идеологии (уникальная длинная инструкция блокирующая конвеер). Редко когда оно действительно нужно.
В Itanium вон даже целочисленное умножение делается через FPU =)
Почему с удивлением? Деление противоречит RISC идеологии (уникальная длинная инструкция блокирующая конвеер). Редко когда оно действительно нужно.
В Itanium вон даже целочисленное умножение делается через FPU =)
Хотелось бы знать названия приложений, авторы которых уделяют такое внимание оптимизации. Это же потенциальное конкурентное преимущество, не видное пользователю, стоящему перед проблемой (кстати, пишется с одним «м» :) выбора. А мы, пользователи, ведь можем и поддержать трудовым баксом. :)
Хех. В мои задачи входило создание приложения. Продет его совсем другой человек в японии (аутсорсинг или как это зовется по современному). Были мысли чтонить сове на основе этого движка написать — да пока не слишком времени хватает (кроме постоянной работы помогаю своему другу писать приложение «Galileo» (на AppleStore уже есть кстати) ).
А, понятно.
На Galileo посмотрел. Жаль, для России это пока неактуально. Приходится пользоваться самодельными кэшами Google Maps.
Кстати, если решитеcь выводить на App Store свои разработки — можете обращаться. :)
На Galileo посмотрел. Жаль, для России это пока неактуально. Приходится пользоваться самодельными кэшами Google Maps.
Кстати, если решитеcь выводить на App Store свои разработки — можете обращаться. :)
Sign up to leave a comment.
Оптимизация приложений (Iphone armv6)