Правила оформления работ

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

Работы должны удовлетворять следующим требованиям:

• Корректно обрабатывать ошибки при взаимодействии с внешним миром: ошибки ввода-вывода, некорректный пользовательский ввод и прочее. Если это произошло – необходимо вывести сообщение об ошибке (на английском языке) и завершить исполнение с ненулевым кодом возврата.

• Программа никогда не должна падать. Падение – признак ошибок в реализации.

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

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

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

При успешном выполнении программа возвращает код 0. Если же что-то пошло не так, то она сообщает о проблеме через ненулевой код возврата (exit code) и сообщение об ошибке в поток вывода ошибок. Если программа неожиданно завершается с "не вашим" кодом возврата, то полезную информацию о возможных причинах можно найти, например, на сайте.

Рекомендации и примечания

1. Массив массивов работает медленнее, чем двумерный массив или одномерный с индексацией как к двумерному.

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

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

4. Тестировать необходимо в Release, а не в Debug. Debug – компиляция с ключом оптимизации /Od (Visual C++) и -Od (clang, gcc/g++). Release – /O2 и -O2 соответственно.

Вместо объявления макросов в cl-файлах, их можно задавать в строке сборки аргументом clBuildProgram как preprocessor definition через ключ -D. Это также упрощает процесс тестирования и замеров времени для графиков.

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