Мне нравится оптимизировать код — определение и исправление неэффективных участков кода приносит некое особое чувство удовлетворения в отличие от закидывания проблемы железом. Ведь последнее — пустая трата ресурсов и выбросов углерода!

В процессе моей работы я много раз оптимизировал использование памяти датафреймов Python. Не учитывая различные особенности, зачастую наиболее быстрым решением является понижающее приведение — к примеру, конвертация столбца нулей и единиц из int в bool. И хотя это срабатывает, недавно к своему удивлению я узнал, что булевы числа не всегда отображаются в качестве одиночных битов. Так как же отображаются типы данных в памяти?

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

Шаблоны проектирования распределенных систем предоставляют разработчикам проверенные решения и передовые методы проектирования и внедрения распределенных приложений.

Совершать невозможное и раздавать пинки здравому смыслу — в этом и состоит жизнь членов Гуррен-Дана! (C) Камина

Эта статья вступает в техническую полемику со статьей 2015 года за авторством Atakua, подходы из которой я и атакую. Atakua исследует 7 видов интерпретаторов байткода, но делает это без уважения - быстрейшей оказывается двоичная трансляция, которая, по сути, уже не интерпретатор байткода, а форма Ahead-Of-Time компилятора. Эта двоичная трансляция транслирует байткод в машинный код, представляющий собой цепочку вызовов скомпилированных сервисных процедур. Тех самых, что в интерпретаторе байткода отвечают за выполнение каждого опкода.

Но Atakua не выжал из интерпретаторов байткода всю скорость которая возможна. Так что эта статья - туториал: как написать интерпретатор байткода, который может обгонять JIT/AOT-компиляцию по скорости. Интересно? Читайте дальше!

Бенчмарк прилагается. Будет немного хардкора и ни одной сгенерированной нейросетью картинки!

Команда Spring АйО перевела и адаптировала доклад "Garbage Collection in Java: The progress since JDK 8" Стефана Йоханссона(Stefan Johansson) с последнего Devoxx Belgium.

Доклад получилось поделить на две статьи. В первой вы узнаете об основах работы сборки мусора в Java, различных сборщиках мусора, а также об их особенностях, плюсах и минусах. Вторая часть будет посвящена сравнению производительности сборщиков и их прогрессу с момента выхода JDK 8.

Волновой алгоритм — это алгоритм поиска пути, который использует волновое распространение для определения кратчайшего пути от начальной вершины до целевой вершины.

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

Привет, Хабр!

Сегодня мы рассмотрим одну из задач высоконагруженных приложений — горизонтального кеширования. Когда система начинает испытывать давление под наплывом пользователей, стандартный кеш не всегда справляется. В таких ситуациях на помощь приходит Redis Cluster. Рассмотрим, как масштабировать кеширование в PHP с помощью Redis Cluster, чтобы распределить нагрузку, повысить отказоустойчивость и не потерять в производительности.

В конце технического интервью, если кандидат ответил на вопросы и справился с задачами, у нас есть время для свободных вопросов, которые можно задать команде или кому-то из интервьюеров. Эту практику я переносил из компании в компанию, и она всегда помогала разрядить обстановку или вывести человека на разговор, если он был напряжен во время общения. Вопросы могут быть любые, кроме личных или тех, что под NDA. Обычно кандидаты задают технические вопросы по стеку, пайплайнам, иногда пытаются задать каверзные вопросы, особенно по плюсам, чтобы проверить нас. Иногда мы не можем ответить на них. Вопросы в стиле Google — например, «почему таблетки круглые?» — тоже встречаются, но недавно на одном из интервью прозвучал вопрос, на который вроде все и знали ответ, но никто сразу не смог его дать. Вопрос звучал так: «Какие общие технологии и решения появились в процессорах с времён 486, которыми мы часто пользуемся?»

Вопрос действительно интересный — что нового появилось, чем мы пользуемся каждый день? Что умеют современные процессоры, чего не могли процессоры год или два назад, пять или десять лет назад, сорок лет назад? Мы просто используем миллиарды транзисторов, даже не зная, как они работают. Покопавшись в Википедии, на сайте Агнера Фога и в документации Intel, я составил список того, что появилось и используется в современных процессорах. Всё, что указано ниже, относится в основном к x86 и консолям, если не указано иное. Поскольку консоли после третьего поколения PlayStation — фактически ПК с минимальными отличиями, речь дальше пойдёт в основном о ПК. История имеет склонность повторяться, и многое из того, что мы сейчас имеем, вводилось не один раз, просто под разными названиями.

Привет! Меня зовут Михаил Боровиков, я тимлид команды, которая отвечает за систему процессинга заказов Lamoda — Orders Management. Эта система, словно «сердце» Lamoda, через которое проходит самый важный для бизнеса шаг — оформление заказа.

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

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

