Numpy: регрессионные тесты polyfit и eig терпят неудачу после обновления Windows 10 до 2004 г.

Изменить: вы, очевидно, используете pip. У меня также был странный результат в Windows AMD64 в недавнем прошлом с библиотеками линейной алгебры и разложением собственных значений (в контексте запуска тестов для статистических моделей).

Если у вас есть время, попробуйте использовать 32-битный Python и pip и посмотрите, возникнут ли у вас те же проблемы? Я не видел их в 32-битных окнах, но они повторялись в 64-битных окнах.

Если я использую conda, которая поставляет MKL, у меня нет ошибок.

Изменить: я также вижу их при использовании NumPy 1.18.5 в Windows AMD64.

тесты не проходят после последнего обновления Windows 10

Были ли тесты до обновления не пройдены?

Нет @charris , перед обновлением набор тестов просто проходит.

@speixoto Вы знаете, какое именно обновление было? Мне было бы интересно узнать, решит ли он мою проблему с установленными колесами.

Обновление 1809 (10.0.17763) не приводило к провалу теста

1909 год тоже ничего не вызывал. Это началось только с 2004 года.

Я не уверен на 100%, что это 2004 год или что-то после него. Думаю, 2004 год сработал.

FWIW Я не могу воспроизвести эти сбои на CI (Azure или appveyor), но я делаю это локально на двух машинах, которые являются AMD64 и обновлены в 2004 году.

Кто-нибудь из вас пытался проверить, есть ли у вас их на 32-битном Python?

Похоже, что с обновлением 2004 года сообщалось о ряде проблем. Может быть, и об этом нужно сообщить?

Я только что запустил следующее при новой установке 1909 и 2004 годов:

pip install numpy scipy pandas pytest cython
git clone https://github.com/statsmodels/statsmodels.git
cd statsmodels
pip install -e . --no-bulid-isolation
pytest statsmodels

На 1909 г. провалов не было. В 2004 г. 30 отказов были связаны с функциями линейной алгебры.

Когда я запускаю тесты в 2004 году в отладчике, я замечаю, что первый вызов функции часто возвращает неправильный результат, но повторный вызов дает правильный результат (который остается правильным при повторном вызове). Не уверен, что это полезная информация, чтобы угадать причину.

У более ранних версий NumPy тоже есть проблемы? Я предполагаю, что вы используете 1.19.0.

Используя pip + 1.18.4 и scipy 1.4.1, я получаю тот же набор ошибок.

Это действительно распространенные:

ERROR statsmodels/graphics/tests/test_gofplots.py::TestProbPlotLongely::test_ppplot - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/graphics/tests/test_gofplots.py::TestProbPlotLongely::test_qqplot_other_array - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/graphics/tests/test_gofplots.py::TestProbPlotLongely::test_probplot - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/graphics/tests/test_regressionplots.py::TestPlot::test_plot_leverage_resid2 - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_params - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_scale - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_ess - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_mse_total - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_bic - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_norm_resids - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_HC2_errors - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_missing - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_norm_resid_zero_variance - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/tsa/tests/test_stattools.py::TestADFConstant::test_teststat - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/tsa/tests/test_stattools.py::TestADFConstant::test_pvalue - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/tsa/tests/test_stattools.py::TestADFConstant::test_critvalues - numpy.linalg.LinAlgError: SVD did not converge

Когда я использую 1.18.5 + MKL, я не получаю ошибок. Трудно сказать, ошибка ли это, вероятно, OpenBLAS или ошибка Windows. Вероятно, последнее, но до него будет действительно сложно добраться, а диагностика выходит за рамки моих возможностей для низкоуровневой отладки.

На той же физической машине, когда я запускаю Ubuntu с использованием пакетов pip, я не вижу никаких ошибок.

Это самое странное поведение. Не работает при первом вызове, работает при втором и последующих. Еще одно сложное для понимания поведение состоит в том, что если я провожу неудачный тест изолированно, я не вижу ошибки.

И последнее обновление: если я тестирую исходную сборку NumPy без оптимизированного BLAS, я все равно вижу ошибки, хотя они не идентичны.

Может, стоит пинговать разработчиков OpenBLAS. Это происходит с float32 так же часто, как с float64?

Когда я запускаю полный тест NumPy 1.19.0, python -c "import numpy;numpy.test('full')" я вижу те же ошибки, что и выше:

FAILED Python/Python38/Lib/site-packages/numpy/lib/tests/test_regression.py::TestRegression::test_polyfit_build - numpy.linalg.LinAlgError: SVD did not conv...
FAILED Python/Python38/Lib/site-packages/numpy/linalg/tests/test_regression.py::TestRegression::test_eig_build - numpy.linalg.LinAlgError: Eigenvalues did n...
FAILED Python/Python38/Lib/site-packages/numpy/ma/tests/test_extras.py::TestPolynomial::test_polyfit - numpy.linalg.LinAlgError: SVD did not converge in Lin...

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

Я подал заявку в Microsoft единственным известным мне способом:

https://aka.ms/AA8xe7q

Публикация на случай, если другие найдут это через поиск:

Пользователи Windows должны использовать Conda / MKL, если в 2004 году, пока проблема не будет решена.

Вот небольшой пример воспроизведения:

import numpy as np
a = np.arange(13 * 13, dtype=np.float64)
a.shape = (13, 13)
a = a % 17
va, ve = np.linalg.eig(a)

Производит

 ** On entry to DGEBAL parameter number  3 had an illegal value
 ** On entry to DGEHRD  parameter number  2 had an illegal value
 ** On entry to DORGHR DORGQR parameter number  2 had an illegal value
 ** On entry to DHSEQR parameter number  4 had an illegal value
---------------------------------------------------------------------------
LinAlgError                               Traceback (most recent call last)
<ipython-input-11-bad305f0dfc7> in <module>
      3 a.shape = (13, 13)
      4 a = a % 17
----> 5 va, ve = np.linalg.eig(a)

<__array_function__ internals> in eig(*args, **kwargs)

c:\anaconda\envs\py-pip\lib\site-packages\numpy\linalg\linalg.py in eig(a)
   1322         _raise_linalgerror_eigenvalues_nonconvergence)
   1323     signature = 'D->DD' if isComplexType(t) else 'd->DD'
-> 1324     w, vt = _umath_linalg.eig(a, signature=signature, extobj=extobj)
   1325
   1326     if not isComplexType(t) and all(w.imag == 0.0):

c:\anaconda\envs\py-pip\lib\site-packages\numpy\linalg\linalg.py in _raise_linalgerror_eigenvalues_nonconvergence(err, flag)
     92
     93 def _raise_linalgerror_eigenvalues_nonconvergence(err, flag):
---> 94     raise LinAlgError("Eigenvalues did not converge")
     95
     96 def _raise_linalgerror_svd_nonconvergence(err, flag):

LinAlgError: Eigenvalues did not converge

LAPACK считает от 0 или 1? Все недопустимые значения оказываются целыми числами:
ДГЕБАЛ
DGEHRD
DORGHR
DHSEQR

Это больше похоже на проблему OpenBlas (или что-то между 2004 и OpenBLAS). Вот мое резюме:

Только NumPy python -c "import numpy;numpy.test('full')"

• Нет оптимизированного BLAS: пройти полный
• OpenBLAS: Нормально полная
• MKL: пройти полный

statsmodels тестирование pytest statsmodels

• Pip NumPy и SciPy: Ошибка, связанная с кодом SVD и QR
• MKL NumPy и SciPy: пройти
• Нет оптимизированного BLAS: сбой , но меньше всего, что связано с scipy.linalg подпрограммами, которые используют OpenBLAS.
• Нет оптимизированного BLAS, нет SciPY linalg: Pass

Было бы неплохо узнать, что изменилось в 2004 году. Может нам нужен другой флаг при компиляции / линковке библиотеки?

_Если_ это ошибка OpenBLAS, маловероятно, что они ее заметили, поскольку ни один из CI на базе Windows не использует сборку 19041 (также известную как Windows 10 2004) или новее.

Чтобы было ясно, правда ли, что ни один из этих отчетов не затрагивает WSL?

Нет. Все с предоставленным conda python.exe или с предоставленным python.org python.exe

Не проходит ли тест, если переменная окружения OPENBLAS_CORETYPE=Haswell или OPENBLAS_CORETYPE=NEHALEM явно установлена?

Я пробовал Atom, SandyBridge, Haswell, Prescott и Nehalem, все с идентичными результатами.

Самое странное, что если ты бежишь

import numpy as np
a = np.arange(13 * 13, dtype=np.float64)
a.shape = (13, 13)
a = a % 17
va, ve = np.linalg.eig(a)  # This will raise, so manually run the next line
va, ve = np.linalg.eig(a)

второй (и любые последующие) вызовы eig завершаются успешно.

SciPy имеет аналогичную ошибку в

import numpy as np
import scipy.linalg
a = np.arange(13 * 13, dtype=np.float64)
a.shape = (13, 13)
a = a % 17
va, ve = scipy.linalg.eig(a) 

