Как создать, открыть и отправить на проверку вашу работу

Репозиторий и ветка

• Сделайте форк семестрового репозитория вашей группы (процессы/потоки, направление).

• Создайте ветку, имя которой точно совпадает с папкой вашей задачи: <фамилия>_<инициал>_<краткое> (например, nesterov_a_elem_vec_sum).

Предварительные требования

• Установите инструменты и зависимости (см. «Инструкция → Окружение»).

• Убедитесь, что вы можете сконфигурировать и собрать проект локально с помощью CMake.

• Если вы работаете из форка, клонируйте свой форк и добавьте основной репозиторий курса как upstream.

Структура папки задачи (единая)

Создайте папку tasks/<фамилия>_<инициал>_<краткое>/ со следующей структурой:

• common/include/common.hpp — общие типы и BaseTask:

  using InType = int;        // example
  using OutType = int;       // example
  using TestType = std::tuple<int, std::string>; // if needed
  using BaseTask = ppc::task::Task<InType, OutType>;
  

• Реализации технологий (добавляйте только нужные в семестре): — Процессы (MPI/SEQ): seq/include, seq/src, mpi/include, mpi/src — Потоки: seq, omp, tbb, stl (аналогичное разделение include/src)

  Каждая реализация определяет класс, унаследованный от BaseTask, и переопределяет ValidationImpl, PreProcessingImpl, RunImpl, PostProcessingImpl. Также добавьте:

  static constexpr ppc::task::TypeOfTask GetStaticTypeOfTask() { return ppc::task::TypeOfTask::kMPI; }
  // or kSEQ/kOMP/kTBB/kSTL as appropriate
  

  Минимальный скелет (пример для SEQ):

  // seq/include/ops_seq.hpp
  #pragma once
  #include "<last>_<initial>_<short>/common/include/common.hpp"
  namespace <last>_<initial>_<short> {
  class MyTaskSEQ : public BaseTask {
   public:
    static constexpr ppc::task::TypeOfTask GetStaticTypeOfTask() { return ppc::task::TypeOfTask::kSEQ; }
    explicit MyTaskSEQ(const InType& in);
   private:
    bool ValidationImpl() override;
    bool PreProcessingImpl() override;
    bool RunImpl() override;
    bool PostProcessingImpl() override;
   };
  } // namespace <last>_<initial>_<short>
  

  // seq/src/ops_seq.cpp
  #include "<last>_<initial>_<short>/seq/include/ops_seq.hpp"
  namespace <last>_<initial>_<short> {
  MyTaskSEQ::MyTaskSEQ(const InType& /*in*/) : BaseTask(/*in*/ InType{}) {}
  bool MyTaskSEQ::ValidationImpl() { return true; }
  bool MyTaskSEQ::PreProcessingImpl() { return true; }
  bool MyTaskSEQ::RunImpl() { /* compute */ return true; }
  bool MyTaskSEQ::PostProcessingImpl() { /* write result */ return true; }
  } // namespace <last>_<initial>_<short>
  

• Тесты (единое размещение): — tests/functional/main.cpp — функциональные тесты на базе ppc::util::BaseRunFuncTests и вспомогательных функций. — tests/performance/main.cpp — тесты производительности на базе ppc::util::BaseRunPerfTests + MakeAllPerfTasks.

Пример функциональных тестов:

const auto kTasks = std::tuple_cat(
  ppc::util::AddFuncTask<MyTaskMPI, InType>(params, PPC_SETTINGS_<task_id>),
  ppc::util::AddFuncTask<MyTaskSEQ, InType>(params, PPC_SETTINGS_<task_id>)
);
INSTANTIATE_TEST_SUITE_P(..., MyFuncTests, ppc::util::ExpandToValues(kTasks), ...);

При необходимости используйте PPC_ID_<task_id> для доступа к ресурсам из data/.

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

const auto kAllPerfTasks = ppc::util::MakeAllPerfTasks<InType, MyTaskMPI, MyTaskSEQ>(PPC_SETTINGS_<task_id>);
INSTANTIATE_TEST_SUITE_P(..., MyPerfTests, ppc::util::TupleToGTestValues(kAllPerfTasks), ...);

