В третьих, если вы сделали игру для Android (или другой платформы, которая поддерживает x86 устройства, например Tizen) и планируете загрузить её в апп стор, то по условиям лицензии вы должны также собрать x86-совместимую версию игры и загрузить её вместе с остальными.
Закрытый кодек стандарта H.264 может (теоретически) разрабатывать кто угодно, включая вас и меня. Вообщем, сотни их.
Лицензия на референсный энкодер H.264 даже более свободная, чем лицензия x264. Но на практике референсный энкодер используют только для отладки и рисёрча, т.к. никаких оптимизаций производительности в нём нет, и потому кодирует он медленно.
Нет никакого подвоха. Цель создания H.265 — обеспечить лучшее, чем у H.264, сжатие видео, при бОльших, чем у H.264, аппаратных требованиях. Именно это мы и видим.
Сравнивается тёплое с мягким. H.264 это стандарт видеокодирования («закрытость» его заключается в том, что некоторые части стандарта покрыты патентами, и за их использование нужно платить лицензионные отчисления), а x264 — видеоэнкодер, кодирующий видео в соответствии со стандартом H.264 («свободность» его заключается в том, что исходный код открыт под GPL).
А почему так мало OpenCL-функций? И как они реализованы: IPP теперь поставляется с исходниками под OpenCL или таскает набор бинарников под растространённые OpenCL устройства?
Я вижу две проблемы с нынешними стандартными библиотеками.
1. С++ ABI не стандартизировано, библиотеки поддерживают только тот компилятор, с которым они поставляются. Из-за этого написание модульных программ (программ с плагинами) на C++ затруднительно, и требует большого количества костылей.
2. Функциональность стандартной библиотеки стандартизирована. В сочетании с первой проблемой это уничтожает стимулы развивать стандартную библиотеку. Например, сравните функциональность класса QString из QT 5 и класса std::basic_string из Microsoft STL.
Я считаю, что нужно как раз обратное: чётко описанное в стандарте C++ ABI, и минимум огранический на стандартную библиотеку.
Мне нравится Java, и я нередко на ней пишу. Но у каждого языка своя ниша. На Java невозможно писать высокопроизводительные научные приложения, у C++ с этим сильно лучше, но я не вижу ничего плохого, чтобы в некоторых чертах он стал похож на Java.
Я имел в виду HTML 4.0/XHTML 1.0. К HTML5 форматирование уже перевели на CSS, и обратная совместимость со старыми тегами вроде font уже не была столь большой проблемой.
3. Соблазн ограничиться одной кодировкой огромен, и многие другие языки так и сделали, но на C++ пишется много софта, который работает и с multi-byte кодировками (текстовые редакторы, например). К тому же разные фреймворки используют разные кодировки Юникода.
8. Если стандартизировать интерфейс на бинарном уровне, единой стандартной библиотеки не потребуется, будет много совместимых со стандартом библиотек (а конкуренция = хорошо).
В HTML когда-то проблему обратной совместимости решили разделением стандарта на strict и transitional версии. Уверен, что тот же подход отлично подошёл бы для C++.
Итак, что нужно убрать из C++:
1. Все встроенные типы с implementation-defined размером: short, int, long, long long заменяем на int16_t, int32_t, и т.п. Как вариант, фиксируем размер short, int, long в битах. Всё равно другие типы на нормальных архитектурах не встречаются, а для экзотических есть C. Плюс 100 к портабельности.
2. Propagation операндов аримтетических операций к int — убираем нафиг и забываем как страшный сон. typeof(short(2) + short(2)) == int — отличный выстрел, прямо в ногу!
3. Аналогично char и wchar_t заменить на char8_t, char16_t, char32_t.
4. Жёстко зафиксировать float = IEEE 754-2008 single-precision, double = IEEE 754-2008 double-precision.
5. enum class не нужен, простой enum должен реализовывать эту функциональность.
6. Implementation defined — зло и ересь, половина кода MSVC-only, половина gcc-only. Стандарт должен ограничивать число возможных вариантов.
7. Undefined behaviour в большинстве случаев туда же. Стандарт должен быть строже в отношении возможных интерпретаций.
8. STL не нужна. Нужен удобный механизм подключения любой стандартной библиотеки (например import "github.com/stroustrup/stl" в стиле Go). Для фич языка, которые должны взаимодействовать со стандартной библиотекой (например typeid), должной быть определено бинарное ABI.
NEON — это не только floating-point, но и целочисленные операции, копирование структур, и их инициализация нулями. Определяется он неправильно: т.к. ваш i.MX6Q поддерживает NEON, то должно определяться как -mfpu=neon. Кроме того, правильное указание архитектуры важно не только для того, чтобы использовались все поддерживаемые инструкции, но и чтобы gcc (или llvm) использовал правильную модель процессора. На ARM неправильное указание архитектуры может замедлить код в несколько раз. Вообщем, советую попробовать перекомпилировать с -O3 -mthumb -march=armv7-a -mcpu=cortex-a9 -mfpu=neon -mvectorize-with-neon-quad
Хм, сейчас запустил openssl speed aes-256-cbc, Haswell получился быстрее:
Спасибо, интересная статья. Несколько замечаний:
Под ARM нужно указывать -mfpu=neon, тогда есть шанс что gcc что-нибудь векторизует на -O3. Также есть мнение, что для ARM clang/llvm лучше, чем gcc.
Что касается высоких результатов ARM в шифровании по AES, думаю, что OpenSSL использует аппаратный блок шифрования где-то в чипсете. В OpenSSL AES тесте Arndale board (упомянутая выше) оказывается производительнее самого быстрого Haswell, что возможно только при аппаратной реализации в чипсете (в отличие от Haswell, никаких инструкций для ускорения AES в Cortex-A15 нет).
© баш
Да и процессор Intel Atom D525 в свободном доступе найти не просто!
Вообщем, реквестирую бенчмарк с clang 3.3
Хитро придумано!
Лицензия на референсный энкодер H.264 даже более свободная, чем лицензия x264. Но на практике референсный энкодер используют только для отладки и рисёрча, т.к. никаких оптимизаций производительности в нём нет, и потому кодирует он медленно.
По результатам видно, что журналисты Tom's Hardware путают SSE3 и SSSE3.
После этой фразы я безошибочно угадал автора
А почему так мало OpenCL-функций? И как они реализованы: IPP теперь поставляется с исходниками под OpenCL или таскает набор бинарников под растространённые OpenCL устройства?
1. С++ ABI не стандартизировано, библиотеки поддерживают только тот компилятор, с которым они поставляются. Из-за этого написание модульных программ (программ с плагинами) на C++ затруднительно, и требует большого количества костылей.
2. Функциональность стандартной библиотеки стандартизирована. В сочетании с первой проблемой это уничтожает стимулы развивать стандартную библиотеку. Например, сравните функциональность класса QString из QT 5 и класса std::basic_string из Microsoft STL.
Я считаю, что нужно как раз обратное: чётко описанное в стандарте C++ ABI, и минимум огранический на стандартную библиотеку.
3. Соблазн ограничиться одной кодировкой огромен, и многие другие языки так и сделали, но на C++ пишется много софта, который работает и с multi-byte кодировками (текстовые редакторы, например). К тому же разные фреймворки используют разные кодировки Юникода.
8. Если стандартизировать интерфейс на бинарном уровне, единой стандартной библиотеки не потребуется, будет много совместимых со стандартом библиотек (а конкуренция = хорошо).
Итак, что нужно убрать из C++:
1. Все встроенные типы с implementation-defined размером: short, int, long, long long заменяем на int16_t, int32_t, и т.п. Как вариант, фиксируем размер short, int, long в битах. Всё равно другие типы на нормальных архитектурах не встречаются, а для экзотических есть C. Плюс 100 к портабельности.
2. Propagation операндов аримтетических операций к int — убираем нафиг и забываем как страшный сон.
typeof(short(2) + short(2)) == int— отличный выстрел, прямо в ногу!3. Аналогично char и wchar_t заменить на char8_t, char16_t, char32_t.
4. Жёстко зафиксировать float = IEEE 754-2008 single-precision, double = IEEE 754-2008 double-precision.
5. enum class не нужен, простой enum должен реализовывать эту функциональность.
6. Implementation defined — зло и ересь, половина кода MSVC-only, половина gcc-only. Стандарт должен ограничивать число возможных вариантов.
7. Undefined behaviour в большинстве случаев туда же. Стандарт должен быть строже в отношении возможных интерпретаций.
8. STL не нужна. Нужен удобный механизм подключения любой стандартной библиотеки (например
import "github.com/stroustrup/stl"в стиле Go). Для фич языка, которые должны взаимодействовать со стандартной библиотекой (например typeid), должной быть определено бинарное ABI.-O3 -mthumb -march=armv7-a -mcpu=cortex-a9 -mfpu=neon -mvectorize-with-neon-quadХм, сейчас запустил
openssl speed aes-256-cbc, Haswell получился быстрее:Наверное, я в прошлый раз перепутал результаты.
Под ARM нужно указывать -mfpu=neon, тогда есть шанс что gcc что-нибудь векторизует на -O3. Также есть мнение, что для ARM clang/llvm лучше, чем gcc.
Что касается высоких результатов ARM в шифровании по AES, думаю, что OpenSSL использует аппаратный блок шифрования где-то в чипсете. В OpenSSL AES тесте Arndale board (упомянутая выше) оказывается производительнее самого быстрого Haswell, что возможно только при аппаратной реализации в чипсете (в отличие от Haswell, никаких инструкций для ускорения AES в Cortex-A15 нет).