Помните, как долго выполняется сложение на бумаге?

¹¹ ¹
6876
+ 3406
------
10282

Начиная с единиц, мы складываем 6 + 6 = 12, записываем 2 и переносим 1. Затем пошагово двигаемся влево, пока складываемые разряды не закончатся.

При реализации сложения больших чисел (например, от 2⁶⁴ и выше) обычно пишут код, похожий на этот алгоритм. Любопытно здесь то, что существует простой трюк, позволяющий существенно ускорить этот процесс на современных CPU.

Но сначала я задам вопрос: почему сложение столбиком мы начинаем с самого младшего разряда? Почему бы не начать слева?

Дело, разумеется, в переносе. Мы не можем точно знать, каким будет текущий разряд числа, пока не выполним все сложения справа от этого разряда.

Привет, Хабр! Меня зовут Юра, я работаю тимлидом проекта Waterbase в KION, а в свободное время люблю читать, что нового происходит в мире ИТ и какие подходы к программированию есть в других странах. Сегодня хочу поговорить о ЯП с синтаксисом не на английском — здесь нет команд вроде if, print и while, к которым мы все так привыкли. Авторы стремились либо упростить вход в ИТ для носителей своего языка, либо переосмыслить само представление о ЯП. Ниже — пять таких проектов: LSE, VisuAlg, Aheui, Qalb и Kalaam. Погнали!

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

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

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

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

Коротко обо мне. Меня зовут Макс, и так получилось, что я вот уже 10 лет, почти с самого начала своей карьеры, занимаюсь оптимизирующими компиляторами. Я начинал в Intel, потом перешёл в Azul Systems, год провёл в Cadence и вернулся обратно, всё это время занимаясь компиляторными оптимизациями для Java, C++ и нейросетевых моделей. На момент написания статьи у меня чуть за 900 патчей в LLVM, большинство из них посвящено цикловым оптимизациям.

За это время я провёл десятки собеседований на позиции как интернов, так и инженеров сеньорного уровня, и довольно часто люди, приходя на эти собеседования, многих вещей не знают или знают поверхностно. И я подумал: а мог бы я написать такой цикл статей, чтобы человек, прочитав их, узнал бы всю ту базу, которая, на мой собственный взгляд, необходимо начинающему компиляторному инженеру? Очень бы хотелось, чтобы новичку в этой области можно бы было дать один (относительно небольшой по объёму) набор текстов, чтобы он получил оттуда всё необходимое для старта. Это не перевод, текст оригинальный, поэтому в нём могут быть ошибки и неточности, которые я буду рад исправить, если вы мне их укажете.

Итак, поехали.

Почему я это написал, и как читать статью

Недавно получил от друга такое сообщение:

Знаешь, какая статья была бы реально интересна? Если бы в ней было показано, что именно происходит с твоим кодом в результате оптимизаций.

Я сразу же подумал: «Ну конечно, я знаю тысячу статей и видеороликов на эту тему», но вскоре осознал, что практически во всех таких источниках от читателя требуется знать компьютерный жаргон, внутреннее устройство, промежуточные представления, т.д. Вот какая проблема здесь возникает: те, кто пользуется компиляторами (как, например, мой друг), всем этим не заморачиваются. Их не волнует, каково именно промежуточное представление LLVM, или что такое φ-узел, или какой проход и почему называется «ротацией циклов». Нет, их интересуют (в порядке убывания приоритета) ответы на вопросы: (1) что, (2) почему, (3) как.

section .data
  msg db "Hello, World!"

section .text
  global _start

_start:
  mov rax, 1
  mov rdi, 1
  mov rsi, msg
  mov rdx, 13
  syscall

  mov rax, 60
  mov rdi, 0
  syscall

Если вы никогда не пробовали смотреть как код на C++ разворачивается компилятором в код Assembly – вас ждёт много сюрпризов, причём, не нужно смотреть какой-то замудренный исходный код полный templates или других сложных конструкций: рассмотрите следущий snippet:

Статический анализ — это очень мощный инструмент, позволяющий следить за качеством кода. Предлагаем вместе попробовать написать простой Lua анализатор на Java, чтобы понять, как устроены статические анализаторы кода внутри.

Нюансы оптронной развязки, борьба с её недостатками и интересный на мой взгляд костыль: как разогнать скорость копеечной опторазвязки и наполучать других бонусов. Я не силён в рекламе, поэтому на месте КДПВ будет сразу тема статьи.

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

Всего в курсе 11 практических роликов с подробными теоретическими материалами к каждому. Будем не просто смотреть на картинки с электрическими схемами, а проводить эксперименты своими руками. Начнем с истоков: познакомимся с оборудованием и линейными электронными компонентами, а закончим сборкой секундомера с применением микросхем цифровой логики. Все подробности — на странице курса и под катом.

Материал подготовлен на основе выступления с CppCon 2015 "Greg Law: Give me 15 minutes & I'll change your view of GDB" (доступно по ссылке ). Многие моменты я изменял и корректировал, поэтому учтите, что перевод достаточно вольный.

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

В статье будет рассматриваться отладка кода на C в ОС Linux.

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

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

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

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

Я люблю трассировщики лучей и даже посвятил им половину своей книги. Менее известна моя любовь к ZX Spectrum — домашнему компьютеру 1982 года, с которым я вырос и с которого начался мой интерес к графике и программированию. По современным стандартам эта машина столь смехотворно слаба (и даже по стандартам 1980-х), поэтому возникает неизбежный вопрос: в какой степени удастся портировать трассировщик лучей из книги Computer Graphics from Scratch на ZX Spectrum?

В ZX Spectrum установлен процессор Z80 на 3,5 МГц (в тысячу раз медленнее, чем современные компьютеры), который не может умножать числа (!!!), и 48 КБ ОЗУ (в миллион раз меньше); он имеет графический режим 256x176 (примерно в двести раз меньше современного разрешения), способный отображать 15 цветов (в миллион раз меньше, к тому же с довольно необычными особенностями). Интересная машина для графического приложения, активно задействующего CPU!

Я планирую реализовать его на Sinclair BASIC — встроенном языке программирования Spectrum. Это не просто BASIC, а древний, очень ограниченный диалект BASIC. Например, единственные структуры управления в нём — это FOR и IF (а у IF нет ELSE и даже ENDIF); все переменные глобальны; не существует вызовов функций, только GO TO и GO SUB; и так далее. Кроме того, он интерпретируемый, то есть сверхмедленный. Но, по крайней мере, он реализует программное умножение! Если мне нужна будет производительность, то я всегда могу переписать трассировщик на ассемблере.

Я настроил минимально необходимую среду: код на BASIC я пишу в VS Code, компилирую его с помощью BAS2TAP и запускаю в эмуляторе FUSE. Благодаря этому скорость итераций оказалась достаточно высокой.

На уходящей неделе мне попалась симпатичная, хоть и не новая мини‑серия статей на Дзен‑канале @zdgzdgzdg про процедурную генерацию лабиринта методом «коллапса волновой функции». Пока я читал эти статьи и знакомился с кодом, меня осенило: ведь это же вычисления в комонаде, погружённые в монаду! Я не издеваюсь, действительно, речь идёт о композиции двух паттернов функционального программирования: комонады Zipper, превращающей локальные правила в глобальное состояние, и монады Random, позволяющей генерировать случайные объекты.

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