Англійська для розробників Mojo

Mojo позиціонує себе як «синтаксис Python з системним рівнем продуктивності», що означає, що його англійська лексика запозичує знайомі Python слова, при цьому додаючи набагато суворіші, Rust-подібні значення навколо семантики власності і цінності — прогалина, яка спонукає розробників, що прибувають з чистого Python. Цей підручник містить інформацію про англійську мову, яку використовують під час обговорення коду Mojo з командою.

Ключовий словник

Власність — Моделювання часу компіляції Mojo, за якою змінна відповідає за час життя значення, визначаючи, коли значення буде скопійовано, запозичено або пересунуто, подібне за змістом до моделювання власності Rust. “Ця функція бере список за значенням замість того, щоб позичати його — це змушує створювати неявну копію при кожному виклику, що перевершує перевагу швидкодії, яку ми хотіли від Mojo.”

Struct (vs. class) — структура даних типу значення зі статичним відправником і без неявної спадковості, використовується для критичного коду продуктивності, на відміну від класів Mojo, сумісних з Python, які зберігають динамічну поведінку типу посилання. “Визнайомтеся зі структурою, а не класом — нам потрібна семантика значення і статичний розподіл для цього гарячого циклу, а клас додасть нам не потрібну накладну вартість підрахунку посилань.”

Borrowed / owned / inout — Конвенції аргументів Mojo, що визначають, чи читає функція значення без прийняття власності ( borrowed ), приймає власність ( owned ), або може мутувати значення викликача на місці ( inout ). “Позначте цей параметр inout замість owned — ми хочемо, щоб функція змінювала буфер виклику безпосередньо, а не брала на себе право власності і повертала новий.”

** MLIR (Multi- Level Intermediate Representation) ** — інфраструктура компілятора, на якій побудовано Mojo, що дозволяє створювати високооптимизований код для різних апаратних цілей, зокрема, для процесорів і графічних процесорів, з одного і того ж джерела. “Причина, чому цей цикл так добре векторизується, не є магією — це Mojo, що знижує до MLIR і дозволяє застосовувати ті ж оптимізаційні проходження, що використовуються для інших апаратних цілей.”

** SIMD type ** — вбудований векторний тип, що представляє декілька скалярних значень, які обробляються паралельно за допомогою однієї інструкції, відкритий безпосередньо у системі типів Mojo, а не прихований за бібліотекою. “Замість циклічного перетворення елемента на елемент, використовуйте тут тип SIMD, щоб компілятор міг виводити векторизовані інструкції безпосередньо, замість того, щоб покладатися на вгадування з автоматичної векторизації.”

** Абстракція нульової вартості ** — властивість мови (наприклад, структури Mojo або перевірки власника), яка не додає додаткових витрат часу виконання у порівнянні з написаним вручну низькорівневим кодом, з усіма безпекою або ергономічністю, що вимагається під час компіляції. “Перевірка меж тут є абстракцією з нульовою вартістю — вона повністю перевіряється під час компіляції, тому немає штрафу за час виконання порівняно з написанням небезпечної версії сирого вказівника вручну.”

Звичайні фрази

• «Чи є цей параметр запозиченим, власним або inout — і чи відповідає це тому, що функція насправді повинна робити?»
• Чи слід це бути структурою замість класу, враховуючи, що нам потрібна семантика цінностей?»
• Чи використовує цей цикл тип SIMD, або покладається на компілятор для автовекторизації?»
• Чи має ця абстракція будь-яку вартість за час виконання, або вона повністю розв’язується в часі компіляції?
• Чи є ця копія неявною через конвенцію про власність, або це необхідно?»

Приклади висловлювань

Перегляд запиту на звантаження: “Ця функція декларує параметр буфера як owned, але ніколи не має потреби зберігати його — перемикання на borrowed уникає небажаної копії при кожному виклику.”

Пояснення рішення про проектування: “Ми використовували структуру з методами inout для типу матриці замість класу, тому мутація на місці під час горячого шляху не виділяється або не викликає підрахунок посилань.”

Опис перемог у продуктивності: “Переписування внутрішньої петлі з явним типом SIMD замість скалярної петлі скоротило час виконання вдвічі, тому що компілятору більше не потрібно було вгадувати, чи векторизація була безпечною.”

Професійні поради

