Высокая производительность *

Что нужно от картинки в видеозвонке? Базово — чтобы не пикселила, не замирала и не вешала весь звонок. Это основы real-time видео, и добиться этого не так трудно. 

Всё самое интересное начинается, когда вы хотите, чтобы в одном звонке могли участвовать сколько угодно человек. И при этом все могли включать видео, а не просто смотреть; разрешение скриншеринга было бы 4К; шеринг оставался суперчётким при любом интернете и т. д. И чтобы звонки работали на любых платформах и устройствах на мобильном нестабильном интернете. 

Как мы добиваемся всего этого в звонках ВКонтакте, какие хаки в настройках используем, как экономим трафик и CPU, как боремся за latency и где нам пришлось идти в обход WebRTC, читайте под катом. 

Предположим, вы разработали приложение или библиотеку на Python и уже готовитесь передать его / её  заказчику. И в этот момент появляются разные вопросы.

Во-первых, к вам прибегает озадаченный проджект-менеджер и говорит: «Мы решили не отдавать исходный код, ведь это наша интеллектуальная собственность. Придумайте что-нибудь, чтобы заказчик был доволен, а мы оставили у себя исходники».

Во-вторых, возникает вопрос окружения - хочется быть уверенным, что заказчик справится с установкой правильной версии Python и всех вспомогательных библиотек, но это не всегда простая задача. Было бы удобно упаковать приложение в автономный исполняемый файл.

И, наконец, хочется,  чтобы конечное приложение работало быстрее, чем в среде разработки.

И вот тут настало время скомпилировать Python-код.

Меня зовут Руслан, я старший разработчик компании «Цифровое проектирование». Сегодня я расскажу, как выбрать тот самый компилятор из множества доступных.

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

Школа синтеза цифровых схем, о которой вы могли читать месяц назад в посте "Проектировщики RISC-V из Yadro покажут школьникам как проектировать процессоры" - прошла на ура. Все 25 мест в офлайне в Сколково были все время заняты. Присутствовали школьники, студенты, преподаватели вузов и кружков. Всего было подано 86 заявок. Все ~70 FPGA плат которые пожертвовали Наносемантика, Максим Маслов и другие, были быстро разобраны, люди охотно проходили роснановский онлайн-курс чтобы получить сертификат и соответственно плату.

Из новых пунктов программы больше всего интереса вызвали опыты по распознаванию мелодий с помощью zero-crossing и конечных автоматов, реализованных в ПЛИС. Это занятие провели преподавательница флейты Мария Беличенко и молодые инженеры Семён Москоленко (МИРЭА) и Виктор Прутьянов (МФТИ, Сколтех, SberDevices) - см. видео в посте.

Так как школа оказалась популярна, ее решили расширить до полноценного семестрового курса по субботам, начиная с 30 октября 2021, с объемом материала на уровне университетских лабораторных по FPGA (типа MIT 6.111), к которым мы добавили элементы компьютерной архитектуры, базовый туториал для ASIC и некоторые умения из промышленности.

Порой жизнь разработчика превращается в кошмар. Называться это может по-разному: «миграция большого проекта», «отладка асинхронного кода», «запущенное легаси» или даже «зоопарк технологий для распределённых приложений». Уже скоро мы проведем .NET-конференцию DotNext, и поучаствовать в ней не только интересно, но и может помогать от кошмаров.

Среди тем конференции — и низкоуровневый хардкор, и нестандартные подходы, и личные истории преодоления препятствий. А рассказывать обо всём этом будут яркие спикеры, уже знакомые многим .NET-разработчикам: например, Скотт Влашин, Дилан Битти, Стивен Тауб, Егор Богатов, Евгений Пешков.

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

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

Каждый, кто работал в аутсорсинге сервисов и бизнес-процессов, не понаслышке знает о важности продаж тех самых сервисов.

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

Yandex Rate Limiter (далее просто YARL) — это сервис лимитирования нагрузки для распределённых сервисов. Его особенность в том, что он способен работать с миллионами квот, имея при этом очень низкие накладные расходы на проверку квоты. Если совсем кратко, это система распределённых Leaky Bucket'ов, с помощью которых можно ограничивать разные величины, связанные со временем: скорость передачи данных по сети, запросы в секунду и т. п.

Меня зовут Денис Кореневский, я работаю в службе разработки внутреннего хранилища Яндекса, и сегодня я расскажу, как YARL устроен внутри, почему мы вообще написали своё решение и с какими трудностями нам пришлось столкнуться в процессе создания. Добро пожаловать под кат.

На протяжении десятилетий высокопроизводительные вычисления (HPC) вносили огромный вклад в развитие науки, промышленности, национальной и региональной безопасности и повышение качества жизни людей. Но если раньше область применения HPC нередко ограничиваясь правительственными проектами и академическими исследованиями, то сегодня трансформация технологий позволяет задействовать HPC для решения весьма широкого круга прикладных и научных задач. В Лаборатории компьютерного дизайна материалов Сколтехе вычислительный кластер стал основным инструментом исследователей и позволил добиться важных практических результатов.

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

Я раньше считал, что JDK в целом хорошо оптимизирована, и если в JDK есть простой способ решения какой-то задачи, то он вполне подойдет для большинства ситуаций и будет работать хорошо.

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

В этом посте рассмотрим один из подобных кейсов: поразительно низкая производительность String.format() при простой конкатенации строк.

