Компиляторы

Создать компилятор JS с высокой производительностью означает сделать больше, чем разработать сильно оптимизированный компилятор, например TurboFan, особенно это касается коротких сессий, к примеру, загрузки сайта или инструментов командной строки, когда большая часть работы выполняется до того, как оптимизирующий компилятор получит хотя бы шанс на оптимизацию, не говоря уже о том, чтобы располагать временем на оптимизацию. Как решить эту проблему? К старту курса о Frontend-разработке делимся переводом статьи о Sparkplug свече зажигания под капотом Chrome 91.

Вот почему с 2016 года мы ушли от синтетических бенчмарков, таких как Octane, к измерению реальной производительности и почему старательно работали над производительностью JS вне оптимизирующих компиляторов. Для нас это означало работу над парсером, стримингом [этой поясняющей ссылки в оригинале нет], объектной моделью, конкурентностью, кешированием скомпилированного кода...

Впрочем, повернувшись лицом к улучшению производительности фактического, начального выполнения JS, мы столкнулись с ограничениями процесса оптимизации интерпретатора. Интерпретатор V8 сам по себе быстрый и сильно оптимизированный, но интерпретаторам как таковым свойственны накладные расходы, избавиться от которых мы не можем: например на декодирование байт-кода или диспетчеризацию неотъемлемые части функциональности интерпретатора.

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

Выход из положения Sparkplug: новый неоптимизирующий компилятор JavaScript, который мы выпустили вместе с V8 9.1, он работает между интерпретатором Ignition и компилятором TurboFan.

Быстрый компилятор

Sparkplug создан компилировать быстро. Очень быстро. Настолько, что мы всегда можем компилировать, когда захотим, повышая уровень кода SparkPlug намного агрессивнее кода TurboFan, [подробнее здесь, этой ссылки в оригинале нет].

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

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

// The Sparkplug compiler (abridged).for (; !iterator.done(); iterator.Advance()) {  VisitSingleBytecode();}

Недочёт промежуточного представления (IR) заключается в том, что компилятор ограничен возможностями оптимизации. Поскольку промежуточной архитектурно независимой стадии нет, этот факт также означает, что всю реализацию нужно переносить на каждую поддерживаемую архитектуру отдельно. Но, оказывается, ни то, ни другое не является проблемой: портировать код довольно легко, вместе с тем Sparkplug не нужно выполнять тяжёлую оптимизацию.

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

Совместимые с интерпретатором фреймы

Добавление нового компилятора в зрелую виртуальную машину JS пугающая задача. Кроме стандартного выполнения в V8 мы должны поддерживать отладчик, профилирование центрального процессора с обходом стека, а значит, трассировки стека для исключений, интеграцию в стратегию динамического повышения уровня функции, замену на стеке, чтобы оптимизировать код горячих циклов. Работы много.

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

Сейчас около половины читателей закричит: "Диаграмма не имеет смысла, стек направлен в другую сторону!" Ничего страшного, я сделал кнопку: думаю, стек направлен вниз.

Когда функция вызвана, адрес возврата кладётся на стек и удаляется со стека функцией, когда она возвращается, чтобы знать, куда вернуться. Затем, когда функция создаёт новый фрейм, она сохраняет указатель на старый фрейм на стеке и устанавливает новый указатель в начало собственного стекового фрейма. Таким образом, на стеке образуется цепочка указателей на фреймы, каждый из которых отмечает начало фрейма, указывающего на предыдущий:

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

Это основной макет стека для всех типов функций; затем идёт соглашение о передаче аргументов и о том, как в своём фрейме функция хранит значения. В V8 мы имеем соглашение для фреймов JS, что аргументы до вызова функции (включая приёмник) добавляются на стек в обратном порядке, а также о том, что первые несколько слотов стека это вызываемая функция, контекст, с которым она вызывается, и количество передаваемых аргументов. Вот наш стандартный фрейм JS.

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

В случае Ignition соглашение становится более явным. Ignition интерпретатор на основе регистров, это означает, что есть виртуальные регистры (не путайте их с машинными!), которые хранят текущее состояние интерпретатора. включая локальные переменные (объявления var, let, const) и временные значения. Эти регистры содержатся в стековом фрейме интерпретатора, вместе с указателем на выполняемый массив байт-кода и смещением текущего байт-кода в массиве.

Sparkplug намеренно создаёт и поддерживает соответствующий фрейму интерпретатора макет фрейма. Всякий раз, когда интерпретатор сохраняет значение регистра, SparkPlug также сохраняет его. Делает он это по нескольким причинам:

1. Это упрощает компиляцию Sparkplug; новый компилятор может просто отражать поведение интерпретатора без необходимости сохранять какое-либо отображение из регистров интерпретатора в состояние Sparkplug.

2. Поскольку компилятор байт-кода выполнил тяжёлую работу по распределению регистров, такой подход ускоряет компиляцию.

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

4. Тривиальной становится и замена на стеке (OSR). Замена на стеке это когда выполняемая функция заменяется в процессе выполнения; сейчас это происходит, когда интерпретированная функция находится в горячем цикле (в это время она поднимается до оптимизированного кода этого цикла) и где оптимизированный код деоптимизируется (когда он опускается и продолжает выполнение функции в интерпретаторе), любая работающая в интерпретаторе логика замены на стеке будет работать и для Sparkplug. Даже лучше: мы можем взаимозаменять код интерпретатора и SparkPlug почти без накладных расходов на переход фреймов.

Мы немного изменили стековый фрейм интерпретатора: во время выполнения кода Sparkplug не поддерживается актуальная позиция смещения. Вместо этого мы храним двустороннее отображение из диапазона адресов кода Sparkplug к соответствующему смещению. Для декодирования такое сопоставление относительно просто, поскольку код Sparklpug получается линейным проходом через байт-код. Всякий раз, когда стековый фрейм хочет узнать "смещение байт-кода" для фрейма Sparkplug, мы смотрим на текущую выполняемую инструкцию в отображении и возвращаем связанное смещение байт-кода. Аналогично, когда Sparkplug нужно узнать OSR из интерпретатора, мы смотрим на байт-код в смещении и перемещаемся к соответствующей инструкции Sparkplug.

Вы можете заметить, что теперь у нас есть неиспользуемый слот фрейма, где должно быть смещение байт-кода; избавиться от него мы не можем, поскольку хотим сохранить оставшуюся часть стека неизменной. Мы перепрофилируем этот слот стека, чтобы вместо него кешировать "вектор обратной связи" для текущей выполняющейся функции; это вектор, хранящий данные о форме объекта, и он должен быть загружен для большинства операций. Всё, что нам нужно делать, соблюдать осторожность с OSR, чтобы гарантировать, что мы подставляем либо правильное смещение байт-кода, либо правильный вектор обратной связи для этого слота. В итоге стековый фрейм Sparkplug выглядит так:

Полагаемся на встроенный код

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

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

2. Этот подход увеличил бы потребление памяти кодом Sparkplug.

3. Пришлось бы переписывать кодогенерацию для большого количества функциональности JS, что, вероятно, означало бы и больше ошибок, и большую поверхность атаки.

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

Вы можете подумать: "Ну и какой тогда смысл во всём этом? Разве Sparkplug не выполняет ту же работу, что и интерпретатор?" и во многом будете правы. Во многих отношениях Sparkplug является "просто" сериализацией выполнения интерпретатора, вызывая те же встроенные двоичные сниппеты и поддерживая тот же стековый фрейм. Тем не менее оно того стоит, потому что Sparkplug удаляет (или, точнее, предварительно компилирует) те самые неустранимые накладные расходы интерпретатора, такие как декодирование операндов и диспетчеризация следующего байт-кода.

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

Производительность

Так как же Sparkplug работает на практике? Мы выполнили несколько бенчмарков Chrome на наших ботах для замера производительности со Sparkplug и без него. Спойлер: мы очень довольны.

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

Speedometer

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

Обзор бенчмарка

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

На этих тестах мы решили посмотреть метрику V8 Main-Thread Thread, измеряющую общее проведённое в V8 время (включая компиляцию и выполнение), в основном потоке (то есть исключая стриминговый парсинг или фоновую оптимизацию). Это лучший способ увидеть, насколько оправдан Sparkplug, без учёта других источников шума бенчмарка.

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

Таким образом, V8 имеет новый сверхбыстрый неоптимизирующий компилятор, повышающий производительность V8 в реальных бенчмарках на 515 %. Он уже доступен в V8 v9.1 (укажите опцию --sparkplug), и мы выпустим его вместе с Chrome 91.

Вот что важно заметить: выделившись в отдельную область разработки, фронтенд не ограничивается одним только JavaScript, например есть множество тонкостей в том, каким образом браузер работает с CSS. Вместе с тем оптимизации на уровне браузера не означают, что можно больше не писать аккуратный, компактный и элегантный код. Скорее они означают, что теперь разработчики будут свободнее чувствовать себя, когда захотят написать сложную или тяжёлую функциональность. Если фронтенд вам интересен, вы можете обратить внимание на наш курс Frontend-разработчик, где получите комплексную подготовку, чтобы в дальнейшем писать и поддерживать приложения различного масштаба и уровня сложности.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Вот пример для проверки:

#include <iostream>int main(){    std::cout << "-3/3u*3 = " << int(-3/3u*3) << "\n";}

Посмотреть результат можно тут.

Или попробуйте поиграться с этим примером здесь или здесь.

Вообще-то мне не удалось найти хоть какой-то компилятор С++, который бы выдавал результат отличный от -4. Даже старый GCC-4.1.2, clang-3.0.0 или Borland C 1992 года. Так же заметил, что результат одинаковый и для константы, вычисляемой в момент компиляции и для времени выполнения.

Предлагаю внимательно рассмотреть результат выражения -3/3u*3.

Если убрать приведение к типу intв примере выше, то получим 4294967292 или 0xFFFFFFFС(-4). Получается, что компилятор на самом деле считает результат беззнаковым и равным 4294967292. До этого момента я был свято уверен, что если в выражении используется знаковый тип, то и результат будет знаковым. Логично же это.

Если посмотреть откуда берется -4 вместо -3, посмотрим внимательней на ассемблерный код примера, например здесь.

Пример изменю, чтобы результат вычислялся не в момент компиляции, а в момент выполнения:

int main(){    volatile unsigned B = 3;    int A = -3/B*3;}

Для x86-64 clang 12.0.0 видим, что используется беззнаковое деление, хотя числитель откровенно отрицательное -3:

        mov     dword ptr [rbp - 4], 3    // B = 3        mov     ecx, dword ptr [rbp - 4]        mov     eax, 4294967293        xor     edx, edx        div     ecx                       // беззнаковое деление !!        imul    eax, eax, 3               // знаковое умножение        mov     dword ptr [rbp - 8], eax

Для x64 msvc v19.28 тот же подход к делению:

        mov     DWORD PTR B$[rsp], 3      // B = 3        mov     eax, DWORD PTR B$[rsp]        mov     DWORD PTR tv64[rsp], eax        xor     edx, edx        mov     eax, -3                             ; fffffffdH        mov     ecx, DWORD PTR tv64[rsp]        div     ecx        imul    eax, eax, 3        mov     DWORD PTR A$[rsp], eax

Получается, что для деления беззнакового числа на знаковое используется БЕЗЗНАКОВАЯ операция деления процессора div. Кстати, следующая команда процессора, это правильное знаковое умножение imul. Ну явный баг компилятора. Банальная логика же подсказывает, что знаковый тип выиграет в приведении типа результата выражения если оба знаковый и беззнаковый типы используются в выражении. И для знакового деления требуется знаковая команда деления процессора idiv, чтоб получить правильный результат со знаком.

Проблема еще и в том, что число 4294967293 не делится на 3 без остатка:4294967293 = 1431655764 * 3 + 1и при умножении 1431655764 обратно на 3, получаем 4294967292 или -4. Так что прикинуться веником и считать, что 4294967293 это то же -3, только вид сбоку, для операции деления не прокатит.

Я когда обнаружил, что используется без-знаковое деление, решил, что это бага компилятора. Протестировал много компиляторов: msvc, gcc, clang. Все показали такой же результат, даже древние трудяги. Но мне довольно быстро подсказали, что это поведение описано и закреплено в самом стандарте.

Действительно, стандарт говорит об этом прямо:

Otherwise, if the unsigned operand's conversion rank is greater or equal to the conversion rank of" "the signed operand, the signed operand is converted to the unsigned operand's type.

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

Вот где оказывается собака зарыта: "the signed operand is converted to the unsigned operand's type"!! Ну почему, почему, Карл!! Логичнее наоборот: "the unsigned operand is converted to the signed operand's type", разумеется при соблюдении ранга преобразования. Ну вот как -3 представить без-знаковым числом?? Наоборот кстати можно.

