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

Всем Хабр! Совсем недавно открыл для себя некоторые прелести Латеха и начал активно в нем работать. По ходу дела возникали разные интересные мысли, которыми здесь и поделюсь. В статье пойдет речь о моих небольших дополнениях к мат-нотациям, которых мне не хватало, а также о том, как построить Машину Тьюринга с помощью оных.

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

Когда в публичном пространстве появляется информация о новом языке программирования, поднимается волна неприятия. Негатива столько, что хоть святых выноси!

Причин у этого явления много и, скорее всего, сделать с ним ничего нельзя, такова уж человеческая природа.

Однако можно подойти к вопросу рационально, и все-таки попробовать поискать ответ на вопрос, а зачем, собственно, создавать новый язык программирования?

Попробуем разобрать мотивы, подвигающие людей на такую работу.

Как водится воскресным вечером, снова я с моим компилятором. На этот раз я расскажу, как работают области видимости переменных и как перегружать функции. Это позволит нам скомпилировать демку про́клятого огня, а также я накидал фантазию на тему игрушки арканоид (скриншот на КПДВ, видео в конце статьи). Я на удивление сам долго залипал на эту анимацию :)

На всякий случай я даю код и на wend, и на C, поскольку понимаю, что код на моём языке вряд ли интересен кому-то помимо того, кто реально возьмётся за компилятор. А вот мелкий код с интересными эффектами всегда найдёт свою публику. Кстати, если у вас есть идеи на тему чего-то интересного, что можно запрограммировать в полста строчек кода, делитесь в комментариях, я внимательно слушаю!

Вы когда-нибудь пробовали компилировать program helloworld на Rust в режиме --release? Если да, то видели, какой размер двоичного файла получается? Достаточно сказать, что он не очень маленький. Или, по крайней мере, не был таким до недавнего времени. В этом посте я расскажу, как узнал об этой проблеме и попытался устранить её в Cargo.

Какое-то время назад, во время разбора кода, мы обсудили выбор dict() вместо {} в новом коде на Python. Коллега утверждал, что dict() более читаем и чётче выражает цель, поэтому следует предпочесть его. Меня это не убедило, но в тот момент контраргуентов не нашлось, поэтому я воздержался.

Это заставило меня задуматься: в чём разница между типом dict и литеральным выражением {}?

Давайте изучим этот вопрос.

Только что вышла новая версия 1.3 моего встраиваемого скриптового языка Umka со статической типизацией. С момента выпуска версии 1.0 язык пополнился замыканиями, инструкцией выбора switch по фактическому типу интерфейса, тернарным условным оператором, более удобным API для взаимодействия с кодом на C, другими мелкими радостями.

Маленькое, но упрямое сообщество пользователей Umka всерьёз озаботилось библиотеками, появился менеджер пакетов UmBox, загружающий и устанавливающий библиотеки и отслеживающий их зависимости.

Umka живёт в ядре фреймворка Tophat для создания 2D игр. На основе этого фреймворка развивается платформер-головоломка SaveScum. Коллекция пробных уровней для игры была выпущена в декабре в виде адвент-календаря, принеся с собой дух простого геймерского счастья в наш проект.

Продолжаем разговор. На прошлой неделе я пообещал за выходные написать компилятор из простенького мной придуманного языка в ассемблер. В назначенное время уложился, и компилятор даже вроде работает, см. заглавную картинку. Теперь дело за малым, потихоньку причесать и стройно изложить. В прошлый раз я рассказал про синтаксические деревья и показал простейший транслятор в питон (по факту, обычный pretty print дерева). Но если в предыдущей статье я синтаксическое дерево строил вручную, то сегодня всё же будем автоматизировать процесс.

Сегодня я публикую две статьи разом, поскольку по дороге меня довольно круто занесло, и получился небольшой спин-офф. Очень рекомендую к прочтению :)

Ну а тема этой статьи - автоматическое построение синтаксического дерева aka лексер и парсер.

Задавались ли вы когда-нибудь вопросом, можно ли полноценно программировать при помощи директивы #define в языке C? Полнота по Тьюрингу шаблонов C++ известна весьма широко, например, люди пишут трассировщики лучей, делающие все вычисления во время компиляции (вместо времени исполнения). А как обстоят дела с препроцессором C? Вопрос оказался сильно нетривиальнее, и эта история является, на мой вкус, отличным анекдотом для курса лекций по теории компиляторов, что я готовлю в данный момент. В частности, для лучшего понимания происходящего здесь, рекомендую ознакомиться со второй статьёй, которую я опубликовал параллельно этой: лексер и парсер.

