Предыдущая часть вызвала бурную дискуссию, в ходе которой выяснилось, что AVX/AVX2 на самом деле есть в десктопных CPU, нет только AVX512. Поэтому продолжаем знакомиться с SIMD, но уже с современной его частью — AVX. А так же разберём некоторые комментарии:

• медленнее ли _mm256_load_si256, чем прямое обращение к памяти?
• влияет ли на скорость использование AVX команд над SSE регистрами?
• действительно ли так плохо использовать _popcnt?

Есть класс задач, которые нельзя ускорить за счёт оптимизации алгоритмов, а ускорить надо. В этой практически тупиковой ситуации к нам на помощь приходят разработчики процессоров, которые сделали команды, позволяющие выполнять операции на большим количеством данных за одну операцию. В случае x86 процессоров это инструкции сделанные в расширениях MMX, SSE, SSE2, SSE3, SSE4, SSE4.1, SSE4.2, AVX, AVX2, AVX512.

В качестве «подопытного кролика» я взял следующую задачу:

Есть неупорядоченный массив arr с числами типа uint16_t. Необходимо найти количество вхождений числа v в массив arr.

Классическое решение, работающее за линейное время выглядит так:

int64_t cnt = 0;
for (int i = 0; i < ARR_SIZE; ++i)
    if (arr[i] == v)
        ++cnt;

В таком виде бенчмарк показывает следующие результаты:

------------------------------------------------------------
Benchmark                     Time           CPU Iterations
------------------------------------------------------------
BM_Count                   2084 ns       2084 ns     333079

Под катом я покажу как его ускорить в 5+ раз.

Алгоритм Wave Function Collapse генерирует битовые изображения, локально подобные входному битовому изображению.

Локальное подобие означает, что

• (C1) Каждый паттерн NxN пикселей в выходных данных должен хотя бы раз встречаться во входных данных.
• (Слабое условие C2) Распределение паттернов NxN во входных данных должно быть подобным распределению паттернов NxN в значительно большом количестве наборов выходных данных. Другими словами, вероятность встречи определённого паттерна в выходных данных должна быть близка к плотности таких паттернов во входных данных.

В течение последних 13 лет я работаю в My.Com. Это очень большая компания, состоящая из более чем 10 разнообразных студий, делающих игры, в первую очередь мобильные. Такой масштаб подразумевает большую плотность запусков новых игр, где-то по 3-4 игры в год. Как вы понимаете, работа с таким потоком требует огромного умения оперативно и точно оценивать проекты на каждом этапе их создания.

И здесь главная сложность связана с проектами, демонстрирующими спорные результаты. Если со слабыми/сильными всё понятно, то вот с оценкой последних всегда возникают проблемы, так как задача уходит из плоскости оценки прямых показателей в плоскость оценки возможного потенциала проекта.

Мы пообщались с потрясающими разработчиками Atomontage, пытаясь разобраться, смогут ли воксели вернуться и победить пиксели.

Воксельная разработка

Бранислав: в 2000-2002 годах я участвовал в соревнованиях европейской демосцены. Я написал несколько 256-байтных демо (также называемых intro) под ником Silique/Bizzare Devs (см. «Njufnjuf», «Oxlpka», «I like ya, Tweety» и «Comatose»). Каждое из интро генерировало в реальном времени воксели или графику из облака точек. И воксели, и облака точек являются примерами сэмплированной геометрии.

Интро выполняли свою задачу всего в 100 инструкциях процессора, таких как ADD, MUL, STOSB, PUSH и им подобных. Однако из-за самой природы такого типа программ на самом деле десятки инструкций использовались просто для правильной настройки, а не для генерации самой графики. Тем не менее этих 50 с лишним инструкций, которые по сути являлись элементарными математическими операциями или операциями с памятью, оказалось достаточно для генерации довольно красивой подвижной 3D-графики в реальном времени. Все эти 256-байтные интро выигрывали с первого по третье места. Это заставило меня осознать, что если такую 3D-графику возможно создавать без полигонов, то в играх и других приложениях можно достичь гораздо большего с помощью того же принципа: использования сэмплированной геометрии вместо полигональных мешей. Решение заключается в простоте. Я понял, что доминировавшая тогда парадигма, основанная на сложных и фундаментально ограниченном (необъёмном) представлении данных, уже готова была упереться в потолок возможностей. То есть настало подходящее время испробовать эту «новую», более простую парадигму: объёмную сэмплируемую геометрию.

Часть 1. Математика

Введение

Мы так привыкли к взаимодействию с окружающим нас миром, что не задумываемся о том, насколько сложно двигаются наши руки и ноги. В академической литературе задача управления манипулятором робота называется инверсной кинематикой. Кинематика обозначает "движения", а понятие "инверсная" связано с тем, что обычно мы не управляем самой рукой. Мы управляем «двигателями», поворачивающими каждую отдельную часть. Инверсная кинематика — это задача определения того, как перемещать эти двигатели, чтобы сдвинуть руку в конкретную точку. И в своём общем виде эта задача чрезвычайно сложна. Чтобы вы понимали, насколько она сложна, то можете вспомнить о таких играх, как QWOP, GIRP или даже Lunar Lander, в которой вы выбираете не куда двигаться, а какие мускулы (или ускорители) приводить в действие.

Задача управления подвижными приводами распостраняется даже на область робототехники. Вас не должно удивлять то, что на протяжении веков математики и инженеры смогли разработать множество решений. В большинстве 3D-редакторов и игровых движков (в том числе и в Unity) есть наборы инструментов, позволяющих выполнять риггинг человекоподобных и звероподобных существ. Для различных схем (манипуляторов роботов, хвостов, щупалец, крыльев и т.д.) встроенных решений обычно не существует.

Заметка задумывалась как продолжение предыдущей заметки о том, как собираем C++ креши на различных платформах включая asm.js и wasm. По количеству материала, это тянет только на заметку, а не полноценную статью, да и нужно быть наркоманом, что бы делать нативный клиент на C++, а потом засовывать его в браузер.

Но! Мы недавно делали доклад об опыте использования wasm на cppconf. Оказалось, что наркоманов больше чем я думал, да и новость Beta for Qt for WebAssembly Technology Preview. Данная заметка может быть полезна, если вы захотите сделать отлов крешей в production окружении.

Под катом:

• отлов падений в asm.js и wasm;
• как выглядит стек вызовов в Safari, Firefox, Chrome.

В предыдущей части мы рассмотрели основные проблемы написания нативных плагинов на Unity под iOS и Android, а также методы их решения для iOS. В этой статье я опишу основные рецепты по решению этих проблем для Android, стараясь сохранить схожую структуру взаимодействия и порядок их рассмотрения.

Геометрический Шейдер

Между этапами выполнения вершинного и фрагментного шейдера есть опциональная стадия, предназначенная для выполнения геометрического шейдера. На входе у геометрического шейдера оказывается набор вершин, формирующих один из допустимых в OpenGL примитивов (точки, треугольники, …). В результате своей работы геометрический шейдер может преобразовать этот набор вершин по своему усмотрению, прежде чем передать его на следующую шейдерную стадию. При этом стоит отметить самую интересную особенность геометрического шейдера: в процессе своей работы набор входных вершин может быть преобразован к представлению совершенно иного примитива, а также может сгенерировать совершенно новые вершины на основе входных данных, увеличивая итоговое количество вершин.

Вступление

Многие языки программирования имеют такой инструмент, как properties: C#, Python, Kotlin, Ruby и т.д. Этот инструмент позволяет вызывать какой-то метод класса при обращении к его "полю". В стандартном C++ их нет если хотите узнать, как можно их реализовать, прошу под кат.

Вам приходилось сталкиваться с необходимостью взаимодействия кода на C# и native-C++ (или скорее С)? Причины могли быть разными: библиотека уже есть, на С/С++ написать проще, разработка частей приложения ведётся разными командами, _______________ (нужное вписать).

Известно, что языки базируются на совершенно разных наборах аксиом.

В С# (CLR, если точнее) вы имеете дело с типами фиксированных размеров (за редкими оговорками), код может быть скомпилирован JIT-компилятором под любую из поддерживаемых целевых платформ (если явно не оговорено иное).

В мире C++ всё совсем иначе: одни и те же типы могут иметь разные размеры при компиляции на разные платформы (привет, size_t), код генерируется по-разному для разных платформ, операционных систем и прочих прелестей.

Под катом будем пробовать их подружить с учётом указанных особенностей.

На сайте майкрософт размещена информация о том, как можно проверить подвержена ли ОС атакам meltdown. Там же имеется информация, как можно отключить последнее исправление.



Учитывая, что в интернете не утихают слухи о катастрофическом падении производительности и даже появляются сравнительные тесты «до» и «после» информация по отключению данной заплатки может оказаться полезной.

По просьбам трудящихся, пишу о внутреннем устройстве WebAssembly.

WebAssembly — байткод для стековой виртуальной машины. Значит, для запуска кода такой нужны интерпретатор, стек и хранилище кода. Если мы хотим взаимодействовать с внешним миром, нужен интерфейс к внешней машине, хосту. Дополнительно стандарт определяет две структуры: непрерывную память и таблицы. В версии MVP стандарта их может быть по одной штуке каждого, или не быть вовсе.

В итоге, наш технобордель выглядит так:

• Интерпретатор
• Интерфейс к хосту
• Стек
• Хранилище кода
• Память
• Таблица

Займёмся делом!

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

Инфографика:



Когда нам нужно оптимизировать код, мы должны отпрофилировать его и упростить. Однако, иногда имеет смысл просто узнать приблизительную стоимость некоторых популярных операций, чтобы не делать с самого начала неэффективных вещей (и, надеюсь, не профилировать программу позже).

Это руководство посвящено написанию простейшего компилятора на LLVM. Никакой предварительной подготовки не требуется.



Входным языком нашего компилятора будет BF. Это классический «игрушечный» язык для компиляторов, и даже есть компилятор BF в примерах к LLVM! В этом посте я приведу процесс написания компилятора с пояснениями.

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Елена Соловьева, менеджер проектов в компании Лаборатория Касперского, специально для блога Нетологии поделилась советами о том, как вести деловую переписку с иностранными коллегами и партнерами на английском языке. Статья участвует в конкурсе.

Электронные сообщения дают возможность быстро обмениваться информацией на больших расстояниях. По скорости передачи идеи это приравнивает их к телефонному разговору. Однако электронные письма сохраняются на почтовых серверах и используются как печатное свидетельство наших слов. Поэтому электронная переписка требует ответственного отношения.

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

Вдохновение на написание данной статьи было получено после прочтения похожей публикации для архитектуры x86 [1].

Данный материал поможет тем, кто хочет понять, как устроены программы изнутри, что происходит до входа в main и для чего всё это делается. Также я покажу как можно использовать некоторые особенности библиотеки glibc. И в конце, как и в оригинальной статье [1] будет визуально представлен пройденный путь. В большинстве своём статья представляет собой разбор библиотеки glibc.

Итак, начнём наш поход. Будем использовать Linux x86-64, а в качестве инструмента отладки — lldb. Также иногда будем дизассемблировать программу при помощи objdump.

Исходным текстом будет обычный Hello, world (hello.cpp):

#include <iostream>
int main()
{
        std::cout << "Hello, world!" << std::endl;
}

Продолжение цикла обзорных статей с конференции CppCon 2017.

На этот раз очень интересное выступление от автора Compiler Explorer (godbolt.org). Обязательно читать всем, кто для быстроты умножает на 2 с помощью сдвига (по крайней мере, на x86-64). Если вы знакомы с ассемблером x86-64, то можете перемотать до разделов с примерами ("Умножение", "Деление" и т.д). Далее слова автора. Мои комментарии в квадратных скобках курсивом.

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

Продолжаю серию публикаций Fil по CppCon 2017. В докладе представлены ранние наработки по добавлению рефлексии и кодогенерации в C++, а также по метаклассам, которые позволят генерировать части классов C++. В стандарт эти новшества попадут не ранее, чем в C++23.