Интересная получается сегрегация по знаковому признаку!

Заметил, что это правило почему-то работает только для операции деления, а операция умножения вычисляется правильно.

Проверим на ассемблере здесь этот пример:

int main(){    volatile unsigned B = 3;    int C = -3*B;}

Стандарт ничего не говорит о неприменимости этого правила для операции умножения. И деление и умножение должны быть БЕЗЗНАКОВМИ.

Я подумал, что что-то в стандарте сломалось и надо срочно это исправить. Написал письмо напрямую в поддержку Стандарта со всеми моими выкладками и предложением поправить это странное правило стандарта пока еще не поздно.

Ага! Наивный!

Мне ответил любезный молодой сотрудник из Стандарта и подтвердил, что мои выкладки правильны, логика на моей стороне, но поведение компиляторов полностью согласуется со Стандартом и само правило менять не будут, так как оно такое древнее, что непонятно кто и когда его ввел (сотрудник сказал, что искал автора, но не нашел) и поэтому его, как святую корову, трогать никто не будет, хотя вроде логично было бы исправить. Ну и милостиво разрешил поведать эту историю миру. О чем и пишу.

Хоть это исследование и было больше года назад, я до сих пор под впечатлением от многих вещей в этой истории:

• Как я не натыкался на это раньше? Не один десяток лет интенсивно кодирую на С и С++ с погружением в ассемблер, но только сейчас споткнулся на неё. Хотя может и натыкался ранее, но не мог поверить что причина именно в этом.

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

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

int main(){    const unsigned a[] = {3,4,5,6,7};    unsigned p = (&a[0] - &a[3])/3u*3;    // -3    unsigned b = -3/3u*3;   // -4}

Хоть я и понимаю, что могу ошибаться в логике работы этого мира, но задумайтесь, в следующий раз садясь в современный, нашпигованный вычислительной логикой самолёт (или автомобиль), а не сработает ли вдруг не оттестированный кусок кода в какой-то редкой нештатной ситуации, и не выдаст ли он -4 вместо элементарных -3, и не постигнет ли его участь подобная Boeing 737 MAX?

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

Предвижу возражение, что есть рекомендация использовать преимущественно без-знаковый тип. Понимаю, с таким правилом Стандарта по другому никак. Но как -4 в беззнаковое перевести, и чтоб всё остальное работало? И почему на других языках и всех процессорах не надо этими танцами с бубном заниматься, а в С++ надо? И что делать с константными выражениями, вычисляемыми компилятором? Вместо элегантных выражений, в которых мы уверены, надо записывать их с оглядкой, чтоб у компилятора небыло изжоги!

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

Как хорошую подсказку познавательно добавить предупреждение в компилятор когда он применяет это правило из Стандарта:"Signed value is intentionally converted to unsigned value. Sorry for crashing one more airplane. Have a nice flight!" Вот удивимся тогда, как мало мы тестируем и как много нам открытий чудных приносит компилятор друг.

Можно еще исправить Стандарт, ограничив правило только операциями сложения и вычитания. Как компромис. Но это крайне маловероятно в этой Вселенной. Да и Боингов еще много летает.

Корректность кода на платформе Android является наиважнейшим аспектом в контексте безопасности, стабильности и качества каждого релиза Android. По-прежнему сложнее всего вытравливаются ошибки, связанные с безопасностью памяти и попадающиеся в коде на С и C++. Google вкладывает огромные усилия и ресурсы в обнаружение, устранение багов такого рода, а также в уменьшение вреда от них, старается, чтобы багов в релизы Android проникало как можно меньше. Тем не менее, несмотря на все эти меры, ошибки, связанные с безопасностью памяти, остаются основным источником проблем со стабильностью. На их долю неизменно приходится ~70% наиболее серьезных уязвимостей Android.

Наряду с текущимиипланируемымимероприятиями по улучшению выявления багов, связанных с памятью, Google также наращивает усилия по их предотвращению. Языки, обеспечивающие безопасность памяти наиболее эффективные и выгодные средства для решения этой задачи. Теперь в рамках проекта Android Open Source Project (AOSP) наряду с языками Java и Kotlin, отличающимися безопасностью памяти, поддерживается и язык Rust, предназначенный для разработки операционной системы как таковой.

Системное программирование

Управляемые языки, в частности, Java и Kotlin, лучше всего подходят для разработки приложений под Android. Эти языки проектировались в расчете на удобство использования, портируемость и безопасность. Среда исполнения Android (ART)управляет памятью так, как указал разработчик. В операционной системе Android широко используется Java, что фактически защищает большие участки платформы Android от багов, связанных с памятью. К сожалению, на низких уровнях ОС Android Java и Kotlin бессильны.

На низких уровнях ОС нужны языки для системного программирования, такие как C, C++ и Rust. При проектировании этих языков приоритет отдавался контролируемости и предсказуемости. Они обеспечивают доступ к низкоуровневым ресурсам системы и железу. Они обходятся минимальными ресурсами, прогнозировать их производительность также сравнительно просто.

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

Rust предоставляет гарантии по поводу безопасности памяти, так как использует сочетание проверок во время компиляции, чтобы обеспечить соблюдение времени жизни объектов и владение ими, а также проверки во время исполнения и таким образом гарантировать валидность обращений к памяти. Такая безопасность действительно обеспечивается, а производительность остается не меньшей, чем при работе с C и C++.

Пределы работы в песочнице

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

В Android это означает, что, если код написан на C/C++ и разбирает потенциально небезопасный ввод, то он должен содержаться в жестко ограниченной песочнице без привилегий. Тогда как следование правилу двух хорошо помогает снижать тяжесть и повышать доступность уязвимостей, связанных с безопасностью, оно сопряжено с некоторыми ограничениями. Работа в песочнице дорогое удовольствие; для ее обеспечения требуются новые процессы, которыесопряжены с дополнительными накладными расходами и провоцируют задержки, связанные с межпроцессной коммуникацией и дополнительным расходом памяти. Работа в песочнице не позволяет полностью исключить уязвимости в коде, а эффективность такой работы снижается при высокой плотности багов, позволяющей злоумышленникам сцеплять вместе множество уязвимостей сразу.

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

1. Снижает плотность багов в нашем коде, тем самым повышая эффективность применяемой песочницы.

2. Снижает потребность в использовании песочницы, поскольку предоставляет новые возможности, которые более безопасны в работе и одновременно менее требовательны к ресурсам.

Что же насчет всего имеющегося C++?

Разумеется, если мы введем новый язык программирования, это никак не поможет нам с исправлением уже имеющихся багов в имеющемся коде на C/C++.

Вышеприведенный анализ возраста багов, связанных с безопасностью памяти (отсчитывается с момента их появления) позволяет судить, почему команда Android делает акцент на новых разработках, а не на переписывании зрелого кода на C/C++. Большинство багов возникает в новом или недавно измененном коде, причем, возраст около 50% багов составляет менее года.

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

Ограничения находимости багов

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

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

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

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

Предотвращение прежде всего

В Rust модернизируется ряд языковых аспектов, что позволяет улучшить корректность кода:

• Безопасность памяти обеспечивается благодаря сочетанию проверок во время компиляции и во время выполнения.

• Конкурентность данных предотвращает гонку данных. Учитывая, насколько легко при этом становится писать эффективный потокобезопасный код, Rust обрел слоганБезбоязненная Конкурентность.

• Более выразительная система типов помогает предотвратить логические ошибки при программировании (напр., обертки нового типа, варианты перечислений с содержимым).

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

• Улучшенная обработка ошибок в стандартных библиотеках потенциально провальные вызовы обертываются в Result, и поэтому компилятор требует от пользователя проверять возможность провала даже для функций, не возвращающих необходимого значения. Это позволяет защититься от таких багов как уязвимостьRage Against the Cage, возникающая из-за необработанной ошибки. Обеспечивая легкое просачивание ошибок при помощи оператора ? и оптимизируя Result с расчетом на низкие издержки, Rust стимулирует пользователей писать все потенциально провальные функции в одном и том же стиле, благодаря чему все они получают ту же защиту.

• Инициализация требует, чтобы все переменные инициализировались перед началом использования. Исторически сложилось, что неинициализированные уязвимости памяти были в Android причиной 3-5% уязвимостей, связанных с безопасностью. В Android 11, чтобы сгладить эту проблему, стала применятьсяавтоматическая инициализация памяти на C/C++. Однако, инициализация в ноль не всегда безопасна, особенно для таких штук, как возвращаемые значения, и в этой области может стать новым источником неправильной обработки ошибок. Rust требует, чтобы любая переменная перед использованием инициализировалась в полноценный член своего типа. Тем самым избегается проблема непреднамеренной инициализации небезопасного значения. Подобно Clang в C/C++, компилятор Rust знает о требовании инициализации и позволяет избежать потенциальных проблем производительности, связанных с двойной инициализацией.

• Более безопасная обработка целых чисел Очистка во избежание включена в отладочных сборках Rust по умолчанию, что стимулирует программистов указывать wrapping_add, если действительно предполагается допустить переполнение при расчетах, или saturating_add если не предполагается. Очистка при переполнении в дальнейшем должна быть включена для всех сборок Android. Кроме того, при всех преобразованиях целочисленных типов применяются явные приведения: разработчик не может сделать случайного приведения в процессе вызова функции при присваивании значения переменной или при попытке выполнять арифметические операции с другими типами.

Что дальше

Введение нового языка на платформу Android серьезное предприятие. Существуют такие связки инструментов и зависимости, которые необходимо поддерживать, тестовая инфраструктура и оснащение, которые потребуется обновить. Также придется дополнительно обучить разработчиков. Это проект не на один год. Следите за обновлениями в блоге Google.

При разработке клиент-серверного приложения, у меня всегда появляется вопрос, а как я его буду разворачивать на сервере, упаковать его в jar/war/docker после написания кода, а потом еще надо передать на сервер, и еще много сделать телодвижений чтоб просто засунуть кусок кода на сервере.

Было бы хорошо просто передать на сервер код, как лямбду, так же как мы передаем лямбду в функцию, так же на сервер ее передать.

Но у меня появилась мысль как сделать этот процесс проще, и у меня что-то получилось.

1 | var query = TcpQuery2 |    .create(IEnv.class).host("myserver.com").port(9988)3 |      .build();4 |5 |  query.apply( 6 |      env -> env.processes().stream().filter(7 |          p -> p.getName().contains("java")8 |      )9 |      .collect(Collectors.toList())10|  ).forEach(System.out::println);

Вот код на java,

• Строки с 1 по 5 включительно и 10 - работают на клиенте

• А строки с 6 по 9 (тело лямбды env->...) работают на сервере

И это не псевдокод, это реальный рабочий код на Java (11).

Действительно код строк с 6 по 9 (само тело лямбды) передаются на сервер и исполняются на сервере, при том сервер о этом куске кода ничего не знает, он принимает этот код исполняет у себя, и отдает обратно клиенту - а я дальше продолжаю писать код без всякого deploy, не выходя из IDE (Idea/Eclipse/etc...).

Статья будет о том, что такое Serializable Lambda в Java, и как передавать байт-код таких лямбд на сервер, без перезапуска сервера, т.е. как можно в теории отказаться от привычных схем deploy приложений и писать более удобный api (это моя фантазия).

Допустим у нас есть такой интерфейс IEnv:

public interface IEnv {List<OsProc> processes();}

Который возвращает список процессов

public class OsProc implements Serializable {public Optional<Integer> getPpid(){ return ... }public int getPid(){ return ... }public void setPid(int pid){ ... }public String getName(){ return ... }public Optional<String> getCmdline(){ return ... }}

И вот таких простым способом я передаю лямбду на сервер

var query = TcpQuery   .create(IEnv.class).host("myserver.com").port(9988) .build();  query.apply( env -> env.processes().stream().filter(     p -> p.getName().contains("java") ) .collect(Collectors.toList()) ).forEach(System.out::println);

Введение - как это работает ?

При разработке клиентского приложения на Java

1. Мы создаем набор исходных файлов, допустим Client.java

2. Компилятор генерирует байт-код - файл Client.class

3. При вызове query.apply() - мы передаем ссылку на лямбду env -> env.proc...toList())

4. Реализация query.apply():

   1. Принимает ссылку на лямбду

   2. Для лямбды обнаруживает имя класса (например Client) и метода (например lambda1) реализующего лямбду

   3. Отыскивает среди ресурсов программы соответствующий байт-код класса (Client.class) и его метода

   4. Загружает байт-код реализации лямбды и отправляет его на сервер

      1. Сервер принимает байт-код лямбды

      2. Генерирует в памяти класс в который вставляет принятый байт-код

      3. Загружает этот класс в память и через рефлексию получает доступ к лямбде

      4. Возвращает идентификатор этого метода обратно

   5. Принимает идентификатор метода и делает вызов его на сервере

      1. Сервер выполняет ранее скомпилированный класс/метод/лямбду

      2. Возвращает результат выполнения

   6. Принимает результат серверного вызова и возвращает его как результат локального вызова