что поднимает

 ** On entry to DGEBAL parameter number  3 had an illegal value
 ** On entry to DGEHRD  parameter number  2 had an illegal value
 ** On entry to DORGHR DORGQR parameter number  2 had an illegal value
 ** On entry to DHSEQR parameter number  4 had an illegal value
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-58-8dfe8125dfe3> in <module>
      4 a.shape = (13, 13)
      5 a = a % 17
----> 6 va, ve = scipy.linalg.eig(a)

c:\anaconda\envs\py-pip\lib\site-packages\scipy\linalg\decomp.py in eig(a, b, left, right, overwrite_a, overwrite_b, check_finite, homogeneous_eigvals)
    245         w = _make_eigvals(w, None, homogeneous_eigvals)
    246
--> 247     _check_info(info, 'eig algorithm (geev)',
    248                 positive='did not converge (only eigenvalues '
    249                          'with order >= %d have converged)')

c:\anaconda\envs\py-pip\lib\site-packages\scipy\linalg\decomp.py in _check_info(info, driver, positive)
   1348     """Check info return value."""
   1349     if info < 0:
-> 1350         raise ValueError('illegal value in argument %d of internal %s'
   1351                          % (-info, driver))
   1352     if info > 0 and positive:

ValueError: illegal value in argument 4 of internal eig algorithm (geev)

Последнее замечание: преобразование в np.complex128 также повышает, а преобразование в np.float32 или np.complex64 работает без проблем.

Части кода Python, скомпилированные с длинными целыми числами, но OpenBLAS, построенный без INTERFACE64 = 1 в частях fortran (LAPACK)?
(Это все еще не объясняет, почему первый вызов терпит неудачу, но все последующие успешны, и почему он работал до обновления 19041)

Пользователи Windows 10 могут проголосовать за эту проблему в Центре отзывов Microsoft.

https://aka.ms/AA8xe7q

По запросу @bashtage я

преобразование в np.complex128 также увеличивается, в то время как преобразование в np.float32 или np.complex64 работают без проблем.

Первое предупреждающее сообщение (которое не появляется в случае успеха) «При входе в DGEBAL параметр номер 3 имел недопустимое значение» вызвано этим условием https://github.com/xianyi/OpenBLAS/blob/ce3651516f12079f3ca2418aa85b9ad571c3a391/lapack -netlib / SRC / dgebal.f # L336, что могло быть вызвано любым количеством предыдущих вычислений, переходящих к NaN.

Играя с этапами воспроизведения, я обнаружил, что выполнение мода как float32 "исправляет" это:

import numpy as np
a = np.arange(13 * 13, dtype=np.float64)
a.shape = (13, 13)
a = (a.astype(np.float32) % 17).astype(np.float64) # <-- only line changed
va, ve = np.linalg.eig(a)

Итак, я предполагаю, что в этом пути кода есть что-то, что правильно сбрасывает состояние, хотя я не уверен, что это такое. Надеюсь, кто-то, более знакомый с внутренним устройством numpy, может знать, где это могло происходить.

Это напоминает мне старую ошибку, которую мы видели с mingw в WIndows, когда конфигурация регистров с плавающей запятой не была унаследована рабочими потоками, что приводило к тому, что денормальные значения не сбрасывались до нуля и иногда приводили к сбоям в последующих вычислениях.
Не уверен, имеет ли это какое-либо отношение к текущей Windows на текущем оборудовании, но может быть интересно узнать, есть ли у вас
Сборка OpenBLAS была выполнена с CONSISTENT_FPCSR = 1 (или, если добавление этой опции сборки помогает).

@mattip Знаете ли вы, что CONSISTENT_FPCSR = 1 в сборке OpenBLAS?

К сожалению, похоже:

https://github.com/MacPython/openblas-libs/blob/444203b6dff90c2f0d2304fb3d85e1ac6db5c1e8/appveyor/build_openblas.sh#L68

Ну, по крайней мере, тогда это не мешает. в любом случае связь казалась довольно удаленной.

Привет! Я уже некоторое время сталкиваюсь с подобной проблемой, и все мои тесты указывают на что-то подозрительное между Windows 10 (2004) и OpenBlas. Обычно я запускаю свои программы на 3 ПК (2 рабочих станции с Windows 10 и более старый ноутбук с Windows 7). Мои скрипты python начали некорректно работать с ошибками, связанными с конвергенцией linalg и svd () примерно в то время, когда я обновил свои 2 рабочие станции до версии 2004 Windows 10. У меня также возникали сбои при первом запуске скрипта, но в большинстве случаев это работал со второй попытки (запуск ноутбуков Jupyter). На старом ноутбуке все те же программы выполнялись без ошибок! У меня miniconda, python 3.6, и все пакеты устанавливаются с помощью pip (env точно такой же на трех машинах).
Сегодня я удалил установку numpy (1.19.0) по умолчанию и установил версию numpy + mkl (numpy-1.19.1 + mkl-cp36-cp36m-win_amd64.whl) с https://www.lfd.uci.edu/ ~ gohlke / pythonlibs /. Пока что исчезли ошибки, связанные с конвергенцией linalg и svd (). Если я найду что-нибудь еще, я вернусь сюда и сообщу об этом.

Дарио

Странно, что DLL OpenBLAS создается VC9 версией lib.exe? Это версия, которая использовалась с Python 2.7. Это может не иметь значения, но кажется странным, учитывая, что VC9 нигде не используется.

Следующим шагом для кого-то (возможно, для меня) будет создание мастера NumPy с однопоточным OpenBLAS ( USE_THREAD=0 ), чтобы посмотреть, решит ли это проблемы.

Я безуспешно пробовал несколько экспериментов:

• Отключить потоки USE_THREADS=0
• ILP64 INTERFACE64=1 <- Segfault в тесте NumPy с нарушением доступа

Можете ли вы запустить набор тестов LAPACK с такой установкой Win10? Я недавно исправил сборку cmake для ее создания, возможно, она дает некоторую подсказку без какого-либо вмешательства.

                        -->   LAPACK TESTING SUMMARY  <--
SUMMARY                 nb test run     numerical error         other error
================        ===========     =================       ================
REAL                    409288          0       (0.000%)        0       (0.000%)
DOUBLE PRECISION        410100          0       (0.000%)        0       (0.000%)
COMPLEX                 420495          0       (0.000%)        0       (0.000%)
COMPLEX16               13940           0       (0.000%)        0       (0.000%)

--> ALL PRECISIONS      1253823         0       (0.000%)        0       (0.000%)

Хотя я вижу много строк вроде

-->  Testing DOUBLE PRECISION Nonsymmetric Eigenvalue Problem [ xeigtstd < nep.in > dnep.out ]
---- TESTING ./xeigtstd... FAILED(./xeigtstd < nep.in > dnep.out did not work) !

поэтому я не уверен, заслуживают ли они доверия.

Похоже, что большинство тестов завершаются сбоем, но сохранившиеся безупречны ... это немного более экстремально, чем я ожидал.
(COMPLEX и COMPLEX16 немного требовательны с точки зрения размера стека, поэтому сбои гораздо более вероятны с настройками ОС по умолчанию, но REAL и DOUBLE обычно показывают запуск около 1200000 тестов. Это заставляет меня задаться вопросом, изменила ли MS что-то по умолчанию в стеке ограничение или макет хотя)

Немного предыстории. Все строится с помощью gcc.exe / gfortran.exe. Они используются для создания файла .a, который затем упаковывается в DLL. В частности:

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\git\numpy-openblas-windows\openblas-libs\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/git/numpy-openblas-windows/openblas-libs/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/lib -L/c/mingw710/prerequisites/x86_64-zlib-static/lib -L/c/mingw710/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 7.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)

$ gfortran -v
Using built-in specs.
COLLECT_GCC=C:\git\numpy-openblas-windows\openblas-libs\mingw64\bin\gfortran.exe
COLLECT_LTO_WRAPPER=C:/git/numpy-openblas-windows/openblas-libs/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/lib -L/c/mingw710/prerequisites/x86_64-zlib-static/lib -L/c/mingw710/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 7.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)

Я действительно думаю, что проблема в передаче обслуживания между NumPy и OpenBLAS. Я не могу себе представить, как еще такое поведение могло произойти, если первый вызов является ошибкой, но второй и последующие в порядке. Как решить эту проблему (или даже точно диагностировать глубокую проблему) ...?

Отменить платформу MS и жить долго и счастливо? Если он не проходит тесты Lapack, проблема передачи обслуживания лежит между Фортраном (= LAPACK часть OpenBLAS) и C или Фортраном и «чем-нибудь еще».

Мне было бы любопытно, можно ли построить Numpy с OpenBLAS, используя icc
и ifort, поэтому посмотрите, сохраняется ли проблема. Однако это большой вопрос.

В среду, 12 августа 2020 г., 19:04 Мартин Кроекер [email protected] написал:

