Я теперь смогу в 10 раз меньше серверов у Интела купить
Занимательный цикл статей. Он ярко подсвечивает, что большую часть проблем Интел сам себе подвёз.
Даже в этой байке про "10 раз". Опытный продажник бы поправил клиента, мол, не в 10 раз меньше серверов, а в 10 раз больше задач можете решать на том же объёме серверов. И не дал бы купить меньше.
Я уже не говорю, что подобная job security (заставлять клиента покупать по сути ненужное ему железо) работает только при полном доминировании на рынке. Стоит ли потом удивляться, что всякие Apple/MS/FB/Amazon, почесав репу, мол, что-то у нас программы медленно работают на Интелловском железе, пытаются сделать своё, и, о, Боже, у них вдруг получается!!! Не у них всё получается, а Интел продавал им ненужное железо, заставляя его работать медленно. Очевидно, что эти компании после столь чудных открытий будут только форсировать переход на не-Интел. А Интел просто слил свою компетенцию, свои миллиарды вложенные в R&D, местами свою репутацию ради жалкой продажи 10х серверов вчера.
Эх, загнал Intel себя в ловушку с Linpack и AVX-512. В принципе же годный набор. И некоторых фич, которые есть только в AVX-512, сильно не хватает в AVX2 или ниже.
Сейчас уже можно откинуться в кресле, и с чувством собственного достоинства изречь "если бы молодость знала, если бы старость могла". Но умные люди (и компании) отличаются тем, что они извлекают уроки из прошлых неудач. Если Интел полностью откажется от AVX-512, то это точно не пойдёт на пользу. Опять придётся догонять, исправлять или ещё что-то.
Есть большое количество сценариев, где AVX-512 показывает неплохие результат и делает пользователей счастливыми. Но эти сценарии не так показательны и известны как linpack, не позволяют вешать "звёзды" на грудь, и, как результат, Интел их "не видит". Отсюда и "постепенно отказывается".
Как сказал один великий человек «страшно далеки они от народа». Это я о фирме Интел. С одной стороны они выпустили замечательный продукт под Линукс, с другой стороны в версии 2017 выкинули поддержку предыдущих поколений процессоров. Хочется отметить, что продукт нацелен в первую очередь на использование профессиональными пользователями. А на профессиональном рынке так быстро машины не меняют. Решение, настроенное раз, работает годами. Я не против того, что новая версия не поддерживает старые процессоры. Но вы оставьте линк на старую версию, чтобы оставить в душе ложное чувство, что Интел заботится о своих пользователях чуть дальше момента покупки нового процессора. Спасибо.
Буду благодарен за ссылку на предыдущий релиз.
Я склонен считать, что это была бага процессора. В официальной доке ничего такого нет.
К нам обратились клиенты, которые жаловались, что наше ПО медленно работает на их достаточно топовой машине. После процесса отладки было обнаружено, что большинство оптимизированных функций не работают. Стали смотреть на процедуру идентификации процессора и обнаружили, что CPUID выдаёт нулевые биты для «предыдущих» SSE технолигий. Самое интересное, что наше ПО находило бит AVX, но проверяло наличие всех битов AVX/SSE42/SSE41/SSSE3 для запуска AVX версии. Пришлось поправить код, и довольствоваться одним битом.
Ещё одна фишка процессоров от AMD. Некоторые процессоры на ядре Bulldozer могут возвращать флаг AVX=1, но при этом флаги SSE42, SSE41 и SSSE3 равными 0, причём все эти технологии присутствуют. Зачем это сделано — не очень понятно. Но старые программы точно не смогут «обнаружить» технологии «занулёные» технологии.
Код не самый красивый, да и вообще не понятно, зачем такое написали, если известна длина копировая. Обычный memcpy справился бы лучше. Лекция за какой год?
PS: Интел очень большой, сотни людей занимаются разными проектами и имеют порой диаметрально противоположные взгляды на какие-то вещи. Моя точка зрения — красивый код почти всегда самый быстрый. Не говоря о том, что он легко читается и поддерживается.
Требование «быстрого кода» никак не противоречит тому, чтобы писать красиво и читабельно. Я встречал в жизни буквально пару случаев, когда действительно код можно написать было «некрасивым» способом, чтобы он работал.
Во всех прочих случая — банальная лень программистов оформлять свой код корректно. По крайней мере, прочитав большой объём кода участников, я не нашёл места, которое нельзя было бы написать «красиво».
Это известные ребята, мы с ними работаем.
К сожалению, не увидел в статье даты, когда она была написана. Возможно просмотрел. И, насколько я понял, они измерили только качество, скорость не измеряли.
Когда-нибудь компания Intel (возможно) откроет доступ к своему внутреннему железу для независимых разработчиков, и тогда все будут счастливы. Я думаю, что x264 парни нашли бы там всё, что их интересует.
К сожалению, если это и случится, то не ближайшие год-два точно. Это вопросы уже высшего менеджмента, это не ко мне.
В большинстве своём, в процессе декодирования внутри кодеков используется тип short int. В ММХ регистр влазит 4 short'а. Т.е. по инструкциям add/sub должен быть прирост 4х, на практике достигается примерно 3х или чуть больше.
Если надо было сложить два short'а, проверить на переполнение и привести результат к диапазону байта (от 0 до 255), то на генеральных регистрах это вообще туча инструкций. А на MMX всего две: сложение и запаковка short в byte. Обе быстрые и короткие.
Полностью технический.
Т.е. Вы не верите, что на скорость рендеринга HTML страниц может оказывать скорость шины процессора?
Само разрешение 720p — ни есть показатель. Как Вы понимаете, просто копировать память на AthlonXP 3000+ можно со скоростью 2666MBs / (1280х720x1.5) = 1928 fps. Это ни о чём не говорит. Как и слова «у меня игрался фильм». В своих словах «процессора с HT было недостаточно» я имел ввиду, что процессора с HT было недостаточно для проигрывания фильма сжатого с вменяемым битрейтом с любой комбинацией использованных фич. Никто не будет покупать программный декодер, если на нём написано «проигрывает H264 720p на Pentium III», а внизу маленькими буквами «только базовый профиль, I/P кадры, без деблокинга». Всех интересует возможность проигрывания всего безобразия, разрешённого стандартом.
Если Вы мне пришлёте кусочек фильма, то я с удовольствием его расковыряю и скажу, как он был сжат. Впрочем, Вы можете сделать это и сами — в сети полно программных средств для определения характеристик сжатых фильмов.
Да, согласен, статья требует наличия каких-то базовых знаний. У меня есть коллега, который как раз пишет на эти темы, я спрошу его, не хочет ли он написать подробнее про базу видео-кодирования.
Не надо смеятся. Достаточно взглянуть на специализированные форумы, где люди подбирают себе машины для видео редактирования/сжатия.
Смотря какие функции, и как они реализованы. Врядли кто-нибудь способен написать функцию, которая считает 8 сумм абсолютных разностей за 4 такта. Именно столько работает инструкция MPSADBW. Вы до сих пор считаете, что их функции работают быстрее?
То, что у них не получилось использовать эти инструкции в своих функциях, ещё не говорит, что функции быстрые, а инструкции бесполезные.
По остальным вопросам — в отдел планирования, я — лишь разработчик.
По личному опыту скажу, что я регулярно заливаю перед поездками видео на iPad, и скорость, с которой это происходит на SandyBridge — для меня главное. Я не пользуюсь --superfast настройкой, пользуюсь только --balanced. Визуальных артефактов не замечаю, видео после просмотра стираю.
Занимательный цикл статей. Он ярко подсвечивает, что большую часть проблем Интел сам себе подвёз.
Даже в этой байке про "10 раз". Опытный продажник бы поправил клиента, мол, не в 10 раз меньше серверов, а в 10 раз больше задач можете решать на том же объёме серверов. И не дал бы купить меньше.
Я уже не говорю, что подобная job security (заставлять клиента покупать по сути ненужное ему железо) работает только при полном доминировании на рынке.
Стоит ли потом удивляться, что всякие Apple/MS/FB/Amazon, почесав репу, мол, что-то у нас программы медленно работают на Интелловском железе, пытаются сделать своё, и, о, Боже, у них вдруг получается!!! Не у них всё получается, а Интел продавал им ненужное железо, заставляя его работать медленно. Очевидно, что эти компании после столь чудных открытий будут только форсировать переход на не-Интел. А Интел просто слил свою компетенцию, свои миллиарды вложенные в R&D, местами свою репутацию ради жалкой продажи 10х серверов вчера.
Хорошая была контора.
Эх, загнал Intel себя в ловушку с Linpack и AVX-512. В принципе же годный набор. И некоторых фич, которые есть только в AVX-512, сильно не хватает в AVX2 или ниже.
Сейчас уже можно откинуться в кресле, и с чувством собственного достоинства изречь "если бы молодость знала, если бы старость могла". Но умные люди (и компании) отличаются тем, что они извлекают уроки из прошлых неудач. Если Интел полностью откажется от AVX-512, то это точно не пойдёт на пользу. Опять придётся догонять, исправлять или ещё что-то.
Есть большое количество сценариев, где AVX-512 показывает неплохие результат и делает пользователей счастливыми. Но эти сценарии не так показательны и известны как linpack, не позволяют вешать "звёзды" на грудь, и, как результат, Интел их "не видит". Отсюда и "постепенно отказывается".
Преподавать (особенно если у обучаемых есть успехи) — особый вид наркотика :).
Keep doing.
Буду благодарен за ссылку на предыдущий релиз.
К нам обратились клиенты, которые жаловались, что наше ПО медленно работает на их достаточно топовой машине. После процесса отладки было обнаружено, что большинство оптимизированных функций не работают. Стали смотреть на процедуру идентификации процессора и обнаружили, что CPUID выдаёт нулевые биты для «предыдущих» SSE технолигий. Самое интересное, что наше ПО находило бит AVX, но проверяло наличие всех битов AVX/SSE42/SSE41/SSSE3 для запуска AVX версии. Пришлось поправить код, и довольствоваться одним битом.
PS: Интел очень большой, сотни людей занимаются разными проектами и имеют порой диаметрально противоположные взгляды на какие-то вещи. Моя точка зрения — красивый код почти всегда самый быстрый. Не говоря о том, что он легко читается и поддерживается.
С генерацией матрицы действительно вышла накладка, тут критика уместна.
Во всех прочих случая — банальная лень программистов оформлять свой код корректно. По крайней мере, прочитав большой объём кода участников, я не нашёл места, которое нельзя было бы написать «красиво».
К сожалению, не увидел в статье даты, когда она была написана. Возможно просмотрел. И, насколько я понял, они измерили только качество, скорость не измеряли.
К сожалению, если это и случится, то не ближайшие год-два точно. Это вопросы уже высшего менеджмента, это не ко мне.
В большинстве своём, в процессе декодирования внутри кодеков используется тип short int. В ММХ регистр влазит 4 short'а. Т.е. по инструкциям add/sub должен быть прирост 4х, на практике достигается примерно 3х или чуть больше.
Если надо было сложить два short'а, проверить на переполнение и привести результат к диапазону байта (от 0 до 255), то на генеральных регистрах это вообще туча инструкций. А на MMX всего две: сложение и запаковка short в byte. Обе быстрые и короткие.
Ну и так далее :)
Т.е. Вы не верите, что на скорость рендеринга HTML страниц может оказывать скорость шины процессора?
Само разрешение 720p — ни есть показатель. Как Вы понимаете, просто копировать память на AthlonXP 3000+ можно со скоростью 2666MBs / (1280х720x1.5) = 1928 fps. Это ни о чём не говорит. Как и слова «у меня игрался фильм». В своих словах «процессора с HT было недостаточно» я имел ввиду, что процессора с HT было недостаточно для проигрывания фильма сжатого с вменяемым битрейтом с любой комбинацией использованных фич. Никто не будет покупать программный декодер, если на нём написано «проигрывает H264 720p на Pentium III», а внизу маленькими буквами «только базовый профиль, I/P кадры, без деблокинга». Всех интересует возможность проигрывания всего безобразия, разрешённого стандартом.
Если Вы мне пришлёте кусочек фильма, то я с удовольствием его расковыряю и скажу, как он был сжат. Впрочем, Вы можете сделать это и сами — в сети полно программных средств для определения характеристик сжатых фильмов.
Смотря какие функции, и как они реализованы. Врядли кто-нибудь способен написать функцию, которая считает 8 сумм абсолютных разностей за 4 такта. Именно столько работает инструкция MPSADBW. Вы до сих пор считаете, что их функции работают быстрее?
То, что у них не получилось использовать эти инструкции в своих функциях, ещё не говорит, что функции быстрые, а инструкции бесполезные.
По остальным вопросам — в отдел планирования, я — лишь разработчик.
По личному опыту скажу, что я регулярно заливаю перед поездками видео на iPad, и скорость, с которой это происходит на SandyBridge — для меня главное. Я не пользуюсь --superfast настройкой, пользуюсь только --balanced. Визуальных артефактов не замечаю, видео после просмотра стираю.