Джон Кармак: «Парсинг» файлов и сетевых данных часто в 100 раз медленнее, чем мог бы быть

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

Например, как бы вы представили хеш-таблицу, где значения — строки, и программа случайным образом вставляет или удаляет случайную строку?

Это не похоже на то, что можно легко представить. Единственный способ, который я могу придумать, — держать стек, содержащий все ваши строки, и периодически его уплотнять.

Редактирование: Может быть, вы также могли бы иметь отдельный стек для строк разного размера. По одному для строк меньше 8, 16, ... байт. Но в этот момент вы, по сути, вручную реализуете свой собственный malloc.

Редактирование: Честно говоря, я думаю, что Goose очень крут! Мне приходилось вручную делать много подобных вещей в Rust, чтобы ускорить управление памятью.

«Потоки, которые ничего не разделяют. Воркер компилируется как отдельная программа с собственной памятью, и плоские значения пересекают типизированные очереди как memcpy. Гонки данных, блокировки, атомарные операции и порядок памяти не существуют в языке.»

Это напоминает мне Dart Isolates — https://dart.dev/language/isolates

Кажется, я помню, что ребята из ML пошли по этому пути. Я думаю, они называли это регионами.

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

Кто-нибудь знает больше деталей?

«Это выглядит действительно аккуратно! Автоматический анализ и использование нескольких стеков данных и полей изменяемого размера переводят это из «много работы можно сделать таким образом» в «практически всё можно».

Относительные ссылки и встроенная проверка двоичной структуры также позволяют напрямую отображать структуры данных в память и сразу использовать сетевые данные. «Парсинг» файловых и сетевых данных часто в 100 раз медленнее, чем мог бы быть.» — Джон Кармак

Это выглядит очень интересно! Я в основном пишу на языках со сборкой мусора (в той степени, в какой я вообще ещё пишу что-то вручную...), так что я просто зритель в дебатах об управлении памятью, но меня часто поражало, что управление кучей — это скорее искусство, чем наука. Идея рассматривать память больше как стеки сразу показалась мне интуитивно понятной. Меня также завораживает реализация потоков, хотя я недостаточно знаю, чтобы продумать потенциальные преимущества/затраты по сравнению с другими подходами к конкурентности.

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

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

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

В общем, я обычно ... [текст обрывается]

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

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

Как это будет работать в мире wasm? Вопрос немного плохо сформулирован, потому что упускает много контекста — wasm — где, как, какая реализация, но из моего простого понимания большая часть wasm — это 32-битная работа в браузере. Чтобы это работало, понадобится настоящее виртуальное 64-битное (или 48-битное) адресное пространство. Хост, будь то браузер или что-то ещё, может его предоставить, но....

Если хосту нужно загрузить несколько таких .wasm, скомпилированных с goose, то ему также придётся запускать их в отдельных (браузерных) экземплярах (или, может быть, wasm так работает по умолчанию — не уверен).

Это просто заставило меня задуматься — язык готов к трансляции в javascript workers, потому что он по своей природе действительно однопоточный с коммуникацией между потоками (или, выражаясь языком dart, «изолятами»), что делает их идеальными для браузера, теперь единственный вопрос — это раскладка памяти.