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

Эта статья обсуждалась на Hacker News.

В течение минувшего года я шлифовал мой подход к выделению регионов. Практика показывает, что это эффективный, простой и быстрый подход; обычно его используют в качестве средства для сборки мусора без издержек. В зависимости от того, что нам требуется, в аллокаторе может быть всего 7–25 строк кода — идеально для случаев, когда мы работаем без среды исполнения. Теперь, когда я окончательно сформулировал ключевые аспекты моего подхода, самое время их задокументировать и рассказать вам о том, что мне удалось выучить. Определённо, это не единственный возможный подход к выделению регионов. Я просто расскажу вам о приёмах, которые сам выработал для упрощения программ и искоренения ошибок.

Регион (арена) — это буфер памяти и смещение до этого буфера. Изначально это смещение равно нулю. Чтобы выделить объект, нужно взять указатель на него с заданным смещением, увеличить смещение на размер объекта, а затем вернуть указатель. Этим дело не ограничивается — например, нужно обеспечить выравнивание и доступность. До этого мы ещё дойдём. Объекты не высвобождаются каждый по отдельности. Напротив, сразу высвобождаются целые группы ранее выделенных объектов, и смещение откатывается к более раннему значению. Когда не предусмотрены собственные времена жизни для отдельных объектов, деструкторы писать также не требуется, а вашим программам не приходится прямо во время выполнения обходить структуры данных и убирать ненужные. Кроме того, больше можно не беспокоиться об утечках памяти.

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

Апдейт: ведущий разработчик Godot Хуан Линьетски опубликовал ответ на этот пост.

Преуведомление

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

Выпуск Java 21 состоялся 19 сентября 2023 года. В этой версии поддерживаются паттерны записи в switch-блоках и выражениях. Такой синтаксис выглядит монументально (как минимум, по меркам Java). Это водораздел, после которого мы вправе говорить, что в Java полноценно поддерживаются паттерны функционального программирования, подобно тому, как это сделано в Kotlin, Rust или C#. Вот и первый пункт, который пробуждает во мне зависть (я Kotlin-разработчик).

Серверные компоненты React – это большой кусок работы. Недавно мы переосмыслили нашу документацию и устроили ребрендинг Mux. Пока мы этим занимались, мы перенесли весь материал сайтов mux.com и docs.mux.com на серверные компоненты. Так что, поверьте мне… я знаю. Знаю, что это возможно, не так страшно и, в принципе, что дело того стоит.

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

Сколько родилось отличных проектов open source, потому что у кого‑то руки чесались что‑то попробовать! Именно так было и в случае с Firecracker. В 2014 году компания Amazon запустила AWS Lambda, которую позиционировала как «бессерверную» вычислительную платформу. В AWS Lambda пользователь может задать функцию — скажем, десять строк кода на Python — а Lambda в ответ достроит всю требуемую инфраструктуру, чтобы сработала цепочка: прибывает HTTP‑запрос, вызывается функция, запрос обрабатывается, и, наконец, генерируется ответ.

Чтобы этот сервис работал безопасно и эффективно, Amazon нужно было разработать механизм, который позволял бы с минимальными издержками запускать виртуальные машины. Так появился Firecracker. Это монитор виртуальных машин (VMM), работающий совместно с Linux KVM. Он запросто создаёт «микро-VM» и управляет ими.

Некоторое время назад в Интернете ходила статья о неопределённом поведении, просто бесившая коренную аудиторию Rust. Завсегдатаи С и C++ в ответ только бурчали, что кто-то просто не понимает Всех Тонкостей и Нюансов Их Светлейшего Языка. Как обычно, пришло время и мне постараться изо всех сил и вставить мои пять копеек в эту застарелую дискуссию.

Готовьтесь поговорить об Основной Проблеме языков C и C++, а также о Принципе Лома.

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

Как подтвердит любой, кому когда-либо доводилось проходить собеседование по программированию, при наличии арифметической и геометрической прогрессии геометрическая всегда возобладает. При горизонтальном масштабировании расходы растут линейно (арифметически). Но по закону Мура вычислительные мощности со временем растут экспоненциально (геометрически). Это означает, что можно несколько лет ничего не делать, а затем масштабировать систему вертикально и получать улучшение на порядки. За двадцать лет плотность транзисторов возросла в  1000 раз. Это значит, что такая задача, для решения которой в 2002 году потребовались бы тысячи машин, сегодня выполнима всего на одной.

Вы когда-нибудь пробовали скачивать видео с YouTube? Я имею в виду ручками, а не через такие софтины, как youtube-dl, yt-dlp или один из «этих» сайтов. Оказывается, это гораздо сложнее, чем можно было бы подумать.

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

Привет, Хабр. Вашему вниманию предлагается сокращённый перевод эпичного поста под авторством Энди Уорфилда, вице-президента и заслуженного инженера в компании Amazon, занятого разработкой S3. Пост основан на его пленарном выступлении с конференции USENIX FAST ‘23 и затрагивает три различных аспекта, касающихся выстраивания и эксплуатации такого огромного хранилища данных как S3. Если пост окажется интересным - рассмотрим вариант перевести и вторую часть

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

tldr; в статье рассмотрены приёмы, позволяющие ускорить обучение больших языковых моделей (LLM) и нарастить в них логический вывод. Для этого нужно использовать большое контекстное окно, в котором умещается до 100K входных токенов. Вот эти приёмы: ALiBi с подмешиванием в вектор позиции слова в последовательности (positional embedding), разреженное внимание (Sparse Attention), мгновенное внимание (Flash Attention),  многозапросное внимание, условные вычисления и GPU A100 на 80 ГБ.  

