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

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

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

** fn проти def ** — fn декларує строгу, статично типовану функцію, яка вимагає типів аргументів і власника, в той час як def декларує сумісну з Python функцію з динамічним типуванням. “Ми переписали гарячу внутрішню петлю як функцію fn, щоб компілятор міг захопити невідповідність типів, яку def мовчки дозволяв.”

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

** Struct ** — тип значення з фіксованим, відомим компілятору розкладом, який використовується для даних, що мають критичне значення для швидкодії, замість динамічного класу у стилі Python.

• “Ми перенесли це з класу Python до структури Mojo, тому що нам потрібна гарантована пам’ ять для операцій SIMD вниз по течії.” *

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

** Python interop ** — можливість Mojo імпортувати і викликати існуючі Python модулі безпосередньо, дозволяючи командам мігрувати поступово, а не переписувати все зразу. “Ми не переписуємо весь конвейєр даних в Mojo — ми використовуємо Python interop, щоб зберегти існуючу передобробку NumPy і тільки переписуємо вузьке місце в рідному Mojo.”

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

• Чи є ця функція fn або def — чи вона потребує строгого типування, чи є динамічна поведінка навмисною тут?
• Чи повинен цей параметр бути borrowed замість owned, оскільки ми тільки читаємо його?
• «Чи це структура, тому що нам потрібен фіксований макет пам’яті, або регулярне значення буде працювати добре?»
• Чи ми використовуємо тут SIMD-тип, чи це все ще скалярне і залишає продуктивність на столі?»
• Чи можемо ми покластися на Python interop для цієї частини, або чи потрібно мати рідне Mojo для швидкості?»

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

Пояснення вибору власника у перегляді:

• “Я змінив цей параметр на inout, оскільки функції потрібно змінити буфер на місці, а не просто прочитати з нього.” *

Опис стратегії міграції: “Ми зберігаємо логіку оркестрації в Python і переносимо лише числове ядро на Mojo, використовуючи interop для з’ єднання обох.”

Обґрунтування рішення щодо швидкодії:

• “Перехід з класу Python на структуру Mojo з фіксованою компонуванням дозволяє компілятору автоматично векторизувати петлю.” *

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

• Зазначте, чи є код ** fn ** або ** def ** явно, коли обговорюється помилка типу — це змінює те, що компілятор може припустити.
• Назва точної ** ownership ** анотації ( owned, borrowed, inout ) при перегляді підпису функції — вона повідомляє про намір, що “приймає значення” не робить.
• Обґрунтуйте ** struct ** над класом Python, назвавши конкретні вимоги до продуктивності або макету, а не просто « це швидше »
• Впровадження Python interop як інкрементальної стратегії міграції у пропозиціях — це зменшує сприйнятий ризик прийняття новітньої мови.

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

1. Поясніть різницю між fn і def в Mojo.
2. Описати, коли ви б обрали borrowed замість owned для параметра функції.
3. Напишіть речення, яке обґрунтовує послідовну міграцію за допомогою Python interop.

Навигація по лінії — практичний підхід

Дизайн Mojo, особливо його акцент на власності і одночасності, може призвести до деяких дуже специфічних технічних дискусій. Це не просто про те, що ви створюєте; це про те, як ви повідомляєте про це, особливо при отриманні відгуків. Як розробник Mojo, ви витратите значну кількість часу на обговорення наслідків вашого вибору дизайну через письмове спілкування - запити на витягування, перегляд коду, гілки Slack і документацію. Освоєння цього способу спілкування має вирішальне значення для співпраці і забезпечення того, щоб ваша робота відповідала цілям команди. Поширеним камінням спотикання для носіїв англійської мови, які не є рідними, є переклад технічних концепцій на ясну, точну мову. Легко повернутись до надмірно формального вимови або використовувати жаргон без повного пояснення його контексту.

Розглянемо такий сценарій: ви надіслали запит на витягнення, який вводить нову операцію з вектором SIMD. Під час перегляду коду старший інженер залишає коментар, в якому говорить: «Це виглядає добре в ізоляції, але я хвилююся про потенційні перегони даних, якщо це не буде належним чином синхронізовано з існуючою системою управління пам’ яттю». Проста, пряма відповідь може бути: «Я розумію вашу занепокоєність щодо умов перегонів. Я додав явне блокування навколо операції SIMD, щоб запобігти одночасному доступу і забезпечити безпеку потоку. “Проте, це функціональний опис; він не повністю відповідає на питання * чому * блокування було необхідним або як ви перевірили його ефективність. Більш надійною відповіддю було б: «Дякую за те, що ви це позначили — це важлива розмова з SIMD операціями. Ми реалізували mutexes для серіалізації доступу до векторних даних, забезпечуючи, що тільки один потік може змінювати їх у будь- який момент часу. Ми також додали тести на одиницю, які спеціально спрямовані на потенційні умови гонки, використовуючи ThreadSanitizer, щоб підтвердити його ефективність.”Зауважте зміну тону - визнання зворотнього зв’язку, пояснення обґрунтування вашого рішення і демонстрація того, що ви зробили проактивні кроки для зменшення ризику.

Інша поширена ситуація виникає під час описів PR. При запропонуванні змін, пов’ язаних з співпрацездатністю Python, чіткість є найважливішою. Слабким описом може бути: « Виправляє проблеми взаємодії Python ». Сильнішим описом буде: « Цей PR вирішує проблеми з перервами під час виклику функцій Python з Mojo через невідповідності типів у структурах даних. » Зокрема, ми реалізували явне відтворення, використовуючи cast<py::object>, де це необхідно, щоб забезпечити сумісність між моделлю власності Mojo і динамічним типуванням Python. Цей файл розв’ язує повідомлену ваду [Видалення # 123] і містить поліпшене ведення журналу для зневадження майбутніх проблем з взаємодією. » Докладні описи не лише переказують технічні подробиці, але також надають контекст, що дозволяє рецензентам швидко зрозуміти обсяг зміни і її потенційний вплив.

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

// Example: Using ThreadSanitizer to detect race conditions in Mojo code
#include <thread>
#include <vector>

int main() {
  std::vector<int> data(10);
  for (int i = 0; i < 10; ++i) {
    data[i] = i;
  }

  // Simulate a race condition using multiple threads
  std::thread t1([&]() {
    for (int i = 0; i < 5; ++i) {
      data[i] += 1;
    }
  });
  std::thread t2([&]() {
    for (int i = 5; i < 10; ++i) {
      data[i] += 1;
    }
  });

  t1.join();
  t2.join();

  // Run ThreadSanitizer to detect race conditions
  // This would typically be invoked via the command line:
  // threadsanitizer ./your_mojo_executable
}