Привет! Мы уже рассказывали в блоге о том, как работаем с данными на Мосбирже. Но задач, связанных с data, равно как и её разновидностей, настолько много, что одной публикацией точно не обойтись. К примеру, мы – Кирилл Хомутов и Дмитрий Польских – в составе команды ИТ-Финансы обрабатываем данные, которые используются для формирования финансовой отчетности. Сегодня поделимся опытом, как мы научились регулярно получать, агрегировать и «приводить к общему знаменателю» миллионы транзакций из различных ИТ-систем компаний Группы «Московская Биржи».

Не все знают, но Московская биржа – это одна из компаний группы, которая занимается организацией торгов разными классами активов, учетом активов, расчетами. В группу также входят Национальная Товарная Биржа (НТБ), Национальный клиринговый центр (НКЦ), Национальный расчетный депозитарий (НРД) и несколько небольших компаний, которые выполняют узкоспециализированные сервисные функции.

Все участники группы находятся под разным регулированием, по-разному ведут бухгалтерский учёт и сдают разную отчетность. Биржи ведут учёт по стандартам для некредитных финансовых организаций (НФО). НКЦ и НРД ведут учёт уже как банки, закрывая операционный день и т.п.. А сервисные компании ведут учёт по РСБУ в соответствии с требованиями Минфина.

Нам нужно было собрать все эти «разношёрстные» учетные данные и свести в единую модель, чтобы сформировать консолидированную внешнюю отчетность по международным стандартам (МСФО). Добывать информацию приходилось из очень разных источников. Как мы это делали — читайте дальше.

Подобный Python Triton уже работает в ядрах, которые в 2 раза эффективнее эквивалентных реализаций Torch. А ядра матричного умножения FP16, сравнимые производительностью с cuBLAS, на Triton займут менее 25 строк. Как утверждает автор, многие программисты не могут написать такие ядра. Подробностями о Triton делимся к старту курса по ML и DL.

Задача

В Uber применяется несколько технологий хранения информации, причем, хранение бизнес-данных зависит от того, какова модель приложения, в которой они применяются. Одна из таких технологий называется Schemaless и обеспечивает моделирование взаимосвязанных записей с представлением в виде одной строки из множества столбцов, а также версионирование для каждого столбца отдельно.

Schemaless в ходу уже пару лет, и там накапливаются данные Uber. Притом, что Uber консолидирует все практические кейсы в Docstore, Schemaless остается источником истины для различных клиентских конвейеров задач, тех, что существуют уже давно. Schemaless как таковая использует быструю (но дорогую) базовую технологию хранения данных, которая позволяет обходиться задержкой порядка нескольких миллисекунд при высоком показателе QPS (запросы в секунду). Кроме того, Schemaless развертывает для каждого региона несколько реплик, чтобы обеспечить сохранность и доступность данных при различных моделях отказов.

Поскольку Schemaless – дорогостоящее хранилище, а данных в нем накапливается все больше, она превратилась в ключевую статью расходов и поэтому требует внимания. Чтобы разобраться в этой ситуации, были проведены замеры, помогающие лучше понять паттерны обращения к данным. Было обнаружено, что в течение некоторого периода времени обращения к данным происходили часто, а после этого – не столь часто. Точная длительность такого периода варьируется от кейса к кейсу, но при любом запросе старые данные все равно должны безусловно предоставляться по запросу.

Вы не используете очередь? Вы просто не умеете её готовить. Но прежде чем этому научиться, нужно разобраться, что это вообще такое и где это применяется. Потому что большинству достаточно 10 000 запросов в секунду, а это дает любой брокер. Но если вам нужно больше, придется погрузиться в очереди достаточно глубоко.

Расскажу, что такое очереди, зачем они нужны и как работают. На примере нескольких сценариев объясню, как устроены очереди и какие есть решения. Какие у очередей самые распространенные проблемы и как их избежать. В чем отличия брокеров, их плюсы и минусы, и как все это использовать в своих целях.

В 1967 году Мелвин Конвей сформулировал известный тезис, без упоминания о котором не обходится практически ни одно руководство по созданию микросервисной архитектуры. И не напрасно, ведь не одно поколение разработчиков сталкивалось с его подтверждениями.

Но если структура коммуникаций компании меняется из-за развития и выхода на новые международные рынки, то приходится менять сам продукт для соответствия потребностям пользователей этих рынков.

Именно с задачей по подготовке продукта к выходу на международные рынки и столкнулась наша команда летом 2020-го года. На тот момент у нас был обширный набор микросервисов, спроектированных и поддерживаемых исходя из старой организационной структуры компании. Поддерживать эту кучу сервисов было сложно и дорого. Более того, куча сервисов уже не соответствовала актуальным требованиям бизнеса и технологическим трендам. Об этом под катом:

В этой серии постов я хотел бы поговорить о Linux Page Cache. Я считаю, что данные знания теори и инструментов жизненно необходимы и важны для каждого SRE. Общее понимание как работает Page Cache помогает и в рутинных повседневных задачах, и в экстренной отладке на продакшене. При этом Page Cache часто оставляют без внимания, а ведь его лучшее понимание. как правило, приводит к:

- более точному планированию емкости системы и лимитов сервисов и контейнеров;
- улучшенным навыкам отладки приложений, интенсивно использующих память и диски (СУБД и храанилища данных);
- созданию безопасных и предсказуемых сред выполнения специальных задач, связанных с памятью и/или вводом-выводом (например: сценарии резервного копирования и восстановления, rsyncоднострочники и т.д.).

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