⚡️ Насколько быстр Go? Симуляция миллионов частиц на смарт-ТВ

Команда Go for Devs подготовила перевод статьи о том, насколько быстрым может быть Go. Автор проверил это на практике — написал симуляцию миллионов частиц с мультиплеером, только на CPU и так, чтобы оно работало даже на смарт-ТВ.

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

📚 Подробности на Хабр: https://habr.com/ru/articles/953434/

🤨 Goiaba: Go-компилятор на Rust

Raph Amorim решил написать компилятор для Go… на Rust. Проект называется Goiaba (в переводе с португальского — гуава), и это пока эксперимент, но довольно показательный.
Автор известен по вкладам в экосистему WebAssembly и Wasmer. Его цель — исследовать, насколько реально собрать полноценный Go-компилятор с нуля на Rust, не используя LLVM, TinyGo или классический toolchain от Google.

• Goiaba написан на чистом Rust, без зависимостей от существующих Go-компиляторов.
• Потенциально может использоваться как библиотека внутри Rust-проектов.
• Может компилировать Go-код в WebAssembly, как TinyGo, но с иным подходом к архитектуре.
• Сообщество уже спорит, сможет ли он быть быстрее официального Go-компилятора (сомнительно, но Rust даёт шанс на более безопасные оптимизации).

На Hacker News обсуждение быстро скатилось в старую добрую войну “Rust vs Go”: кто быстрее компилирует.

> Скорость компиляции — не то, о чём я переживаю в Go. В отличие от Rust, с которым я почти не работаю — в том числе именно из-за скорости компиляции.

> Меня реально удивляет, что люди до сих пор жалуются на скорость компиляции Rust. Я работал с довольно большими проектами — отладочная сборка занимает несколько секунд, релизная — меньше минуты. Это точно не хуже, чем сборка TypeScript.

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

Репозиторий на GitHub
Обсуждение на Hacker News

@go_for_devs

Не, ну какие контрол-фрики эти правила придумывают

Может, еще пробелы по штангенциркулю подравнять?

🪲 Cloudflare нашли редчайший баг — прямо в компиляторе Go для ARM64!

Да, это не опечатка: не рантайм, не race condition в их коде, а чистый косяк в сгенерированном машинном коде Go. И баг был настолько редким, что проявиться он мог только в инфраструктуре масштаба Cloudflare — при 84 миллионах HTTP-запросов в секунду.

На ARM64-машинах Cloudflare стали вылезать странные паники вроде traceback did not unwind completely — ошибка, указывающая на повреждённый стек при попытке раскрутки. Поначалу инженеры списали это на баг в старом коде с panic/recover, потом — на библиотеку Go Netlink. Но когда даже без неё паники продолжились, стало ясно: проблема глубже.

После недель отладки выяснилось: краш происходит при асинхронном вытестении (введённом в Go 1.14), когда рантайм прерывает горутину между двумя машинными инструкциями, корректирующими указатель стека. В этот момент стек оказывается в «разрезанном» состоянии — раскрутчик стека получает некорректный указатель и падает.

Инженеры написали минимальный Go-пример, где функция с большим стеком (>64 КБ) порождает тот самый двойной ADD. После пары минут работы программа стабильно умирала с SIGSEGV. Без сторонних библиотек. Только чистый Go.

package main

import (
"runtime"
)

//go:noinline
func big_stack(val int) int {
var big_buffer = make([]byte, 1 << 16)

sum := 0
// предотвращаем оптимизацию стека компилятором
for i := 0; i < (1<<16); i++ {
big_buffer[i] = byte(val)
}
for i := 0; i < (1<<16); i++ {
sum ^= int(big_buffer[i])
}
return sum
}

func main() {
go func() {
for {
runtime.GC()
}
}()
for {
_ = big_stack(1000)
}
}

Разобравшись, они подтвердили: это ошибка в компиляторе Go, который на ARM64 разбивает корректировку стека на две инструкции, не учитывая возможность асинхронного вытеснения между ними.

