В Linux прекратилась поддержка SIMD-набора инструкций 3DNow! для процессоров AMD. Этот набор был выпущен компанией AMD в 1998 году вместе с процессорами K6 3D.
AMD готовит инструкции SSE5
Согласно недавнему сообщению ряда западных ИТ-изданий, компания AMD намерена дополнить архитектуру x86 набором команд под обозначением SSE5. Включающие в себя 50 команд новые инструкции, как ожидается, позволят разработчикам игровых и мультимедийных приложений значительно упростить код и повысить эффективность итоговых продуктов.
Одна из главных особенностей SSE5 — это увеличенное с двух до трёх количество операндов, что до сих пор было характерно лишь для некоторых RISC-платформ. Это, в частности, позволит объединять несколько простых инструкций в одну, что в свою очередь увеличить производительность. Не исключено, что поддержка SSE5 будет включена в процессорах AMD под кодовым названием Bulldozer, выход которых ожидается в 2009 году.
Очевидно, не обошлось без сотрудничества с Intel.
via CNET News.com
Одна из главных особенностей SSE5 — это увеличенное с двух до трёх количество операндов, что до сих пор было характерно лишь для некоторых RISC-платформ. Это, в частности, позволит объединять несколько простых инструкций в одну, что в свою очередь увеличить производительность. Не исключено, что поддержка SSE5 будет включена в процессорах AMD под кодовым названием Bulldozer, выход которых ожидается в 2009 году.
Очевидно, не обошлось без сотрудничества с Intel.
via CNET News.com
Интервью с Андершем Лильенбергом. Часть 3, последняя. Книги.
Это заключительная часть интервью. Андерш оказался большим любителем и знатоком русской литературы и, конечно, серьезным авторитетом по части литературы деловой.
- Вторая часть интервью
Первая часть интервью
Подкасты правильно слушать по подписке.
Правильный фид для подписки —
Манн, Иванов и Фербер RSS.
Тестируем свежеиспечёные SSE модификации FFT/MDCT
Написал для своего детища SSE-реализацию комплексного FFT и MDCT. Результаты поразили даже меня:
Вычислялось два миллиона 128-точечных комплексных FFT и один миллион 512-точечных MDCT. Процессор Intel® Core(TM)2 Duo CPU E8400 @ 3.00GHz
Интересно можно ли это кому-нибудь продать или лицензировать? :)
| преобразование/вариант | без SSE | SSE-модификация |
|---|---|---|
| 2000000 * FFT-128 | ||
| 1000000 * MDCT-512 | 10,4с |
Вычислялось два миллиона 128-точечных комплексных FFT и один миллион 512-точечных MDCT. Процессор Intel® Core(TM)2 Duo CPU E8400 @ 3.00GHz
Интересно можно ли это кому-нибудь продать или лицензировать? :)
Intel Ct beta — что, зачем, как
2 недели назад помогал клиенту начать пользоваться бетой Intel Ct. Заодно, как водится, и сам немножко разобрался, и теперь хочу поделиться.
Недавно появилась возможность скачать бету Ct, зарегистрировавшись на сайте. Пока только для Windows, но через некоторое время должна появиться бета и для Linux.
Недавно появилась возможность скачать бету Ct, зарегистрировавшись на сайте. Пока только для Windows, но через некоторое время должна появиться бета и для Linux.
«The Simdsons» — немного о семействе векторных инструкций SIMD
Когда я впервые увидела этот мультфильм, то абсолютно не впечатлилась. Какие-то желтые (хорошо хоть не зеленые) человечки с выпученными глазами, сюжет не особенно интересный, шутки несмешные…
Но вскоре все радикально изменилось. Нет, «Симпсоны» остались теми же, зато я провела около месяца в командировке в мир Симпсонов — США, где наконец поняла, почему этот сериал многие считают лучшим. «The Simpsons» — действительно прекрасная пародия на американский образ жизни от мелочей до глобальных вопросов, это и юмор и философия и еще много отличных поводов для просмотра.
К чему это я? А к тому, что наверняка первое знакомство с семейством векторных инструкций SIMD (и, в частности, SSE) многих программистов не впечатлило. Какие-то новые инструкции с
Попробую радикально изменить это представление. Нет, я не буду убеждать вас, что SSE — прекрасное средство оптимизации приложений. Пойду другим путем. В Симпсонах — 21 сезон (кстати, это — самый длинный сериал в истории американского ТВ). В честь этого я приведу 21 интересный факт про Intel SIMD. Надеюсь, что действительно интересный — даже знатокам SIMD.
«The Simdsons» — финал
Знаете ли вы, что Гомер Симпсон, глава семейства «The Simpsons», когда-то действительно официально работал на компанию Интел, причем довольно успешно? А именно, он рекламировал
Ну а под катом можно посмотреть завершение предыдущего поста с 21 любопытными фактами про Intel SIMD.
HTML5 и события сервера (обновлено)
Помимо уже упомянутого мною двунаправленного коммуникационного канала известного как WebSocket, HTML5 включаетв себя также сервер-push технологию Server-Sent Events (SSE). В то время как WebSocket широко обсуждается, доступно множество реализаций серверов WebSocket, технология уже почти в полном объеме доступна в браузере Google Chrome, SSE, по большей части остаются в тени.
Мы привыкли что HTTP ограничен моделью запрос-ответ, что значит: клиент посылает запрос HTTP и ожидает на него HTTP-ответ. По сути, сервер не может сообщить что-либо клиенту до тех пор пока клиент его его «не попросит». Даже для такой тривиальной вещи как онлайн статус пользователя, нам надо прибегать к различным уловкам. Ну вы знаете – неугомонная изобретательность энтузиастов породила множество таких решений, на что есть собирательное имя Comet. Впрочем, цитируя экспертов: «Comet есть не что иное как гигантский хак». Похоже, HTML 5 призван обогатить нас нативными возможностями, на смену ныне используемому Comet. В случе SSE, HTML5 предоставляет API для открытия специального HTTP соединения для принятия уведомлений со стороны сервера. Взгляните, на то какой простой интерфейс
Мы привыкли что HTTP ограничен моделью запрос-ответ, что значит: клиент посылает запрос HTTP и ожидает на него HTTP-ответ. По сути, сервер не может сообщить что-либо клиенту до тех пор пока клиент его его «не попросит». Даже для такой тривиальной вещи как онлайн статус пользователя, нам надо прибегать к различным уловкам. Ну вы знаете – неугомонная изобретательность энтузиастов породила множество таких решений, на что есть собирательное имя Comet. Впрочем, цитируя экспертов: «Comet есть не что иное как гигантский хак». Похоже, HTML 5 призван обогатить нас нативными возможностями, на смену ныне используемому Comet. В случе SSE, HTML5 предоставляет API для открытия специального HTTP соединения для принятия уведомлений со стороны сервера. Взгляните, на то какой простой интерфейс
Создание приложений реального времени с помощью Server-Sent Events
Буквально недавно стало известно, что Firefox 6 получит SSE (уже есть в Opera 10.6+, Chrome, WebKit 5+, iOS Safari 4+, Opera Mobile 10+) так, что поддержка более половины всех браузеров (охват аудитории пользователей) уже не за горами. Настало время присмотреться к этой технологии. SSE предложил Ian Hickson более 7 лет назад, но только год назад она стала появляться в браузерах. У нас же есть WebSockets зачем нам ещё один какой-то протокол?! Но во всем есть свои плюсы и минусы, давайте посмотрим чем же SSE может быть полезен.
Идея SSE проста — клиент подписывается на события сервера и как только происходит событие — клиент сразу же получает уведомление и некоторые данные, связанные с этим событием. Чтобы понять полезность протокола SSE необходимо сравнить его с привычными методами получения событий, вкратце объясню их суть:
Идея SSE проста — клиент подписывается на события сервера и как только происходит событие — клиент сразу же получает уведомление и некоторые данные, связанные с этим событием. Чтобы понять полезность протокола SSE необходимо сравнить его с привычными методами получения событий, вкратце объясню их суть:
Реализация HTTP server push с помощью Server-Sent Events
Из песочницы
На эту тему было уже много статей, но раскрыта далеко не вся правда. Для тех, кто пропустил — читайте Создание приложений реального времени с помощью Server-Sent Events .
Как же работает Server-Sent-Events?
Об истории реализаций memcpy и их производительности
void * memcpy ( void * destination, const void * source, size_t num );
Казалось бы, что там сложного? А о реализациях этой функции можно написать целую историю.
Когда я смотрю на окно своего любимого рабочего инструмента — профилировщика Vtune XE, очень часто вижу, что он в очередной раз обнаружил, что значительное время потратилось на копирование памяти. Так и обычно и написано: clock ticks spent in libgcc/[g]libc/kernel memcpy — XX%.
Наверное, поэтому memcpy часто переписывался, например в lkml частенько появляются подобные треды. (Больше реализаций, скорее всего, есть только у сортировок). Казалось бы, в отличие от сортировки, где есть много вариантов и алгоритмов с копированием памяти все просто. На самом деле, даже если говорить о корректности, а не производительности, возможны варианты. (В подтверждение тому — обсуждение эпического бага с участием Линуса Торвальдса и Ульриха Дреппера).
Еще во времена 8086, то есть тридцать четыре года назад, внутри реализации memcpy был следующий код:
mov [E]SI, src
mov [E]DI, ptr_dst
mov [E]CX, len
rep movsb
(все проверки и т.д. здесь и далее опущены для простоты)
Что же изменилось с тех пор? Под катом ассемблерный код и ни одной картинки.
Казалось бы, что там сложного? А о реализациях этой функции можно написать целую историю.
Когда я смотрю на окно своего любимого рабочего инструмента — профилировщика Vtune XE, очень часто вижу, что он в очередной раз обнаружил, что значительное время потратилось на копирование памяти. Так и обычно и написано: clock ticks spent in libgcc/[g]libc/kernel memcpy — XX%.
Наверное, поэтому memcpy часто переписывался, например в lkml частенько появляются подобные треды. (Больше реализаций, скорее всего, есть только у сортировок). Казалось бы, в отличие от сортировки, где есть много вариантов и алгоритмов с копированием памяти все просто. На самом деле, даже если говорить о корректности, а не производительности, возможны варианты. (В подтверждение тому — обсуждение эпического бага с участием Линуса Торвальдса и Ульриха Дреппера).
Еще во времена 8086, то есть тридцать четыре года назад, внутри реализации memcpy был следующий код:
mov [E]SI, src
mov [E]DI, ptr_dst
mov [E]CX, len
rep movsb
(все проверки и т.д. здесь и далее опущены для простоты)
Что же изменилось с тех пор? Под катом ассемблерный код и ни одной картинки.
Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
По мотивам одного вчерашнего поста про оптимизацию условных переходов при расчете x=sign(a,b)*min(abs(a), abs(b)) якобы в 10 раз. Краткая сводка:
В общем, опять пачка классических методологических ошибок при бенчмарке. Кому интересно, как такие ошибки НЕ делать, подробности, детальный разбор полетов, оптимизация в еще несколько раз и, главное, исходники под катом.
- оптимизация налицо, но размер мнимый: не в 10 раз, а 2.5 раза;
- бенчмарки надо делать правильно: не надо мерить CPU stalls, RAM bandwidth итп вместо исследуемой функции;
- бенчмарки надо делать правильно: иначе могут дико дрожать;
- выставлять только приоритет прикольно, но на коротких бенчмарках зря: +0.5% скорости, -15% дрожания;
- нужно мерить исследуемую функцию и только ее, только так получаешь корректные данные;
- нужно греть проц, нужно считать минимум из N прогонов/секунд, только так побеждаешь дрожание;
- нужно пользовать SSE, с ним получилось 8.6 раз, причем код… читается.
В общем, опять пачка классических методологических ошибок при бенчмарке. Кому интересно, как такие ошибки НЕ делать, подробности, детальный разбор полетов, оптимизация в еще несколько раз и, главное, исходники под катом.
Оптимизация приложений под Android x86: проверенные способы
Любое приложение для Android, даже написанное только на скриптовых и ненативных языках (таких как Java или HTML5), в конечном счёте использует базисные компоненты среды исполнения, которые должны быть оптимизированы. Хорошими примерами для иллюстрации оптимизационных подходов и потребностей являются приложения, использующие технологии мультимедиа и дополненной реальности, описанные ниже. Для платформы Android (смартфоны и планшеты) Intel использует различные виды процессоров Atom, имеющих SSSE3 уровень векторизации и обычно 2 ядра с гипертредингом – считайте это намеком :) Для тех, кто намек понял, под катом – история оптимизации и распараллеливания одного конкретного приложения израильской компании iOnRoad — iOnRoad.
Новые решения старой задачи
Tutorial
Или перевод велосипеда на реактивную тягу
Существует одна очень старая задача, возраст которой равен возрасту Американского Стандартного Кода для Обмена Информацией. Конкретнее — это задача преобразования целого числа в его шестнадцатеричное представление ASCII строкой.
В данной публикации будем рассматривать преобразование целого беззнакового шестидесятичетырехбитного числа в строку фиксированной длины без усечения старших нулей.
Задача на первый взгляд кажется элементарной. Она и была бы таковой, если бы таблица ASCII была другой. Но имеем, то что имеем.
Все решения будут только для IA-32 и Intel 64 архитектуры.
История одного бага: выравнивание данных на x86
Перевод
Однажды мне пришлось вычислять сумму векторов целых чисел.
Звучит необычно. Кому понадобится делать это в реальной жизни? Обычно такие вычисления встречаются только в задачках из начальной школы или бенчмарках компилятора. Но сейчас это случилось на самом деле.
В реальности стояла задача проверить контрольную сумму заголовков IPv4, которая является суммой обратных кодов (дополнений до единицы) двухбайтных машинных слов. Проще говоря, это означает сложение всех слов и всех битов переноса, которые производятся в процессе. У этой процедуры есть несколько приятных особенностей:
Звучит необычно. Кому понадобится делать это в реальной жизни? Обычно такие вычисления встречаются только в задачках из начальной школы или бенчмарках компилятора. Но сейчас это случилось на самом деле.
В реальности стояла задача проверить контрольную сумму заголовков IPv4, которая является суммой обратных кодов (дополнений до единицы) двухбайтных машинных слов. Проще говоря, это означает сложение всех слов и всех битов переноса, которые производятся в процессе. У этой процедуры есть несколько приятных особенностей:
- её можно эффективно выполнить с помощью процессорной инструкции
ADC(к сожалению, эта функция недоступна в C); - её можно выполнить на словах любого размера (можете добавить по желанию восьмибайтные значения, только результат следует уменьшить до двух байт и добавить все биты переполнения);
- она нечувствительна к порядку следования байтов (удивительно, но это так).
Как я сделал самый быстрый ресайз изображений. Часть 0
Здравствуйте, меня зовут Саша, я написал самый быстрый ресайз изображений для современных х86 процессоров. Я так утверждаю, поскольку все остальные библиотеки, которые я сумел найти и протестировать, оказались медленнее. Я занялся этой задачей, когда работал над оптимизацией ресайза картинок на лету в Uploadcare. Мы решили открыть код и в результате появился проект Pillow-SIMD. Любой желающий с легкостью может использовать его в приложении на языке Python.
Любой код выполняется на конкретном железе и хорошей оптимизации можно добиться, только понимая его архитектуру. Всего я планирую выпустить 4 или 5 статей, в которых расскажу как применять знание архитектуры железа для оптимизации реальной задачи. Своим примером я хочу побудить вас оптимизировать другие прикладные задачи. Первые две статьи выйдут в течение недели, остальные — по мере готовности.
Как я сделал самый быстрый ресайз изображений. Часть 1, общие оптимизации
В пилотной части я рассказал о задаче как можно подробнее. Рассказ получился долгим и беспредметным — в нем не было ни одной строчки кода. Но без понимания задачи очень сложно заниматься оптимизацией. Конечно, некоторые техники можно применять, имея на руках только код. Например, кешировать вычисления, сокращать ветвления. Но мне кажется, что некоторые вещи без понимания задачи просто никогда не сделать. Это и отличает человека от оптимизирующего компилятора. Поэтому ручная оптимизация все еще играет огромную роль: у компилятора есть только код, а у человека есть понимание задачи. Компилятор не может принять решение, что значение "4" достаточно случайно, а человек может.
Напомню, что речь пойдет об оптимизации операции ресайза изображения методом сверток в реально существующей библиотеке Pillow. Я буду рассказывать о тех изменениях, что я делал несколько лет назад. Но это не будет повторение слово-в-слово: оптимизации будут описаны в порядке, удобном для повествования. Для этих статей я сделал в репозитории отдельную ветку от версии 2.6.2 — именно с этого момента и будет идти повествование.
Как я сделал самый быстрый ресайз изображений. Часть 2, SIMD
Это продолжение цикла статей о том, как я занимался оптимизацией и получил самый быстрый ресайз на современных x86 процессорах. В каждой статье я рассказываю часть истории, и надеюсь подтолкнуть еще кого-то заняться оптимизацией своего или чужого кода. В предыдущих сериях:
→ Часть 0
→ Часть 1, общие оптимизации
В прошлый раз мы получили ускорение в среднем в 2,5 раза без изменения подхода. В этот раз я покажу, как применять SIMD-подход и получить ускорение еще в 3,5 раза. Конечно, применение SIMD для обработки графики не является ноу-хау, можно даже сказать, что SIMD был придуман для этого. Но на практике очень мало разработчиков используют его даже в задачах обработки изображений. Например, довольно известные и распространенные библиотеки ImageMagick и LibGD написаны без использования SIMD. Отчасти так происходит потому, что SIMD-подход объективно сложнее и не кроссплатформенный, а отчасти потому, что по нему мало информации. Довольно просто найти азы, но мало детальных материалов и разбора реальных задач. От этого на Stack Overflow очень много вопросов буквально о каждой мелочи: как загрузить данные, как распаковать, запаковать. Видно, что всем приходится набивать шишки самостоятельно.
Быстрое удаление пробелов из строк на процессорах ARM
Перевод
Предположим, что я дал вам относительно длинную строку, а вы хотите удалить из неё все пробелы. В ASCII мы можем определить пробелы как знак пробела (‘ ’) и знаки окончания строки (‘\r’ и ‘\n’). Меня больше всего интересуют вопросы алгоритма и производительности, так что мы можем упростить задачу и удалить все байты со значениями меньшими либо равными 32.В предыдущией статье, где я задавал вопрос об удалении пробелов на скорость, лучшим ответом было использование векторизации с помощью 128-битных регистров (SSE4). Оно оказалось в 5-10 раз быстрее подхода в лоб.
Очень удобно, что во всех процессорах имеются 128-битные векторные регистры, также как в процессорах x64. Неужели процессоры ARM могут работать настолько же быстро, как процессоры x64?
Как я сделал самый быстрый ресайз изображений. Часть 3, числа с фиксированной точкой
Я продолжаю подробно рассказывать о приемах оптимизации, позволивших мне написать самый быстрый ресайз изображений на современных x86 процессорах. На этот раз речь пойдет о преобразовании вычислений с плавающей точкой в вычисления с целыми числами. Сперва я расскажу немного теории, как это работает. Затем вернусь к реальному коду, в том числе SIMD-версии.
В предыдущих частях: