C++ *

GPU для сверточных нейросетей и быстрой обработки данных

В среду, 11 декабря, подключайтесь к бесплатному онлайн-митапу от сообщества C++ Russia. В программе всего два доклада — трансляция начнется в 17:00.

«Свертка на GPU и увеличение ее размерности»

Рассказывает: Кирилл Колодяжный (@Mik42), ведущий инженер по разработке ПО, YADRO

Вы познакомитесь с понятием свертки и ее доступными реализациями для NVIDIA GPU. Вместе с докладчиком рассмотрите различные алгоритмы расчета свертки: наивный алгоритм, FFT, GEMM (im2col/col2im), Winograd. Основное внимание уделим тому, как увеличить размерность свертки, так так сейчас наиболее распространена 3D-свертка.

Кирилл покажет простой подход к увеличению размерности с использованием PyTorch и расскажет, почему он не подошел. Также он поделится деталями реализации подхода на основе vol2col, расскажет, как тот позволяет масштабировать размерности и использовать быстрые реализации базовой операции GEMM с использованием cuBLAS и CUTLASS.

«GPU для ускорения фреймворка обработки слабоструктурированных данных Otterbrix: технологии, массивы и производительность»

  Александр Боргардт, техлид DuckStax 

Доклад посвящен ускорению обработки колоночных данных с использованием видеокарт. Александр рассмотрит применение GPU для оптимизации работы с массивами данных, характерных для фреймворка. Особое внимание уделим сравнительному анализу технологий CUDA и OpenCL с точки зрения их эффективности и применимости в данной области. Сравним производительность подходов в нескольких бенчмарках.

Особенно полезен доклад исследователям и специалистам в области высокопроизводительных вычислений, заинтересованных в использовании GPU для обработки больших объемов данных.

Кому подойдет митап: Организаторы ожидают, что участники понимают и могут читать код на С++. Если вы никогда не программировали GPU, на открытии будет введение в технологию.

Митап пройдет онлайн на платформах YouTube и VK Видео:

• Регистрация →

• Чат митапа → 

Это не IDE, а neIDE - простое графическое приложение для быстрого запуска небольших программ на C++. Может пригодиться когда появилась идея или что-то прочитал и хочется быстро протестировать, но нет времени на запуск тяжеловесных IDE типа Visual Studio или открывать в браузере 1001-ю вкладку чтобы протестировать в godbolt.org. Нужно лишь назначить комбинацию клавиш на запуск или создать ярлык в доке. Можно конечно по-быстрому запустить vim, набрать код и ручками напечатать "g++ main.cpp && ./a.out", но мне надоело так постоянно делать, поэтому написал программу, которая все это делает сама. Ближайший аналог - geany - мощный блокнот, где можно прописать свои команды, но она мне показалась слишком перегруженной функционалом.

В общем, представляю neIDE, где есть только кнопка "Run", поле для ввода кода и поле вывода результатов/ошибок. При запуске загружает код-заготовку. Работает только с тем кодом, что в окне ввода. Нет возможности подгружать внешние файлы. Написана на wxWidgets. Компилирует код под с++17, но можно легко скорректировать под нужный стандарт. Заточена на Linux, но при некотором упорстве можно скомпилировать на Windows. Минимум строк кода, можно форкнуть и быстро доработать под свои хотелки.

Ссылки на репозиторий github и gitflic.

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

Приветствую, Земляне! Намедни закончил новый проект на платформе Arduino.

Проект получил название NotOnlyClock (Ну не только же часы), и из названия можно предположить, что устройство представляет из себя часы, отчасти это так, и у вас моментально возникнет вопрос: "Очередные часы? Таких устройств уже существует сотни, если не тысячи." Конечно, с этим сложно поспорить, но там помимо часов есть много других функций (секундомер, таймер, будильник, термометр, гигрометр и барометр), кроме этого, я обеспечил проект полным набором документации (схемы, разводки печатных плат, модель корпуса, исходный код прошивки и т.д.), а также обеспечил все подробными инструкциями по сборке. И в конце концов, если что-то хочется - надо это сделать. Надеюсь это принесет пользу не только мне.