• Використовуйте **“борговано”, “власне”, ** і **“вхід” ** явно, коли обговорюєте підписи функцій — це ключові слова в Mojo, а не стилістичні вибори.
• Під час перегляду коду, що залежить від продуктивності, запитайте “це структура чи клас?” — відповідь визначає, чи ви отримуєте семантику значення і статичну відправку або посилання на семантику з надлишком.
• Використовуйте “абстракцію нульової вартості” точно — це означає, що немає витрат на час виконання порівняно з рукописним еквівалентом низького рівня, а не просто “ефективним”
• Розрізняти “SIMD type” (явний векторний тип у системі типів) від “auto-vectorization” (компілятор виводить векторизацію зі скалярного циклу) при обговоренні того, чому гарячий цикл швидкий або повільний.

Практичні вправи

1. Поясніть у двох реченнях, чому позначення параметра owned, коли borrowed буде достатньо, може погіршити продуктивність.
2. Написати коментар перегляду коду у одному реченні, у якому рекомендується використовувати структуру замість класу для типу, який має критичне значення для швидкодії.
3. Опишете, вашими словами, що означає « абстракція нульової вартості » у контексті перевірок власності Mojo.

«Перехідний період» (англ. Transition Period) — «Перехідний період» (англ. Transition Period)

Мойо зосереджений на створенні високопродуктивних, MLIR-заснованих систем, що означає, що розмови навколо якості коду і оптимізації є * критичним *. Просто сказати комусь “виправити це” недостатньо. Метою є отримання відповіді, яка демонструє розуміння основних технічних проблем, потенційних компромісів і запропонованих рішень - все це чітко повідомляється англійською мовою. Поширеним розчаруванням для носіїв мови, яка не є рідною, є відчуття, що їх внесок не повністю оцінюється, тому що зворотній зв’язок не має контексту або деталей. Це не про звинувачення; це про спільне вдосконалення.

Розглянемо сценарій: Сара, молодший розробник, надсилає PR, що містить оптимізацію, яка, на її думку, покращить затримку моделі. Головний інженер, Девід, залишає коментар, в якому пише: «Це потребує роботи». Хоча це технічно вірно, воно не надає ніякої корисної інформації. Сара может почувствовать себя обескураженной и неуверенной в том, как действовать дальше. Замість цього, Девід повинен намагатися зробити щось на зразок: «Зміни в ядрі compute_matrix_multiply показують перспективи в зменшенні затримки, особливо з векторізацією, яку ми додали. Однак, я хвилююся щодо можливих піків використання пам’ яті під час операцій з більшими матрицями — чи можете ви розглянути можливість додавання механізму кешування або профілювання цієї секції під час різних умов завантаження? Давайте обговоримо ваші аргументи і, якщо це буде необхідно, розглянемо альтернативні підходи. » Зауважте, що Девід розглядає це як * можливість * вивчити і вдосконалити оптимізацію, пропонуючи конкретні пропозиції щодо подальшого дослідження. Ключ змінюється з директиви (« виправити це ») на спільний запит на розуміння.

Крім того, точна термінологія стає неймовірно важливою при обговоренні перетворень MLIR і продуктивності. Використання фраз, таких як «покращити пропускну здатність» проти «зменшити затримку» має різні конотації і передбачає різні стратегії оптимізації. Аналогічно, розмови про власність на структури та управління пам’ яттю вимагають чіткого визначення таких поняттів, як «позичення» та «життя». Не припускайте, що ви знайомі з цими термінами – завжди пояснюйте їх у контексті обговорення. Сфокусуйтесь на тому, “чому” щось робиться, а не тільки на тому, “що” робиться.

Ось простий приклад, що використовує mlir для демонстрації цього:

# This demonstrates a basic MLIR transformation to specialize
# a matrix multiply kernel based on input dimensions.
use ::.MatMulOp;
use ::.AffineMap;
use ::.IntrinsicExpr;

let input_size = 16; // Example size, could be dynamic
let output_size = 32;
let map = AffineMap::create(input_size, output_size);  // Create a linear mapping
let specialized_kernel = IntrinsicExpr::create(map, MatMulOp::kTilingSize);

// This is a simplified representation - actual MLIR code would be much more complex.

Пам’ятайте, ефективне спілкування не тільки про використання правильного словника; це про створення культури конструктивного зворотнього зв’язку і спільного розуміння в межах вашої команди - такої, де нюансовані технічні обговорення заохочуються і цінуються.