Давайте представим, что вы устроились много лет назад в 2GIS и вам выпала честь написать алгоритм, который будет прокладывать самый короткий автомобильный маршрут от точки A к точке B.

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

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

Теперь вы, как специалист на посту разработчика 2GIS изучили местность более подробно и поняли, что BFS не подходит для решения вашей задачи, так как дороги имеют разную протяженность и маршрут от A до B не может исчисляться в условной единице.

Оказалось, что тема суммирования целых чисел в кодировке ASCII в Haswell со скоростью memcpy гораздо популярнее, чем я мог ожидать. Именно поэтому я решил поучаствовать и в другом челлендже в жанре HighLoad: подсчёт uint8. В настоящее время я занимаю всего лишь 13 место в списке лидеров, проигрываю первому месту около 7%, но уже узнал немало интересного. В этом посте я полностью опишу моё решение, в том числе, удивительный паттерн считывания из памяти. Используя его, можно примерно до 30% (по сравнению с обычным последовательным доступом) повысить скорость передачи в контексте одноядерных рабочих нагрузок, ограниченных размером кэша. По-видимому, этот метод малоизвестен.

Как и в других постах автора, программа настроена для следующих входных характеристик высоконагруженной системы: Intel Xeon E3-1271 v3 @ 3,60 ГГц, ОЗУ 512 МБ, Ubuntu 20.04. В ней используется только AVX2, а AVX512 не используется.

Итак, Linux - не операционная система, а только ядро для неё. Всё остальное приходит от проекта GNU (и других). И вот интересно - на что годится ядро само по себе?

Эта статья - очень "начального" уровня. Устроим маленький эксперимент - создадим чистую виртуальную машину и попробуем запустить ядро Linux "без всего". Или почти "без", т.к. нам понадобится загрузчик ОС - и какая-нибудь "пользовательская программа" (её мы сотворим сами). Конечно, продвинутые пользователи Linux такой "эксперимент" могут провести просто отредактировав параметры запуска при включении - но наш рассказ всё же для тех кто почти (или совсем) не в теме :)

Бонусом чуть-чуть коснёмся системных вызовов и пару слов скажем о других ядрах.

Хотя алгоритмы определения простоты числа известны с древних времён, полиномиального алгоритма долгое время известно не было. То есть было неизвестно, принадлежит ли эта задача классу сложности P. В 2002 году индийскими математиками Агравалом, Кайялом и Саксеной был впервые предложен полиномиальный алгоритм проверки простоты чисел, поставивший точку в этом вопросе.

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

«В то время я ошибочно полагал, что физики настроены на левое ухо Бога», — говорит Джонсон.

Окончив в 1950 году в возрасте 19 лет Университет Миннесоты Twin Cities со степенью бакалавра по физике, он собирался поступать в аспирантуру, когда ему позвонил руководитель физического отдела научно-исследовательской лаборатории компании 3M и предложил работу. Соблазнившись перспективой делать всякое своими собственными руками, Джонсон согласился на должность физика на предприятии компании в Сент-Поле, штат Миннесота. Так началась его более чем семидесятилетняя карьера инженера-электрика, изобретателя и предпринимателя, которая продолжается и по сей день.

MariaDB Server исполняется 15 лет! Вот 15 причин, по которым разработчики и администраторы баз данных любят его!

Для начала нужно понять главное - файлов не существует.
А потом на примере простых манипуляций разобрать что такое hard links, чем может быть полезен непонятный XOR и как это всё уживается в системах копирования и снимков

Okko – один из крупнейших онлайн-кинотеатров в России c нагрузкой в несколько тысяч запросов в секунду, в котором персональные рекомендации занимают важное место. Для улучшения пользовательского опыта нужно не только предоставить качественные рекомендации, но и обеспечить быстрый доступ к ним.

В этой статье мы поделимся:

1. Описанием, как мы использовали инструменты Jaeger и Grafana для выявления узких мест в производительности, что привело к выявлению критических проблем со сборщиком мусора;

2. Анализом влияния различных настроек сборщика мусора на время ответа, что позволило сократить его вдвое для 99% запросов;

3. Когда и почему стоит рассматривать изменение стандартных настроек сборщика мусора (на примере нашего случая).

Статья для тех кто не знаком с ассемблерами - но хочет взглянуть "одним глазком". Мы не сделаем вас гуру разработки на ассемблере за 15 минут - но покажем ассемблеры для нескольких популярных архитектур микроконтроллеров (ARM32, AVR, MSP430, 8051) - и для настольных наших компьютеров (x86 под Linux и DOS) - чтобы увидеть их различия и сходства - и не бояться погрузиться глубже, если что-то из этого может быть вам полезно.

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

Бонусом - для любопытных - ассемблер для Intel-4004 - 4-разрядного процессора которому уже больше 50 лет. К нему будет также небольшой "интерактивчик".

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

Можно ли с этим что-то сделать? Конечно! Добро пожаловать под кат, там вас ждет готовое решение и куча технических подробностей.