Компиляторы *

Я покажу вам, как написать небольшую программу, которая скачивает ленту(feed) в формате JSON, парсит и выводит список заметок на консоль в форматированном виде.

У нас все вылилось в очень лаконичный код. Как? Смотрите под катом.

Представьте себе, что есть некая очень полезная программа, но она, например, существует только в версии Windows и только 64 бита. А вам нужно, например, под ARM64 и под другую ОС, соответственно. Причём исходников у вас нет, и достать их невозможно.


Что делать? Существует проект MCSema (пост на Хабре про mcsema: https://habrahabr.ru/post/232871/). Его создатели (а они на финансировании DARPA, между прочим), обещают сказочные вещи: перевод бинарников в LLVM IR, оптимизации, семантический анализ кода и т.д. И конечно же, перекомпиляцию на любые архитектуры, которые поддерживает LLVM. Проект опенсорсный (ссылка на гитхаб: https://github.com/trailofbits/mcsema)

А теперь посмотрим, что происходит на самом деле.

Оба авторе: Лин Кларк — разработчик в группе Mozilla Developer Relations. Занимается JavaScript, WebAssembly, Rust и Servo, а также рисует комиксы о коде.

Люди называют WebAssembly фактором, меняющим правила игры, потому что эта технология ускоряет выполнение кода в вебе. Некоторые из ускорений уже реализованы, а другие появятся позже.

Одна из техник — потоковая компиляция, когда браузер компилирует код во время его загрузки. До настоящего времени эта технология рассматривалась лишь как потенциальный вариант ускорения. Но с выпуском Firefox 58 она станет реальностью.

Firefox 58 также включает в себя двухуровневый компилятор. Новый базовый компилятор компилирует код в 10–15 раз быстрее, чем оптимизирующий компилятор.

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



На десктопе мы компилируем 30-60 МБ кода WebAssembly в секунду. Это быстрее, чем сеть доставляет пакеты.

Мне приходит в голову множество разных целей для Rust в текущем 2018 году, к слову, 2017 год прошел для меня очень быстро, так что я задался следующим вопросом: если бы я мог выбрать одну-единственную цель для Rust в 2018 году, то что бы я выбрал?

Я буду пристрастен, и вот мое мнение:

Ключевое слово unsafe является неотъемлемой частью дизайна языка Rust. Для тех кто не знаком с ним: unsafe — это ключевое слово, которое, говоря простым языком, является способом обойти проверку типов (type checking) Rust'а.

Существование ключевого слова unsafe для многих поначалу является неожиданностью.
В самом деле, разве то, что программы не "падают" от ошибок при работе с памятью,
не является особенностью Rust? Если это так, то почему имеется легкий способ обойти
систему типов? Это может показаться дефектом языка.

Но не все так просто, детали — под катом.

Команда Rust рада сообщить о новой версии Rust: 1.23.0. Rust — это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Если у вас установлена предыдущая версия Rust, для обновления достаточно выполнить:

$ rustup update stable

Если же у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.23.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.23.0

Новый год, новый Rust! Нашим первым улучшением является избавление от избыточных копий в некоторых ситуациях. С этими изменениями потребление памяти rustc уменьшилось на 5-10%, но результаты для ваших приложений могут отличаться.

Команда документации прошла долгий путь для того чтобы rustdoc использовал CommonMark. До этого rustdoc не гарантировал какой движок отрисовки markdown он использовал. В рамках этого выпуска мы все еще визуализируем документацию нашим прошлым движком — Hoedown — но параллельно визуализируем еще и совместимым с CommonMark движком, выдавая предупреждения при различных результатах. Нам еще не встречались ситуации, где нельзя было бы изменить синтаксис документа так, чтобы он удовлетворял обоим движкам сразу. Участник команды документации Guillaume Gomez написал заметку об этом в своем журнале, где показаны некоторые часто встречающиеся отличия движков и способы их обхода.

По просьбам трудящихся, пишу о внутреннем устройстве WebAssembly.

WebAssembly — байткод для стековой виртуальной машины. Значит, для запуска кода такой нужны интерпретатор, стек и хранилище кода. Если мы хотим взаимодействовать с внешним миром, нужен интерфейс к внешней машине, хосту. Дополнительно стандарт определяет две структуры: непрерывную память и таблицы. В версии MVP стандарта их может быть по одной штуке каждого, или не быть вовсе.

В итоге, наш технобордель выглядит так:

• Интерпретатор
• Интерфейс к хосту
• Стек
• Хранилище кода
• Память
• Таблица

Займёмся делом!

Многие программисты не понаслышке знают о том, что программа на языке C и C++ собирается очень долго. Кто-то решает эту проблему, сражаясь на мечах во время сборки, кто-то — походом на кухню «выпить кофе». Это статья для тех, кому это надоело, и он решил, что пора что-то предпринять. В этой статье разобраны различные способы ускорения сборки проекта, а также лечение болезни «поправил один заголовочный файл — пересобралась половина проекта».

Представлять WebAssembly не нужно — поддержка уже есть в современных браузерах. Но технология годится не только для них.

WebAssembly — кроссплатформенный байткод. Значит, этот байткод можно запустить на любой платформе, где есть его виртуальная машина. И для этого вовсе не нужен браузер и Javascript-движок.

Далее — проверка концепции на прочность, инструментарий и первый скриптовый модуль.

Я большой поклонник Prometheus и Grafana. Поработав SRE в Google, я научился ценить хороший мониторинг и за прошедший год предпочитал пользоваться комбинацией этих инструментов. Я использую их для мониторинга своих личных серверов (black-box и white-box мониторинг), внешних и внутренних событий Euskal Encounter, для мониторинга клиентских проектов и много другого. Prometheus позволяет очень просто писать кастомные модули экспорта для мониторинга моих собственных данных, к тому же вполне можно найти подходящий модуль прямо из коробки. Например, для создания симпатичной панели имеющихся метрик Encounter-событий мы используем sql_exporter.

Продолжение. Начало здесь.

Введение

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

В моём углубленном курсе компиляторов прошлой осенью мы провели некоторое время, изучая дерево исходников LLVM. Миллион строк кода на C++ выглядят пугающе, но я нахожу это интересным упражнением, и, по крайней мере, некоторые студенты с этим согласны, и я подумал, что я попытаюсь написать что-то подобное. Мы будем использовать LLVM 3.9, но предыдущие (и, возможно, будущие) релизы не сильно отличаются.

Как-то раз моему коллеге в беклог упала задача «хотим организовать взаимодействие с внутренним REST-api так, чтобы любое изменение контракта сразу приводило к ошибке компиляции». Что может быть проще? – подумал я, однако работа с получившимся кактусом вынудила заняться многочасовым курениям документации, спуску от привычных концепций оверинжинеринга «налепим побольше интерфейсов, добавим максимум косвенности, и приправим всё это DI» до переезда на .Net Core, ручной кодогенерации промежуточного ассемблера и изучения нового компилятора C#. Лично я для себя открыл много интересного как в рантайме, так и в структуре самого компилятора. Думаю, некоторые вещи хабровчане уже знают, а некоторые станут полезной пищей для размышления.

Команда Rust рада сообщить о двух новых версиях Rust: 1.22.0 и 1.22.1. Rust — это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Подождите, две версии? В последний момент мы обнаружили проблему с новой macOS High Sierra в версии 1.22.0 и по разным причинам выпустили версию 1.22.0 как обычно, но так же выпустили 1.22.1 с исправлением. Ошибка была найдена в менеджере пакетов Cargo, а не в rustc, и затронула только пользователей macOS High Sierra.

Если у вас установлена предыдущая версия Rust, для обновления достаточно выполнить:

$ rustup update stable

Если же у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.22.0 и 1.22.1 можно ознакомиться на GitHub.

Что вошло в стабильную версии 1.22.0 и 1.22.1

Самое главное изменение в этой версии, которого многие долго ждали: теперь вы можете использовать ? с Option<T>! Около года назад, в Rust 1.13, мы ввели оператор ? для работы с Result<T, E>. С тех пор ведутся дискуссии о том, как далеко оператор ? должен зайти: Должен ли он остаться только для Result? Разрешать ли пользователям расширять его? Должен ли он использоваться с Option<T>?

В Rust 1.22, основное использование оператора ? с Option<T> стабилизировано. Теперь такой код соберется:

Из центральной части Канады — на юго-запад США! Альбукерке расположен в штате Нью-Мексико:



На встрече международного комитета по стандартизации C++, которая прошла в этом городе, приняли одно очень большое нововведение в С++20 и несколько маленьких.

Это руководство посвящено написанию простейшего компилятора на LLVM. Никакой предварительной подготовки не требуется.



Входным языком нашего компилятора будет BF. Это классический «игрушечный» язык для компиляторов, и даже есть компилятор BF в примерах к LLVM! В этом посте я приведу процесс написания компилятора с пояснениями.

В этой статье я покажу, как написать рудиментарный, нативный x86-64 just-in-time компилятор (JIT) на CPython, используя только встроенные модули.

Код предназначен для UNIX-систем, таких как macOS и Linux, но его должно быть легко транслировать на другие системы, типа Windows. Весь код опубликован на github.com/cslarsen/minijit.

Цель — сгенерировать в рантайме новые версии нижеприведённого ассемблерного кода и выполнить их.

48 b8 ed ef be ad de  movabs $0xdeadbeefed, %rax
00 00 00
48 0f af c7           imul   %rdi,%rax
c3                    retq

В основном, мы будем иметь дело с левой частью кода — байтовой последовательностью 48 b8 ed ... и так далее. Эти 15 байтов в машинном коде составляют функцию x86-64, которая умножает свой аргумент на константу 0xdeadbeefed. На этапе JIT будут созданы функции с разными такими константами. Такая надуманная форма специализации должна продемонстрировать базовую механику JIT-компиляции.

Когда я начинал карьеру разработчика, то очень удивился, прочитав фразу, которую приписывают Филу Карлтону (Phil Karlton): «В информатике есть лишь две сложности: инвалидация кеша и присвоение имён». Я отнёсся к этому недоверчиво, поскольку не понял сути фразы. Но немного позже я начал понимать.

Я хочу рассказать о проблеме, с которой мы столкнулись не так давно в нашей production-инфраструктуре. Сразу после успешного развёртывания при обновлении страниц, изменённых новым релизом, какое-то время не отображался новый код. Вообще-то такое далеко не редкость для веб-приложений, написанных на PHP. Мы сталкивались с подобным и раньше, а после перехода на новую production-среду проблема стала заметнее. Поэтому мы решили заняться расследованием.

Мы часто слышим, что некоторые люди утверждают, что проблемы, вытекающие из неопределённого поведения (UB) в C и C++ в основном решены путём широкого распространения инструментов динамической проверки, таких, как ASan, UBSan, MSan и TSan. Мы здесь покажем очевидное: несмотря на то, что в последние годы произошло множество прекрасных улучшений в этих инструментах, проблемы UB далеки от разрешения, и рассмотрим ситуацию в деталях.

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