5. Возврат результата вызова query.apply()

Далее в статье будет рассмотрено я на примере очень простой библиотеки покажу, как запустить свои наработки в режиме клиент-сервера, и писать клиентов без выхода из IDE и перезапуска серверов.

Как воспользоваться?

Что бы с этим по играть, воспользуйтесь моим pet project-ом:

v 1.0 https://github.com/gochaorg/trambda/releases/tag/1.0

maven

<dependency>  <groupId>xyz.cofe</groupId>  <artifactId>trambda</artifactId>  <version>1.0</version>  <type>pom</type></dependency><dependency>  <groupId>xyz.cofe</groupId>  <artifactId>trambda-core</artifactId>  <version>1.0</version></dependency><dependency>  <groupId>xyz.cofe</groupId>  <artifactId>trambda-tcp</artifactId>  <version>1.0</version></dependency>

Чтобы воспользоваться, у вас должна быть какая нибудь библиотека к которой вы хотите обращаться по сети (TCP)

В моем примере это будет очень простая библиотека, в ней всего три файла:

• OsProc.java - описывает процесс ОС (описание было выше)

• IEnv.java - Интерфейс получения списка процессов для ОС (описание было выше)

• LinuxEnv.java - Получение списка процессов для ОС Linux - реализация IEnv

Библиотека из примера работает так:

package xyz.cofe.trambda.demo.api;import org.junit.jupiter.api.Test;public class LinuxEnvTest {   @Test   public void test(){       var env = new LinuxEnv();       env.processes().stream()           .filter(p->p.getName().equalsIgnoreCase("java"))           .forEach(System.out::println);   }}

LinuxEnv - это простой класс, он устроен так:

package xyz.cofe.trambda.demo.api;import java.util.ArrayList;import java.util.List;import xyz.cofe.io.fs.File;public class LinuxEnv implements IEnv {   @Override   public List<OsProc> processes(){       ArrayList<OsProc> procs = new ArrayList<>();       File procDir = new File("/proc");       procDir.dirList().stream()           .filter( d -> d.getName().matches("\\d+") && d.isDir() )           .map(OsProc::linuxProc)           .forEach(procs::add);       return procs;   }}

Код его тривиален, он сканирует каталог /proc и находит описание процесса ОС, (для Linux все процессы сервера отображаются в виде файлов/подкаталогов /proc)

Скомпилируем библиотеку (или возьмем свою)

Клонируем репозиторий (git commit 67ec260)

> git clone https://github.com/gochaorg/trambda.gitКлонирование в trambda...remote: Enumerating objects: 978, done.remote: Counting objects: 100% (978/978), done.remote: Compressing objects: 100% (464/464), done.remote: Total 978 (delta 308), reused 862 (delta 195), pack-reused 0Получение объектов: 100% (978/978), 715.70 KiB | 559.00 KiB/s, готово.Определение изменений: 100% (308/308), готово.

Собираем библиотеку для демонстрации

user@user-Modern-14-A10RB:22:10:35:~/Загрузки/sample-tr:> cd trambda/trambda-demo/tr-demo-api/user@user-Modern-14-A10RB:22:10:49:~/Загрузки/sample-tr/trambda/trambda-demo/tr-demo-api:> mvn clean package install...[INFO] ------------------------------------------------------------------------[INFO] BUILD SUCCESS[INFO] ------------------------------------------------------------------------[INFO] Total time:  13.933 s[INFO] Finished at: 2021-04-18T22:11:11+05:00[INFO] ------------------------------------------------------------------------

В каталоге target должен оказаться файл jar с нашей библиотекой

user@user-Modern-14-A10RB:22:13:13:~/Загрузки/sample-tr/trambda/trambda-demo/tr-demo-api:> ll target/итого 48drwxrwxr-x 10 user user 4096 апр 18 22:11 ./drwxrwxr-x  4 user user 4096 апр 18 22:11 ../drwxrwxr-x  3 user user 4096 апр 18 22:11 classes/drwxrwxr-x  3 user user 4096 апр 18 22:11 generated-sources/drwxrwxr-x  3 user user 4096 апр 18 22:11 generated-test-sources/drwxrwxr-x  2 user user 4096 апр 18 22:11 maven-archiver/drwxrwxr-x  3 user user 4096 апр 18 22:11 maven-status/drwxrwxr-x  4 user user 4096 апр 18 22:11 site/drwxrwxr-x  2 user user 4096 апр 18 22:11 surefire-reports/drwxrwxr-x  3 user user 4096 апр 18 22:11 test-classes/-rw-rw-r--  1 user user 6337 апр 18 22:11 tr-demo-api-1.0-SNAPSHOT.jar

Запуск сервера

Теперь когда библиотека собрана копируем сервер с github и распаковываем архив

user@user-Modern-14-A10RB:22:37:25:~/Загрузки/sample-tr:> wget https://github.com/gochaorg/trambda/releases/download/1.0/trambda-tcp-serv-cli.zip--2021-04-18 22:37:31--  https://github.com/gochaorg/trambda/releases/download/1.0/trambda-tcp-serv-cli.zipРаспознаётся github.com (github.com)... 140.82.121.4Подключение к github.com (github.com)|140.82.121.4|:443... соединение установлено.HTTP-запрос отправлен. Ожидание ответа... 302 FoundАдрес: https://github-releases.githubusercontent.com/350075998/47380d00-9b40-11eb-90a4-4e353f42e67c?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210418%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210418T173731Z&X-Amz-Expires=300&X-Amz-Signature=97ade1f58bfbe1eaa320805179987e8c4df730b9f5eddf24c05662fb676caafe&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=350075998&response-content-disposition=attachment%3B%20filename%3Dtrambda-tcp-serv-cli.zip&response-content-type=application%2Foctet-stream [переход]--2021-04-18 22:37:31--  https://github-releases.githubusercontent.com/350075998/47380d00-9b40-11eb-90a4-4e353f42e67c?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210418%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210418T173731Z&X-Amz-Expires=300&X-Amz-Signature=97ade1f58bfbe1eaa320805179987e8c4df730b9f5eddf24c05662fb676caafe&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=350075998&response-content-disposition=attachment%3B%20filename%3Dtrambda-tcp-serv-cli.zip&response-content-type=application%2Foctet-streamРаспознаётся github-releases.githubusercontent.com (github-releases.githubusercontent.com)... 185.199.111.154, 185.199.108.154, 185.199.109.154, ...Подключение к github-releases.githubusercontent.com (github-releases.githubusercontent.com)|185.199.111.154|:443... соединение установлено.HTTP-запрос отправлен. Ожидание ответа... 200 OKДлина: 12107487 (12M) [application/octet-stream]Сохранение в: trambda-tcp-serv-cli.ziptrambda-tcp-serv-cli.zip                                    100%[========================================================================================================================================>]  11,55M  3,75MB/s    за 3,1s    2021-04-18 22:37:35 (3,75 MB/s) - trambda-tcp-serv-cli.zip сохранён [12107487/12107487]user@user-Modern-14-A10RB:22:37:35:~/Загрузки/sample-tr:> llитого 11836drwxrwxr-x  3 user user     4096 апр 18 22:37 ./drwxr-xr-x 11 user user     4096 апр 18 22:00 ../drwxrwxr-x 10 user user     4096 апр 18 22:10 trambda/-rw-rw-r--  1 user user 12107487 апр 12 03:36 trambda-tcp-serv-cli.zipuser@user-Modern-14-A10RB:22:37:42:~/Загрузки/sample-tr:> unzip trambda-tcp-serv-cli.zip Archive:  trambda-tcp-serv-cli.zip   creating: trambda-tcp-serv-cli/   creating: trambda-tcp-serv-cli/jars/  inflating: trambda-tcp-serv-cli/jars/asm-9.1.jar    inflating: trambda-tcp-serv-cli/jars/jline-2.14.6.jar    inflating: trambda-tcp-serv-cli/jars/iofun-1.0.jar    inflating: trambda-tcp-serv-cli/jars/groovy-swing-3.0.7.jar    inflating: trambda-tcp-serv-cli/jars/groovy-console-3.0.7.jar    inflating: trambda-tcp-serv-cli/jars/groovy-xml-3.0.7.jar    inflating: trambda-tcp-serv-cli/jars/trambda-tcp-serv-cli-1.0.jar    inflating: trambda-tcp-serv-cli/jars/ecolls-1.10.jar    inflating: trambda-tcp-serv-cli/jars/trambda-core-1.0.jar    inflating: trambda-tcp-serv-cli/jars/slf4j-api-1.7.25.jar    inflating: trambda-tcp-serv-cli/jars/asm-tree-9.1.jar    inflating: trambda-tcp-serv-cli/jars/asm-util-9.1.jar    inflating: trambda-tcp-serv-cli/jars/fs-1.2.jar    inflating: trambda-tcp-serv-cli/jars/logback-classic-1.2.3.jar    inflating: trambda-tcp-serv-cli/jars/trambda-tcp-1.0.jar    inflating: trambda-tcp-serv-cli/jars/groovy-groovysh-3.0.7.jar    inflating: trambda-tcp-serv-cli/jars/groovy-templates-3.0.7.jar    inflating: trambda-tcp-serv-cli/jars/asm-analysis-9.1.jar    inflating: trambda-tcp-serv-cli/jars/text-1.0.jar    inflating: trambda-tcp-serv-cli/jars/logback-core-1.2.3.jar    inflating: trambda-tcp-serv-cli/jars/groovy-3.0.7.jar    inflating: trambda-tcp-serv-cli/jars/cbuffer-1.3.jar     creating: trambda-tcp-serv-cli/bin/  inflating: trambda-tcp-serv-cli/bin/trambda-tcp-serv.bat    inflating: trambda-tcp-serv-cli/bin/trambda-tcp-serv  user@user-Modern-14-A10RB:22:37:50:~/Загрузки/sample-tr:> rm trambda-tcp-serv-cli.zip 

После копируем нашу библиотеку в каталог trambda-tcp-serv-cli/jars

ser@user-Modern-14-A10RB:22:40:47:~/Загрузки/sample-tr:> cp -v trambda/trambda-demo/tr-demo-api/target/tr-demo-api-1.0-SNAPSHOT.jar trambda-tcp-serv-cli/jars/'trambda/trambda-demo/tr-demo-api/target/tr-demo-api-1.0-SNAPSHOT.jar' -> 'trambda-tcp-serv-cli/jars/tr-demo-api-1.0-SNAPSHOT.jar'

Нам понадобиться подготовить скрипт запуска, скрипт на языке groovy (не беспокойтесь, это не обязательно именно так запускать, все можно сделать на голой Java)

Возьмем скрипт из примера:

> cat trambda/trambda-tcp-serv-cli/src/test/samples/sample-1.groov

// Сервис xyz.cofe.trambda.demo.api.LinuxEnv // будет запущен на порту 9988, и будет доступен с любого IPapp.service( "0.0.0.0:9988", new xyz.cofe.trambda.demo.api.LinuxEnv() ) {    daemon false    // Указываем настройки безопасности    security {        // Какие API/Методы будут доступны извне        allow {            // method("System") {            //     methodOwner ==~ /java.lang.System/ && methodName in ['gc']            // }            // field( "System.out" ) {            //     fieldOwner ==~ /java.lang.System/ && fieldName in ['out','in','err'] && readAccess            // }            invoke( 'Java compiler' ){                methodOwner ==~ /java\.lang\.invoke\.(LambdaMetafactory|StringConcatFactory)/            }            invoke( 'Java collections' ){                methodOwner ==~ /java\.util\.(stream\.(Stream|Collectors)|(List))/            }            invoke( 'Java lang' ){                methodOwner ==~ /java\.lang\.String/            }            invoke( 'Api '){                methodOwner ==~ /xyz\.cofe\.trambda\.demo\.api\.(IEnv|OsProc)/            }        }        // Для всех остальных случаев - запрещаем вызов        deny {            any("ban all")        }    }}

Запускаем сервер