Кликайте сюда, чтобы самостоятельно во всем убедиться.

Чтобы узнавать обо всех обновлениях в числе первых, подписывайтесь на Telegram-канал

Захват переменных в С++ без ошибок? Как?

Попробуем рассказать об этом завтра на нашем бесплатном вебинаре «Ля какие! Лямбды в С++».

Встретимся и поговорим про:

→ Захваты переменных, параметры, возвращаемые значения и типы замыканий.
→ Лямбды в C++20 и C++23.
→ Применение в реальных задачах: передача функций в алгоритмы STL, написание компактных колбэков

⚡️ Спикер: Юрий Вашинко, Tech Lead/Lead Developer с опытом более 15 лет в разработке

📌 15 октября, завтра, в 14:00 мск
📌 Занять место на вебинаре — через бота.

Приходите 🙃

Prime World от Nival отдали в open source

Официальный сервер был выключен в 2021 году.

Лицензия запрещает коммерческое использование - но велкам улучшать игру, комьюнити уже занимается этим. Как насчет сборки для Линукс?

Похоже это первая open source MOBA.

Репозиторий: https://github.com/Nival-Pub/Prime-World, скоро должны форкнуть.

Комьюнити:

https://vk.com/primeworldclassic

Там, если хотите, найдете чат программистов.

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

Привет! На связи команда Neiry Tech, мы занимаемся разработкой BCI-устройств и алгоритмов для использования с ними. Расскажем про ПО Capsule, считывающее и записывающее мозговую активность, и другие физиологические сигналы пользователя. И Capsule API — он помогает нам строить на основе классифицированных метрик и индексов итоговые приложения).

По сути Capsule — библиотека для десктопных и мобильных платформ с собственным графическим интерфейсом. Для быстродействия написали её на C++. Для Capsule API выбрали C.

Для вывода в API на разных платформах иногда пишем нативный код на Android или iOS, ну и обертку на C, чтобы API мог использовать широкий спектр разработчиков — за родным ноутом и в лаборатории.

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

Головной боли добавляют особенности различных платформ — с плавающими задержками протокола BLE, или с реализацией вроде бы базовых вещей. Мы как-то обнаружили, что библиотека, занимающаяся быстрым преобразованием Фурье, нагружала новенькие Apple Silicon на 30%.

Сейчас Capsule и API позволяют работать с данными ЭЭГ и ФПГ на высоком для не лабораторного устройства уровне. Смотрим, радуемся и гордимся.

Хотите поработать с этими данными и нашим API? Присоединяйтесь к хакатону BCI Hack Moscow, регистрация до 15 сентября.

кстати, написал логгер, планирую опубликовать в статью
https://github.com/Fallet666/logger

Привет, Хабр! Держите задачу от наставника курса «Разработчик на С++» Саввы Лебедева. Предлагайте варианты решения в комментариях.

Дан непустой массив целочисленных элементов, где каждый элемент повторяется дважды, кроме одного. Найдите этот одинокий элемент.

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

Пример 1:

Ввод: nums = [2,2,1]
Вывод: 1

Пример 2:

Ввод: nums = [4,1,2,1,2]
Вывод: 4

Пример 3:

Ввод: nums = [1]
Вывод: 1 

Ограничения:

•  1 <= nums.size() <= 3 * 10^4

•  -3 * 10^4 <= nums[i] <= 3 * 10^4

• Каждый элемент в массиве повторяется дважды, кроме одного: он будет единожды.

int FindSingleNumber(vector<int>& nums) {
	...
}

Почему бы не сделать runtime языка С++ проще и легче? почему бы не сделать его перенос в том числе проще? Когда я задался этим вопросом, я решил, что во чтобы то ни стало, я напишу свой RT, для тех, кто пишет под слабые машины, или тех, кто пишет под bare metal среду. результат вы можете посмотреть на гитхабе: вотъ

