Разоблачение рекламной статьи Intel

[@zone19]

Интересно, кто-нибудь вообще берет в расчет бенчмарки от компаний-производителей? А уж тем более когда в них приводятся фразы типа «мы в 400 раз быстрее ближайших конкурентов»?

[@pogorskiy]

У того же самого Intel-а в примерах декодера видео, построенного на Intel Media SDK, инкремент декодированных фреймов происходил в двух местах, в результате чего показывался в два раза больший fps. Несколько часов я потратил чтобы понять почему мой собственный пример на их компонентах выдает меньший fps чем их пример. Конечно, я думаю, что это была непреднамеренная ошибка.

[@homm]

Хочу обратиться к НЛО, которое без спроса добавляет кавычки (причем криво) и убирает переносы строк: я благодарен за желание помочь, но впредь лучше писать свои предложения в личку.

[@david_mz]

Столь строгое совпадение времени ресайза libNthumbIppOnly и libNthumb даже афинными преобразованиями не объяснить. Я бы вообще предположил, что они и там и там использовали предварительное 8-кратное уменьшение. Ну а что, всё равно никто не проверит…

[@homm]

Ну почему же, аффинные преобразования действительно имеют линейное время относительно исходного разрешения, потому что изображение строится по одинаковому набору точек.

In [1]: import cv2

In [2]: i = cv2.imread('ex1_.jpg')
In [3]: i.shape
Out[3]: (1280, 1920, 3)
In [4]: %timeit -n 50 r = cv2.resize(i, (400, 300), interpolation=cv2.INTER_LINEAR)
"50 loops, best of 3: 2.75 ms per loop"

In [5]: i = cv2.imread('5k.jpg')
In [6]: i.shape
Out[6]: (2880, 5120, 3)
In [7]: %timeit -n 50 r = cv2.resize(i, (400, 300), interpolation=cv2.INTER_LINEAR)
"50 loops, best of 3: 2.88 ms per loop"

[@david_mz]

Да, Вы правы. Это я ступил что-то.

[@homm]

Линейное → постоянное. В статье тоже исправил.

[@DISaccount]

Но это только мое мнение и я не могу никак помешать компании Intel продавать библиотеку, реализующую именно этот метод.

Методов ресайза в библиотеке несколько. Не примите за нравоучение или грубость, но лучше Вы сами не вводите разработчиков в заблуждение выдавая свои догадки

Мне кажется, что в Intel IPP используется метод аффинных преобразований (тут я снова отсылаю вас прочесть методы ресайза изображений),

за чистую монету. Документация на каждую функцию доступна.

Более того, я так же не хочу им помогать/рекламировать, как и Вы не хотите навредить Intel. Но 5 лет использования библиотеки (а теперь и компилятора), благо наши системы привязаны на процессоры, дают понять, что аналогов не так уж и много. Я сейчас говорю про наличие в ней не только таких "примитивных" функций, как ресайз, а более сложных статистических функций и прочих. Поэтому, я думаю, не стоит заострятся на какой-то одной функции, т.к. пускают пыль в глаза ВСЕ производители.

[@homm]

Методов ресайза в библиотеке несколько.

Да, помимо аффинных преобразований есть суперсемплинг. Но именно реализация ресайза аффинными преобразованиями с моей точки зрения является багом.

Не понял, при чем тут аналоги, «примитивность» ресайза (если так примитивно, что же правильно не реализовали) и другие функции, если речь о недобросовестном сравнении.

пускают пыль в глаза ВСЕ производители

Во-первых, вы сейчас совершенно бездоказательно оклеветали других производителей. Во-вторых, пыль в глаза можно пускать по разному. Можно поставить сравниваемые продукты в одинаковые условия, не благоприятные для одного из них. А можно в совершенно разные и выдавать это за сравнение.

[@DISaccount]

Не понял, при чем тут аналоги, «примитивность» ресайза

