Привет! Меня зовут Константин Яковлев, я научный работник и вот уже более 15 лет я занимаюсь методами планирования траектории. Часто эта задача сводится к поиску пути на графе, для чего обычно используется алгоритм эвристического поиска A*. Этот алгоритм был предложен в 60-х годах XX века и с тех пор используется повсеместно. Скорее всего, юнит вашей любимой RTS бежит по карте с помощью той или иной вариации A*. Точно так же, под капотом беспилотного авто вы, наверняка, найдёте A*, хотя там, конечно, не только он.

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

Этот текст посвящен как самому алгоритму A*, так и попыткам повысить его эффективность с помощью методов искусственного интеллекта. Заодно я расскажу о том, какие новшества в этом направлении придумали мы с коллегами: научная статья на эту тему опубликована в сборнике конференции AAAI 2023.

Введение

Я делала много вещей с компьютерами, но в моих знаниях всегда был пробел: что конкретно происходит при запуске программы на компьютере? Я думала об этом пробеле — у меня было много низкоуровневых знаний, но не было цельной картины. Программы действительно выполняются прямо в центральном процессоре (central processing unit, CPU)? Я использовала системные вызовы (syscalls), но как они работают? Чем они являются на самом деле? Как несколько программ выполняются одновременно?

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

И, как говорится, ты по-настоящему знаешь что-то, только если можешь объяснить это другому.

Более удобный формат статьи.

Привет, Хабр! Меня зовут Вова, я разрабатываю observability-платформу в Ozon. Как-то раз в наш уголок на 42 этаже заглянули коллеги — и поделились наблюдением. Если открыть рядом графики времён запросов и ответов двух живущих в Kubernetes и общающихся между собой микросервисов, то иногда можно наблюдать большую разницу в высоких квантилях: клиент считает, что один ответ из сотни ему приходит за сто миллисекунд, сервер же говорит, что успевает ответить за десять.

Куда ушло время? Можно ли его вернуть? Под катом расскажу о том, с какими граблями может столкнуться микросервис, живущий в типичной инсталляции Kubernetes.

Недавно, постигая азы Машинного Обучения и изучая классификацию, я наткнулся на precision и recall. Диаграммки, которые часто вставляют, объясняя эти концепции, мне не помогли понять отличия между ними. Но чудо, я придумал объяснение, которое понятно мне, и я надеюсь, что оно поможет кому-нибудь из вас на пути изучения ML (возможно это объяснение кто-то придумал до меня) .

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

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

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

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

Не верите?

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

Когда-то давно меня очаровал ADOM. Я даже и близко не подошёл к прохождению игры, но мне нравилось бродить по этому миру, собирать предметы с эффектом, который не прочувствуешь, пока не используешь. Нравилось, что монстры в подземельях имели какие-то зачатки собственного интеллекта, подбирали с пола вещи и использовали их. Всё время что-то происходило и менялось, проходишь по тому же месту – смотришь кто-то уже подобрал с пола монеты. Или предметы в инвентаре испортились. Мир как будто живёт своей жизнью. В пещерах можно идти по коридорам, а можно наугад пробивать туннели заклинанием в надежде отыскать потайную комнату, оставляя на полу груду камней. Мир полный возможностей и способов взаимодействия.

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

Thinkpad T480 с i5 8350U троттлит в своей стоковой комплектации, я провёл несколько тестов с разными вариантами охлаждения процессора этого ноутбука, и детально сравнил результаты в этом гайде. Он будет полезен не только для владельцев T480, так как эти способы могут быть использованы и в других устройствах.

T480 выпускается в различных комплектациях, версия с i5 8350u без дискретной видеокарты имеет радиатор с одной медной трубкой, он справа на фотографии. Версия ноутбука с процессором i7 8550U и дискретной видеокартой mx150 имеет радиатор с двумя медными трубками и область для GPU.

Ничто не мешает поставить большой радиатор в ноутбук без дискретной видеокарты, чтобы значительно понизить температуру процессора. Я купил радиатор с двумя медными трубками на Aliexpress за 26$ (2100 рублей на момент написания статьи).
Маленький радиатор весит 69 грамм, большой 93.

Введение

• 12 m уникальных пользователей в месяц;
• Версии для всех современных платформ (Web, iOS, Android);
• Достаточно нагруженное приложение – около 800 тысяч подключений онлайн по WebSocket (основной протокол общения с пользователями).

• Вначале посмотрим глазами новичка. Что такое БД в памяти? Какие задачи они решают лучше дисковых БД?
• Потом посмотрим архитектурно. Как обстоит вопрос с производительностью, надёжностью, масштабированием?
• В третьей части лезем в технические вещи поглубже. Типы данных, итераторы, индексы, транзакции, ЯП, репликация, коннекторы.

Дабы исчерпать до дна тему сокетов в Python я решил изучить все возможные способы их использования в данном языке. Чтобы всех их можно было испытать и попробовать на зуб, были созданы 19 версий простого эхо-сервера: от примитивного использования класса socket до asyncio. Блокирующие и неблокирующие сокеты, процессы и потоки, select'ы и selector'ы, коллбеки и сопрограммы — все эти темы расположены в эволюционном порядке, чтобы один пример плавно перетекал в другой.

Отдельно разобрано появление асинхронности в Python. На примерах детально показано, как и зачем появились итераторы, из них — генераторы, сопрограммы. Ближе к концу построен учебный макет библиотеки asyncio с минимально необходимым кодом, чтобы любой (даже такой, как я) смог разобраться, как на самом деле устроена асинхронность, как там все внутри работает.

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

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

Мы берём Go, начинаем писать конкурентный код. Конечно, ожидаем, что легко сможем обуздать мощь каждого ядра нашего процессора. Так ли это?

Меня зовут Артемий. Этот пост — вольная расшифровка моего доклада с GopherCon Russia. Он появился как попытка дать толчок людям, которые хотят разобраться, как писать хороший, конкурентный код.

Видео с конференции GopherCon Russia

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

Данный обзор охватывает сразу несколько тем. Мы начнем с устройства решающего дерева и градиентного бустинга, затем подробно поговорим об XGBoost и CatBoost. Среди основных особенностей алгоритма CatBoost:

• Упорядоченное target-кодирование категориальных признаков
• Использование решающих таблиц
• Разделение ветвей по комбинациям признаков
• Упорядоченный бустинг
• Возможность работы с текстовыми признаками
• Возможность обучения на GPU

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

Практика показывает, что в современном мире Docker-контейнеров и оркестраторов (Kubernetes, Nomad, etc) проблема с утечкой памяти может быть обнаружена не при локальной разработке, а в ходе нагрузочного тестирования, или даже в production-среде. В этой статье рассмотрим причины появления утечек в Python-приложениях, доступные инструменты для отладки и мониторинга работающего приложения, а также общую методику поиска утечек памяти.