Отменить платформу MS и жить долго и счастливо? Если это не удается
Lapack проверяет, что проблема передачи обслуживания лежит между Фортраном (= часть LAPACK
OpenBLAS) и C, или Fortran и "все остальное".

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/numpy/numpy/issues/16744#issuecomment-673026759 или
отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ABKTSRLSHZ2XWF4OE7J3QO3SALKSJANCNFSM4OP5IXNQ
.

Вероятно, было бы достаточно просто собрать OpenBLAS с компиляторами Intel (хотя это кажется достаточно проблематичным, по крайней мере, с VS из того, что появилось недавно, и на данный момент у меня нет действующей лицензии на ifc / ifort.

Возможная связанная проблема:

https://developercommunity.visualstudio.com/content/problem/1095521/link-error-in-in-rust-test-binary.html

Пользователи Windows должны использовать Conda / MKL, если в 2004 году, пока проблема не будет решена.

@bashtage Спасибо за ваше предложение.
В моем случае у меня возникла ошибка, когда я использую sqlite с помощью pandasql после применения версии Conda для numpy.

но у меня нет проблем, когда я использую эту версию numpy + mkl .

@bashtage кажется, что есть новый предварительный выпуск MSVC с исправлением этой проблемы с ржавчиной ссылки, может быть, стоит попробовать?

FYI: связанная проблема SciPy: https://github.com/scipy/scipy/issues/12747

Есть отчет, что сборка Windows 17763.1397 (11 августа) устраняет проблему, см. # 17082.

Есть отчет, что сборка Windows 17763.1397 (11 августа) устраняет проблему, см. # 17082.

https://support.microsoft.com/en-us/help/4565349/windows-10-update-kb4565349

Сборка 17763.1397 предназначена только для Windows 10 версии 1809 (применимо к: Windows 10 версии 1809, всем выпускам, Windows Server версии 1809, Windows Server 2019, всем выпускам).
В этом случае для Windows 10 версии 1809 проблем нет.

Это недавно обновленная версия Windows 10, версия 2004.
https://support.microsoft.com/en-us/help/4566782
11 августа 2020 г. - KB4566782 (сборка ОС 19041.450).

У меня все еще такая же проблема с Windows 10 версии 2004

Такие же сбои на 19042.487 (это ветка 20H2):

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=============================================== short test summary info ===============================================
FAILED lib/tests/test_regression.py::TestRegression::test_polyfit_build - numpy.linalg.LinAlgError: SVD did not conve...
FAILED linalg/tests/test_regression.py::TestRegression::test_eig_build - numpy.linalg.LinAlgError: Eigenvalues did no...
FAILED ma/tests/test_extras.py::TestPolynomial::test_polyfit - numpy.linalg.LinAlgError: SVD did not converge in Line...
3 failed, 11275 passed, 559 skipped, 20 xfailed, 1 xpassed, 1 warning in 398.16s (0:06:38)

Я могу воспроизвести (частичные) сбои в лапак-тесте OpenBLAS - затрагивая только тесты EIG (собственное значение), которые, как известно, предъявляют некоторые необычно высокие требования к размеру стека. Здесь SIGSEGV встречается в __chkstk_ms_, который вводится даже перед main (). Удвоение значений «зарезервированного размера стека» и «размера фиксации стека» по умолчанию для соответствующего исполняемого файла с помощью утилиты peflags (например, peflags -x4194304 -X4194304 EIG/xeigtsts.exe ) заставляет программы работать нормально, предполагая, что взаимодействие C / Fortran и передача аргументов как таковые являются не проблемно. Я еще не пытался применить это к случаю numpy (не уверен, даже чей параметр peflag настраивается там - python.exe?), Но сам OpenBLAS, похоже, работает нормально при сборке с версией msys2 mingw64 gcc 9.1.0 на 19041.450 aka 2004 г.

@ martin-frbg Похоже, прогресс.

Спустился в кроличью нору, пытаясь установить все зависимости для создания numpy в Windows / MSYS2, поэтому никакого дальнейшего прогресса.

@ martin-frbg, пакет numpy на основе Msys2 можно установить с помощью pacman. Скрипты сборки и исправления Msys2 доступны здесь: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python-numpy и https://github.com/msys2/MINGW-packages/tree / мастер / mingw-w64-openblas.

На последнем совещании по сортировке это стало относительно высоким приоритетом, и мы с @hameerabbasi готовы помочь. Что мы можем сделать?

@bashtage не могли бы вы попробовать увеличить стек с помощью editbin /STACK:3145728 python.exe

Есть ли способ попробовать собрать NumPy с выпусками библиотек OpenBLAS вместо тех, которые мы создаем? Возможно, наши сборки немного не в порядке.

Вероятно, можно было бы заменить libopenblas.dll в вашей сборке на файл, созданный либо из текущей ветки develop или из более ранней версии, такой как 0.3.8 или 0.3.9, чтобы посмотреть, имеет ли это какой-либо эффект? (Не то чтобы у меня сейчас есть какие-то конкретные коммиты, которые могли бы иметь какое-либо отношение к этому). К сожалению, я все еще испытываю ошибки при установке даже с пакетами msys2, в настоящее время не могу запускать тесты, по-видимому, из-за того, что self.ld_version ничего не возвращает при проверке версии.

Благодарю. Я пытаюсь обновить свои окна до сборки 2004, посмотрим, закончу ли я до выходных

Кроме того, «небольшой пример воспроизведения» bashtage из https://github.com/numpy/numpy/issues/16744#issuecomment -655430682 не вызывает никаких ошибок в моей настройке msys2. (Насколько я могу судить, их libopenblas в mingw64 / usr / lib - однопоточная версия 0.3.10, созданная для Haswell)

@ martin-frbg Можно ли построить OpenBLAS с помощью MSVC?

Обычный MSVC? Выполнимо, но дает плохо оптимизированную библиотеку, поскольку MSVC не поддерживает ядра сборки - практически так же, как если бы вы создали OpenBLAS для TARGET = GENERIC.

Кроме того, "небольшой пример воспроизведения" bashtage из # 16744 (комментарий) не вызывает никаких ошибок в моей настройке msys2. (Насколько я могу судить, их libopenblas в mingw64 / usr / lib - однопоточная версия 0.3.10, созданная для Haswell)

Я почти уверен, что это связано с интерфейсом между NumPy и OpenBLAS. 32-битная сборка NumPy также не имеет этой проблемы. Идеи людей из Microsoft, с которыми я говорил, о том, что это, скорее всего, проблема синхронизации потоков, кажутся наиболее правдоподобными. Это могло бы объяснить, как неправильное значение присутствует в первом вызове, а затем исправляется в последующих вызовах.

Спустился в кроличью нору, пытаясь установить все зависимости для создания numpy в Windows / MSYS2, поэтому никакого дальнейшего прогресса.

Это боль. Я сделал это, но автоматизация для некоторых экспериментов заняла много времени. В основном это требует копирования шагов из https://github.com/MacPython/openblas-libs для получения файлов .a, а затем копирования шагов из https://github.com/numpy/numpy/blob/master/ azure-steps-windows.yml для сборки NumPy. Это особенно сложно, поскольку для некоторых частей требуется стандартный MSYS2, а для других необходимо, чтобы они были удалены, поэтому вы в конечном итоге устанавливаете и удаляете большую часть gcc каждый раз, когда хотите провести эксперимент.

Самый простой способ получить сборку DLL - открыть учетную запись приложения, а затем клонировать https://github.com/MacPython/openblas-libs. В конце вашей сборки есть артефакт, который вы можете найти на веб-сайте для загрузки, который имеет dll (и файл .a). Однако это медленно и занимает 3 часа, чтобы собрать все 3 версии.

Глядя на https://github.com/MacPython/openblas-libs , кажется, что OpenBLAS построен с использованием INTERFACE64=1 . Это не относится к Msys2 build OpenBLAS и numpy.

@carlkl Эта проблема не связана с Msys2-сборкой NumPy или OpenBLAS. Речь идет о сборке Win32 / AMD64, которая использует предоставленный Msys2 gfortran для компиляции исходных текстов fortran, но затем создает Win32 DLL из скомпилированной библиотеки с помощью MS lib.exe.

@bashtage Я упомянул об этом, потому что https://github.com/numpy/numpy/issues/16744#issuecomment -689785607 сообщалось, что segfault не может быть воспроизведен в msys2. И я предполагаю, что упомянутая среда msys2 содержит двоичные пакеты openblas и numpy, предоставленные msys2.

Я понятия не имею, скомпилирован ли Windows 64bit numpy с аналогичным флагом с MSVC или нет.

Кстати: я не могу найти флаг -fdefault-integer-8 в репозитории scipy.
Я не уверен, что код, скомпилированный с помощью -fdefault-integer-8 совместим с ABI с кодом, скомпилированным без этого флага.

Мне пришло в голову еще одно: возможно, -fdefault-integer-8 следует объединить с -mcmodel=large .

РЕДАКТИРОВАТЬ: Помните: Windows64 имеет модель памяти LLP64, а не ILP64.
LLP64 означает: длинный: 32 бит, указатель: 64 бит

Итак, какого размера целые числа использует сборка numpy, которая испытывает проблему с Win10-2004? Он лучше соответствовал тому, для чего был создан OpenBLAS, но IIRC эта тема уже поднималась ранее в этом потоке (и несоответствие, вероятно, привело бы к более выраженной поломке независимо от уровня исправления Windows)

По крайней мере, Openblas можно собрать в трех вариантах с https://github.com/MacPython/openblas-libs (см. Appveyor.yml):

• 32 бит
• 64 бит
• 64 бит с INTEGER64

но если не знаете, что используется для 64-битных сборок в Windows.

_и несоответствие, вероятно, привело бы к более явной поломке, независимо от уровня исправления Windows_

-fdefault-integer-8 применяется только к передней части Lapack. Он не меняет базовую модель памяти (LLP64), поэтому я не уверен, стоит ли ожидать проблем вне частей Fortran Lapack.

хм,

https://github.com/numpy/numpy/blob/60a21a35210725520077f13200498e2bf3198029/azure-pipelines.yml говорит

- job: Windows pool: vmImage: 'VS2017-Win2016' ... Python38-64bit-full: PYTHON_VERSION: '3.8' PYTHON_ARCH: 'x64' TEST_MODE: full BITS: 64 NPY_USE_BLAS_ILP64: '1' OPENBLAS_SUFFIX: '64_'
все другие версии ( Python36-64bit-full , Python37-64bit-full ) построены без NPY_USE_BLAS_ILP64.

Все двоичные файлы Numpy на pypi.org построены с использованием 32-битных целочисленных openblas. https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

Подробные сведения о процессе сборки gfortran и MSVC см. Здесь . Microsoft lib.exe не участвует в создании openblas DLL, это все инструменты mingw. Numpy использует файл openblas.a и генерирует DLL с помощью gfortran. https://github.com/numpy/numpy/blob/74712a53df240f1661fbced15ae984888fd9afa6/numpy/distutils/fcompiler/gnu.py#L442 Инструменты MSVC используются для создания файла .lib из файла .def и кода Numpy C, скомпилированного с помощью файла .def. связан с помощью этого файла .lib с DLL, созданной gfortran.

Одна теоретическая возможность, которая может пойти не так, - это несоответствие версии mingw между mingw, создавшим статический артефакт openblas.a, и версией mingw, используемой при сборке numpy. Однако не уверен, возможно ли это, что это может вызвать проблемы.

choco install -y mingw --forcex86 --force --version=5.3.0 используемые в windows.yml кажутся устаревшими. Почему бы не использовать 7.3.0 или 8.1.0 ? Я помню проблемы, которые у меня были с gcc-5.x два или три года назад.

choco install -y mingw --forcex86 --force --version = 5.3.0, используемый в windows.yml, кажется устаревшим

Это только для 32-битной сборки Windows, поэтому, вероятно, не связано с этой проблемой.

все другие версии ( Python36-64bit-full , Python37-64bit-full ) построены без NPY_USE_BLAS_ILP64.

Те же ошибки на Python 3.6 и 3.8.

Осталась одна идея (копаюсь в темноте):

OpenBLAS теперь компилируется с помощью -fno-optimize-sibling-calls , см. Https://github.com/xianyi/OpenBLAS/issues/2154 , https://github.com/xianyi/OpenBLAS/pull/2157 и https: // gcc .gnu.org / bugzilla / show_bug.cgi? id = 90329.
Изменить: см. Также: https://gcc.gnu.org/legacy-ml/fortran/2019-05/msg00181.html

Numpy не применял этот флаг в своей gfortran части distutils. Я знаю, что numpy скомпилирован с помощью MSVC. Поэтому я бы ожидал проблем с scipy скорее с numpy, так что это может быть снова неправильная поездка.

Все двоичные файлы Numpy на pypi.org построены с использованием 32-битных целочисленных openblas. https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

Почему конфигурации сборки, используемые при тестировании, отличаются от используемых в выпуске? Это похоже на риск.

Можно ли добавлять артефакты в сборки Azure? Это упростило бы получение колес для испытаний. Меня беспокоит только то, что ограничение бесплатного артефакта довольно мало IIRC, 1 ГБ, и я не знаю, что происходит, когда вы его нажимаете (FIFO было бы хорошо, но может делать другие вещи, включая ошибку).

Почему конфигурации сборки, используемые при тестировании, отличаются от используемых в выпуске?

Мы тестируем все поддерживаемые версии Python в Windows без NPY_USE_BLAS_ILP64 , а также тестируем Python 3.8 с NPY_USE_BLAS_ILP64 , см. Https://github.com/numpy/numpy/blob/v1.19.2/azure -pipelines.yml # L195. Таким образом, еженедельные сборки верны при использовании 32-битных целочисленных openblas.

Можно ли добавлять артефакты в сборки Azure?

Наверное, легко попробовать это и узнать о пределах, если это произойдет. Однако еженедельные колеса предназначены для точного воссоздания тестовых сборок. Любые расхождения следует рассматривать как ошибки и исправлять.

Наверное, легко попробовать это и узнать о пределах, если это произойдет. Однако еженедельные колеса предназначены для точного воссоздания тестовых сборок. Любые расхождения следует рассматривать как ошибки и исправлять.

Я думал, что проще будет поэкспериментировать с PR на основной репо и взять артефакт для тестирования в 2004 году.

Имеет смысл.

Вы можете включить конвейеры Azure в своем репо bashtage / numpy

Еще немного информации: первый вызов, который не удался, связан с тем, что DNRM2 внутри OpenBLAS возвращает NAN. Для меня это повторяется: каждый звонок

a = np.arange(13 * 13, dtype=np.float64).reshape(13, 13)
a = a % 17
np.linalg.eig(a)

выводит ** On entry to DGEBAL parameter number 3 had an illegal value , что является другим способом сказать « DNRM2 возвращено NAN». Операция mod является критической, без нее вызов eig не выводит эту ошибку.

Как могло быть какое-либо взаимодействие между mod ufunc и вызовом OpenBLAS?

Операция mod является критической, без нее вызов eig не выводит эту ошибку.

Возникает ли ошибка при создании этого точно такого же массива вручную?

Этот код не вызывает сбой:

a = np.array([x % 17 for x in range(13 * 13)], dtype=np.float64)
a.shape = (13, 13)
np.linalg.eig(a)

Может ли предыдущий mod оставить регистр в неопределенном состоянии? Я не проверял nrm2.S снова, но я думаю, что несколько лет назад у нас были проблемы, когда сборка выполняла XOR с самим собой, чтобы очистить его, что не помогло бы при NaN.

Для тех, кто следит за этим, float64 % заканчивается вызовом npy_divmod для каждого значения.

... который в первой строке вызывает npy_fmod() , то есть fmod () . Вот некоторые изменения, которые я пробовал. «Ошибка» означает, что я получаю сообщение «недопустимое значение» от OpenBLAS при запуске кода, который вызывает a % 17; np.linalg.eig(a)
код | результат
--- | ---
mod = npy_fmod@c@(a, b); (исходный код) | ошибка
mod = 100; //npy_fmod@c@(a, b); | Нет ошибки
mod = npy_fmod@c@(a, b); mod = 100.0; | ошибка

Итак, похоже, что fmod от MSVC делает что-то, что сбивает OpenBLAS с толку.

Это интересно и странно.

Можете ли вы использовать наивную (не поставляемую с платформой) версию fmod, чтобы проверить, исправила ли она это?

Или просто принудительно установите HAVE_MODF на 0 .

Не думаю, что у нас есть наивная версия fmod, не так ли?

Я вижу, что есть макрос HAVE_MODF, но куда ведет этот путь ?

Похоже, он возвращается к двойной версии, если отсутствуют float и long double. Двойная версия обязательна для сборки numpy. Undef, вероятно, должен избегать встроенных функций компилятора, ISTR, который давным-давно был проблемой для Windows.

Я хотел «доказать», что проблема заключается в реализации fmod , которая исходит из ucrtbase.dll . Поэтому я написал небольшой обходной маневр, который использует ctypes для извлечения функции из dll и использования ее вместо прямого вызова fmod . Тесты по-прежнему терпят неудачу. Затем я перешел на старую версию ucrtbase.dll (только для функции fmod ). Тесты пройдены. Я открыл ветку на форуме Visual Studio . Если кто-нибудь знает, как лучше связаться с Microsoft, это было бы здорово.

diff --git a/numpy/core/src/npymath/npy_math.c b/numpy/core/src/npymath/npy_math.c
index 404cf67b2..675905f73 100644
--- a/numpy/core/src/npymath/npy_math.c
+++ b/numpy/core/src/npymath/npy_math.c
@@ -7,3 +7,27 @@

 #define NPY_INLINE_MATH 0
 #include "npy_math_internal.h"
+#include <Windows.h>
+
+typedef double(*dbldbldbl)(double, double);typedef double(*dbldbldbl)(double, double);
+
+dbldbldbl myfmod = NULL;
+
+typedef double(*dbldbldbl)(double, double);
+extern dbldbldbl myfmod;
+
+
+double __fmod(double x, double y)
+{
+    if (myfmod == NULL) {
+        HMODULE dll = LoadLibraryA("ucrtbase_old.dll");
+        //HMODULE dll = LoadLibraryA("c:\\windows\\system32\\ucrtbase.DLL");
+         myfmod = (dbldbldbl)GetProcAddress(dll, "fmod");
+    }
+    return myfmod(x, y);
+}
+
+long double __fmodl(long double x, long double y) { return fmodl(x, y); }
+float __fmodf(float x, float y) { return fmodf(x, y); }
+
+
diff --git a/numpy/core/src/npymath/npy_math_internal.h.src b/numpy/core/src/npymath/npy_math_internal.h.src
index 18b6d1434..9b0600a34 100644
--- a/numpy/core/src/npymath/npy_math_internal.h.src
+++ b/numpy/core/src/npymath/npy_math_internal.h.src
@@ -55,6 +55,11 @@
  */
 #include "npy_math_private.h"

+double __fmod(double x, double y);
+long double __fmodl(long double x, long double y);
+float __fmodf(float x, float y);
+
+
 /*
  *****************************************************************************
  **                     BASIC MATH FUNCTIONS                                **
@@ -473,8 +478,8 @@ NPY_INPLACE @type@ npy_@kind@@c@(@type@ x)
 /**end repeat1**/

 /**begin repeat1
- * #kind = atan2,hypot,pow,fmod,copysign#
- * #KIND = ATAN2,HYPOT,POW,FMOD,COPYSIGN#
+ * #kind = atan2,hypot,pow,copysign#
+ * #KIND = ATAN2,HYPOT,POW,COPYSIGN#
  */
 #ifdef HAVE_@KIND@@C@
 NPY_INPLACE @type@ npy_@kind@@c@(@type@ x, @type@ y)
@@ -484,6 +489,13 @@ NPY_INPLACE @type@ npy_@kind@@c@(@type@ x, @type@ y)
 #endif
 /**end repeat1**/

+#ifdef HAVE_FMOD@C@
+NPY_INPLACE @type@ npy_fmod@c@(@type@ x, @type@ y)
+{
+    return __fmod@c@(x, y);
+}
+#endif
+
 #ifdef HAVE_MODF@C@
 NPY_INPLACE @type@ npy_modf@c@(@type@ x, @type@ *iptr)
 {

Что, если вы добавите код после вызова fmod, чтобы ST(0) не содержало nan? Или установить нан синтетически?
Не накладывают ли соглашения о вызовах некоторые ограничения на поведение этих регистров?

Я хотел «доказать», что проблема заключается в реализации fmod , которая исходит из ucrtbase.dll . Поэтому я написал небольшой обходной маневр, который использует ctypes для извлечения функции из dll и использования ее вместо прямого вызова fmod . Тесты по-прежнему терпят неудачу. Затем я перешел на старую версию ucrtbase.dll (только для функции fmod ). Тесты пройдены. Я открыл ветку на форуме Visual Studio . Если кто-нибудь знает, как лучше связаться с Microsoft, это было бы здорово.

Как минимум, любой, у кого есть лазурная учетная запись, а их здесь, вероятно, много, может проголосовать за нее. Я обращусь к некоторым контактам, с которыми я установил, когда эта проблема первоначально возникла, которые работают в Azure ML, чтобы узнать, могут ли они что-нибудь сделать.

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

Спасибо за подсказку, проголосовали за!

Не думаю, что у нас есть наивная версия fmod, не так ли?

Нет. Это сложная функция, которая требуется спецификацией IEEE-754 для определенного поведения. Кроме того, он очень медленный, что, вероятно, связано со спецификацией.

Тяжелая работа fmod выполняется инструкцией fprem x87, даже в варианте VS2019 - см. Суть @mattip (последняя строка) https://gist.github.com/mattip / d9e1f3f88ce77b9fde6a285d585c738e. ( fprem1 - это вариант remainder кстати.)

Следует проявлять осторожность при использовании вместе с регистрами MMX или SSE - как описано здесь: https://stackoverflow.com/questions/48332763/where-does-the-xmm-instruction-divsd-store-the-remainder.

Доступны несколько альтернативных реализаций, как описано в https://github.com/xianyi/OpenBLAS/issues/2709#issuecomment -702634696. Однако: все это требует компиляции gcc (mingw-w64). OpenLIBM не компилируется с MSVC AFAIK. А встроенный код ассемблера не допускается в MSVC. В принципе можно построить (mingw-w64) и использовать (MSVC) вспомогательную библиотеку fmod во время сборки numpy.

Что, если вы добавите код после вызова fmod, чтобы ST (0) не содержал nan? Или установить нан синтетически? Не накладывают ли соглашения о вызовах некоторые ограничения на поведение этих регистров?

Думаю, мы могли бы добавить небольшую часть сборки для очистки регистров перед вызовом OpenBLAS в Windows. Я попытался сделать это в небольшой тестовой настройке, но моя сборка foo для masm слабая. Я пробовал написать процедуру, которая просто вызывает fldz несколько раз, при ее использовании возникает исключение. Помогите?

.code
lots_of_fldz proc
    fldz
    fldz
    fldz
    fldz
    fldz
    fldz

lots_of_fldz endp
end

#include <iostream>
#include <Windows.h>

extern "C" {
int lots_of_fldz(void);
}

int main()
{
    typedef double(*dbldbldbl)(double, double);
    //HMODULE dll = LoadLibraryA("D:\\CPython38\\ucrtbase_old.dll");
    HMODULE dll = LoadLibraryA("c:\\windows\\system32\\ucrtbase.DLL");
    if (dll == NULL) {
        return -1;
    }
    dbldbldbl myfmod;
    myfmod = (dbldbldbl)GetProcAddress(dll, "fmod");
    double x = 0.0, y = 17.0;
    double z = x + y;
    z = myfmod(x, y);
    lots_of_fldz();
    /* CRASH */
    std::cout << "Hello World!\n";
    return 0;
}

@mattip , я создал файл ассемблера для 64-битной функции text: как в соответствующей функции fmod из mingw-w64 (64-бит). Не знаю, работает ли это как замена глючной функции fmod, но, по крайней мере, стоит попробовать. Полученный obj-файл можно добавить в npymath.lib.

fmod.asm: (64-разрядная)

.code
fmod PROC
    sub    rsp , 18h
    movsd  QWORD PTR [rsp+8h] , xmm0
    fld    QWORD PTR [rsp+8h]
    movsd  QWORD PTR [rsp+8h] , xmm1
    fld    QWORD PTR [rsp+8h]
    fxch   st(1)
L1:
    fprem
    fstsw  ax
    sahf
    jp     L1
    fstp   st(1)
    fstp   QWORD PTR [rsp+8h]
    movsd  xmm0 , QWORD PTR [rsp+8h]
    add    rsp,18h
    ret
fmod endp
end

Команда masm: ml64.exe /c fmod.asm создает fmod.obj (используйте 64-битный вариант ml64.exe)

``

objdump -D fmod.obj
....
Disassembly of section .text$mn:
0000000000000000 <fmod>:
   0:   48 83 ec 18            sub    $0x18,%rsp
   4:   f2 0f 11 44 24 08      movsd  %xmm0,0x8(%rsp)
   a:   dd 44 24 08            fldl   0x8(%rsp)
   e:   f2 0f 11 4c 24 08      movsd  %xmm1,0x8(%rsp)
  14:   dd 44 24 08            fldl   0x8(%rsp)
  18:   d9 c9                  fxch   %st(1)
  1a:   d9 f8                  fprem
  1c:   9b df e0               fstsw  %ax
  1f:   9e                     sahf
  20:   7a f8                  jp     1a <fmod+0x1a>
  22:   dd d9                  fstp   %st(1)
  24:   dd 5c 24 08            fstpl  0x8(%rsp)
  28:   f2 0f 10 44 24 08      movsd  0x8(%rsp),%xmm0
  2e:   48 83 c4 18            add    $0x18,%rsp
  32:   c3                     retq

@carlkl спасибо. Я был бы более доволен частью ассемблера, который сбрасывает регистры ST (N), которые мы могли бы использовать на x86_64 перед вызовом функций OpenBLAS. Сегодня эта проблема возникла из-за изменения fmod , завтра может быть другая функция. Я не уверен, что нужны функции для сброса регистров ST(N) при возврате. Если такого требования нет, fmod самом деле не содержит ошибок, и изменение в окнах выявило сбой в OpenBLAS для сброса регистров перед их использованием, и мы должны либо помочь им исправить, либо обойти это.

Я попытался сбросить регистры, используя fldz в комментарии выше, но моя тестовая программа не работает.

@mattip , мои https://stackoverflow.com/questions/19892215/free-the-x87-fpu-stack-ia32/33575875

С https://docs.microsoft.com/de-de/cpp/build/x64-calling-convention?view=vs-2019 :

The x87 register stack is unused. It may be used by the callee, but consider it volatile across function calls.

Думаю, мы могли бы также вызвать fninit в начале OpenBLAS nrm2.S (после макроса PROFCODE), чтобы проверить эту теорию.

Интересный фрагмент из
Двоичный интерфейс приложения System VДополнение к процессору архитектуры AMD64Черновая версия 0.99.6

_Биты управления регистра MXCSR сохраняются для вызываемого (сохраняются при вызовах), а биты состояния сохраняются для вызывающего (не сохраняются) ._

_Регистр слова состояния x87 сохраняется для вызывающего абонента, тогда как контрольное слово x87 сохраняется для вызываемого.

_Все регистры x87 сохраняются для вызывающих, поэтому вызываемые, использующие регистры MMX, могут использовать более быструю инструкцию femms.

Совсем иначе по сравнению с соглашением о вызовах 64-битной Windows.

@ martin-frbg, fninit опасно: The FPU control word is set to 037FH (round to nearest, all exceptions masked, 64-bit precision). X87 расширенная точность не нужна во всех случаях, особенно в Windows.

Я бы не хотел этого для релизной версии, просто для быстрого тестирования. По-прежнему не совсем уверен, что OpenBLAS должен каким-то образом очистить "до" самого себя, но я не могу найти какой-либо четкой документации о поведении Windows по отношению к устаревшему fpu x87. Я заметил, что у Агнера Фога есть документ о соглашениях о вызовах на http://www.agner.org/optimize/calling_conventions.pdf (обсуждение обработки Win64 регистров FP начинается на странице 13, но основное внимание уделяется базовой доступности и поведению при переключении контекста).

См. Https://github.com/numpy/numpy/issues/16744#issuecomment -703305582:

The x87 register stack is unused. It may be used by the callee, but consider it volatile across function calls.

Думаю, это означает: не используйте инструкции x87 (Win64). Если да, удачи. Или, другими словами: вызываемый несет ответственность не причинить вреда.

Хм, это, кажется, конкретно описывает поведение компилятора MSVC, в то время как я _think_, мы находимся в экосистеме mingw?

Нет, Numpy (Pypi) скомпилирован с MSVC (Visual Studio 2019) в Windows. Для OpenBLAS используется mingw-w64 (из-за частей Fortran). Также части Scipy Fortran скомпилированы с помощью mingw-w64. Однако CPython и его двоичные расширения в значительной степени основаны на стандартах, установленных MSVC.

Кстати: это было причиной разработки https://github.com/mingwpy, который в настоящее время снова оживает. (бесстыдная пробка)

Еще немного:

mingw-w64 использует (почти) те же соглашения о вызовах, что и MSVC. Единственные заметные различия - это различное выравнивание стека на x86 (32-бит) - актуально для SIMD и неподдерживаемого vectorcall .

Интересно. x86 не затрагивается. Только AMD64.

Вс, 4 октября 2020 г., 22:19 carlkl [email protected] написал:

Еще немного:

mingw-w64 использует (почти) те же соглашения о вызовах, что и MSVC. Единственный
заметные отличия - различное выравнивание стека на x86 (32-бит) -
актуально для SIMD и неподдерживаемого векторного вызова.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/numpy/numpy/issues/16744#issuecomment-703317784 или
отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ABKTSRMFHWZVLDYDFGBM6YDSJDRGTANCNFSM4OP5IXNQ
.

Может быть, MSVC 32bit не отказался от фпу? Я просто сделаю временную замену nrm2.S, использующего fpu, либо на nrm2_see2.S (если он жизнеспособен, к сожалению, в кодовой базе есть несколько неиспользуемых, но смертоносных процедур сборки), либо на простую версию C для ОС == Тогда винда. (Другая проблема, обсуждаемая здесь, должна быть чем-то другим, поскольку я думаю, что все другие старые процедуры сборки для x86_64, по крайней мере, SSE2)

@mattip , может быть, вызова _fpreset после divmod достаточно для сброса из испорченного состояния FPU?

возможно звонок на _fpreset

Нет, он не сбрасывает регистры ST(N) и не исправляет неудачные тесты.

Вы попробовали _fninit ? Это должно сбросить стек FPU. Или ffree или fstp вместо fldz как указано в https://stackoverflow.com/questions/19892215/free-the-x87-fpu-stack-ia32/33575875 ?

см. https://developercommunity.visualstudio.com/content/problem/1208774/fpu-exception-in-fmod0-x-in-windows-10-version-200.html

Я бы с радостью попробовал команды ассемблера, но тестовый проект в комментарии выше вылетает. Кому-то нужно исправить мой код, чтобы он работал (действительно, fninit кажется хорошим кандидатом), тогда я могу выпустить инструкции ассемблера для сброса регистров в NumPy перед вызовом OpenBLAS.

Что-то вроде этого?

.code
reset_fpu proc
    finit
    fldz
reset_fpu endp
end

finit ist wait плюс fninit . Я не уверен, что fldz необходима после fninit .

Как я уже сказал в комментарии, чего-то не хватает, чтобы вызов скомпилированного кода сборки работал правильно. Это в значительной степени то, что я написал в этом комментарии. Код вылетает с exited with code -2147483645 . Взгляните на полный код и посмотрите, сможете ли вы заставить его работать.

Могу попробовать (завтра). Однако, возможно, эти фрагменты полезны:

https://www.website.masmforum.com/tutorials/fptute/fpuchap4.htm
(один из самых читаемых сайтов по этой теме, который я нашел)

FLDZ (Load the value of Zero)

Syntax:    fldz  (no operand)

Exception flags: Stack Fault, Invalid operation

This instruction decrements the TOP register pointer in the Status Word 
and loads the value of +0.0 into the new TOP data register.

If the ST(7) data register which would become the new ST(0) is not empty, both 
a Stack Fault and an Invalid operation exceptions are detected, setting both flags 
in the Status Word. The TOP register pointer in the Status Word would still 
be decremented and the new value in ST(0) would be the INDEFINITE NAN.

A typical use of this instruction would be to "initialize" a data register intended 
to be used as an accumulator. Even though a value of zero could also be easily 
loaded from memory, this instruction is faster and does not need the use of memory. 

Насколько я понимаю, fldz может segfault, если st (7) используется, поэтому:

FFREE (Free a data register)

Syntax:   free st(x)

This instruction modifies the Tag Word to indicate that the specified 80-bit data register 
is now considered as empty. Any data previously in that register becomes unusable. 
Any attempt to use that data will result in an Invalid exception being detected and an 
INDEFINITE value possibly being generated.

Although any of the 8 data registers can be tagged as free with this instruction, 
the only one which can be of any immediate value is the ST(7) register when 
all registers are in use and another value must be loaded to the FPU. 
If the data in that ST(7) is still valuable, other instructions should be used 
to save it before emptying that register. 

вы можете попробовать:

.code
reset_fpu proc
    ffree st(7)
    fldz
reset_fpu endp
end

Извините, я не ясно выражаюсь. Непосредственная проблема не в том, какие вызовы ассемблера делать. Непосредственная проблема заключается в том, как правильно создать вызываемую процедуру таким образом, чтобы мы могли ее использовать, и продемонстрировать это в двухфайловом формате ( *.asm и main.c / main.cpp ), который компилируется и запускается. Как только мы получим это, я смогу продолжить изучение различных вызовов и их влияния на OpenBLAS.

@mattip , я понимаю. Я обязательно попробую, но это может занять время.

У меня сложилось впечатление, что _tempory_ плохое поведение fmod в UCRT должно быть _ вылечено OpenBLAS: https://github.com/xianyi/OpenBLAS/pull/2882, а не numpy, поскольку numpy не использует FPU на WIN64. И, конечно же, MS должна исправить эту проблему с помощью патча для Windows.
Патч numpy в этом случае должен гарантировать использование версии OpenBLAS во время сборки не старше предстоящего выпуска OpenBLAS.

@matti В numpy/__init__.py есть проверка на работоспособность . Есть ли простой и надежный тест, который мы могли бы добавить для обнаружения этой проблемы?

a = np.arange(13 * 13, dtype=np.float64).reshape(13, 13)
a = a % 17
va, ve = np.linalg.eig(a)

@mattip , спасибо за фрагмент. Но мне понадобится время, чтобы получить доступ к рабочему столу, на котором я смогу проводить такие тесты. Сейчас я большую часть времени работаю с ноутбуком с минимальной средой программирования, где я почти ничего не могу установить.

Мы объединили обновление для OpenBLAS v0.3.12, и локальная сборка с использованием этой версии + обновление Windows 2004 проходит через набор тестов.

Оставьте это открытым до обновления Windows.

Были ли созданы предварительные версии колес с новым OpenBLAS? С удовольствием проведу еще несколько тестов с последующими проектами, в которых возникла эта ошибка.

Предварительные версии Windows 3.9 в настоящее время отсутствуют из-за ошибок тестирования (теперь они исправлены). Фиксированная библиотека будет использоваться в версии 1.19.3, которая выйдет сегодня или завтра.

Параметр /MT включает статическое связывание в Windows. Возможно статическое связывание с libucrt.lib с помощью версии 1909 Microsoft SDK. Это могло бы послужить обходным решением для ошибки ucrtbase.dll в 2004 и 20H2. Это сделало бы колеса больше, что является недостатком.

Я понятия не имею, актуальна ли эта проблема / MT , но ее следует рассмотреть.

Я думаю, что если NumPy - единственный модуль, который строится с помощью MT, это может быть
ХОРОШО. Конечно, может случиться так, что если NumPy является MT, то любой
нисходящий поток также должен быть MT, и поэтому это будет проблемой.

В пн, 2 ноября 2020 г., 19:37 carlkl [email protected] написал:

Понятия не имею, это проблема / MT
https://stevedower.id.au/blog/building-for-python-3-5-part-two все еще
действительно, но это следует учитывать.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/numpy/numpy/issues/16744#issuecomment-720682011 или
отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ABKTSRJIVAQLECK4E2EVSSDSN4C65ANCNFSM4OP5IXNQ
.

Какие-либо рекомендуемые обходные пути для этой проблемы? Моя ситуация такова, что я нахожусь на машине, обновленной до обновления 2004 года, и у меня есть настольное программное обеспечение, которое использует pip для установки numpy / scipy / pandas и т. Д. Все это программное обеспечение подвержено этой проблеме, вызванной обновлением Microsoft.

Любые рекомендации будут оценены, потому что использование conda для установки numpy не является вариантом для программного обеспечения, над которым я работаю.

Если вам не нужен докер, вы можете закрепить 1.19.3. Он проходит все тесты в моих системах Windows.

Благодарю. 1.19.3 работает с пипсом по этой проблеме.

Ссылка в обнаружении плохого BLAS приводит к появлению множества шумных сообщений на сайте MS. Надеюсь, это не взорвется.

Я полагаю, что другой альтернативой является использование стороннего fmod на Win64.

Интересно, какова была бы реакция, если бы в NumPy была нефиксированная настолько серьезная ошибка в течение четырех месяцев после выпуска, особенно если бы мы не предоставили пользователям четких инструкций по переходу на предыдущую версию. Пользователи могут легко закрепить на 1.19.3, но это не решит проблему, это только переместит его в другой пакет, который использует регистры, после того, как они были испорчены: возможно scipy, может быть tenorflow.

Еще одна идея обходного пути: посмотрите, есть ли в ucrt какие-либо другие функции, которые используют FPU и оставляют его состояние в хорошем состоянии. Если он есть, мы могли бы вызвать его после fmod. Это имело бы преимущество перед обходным путем сборки,

Я не думаю, что мы должны прилагать больше усилий для решения этой проблемы. Любая дополнительная работа, которую мы выполняем для устранения проблемы, отнимет у разработчиков драгоценное время и снизит давление на Microsoft, чтобы исправить это. Кроме того, как упоминалось выше, любой код в других проектах, который вызывает fmod и / или использует регистры, может столкнуться с этой проблемой без подключения к NumPy.

Я не думаю, что мы должны прилагать больше усилий для решения этой проблемы. Любая дополнительная работа, которую мы выполняем для устранения проблемы, отнимет у разработчиков драгоценное время и снизит давление на Microsoft, чтобы исправить это. Кроме того, как упоминалось выше, любой код в других проектах, который вызывает fmod и / или использует регистры, может столкнуться с этой проблемой без подключения к NumPy.

Видя реакцию на сообщение об ошибке, это явно не очень помогает. Он должен, например, предложить пользователям Windows, которые хотят использовать последние функции NumPy, следует использовать дистрибутив, который поставляется с MKL, а не с pip wheel. Он также должен включать ссылку на эту ветку.

Хотя ответственность за это, несомненно, лежит на MS, причинение неудобств пользователям, указывающим на чью-то вину, редко бывает хорошим способом для любых проектов сохранять добрую волю.

@bashtage Не совсем говоря о причинении боли. Мы могли бы удалить ссылку, и вместо этого пользователи попадали бы сюда, но мы должны предупредить пользователей, что при запуске в 2004 году нельзя доверять результатам, и если вы не можете доверять результатам вычислений, вам следует избегать вычислений на этой платформе.

Не совсем понимаю, что вы имеете в виду, говоря о причинении боли.

Импорт NumPy терпит неудачу, и обходного пути не предусмотрено. Для большинства пользователей было бы очень полезно, если бы список известных обходных путей был четко виден:

(a) Использование дистрибутива на основе MKL, такого как conda или Enthought Deployment Manager, который избегает этого, но в коде линейной алгебры
(b) Вернуться к NumPy 1.19.3, который поставляется с версией OpenBLAS, защищенной от ошибки. Этот вариант может не подходить для пользователей, работающих в контейнерах.
(c) Сборка из исходного кода. Этот вариант будет иметь низкоэффективный BLAS, но может быть подходящим в средах, где стороннее распространение не разрешено и либо используются контейнеры, либо требуется недавняя функция или исправление ошибок в NumPy.

Я не считаю неправильным привлекать внимание к ошибке fmod, но затем она отправляет пользователей на этот форум, как будто их ждет какое-то решение.

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

Это не вариант. Пользователям нужно только избегать NumPy + OpenBLAS (например, 0.3.12). Им не нужно избегать NumPy + Windows (2004 / 20H2 (сейчас затронуты 2 выпущенные версии)).

Распределение на основе MKL

Сообщалось также о проблемах с МКЛ.

Вернуться к NumPy 1.19.3

Но это не решит других потенциальных проблем, связанных с использованием fmod. Проблема в том, что невозможно быть уверенным в правильности результатов.

Людям не следует использовать Python в 2004 году, может быть, вместо этого используйте WSL? Я также был бы в порядке с включением более старого ucrt с колесами Windows, если бы это было возможно, но как насчет других проектов? Есть ли простой способ вернуться к более ранним версиям Windows?

Сообщалось также о проблемах с МКЛ.

У NumPy нет теста, который не прошел бы на MKL. Трудно предположить наличие проблемы, когда не сообщается о сбоях. Ошибка fmod не проявляется в BLAS MKL (предположительно потому, что он не использует FPU).

Но это не решит других потенциальных проблем, связанных с использованием fmod. Проблема в том, что невозможно быть уверенным в правильности результатов.

Нет, но он также не исправит проблем с безопасностью Windows или многих других ошибок. Проблема здесь очень особенная.

1. fmod хорош тем, что дает правильные результаты
2. Чтобы столкнуться с этой проблемой, вам потребуется код, написанный на ассемблере, поскольку системный компилятор не создает код x87.

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

Я также считаю разумным выпустить исправление, поскольку, если бы OpenBLAS 0.3.12 работал так, как ожидалось, был бы выпущен NumPy, и эта проблема никогда не была бы затронута пользователями.

Людям не следует использовать Python в 2004 году, может быть, вместо этого используйте WSL? Я также был бы в порядке с включением более старого ucrt с колесами Windows, если бы это было возможно, но как насчет других проектов? Есть ли простой способ вернуться к более ранним версиям Windows?

Я подозреваю, что для многих это не вариант для многих: корпоративных пользователей на корпоративном компьютере, начинающих студентов (которым следует использовать conda) или всех, кто купил ноутбук с 2004 или 20H2, кто не может перейти на более раннюю версию.

Обратите внимание, что Condas numpy не только упакован, связанный с MLK, он также уже поставляет свою собственную версию ucrtbase.dll которая является более старой версией (10.0.17134.12)

В целом согласен с

@jenshnielsen : Обратите внимание, что не только Condas numpy упакован, связан с MLK [...]

Сборки, упакованные conda-forge, позволяют исключить реализацию blas / lapack (из openblas / mkl / blis / netlib), она не _обязательно_ быть MKL.

Людям не следует использовать Python в 2004 году, может быть, вместо этого используйте WSL?

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

Я также был бы в порядке с включением более старого ucrt с колесами Windows, если бы это было возможно, но как насчет других проектов?

За другие проекты мы не несем ответственности.

Есть ли простой способ вернуться к более ранним версиям Windows?

Если вы выполнили новую установку или очистили дисковое пространство, это станет практически невозможно.

В целом согласен с

Я согласен. Если мы этого не исправим, мы можем потерять много пользователей.

Я также был бы в порядке с включением более старого ucrt с колесами Windows, если бы это было возможно, но как насчет других проектов?

@charris , это не поможет в Windows 10. Если вы развернете другой ucrt вместе с python или numpy, он никогда не будет загружен в Windows 10. Этот метод применим только к более старым версиям Windows (Windows 7, 8, 8.1).

@carlkl
Упакованный в conda python фактически вмешивается в разрешение пути поиска DLL (которое - без изменений - предположительно может быть причиной, по которой вы говорите, что он никогда не может работать в Windows 10), и это AFAICT также причина, по которой conda _does_ предоставляет ucrtbase.dll , как пишет @jenshnielsen .

@ h-vetinari, В развертывании Universal CRT четко указано:

_Существуют два ограничения на локальное развертывание, о которых следует помнить:
В Windows 10 универсальный CRT в системном каталоге всегда используется, даже если приложение включает локальную копию универсального CRT. Это правда, даже когда локальная копия новее, потому что универсальная CRT является основным компонентом операционной системы Windows 10._

Кстати: я сам это тестировал. Нет возможности загрузить другой UCRT, кроме доступного UCRT, развернутого с Windows 10.

Я тоже считаю разумным выпустить исправление

под этим я думаю вы имеете в виду добавление PR gh-17547?

Доказательство точки зрения @carlkl :

Эта ошибка, вызванная самой MS, должна называться Heisenbug . Найти причину было сложно и дорого: Windows 2004 UCRT fmod оставляет регистры FPU в неправильном состоянии при определенных обстоятельствах. Это может привести к ошибкам численных расчетов намного позже при повторном использовании FPU. Ошибки вычислений обычно не появляются в кодах пользователей, если они не были тщательно проверены. Это может означать, что значительные численные ошибки остаются незамеченными в течение длительного времени. Хуже быть не могло.

под этим я думаю вы имеете в виду добавление PR gh-17547 ?

Извините, я неправильно написал.

Единственное изменение, которое я предлагаю, заключается в том, что NumPy предоставляет больше информации в исключении, возникающем при импорте, которое предлагает способы, с помощью которых пользователь может получить среду в Windows 2004 / H2, которая позволила бы им продолжить свою работу / школу / хобби.

1. WSL
2. conda / enthought
3. 1.19.3
4. Сборка из исходников

[Я предпочитаю этот заказ с точки зрения качества решения]

Я думаю, что было бы также иметь смысл связать эту проблему или проблему, которая немного чище и дает более глубокое объяснение. Эта вторая ссылка также может относиться к некоторым примечаниям к выпуску в документации, а не к проблеме с github.

Сборки, упакованные conda-forge, позволяют исключить реализацию blas / lapack (из openblas / mkl / blis / netlib), она не _обязательно_ быть MKL.

@ h-vetinari Проходят ли сборки conda-forge + OpenBLAS тесты на 2004 / H2?

Я только что проверил, и coda-forge поставляет OpenBlas 0.3.12. Значит, это приводит к сбою контейнеров?

Использование метода восстановления состояния FPU с помощью инструкции EMMS в OpenBLAS-0.3.12 должно, конечно, помочь очистить тесты numpy и scipy, но, как заявил @charris, вызов fmod(0,x) in Также могут произойти инструкции CPython, а затем инструкции FPU, вызываемые позже (в другом пакете, чем OpenBLAS). В этом случае проблема только переносится в другое место.

Лучше всего заставить MS исправлять ошибочное поведение. Может, Стив Дауэр сможет помочь?

Это также может быть интересная история для Агнера Фога или, может быть, Брюса Доусона: см., Например, эту историю в его блоге:
Все старое снова новое и ошибка компилятора

Вероятно, ошибка в OpenBlas 0.3.12. Обратите внимание на столбец Private Bytes:

Вероятно, по умолчанию установлено 24 потока BLAS, поскольку у меня 24 логических процессора.

Это OpenBLAS 0.3.12 с NumPy 1.19.2 от conda-forge.

Установка $env:OPENBLAS_NUM_THREADS=1 приводит к резкому снижению

И с потоками $env:OPENBLAS_NUM_THREADS=4 :

@bashtage : не могли бы вы продолжить обсуждение OpenBLAS 0.3.12 в OpenBLAS xianyi / OpenBLAS # 2970?

@mattip Я пытался определить, была ли conda + OpenBLAS надежной альтернативой. Я не думаю, что это решает что-то, что решает 1.19.3, увидев эти результаты.

@bashtage : Доказательство точки зрения @carlkl :

Поскольку python, упакованный в conda, активно обходит стандартное разрешение DLL Windows, я не уверен, насколько надежным будет инструмент Windows. Я столкнулся с этой проблемой, например, с устаревшим libcrypto.dll в C:\Windows\System32 , см., Например, https://github.com/conda-forge/staged-recipes/pull/11452. Короче говоря, устаревшая системная библиотека была обнаружена только в результате сбоя теста в тестовом наборе cryptography , а затем - с помощью CONDA_DLL_SEARCH_MODIFICATION_ENABLE - можно было принудительно использовать предоставленный conda openssl.

@bashtage : @ h-vetinari Проходят ли сборки conda-forge + OpenBLAS тесты на 2004 / H2?

CI, который собирает пакеты, по-видимому, не в такой текущей версии, и мне потребовалось немного времени, чтобы собрать его самому. Сейчас я использую машину 2004 года выпуска, и это - очень положительный - результат **:

= 10487 passed, 492 skipped, 19 xfailed, 1 xpassed, 227 warnings in 529.08s (0:08:49) =

@bashtage : Я только что проверил, и conda-forge поставляет OpenBlas 0.3.12. Значит, это приводит к сбою контейнеров?

conda-forge не поставляется с какой-либо фиксированной версией openblas - версия blas может даже быть "горячей" заменой (например, между openblas, mkl, blis), так что версия не имеет большого значения. Как правило, он будет использовать самую последнюю упакованную версию. Я не могу проверить, воспроизводится ли сбой в контейнерах или нет.

@bashtage :: @mattip Я пытался определить, является ли conda + OpenBLAS надежной альтернативой. Я не думаю, что это решает что-то, что решает 1.19.3, увидев эти результаты.

Увеличение памяти произошло из-за изменения в openblas 0.3.12, как описано далее в xianyi / OpenBLAS # 2970. Пока что conda-forge кажется мне надежной альтернативой - по крайней мере, ошибка не затронута напрямую.

** Я использовал текущий мастер https://github.com/conda-forge/numpy-feedstock , который все еще находится на версии 1.19.2, в сочетании с openblas 0.3.12. Я мог бы также попробовать https://github.com/conda-forge/numpy-feedstock/pull/210 + openblas 0.3.12, если людям интересно.

Хорошие новости: MS вернулся на форум VS и предположил, что исправление может быть выпущено к концу января 2021 года. Учитывая это обновление, я думаю, единственный вопрос заключается в том, есть ли какое-либо значение в обновлении сообщения об ошибке, которое появляется, обнаружена глючная функция.

Поскольку python, упакованный в conda, активно обходит стандартное разрешение DLL Windows, я не уверен, насколько надежным будет инструмент Windows. Я столкнулся с этой проблемой, например, с устаревшим libcrypto.dll в C:\Windows\System32 , см., Например, conda-forge / staged-recipes # 11452 . Короче говоря, устаревшая системная библиотека была обнаружена только в результате сбоя теста в тестовом наборе cryptography , а затем - с помощью CONDA_DLL_SEARCH_MODIFICATION_ENABLE - можно было принудительно использовать предоставленный conda openssl.

conda create -n cf -c conda-forge python numpy pytest hypothesis blas=*=openblas openblas=0.3.9 -y
conda activate cf
python -c "import numpy as np;np.test('full')"

выходы

C:\Anaconda\envs\cf\lib\site-packages\numpy\linalg\linalg.py:94: LinAlgError
---------------------------------------------------------------------- Captured stdout call ----------------------------------------------------------------------
 ** On entry to DGEBAL parameter number  3 had an illegal value
 ** On entry to DGEHRD parameter number  2 had an illegal value
 ** On entry to DORGHR DORGQR parameter number  2 had an illegal value
 ** On entry to DHSEQR parameter number  4 had an illegal value

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

Только openblas = 0.3.12 из conda forge пройдет тесты, но это то же самое, что и в NumPy 1.19.3.

Что говорит против новой версии numpy, скомпилированной с отключенным OpenBLAS-0.3.12? Уменьшенный размер буфера и, возможно, уменьшенное количество потоков во время компиляции OpenBLAS, используемого для numpy. Это должно снизить потребление памяти OpenBLAS и должно помочь не только в тестовом сценарии Docker, но и пользователям с менее оснащенным оборудованием.
окна коробки.

Здесь из отчета об ошибке https://tinyurl.com/y3dm3h86 изнутри Python. Во-первых, спасибо за предоставление версии, которая на данный момент работает в Windows (1.19.3).

Я понимаю, что 1.19.3 не работает в Linux, а 1.19.4 не работает в Windows (пока есть ошибка).

Можно ли сделать последнюю версию на pypi 1.19.3 для Windows и 1.19.4 для всех других платформ? Другими словами, просто удалите https://files.pythonhosted.org/packages/33/26/c448c5203823d744b7e71b81c2b6dcbcd4bff972897ce989b437ee836b2b/numpy-1.19.4-cp36-cp36m-win_amd649 amd64.whd полностью 3.649 amd / 3.649 amd / 3.649 amd / 3.649 amd649 amd / 3.649 amd649 amd. теперь?

@luciansmith Пока доступен исходный код для 1.19.4, pip будет пытаться использовать эту версию, если не переданы дополнительные флаги. Я думаю, что большинство пользователей передали бы дополнительные флаги только в том случае, если бы знали о проблеме, но тогда они могли бы просто закрепить 1.19.3.

Я бы предпочел иметь версию 1.19.5, которая использует OpenBLAS 0.3.9 в Linux и 0.3.12 в Windows, но я не знаю, возможно ли это.