user@user-Modern-14-A10RB:22:56:08:~/Загрузки/sample-tr:> bash ./trambda-tcp-serv-cli/bin/trambda-tcp-serv -s trambda/trambda-tcp-serv-cli/src/test/samples/sample-1.groovy# [main] INFO  x.c.t.tcp.serv.cli.TcpServerCLI - starting xyz.cofe.trambda.tcp.serv.cli.TcpServerCLI # [main] INFO  x.c.t.tcp.serv.cli.TcpServerCLI - executeScript( "trambda/trambda-tcp-serv-cli/src/test/samples/sample-1.groovy", UTF-8 ) # [main] INFO  x.c.t.tcp.serv.cli.TcpServerCLI - registry class xyz.cofe.trambda.demo.api.LinuxEnv on 0.0.0.0:9988 # [main] INFO  x.c.t.tcp.serv.cli.TcpServerCLI - starting service xyz.cofe.trambda.demo.api.LinuxEnv@55e7a35c on /0.0.0.0:9988 # [main] DEBUG x.c.t.tcp.serv.cli.TcpServerCLI - create server socket # [main] DEBUG x.c.t.tcp.serv.cli.TcpServerCLI - bind server socket /0.0.0.0:9988 # [main] DEBUG x.c.t.tcp.serv.cli.TcpServerCLI - server started 

Все, сервер запущен, теперь можем им пользоваться

Запуск клиента

Клиента можно взять из примера (ClientTest.java)

package xyz.cofe.trambda.demo.client;import java.util.stream.Collectors;import org.junit.jupiter.api.Test;import xyz.cofe.trambda.demo.api.IEnv;import xyz.cofe.trambda.tcp.TcpQuery;public class ClientTest {   @Test   public void test01(){       var query = TcpQuery           .create(IEnv.class).host("localhost").port(9988)           .build();       query.apply(           env -> env.processes().stream().filter(p ->               p.getName().contains("java"))           .collect(Collectors.toList())       ).forEach(System.out::println);   }}

Запустим и посмотрим, что он выведет, часть логов я опущу - т.к. для пояснения работы они не важны

Что происходит на сервере ?

часть логов я опущу - т.к. для пояснения работы они не важны

Настройка безопасности сервера

Совсем не обязательно использовать сервер через скрипты запуска, сервер можно встроить как часть своего приложения и настраивать так:

// Создание TCP сокетаServerSocket ssocket = new ServerSocket(port);// Настраиваем сокетssocket.setSoTimeout(1000*5);// Создаем серверserver = new TcpServer<IEnv>(    // Передаем сокет    ssocket,        // Передаем функцию получения сервиса для новой сессии    s -> new LinuxEnv(),        // Настраиваем безопасность    SecurityFilters.create(s -> {                // Разрешаем вызовы строго - определенных методов         s.allow( a -> {                        // Публикуемый API нашего сервиса             a.invoke("demo api", c->                c.getOwner().matches(                    "xyz\\.cofe\\.trambda\\.tcp\\.demo\\.([\\w\\d]+)"));                        // Работа с коллекциями            a.invoke("java collections api", c->c.getOwner().matches(                "java\\.util\\.(List)|java\\.util\\.stream\\.([\\w\\d]+)"));                        // Работа с Java строками            a.invoke("java lang api", c->                c.getOwner().matches("java\\.lang\\.(String)"));                        // Методы которые использует компилятор Java            a.invoke("java compiler", c->                c.getOwner().matches(                    "java\\.lang\\.invoke\\.(LambdaMetafactory|StringConcatFactory)"));        });                // Все остальное запрещаем        s.deny().any("by default");    }));// Указываем что Thread сервера будет запущен как фоновыйserver.setDaemon(true);// Запускаем серверserver.start();// Создание TCP сокетаServerSocket ssocket = new ServerSocket(port);// Настраиваем сокетssocket.setSoTimeout(1000*5);

Код приведенный выше вроде кажется понятным, но наверно следует дать несколько пояснений

• Правила проверки безопасности указываются в виде списка фильтров

• Список фильтров обрабатывается последовательно и соответственно первые правила имеют более высокий приоритет, нежели последние

• В списке могут быть как разрешающие, так и запрещающие правила

• Java компилятор генерирует

  • вызовы LambdaMetafactory когда вы используете лямбды в своем коде

  • вызовы StringConcatFactory когда вы применяете оператор + к строкам

• Вы также можете контролировать обращения к полям класса на чтения/запись - см. SecurityFilters.java / PredicateBuilder#field

• Для доступа к стандартным функция, там даже как Object.toString() то, же надо будет задать правила доступа

Более подробную информацию о работе можно найти на странице проекта, например на github или git pages

Чем это может быть полезно?

Резонный вопрос, чем может быть полезно и чем оно отличаеться от уже существующих, например RMI, gRPC ? Давайте рассмотрим отличия

Протоколов передачи данных и вызова процедур много, будут рассмотрены некоторые из известных автору. Эти протоколы можно разделить на несколько категорий/свойств:

• Передача данных

  • Строго ограниченные форматы данных / типы данных

  • Гибкие форматы данных / комбинированные/структурированные типы данных

• Передача программного кода

  • Ограничения на алгоритмы

    • Простые выражения

    • Циклы/ветвления

    • Процедуры/функции/объекты

    • Ограничения на интерпретацию алгоритмов

    • Слабая типизация

    • Строгая типизация

  • Безопасность

    • авторизация и т.д.

    • время исполнения

    • и т.д.

• Поддержка существующий решений

  • Потребность в перезапуске серверов, что бы опробовать новые решения

  • Возможность на ходу опробовать новые решения

  • Профилирование выполнения

• Большинство протоколов ориентированы только на передачу данных (Java-RMI, SOAP, REST-JSON, GraphQL)

  • Часть из них работают со строго типизированными данными (Java-RMI, SOAP, GraphQL)

  • Другие (REST-JSON, Hadoop) со слабо типизированными

• Небольшое кол-во протоколов поддерживают еще передачу программного кода (SQL, Hadoop)

Наличие строгой типизации и передачу программного кода из рассмотренных есть только в SQL

В предлагаемом проекте есть следующие возможности, с оговорками

• Передача данных (*)

  • Гибкие форматы данных / комбинированные / структурированные типы данных

• Передача программного кода

  • Простые выражения

  • Циклы/ветвления

  • Процедуры/функции/

  • программные объекты (**)

• Ограничения на интерпретацию алгоритмов

  • Строгая типизация

  • Безопасность (***)

• Поддержка существующий решений

  • Возможность на ходу опробовать новые решения

  • Профилирование выполнения (****)

Оговорки

• (*)

  • передаваемые типы должны быть Serializable

  • требуется апробация Proxy для интерфейсов

• (**)

  • требуется апробация Proxy для объектов - очень неоднозначный вопрос

• (***)

  • реализована проверка байт-кода, без учета текущего пользователя

  • не реализован механизм аутентификации, см план реализации

• (****)

  • еще не реализовано, см план реализации

Область применения

Поскольку проект только начат, говорить о реальном применении рано, можно говорить о потенциальном применении

Возможны следующий области применения

• фильтрация данных в программах написанных на Java по аналогии SQL WHERE (уже есть)

• выполнение серверных процедур по аналогии RPC/RMI/SOAP/ (уже есть)

• подписка клиента на события сервера

• масштабирование нагрузки (как частный случай реализации сетевого протокола)

При дальнейшем развитии возможно автоматическая прозрачная трансляция JAVA/Kotlin/Scala кода в целевые системы (SQL, MongoDB, REST, )

Данное возможно при условии развития функции декомпиляции байт-кода в код AST/Java/, по факту такая функция реализована в декомпиляторе JAD

Что собственно ведет к уменьшению издержек при разработке ПО.

Как же оно внутри работает ?

Идея была проста, весь код Java который компилируется, обычно сохраняется в виде байт-кода который является файлом с расширением .class, а для любого объекта java можно узнать класс, обычно это выглядит так: obj.getClass()

Через объект Class можно узнать его название, и соответственно через Class.getResource(имя класса) можно получить URL ссылку на данный файл.

Гладко было на бумаге, но забыли про овраги

Такова была идея, но есть нюансы

Процесс разработки, как найти байт код?

Допустим у нас есть такой код

package xyz.cofe.trambda.l1;import java.util.function.Function;import org.junit.jupiter.api.Test;public class SimpleLambdaTest {   @Test   public void javaLambda01(){       Function<Function<String,String>,String> test = (f) -> {           System.out.println("f="+f.getClass());           return null;       };       test.apply( x -> x.repeat(4) );   }}

При выполнении теста будет вот это:

f=class xyz.cofe.trambda.l1.SimpleLambdaTest$$Lambda$235/0x0000000800142040

По идее у нас в каталоге test-classes/ должен быть файл SimpleLambdaTest$$Lambda$235, но такого файла не видно

user@user-Modern-14-A10RB:00:41:32:~/code/trambda/trambda-core/target/test-classes/xyz/cofe/trambda/l1:> llитого 12drwxrwxr-x 2 user user 4096 апр 25 00:40 ./drwxrwxr-x 5 user user 4096 апр 25 00:40 ../-rw-rw-r-- 1 user user 2162 апр 25 00:40 SimpleLambdaTest.class

Тогда посмотрим байт код

> javap -p SimpleLambdaTest.class Compiled from "SimpleLambdaTest.java"public class xyz.cofe.trambda.l1.SimpleLambdaTest {  public xyz.cofe.trambda.l1.SimpleLambdaTest();  public void javaLambda01();  private static java.lang.String lambda$javaLambda01$1(java.lang.String);  private static java.lang.String lambda$javaLambda01$0(java.util.function.Function);}

По факту где-то lambda$javaLambda01$1 или lambda$javaLambda01$0 находиться код нашей лямбды, но можно долго гадать, но это не наш подход

По факту сопоставить class и лямбду в Java с разбегу не удастся, а гадать это сразу путь на костыли.

В Java есть интересный интерфейс Serializable, и этим интерфейсом можно пометить лямбду

Например так

package xyz.cofe.trambda.l2;import java.io.Serializable;import java.util.function.Function;public interface Fn<A,Z> extends Function<A,Z> , Serializable {}

или вот так

Runnable r = (Runnable & Serializable)() -> System.out.println("Serializable!");

Фактически это заставит компилятор Java сгенерировать дополнительный код, давайте возьмем код теста выше и немного его модифицируем

package xyz.cofe.trambda.l2;import java.lang.invoke.SerializedLambda;import java.lang.reflect.InvocationTargetException;import java.lang.reflect.Method;import java.util.function.Function;import org.junit.jupiter.api.Test;public class SerialLambdaTest {   @Test   public void serLambda01(){       Fn<Fn<String,String>,String> test = (lambda) -> {           System.out.println("lambda="+lambda.getClass());           Method writeReplace = null;           try{               writeReplace = lambda.getClass().getDeclaredMethod("writeReplace");               writeReplace.setAccessible(true);               SerializedLambda sl = (SerializedLambda) writeReplace.invoke(lambda);               System.out.println(sl);           } catch( NoSuchMethodException | InvocationTargetException | IllegalAccessException e ) {               e.printStackTrace();           }           return null;       };       test.apply( x -> x.repeat(4) );   }}

Теперь результат будет таким, его разбор будет ниже.

lambda=class xyz.cofe.trambda.l2.SerialLambdaTest$$Lambda$235/0x0000000800142040SerializedLambda[capturingClass=class xyz.cofe.trambda.l2.SerialLambdaTest, functionalInterfaceMethod=xyz/cofe/trambda/l2/Fn.apply:(Ljava/lang/Object;)Ljava/lang/Object;, implementation=invokeStatic xyz/cofe/trambda/l2/SerialLambdaTest.lambda$serLambda01$3fed5817$1:(Ljava/lang/String;)Ljava/lang/String;, instantiatedMethodType=(Ljava/lang/String;)Ljava/lang/String;, numCaptured=0]

А при просмотре байт кода мы увидим

user@user-Modern-14-A10RB:00:51:48:~/code/trambda/trambda-core/target/test-classes/xyz/cofe/trambda/l2:> javap -p SerialLambdaTest.class Compiled from "SerialLambdaTest.java"public class xyz.cofe.trambda.l2.SerialLambdaTest {  public xyz.cofe.trambda.l2.SerialLambdaTest();  public void serLambda01();  private static java.lang.Object $deserializeLambda$(java.lang.invoke.SerializedLambda);  private static java.lang.String lambda$serLambda01$3fed5817$1(java.lang.String);  private static java.lang.String lambda$serLambda01$47b6c34$1(xyz.cofe.trambda.l2.Fn);}

Первое что мы можем заметить - у нас появился метод $deserializeLambda$ пока не важно что делает этот метод, есть факт что добавление интерфейса Serializable меняет поведение компилятора.

java.lang.invoke.SerializedLambda - это final класс, который содержит ряд интересных свойств, а именно

• String getImplClass() - Имя класса, содержащего метод реализации.

• String getImplMethodName() - название метода реализации.

В stdout можно заметить фрагмент

implementation=invokeStatic xyz/cofe/trambda/l2/SerialLambdaTest.lambda$serLambda01$3fed5817$1:(Ljava/lang/String;)Ljava/lang/String;

И в байт коде:

private static java.lang.String lambda$serLambda01$3fed5817$1(java.lang.String);

Т.е. можно однозначно установить байт-код для лямбды

