Это продолжение цикла статей о том, как я занимался оптимизацией и получил самый быстрый ресайз на современных x86 процессорах. В каждой статье я рассказываю часть истории, и надеюсь подтолкнуть еще кого-то заняться оптимизацией своего или чужого кода. В предыдущих сериях:

→ Часть 0
→ Часть 1, общие оптимизации

В прошлый раз мы получили ускорение в среднем в 2,5 раза без изменения подхода. В этот раз я покажу, как применять SIMD-подход и получить ускорение еще в 3,5 раза. Конечно, применение SIMD для обработки графики не является ноу-хау, можно даже сказать, что SIMD был придуман для этого. Но на практике очень мало разработчиков используют его даже в задачах обработки изображений. Например, довольно известные и распространенные библиотеки ImageMagick и LibGD написаны без использования SIMD. Отчасти так происходит потому, что SIMD-подход объективно сложнее и не кроссплатформенный, а отчасти потому, что по нему мало информации. Довольно просто найти азы, но мало детальных материалов и разбора реальных задач. От этого на Stack Overflow очень много вопросов буквально о каждой мелочи: как загрузить данные, как распаковать, запаковать. Видно, что всем приходится набивать шишки самостоятельно.

Изменение размера изображения с учётом содержимого (Content Aware Image Resize), жидкое растяжение (liquid resizing), ретаргетинг (retargeting) или вырезание шва (seam carving) относятся к методу изменения размера изображения, где можно вставлять или удалять швы, или наименее важные пути, для уменьшения или наращивания изображения. Об этой идее я узнал из ролика на YouTube, от Shai Avidan и Ariel Shamir.

В этой статье будет рассмотрена простая пробная реализация идеи изменения размера изображения с учётом содержимого, естественно на языке Rust.

Для подопытной картинки, я поискал по запросу¹ "sample image", и нашел её²:

В сфере игр меня, среди прочего, увлекает то, насколько их потребление может отличаться в разных странах в зависимости от множества факторов, среди которых — размер рынка, вкусы потребителей и даже политика. Мы в Alconost перевели беседу с Джошем Барнсом — опытным специалистом, работавшим с ведущими компаниями-разработчиками мобильных игр, например Zynga, Ludia и многими другими студиями: Джош помогает совершать «стратегические набеги» на азиатские рынки. Он рассказал об индустрии мобильных игр в Японии, а именно о том, что делает ее настолько отличной от многих других рынков, и что понадобится издателю западной игры, чтобы добиться там успеха.

Что именно делает японский рынок мобильных игр таким интересным?

В первую очередь — огромные возможности: население Японии составляет менее половины (40 %) от населения США, однако рынок мобильных игр при этом не уступает американскому. Также известно, что средний доход на скачивание в случае японских пользователей невероятно высок: несколько лет назад он составлял более 5 долл. США для приложений любой категории (игровых и неигровых), а теперь он, скорее всего, еще выше.

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

Перевод статьи Аллана О’Доннелла Learning C with GDB.

Исходя из особенностей таких высокоуровневых языков, как Ruby, Scheme или Haskell, изучение C может быть сложной задачей. В придачу к преодолению таких низкоуровневых особенностей C, как ручное управление памятью и указатели, вы еще должны обходиться без REPL. Как только Вы привыкнете к исследовательскому программированию в REPL, иметь дело с циклом написал-скомпилировал-запустил будет для Вас небольшим разочарованием.

Недавно мне пришло в голову, что я мог бы использовать GDB как псевдо-REPL для C. Я поэкспериментировал, используя GDB как инструмент для изучения языка, а не просто для отладки, и оказалось, что это очень весело.

Сегодня мы представляем материал от наших давних партнеров, компании Music Paradise, которые, как вы помните, уже делились с Хабром секретами создания музыкальных приложений в нашей совместной статье «Внедрение социальных сервисов в неигровое приложение». На этот раз специалисты из команды расскажут о специфике реализации базовых функций утилиты Audio Editor, изначально написанной для iOS и Mac устройств, на новой платформе — Windows — и о том методе, который они применяли при адаптации.



«В этой статье мы рассмотрим один из самых доступных способов получения аудиоданных из файла. Извлечение аудиоданных является краеугольным камнем для всех разработчиков, которые делают первые шаги в работе со звуком, однако внимания ей уделяется на удивление мало. Проблема ощущается особенно остро при попытках найти готовые решения или инструкции для UWP в интернете: в большинстве случаев ответа не получаешь вообще или же приходится довольствоваться устаревшими решениями. Между тем, при работе со звуком извлечение данных имеет значимый смысл, давая разработчику возможность редактировать данные: копировать, добавлять, изменять, путем наложения эффектов, визуализировать их на экране пользователя. Именно о визуализации сегодня и пойдет речь. Несмотря на существование специальных библиотек для работы с аудиоданными в галерее NuGet, мы построим логику приложения на самостоятельной обработке байтов аудиофайла. Таким образом, в процессе мы узнаем больше о структуре wav-файла и убедимся на практике, что работа с аудио данными — это не так уж сложно.

Прошло 1 апреля. Часто первоапрельские шутки, выложенные в Интернете, продолжают свое шествие, и всплывают совершенно в неожиданное время. О такой шутке про язык Си и будет эта статья. В каждой шутке есть только доля шутки. Код из нее я взял на вооружение для беглого тестирования на знание языка Си.

Надо написать программу (с пояснениями), в которой будет работать следующая строка:

for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

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

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


Вот так выглядит здание научного центра Глазго: даже фонари рядом на солнечных элементах



Мы пошли к авторам «Фиксиков» и сказали – давайте лицензию. Дальше – стандартный путь продукта. Главный вопрос был в том, какие опыты брать для шестилеток. И вот здесь нам пригодился опыт детских секций в научных центрах в разных городах. Про Кейптаун я уже рассказывал, поэтому сейчас хотел бы показать отличный научный центр Глазго и рассказать, что и как отразилось на будущей игре.

В общем, давайте начнём экскурсию. Добро пожаловать в Глазго.
Внимание, трафик. Под катом много картинок.

Привет всем, не знаю зачем это надо, но может кому пригодится…

Дисклеймер: Я ни в коем случае не являюсь профессиональным Си программистом.

Что нам понадобится:

1. Любой компьютер на Linux, Ubuntu, Centos, MacOS… с доступом к порту 443 или 8443 из интернета.
2. Любой Си компилятор
3. Бибилиотеки openssl, libssl-dev («apt-get install openssl libssl-dev» в терминале, для Ubuntu)

I saw a book entitled «Die GNU Autotools» and I thought «My feelings exactly». Turns out the book was in German¹. ©

Можно долго рассуждать о несовершенстве сего инструментария, о превосходстве CMake/QMake/подставьте_вашу_любимую систему сборки, но проекты, использующие autotools, окружают нас повсюду, и стоит как минимум знать, что это за зверь и с чем его едят, чтобы при попытке сделать, а то и отправить разработчикам патч, не править автосгенерированные файлы, чем я не так давно занимался.

Так же следует понимать, что именно autoconf системой сборки не является вообще, это система конфигурации перед сборкой. autoconf почему-то многие считают неким монстром, «проверяющим 15 давно несуществующих версий компилятора Fortran, а потом поддержку ключей этими компиляторами», что не совсем верно, ибо оно делает ровно то, что ему скажут. Другое дело, что многие просто копипастят его конфиг из проекта в проект, в итоге результат получается ужасающим.

В данной статье (планируется всё же осилить цикл) я хотел бы рассказать про autoconf, зачем он нужен и как его использовать.