Чтобы не было обманутых впечатлений, предупрежу сразу, что рейтрейсера не будет, но про́клятый код будет очень даже! Итак, поехали. Для начала, почему я вообще задался этим вопросом? Если обычный код компьютерной графики вам скучен, следующий раздел можно пропустить, перематывайте до последней картинки.

Разбирался тут на досуге с (относительно) новыми МК фирмы WCH с ядром RISCV (CH32V307FBP6) с целью осветить данный прибор, скачал рекомендованную среду разработки (mounriver) и на первом же примере наткнулся на совершенно неожиданную вещь. Пример совершенно классический (нет, не мигание светодиодом и даже не приветствие миру) и посвящен использованию функции printf, вот он:

USART_Printf_Init(115200);
printf("SystemClk:%d\r\n"),SystemCoreClоck);
printf("This is printf example\r\n");

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

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

В back in 2007 трое гуру из Google — Роб Пайк, Кен Томпсон и Роберт Гриземер — решили, что мир нуждается в чем-то свежем и быстром. Они метили на упрощение процесса разработки, но при этом хотели сохранить весь перфоманс на уровне C. И вот, в 2009 году появился Golang.

Первые версии были далеки от совершенства, но с каждым релизом Go становился только круче. Garbage collector, goroutines, channels — эти фичи сделали Go особенным. С каждым апдейтом Go становился только быстрее и надежнее. И не забудем про экосистему — с каждым годом она росла как на дрожжах, предлагая всё новые инструменты и библиотеки.

С версии 1.5 компилятор Go сам начал компилироваться в Go. С тех пор производительность только растет. JIT, улучшения в escape analysis, введение модулей в версии 1.11 — каждая фича делала Go всё более мощным.

В последниях версиях появились дженерики, которые все так долго ждали. Это был следующий шаг в удобстве написания кода в go.

Вам когда-нибудь приходилось задаваться вопросом, как работает компилятор, но так руки и не дошли разобраться? Тогда этот текст для вас. Мне тоже не доводилось заглядывать под капот, но тут так случилось, что мне нужно прочитать курс лекций о компиляторах местным третьекурсникам. Кто встречался с некомпетентными преподавателями? Здравствуйте, это я :)

Итак, чтобы самому разобраться в теме, я собираюсь написать транслятор с эзотерического языка программирования wend (сокращение от week-end), который я только что сам придумал, в обычный ассемблер. Задача уложиться в несколько сотен строк питоновского кода. Основной репозиторий живёт на гитхабе (не забудьте заглянуть в мой профиль и посмотреть другие tiny* репозитории).

Хотя уменьшение сегодня уже необязательно, оно всё равно лучше.

Есть оптимизации, польза от которых очевидна всегда или почти всегда. Например, не делать лишнюю проверку лучше, чем делать. Не считать два раза одно и то же обычно лучше, чем считать (если только мы не упёрлись в нехватку регистров или имеем другие подобные проблемы на нижнем уровне). Вычислять выражения вне цикла выгоднее, чем в цикле. И так далее.

Но есть оптимизации, применение которых имеет как плюсы, так и минусы. Выиграв в одном месте, мы можем получить отрицательные эффекты в другом. Например, сэкономив на количестве проверок, мы можем раздуть общий объём кода и поломать микрооптимизации. Каноничным примером такой оптимизации, решение вопроса об использовании которой больше похоже на искусство, чем на науку, является размотка циклов (Loop Unrolling), о которой мы сегодня поговорим. В статье я попробую осветить как можно больше (хотя, наверное, и не все) соображения о том, почему эту оптимизацию может быть нужно или не нужно применять.

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

Отсутствие скрытой неэффективности

Templates in C++ have evolved from little more than token substitution into a programming language in itself. Many useful aspects of C++ templates have been discovered rather than designed.

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

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

rustup update stable

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

Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.

Просматривая недавно соцсети, я наткнулся на этот скриншот. Разумеется, его сопровождало множество злобных комментариев, критикующих попытку этого новичка в программировании решить классическую задачу computer science: операцию деления с остатком.

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

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

Привет, Хабр! Меня зовут Владислав Виноградов, я инженер группы исследований и разработки ПО глубокого обучения в YADRO. Моя команда создает и оптимизирует связанное с искусственным интеллектом программное обеспечение. Сегодня я расскажу, как можно разработать тензорный компилятор для процессора на базе открытой архитектуры RISC-V. 

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

В этой статье я поделюсь с вами долгой историей, которая начинается с op.read() opendal, а заканчивается неожиданным поворотом. Это путешествие оказалось для меня достаточно поучительным, надеюсь, и для вас оно будет таким же. Я постараюсь максимально точно воссоздать свой опыт и дополню его выводами, которые сделал в процессе.