Сериализация байт кода

Теперь, на данном этапе прочесть байт код лямбды - дело техники, а именно так:

SerializedLambda sl = (SerializedLambda)writeReplace.invoke(lambda);var implClassName = sl.getImplClass()var implClassUrl =labmda.getClass().getResource("/"+implClassName.replace(".","/")+".class");

implClassUrl - указывает на файл класса содержащего байт код

получаем байт код из URL как массив байтов

byte[] classByteCode = null;try{   classByteCode = IOFun.readBytes(implClassUrl);} catch( IOException e ) {   throw new IOError(e);}

После этого передаем этот набор байтов в библиотеку ASM для прочтения байт кода

var classReader = new ClassReader(classByteCode);

и читаем байт код нужного метода

ClassVisitor cv = new ClassVisitor(Opcodes.ASM9) {   @Override   public MethodVisitor visitMethod(int access, String name, String descriptor, String signature, String[] exceptions) {       if( methName.equals(name) && descriptor!=null && descriptor.equals(methSign) ){           mdef0.set(new MethodDef(access,name,descriptor,signature,exceptions));           return dump(byteCodes::add);       }       return null;   }};cr.accept(cv, 0);

MethodVisior - это класс который получает байт код конкретного метода. Методы этого класса можно переопределить, рассмотрим часть реализации MethodDump extends MethodVisitor:

package xyz.cofe.trambda;public class MethodDump extends MethodVisitor implements Opcodes {...@Overridepublic void visitParameter(String name, int access){   emit(new MParameter(name,access));}@Overridepublic void visitInsn(int opcode){   emit(new MInsn(opcode));}...}

Данный класс принимает байт код через вызовы методов visitXXXX(...) - их много методов (по этому показа только часть)

При каждом вызове метода генерируется объект который описывает вызов, например для visitInsn( op ) генерируется new MInsn(op), а потом этот объект передается выше emit(..) где уже этот объект передается в сеть

Восстановление классов из байт кода

После этого как код передан по сети в виде набора объектов, эти объекты обратно собирается в байт код (с дополнительными проверками безопасности)

Для этого в моей библиотеке есть класс xyz.cofe.trambda.MethodRestore его работа заключается примерно в следующем