Когда я работал, я старался максимально всё упростить, при этом сохранив юзабельность. не знаю как для других, но лично мне было важно сохранить исключения, для меня это удобно. но в С++ они жутко дорогие из-за RTTI (RunTime Type Information), и на bare metal реализуется с большим напрягом. выход прост - использовать статусы вместо типов. но чтобы оставить всем знакомый и удобный синтаксис исключений и позволить функциям возвращать что-то вместо статуса, где это везде лепят, я переделал всё на тупо макросах :>

так же я понял, что сложность моей работы и сложность переносимости этой вещицы усложнится, если прям всё с нуля пилить, поэтому просто воспользовался libc, выпилив libc++. Пришлось сделать обёртки над new и delete, но это не так уж и сложно, просто вызывать malloc/free.

Так же я невероятно сильно намучился в попытках сделать всё используя стандартный синтаксис С++. Потратил несколько часов в попытках разобраться как оторвать исключения от использования rtti, возился в флагах, писать cxa, gxx и unwind с нуля, даже лез в ассемблерный код в попытках вырезать надоеду, но по итогу сдался и просто слепил всё из макросов.

Всем добра <3

Всем привет. Возможно, вы помните меня по статьям об изменениях в C++ и о фреймворке 🐙 userver, поэтому сразу к делу. 27 июля я выступаю на конференции C++ Zero Cost Conf, которая пройдёт в Москве и Ереване. Там я поделюсь новостями со встречи Международного комитета по стандартизации языка в Сент-Луисе и расскажу о наших планах на C++26 и C++29. А ещё отвечу на ваши вопросы. Приходите в гости!

Помимо меня, вас также будут ждать: 

• Константин Владимиров, руководитель отдела компиляторов и средств разработки Syntacore. Покажет развитие архитектуры сложного LLVM-based-C++-проекта и конкретные задачи, возникающие при его развитии.

• Андрей Аксёнов, руководитель разработки инфраструктуры поиска Авито/Sphinx. Расскажет историю из продакшена с One Billion Row Challenge, парсингом гигабайтов TSV’шек, десятью странными оптимизациями и боттлнеками вообще везде.

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

• Константин Облаков, старший разработчик браузера Яндекс Поиска и Рекламных технологий. Покажет на практике, как GDB позволяет добиться результатов, недоступных другими методами.

Полный список спикеров и темы докладов смотрите на сайте. 

Если не получится прийти лично, подключайтесь дистанционно.

Интересный пример, когда определение friend T (где T — шаблонный параметр) имеет смысл:

template <class T>
class Badge {
   friend T;
   Badge() { }
};

Допустим, у нас есть какой-нибудь публичный метод, и предполагается, что круг его пользователей ограничен одним классом, например:

class VFS {
   ...
public:
   void register_device(Device&);
   void unregister_device(Device&);
};

Предполагается, что эти методы будут вызываться внутри конструкторов (и деструкторов) Device и нигде (и никем) больше. Но как закрепить наше ожидание на уровне API?

Распространенное решение — вынести (un)register_device в приватную часть, а Device объявить другом:

class VFS {
private:
   friend class Device;
   void register_device(Device&);
   void unregister_device(Device&);
};

И это действительно запрещает всем кроме Device обращаться к данным методам. Но это так же разрешает Device обращаться ко всем остальным членам VFS!

Выразить же желаемое наиболее четко и ясно нам помогает как раз таки класс Badge, приведенный в самом начале статьи: мы можем оставить методы (un)register_device публичными, но при этом сделать их первым аргументом значение Badge<Device>:

class VFS {
    ...
public:
    void reg_Device(Badge<Device>, Device&);
    void unregister_device(Badge<Device>, Device&);
};

Теперь чужак не может использовать эти методы, потому что он не может сконструировать Badge<Device>, а а сам Device может вызывать их где и как пожелает:

Device::Device()
{
    VFS::instance().register_device({}, *this);
}

ZED Online, любительская открытая имплементация знаменитой DOS игры Z - тоже заброшена. Играбельна, но есть проблемки (я завел несколько тикетов), есть краши. Если кто хочет форкнуть и улучшить игру и свой C++.

