Comments 11
Неплохо было бы перенести сие добро в тематический раздел. Заранее спасибо тем кто поможет :)
0
я не программер, и но с удовольствием почитал. Умеют же некоторые люди сложные вещи понятно объяснить :)
0
Прямо какое то исследование.
Спасибо, хороший анализ. Надеюсь не понадобится. ;)
Спасибо, хороший анализ. Надеюсь не понадобится. ;)
0
Насчет «исследование» это наверно влияние университета :)
А вообще эплы сделали замечательную среду разработки под iPhone. В этом конкретном случае мне было достаточно открыть инструменты (CPU Sampler) да глянуть что у меня больше всего грузит процессор…
З.Ы. Вообще armv6 очень хорош для обработки звука.
А вообще эплы сделали замечательную среду разработки под iPhone. В этом конкретном случае мне было достаточно открыть инструменты (CPU Sampler) да глянуть что у меня больше всего грузит процессор…
З.Ы. Вообще armv6 очень хорош для обработки звука.
+1
Не сильно понимаю в различиях между процессарами. Каким образом он подходит больше остальных? Ну или в чем удобсвта?
0
Набор комманд. У 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-мя последующими проверками (или еще какие подобные выкрунтасы).
+1
>> Кстати, почитав документацию я с удивлением обнаружил отсутствие целочисленного деления.
Почему с удивлением? Деление противоречит RISC идеологии (уникальная длинная инструкция блокирующая конвеер). Редко когда оно действительно нужно.
В Itanium вон даже целочисленное умножение делается через FPU =)
Почему с удивлением? Деление противоречит RISC идеологии (уникальная длинная инструкция блокирующая конвеер). Редко когда оно действительно нужно.
В Itanium вон даже целочисленное умножение делается через FPU =)
+1
Хотелось бы знать названия приложений, авторы которых уделяют такое внимание оптимизации. Это же потенциальное конкурентное преимущество, не видное пользователю, стоящему перед проблемой (кстати, пишется с одним «м» :) выбора. А мы, пользователи, ведь можем и поддержать трудовым баксом. :)
0
Хех. В мои задачи входило создание приложения. Продет его совсем другой человек в японии (аутсорсинг или как это зовется по современному). Были мысли чтонить сове на основе этого движка написать — да пока не слишком времени хватает (кроме постоянной работы помогаю своему другу писать приложение «Galileo» (на AppleStore уже есть кстати) ).
0
А, понятно.
На Galileo посмотрел. Жаль, для России это пока неактуально. Приходится пользоваться самодельными кэшами Google Maps.
Кстати, если решитеcь выводить на App Store свои разработки — можете обращаться. :)
На Galileo посмотрел. Жаль, для России это пока неактуально. Приходится пользоваться самодельными кэшами Google Maps.
Кстати, если решитеcь выводить на App Store свои разработки — можете обращаться. :)
0
Sign up to leave a comment.
Оптимизация приложений (Iphone armv6)