public synchronized byte[] generate(){  // генерируем имя целевого класса  binClassName = className.replace('.', '/');// Создаем ClassWriter (часть ASM) // в котором будем вызывать методы visitXXXX( op )var cw = new ClassWriter(ClassWriter.COMPUTE_MAXS|ClassWriter.COMPUTE_FRAMES);cw.visit(Opcodes.V11,   Opcodes.ACC_PUBLIC|Opcodes.ACC_SUPER,   binClassName,null,   "java/lang/Object", null);// генерация методаvar mv = cw.visitMethod(  acc, // флаги как static public  name, // имя метода  desc, // параметры метода  sign, // сигнатура если есть Generic параметры  excepts); // исключения которые может генерировать метод// Потом в цикле для каждого переданного объекта // генерируем соответствующий вызов visitXXXX()// генерируем код в той же последовательности, что и был прочитанfor( var bc : byteCodes ){   if( bc instanceof MCode )build((MCode) bc);   else if( bc instanceof MEnd )build((MEnd) bc);   else if( bc instanceof MLabel )build((MLabel) bc);   else if( bc instanceof MLineNumber )build((MLineNumber) bc);   else if( bc instanceof MVarInsn )build((MVarInsn) bc);  ...}// Получаем байт кодreturn cw.toByteArray();}// Вызов visitCode() - начало методаprotected void build(MCode code){ mv.visitCode(); }// Вызов visitEnd() - конец методаprotected void build(MEnd end){ mv.visitEnd(); }protected void build(MTypeInsn tinst){   mv.visitTypeInsn(tinst.getOpcode(), tinst.getOperand());}

Теперь когда у нас есть на сервере байт код, остается его загрузить и вызвать соответствующий метод

Для этого создаем свой ClassLoader

var byteCode = new MethodRestore()   .className(clName)   .methodName("lambda1")   .methodDef(mdef)   .generate();ClassLoader cl = new ClassLoader(ClassLoader.getSystemClassLoader()) {   @Override   protected Class<?> findClass(String name) throws ClassNotFoundException{       if( name!=null && name.equals(clName) ){           return defineClass(name,byteCode,0,byteCode.length);       }       return super.findClass(name);   }};

Загружаем класс

System.out.println("try read class "+clName);Class c = null;try{   c = Class.forName(clName,true,cl);   System.out.println("class found "+c);} catch( ClassNotFoundException e ) {   e.printStackTrace();   return;}

Ищем нужный нам метод класса

Method m = null;System.out.println("methods");for( var delMeth : c.getDeclaredMethods() ){  System.out.println(""+delMeth);  if( delMeth.getName().equals(methName) ){    m = delMeth;  }}

и вызываем его с параметрами

try{   Object arg0 = "abc";   System.out.println("call with "+arg0);   Object res = m.invoke(null, arg0);   System.out.println("result "+res);} catch( IllegalAccessException | InvocationTargetException e ) {   e.printStackTrace();}

Ограничения

Конечно у данного решения есть ряд ограничений

1. Не для любого языка подойдет

   1. например для Kotlin придется дописывать реализацию, т.к. Kotlin по другому компилирует лямбды, такая же ситуация с Scala

   2. для динамических языков (Groovy, JavaScript) вообще наверно не подойдет - но там наверно можно и по другому передавать лямбды, например передавать AST дерево лямбд - все зависит от их представления промежуточного кода, чем бы это не являлось.

2. Гарантировать типо безопасность - особенно когда разные версии библиотек на сервере и на клиенте - задача непростая, но еще не означает что невозможно

3. Потенциально на клиенте может Java более новая, с другим байт-кодом нежели на сервере, сервер может не знать о каких либо конструкциях новой Java

4. Библиотека не весь байт код передает, это связано с тем, что не весь байт код имеет объектное представление - наверно это решаемый вопрос, вопрос доработки.

5. Отдельно - это вопрос передачи по сети

   1. Вопрос безопасности - технически это решаемо, но требует допиливание напильником

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

Зададимся вопросом, что такое прогресс? Википедия говорит нам следующее:

Прогресс, проградация(лат.pro движение вперёд, успех;grad шагать, ступать;gradatio постепенное повышение) направление развития от низшего к высшему, положительная динамика, поступательное движение вперед, повышение уровня организации, усложнение способа организации, характеризуется увеличением внутренних связей. Противоположность регресс,деградация

Люди, общество, социум испокон веков стремилось к познанию, открытию, изучению. Вы когда- нибудь задавались вопросом, почему? Почему мы прогрессируем? Что это, код, заложенный в нас природой на генном уровне или чей-то промысел? От каменного оружия до нанотехнологий, от лечения травами, до пересадки сердца, постепенно, со временем, но мы улучшаем и облегчаем нашу жизнь! Вот, два ключевых слова, улучшаем и облегчаем, именно эти два слова, являются нашим двигателем, двигателем развития и прогресса. О чем вы подумаете, если я вам скажу, что война, это тоже необратимая часть прогресса? История, является отражением нашего с вами развития, наших поступков и достижений, от простейшего организма, до организма со сложнейшей структурой. Мы делаем выводы, мы учимся, словно нейросеть. Допускали ли вы, что человек это и есть искусственный интеллект. Забавно, но человек, подобно Богу, стремится создать существо, по образу и подобию своему.

В начале было слово, в нашем же случае, был машинный язык. На протяжении 1950-х годов разработка программ для машин увеличивалась, код усложнялся, структура становилась сложнее. Как итог, люди пришли к созданию первого высокоуровневого языка программирования Фортран, и уже в след за ним начали появляться и другие языки, началось улучшение и развитие инструмента взаимодействия с машиной, причина, следствие. Добавим немного Википедии:

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

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

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

"Всё гениальное просто, и всё простое гениально. Маленькому человечку нравится скрывать свою ничтожность за сложными вещами." Йозеф Геббельс

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

Да, интерпретируемые языки, такие как Python, Ruby, являются "медленными", в сравнении с такими компилируемыми языками, как Java, С++. Скорость работы программ, написанных на них, позволяет нам управлять ракетами, и мы безусловно, должны чтить и уважать их, ибо благодаря им мы имеем, что имеем. Но дело не только в скорости работы программ, но и в простоте написания и скорости разработки. Instagram, Hulu, Twich, Github, Airbnb, Shopify, Reddit, Spotify, все это написано на интерпретируемом языке и я сомневаюсь, что кто-то станет писать Instagram на C++/C, только потому что он быстрее Python, также, верно и обратное утверждение, на Python ни кто не будет писать операционную систему или драйвера. Однако, человеческая природа хочет облегчать и совершенствовать различного рода процессы. Это заложено в нас, идти в перед, развиваться и я не на миг не сомневаюсь, что лет через 100, языки программирования будут подобно человеческому, скорость которых будет сравнима скорости машинному языку. И все это, благодаря человечеству, который подобно организму, развивается, обучается и улучшается.

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

"Я хочу, чтобы компьютер был моим слугой, а не господином, поэтому я должен уметь быстро и эффективно объяснить ему, что делать. " Мацумото Юкихиро

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

"Скорость работы больше не является главной проблемой. Как быстро вы зайдёте на рынок, да." Дин Хуэй

Представьте себе, что вы студент, изучающий современные фичи C++. И вам дали задачу по теме concepts/constraints. У преподавателя, конечно, есть референсное решение "как правильно", но для вас оно неочевидно, и вы навертели гору довольно запутанного кода, который всё равно не работает. (И вы дописываете и дописываете всё новые перегрузки и специализации шаблонов, покрывая всё новые и новые претензии компилятора).

А теперь представьте себе, что вы преподаватель, который увидел эту гору, и захотел помочь студенту. Вы стали упрощать и упрощать его код, и даже тупо комментировать куски юнит-тестов, чтобы оно хоть как-то заработало... А оно всё равно не работает. Причём, в зависимости от порядка юнит-тестов, выдаёт разные результаты или вообще не собирается. Где-то спряталось неопределённое поведение. Но какое?

Сперва преподаватель (то есть, я) минимизировал код вот до такого: https://gcc.godbolt.org/z/TaMTWqc1T

// пусть у нас есть концепты указателя и вектораtemplate<class T> concept Ptr = requires(T t) { *t; };template<class T> concept Vec = requires(T t) { t.begin(); t[0]; };// и три перегрузки функций, рекурсивно определённые друг через другаtemplate<class T> void f(T t) {  // (1)  std::cout << "general case " << __PRETTY_FUNCTION__ << std::endl;}template<Ptr T> void f(T t) {  // (2)  std::cout << "pointer to ";  f(*t);  // допустим, указатель не нулевой}template<Vec T> void f(T t) {  // (3)  std::cout << "vector of ";  f(t[0]);  // допустим, вектор не пустой}// и набор тестов (в разных файлах)int main() {  std::vector<int> v = {1};    // тест А  f(v);  // или тест Б  f(&v);  // или тест В  f(&v);  f(v);  // или тест Г  f(v);  f(&v);}

Мы ожидаем, что

• f(v) выведет "vector of general case void f(T) [T=int]"

• f(&v) выведет "pointer to vector of general case void f(T) [T=int]"

А вместо это получаем

• А: "vector of general case void f(T) [T=int]"

• Б: "pointer of general case void f(T) [T=std::vector<int>]" ?

• В: clang выводит Б и А ?!, gcc ошибку линкера

• Г: clang и gcc выводят ошибку линкера

Что здесь не так?!

А не так здесь две вещи. Первая это то, что из функции (2) видны объявления только (1) и (2), поэтому результат разыменования указателя вызывается как (1).

Без концептов и шаблонов это тоже прекрасно воспроизводится: https://gcc.godbolt.org/z/47qhYv6q4

void f(int x)    { std::cout << "int" << std::endl; }void g(char* p)  { std::cout << "char* -> "; f(*p); }  // f(int)void f(char x)   { std::cout << "char" << std::endl; }void g(char** p) { std::cout << "char** -> "; f(**p); }  // f(char)int main() {  char x;  char* p = &x;  f(x);  // char  g(p);  // char* -> int  g(&p); // char** -> char}

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

Из-за этого, кстати, для взаимно-рекурсивных функций приходится отдельно писать объявления, отдельно (ниже) определения.

Ладно, с этим разобрались. Вернёмся к шаблонам. Почему в тестах В и Г мы получили нечто, похожее на нарушение ODR?

Если мы перепишем код вот так:

template<class T> void f(T t) {.....}template<class T> void f(T t) requires Ptr<T> {.....}template<class T> void f(T t) requires Vec<T> {.....}

то ничего не изменится. Это просто другая форма записи. Требование соответствия концепту можно записать и так, и этак.

Но вот если прибегнем к старому доброму трюку SFINAE, https://gcc.godbolt.org/z/4sar6W6Kq

// добавим второй аргумент char или int - для разрешения неоднозначностиtemplate<class T, class = void> void f(T t, char) {.....}template<class T> auto f(T t, int) -> std::enable_if_t<Ptr<T>, void> {.....}template<class T> auto f(T t, int) -> std::enable_if_t<Vec<T>, void> {.....}..... f(v, 0) .......... f(&v, 0) .....

или ещё более старому доброму сопоставлению типов аргументов, https://gcc.godbolt.org/z/PsdhsG6Wr

template<class T> void f(T t) {.....}template<class T> void f(T* t) {.....}template<class T> void f(std::vector<T> t) {.....}

то всё станет работать. Не так, как нам хотелось бы (рекурсия по-прежнему сломана из-за правил видимости), но ожидаемо (вектор из f(T*) видится как "general case", из main - как "vector").

Что же ещё с концептами/ограничениями?

Коллективный разум, спасибо RSDN, подсказал ещё более минималистичный код!

Всего 4 строки: https://gcc.godbolt.org/z/qM8xYKfqe

template<class T> void f() {}void g() { f<int>(); }template<class T> void f() requires true {}void h() { f<int>(); }

Функция с ограничениями считается более предпочтительной, чем функция без них. Поэтому g() по правилам видимости выбирает из единственного варианта, а h() - из двух выбирает второй.

И вот этот код порождает некорректный объектный файл! В нём две функции с одинаковыми декорированными именами.

Оказывается, современные компиляторы (clang 12.0, gcc 12.0) не умеют учитывать requires в декорировании имён. Как когда-то старый глупый MSVC6 не учитывал параметры шаблона, если те не влияли на тип функции...

И, судя по ответам разработчиков, не только не умеют, но и не хотят. Отмазка: "если в разных точках программы одинаковые обращения к шаблону резолвятся по-разному, такая программа ill-formed, никакой диагностики при этом не нужно" (однако, ill-formed означает "не скомпилируется", а не "скомпилируется как попало"...)

Проблема известна с 2017 года, но прогресса пока нет.

Так что живите с этим. И не забывайте объявлять взаимно-рекурсивные функции до определений. А если увидите странные ошибки линкера, то хотя бы будете понимать, из-за чего они возникают. (А если компилятор будет инлайнить наобум, ну, тогда не повезло).

В первой части Разработка стековой виртуальной машины и компилятора под неё (часть I) сделал свою элементарную стековую виртуальную машину, которая умеет работать со стеком, делать арифметику с целыми числами со знаком, условные переходы и вызовы функций с возвратом. Но так как целью было создать не только виртуальную машину, но и компилятор C подобного языка, пришло время сделать первые шаги в сторону компиляции. Опыта никакого. Буду действовать по разумению.

Одним из первых этапов компиляции является синтаксический анализ (parsing) исходного кода нашего "C подобного языка" (кстати, надо какое-то название дать как только он станет более формальным). Задача простая - "нарубить" массив символов (исходный код) на список классифицированных токенов, чтобы последующий разбор и компиляция не вызывали сложности.

Итак, первый шаг - определиться с типами токенов (интуитивно будем ориентироваться на синтаксис C), символами которые будут отделять токены друг от друга, а также определить структуру для хранения токена (тип, текст токена, длина, строка и столбец в исходном коде).

constexpr char* BLANKS = "\x20\n\t";constexpr char* DELIMETERS = ",;{}[]()=><+-*/&|~^!.";enum class TokenType {NONE = 0, UNKNOWN, IDENTIFIER,CONST_CHAR, CONST_INTEGER, CONST_REAL, CONST_STRING,COMMA, MEMBER_ACCESS, EOS, OP_BRACES, CL_BRACES, OP_BRACKETS, CL_BRACKETS, OP_PARENTHESES, CL_PARENTHESES,BYTE, SHORT, INT, LONG, CHAR, FLOAT, DOUBLE, STRING, IF, ELSE, WHILE, RETURN,ASSIGN, EQUAL, NOT_EQUAL, GREATER, GR_EQUAL, LESS, LS_EQUAL,PLUS, MINUS, MULTIPLY, DIVIDE, AND, OR, XOR, NOT, SHL, SHR,LOGIC_AND, LOGIC_OR, LOGIC_NOT};typedef struct {TokenType type;          char* text;              WORD length;             WORD row;                WORD col;                } Token;

Далее напишем класс для разбора, ключевым методом которого станет parseToTokens(char*). Тут алгоритм простой: идем до разделителя (BLANKS и DELIMETERS), определяем начало и конец токена, классифицируем его и добавляем в вектор (список) токенов. Особые случаи разбора - это отличать целые числа от вещественных, вещественные числа (например, "315.0") отличать от применения оператора доступа к членам структуры/объекта ("obj10.field1"), а также отличать ключевые слова от других идентификаторов.

void VMParser::parseToTokens(const char* sourceCode) {TokenType isNumber = TokenType::UNKNOWN;bool insideString = false;                                         // inside string flagbool isReal = false;                                               // is real number flagsize_t length;                                                     // token length variablechar nextChar;                                                     // next char variablebool blank, delimeter;                                             // blank & delimeter char flagstokens->clear();                                                   // clear tokens vectorrowCounter = 1;                                                    // reset current row counterrowPointer = (char*)sourceCode;                                    // set current row pointer to beginningchar* cursor = (char*)sourceCode;                                  // set cursor to source beginning char* start = cursor;                                              // start new token from cursorchar value = *cursor;                                              // read first char from cursorwhile (value != NULL) {                                            // while not end of stringblank = isBlank(value);                                          // is blank char found?delimeter = isDelimeter(value);                                  // is delimeter found?length = cursor - start;                                         // measure token length    // Diffirentiate real numbers from member access operator '.'isNumber = identifyNumber(start, length - 1);                    // Try to get integer part of real numberisReal = (value=='.' && isNumber==TokenType::CONST_INTEGER);     // Is current token is real numberif ((blank || delimeter) && !insideString && !isReal) {          // if there is token separator                   if (length > 0) pushToken(start, length);                      // if length > 0 push token to vectorif (value == '\n') {                                           // if '\n' found rowCounter++;                                                // increment row counterrowPointer = cursor + 1;                                     // set row beginning pointer}nextChar = *(cursor + 1);                                      // get next char after cursorif (!blank && isDelimeter(nextChar)) {                         // if next char is also delimeterif (pushToken(cursor, 2) == TokenType::UNKNOWN)              // try to push double char delimeter tokenpushToken(cursor, 1);                                      // if not pushed - its single char delimeterelse cursor++;                                               // if double delimeter, increment cursor} else pushToken(cursor, 1);                                   // else push single char delimeterstart = cursor + 1;                                            // calculate next token start pointer}else if (value == '"') insideString = !insideString;             // if '"' char - flip insideString flag else if (insideString && value == '\n') {                        // if '\n' found inside string// TODO warn about parsing error}cursor++;                                                        // increment cursor pointervalue = *cursor;                                                 // read next char}length = cursor - start;                                           // if there is a last tokenif (length > 0) pushToken(start, length);                          // push last token to vector}

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

class VMParser {public:VMParser();~VMParser();void parseToTokens(const char* sourceCode);Token getToken(size_t index);size_t getTokenCount();  private:vector<Token>* tokens;WORD rowCounter;char* rowPointer;  bool isBlank(char value);bool isDelimeter(char value);TokenType pushToken(char* text, size_t length);TokenType getTokenType(char* text, size_t length);TokenType identifyNumber(char* text, size_t length);TokenType identifyKeyword(char* text, size_t length);};

Попробуем используя класс VMParser разобрать строку исходного кода C подобного языка (исходный код бессмысленный, просто набор случайных токенов для проверки разбора):

int main(){    printf ("Wow!");    float a = 365.0 * 10 - 10.0 / 2 + 3;while (1 != 2) {    abc.v1 = 'x';}if (a >= b) return a && b; else a || b; };

В итоге получаем в консоли следующий перечень классифицированных токенов:

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

Для простоты сначала реализуем компилятор арифметических выражений с целыми числами (приоритет "*" и "/" над "+" и "-" учитывается), без скобок, унарных операций и других важных вещей, в том числе проверки синтаксических ошибок. Разбор выражений напишем вот так:

void VMCompiler::parseExpression(size_t startIndex, VMImage* destImage) {Token tkn;currentToken = startIndex;parseTerm(destImage);tkn = parser->getToken(currentToken);while (tkn.type==TokenType::PLUS || tkn.type==TokenType::MINUS) {  currentToken++;  parseTerm(destImage);  if (tkn.type==TokenType::PLUS) destImage->emit(OP_ADD); else destImage->emit(OP_SUB);  tkn = parser->getToken(currentToken);}}void VMCompiler::parseTerm(VMImage* destImage) {Token tkn;parseFactor(destImage);currentToken++;tkn = parser->getToken(currentToken);while (tkn.type == TokenType::MULTIPLY || tkn.type == TokenType::DIVIDE) {  currentToken++;  parseFactor(destImage);  if (tkn.type == TokenType::MULTIPLY) destImage->emit(OP_MUL); else destImage->emit(OP_DIV);  currentToken++;  tkn = parser->getToken(currentToken);}}void VMCompiler::parseFactor(VMImage* destImage) {Token tkn = parser->getToken(currentToken);char buffer[32];strncpy(buffer, tkn.text, tkn.length);buffer[tkn.length] = 0;destImage->emit(OP_CONST, atoi(buffer));}

Попробуем скормить этому компилятору выражение "3+5*6+2*3+15/5", запускаем компилятор с выводом скомпилированных команд и сразу запускаем виртуальную машину. Ожидаем, что результат вычисления должен остаться на вершине стека - 42.

Ура! Получилось! Первые шаги в сторону компилятора сделаны.

Всем привет! На связи Антон Баширов, разработчик из ИТ-кластера Ростелекома. Импортозамещение набирает обороты, а российский софт всё глубже проникает в нашу повседневную ИТ-шную сущность бытия. Процессоры Эльбрус и Байкал становятся более востребованными, комьюнити расширяется, но мысли о необходимости портировать весь наш любимый технологический стек на неизведанную архитектуру E2K звучат страшнее рассказов про горящий в пламени production-кластер.

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

Итак, гость в студии база данных Reindexer, разработка нашего ИТ-кластера.

Стоит сказать, почему выбор пал именно на Reindexer, а не другую БД. Во-первых, всеми любимый и известный Postgres уже есть в составе пакетов ОС Эльбрус. Переносить его нет необходимости. Во-вторых, наш гость уже прошел испытания на ARM, следовательно, пришло время ему покорить Эльбрус.

Стоит упомянуть, что Reindexer появился на свет как продуктвыбора между Elastic и Tarantool. Это определенно хочется попробовать завести на отечественном процессоре.

День 0. Знакомство с гостем

Несколько слов про нашего гостя:

Имя:NoSQL in-memory database Reindexer с функционалом полнотекстового поиска
Возраст:на момент испытаний версия БД была 3.1.2
Происхождение:Россия
Место рождения:пытливый ум разработчика Олега Герасимова@olegator99
Место жительства:https://github.com/Restream/reindexer
Место работы:Ростелеком
Строение:основная составляющая C++, имеются примеси из языка Ассемблера и немного CMake
Особенности:- Ассемблерные вставки;
- Много С++11 и C++14;
- Используются корутины.

Деятельность:- Хранение данных в памяти и на диске;
- Выполнение SQL запросов со скоростью 500K queries/sec для PK запросов;
- Выполнение запросов типа full-text search (почти как Elastic, только не тормозит);
- Работа в режиме server и embedded;
- Общение с крутыми парнями: Go, Java, Rust, .NET, Python, C/C++ и (да простит меня Хабр) PHP.

Заскучали? На этом нудная часть закончилась. В эфире рубрика Ээээксперименты!

День 1. А ты думал, в сказку попал?

Для начала попробуем нашего друга собрать из того, что есть.Идем на тестовый сервер Эльбрус 8C с ОС Эльбрус 6.0.1, клонируем туда репозиторий и запускаем CMake.

Хорошие новости, мы нашли компилятор! Новость действительно хорошая, ведь у Эльбруса свой компилятор LCC.

К счастью, создатели Эльбрус сделали LCC полностью совместимым с GCC и наши любимые нативные программки и сборщики смогут чувствовать себя хорошо без особых манипуляций. LCC уже сделал за вас нужные линки:gcc -> /opt/mcst/bin/lcc*.

Но вернемся к нашему гостю и тому, что не понравилось CMake.

В скриптах сборки, в CMakeLists.txt выполняется определение операционной системы и архитектуры процессора, на которой собирается Reindexer. Нужно это для того, чтобы подключать правильные исходники ассемблера, ведь как говорится Write once, run anywhere.

Разумеется, на момент написания скриптов никто не знал про процессоры Эльбрус, поэтому наш скрипт и упал. Исправляем.

Программисты люди ленивые, поэтому:

Попытка 2:

А что так можно было? На самом деле да для того, чтобы завелся CMake, этого было достаточно. Теперь ударим в бубен и запустимmake -j8:

Для тех, кто уже успел поработать с кроссплатформенным софтом, не новость, что С/С++ код с помощью макросов разделяют на платформозависимые секции.

Поэтому, в некоторые места кода Reindexer понадобилось добавить парочку новых условий для__E2K__и__LCC__:

После колдовства с макросами нас ждал монстр пострашнее:

Вот что бывает, когда игнорируешь messages у CMake.

Из-за того, что CMake не нашел подходящих исходников, компилятор не смог найти реализации двух функций:jump_fcontextиmake_fcontext. Про назначение этих функций я расскажу чуть позже, а пока что давайте успокоим нашего гостя и подсунем ему пару пустышек:

Этих операций оказалось достаточно, чтобы Reindexer собрался.

Поздравляю, у вас двойня!

Вот они, наши два долгожданных файла:

# file reindexer_serverreindexer_server: ELF 64-bit LSB executable, MCST Elbrus, version 1 (GNU/Linux

# file reindexer_toolreindexer_tool: ELF 64-bit LSB executable, MCST Elbrus, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux.so.2, for GNU/Linux 2.6.33, with debug_info, not stripped

Это можно считать успехом. Мы смогли собрать наш первый Эльбрус-бинарник. Даже два бинарника: reindexer_server и reindexer_tool.

Подведем итоги. Чтобы собрать Reindexer, мы:

• Поправили CMake-скрипты;

• Добавили несколько условий в макросы препроцессора;

• Заглушили ASM функции.

День 3. Наш Гость, попав на Эльбрус, начал подавать признаки жизни

Первый запуск прошел успешно - сервер поднялся, и даже открылся web-ui.

Я привык не останавливаться на достигнутом и решил немного поработать над Reindexer.

Результат меня порадовал - Гость устал и прилег отдохнуть:

Такое поведение наблюдалось только на Эльбрус. На i5 все работало штатно.

Давайте разбираться. Вооружившись отладчиком (gdb кстати под E2K работает прекрасно) и CLion, мне удалось докопаться до истины.

Пару запросов к Reindexer смогли воспроизвести ошибку:

Падает в деструкторе. Интересный момент - упало на free (в данном случае free реализуется через jemalloc). Видимо, здесь идет высвобождение памяти по некорректному указателю. Ошибку эту я исправлял в два этапа:

1. work around - дело в том, что QueryEntry лежит в объекте ExpressionTree, в самом классе примечательного я не нашел, поэтому копнул в сторону родителя. Оказалось, что до вызова деструктора был вызван вот такой копирующий конструктор, в котором есть интересный MakeDeepCopy(), реализованный с помощью библиотечкиmpark-variant.

   Подробнее про expression tree рассказываюттут.

   На часах было 2 часа ночи, я засиделся в офисе и разбираться в variant было уже лениво, поэтому, каюсь, я решил просто убрать вызов этого метода.

   

   Итог - оно заработало.

2. TODO: Исправление тоже есть, но рассказ про него уже выходит за рамки данной статьи. Небольшой спойлер (код из mpark-variant с патчем под e2k):

inline constexpr DECLTYPE_AUTO visit(Visitor &&visitor, Vs &&... vs)#ifdef E2K //Fix for Elbrus    -> decltype(detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...))    {     return detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...);    }#else    DECLTYPE_AUTO_RETURN(        (detail::all(             lib::array<bool, sizeof...(Vs)>{{!vs.valueless_by_exception()...}})             ? (void)0             : throw_bad_variant_access()),        detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...))#endif

День 5. Он ожил! Ну почти

Сервер у нас, действительно, работает, даже удалось получить первые результаты бенчмарков.

Но все это время я упорно игнорировал один компонент.

Помните, как мы убрали завязку на ASM и функцииmake_fcontext и jump_fcontext?

Так вот, ASM исходники в Reindexer нужны для реализации C++ корутин, а эти функции - ключевые для корутин из библиотеки boost/context.

Корутина это функция, которая может быть приостановлена и возобновлена в любой момент. Для реализации достаточно трех основных компонентов:
- функция
- механизм для ее паузы (suspend)
- механизм для возобновления ее с той точки, в которой была сделана пауза (resume).

Реализацию корутин можно увидеть в таких языках и библиотеках, как:

• Libcoro(корутины на C/С++)

• Koishi(тоже корутины, тоже на С/С++)

• Boost(и это тоже корутины, тоже на С/С++, корутин много не бывает!)

• Node-fibers(корутины для NodeJS на базе libcoro)

• Tarantool(fibers на базе libcoro)

• Kotlin(свои корутины, не на C++)

• C++20

• Goroutine

Для наглядности вот скрин теста корутин из Koishi:

Последовательность следующая:

1. Создали корутину, выделили стек, задали функцию;

2. Возобновили корутину - в этот момент вызвалась наша функция;

3. Приостановили корутину с помощьюkoishi_yield здесь мы вернули управление в test1 сразу после строчкиkoishi_resume;

4. Если мы еще раз сделаемkoishi_resumeна нашей корутине мы вернемся на строчку функции cofunc1 сразу после первого вызоваkoishi_yield.

Без корутин не будет работать reindexer_tool, но не можем же мы оставить Reindexer без такой важной конечности. Будем исправлять.

Начнем с анализа ситуации. Ожидаемо, что ASM Эльбруса бустовские корутины не поддерживают (пока что), а значит нам нужно реализовать их самим. Подробности и реализацию бустовских корутин можете посмотретьздесь, а сейчас наступило время скрещивать ужа с ежом.

Есть несколько вариантов реализовать корутины:

• Вариант 1:написать ASM реализацию. Самый очевидный, но при этом самый сложный вариант. У нас есть в планах попробовать именно этот вариант, так как ASM корутины - самые быстрые.

• Вариант 2: забить. Нет, это не наш путь.

• Вариант 3: использовать библиотеку.

По счастливой случайности Koishi оказалось той самой библиотекой, поддерживающей реализацию корутин с помощью встроенных E2K функций:makecontext_e2k()иfreecontext_e2k().

Там, где стандартная медицина бессильна, в дело вступает генная инженерия.

Для начала внедрим Koishi в организм Reindexer:

Заменим больной орган на здоровый:

Стараемся не повредить то, что уже работает:

Одним из backend-ов Koishi для корутин выступает fcontext (те же самые boost исходники, что в Reindexer). Последуем древней мудрости работает не трогай! и оставим как есть в случае, если у нас не E2K архитектура. Для Эльбруса мы будем использоватьucontext_e2k.c

И вот он, наш мутант с корутинами полностью здоров и функционален (и на amd64, и на E2K):

День 11. Проводим финальные испытания

Две половинки нашего Франкенштейна собраны вместе, даже сторонняя библиотека прижилась и отлично себя показала. Пришло время для финальных тестов.

Всего в Reindexer около 300 функциональных тестов, и мне не терпится запустить их все.

Тесты бежали, бежали и не добежали. Один из тестов вызвал Segmentation Fault.

Всему виной оказались вот эти строчки:

struct ConnectOpts {  /* тут тоже код, но он не такой интересный */  uint16_t options = 0;  int expectedClusterID = -1;};

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

Попробуем воспроизвести на изолированном более простом примере.

ASM, настало твое время

Внимание на скриншот:

Ошибка проявляется именно в том случае, когда отсутствуют не проинициализированные поля. Другими словами, если все ваши поля инициализируются при объявлении вы счастливчик, поймавший Segmentation Fault.

Баг заключается в том, что скомпилированное создание структуры выглядит как странныйaddd. Именно эта строчка и вызывает segfault. Кстати, если вместоbool anyField = falseнаписать простоbool anyField, то код совершенно другой и ошибки нет.

Семь бед, один ответ обновитесь!

Разгадка тайны оказалась проста. На момент работы с Reindexer последней версией компилятора LCC была v.1.25.16, однако в состав пакетов ОС Эльбрус по умолчанию входит 1.25.14, на котором я и запускал тесты. Добрые люди из сообщества подсказали нам, что уже в 15 версии данный баг был исправлен. Я решил обновиться на 16-ую и посмотреть, что будет.

Вот что нам принес новый компилятор LCC v.1.25.16:

C++ код такой же, однако ASM совсем другой, и что самое главное он работает! Последовательно (заранее прошу прощения за мой ломаный asm-русский переводчик):

1. gestp - выделяем стек и кладем его в %dr3

2. setwd - задаем текущее окно в регистровом файле

3. setbn - задаем подвижную базу регистров в текущем окне регистрового файла

4. addd - кладем "дно" стека (стек размером 0x20) в %dr2

5. addd - выделяем на стеке нашу структуру

6. ldb - достаем из констант наш false и кладем его в %r5

7. stb - кладем наш false из регистра %r5 в наше поле anyField1

8. addd - подготовили локальный указатель на структуру для вызова метода

9. addd - передаем указатель в базовый регистр для передачи при вызове anyMethod (в anyMethod мы достаем указатель из регистра %dr0)

10. disp - подготавливаем регистр перехода на anyMethod

11. call - вызываем anyMethod

Дальше все просто пересобрать, перезапустить, обрадоваться.

Тесты прошли успешно, и теперь у нас есть полностью рабочий и протестированный Reindexer на Эльбрусе.

На этом все ?

На самом деле нет. Сейчас мы смогли:

• собрать Reindexer Server

• запустить Reindexer Server

• собрать Reindexer Tool

• запустить Reindexer Tool

• переписать кусочек Reindexer Tool

• уронить Reindexer и поднять его

• добиться 100% проходимости Reindexer тестов

Мы научились:

• собирать C++ софт на Эльбрус

• переписывать C++ софт под особенности и отличия Эльбрусов

• разбираться в ASM E2K

• превозмогать трудности

• разбираться в C++ корутинах даже на Эльбрусе

Что в планах:

• корутины на ASM E2K (может быть даже сравнить fcontext ASM на i5 и ucontext/ASM на E2K)

• оптимизировать Reindexer под архитектуру Эльбрус

• перенести еще несколько интересных приложений на Эльбрус

• дополнить базу библиотек и пакетов Эльбрус

• организовать E2K инфраструктуру и песочницу

Что же можно сказать про Эльбрус со стороны простого разработчика?

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

На сегодня это всё, что хотелось бы вам рассказать, но я еще вернусь с новыми интересными подробностями про портирование и оптимизацию, и да прибудет с вами сила Эльбруса!

По ходу разработки генератора кода для виртуальной машины понял, что виртуальная машина не готова к полноценным вызовам функций, с передачей аргументов и хранением локальных переменных функций. Поэтому её необходимо доработать. А именно, нужно определиться с Соглашением о вызовах (calling convention). Есть много разных вариантов, но конечный выбор за разработчиком. Главное - это обеспечить целостность стека, после вызова.

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

На сегодняшний день, наиболее знакомые мне Соглашения о вызове (calling convention), регулирующее правила передачи аргументов функции, очистки стека после вызова, а также логика хранения локальных переменных - это C declaration (cdecl, x86/64) и pascal. Попробую применить эти знания с небольшими модификациями, а именно без прямого доступа программы к регистрам виртуальной машины (она же всё таки стековая, а не регистровая). Итак, логика будет следующая:

Поясню что происходит. Функция main() вызывает функцию sum() и передаёт ей два аргумента - значение переменной i и константное число 10. Осуществляется передача аргументов путём добавления значений аргументов в стек слева направо (как в pascal). После чего осуществляется вызов функции инструкцией виртуальной машины call, которой указывается адрес вызова и количество передаваемых через стек аргументов - 2.

Дальше команда call должна сделать следующие вещи:
1) сохранить в стек адрес возврата после вызова IP (Instruction Pointer + 1)
2) сохранить в стек значение Frame Pointer (регистр виртуальной машины, которым мы показываем до куда очищать стек после вызова).
3) сохраняем в стек значение Locals Pointer (регистр указывающий на место в стеке где начинаются локальные переменные вызывающей функции).
4) выставить значение Frame Pointer на первый аргумент в стеке, чтобы мы знали докуда очищать стек после завершения выполнения функции.
5) выставить значение Locals Pointer на адрес в стеке сразу после сохранных значение IP, FP, LP.

