Привет, Хабр! Меня зовут Александр Иванов, я разрабатываю средства управления сетевыми элементами сотовой связи и пишу на языке Go в YADRO. Однажды я работал над приложением, которое испытывало пиковые нагрузки каждые 10 минут, но выполнить обработку памяти быстро мешал Garbage Collector. Чтобы решить эту проблему, я изучил несколько способов реализации memory pool и провел испытания скорости работы. 

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

В первой части статьи мы рассмотрели, как можно вручную ускорить Go-код с помощью векторизации и SIMD-инструкций, реализованных через Go-ассемблер. Написали простую, но показательно быструю реализацию sliceContains и увидели, что даже базовая векторизация может дать ускорение в 10–14 раз по сравнению со стандартной реализацией.

Во второй части статьи погрузились в практическое применение SIMD в Go-ассемблере, реализовали функцию SliceContainsV1 и изучили, как с помощью VADD, VDUP и других инструкций можно добиться 10–14-кратного ускорения простых задач.

Но возможности оптимизации Go-программ на этом не заканчиваются. В этой части мы пойдём дальше: рассмотрим другие техники низкоуровневой оптимизации — от использования C-кода и альтернативных компиляторов с поддержкой векторизации до работы с аппаратными транзакциями памяти на Intel. Поговорим о том, как внедрять ассемблер в продакшен-код, не боясь за его поддержку, и как обойти ограничения стандартного Go-компилятора.

Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества, веду телеграм-канал и youtube-канал. Если вы уже знакомы с базовыми техниками векторизации, эта часть поможет глубже понять, как устроены продвинутые способы ускорения Go-кода и на что стоит обратить внимание при работе с архитектурно-зависимыми оптимизациями.

В то время как ещё не вышедшие новые герои обрастают хейтерами («о нет, мобильная графика»), безусловными фанатами («давно жду, дайте две») и пессимистично‑настроенной публикой («не вывезут, у них из опыта только Iratus») — в Olden Era оказалась упущена другая возможность развития серии. А именно — боёвка в стиле Disciples 1/2.

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

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

Начнем с бекграунда и причин.

Я – инженер машиностроитель (мой профиль – торцевые уплотнения вращающихся валов). Я начал работать в своей отрасли сразу после бакалавра, параллельно заканчивая магистратуру, и как только я начал работать, я стал стараться впитать как можно больше теоретических знаний по моей специальности из академических источников. Достаточно бысто я понял, что последняя серьезная книга по моей специальности на русском языке была написана в 1978 году. И спустя больше чем 40 лет технологии сильно поменялись, а вот их описание на русском языке отсутствовает. Зато я нашел на reddit людей работающих в штатах в моей же отрасли. Они мне насоветовали кучу классной литературы. Разумееется, она вся на английском, и русского перевода не имеет.

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

Конечно, перед началом обучения я прочитал много статей на хабре о том как люди учат языки. Некоторые из них поражали скоростью овладения материалом (что-то вроде с нуля до fluent за 4 месяца). Но одна вещь была неизменна – у всех был какой-то план изучения языка.

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

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

Поэтому сегодня мы поговорим об установке и использовании графической панели 3X-UI для сервера X-Ray с поддержкой всего того, что умеет X-Ray: Shadowsocks-2022, VLESS с XTLS и т.д.

Привет Хабр!

В своей предыдущей статье про разбор кода победившего в VK Cup'22/23 я описывал как мне удалось ускорить копирование одной картинки в другую в 30 раз с помощью чёрной магии unsafe. Однако я не переставал задаваться вопросом, можно ли увеличить скорость еще больше. Я даже привлёк OpenAI в поисках решения, но он мне помог только с картинкой для обложки статьи. В итоге я нашел способ улучшить код еще в 2 раза. Чем и хочу поделиться.

Создаём объём при помощи света и теней.

Игра двухмерная, разрабатывается на Game Maker Studio 2 и во время работы я столкнулся с множеством задач а-ля «должно быть красиво». Где-то пришлось придумать свой велосипед, где-то повезло наткнуться на описание решения похожих задач.

В свое время меня очень вдохновила статья про рендер в Graveyard Keeper - это очень классный материал для разработчика 2D игр, в сети подобного довольно мало. Поэтому надеюсь, что моя статья тоже послужит для кого-то источником вдохновения.

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

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

Думаю, это очень классная история, когда ты подарил цветы, а они не вянут целый год!

Стабилизированное растение больше напоминает свежесрезанный цветок, чем мумифицированный остов из гербария. Оно остается эластичным — его можно трогать, не боясь, что растение рассыплется от прикосновения.

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

UPDATE Анализ устарел минимум на полгода. Более свежий анализ на февраль 2021 здесь.

На Московской Бирже торгуется сейчас 44 ETF и БПИФа. Это биржевые фонды, которые держат в себе готовые специализированные портфельчики и запакованные в stand-alone акцию (будто микросервис в докер-контейнере). Эту акцию можно купить, получив долю в общем портфеле.

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

Есть интерактивная версия матрицы (осторожно, трафик)

Начнем сразу с результатов анализа биржевых фондов. В матрице выше — корреляции всех ETF и БПИФ, которые появились до января 2020. До 20-го года БПИФов было слишком мало, анализировать там нечего.

В начале была технология и называлась она BPF. Мы посмотрели на нее в предыдущей, ветхозаветной, статье этого цикла. В 2013 году усилиями Алексея Старовойтова (Alexei Starovoitov) и Даниэля Боркмана (Daniel Borkman) была разработана и включена в ядро Linux ее усовершенствованная версия, оптимизированная под современные 64-битные машины. Эта новая технология недолгое время носила название Internal BPF, затем была переименована в Extended BPF, а теперь, по прошествии нескольких лет, все ее называют просто BPF.

Грубо говоря, BPF позволяет запускать произвольный код, предоставляемый пользователем, в пространстве ядра Linux и новая архитектура оказалась настолько удачной, что нам потребуется еще с десяток статей, чтобы описать все ее применения. (Единственное с чем не справились разработчики, как вы можете видеть на кпдв ниже, это с созданием приличного логотипа.)

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

Прелюдия

1. Language Mechanics On Stacks And Pointers (перевод)
2. Language Mechanics On Escape Analysis (перевод)
3. Language Mechanics On Memory Profiling
4. Design Philosophy On Data And Semantics

Вступление

Задался вопросом размещением массивов и слайсов на стеке, подобно std::array в C++ и массивам в Си. Про стек хорошо написал Vincent Blanchon в статье Go: How Does the Goroutine Stack Size Evolve?. Винсент рассказывает про изменения стека в горутинах. Резюмируя:

• минимальный размер стека 2 KB;
• максимальный размер зависит от архитектуры, на 64 битной архитектуре 1 GB;
• каждый раз размер стека увеличивается вдвое;
• стек как увеличивается, так и уменьшается.

Выясню сколько можно положить на стек и какой оверхед может с собой принести.

Дисклеймер:

You've run into a really hairy area of asm code.
My first suggestion is not try to call from assembler into Go. — Ian Lance Taylor

До тех пор, пока ваш ассемблерный код делает что-то простое, всё выглядит неплохо.

Как только у вас возникает задача вызвать из ассемблерного кода Go функцию, один из первых советов, который вам дадут: не делайте так.

Но что если вам это очень-очень нужно? В таком случае, прошу под кат.