Привет Хабр! В прошлый раз писал про проект по рентгеновской инспекции печатных плат. Сейчас мы сильно продвинулись, есть рабочий прототип софта плюс “потыкали палочкой” в Эльбрус. Про этот опыт я и хочу рассказать.

Интро

На старте проекта нам удалось найти дополнительное финансирование, основным условием была полная кроссплатформенность ПО, в том числе поддержка отечественных процессоров. На тот момент наиболее производительным вариантом для десктоп машин был Эльбрус 8С (пока он им и остается, 8СВ еще вроде не вышел). Мы купили две станции «Эльбрус 801-РС» напрямую от МЦСТ. Сейчас их стоимость указана на сайте, год назад были чуть дороже.

Из курьезных мелочей, с которыми столкнулись при закупке – бумажные заявки на поставку. Сразу советую заключить договор NDA, это даст доступ к свежим инструментам разработчика (оформление около месяца). Приехали машины быстро, по комплектации – есть проблема с кастомизацией на стороне МЦСТ. Проще докупить и поставить самим нужные видеокарты или периферию. Перечень проверенного оборудования/чипов карт пока есть только в багтрекере МЦСТ, хотя стоило бы опубликовать список на вики ресурсе по Эльбрусам.

Всем привет!

До C++ Russia осталось меньше месяца — самое время показать вам, о чём там расскажут-то.

Как обычно, спектр тем будет широкий — от прикладных («решаем нетривиальные задачи средствами современного CMake») до довольно академических («как лямбды в C++ и других языках соотносятся с исходной идеей лямбд»). Как обычно, состав спикеров интересный, и о некоторых технологиях поведают их непосредственные авторы: обсудим Compiler Explorer с Мэттом Годболтом, а про GWP-ASan расскажет Константин Серебряный.

А подробнее о блоках программы и каждом докладе — под катом.

В связи с тем, что у меня не так много времени для ресерча каких-то новых штук и написания статей о них, я решил перевести серию уроков по Vulkan. Надеюсь, что мои переводы будут кому-то полезны и не очень плохого качества. Для начала обучения — прошу под кат.

Автор оригинала дал свое согласие на перевод. Также, когда я доперевожу все статьи и у меня будет время отформатировать их для github, он добавит русский перевод на свой сайт.

Введение

Популярные способы и их критика

В этом году, когда из-за пандемии все мероприятия перешли в онлайн, мы уже проводили «фестивальчик на удалёночке» TechTrain. Теперь число заражений снова бьёт рекорды, вопрос «как интересно провести выходной дома» снова актуален, и мы устраиваем TechTrain 2020 Autumn: он состоится 24 октября.

Что можно будет увидеть? И доклады, и различные разговорные формы: круглые столы, интервью, набросы в прямом эфире. И, как водится на TechTrain, топовых спикеров, которые в своей сфере пользуются большим уважением. Например, на вопросы о производительности будут отвечать трое экспертов сразу: двое из Java-мира (Алексей Шипилёв и Андрей Паньгин), третий из .NET (Андрей Акиньшин).

Какие-то темы рассчитаны на определённых разработчиков («Ускоряем Flutter-разработку»), какие-то — на всех («Будущее IDE»). Расписали все темы под катом.

Вы сталкивались когда-нибудь с построением (непрерывного) пути обхода кривой на плоскости, заданной отрезками и кривыми Безье?

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

Всё было хорошо, пока из-под рук дизайнеров не стали вылезать монструозные пути, где отдельные кривые могли пересекаться или не точно состыковываться. Объяснение было предельно простым — визуально они все лежат как надо, а для станка, который этот путь будет обходить, такие отклонения незаметны.

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

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

Вопрос о том надо ли проверять то, что возвращает malloc является спорным и всегда порождает жаркие дискуссии.

Часть людей считает, что надо пытаться обрабатывать все виды runtime ошибок, в т.ч. и OOM ситуации. Другие считают, что с OOM всё равно мало что можно сделать и лучше дать приложению просто упасть. На стороне второй группы людей ещё и тот факт, что дополнительная логика обработки OOM с трудом поддаётся тестированию. А если код не тестируется, то почти наверняка он не работает.

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