В свою очередь команда ret должна выполнить действия в обратном порядке:
1) Восстановить из стека предыдущие значения IP, FP, LP.
2) Взять результат выполнения функции с вершины стека.
3) Выставить SP = FP (очистить стек в состояние до вызова).
4) Положить на вершину стека результат выполнения функции.

Так как делаем стековую, а не регистровую виртуальную машину, не хочу давать прямой доступ к регистрам, поэтому доработаем инструкцию CALL / RET, а также добавим четыре дополнительные инструкции LOAD (положить в стек значение локальной переменной с указанным индексом), STORE (взять верхнее значение в стеке и сохранить в локальной переменной с указанным индексом), ARG (добавить в стек значение аргумента функции с указанным индексом), а также DROP - инструкция выбросить из стека верхнее значение. Последняя инструкция DROP нужна для функций значение которых нам не нужно, так как мы не даём прямой доступ к регистрам.

case OP_CALL:a = memory[ip++];      // get call address and increment addressb = memory[ip++];      // get arguments count (argc)b = sp + b;            // calculate new frame pointermemory[--sp] = ip;     // push return address to the stackmemory[--sp] = fp;     // push old Frame pointer to stackmemory[--sp] = lp;     // push old Local variables pointer to stackfp = b;                // set Frame pointer to arguments pointerlp = sp - 1;           // set Local variables pointer after top of a stackip = a;                // jump to call addressbreak;case OP_RET:a = memory[sp++];      // read function return value on top of a stackb = lp;                // save Local variables pointersp = fp;               // set stack pointer to Frame pointer (drop locals)lp = memory[b + 1];    // restore old Local variables pointerfp = memory[b + 2];    // restore old Frame pointerip = memory[b + 3];    // set IP to return addressmemory[--sp] = a;      // save return value on top of a stackbreak;case OP_LOAD:a = memory[ip++];         // read local variable indexb = lp - a;               // calculate local variable addressmemory[--sp] = memory[b]; // push local variable to stackbreak;case OP_STORE:a = memory[ip++];         // read local variable indexb = lp - a;               // calculate local variable addressmemory[b] = memory[sp++]; // pop top of stack to local variablebreak;case OP_ARG:a = memory[ip++];         // read parameter indexb = fp - a - 1;           // calculate parameter addressmemory[--sp] = memory[b]; // push parameter to stackbreak;case OP_DROP:                   // pop and drop value from stacksp++;break;