Go-команда признала баг и исправила его в версиях go1.23.12, go1.24.6 и go1.25.0.

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

Источник

@go_for_devs

⚡️ 1 000 000 узлов в Kubernetes

Кажется, кто-то снова решил побить рекорды: проект k8s-1m замахнулся на кластер из миллиона узлов.

Если вкратце:

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

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

3. Основное ограничение выявилось не в самом Kubernetes, а в используемом хранилище данных. Стандартный etcd оказался узким местом при высокой частоте обновлений. В проекте его заменили на более лёгкую in-memory реализацию, что позволило увеличить скорость обработки и снизить задержки.

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

Полный обзор на Хабр
Инструкция по запуску

@go_for_devs

💥 Как memory maps (mmap) обеспечивают в 25 раз более быстрый доступ к файлам в Go

Одно из самых медленных действий, которое можно совершить в приложении, — это системный вызов. Они медленные, потому что требуют перехода в ядро, а это дорогостоящая операция. Что делать, если нужно выполнять много операций ввода-вывода с диском, но при этом важна производительность? Один из вариантов — использовать memory maps.

Memory maps — это современный механизм Unix, позволяющий «включить» файл в виртуальную память. В контексте Unix «современный» означает появившийся где-то в 1980-х или позже. У вас есть файл с данными, вы вызываете mmap, и получаете указатель на участок памяти, где эти данные находятся. Теперь, вместо того чтобы делать seek и read, вы просто читаете по этому указателю, регулируя смещение, чтобы попасть в нужное место.

Производительность

Ниже сравнение производительности при чтении файла через memory map и через ReaderAt. ReaderAt использует системный вызов pread(), совмещающий seek и read, а mmap просто читает напрямую из памяти.

Случайное чтение (ReaderAt): 416.4 ns/op
Случайное чтение (mmap):      3.3 ns/op
---
Итерация (ReaderAt):          333.3 ns/op
Итерация (mmap):              1.3 ns/op

Почти как магия. Возможно кто-то из вас помнит Varnish Cache – ускоритель HTTP, разработанный для динамических веб-сайтов с большим количеством контента. В 2006 году именно эта возможность делала его настолько быстрым при выдаче контента. Varnish Cache использовал memory maps, чтобы доставлять данные с невероятной скоростью.

Кроме того, поскольку можно работать с указателями на память, выделенную memory map, снижается нагрузка на память и уменьшается общая задержка.

Обратная сторона memory maps

Недостаток memory maps в том, что по сути в них нельзя писать. Причина кроется в устройстве виртуальной памяти.
Когда вы пытаетесь записать в область виртуальной памяти, которая не отображена на физическую, процессор вызывает page fault. Современный CPU отслеживает, какие страницы виртуальной памяти соответствуют каким физическим страницам. Если вы пишете в страницу, которая не сопоставлена, процессору нужна помощь.

При page fault операционная система:

1. Выделяет новую страницу памяти.
2. Считывает содержимое файла по нужному смещению.
3. Записывает это содержимое в новую страницу.
4. Затем управление возвращается приложению, и оно перезаписывает эту страницу новыми данными.

Можно просто поаплодировать тому, насколько это неэффективно. Думаю, можно с уверенностью сказать: писать через memory map — плохая идея, если важна производительность, особенно если есть риск, что файл ещё не загружен в физическую память.

Вот несколько бенчмарков:

Запись через mmap, страницы не в памяти: 1870 ns/op
Запись через mmap, страницы в памяти:     79 ns/op
WriterAt:                                 303 ns/op

Как видно, наличие страниц в кэше критически влияет на производительность. WriterAt, использующий системный вызов pwrite, даёт куда более предсказуемые результаты.

Тем не менее, в начале Varnish Cache действительно писал через memory map. Как-то это срабатывало — в основном потому, что конкуренты тогда были гораздо хуже.

Источник

@go_for_devs