Вот видео https://www.youtube.com/watch?v=F03PtRb9mvs

Статья в Википедии про оригинал https://en.wikipedia.org/wiki/Z_(video_game) - там написано что рейтинги у игры были высокие.

https://sourceforge.net/projects/zedonline/

Спасибо, хорошего дня.

27 и 28 марта в Лондоне проходила конференция Rust Nation 24. На конференции выступал Ларс Бергстром [Lars Bergstrom], который занимает в Google пост технического директора. Доклад Ларса носил название «Beyond Safety and Speed: How Rust Fuels Team Productivity» (дословно «Кроме безопасности и скорости: как Rust заряжает команду продуктивностью»).

Во время выступления технический директор Google заявил, что команды Rust в Google в два раза продуктивнее команд C++. Этот мощный посыл успел разлететься фотографией с конференции.

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

Как выяснилось, на переписывание на Rust нужно примерно столько же времени и людей, сколько уходит на написание продукта на Go. При этом памяти приложения на Rust используют куда меньше, в них меньше дефектов. Когда компонент на C++ переписывают на Rust при одинаковом размере команд, в два или более раз сокращаются время и усилия как для написания, так и поддержки кода.

Слегка портит картину то, что Бергстром — это ещё и председатель совета директоров Rust Foundation, поэтому делать такие заявления он непосредственно заинтересован.

На записи видеотрансляции с конференции обсуждение деталей производительности идёт с отметки 7:30:13.

Проклятие дженериков 💀

Дженерики могут показаться очень простой темой.
Например, вот так в Java выглядят классные и простые методы интерфейса List:

interface List<E> extends Collection<E> {
	boolean add(E e);
	E set(int index, E element);
}

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

interface Stream<T> extends BaseStream<T, Stream<T>> {
	<R> Stream<R> flatMap(Function<? super T, ? extends Stream<? extends R>> mapper);
}

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

Из-за таких сложностей, в языке Go (философия которого - простота и минимализм) дженерики появились аж через 12 лет после релиза языка. А первый коммент про то что нужны дженерики появился меньше чем через 24 часа🙃

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

• С++ вышел в 1979, дженерики - 1986

• Java - 1996, дженерики - 2004

• C# - 2001, дженерики - 2005

• Go - 2009, дженерики - 2021

Состоялся релиз открытой библиотеки Intel x86-simd-sort 5.0, в которой представлен новый API для сортировки пользовательских объектов C++ с помощью object_qsort.

Согласно тестам разработчиков проекта, новая поддержка сортировки пользовательских объектов C++ может быть в 4-5 раз быстрее, чем использование std::sort в системах AVX-512, но в конечном итоге влияние на производительность будет варьироваться в зависимости от используемых задач.

Также в выпуске x86-simd-sort 5.0 добавлен новый API-интерфейс keyvalue_qsort для сортировки массивов, представляющих пары «ключ-значение», и этот новый API тоже работает намного быстрее.

В версии x86-simd-sort 5.0 добавлена поддержка AVX2 для методов argosrt и argselect. Эти дополнения AVX2 уже вошли в исходную версию NumPy для NumPy 2.0, причем эта библиотека Python была одним из первых проектов, который добавил поддержку высокопроизводительной библиотеки Intel.

Состоялся релиз мажорной версии библиотеки GLM 1.0.0 (OpenGL Mathematics).

OpenGL Mathematics (GLM) — это header only математическая библиотека C++, предназначенная для графического ПО, основанная на спецификациях языка шейдинга OpenGL (GLSL).

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

Проект GLM не ограничивается функциями GLSL. Системные расширения проекта основаны на extension conventions GLSL и предоставляют расширенные возможности, включая матричные преобразования, кватернионы, упаковку данных, случайные числа, шум и так далее.

Разработчики пояснили, что библиотека стабильно работает с OpenGL, но также обеспечивает совместимость с другими сторонними библиотеками и SDK. Это хороший кандидат для программного рендеринга (трассировка лучей/растеризация), обработки изображений, физического моделирования и любого контекста разработки, требующего простой и удобной математической библиотеки.

