Bug 52969 - hpl: использование -Ofast приводит к неработоспособности теста
Summary: hpl: использование -Ofast приводит к неработоспособности теста
Status: REOPENED
Alias: None
Product: Sisyphus
Classification: Development
Component: hpl (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P5 normal
Assignee: Andrew Savchenko
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-07 12:29 MSK by Nikolay Strelkov
Modified: 2025-02-19 13:18 MSK (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolay Strelkov 2025-02-07 12:29:16 MSK
В spec-файле явно задан ключ -Ofast, который передается компилятору одновременно с -O2.
Это приводит неработоспособности теста.

Ключ -Ofast следует убрать.
Comment 1 Repository Robot 2025-02-07 21:45:42 MSK
hpl-2.3-alt3 -> sisyphus:

 Fri Feb 07 2025 Nikolay Strelkov <snk@altlinux> 2.3-alt3
 - Removed -Ofast as conflicting with -O2 (closes: #52969).
Comment 2 Andrew Savchenko 2025-02-10 12:29:43 MSK
(Ответ для Nikolay Strelkov на комментарий #0)
> В spec-файле явно задан ключ -Ofast, который передается компилятору
> одновременно с -O2.
> Это приводит неработоспособности теста.
> 
> Ключ -Ofast следует убрать.

1) Вы не понимаете, как работают комбинации флагов -O в gcc. Читайте man gcc, в частности:

If you use multiple -O options, with or without level numbers, the last such option is the one that is effective.

2) -Ofast действительно может ломать пакеты. Но HPL сделан для конкретной задачи перемножения матриц, где этого быть не должно. Так что разбирайтесь с тестом или версией компилятора. Никакой информации об ошибке Вы не предоставили.

3) Вы нарушили политику NMU:
https://www.altlinux.org/NMU

В нарушение официально действующей политики Вы без понимания происходящего (см. п.1 и 2) внесли изменение в чужой пакет не дождавшись реакции мейнтенера менее чем за 10 часов.

Даже для блокера (которым этот баг не является) политикой установлено ожидание 12 часов. Вам следовало ожидать хотя бы 2 недели.

При сохранении проблемы в hpl, оформляйте баг надлежащим образом и следуйте действующим политикам.

Попрошу Вас в дальнейшем воздерживаться от актов вандализма.

А пока что я откатываю дважды некорректное изменение (непонимание взаимодействия нескольких -O* и нарушение NMU).
Comment 3 Nikolay Strelkov 2025-02-10 13:17:03 MSK
За нарушение NMU прошу прощения, не разобрался, хотел помочь, примите мои искренние извинения!

По поводу -Ofast посмотрите, пожалуйста, лог сборки, иницированной Вами - https://git.altlinux.org/tasks/archive/done/_353/361890/build/300/x86_64/log . Там присутствует оба ключа -O2 и -Ofast - см. например строку

[00:00:05] + CFLAGS='-pipe -frecord-gcc-switches -Wall -g -O2 -flto=auto -ffat-lto-
objects -Ofast'

Как гентушник с большим 20-летним стажем я могу сказать, что НИКОГДА такого сочетания не видел. Обычно в продакшене ставят просто -O2 (см., например https://wiki.gentoo.org/wiki/Safe_CFLAGS#Alder_Lake ).

Пакет, собранный Вами в старом задании 361890 на мой взгляд все-таки был сломан - тест просто виснет реальном железе с полностью обновленной регуляркой на Intel i7-11700 и AMD Ryzen 5700G при вызове с помощью команд ниже (стандартный тест LINPACK для матрицы 10000x10000, часто применямый тестировщиками, и под Windows с помощью LinX): 

```
cat << EOF > HPL.dat
HPLinpack benchmark input file
Innovative Computing Laboratory, University of Tennessee
HPL.out      output file name (if any)
6            device out (6=stdout,7=stderr,file)
1            # of problems sizes (N)
10000        Ns
1            # of NBs
128          NBs
0            PMAP process mapping (0=Row-,1=Column-major)
1            # of process grids (P x Q)
1            Ps
1            Qs
16.0         threshold
1            # of panel fact
2            PFACTs (0=left, 1=Crout, 2=Right)
1            # of recursive stopping criterium
4            NBMINs (>= 1)
1            # of panels in recursion
2            NDIVs
1            # of recursive panel fact.
1            RFACTs (0=left, 1=Crout, 2=Right)
1            # of broadcast
1            BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM)
1            # of lookahead depth
1            DEPTHs (>=0)
0            SWAP (0=bin-exch,1=long,2=mix)
1            swapping threshold
1            L1 in (0=transposed,1=no-transposed) form
1            U  in (0=transposed,1=no-transposed) form
0            Equilibration (0=no,1=yes)
8            memory alignment in double (> 0)
EOF

/usr/lib64/openmpi/bin/mpirun -np 8 xhpl
```

на момент 7 февраля дальше строки вывода не было. При использовании эталонного файла /usr/share/doc/hpl-2.3/HPL.dat поведение такое же.
Отсюда я сделал вывод о некорректности одновременного применения -O2 и -Ofast.
Возникли вопросы как именно тестировался пакет перед публикацией версии 2.3-alt2 - на каком железе, с каким файлов конфигурации, .

А вот пакет пересобранный мной в задании 373476 только с -O2 (см. https://git.altlinux.org/tasks/archive/done/_364/373476/build/200/x86_64/log ), благополучно проходит тест и дает адекватную для моего Ryzen 5700G цифру 214 GFlops:

```
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR11C2R4       10000   128     1     1               3.12             2.1357e+02
HPL_pdgesv() start time Mon Feb 10 13:06:31 2025

HPL_pdgesv() end time   Mon Feb 10 13:06:34 2025

--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=   2.58159057e-03 ...... PASSED

```

которая очень даже близка к Gentoo c -O2, где получилось 218 GFlops. Добавление -O3 при -march=znver3 в Gentoo дает 241 GFlops, прирост минимален.

Протестируйте, пожалуйста, указанным выше способом современное задание https://git.altlinux.org/tasks/374200/ , возможно -Ofast и не виноват и у Вас все нормально заработает :) ...
Comment 4 Nikolay Strelkov 2025-02-11 22:44:09 MSK
Для информации: обновление пакета hpl до 2.3-alt4 версии не решило проблему, тест по прежнему виснет (процедура описана в комментарии #3). 
Проверил дополнительно на i7-740QM и i5-1155G7. 
Открываю баг-репорт обратно, готов помочь с тестированием, больше никуда не спешу.
Comment 5 Andrew Savchenko 2025-02-19 13:18:58 MSK
(Ответ для Nikolay Strelkov на комментарий #3)
> Как гентушник с большим 20-летним стажем я могу сказать, что НИКОГДА такого
> сочетания не видел. Обычно в продакшене ставят просто -O2 (см., например
> https://wiki.gentoo.org/wiki/Safe_CFLAGS#Alder_Lake ).

Вы разговариваете с гентушником с 18-летним стажем, который 10 лет официально являлся разработчиком Gentoo :)

Как опытный гентушник, Вы должны знать, что последний флаг -O перебивает все ранее указанные, что и подтверждается ранее приведённой цитатой из man gcc.

Вы просто нашли баг при сборке с -Ofast и именно с этим нужно разбираться. На момент добавления пакета на моей машине всё работало. Тесты при сборке пакета я не делал, чтоб не перегружать сборочницу.
 

> Отсюда я сделал вывод о некорректности одновременного применения -O2 и
> -Ofast.

Это неверный вывод. Слом даёт именно -Ofast безотносительно указания -O2, т.к. -Ofast эквивалентен -O3 с несколькими дополнительными флагами, а -O3 включает в себя -O2 + доп. флаги (см. man gcc). Вообще, любая -O* — это просто удобный алиас для конкретного набора флагов, который часто зависит от версии компилятора, а иногда и от архитектуры.

Вы можете помочь, определив какой именно флаг (или их комбинация) ломают hpl. Я бы начал с проверки -O3, раз она заработал на том же железе в Gentoo (но компиляторы в Alt и Gentoo различаются, поэтому нельзя автоматически переносить суждение о работоспособности опции из одной системы в другую).

Если с -O3 всё хорошо, то медом дихотомии несложно будет найти виновника в опциях -Ofast, которые идут поверх -O3. Их там совсем немного.