Привет, друзья!
О том, как работает С++-движок рекламного сервера и с какими проблемами прошлось столкнуться разработчикам – поговорим с Дмитрием Корчагиным. Он является руководителем группы разработки сервиса, отвечающего за подбор и ранжирование рекламных объявлений — рекламного сервера myTarget.
📋 https://clck.ru/bGdD7
На своем выступлении Дмитрий расскажет об архитектуре сервиса, отвечающего за подбор рекламных объявлений. Поделится о том, как они боролись с фродом рекламодателей. Научились без потерь переживать несколько часов без синхронизации данных. А также как они выдерживают лимиты откруток кампаний в распределенной системе из нескольких сотен серверов.
План доклада:
* общая схема работы myTarget;
* очереди задач;
* синхронизация индекса;
* работа с метриками и статистикой;
* как решалась проблема с бесплатным для рекламодателя показом баннеров.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bGdZ3
О том, как работает С++-движок рекламного сервера и с какими проблемами прошлось столкнуться разработчикам – поговорим с Дмитрием Корчагиным. Он является руководителем группы разработки сервиса, отвечающего за подбор и ранжирование рекламных объявлений — рекламного сервера myTarget.
📋 https://clck.ru/bGdD7
На своем выступлении Дмитрий расскажет об архитектуре сервиса, отвечающего за подбор рекламных объявлений. Поделится о том, как они боролись с фродом рекламодателей. Научились без потерь переживать несколько часов без синхронизации данных. А также как они выдерживают лимиты откруток кампаний в распределенной системе из нескольких сотен серверов.
План доклада:
* общая схема работы myTarget;
* очереди задач;
* синхронизация индекса;
* работа с метриками и статистикой;
* как решалась проблема с бесплатным для рекламодателя показом баннеров.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bGdZ3
Привет, друзья!
Эволюцию акторной системы обсудим на выступлении Алексея Станкевичуса (Яндекс).
Он руководит группой разработки распределенного хранилища и распределенной платформы YDB.
📋 https://clck.ru/bHZAW
Существует несколько подходов к созданию эффективных многопоточных приложений на С++. В Yandex Database (YDB) выбрали модель акторов и с нуля создали свою акторную систему. С тех пор прошло более 7 лет, и сегодня акторная система исполняется на десятках тысяч серверов. Чтобы пройти путь к созданию сложных модульных распределенных систем с помощью модели акторов разработчикам пришлось решить множество проблем.
Из доклада узнаем о некоторых из них:
* как совместить интерактивную нагрузку и фоновые задачи в одном приложении;
* как обеспечить гарантии latency и высокую утилизацию;
* как изолировать подсистемы и обойтись без резервирования CPU.
И, конечно, расскажет, почему выбрали именно модель акторов.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве –
https://clck.ru/bHYn3
Эволюцию акторной системы обсудим на выступлении Алексея Станкевичуса (Яндекс).
Он руководит группой разработки распределенного хранилища и распределенной платформы YDB.
📋 https://clck.ru/bHZAW
Существует несколько подходов к созданию эффективных многопоточных приложений на С++. В Yandex Database (YDB) выбрали модель акторов и с нуля создали свою акторную систему. С тех пор прошло более 7 лет, и сегодня акторная система исполняется на десятках тысяч серверов. Чтобы пройти путь к созданию сложных модульных распределенных систем с помощью модели акторов разработчикам пришлось решить множество проблем.
Из доклада узнаем о некоторых из них:
* как совместить интерактивную нагрузку и фоновые задачи в одном приложении;
* как обеспечить гарантии latency и высокую утилизацию;
* как изолировать подсистемы и обойтись без резервирования CPU.
И, конечно, расскажет, почему выбрали именно модель акторов.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве –
https://clck.ru/bHYn3
Всем привет!
О том, как готовили поиск в Delivery Club – узнаем у Евгения Исупова и Ивана Максимова.
📋 https://clck.ru/bQ9ms
На конференции Highload++ Foundation они расскажут почему поиск — это не просто совпадения по полям данных. Как на запрос "Маргарита" появляется пицца, а на запрос "Пьяная бабушка" — бургер из известной сети? Каким образом на запрос "Макдональдс" вернуть не только сам ресторан, но и другие бургерные?
В докладе они поделятся об архитектуре поиска в Delivery Club, а также о повышении его релевантности с помощью ML-инструментов без потери в скорости ответа сервиса.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bQA7W
О том, как готовили поиск в Delivery Club – узнаем у Евгения Исупова и Ивана Максимова.
📋 https://clck.ru/bQ9ms
На конференции Highload++ Foundation они расскажут почему поиск — это не просто совпадения по полям данных. Как на запрос "Маргарита" появляется пицца, а на запрос "Пьяная бабушка" — бургер из известной сети? Каким образом на запрос "Макдональдс" вернуть не только сам ресторан, но и другие бургерные?
В докладе они поделятся об архитектуре поиска в Delivery Club, а также о повышении его релевантности с помощью ML-инструментов без потери в скорости ответа сервиса.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bQA7W
This media is not supported in your browser
VIEW IN TELEGRAM
Всем привет!
Поговорим с Владимиром Витковским о лучших практиках, на которых основан очень быстрый сборщик логов, используемый в Ozon.
📋 https://clck.ru/bR3ap
Владимир расскажет, как с помощью этого инструмента они сократили издержки на сбор логов в 10 раз по CPU и добились 100% доставляемости логов.
Вы узнаете:
* как организована общая архитектура сборщика логов;
* как написать быстрый плагин для чтения логов из файлов;
* как оптимизировать внутреннюю обработку потока логов;
* как правильно распараллелить обработку;
* как гарантировать доставку.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bR42b
Поговорим с Владимиром Витковским о лучших практиках, на которых основан очень быстрый сборщик логов, используемый в Ozon.
📋 https://clck.ru/bR3ap
Владимир расскажет, как с помощью этого инструмента они сократили издержки на сбор логов в 10 раз по CPU и добились 100% доставляемости логов.
Вы узнаете:
* как организована общая архитектура сборщика логов;
* как написать быстрый плагин для чтения логов из файлов;
* как оптимизировать внутреннюю обработку потока логов;
* как правильно распараллелить обработку;
* как гарантировать доставку.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bR42b
🔥3
Привет, друзья!
Тернистый путь цифровой трансформации классического телеком-оператора большой тройки в современную IT-компанию. Как обеспечить интеграцию множества сервисов, разрабатываемых множеством команд, между собой и не допустить хаоса во взаимодействии – расскажет Алексей Коновкин (Nexign).
📋 https://clck.ru/bVYkk
Аутентификация и авторизация "всех со всеми", если у вас несколько поставщиков идентификационной информации (Identity Providers), множество сервисов, а безопасностью взаимодействия нельзя пренебречь.
"Купить или не купить — вот в чем вопрос". Вопрос выбора API Gateway, и почему они решили пойти своим путем.
🔹Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bVYmu
Тернистый путь цифровой трансформации классического телеком-оператора большой тройки в современную IT-компанию. Как обеспечить интеграцию множества сервисов, разрабатываемых множеством команд, между собой и не допустить хаоса во взаимодействии – расскажет Алексей Коновкин (Nexign).
📋 https://clck.ru/bVYkk
Аутентификация и авторизация "всех со всеми", если у вас несколько поставщиков идентификационной информации (Identity Providers), множество сервисов, а безопасностью взаимодействия нельзя пренебречь.
"Купить или не купить — вот в чем вопрос". Вопрос выбора API Gateway, и почему они решили пойти своим путем.
🔹Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bVYmu
Всем привет!
На конференции HighLoad++ выступит Юрий Печатнов из Яндекса.
📋 https://clck.ru/bVm8P
Его доклад будет о том, как они научились более эффективно передавать данные между своими сервисами.
С сохранением exactly once и отказоустойчивости они уменьшили материализацию потока промежуточных данных на дисках на 90% и примерно на столько же снизили latency.
Подробнее на простом примере:
Пусть у них есть много входных очередей (например, kafka) с событиями, каждое событие содержит идентификатор стейта StateId и относится к соответствующему стейту. И они хотят в реальном времени считать агрегаты произвольной сложности (= обновлять стейты) по входным событиям с семантикой exactly once.
Для эффективной работы такой схемы обновления стейтов в хранилище нужна какая-то локальность по ключам, поэтому входные данные нужно сначала пошардировать примерно так же, как шардированы данные в хранилище.
Тогда в этом простом случае получается, что нужно два сервиса: один читает входные события и пишет их в промежуточную очередь пошардировано (resharder), другой читает уже шардированные события и обновляет стейты в соответствии с ними (aggregator).
Что плохо в этой схеме? То, что весь поток событий необходимо писать через промежуточную очередь, а это большой поток на записи на диски и, соответственно, много железа! А ведь еще есть небольшая задержка.
То есть они решают проблему: как передать данные от resharder'а aggregator'у с наименьшей материализацией на дисках, с наименьшими задержками и при этом отказоустойчиво и с exactly once.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bVmRZ
На конференции HighLoad++ выступит Юрий Печатнов из Яндекса.
📋 https://clck.ru/bVm8P
Его доклад будет о том, как они научились более эффективно передавать данные между своими сервисами.
С сохранением exactly once и отказоустойчивости они уменьшили материализацию потока промежуточных данных на дисках на 90% и примерно на столько же снизили latency.
Подробнее на простом примере:
Пусть у них есть много входных очередей (например, kafka) с событиями, каждое событие содержит идентификатор стейта StateId и относится к соответствующему стейту. И они хотят в реальном времени считать агрегаты произвольной сложности (= обновлять стейты) по входным событиям с семантикой exactly once.
Для эффективной работы такой схемы обновления стейтов в хранилище нужна какая-то локальность по ключам, поэтому входные данные нужно сначала пошардировать примерно так же, как шардированы данные в хранилище.
Тогда в этом простом случае получается, что нужно два сервиса: один читает входные события и пишет их в промежуточную очередь пошардировано (resharder), другой читает уже шардированные события и обновляет стейты в соответствии с ними (aggregator).
Что плохо в этой схеме? То, что весь поток событий необходимо писать через промежуточную очередь, а это большой поток на записи на диски и, соответственно, много железа! А ведь еще есть небольшая задержка.
То есть они решают проблему: как передать данные от resharder'а aggregator'у с наименьшей материализацией на дисках, с наименьшими задержками и при этом отказоустойчиво и с exactly once.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bVmRZ
Всем привет!
Как наладить CI-процесс в монорепозитории и сохранить спокойствие разработчиков – расскажет Алина Власова. Она работает в “Лаборатории Касперского” c 2015 года. В данный момент является руководителем группы, занимающейся разработкой инфраструктуры для непрерывной интеграции.
📋 https://clck.ru/bd3C5
Несколько лет тому назад в Лаборатории Касперского приняли решение переехать в монорепозиторий с собственной инфраструктурой. В докладе Алина расскажет о том, как это решение повлияло на жизнь разработчиков и на скорость доставки изменений в код.
Вы узнаете о том, как у них устроен CI-процесс, какие преимущества они получили и с какими проблемами столкнулись. Какие инструменты и мониторинги используют для того, чтобы повышать работоспособность данного процесса и создавать комфортные условия для разработчиков, вносящих изменения в код.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bd3CV
Как наладить CI-процесс в монорепозитории и сохранить спокойствие разработчиков – расскажет Алина Власова. Она работает в “Лаборатории Касперского” c 2015 года. В данный момент является руководителем группы, занимающейся разработкой инфраструктуры для непрерывной интеграции.
📋 https://clck.ru/bd3C5
Несколько лет тому назад в Лаборатории Касперского приняли решение переехать в монорепозиторий с собственной инфраструктурой. В докладе Алина расскажет о том, как это решение повлияло на жизнь разработчиков и на скорость доставки изменений в код.
Вы узнаете о том, как у них устроен CI-процесс, какие преимущества они получили и с какими проблемами столкнулись. Какие инструменты и мониторинги используют для того, чтобы повышать работоспособность данного процесса и создавать комфортные условия для разработчиков, вносящих изменения в код.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bd3CV
💥 Кто получит премию HighLoad++ Award 2022? Решать вам!
Ранее мы объявляли о наборе номинантов на премию HighLoad++, в котором мог принять участие каждый, кто оказал положительное влияние в развитие экосистемы интернет-разработки.
Экспертный совет произвел первичный отбор поданных заявок. И теперь все номинанты, прошедшие фильтр – попали в закрытое голосование.
В голосовании могут принять участие абсолютно все, необходимо зайти на сайт голосования, авторизироваться через соцсеть и отдать свой голос в одной номинации или нескольких.
✅ Голосование будет проходить до 20 февраля.
Переходите по ссылке 👉 https://clck.ru/auCAr и оставляйте свой голос за лучшего!
Ранее мы объявляли о наборе номинантов на премию HighLoad++, в котором мог принять участие каждый, кто оказал положительное влияние в развитие экосистемы интернет-разработки.
Экспертный совет произвел первичный отбор поданных заявок. И теперь все номинанты, прошедшие фильтр – попали в закрытое голосование.
В голосовании могут принять участие абсолютно все, необходимо зайти на сайт голосования, авторизироваться через соцсеть и отдать свой голос в одной номинации или нескольких.
✅ Голосование будет проходить до 20 февраля.
Переходите по ссылке 👉 https://clck.ru/auCAr и оставляйте свой голос за лучшего!
Привет, друзья!
В своем докладе Андрей Аксенов (Авито, Sphinx) поделится, как они в порядке эксперимента выжимали 1 миллион запросов в секунду из 1 физического сервера и СУБД, никогда при этом НЕ рассчитанной на именно такой workload (спойлер: СУБД всё ещё Сфинкс).
📋 https://clck.ru/bfrRy
На выступлении узнаем:
- Почему выжимали именно ~1 миллион (а не ~0.1 или ~10м).
- В каких местах обнаружились тормоза (спойлер: в разных и поначалу несколько удивительных).
- Как получилось подлечить 3+ места с разумной трудоемкостью и немедленно закатить эти успехи в бой (тизеры: не обошлось без пары строчек ассемблера, причем, что удивительно, сервер Intel, а ассемблер понадобился ARM; не обошлось без легких лок-фри-фокусов; не обошлось без переписывания простеньких системных вызовов вручную и прочей легкой наркомании).
- Чего в итоге получилось.
- Где ещё есть известные диоды, которые уже так просто не залечить.
- Ну и совсем вкратце — как теоретически атаковать следующие вершины (10+ миллионов RPS).
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bfrn5
В своем докладе Андрей Аксенов (Авито, Sphinx) поделится, как они в порядке эксперимента выжимали 1 миллион запросов в секунду из 1 физического сервера и СУБД, никогда при этом НЕ рассчитанной на именно такой workload (спойлер: СУБД всё ещё Сфинкс).
📋 https://clck.ru/bfrRy
На выступлении узнаем:
- Почему выжимали именно ~1 миллион (а не ~0.1 или ~10м).
- В каких местах обнаружились тормоза (спойлер: в разных и поначалу несколько удивительных).
- Как получилось подлечить 3+ места с разумной трудоемкостью и немедленно закатить эти успехи в бой (тизеры: не обошлось без пары строчек ассемблера, причем, что удивительно, сервер Intel, а ассемблер понадобился ARM; не обошлось без легких лок-фри-фокусов; не обошлось без переписывания простеньких системных вызовов вручную и прочей легкой наркомании).
- Чего в итоге получилось.
- Где ещё есть известные диоды, которые уже так просто не залечить.
- Ну и совсем вкратце — как теоретически атаковать следующие вершины (10+ миллионов RPS).
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bfrn5
👍1
Привет, друзья!
В докладе Тимура Давыдова (Московская Биржа) рассмотрим архитектуру современной торгово-клиринговой системы (ТКС) и более подробно познакомимся с in-memory-базой данных, оптимизированной для работы с низкими и предсказуемыми задержками, предназначенными для хранения информации во время работы ТКС.
📋 https://clck.ru/bggxi
В связи с изменением поведения рынков со временем и требованием хранения большего количества информации, были сделаны оптимизации как в самом представлении данных, так и в организации базы данных. Но одна проблема все еще оставалась нерешенной — это выделение оптимального объема памяти для каждой таблицы БД с расчетом на худший случай.
Поэтому в докладе также будут рассмотрены способы увеличения объема непрерывной области данных в памяти и предложена оптимальная реализация технологии динамического увеличения непрерывной области данных в памяти за константное время. Также будет рассмотрен опыт внедрения и применения данной технологии в реальных условиях. Отдельное внимание будет уделено решению проблем, возникших в процессе реализации и тестирования.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bghNU
В докладе Тимура Давыдова (Московская Биржа) рассмотрим архитектуру современной торгово-клиринговой системы (ТКС) и более подробно познакомимся с in-memory-базой данных, оптимизированной для работы с низкими и предсказуемыми задержками, предназначенными для хранения информации во время работы ТКС.
📋 https://clck.ru/bggxi
В связи с изменением поведения рынков со временем и требованием хранения большего количества информации, были сделаны оптимизации как в самом представлении данных, так и в организации базы данных. Но одна проблема все еще оставалась нерешенной — это выделение оптимального объема памяти для каждой таблицы БД с расчетом на худший случай.
Поэтому в докладе также будут рассмотрены способы увеличения объема непрерывной области данных в памяти и предложена оптимальная реализация технологии динамического увеличения непрерывной области данных в памяти за константное время. Также будет рассмотрен опыт внедрения и применения данной технологии в реальных условиях. Отдельное внимание будет уделено решению проблем, возникших в процессе реализации и тестирования.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bghNU
Всем привет!
Что могут C и C++, и когда нужен ассемблер – узнаем у Александра Крижановского. Он является основателем и системным архитектором Tempesta Technologies, экспертом в области высокопроизводительных вычислений в Linux/x86-64.
📋 https://clck.ru/bkrkK
C и C++ известны скоростью сгенерированного кода. Однако, код генерируется конкретным компилятором под конкретную ОС на конкретное железо. Расширения компиляторов позволяют генерировать еще более быстрый код, чем для "чистых" C и C++. Микропроцессоры тоже предоставляют свои расширения, которые недоступны даже для расширений компилятора и для использования которых нужен ассемблер.
В этом докладе Александр посмотрит, какой код генерируют GCC и Clang для некоторых C и C++ конструкций и как сделать этот код быстрее. Также он копнет в специфичные для x86-64 оптимизации. Обсудит микробенчмарки.
А еще узнаем:
- Как x86-64 исполняет код и как работает с памятью.
- Некоторые полезные расширения и оптимизации GCC и Clang для C и C++.
- Когда ассемблер x86-64 не только быстрее, но и проще C.
- Скользкие места программирования для многоядерных архитектур.
- Защита от Spectre в компиляторах.
- Profiler guided optimization (PGO) и когда она бесполезна.
📍До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bkrkm
Что могут C и C++, и когда нужен ассемблер – узнаем у Александра Крижановского. Он является основателем и системным архитектором Tempesta Technologies, экспертом в области высокопроизводительных вычислений в Linux/x86-64.
📋 https://clck.ru/bkrkK
C и C++ известны скоростью сгенерированного кода. Однако, код генерируется конкретным компилятором под конкретную ОС на конкретное железо. Расширения компиляторов позволяют генерировать еще более быстрый код, чем для "чистых" C и C++. Микропроцессоры тоже предоставляют свои расширения, которые недоступны даже для расширений компилятора и для использования которых нужен ассемблер.
В этом докладе Александр посмотрит, какой код генерируют GCC и Clang для некоторых C и C++ конструкций и как сделать этот код быстрее. Также он копнет в специфичные для x86-64 оптимизации. Обсудит микробенчмарки.
А еще узнаем:
- Как x86-64 исполняет код и как работает с памятью.
- Некоторые полезные расширения и оптимизации GCC и Clang для C и C++.
- Когда ассемблер x86-64 не только быстрее, но и проще C.
- Скользкие места программирования для многоядерных архитектур.
- Защита от Spectre в компиляторах.
- Profiler guided optimization (PGO) и когда она бесполезна.
📍До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bkrkm
Привет, друзья!
Продолжаем знакомить вас со спикерами HighLoad++. Одним из них станет Александр Ляпунов (VK).
📋 https://clck.ru/bm63K
В своем докладе он расскажет, как они используют msgpack в асинхронном сетевом протоколе СУБД и сервера приложений Tarantool в целом и о реализации его клиентской части (коннектора) на С++, в частности.
Для коммуникации с базами данных проблемой является заранее неизвестная структура данных, а если рассматривать Tarantool в контексте сервера приложений, то задача становится фактически реализацией протокола RPC с неопределенным набором функций. Другими словами, при реализации сервера и коннектора к нему структура и набор данных не определены. Для такого динамического протокола хорошо подошел msgpack, однако это принесло сложности в разработке и затронуло быстродействие системы.
У коннектора, вдобавок к динамичности, есть еще одна проблема — встраиваемость в существующую кодовую базу приложения. По-хорошему, нужно сделать так, чтобы вне зависимости от того, что использует приложение — блокирующее I/O, epoll, другие событийные циклы, файберы — можно было бы удобно использовать коннектор.
В этом докладе Александр попробует поделиться решениями этих и других проблем, а также просто опытом создания подобных систем.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bm63a
Продолжаем знакомить вас со спикерами HighLoad++. Одним из них станет Александр Ляпунов (VK).
📋 https://clck.ru/bm63K
В своем докладе он расскажет, как они используют msgpack в асинхронном сетевом протоколе СУБД и сервера приложений Tarantool в целом и о реализации его клиентской части (коннектора) на С++, в частности.
Для коммуникации с базами данных проблемой является заранее неизвестная структура данных, а если рассматривать Tarantool в контексте сервера приложений, то задача становится фактически реализацией протокола RPC с неопределенным набором функций. Другими словами, при реализации сервера и коннектора к нему структура и набор данных не определены. Для такого динамического протокола хорошо подошел msgpack, однако это принесло сложности в разработке и затронуло быстродействие системы.
У коннектора, вдобавок к динамичности, есть еще одна проблема — встраиваемость в существующую кодовую базу приложения. По-хорошему, нужно сделать так, чтобы вне зависимости от того, что использует приложение — блокирующее I/O, epoll, другие событийные циклы, файберы — можно было бы удобно использовать коннектор.
В этом докладе Александр попробует поделиться решениями этих и других проблем, а также просто опытом создания подобных систем.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bm63a
👍1
Всем привет!
Про статистический анализ кода++ поговорим с Анастасией Казаковой из JetBrains.
📋 https://clck.ru/bmEpE
Если судить по опросу C++ Foundation, то проблемы безопасности кода на C++, ошибки при работе с памятью и прочие типичные "боли" языка — все еще самые актуальные для разработчиков на C++. При этом, как известно, софт более высокого качества обходится дешевле в создании (а не только в поддержке, как можно было бы подумать).
В своем докладе Анастасия обсудит некоторые примеры типичных проблем, рассмотрит, что сейчас предлагает язык (интересно, что несмотря на очень активное развитие инструментов статического анализатора кода, многие предложения направлены именно на внесение дополнительной аналитики в сам компилятор языка), и выяснит, что же умеют современные статические анализаторы, и как далеки компиляторы от "счастливого и безопасного" будущего в C++.
📍Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bmEpj
Про статистический анализ кода++ поговорим с Анастасией Казаковой из JetBrains.
📋 https://clck.ru/bmEpE
Если судить по опросу C++ Foundation, то проблемы безопасности кода на C++, ошибки при работе с памятью и прочие типичные "боли" языка — все еще самые актуальные для разработчиков на C++. При этом, как известно, софт более высокого качества обходится дешевле в создании (а не только в поддержке, как можно было бы подумать).
В своем докладе Анастасия обсудит некоторые примеры типичных проблем, рассмотрит, что сейчас предлагает язык (интересно, что несмотря на очень активное развитие инструментов статического анализатора кода, многие предложения направлены именно на внесение дополнительной аналитики в сам компилятор языка), и выяснит, что же умеют современные статические анализаторы, и как далеки компиляторы от "счастливого и безопасного" будущего в C++.
📍Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bmEpj
Привет, друзья!
На выступлении Данилы Смирнова обсудим поиск в HeadHunter: как подружить machine learning и production.
📋 https://clck.ru/bmFba
Современные web-сервисы уже практически немыслимы без машинного обучения. Тем не менее эффективное использование в production ML-моделей может быть сопряжено с большим количеством задач на построение архитектуры приложения или оптимизации производительности, которые практически не встречаются в обычной разработке и для которых ещё не выработали стандартных решений.
Именно с такими задачами столкнулись в HeadHunter во время внедрения машинного обучения в сервис поиска, и на примере чего хочется обсудить возникшие проблемы и их решения:
- для взаимодействия между обучением моделей на python и инференсом на java;
- для оптимизации архитектурных решений на java для сложных моделей;
- поведенческие признаки в production;
- а также java и mmap, сериализация и обмен данными между python и java.
✅ До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bmFR3
На выступлении Данилы Смирнова обсудим поиск в HeadHunter: как подружить machine learning и production.
📋 https://clck.ru/bmFba
Современные web-сервисы уже практически немыслимы без машинного обучения. Тем не менее эффективное использование в production ML-моделей может быть сопряжено с большим количеством задач на построение архитектуры приложения или оптимизации производительности, которые практически не встречаются в обычной разработке и для которых ещё не выработали стандартных решений.
Именно с такими задачами столкнулись в HeadHunter во время внедрения машинного обучения в сервис поиска, и на примере чего хочется обсудить возникшие проблемы и их решения:
- для взаимодействия между обучением моделей на python и инференсом на java;
- для оптимизации архитектурных решений на java для сложных моделей;
- поведенческие признаки в production;
- а также java и mmap, сериализация и обмен данными между python и java.
✅ До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bmFR3