Скомпилируем код представленный на иллюстрации выше чтобы протестировать как работают новые инструкции CALL, RET, LOAD, STORE, ARG (примечание: syscall 0x21 - это распечатка числа с вершины стека в консоль):

Запустим исполнение этого кода с распечаткой состояния виртуальной машины после выполнения каждой инструкции:

[   0]    iconst  5     IP=2 FP=65535 LP=65534 SP=65534 STACK=[5] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[5,5] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[5,4] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[5,4,4] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[4,4] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[4,4,4] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[4,4,4,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[4,4,4,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[4,4,4,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[4,4,4,10,14,65535,65534,10,4] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[4,4,4,10,14,65535,65534,10,4,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[4,4,4,10,14,65535,65534,10,14] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[4,4,4,10,14,65535,65534,10,14,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[4,4,4,10,14,65535,65534,10,4] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[4,4,4] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[4,4] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[4,4,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[4] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[4,4] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[4,3] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[4,3,3] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[3,3] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[3,3,3] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[3,3,3,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[3,3,3,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[3,3,3,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[3,3,3,10,14,65535,65534,10,3] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[3,3,3,10,14,65535,65534,10,3,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[3,3,3,10,14,65535,65534,10,13] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[3,3,3,10,14,65535,65534,10,13,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[3,3,3,10,14,65535,65534,10,3] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[3,3,3] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[3,3] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[3,3,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[3] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[3,3] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[3,2] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[3,2,2] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[2,2] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[2,2,2] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[2,2,2,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[2,2,2,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[2,2,2,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[2,2,2,10,14,65535,65534,10,2] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[2,2,2,10,14,65535,65534,10,2,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[2,2,2,10,14,65535,65534,10,12] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[2,2,2,10,14,65535,65534,10,12,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[2,2,2,10,14,65535,65534,10,2] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[2,2,2] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[2,2] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[2,2,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[2] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[2,2] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[2,1] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[2,1,1] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[1,1] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[1,1,1] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[1,1,1,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[1,1,1,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[1,1,1,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[1,1,1,10,14,65535,65534,10,1] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[1,1,1,10,14,65535,65534,10,1,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[1,1,1,10,14,65535,65534,10,11] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[1,1,1,10,14,65535,65534,10,11,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[1,1,1,10,14,65535,65534,10,1] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[1,1,1] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[1,1] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[1,1,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[1] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[1,1] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[1,0] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[1,0,0] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[0,0] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[0,0,0] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[0,0,0,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[0,0,0,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[0,0,0,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[0,0,0,10,14,65535,65534,10,0] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[0,0,0,10,14,65535,65534,10,0,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[0,0,0,10,14,65535,65534,10,10] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[0,0,0,10,14,65535,65534,10,10,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[0,0,0,10,14,65535,65534,10,0] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[0,0,0] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[0,0] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[0,0,0] -> TOP[  18]    icmpjg  [2]   IP=20 FP=65535 LP=65534 SP=65534 STACK=[0] -> TOP[  20]    ---- halt ----IP=21 FP=65535 LP=65534 SP=65534 STACK=[0] -> TOPEXECUTION TIME: 0.620997s

В консоли данная программа выдает следующее

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

Ура! Это вдохновляет!

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

• Мультиклеточный процессор это что?

• Мультиклет R1 первые тесты

• Компилятор С/С++ на базе LLVM для мультиклеточных процессоров: быть или не быть?

• Развитие компилятора C для нового мультиклета-нейропроцессора

Первое, что необходимо сказать, Мультиклет концептуально переходит от разработки отдельных процессоров к разработке мультиклеточной платформы на основе MultiClet B базового элемента, состоящего из 4 клеток.

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

В мультиклеточную платформу входят два типа ядер, два типа блоков матричной арифметики и два типа блоков доступа к памяти.

Процессоры могут отличаться количеством ядер, системой команд, разрядностью данных, методами доступа к памяти. Конфигурация процессора может быть гомогенной, если процессор состоит из однотипных ядер. Гетерогенной, если в составе процессора присутствуют ядра различных типов. Частным случаем гомогенной конфигурации является матричная организация, когда 1, 4 или 16 ядер объединены блоком матричных операций.

Ядро в мультиклеточном процессоре это четыре клетки объединенные в единый неделимый блок - мультиклетку. Ядра отличаются разрядностью данных. Младшее ядро использует малоразрядные данные 8i, 16if, 32if, где цифры указывают на разрядность используемых данных, а индексы i, f на их тип (i целочисленные, f с плавающей точкой). Старшее данные 16if, 32if, 64if. Каждый тип ядра имеет два варианта реализации внутренней архитектуры:

1. Первый предназначен для создания процессоров с низким энергопотреблением и имеет внутренние конвейеры с минимальным количеством ступеней.

2. Второй для процессоров с высокой производительностью, что требует увеличения глубины конвейеров.

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

Блоки матричной арифметики также отличаются разрядностью, а именно блок, использующий 16-ти битовые данные с плавающей точкой и блок с данными 32f/64f. Каждый из блоков обеспечивает выполнение операции умножения матрицы. Допустимы три варианта размерности матрицы. При использовании одного ядра: 2х2 (64f); 2х4 (32f); 4х4 (16f). При использовании 4-х ядер: 4х4 (64f); 4х8 (32f); 8х8 (16f). Для 16-ти ядер размерности составят: 8х8 (64f); 8х16 (32f); 16х16 (16f).

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

Максимальную эффективность метод DMC демонстрирует при решениии расчетных задач, которые отличаются сранительно небольшими объемами программ, но при этом выпоняют большой объем вычислений.

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

При создании MultiClet B была проведена множественная оптимизации ядра, что позволило увеличить тактовую частоту ядра до 2 ГГц на топонорме 28 нм и одновременно на 15-20% ускорить исполнения кода на этой частоте. Ускорение было достигнуто за счет сокращения времени прохождения команд по тракту исполнения. В частности было уменьшено время обработки команд в буфере АЛУ и обеспечена передача адреса нового параграфа клеткам по отдельному тракту. Компилятор был обновлен до LLVM 11.0.0, что также дало ускорение скомпилированного кода.

Бенчмарки

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

Данные в таблице, приведенной ниже, будут использоваться для расчетов удельной производительности на Ватт и на мм² для всех бенчмарков. Характеристики ядра MultiClet B получены по результатам логического синтеза и последующего моделирования.

CoreMark

CoreMark набор тестов для комплексной оценки производительности микроконтроллеров и центральных процессоров, а также их C-компиляторов. Более подробное его описание и причину использования можно посмотреть в одной из предыдущих статей.

DhryStone

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

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

Задача о 8 ферзях

Задача о восьми ферзях широко известная комбинаторная задача по расстановке фигур на шахматной доске. Исходная формулировка: Расставить на стандартной 64-клеточной шахматной доске 8 ферзей так, чтобы ни один из них не находился под боем другого.

Данный тест интересен тем, что содержит в себе множество ветвлений, которые плохо поддаются предсказанию.

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

Бинарные деревья, глубина 6

Задача данного теста состоит в создании бинарных деревьев с использованием минимального количества выделений памяти. Листья дерева и внутренние узлы должны быть одинаковыми. Скорость данного теста во многом определена эффективностью реализации динамического выделения памяти.

Множество Мандельброта, размерность 32х32

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

Все показанные бенчмарки были скомпилированы компилятором LLVM из исходного кода на С. Компилятор для мультиклеточной архитектуры пока генерирует не самый оптимальный код, что видно по количеству тактов, затрачиваемых на выполнение бенчмарков. Не вдаваясь в разницу между мультиклеточной системой команд и x86, количество инструкций, которые исполняет процессор от Интела для выполнения любого из этих бенчмарков в среднем в 2 и более раза ниже, чем количество инструкций, исполняемых мультиклеточным процессором. Это значит, что у компилятора есть перспектива развития, а также что производительность процессора на данных бенчмарках можно значительно ускорить только за счет оптимизации программного обеспечения.

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

• Удалены лишние пробросы значений инструкцией load, оставшиеся после phi узлов

• Вместо использования памяти, передача данных между параграфами сделана через коммутатор, где это возможно

• Где это невозможно, передача данных сделана через регистры общего назначения

• Объединены некоторые параграфы и/или перенесены некоторые инструкции из следующего параграфа в предыдущий для заполнения простоев, возникающих при переходе с одного параграфа на другой

Эти оптимизации, которые можно внедрить в компилятор и которые требуют разработки, были вручную вписаны в ассемблерный код, что позволило понять какие оптимизации компилятора будут самые эффективные, какие нужно делать в первую очередь, и какую можно ожидать производительность. В итоге, количество тактов уменьшилось с 905,430 до 412,117:

Полученные данные показывают, что при реализации сугубо последовательных алгоритмов, мультиклеточное ядро по производительности почти эквивалентно одному ядру архитектуры Intel Kaby Lake, но при этом энергопотребление и затраты кремниевых ресурсов получаются в десятки раз меньше.

Ethereum

Ethereum мы тоже используем как бенчмарк, и он очень важен по двум причинам:

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

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

Как можно заметить, при сопоставимом хэшрейте энергопотребление в 2-3 раза ниже даже на техпроцессе 28 нм. При переходе на техпроцесс 7 нм энергопотребление сокращается еще сильнее.

Оценка использования мультитклеточной платформы для майнинга проводилась на примере получения криптовалюты Ethereum. Моделирование проводилось для процессора MultiClet S1, состоящего из 16 мультиклеток. Данные по производительности платы получены расчетным путем. Для сравнения была выбрана старшая модель платы компании NVIDIA, которая спроектирована специально для майнинга и выпуск которой намечен на 2021год. Данные по ее планируемой производительности взяты с сайта компании. Результаты показывают, что при близкой производительности, плата использующая процессоры MultiClet S1, по удельным показателям, эффективна более чем в 2 раза по сравнению с NVIDIA 90HX.

Заключение

Анализ полученных результатов определил дальнейшие направления оптимизации программного и аппаратного обеспечения:

• Во первых, на аппаратном уровне это оптимизация доступа к памяти, аналогичная той, которая реализована для команд, проходящих через буфер АЛУ.

• Во вторых, это разработка и реализация алгоритмов оптимизации бэкенда для компилятора LLVM. При выполнении всех схем оптимизации (показанные на примере компиляции генератора множества Мандельброта) производительность мультиклеточного ядра на скомпилированном коде будет практически эквивалентно современному ядру Intel, но при этом удельные характеристики по энергопотреблению и кремниевым ресурсом в будут превосходить его в десятки раз.

Если у вас есть желание попробовать скомпилировать и запустить программы на функциональной модели, SDK есть на сайте Мультиклета.

Благодарим за внимание!