В mainfs из виртуальной машины от холы дуо в качестве floating point strategy стоит vfpv3-d16. Я много читал об этих ускорителях, даже свои опыты ставил, собирая тестовые проги либо с тем либо с тем ускорителем. И ни собственные тесты, ни какие либо источники из интернет не показали хоть какого-то превосходства vfp над neon ни на 8-х, ни на 9-х кортексах. Вот мне и интересно, я что-то пропустил, или эта настройка основанна на личных предпочтениях? Кстати thumb2 даёт некоторую экономию размеров бинарников, но за счёт снижения производительности на 5-10%. И на любых компиляторах кроме linaro в режиме thumb2 принципиально не собирается php. А вот сам linaro довольно спорный компромис. С codesourcery лично у меня проблем было на порядок меньше. А использовать linaro вынуждает сам фрискейл: вивантовские либы которые лежат у них на сайте ни фига не работают... Я даже ltib собирал, подсунув патч для холы, большая часть видосов или вообще не воспроизводится или наглухо вешает плату на 2-3 минуте просмотра.
Так что не воспримите этот пост как наезд, я всего лишь хочу знать обоснование, почему используется более медленный vfpv3-d16

Цитата

Вот мне и интересно, я что-то пропустил, или эта настройка основанна на личных предпочтениях?

не знаю какие ваши предпочтения, а майнстрим - vfpv3-d16

https://wiki.debian.org/ArmHardFloatPort#Minimum_CPU_.26_FPU

Цитата

Кстати thumb2 даёт некоторую экономию размеров бинарников, но за счёт снижения производительности на 5-10%.

какие-то тесты поддтверждающие ваши слова есть ?

Цитата

А вот сам linaro довольно спорный компромис. С codesourcery лично у меня проблем было на порядок меньше.

вы для начала прочитайте про то чем пользуетесь

http://e2e.ti.com/support/embedded/linux/f/354/p/329715/1150828.aspx#1150828

Насчёт thumb2 гдето на хабре вычитал, сходу не нашёл.
А по второй части, ну допустим в codesourcery действительно нет оптимизации. Но тогда мне интересно, почему тот же ti в хвост и гриву эксплуатирует codesourcery lite? Использовать linaro им религия чтоли не позволяет? Или там толпа дибилов собралась? Кстати они же упорно продвигают именно neon. А когда nvidia на второй тегре пошла по мейнстриму, что-то её загнобили...
Единственное но: я не щупал их камней кроме cortex-a8. Так что не судите строго... Я не придираюсь, не выпендриваюсь, я всего-лишь хочу подобрать оптимальный вариант для холы.

Цитата

Насчёт thumb2 гдето на хабре вычитал

лично я больше доверяю инженерам Linaro - в их сборках thumb2 по умолчанию

Цитата

Но тогда мне интересно, почему тот же ti в хвост и гриву эксплуатирует codesourcery lite?

ну они ядро 2.6.37 активно эксплуатируют - о чем это вообще может говорить ?

Цитата

Единственное но: я не щупал их камней кроме cortex-a8.

NEON в качестве FPU дает выигрыш как раз только на a8 - у него VFP Lite без конвеера, только NEON на кортексах a8/9 не поддерживает двойную точность, при этом GCC для ARM в принципе не способен выполнять автовекторизацию, так что не знаю где вы мифов начитались

Цитата

я всего-лишь хочу подобрать оптимальный вариант для холы

на мультимедийных процессорах ARM играет вспомогательную роль, я лично не заметил никаких улучшений производительности когда собирал с -mfpu=neon -O3, а вот проблемы со стабильностью проявились через пару минут использования.

UPD "NEON на кортексах a8/9 не поддерживает двойную точность" - это некорректно, a8 не поддерживает, a9 - поддерживает, только без SIMD

Цитата

The Cortex-A9 NEON MPE features are:

SIMD and scalar single-precision floating-point computation

scalar double-precision floating-point computation

В принципе двойную точность я не учёл, поэтому наверное vfp всё-таки будет правильнее. А те кому такая точность не нужна в конфиге бьюлдрута переопределяют опции как им нужно, к примеру opencv нагло втыкает -mfpu=neon -ffast-math, а бьюлдрут, видя что -mfpu уже задана, vfp не подсовывает...