Как ушлый румынский экономист легально обставил лотерейную систему, выиграв миллионы долларов по всему миру.

Вечером в минувшую среду один калифорниец выиграл $1,08 миллиарда в лотерею Powerball – это один из самых больших кушей в истории. Но не эта игровая победа самая невероятная в истории. Ниже предлагается перевод сюжета, впервые опубликованного в августе 2018 года и рассказывающего об экономисте, по-настоящему преуспевшем в лотереях:

15 февраля 1992 года вскоре после 11 утра неказистый лототрон, крутившийся в эфире лотереи Штата Виргиния, выдал на всеобщее обозрение 6 шаров с выигрышными номерами: 8… 11… 13… 15… 19… 20.

В ближайшие дни властям довелось выяснить, что «некто» сорвал не только джекпот на сумму $27 036 142, но и 6 вторых призов, 132 третьих и 135k мелких выигрышей на сумму ещё $900k.

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

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

Вот вам тупой вопрос, который вы сами, наверное, никогда себе не задавали. Каково минимальное количество байт, которые необходимо сохранить в исполняемом .NET-файле, чтобы CLR напечатала "Hello, World!" в консоли стандартного вывода?

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

На дворе 2023 год. Весь Интернет — под контролем Империи GAFAM. Весь? Нет, несколько мелких анклавов пока не поддались их гнёту. А некоторые из этих непримкнувших стали объединять усилия, консолидируясь в «Федиверс».

В ходе дебатов на просторах Twitter и Reddit, Федиверс стал привлекать всё больше внимания и снискал славу. Люди стали всерьёз им пользоваться. Это не могло укрыться от внимания Империи.  

Распространено мнение, будто современные высокопроизводительные процессоры x86 работают так: декодируют «сложные» инструкции x86 в «простые» RISC-подобные инструкции, которые затем обрабатываются в оставшейся части конвейера. Но насколько эта идея на самом деле отражает, как именно устроен внутри процессор?

Чтобы ответить на этот вопрос, давайте проанализируем, как следующий простой цикл обрабатывают различные процессоры x86, от P6 (первой микроархитектуры Intel «современного» типа до современных конфигураций). Код сделан 32-разрядным лишь для того, чтобы можно было затронуть и очень старые процессоры с архитектурой x86.

С прошлой осени Нивен проходит стажировку, разрабатывая новую модель псевдонимов для Rust: древовидные заимствования (tree borrows). Секундочку, уже слышу, как вы вопрошаете: а разве в Rust ещё нет своей псевдонимной модели? Разве вы, автор, не рассказываете повсюду о «стековых заимствованиях»? Действительно, так и есть, но стековые заимствования — всего лишь один из возможных вариантов реализации для модели псевдонимов, и с этим вариантом есть свои проблемы. Древовидные заимствования призваны учесть опыт, усвоенный при работе со стековыми заимствованиями, и построить новую модель, не такую проблемную. Также при её проектировании принимаются немного иные решения, с учётом некоторых нужных компромиссов и той тонкой настройки, которая, возможно, должна быть привнесена в эти модели, и только потом настанет время решать, какую же из этих моделей принять в Rust в качестве официальной.

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

Для краткости я буду иногда называть стековые заимствования «СЗ», а древовидные заимствования — «ДЗ».

В одном недавнем подкасте о том, кто сейчас главный в Rust, вновь всплыл вопрос о том, кому быть BDFL (великодушным пожизненным диктатором), и Джереми Соллер сказал (это был чемпионский заход на приз «за преуменьшение века»): «Я считаю, Грейдон забраковал бы некоторые вещи, которые всем нам сейчас нравятся». Этим он вторит другой дискуссии на reddit, в которой мне напомнили, что я собирался как-нибудь расписать, каким образом «я сделал бы всё по-другому». Вероятно, это бы крайне не понравилось всем причастным, и эти идеи далеко бы не распространились.

Ну и ну. Я понял, что следующий момент не вполне очевиден и он, пожалуй, заостряет вопрос, «а действительно ли в проекте нужен BDFL». Так вот, озвучу его: Rust Нашего Времени далеко, далеко отстоит от Rust Моей Мечты. Главное, не поймите меня неправильно: мне нравится, что у нас получилось. Получилось отлично. Я воодушевлён, что теперь есть столь жизнеспособная альтернатива C++, в особенности такая, которую другие люди уже начинают воспринимать как норму, как реальный вариант для повседневной работы. Я пользуюсь Rust и очень доволен, что могу отдавать ему предпочтение перед C++. Но!

Я столько всего сделал бы в Rust по-другому, если бы всё это время «отвечал» за его развитие.

Вам знакомы муки, когда пытаешься добиться чего-то от тормознутого сайта, а он не реагирует на щелки мыши или пробуксовывает при прокрутке? Подобные проблемы с производительностью могут провоцировать:

Нервозное перещёлкивание (rage clicking)

Повышенный отток пользователей и снижение показателей конверсии

Потерю позиций в поисковой выдаче

Более трёх лет мобильная версия Википедии сбоила из-за фрагмента кода на JavaScript, выполнение которого могло занимать более 600 мс при загрузке страницы на маломощных устройствах. В результате работать со страницей становилось попросту невозможно.

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