Вопрос о том надо ли пытаться обрабатывать OOM ситуации в библиотеках/приложениях является противоречивым и мы не будем его здесь касаться. В рамках данной публикации я лишь хочу поделиться опытом того как можно тестировать реализованную логику обработки OOM ситуаций в приложениях написанных на C/C++. Разговор будет идти об операционных системах Linux и macOS. Ввиду ряда причин, Windows будет обойдён стороной.

Стандарт С++ почти никогда не указывает, как именно должен быть реализован тот или иной std алгоритм. Дается только описание того, что на входе, что на выходе и асимптотические ограничения по времени работы и памяти. В статье я постарался прикинуть, какие математические алгоритмы и структуры данных имели ввиду авторы стандарта, указывая ограничения для той или иной сортировки и для некоторых других алгоритмов. А так же как эти алгоритмы реализованы на практике.

При написании статьи я использовал стандарт C++17. В качестве реализаций рассматривал GCC 10.1.0 (май 2020) и LLVM/Clang 10.0.0 (март 2020). В каждой и них есть своя реализация STL, а значит и std алгоритмов.

В этой статье я хотел бы пройтись и показать основные моменты того, как настроить IDE CLion для компиляции CMake проекта средствами Emscripten. Когда я занимался этим скрещиванием мне пришлось потратить день или два на эксперименты. И в этой заметке я собираюсь собрать некое "how to", которое в итоге сработало.

Java и другие управляемые языки просты и удобны во многих случаях, но иногда их возможностей недостаточно — например, если нужна библиотека, написанная только на C или C++. Иногда хочется позвать пару методов из системного API, или попытаться улучшить производительность для модуля — и тогда прямой путь в нативный код.

Но тут возникают подводные камни: написать нативный метод и вызвать библиотеку может быть и легко, но JVM начинает крашиться в случайных местах, производительность падает, сборщик мусора перестает справляться с работой, а в репозитории царствуют бесконечные C-шные файлы с буквами JNI. Что же могло пойти не так?

Иван Углянский (dbg_nsk) из Huawei разбирается со всем по порядку: что необычного в интеропе между Java и нативным кодом, как оно работало раньше и что нужно делать для их нормальной совместной работы (и можно ли это вообще сделать). Иван рассказывает, как избежать просадок производительности, внезапных OOM и размышляет на тему будущего — в контексте проектов Panama и Sulong.

Мы подготовили текстовую версию доклада о работе с нативами в Java. В первой части:

• Зачем вообще работать с нативным кодом в Java.
• С какими ошибками и проблемами придётся столкнуться при работе с нативами.

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

Далее — повествование от лица спикера.

Привет, хабровчане! Хочу рассказать о своей системе UI, которую я написал для своего игрового движка, на которой делаю редактор для него же.

“C позволяет легко выстрелить себе в ногу. На C++ это сделать сложнее, но ногу оторвёт целиком” — Бьёрн Страуструп, создатель C++.

Введение

Данная статья является продолжением данной статьи.

Бесконечный поток данных при помощи co_yield

Код ниже реализует бесконечный поток данных. Корутина getNext использует co_yield для создания потока данных который начинается со start и выдает по запросу каждое новое значение с шагом step.

Введение

Данная статья является переводом главы из книги Райнера Гримма Concurrency with Modern C++, которая является более доработанной и обширной версией статьи на его сайте. Так как весь перевод не умещается в рамках данной статьи, в зависимости от реакции на публикацию, выложу оставшуюся часть.

Корутины

Корутины это функции которые могут приостановить или возобновить свое выполнение при этом сохраняя свое состояние. Эволюция функций в C++ сделала шаг вперед. Корутины с наибольшей вероятностью войдут вошли в C++20.

Идея корутин, представленная как новая в C++20, довольно стара. Понятие корутины было предложено Мелвином Конвеем. Он использовал данное понятие в публикации о разработке компиляторов от 1963. Дональд Кнут называл процедуры частным случаем корутин. Иногда должно пройти время чтобы та или иная идея была принята.