"Примитивность" по сравнению с операциями взаимной кросс-корреляции/преобразование Фурье и т.д. Аналоги, в смысле другие пакеты (тот же OpenCV), не обладают таким богатством «элементарных» функций (кирпичиков), заточенных на быстродействие. Кстати, OpenCV можно таки собрать с использованием IPP. И прирост производительности действительно заметен.

Во-первых, вы сейчас совершенно бездоказательно оклеветали других производителей

Согласен, каюсь. Скажу иначе. Весь мой опыт работы и решения (программные), с которыми я сталкивался/знакомился, а так же решения, которые сам продвигал всегда напоминают (если уж совсем утрировано) сказку «Как старик корову продавал». В смысле, кто будет говорить о недостатках своего решения или делать сравнения в невыгодных для себя условиях. Ну глупо же -). Поэтому Вам в первом комментарии вполне резонно и написали, мол «это давно известный факт».

[@vanxant]

При всём при этом, не могу не заметить, что IPP действительно крутая штука, позволяющая выжать из железа максимум. Жаль только, что платная. Что, вообще говоря, удивительно, так как на процах конкурирующего производителя она все равно бесполезна…

[@wizardsd]

Бесполезна по сравнению с чем? Сможете показать на примере? Например, сравните прирост/падение производительности на процессоре Intel при переходе от FFTW к IPP FFT с приростом/падением производительности того же примера на аналогичном по набору инструкций процессоре AMD. Только проконтролируйте использование именно той же библиотеки IPPS в обоих случаях, чтобы автоматический диспетчер не мешал… Можно даже на статью на хабре набрать материала, если получится интересный результат… У меня, к сожалению, нет таких процессоров в шаговой доступности.

[@DISaccount]

Товарищ vanxant хотел сказать, что программа скомпилированная с использованием IPP, вполне может быть, не будет работать на машине с процессором AMD, о чем сам Intel и пишет в своих доках, но завуалированно. Ни о каком падении в сравнении с чем то речи не идет-)

[@wizardsd]

Пока достоверно не известно, что он хотел сказать, но на официальном сайте указано именно об уровне оптимизации, и не слова о том, что IPP вообще не будет работать на процессорах других производителей. Если бы это было так, то мало кто решился бы выпускать продукт для широкого круга пользователей используя IPP и/или компилятор Intel. Привязав IPP к своим процессорам Intel потеряла бы большую часть пользователей. Вы бы купили такой программный продукт? Рекомендовали бы его коллегам?..

[@guyfawkes]

Заинтересовало быстрое уменьшение jpeg. Насколько я понимаю, ссылка www.libjpeg-turbo.org/About/SmartScale, к примеру, именно к этому относится?

[@vlivyur]

а уменьшенное в 8 раз

Только это в 64 раза уменьшено.

[@pfalcon]

Статья немного улыбнула, ее смысл можно свеcти к «closed-source библиотеки едят ваши данные бенчмарки!!!11». Но ведь это и так все знают, не так ли? Кто хочет качество, использует библиотеку с открытой реализацией известного алгоритма, которую можно проверить (и даже оптимизировать). Кто хочет дописать строчку с аббревиатурами и buzzword'ами в прес-релиз, тоже имеет свой вариант. Для всех есть место под солнцем, и никому ни перед кем извиняться не надо.

[@krogozh]

Добрый день, уважаемые коллеги.
Вы совершенно правы – обсуждаемая здесь статья была опубликована без рецензии со стороны разработчиков библиотеки IPP ( Intel® Integrative Primitives ) и статья действительно содержит явные ошибки допущенные авторами.
Мы работаем над исправлением и обновлением данной публикации и сообщим здесь на форуме когда это обновление произойдет.
Мы также подумаем как обновить соответствующие части документации и сделаем это в одном из будущих обновлений.

С Уважением, Intel® IPP Team.

[@homm]

Первые комментарии за почти два месяца, но все равно, спасибо.

[@erlyvideo]

чего-то стерли её