Советы по тестам

• Делайте тесты детерминированными и укладывающимися в лимиты времени; используйте переменные окружения (см. «Инструкция → Переменные окружения») вместо задержек.

• Используйте PPC_ID_<task_id> для доступа к файлам из data/.

• Покрывайте крайние случаи в функциональных тестах; добавьте ровно два стиля перфтестов (task и pipeline) внутри набора.

• data/ — опциональные входные файлы для тестов (например, изображения).

• settings.json — включение необходимых технологий для вашего семестра, например:

  { "tasks_type": "processes", "tasks": { "mpi": "enabled", "seq": "enabled" } }
  

• info.json — данные студента для автоматизации (scoreboard, макросы):

  { "student": { "first_name": "Имя", "last_name": "Фамилия", "middle_name": "Отчество", "group_number": "Группа", "task_number": "1" } }
  

Сборка и локальный запуск

• Конфигурация и сборка:

  cmake -S . -B build -DENABLE_ADDRESS_SANITIZER=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo
  cmake --build build -j
  

• Запуск тестов через вспомогательный скрипт:

  export PPC_NUM_THREADS=4
  export PPC_NUM_PROC=2
  python3 scripts/run_tests.py --running-type threads --counts 1 2 4
  python3 scripts/run_tests.py --running-type processes --counts 2 4
  python3 scripts/run_tests.py --running-type performance
  

Исполняемые файлы (где искать тесты)

• Исполняемые файлы генерируются в build/bin (или install/bin при установке): - core_func_tests — тесты ядра библиотеки - ppc_func_tests — функциональные тесты для всех задач/технологий - ppc_perf_tests — тесты производительности для всех задач/технологий

Runner автоматически применяет gtest‑фильтры для выбора наборов тестов по технологиям.

Pull Request

• Формат заголовка (пример):

  <Фамилия Имя>. Технология <SEQ/MPI/...>. <Название задачи>. Вариант <N>.

• Описание должно включать: — Полное описание задачи; номер варианта; используемую технологию — Краткое описание реализации и отчёта — Чек‑лист (CI зелёный в форке, clang‑format/clang‑tidy пройдены, функциональные/перф‑тесты ок, ветка названа как директория задачи, достоверность сведений).

Шаблон PR (чек‑лист)

## Description
- Task: <Full task name>
- Variant: <N>
- Technology: <SEQ | MPI | OMP | TBB | STL | ALL>
- Summary: Brief description of your implementation and report

---

## Checklist
- [ ] CI is green in my fork (build, tests, docs)
- [ ] Task folder is named `<last>_<initial>_<short>` and matches branch name
- [ ] clang-format passed locally
- [ ] clang-tidy passed locally (no warnings/errors introduced)
- [ ] Functional tests pass locally
- [ ] Performance tests pass locally
- [ ] Report (`report.md`) is added and follows the template
- [ ] I confirm that provided information is truthful

Частые ошибки (прочтите перед отправкой)

• Неверное имя папки/ветки. Должно быть <фамилия>_<инициал>_<краткое> везде.

• Отсутствует или неверное значение GetStaticTypeOfTask для технологии.

• Тесты зависят от случайности или задержек вместо лимитов по времени окружения.

• В settings.json не включена нужная технология — тесты не запустятся.

• Namespace не соответствует имени папки и конфликтует с другими.

• Количество или именование перфтестов отклоняется от требуемых шаблонов.

Полезные примеры для ориентирования

• Процессы: tasks/example_processes, tasks/example_processes_2, tasks/example_processes_3

• Потоки: tasks/example_threads

• Работайте из своего форка в отдельной ветке (не master). Имя ветки должно совпадать с именем папки задачи.

Примечания

• Все классы должны находиться в уникальном пространстве имён (например, <фамилия>_<инициал>_<краткое>).

• Делайте тесты детерминированными и укладывающимися в лимиты времени; используйте переменные окружения вместо задержек.

• Соблюдайте стиль кода (clang-format/clang-tidy) и запускайте pre-commit локально.