Тестирование, рефакторинги, оптимизации и исправления после ВКР

[Mazdaywik]

Только что завершились две выпускные квалификационные работы:

• @Apakhov, реализовавший построение ациклического графа суперкомпиляции путём задержки рекурсивных вызовов (Прогонка, которая не зацикливается #340),
• @VladisP, реализовавший Расширенный алгоритм обобщённого сопоставления #322 и Специализация без шаблона #251.

Эти расширения станут основным новшеством версии 3.4. Однако, прямо сейчас создавать новую версию преждевременно по следующим причинам.

1. @Apakhov и @VladisP намеренно работали с очень ограниченным объёмом кода (в смысле, я ограничил их работу). Работа @Apakhov’а была ограничена файлом OptTree-Drive-Expr.ref, работа @VladisP’а — файлами GenericMatch.ref и OptTree-Spec.ref. Однако, полноценная реализация новых функций требует изменения куда большего объёма кода (например, скрипта в OptTree.ref).

   Ограниченность поля для работы @Apakhov’а и @VladisP’а была намеренной, т.к. этого было достаточно для выполнения содержательной части задачи.

2. Ациклическая прогонка @Apakhov’а делает ненужной авторазметку прогоняемых функций в том виде, в каком она сейчас есть. Исходно разметка была призвана не допускать пометки $DRIVE для рекурсивных функций. Сейчас рекурсивные функции могут иметь метку $DRIVE, их прогонка не зациклится.

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

4. Да, авторазметка для специализации тоже становится ненужной.

5. Основные компоненты для Универсальная древесная оптимизация $OPT #314 уже реализованы (#251, #322, #340). Фактически в Универсальная древесная оптимизация $OPT #314 нужно реализовать поддержку псевдокомментариев так, как она описана (и в следующем релизе удалить старый синтаксис).

6. Написанный студентами код может быть неоптимальным, т.к. у них нет опыта в оптимизации Рефала.

7. Новые оптимизации работают глубже, из-за чего могут выявиться проблемы в других частях системы. В частности, обостряются проблемы с раздуванием программ (Древесные оптимизации раздувают программы #332). На данный момент проблема купирована в 54c28cad9921556d208bc43dc88f55943d7885cb.

8. Хотя все автотесты выполнились, включая и случайные, тестовое покрытие, выполненное студентами неполное. Требуется более тщательное тестирование.

9. Автотесты проверяют корректность. Содержательную сторону нужно тестировать вручную.

10. Даже если обе оптимизации в отдельных ветках работали порознь, при работе вместе возможны проблемы.

11. Можно удалить ObjectMatch.ref, т.к. новый алгоритм сопоставления покрывает этот случай.

---

В первую очередь нужно

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

[Mazdaywik]

Самоприменение в режиме

set RLMAKE_FLAGS=-X-OiDPRS

прошло успешно. После самоприменения был сделан повторный запуск с ключами

set RLMAKE_FLAGS=-X-OiDS

и включённым профилированием. Профиль показал следующее:

Total time: 1590.76500 s
Total semisteps (function calls and closure unwraps): 782471744
Mean semistep time: 2.033000 us

PartiallyContainsSignature (0367) -> 146585.0 ms (9.21 %, += 9.21 %)                  rel step time 1.37
PartiallyContainsSignature$1?1 (0367) -> 131388.0 ms (8.26 %, += 17.47 %)              rel step time 1.22
PartiallyContainsSignature$2?2 (0367) -> 114076.0 ms (7.17 %, += 24.65 %)              rel step time 1.33
PartiallyContainsSignature$2?1 (0367) -> 95709.0 ms (6.02 %, += 30.66 %)              rel step time 1.11
ContainsSignature (0367) -> 91398.0 ms (5.75 %, += 36.41 %)                           rel step time 0.84
DoCheckExprPairForRelation$1?1 (0367) -> 63350.0 ms (3.98 %, += 40.39 %)              rel step time 2.94
DoCheckExprPairForRelation (0367) -> 63010.0 ms (3.96 %, += 44.35 %)                  rel step time 2.93
DoCheckExprPairForRelation$2?1 (0367) -> 62720.0 ms (3.94 %, += 48.29 %)              rel step time 2.92
Solve-Clashes (5826) -> 59211.0 ms (3.72 %, += 52.02 %)                               rel step time 5.00
GrowDriveTree:1@2 (5699) -> 37907.0 ms (2.38 %, += 54.40 %)                           rel step time 164.09
ApplyContraction-toExpr (5826) -> 33363.0 ms (2.10 %, += 56.50 %)                     rel step time 0.97
PartiallyContainsSignature$2?3 (0367) -> 33064.0 ms (2.08 %, += 58.57 %)              rel step time 0.51
ExtractVariables-Expr (0000) -> 17419.0 ms (1.10 %, += 59.67 %)                       rel step time 0.53
OutlineStrings (1650) -> 17047.0 ms (1.07 %, += 60.74 %)                              rel step time 4.37
ContainsSignature$5:1@1 (0367) -> 15771.0 ms (0.99 %, += 61.73 %)                     rel step time 0.75
GrowDriveTree (5699) -> 13744.0 ms (0.86 %, += 62.60 %)                               rel step time 59.49
ContainsSignature$5?1 (0367) -> 12505.0 ms (0.79 %, += 63.38 %)                       rel step time 0.59

(полный профиль: _profile_count.txt, _profile_time.txt)

ПОЛОВИНУ времени занимает проверка отношения Хигмана-Крускала! Значит, её надо переписывать.

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

[Mazdaywik]

Отношение Хигмана-Крускала оптимизировано:

Total time: 575.85900 s
Total semisteps (function calls and closure unwraps): 346857543
Mean semistep time: 1.660218 us

Solve-Clashes (5826) -> 54201.0 ms (9.41 %, += 9.41 %)                               rel step time 6.08
ApplyContraction-toExpr (5826) -> 31204.0 ms (5.42 %, += 14.83 %)                     rel step time 1.21
GrowDriveTree:1@2 (9075) -> 21601.0 ms (3.75 %, += 18.58 %)                           rel step time 145.19
OutlineStrings (3824) -> 15424.0 ms (2.68 %, += 21.26 %)                              rel step time 6.89
ExtractVariables-Expr (0000) -> 15149.0 ms (2.63 %, += 23.89 %)                       rel step time 0.67
GrowDriveTree (9075) -> 10161.0 ms (1.76 %, += 25.66 %)                               rel step time 68.30
IsTerm (5826) -> 9246.0 ms (1.61 %, += 27.26 %)                                      rel step time 0.67
ClearCoordinates (5826) -> 8940.0 ms (1.55 %, += 28.81 %)                            rel step time 0.70
SimplifyCoordinates-Expr (5826) -> 8666.0 ms (1.50 %, += 30.32 %)                    rel step time 0.83
IsSVarSubset (5826) -> 8604.0 ms (1.49 %, += 31.81 %)                                rel step time 0.63
SimplifyCoordinates-Expr-Inner (5826) -> 8362.0 ms (1.45 %, += 33.26 %)              rel step time 1.15
Add (0000) -> 7619.0 ms (1.32 %, += 34.59 %)                                         rel step time 0.70
Map@11 (5826) -> 7562.0 ms (1.31 %, += 35.90 %)                                      rel step time 0.75
Solve-Clashes$2?1 (5826) -> 6453.0 ms (1.12 %, += 37.02 %)                           rel step time 1.24
Solve-Clashes$3?1 (5826) -> 6341.0 ms (1.10 %, += 38.12 %)                           rel step time 1.23
DoGenSubst (2951) -> 6086.0 ms (1.06 %, += 39.18 %)                                  rel step time 14.52
Solve-Clashes$1?1 (5826) -> 5570.0 ms (0.97 %, += 40.15 %)                           rel step time 1.06
Solve-Clashes$1?2 (5826) -> 5473.0 ms (0.95 %, += 41.10 %)                           rel step time 1.74
Solve-Clashes$5?1 (5826) -> 5432.0 ms (0.94 %, += 42.04 %)                           rel step time 1.36
Solve-Clashes$8?1 (5826) -> 5307.0 ms (0.92 %, += 42.96 %)                           rel step time 1.33
Solve-Clashes$4?1 (5826) -> 5158.0 ms (0.90 %, += 43.86 %)                           rel step time 1.29
__Step-Drop (0000) -> 5137.0 ms (0.89 %, += 44.75 %)                                 rel step time 0.26
Unique (0000) -> 5100.0 ms (0.89 %, += 45.64 %)                                      rel step time 1.29
Solve-Clashes$9?1 (5826) -> 4938.0 ms (0.86 %, += 46.49 %)                           rel step time 1.24
Solve-Clashes$12?1 (5826) -> 4842.0 ms (0.84 %, += 47.33 %)                          rel step time 1.22
Solve-Clashes$13?1 (5826) -> 4787.0 ms (0.83 %, += 48.17 %)                          rel step time 1.21
Solve-Clashes$6?1 (5826) -> 4781.0 ms (0.83 %, += 49.00 %)                           rel step time 1.20
DoAddCoordinateLabels (5826) -> 4680.0 ms (0.81 %, += 49.81 %)                       rel step time 0.80
Solve-Clashes$7?1 (5826) -> 4625.0 ms (0.80 %, += 50.61 %)                           rel step time 1.16
Map@12 (5826) -> 4524.0 ms (0.79 %, += 51.40 %)                                      rel step time 0.68
CheckHKRelation (6259) -> 4344.0 ms (0.75 %, += 52.15 %)                             rel step time 2.42
…

(полный профиль: _profile_count.txt, _profile_time.txt)

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

Кроме того, на третьей и шестой строке находится GrowDriveTree, которую оптимизировать несложно (там есть потери, и соответственно, копирования переменных).

Значит, нужно думать, как оптимизировать сопоставление с образцом и GrowDriveTree.