GLM написан на C++98, но может использовать преимущества C++11, если он поддерживается компилятором. Это независимая от платформы библиотека, независимая и официально поддерживающая следующие компиляторы:

• GCC 4.7 and higher;

• Intel C++ Compose XE 2013 and higher;

• Clang 3.4 and higher;

• Apple Clang 6.0 and higher;

• Visual C++ 2013 and higher;

• CUDA 9.0 and higher (experimental);

• Any C++11 compiler.

Что нужно учитывать, используя std::vector?

Основные плюсы и минусы происходят от линейного расположения элементов в памяти и ограничений, которые это расположение накладывает.

std::vector имеет:

• [+] Доступ к произвольному элементу за O(1).

• [-] Проблема: При превышении capacity - долгая вставка нового элемента (даже в конец), тербующая поэлементного копирования.
  
  Решение: С этим можно побороться, если зарезервировать заранее всю нужную память под все элементы, но мы редко знаем каким будет максимальное количество элементов. И памяти на все процессы так не напасёшься, даже учитывая оптимизацию современных ОС: когда ОС физически выделяет память только когда процесс начинает её использовать.

• Хороший cache coherence:

  • [+] В общем случае это означает более быстрый обход контейнера vector по сравнению с контейнерами а-ля list (map, set, forward_list etc.).

  • [-] Проблема: В частности, нужно разбиратсья с cache sharing.
    Если vector параллельно обходят два потока и каждый из них модифицирует его содержимое, то вероятно кэши этих потоков будет смотеть на смежную область памяти vector-а. Тогда каждая из записей будет инвалидировать содержимое кеша ядра другого потока, тем самым приводя к регулярному refetch-у. В некоторых корнер кейсах замена vector на list может внезапно привести к улучшению перфоманса.
    
    Решение: Лечится такая проблема обычно увеличением размера элемента до размера кэшлайна. Либо же выдачей каждому потоку по N элементов, где (N * sizeof(ElementT)) == cacheline size.

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

Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра.

С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin), один из ключевых разработчиков ядра в компании Intel и создатель таких проектов, как syslinux, klibc и LANANA, разработавший для ядра Linux систему автомонтирования, реализацию RAID 6, драйвер CPUID и x32 ABI. По мнению Анвина, который является автором многочисленных макросов и ассемблерных вставок в ядре, с 1999 года языки С и С++ значительно продвинулись вперёд в своём развитии, а язык С++ стал лучше подходить для разработки ядра операционных систем, чем С.

Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat.

Источник: OpenNET.

Вышел исследовательский проект Vcc (Vulkan Clang Compiler), нацеленный на создание компилятора, способного транслировать код на языке С++ в представление, выполняемое на GPU, поддерживающих графический API Vulkan. В отличие от моделей программирования GPU на базе языков шейдеров GLSL и HLSL в Vcc развивается идея полного отказа от использования отдельных языков шейдеров и предоставляется возможность прямой компиляции кода C/C++ для Vulkan. Наработки проекта Vcc распространяются под лицензией MIT.

Для компиляции кода в Vcc задействованы компоненты проекта LLVM и Clang в качестве фронтенда. Для выполнения на GPU развивается собственное промежуточное представление шейдеров Shady и компилятор для преобразования кода в это представление. По возможности поддерживается компиляция обычного стандартного кода C/C++, а для поддержки специфичных для GPU возможностей предоставляются дополнительные встроенные функции.

В Vcc применяются штатные возможности C/C++ для управления ходом выполнения программы, включая возможность использования оператора goto. Допускается вызов функций, рекурсивное выполнение функций, использование физических указателей, теггированных указателей и указателей на функции, выполнение арифметических операций над указателями, а также определение раскладки типов в памяти. Из ограничений реализации упоминается отсутствие поддержки исключений C++, недоступность функций malloc/free и непереносимость функций и указателей между хост-системой и GPU.

Источник: OpenNET.