Numpy: Пакет колеса Windows (.whl) на Pypi

Хорошо сказано - и действительно, @carlkl проделал большую работу за кулисами, чтобы это произошло. Я полагаю, что мы уже почти у цели - @carlkl - когда вы станете публичной, как вы думаете?

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

Я развернул недавние колеса numpy и scipy на основе OpenBLAS на binstar. Вы можете установить их с помощью:

pip install -i https://pypi.binstar.org/carlkl/simple numpy
pip install -i https://pypi.binstar.org/carlkl/simple scipy

Это работает для python-2.7 и для python-3.4. Колеса имеют пометку «экспериментальные». Обратная связь приветствуется.

Если вы хотите широкомасштабное тестирование, вы должны отправить это в список :-)

В четверг, 22 января 2015 г., в 20:54, [email protected] написал:

Я развернул недавние колеса numpy и scipy на основе OpenBLAS на binstar.
Вы можете установить их с помощью:

pip install -i https://pypi.binstar.org/carlkl/simple numpy
pip install -i https://pypi.binstar.org/carlkl/simple scipy

Это работает для python-2.7 и для python-3.4. Колеса имеют маркировку
«экспериментальный». Обратная связь приветствуется.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-71096693 .

Натаниэль Дж. Смит
Постдокторант - Информатика - Эдинбургский университет
http://vorpus.org

fwiw Лично я хотел бы изменить размер целого числа по умолчанию в win64, прежде чем мы на самом деле предоставим официальные двоичные файлы, хотя было некоторое сопротивление, когда я в последний раз предлагал это, также, возможно, с anaconda и другими сторонними двоичными файлами, вероятно, уже слишком поздно: (

также говоря об openblas, кому-то нравится отладка, я устал от этого (похоже на тот же сбой, который ломает scipy с openblas):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== Invalid read of size 16
==31931==    at 0x7B28EB9: ddot_k_NEHALEM (in /usr/lib/libopenblasp-r0.2.10.so)
==31931==    by 0x6DBDA90: DOUBLE_dot (arraytypes.c.src:3127)
==31931==    by 0x6E93DEC: cblas_matrixproduct (cblasfuncs.c:528)
==31931==    by 0x6E6B7B3: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931==    by 0x6E6E29B: array_matrixproduct (multiarraymodule.c:2276)

Используемая версия OpenBLAS — 0.2.12. У меня еще не было серьезных проблем с этой версией.

Ошибки scipy копируются на https://gist.github.com/carlkl/b05dc6055fd42eba8cc7.

32-битные только сбои numpy из-за http://sourceforge.net/p/mingw-w64/bugs/367

======================================================================
FAIL: test_nan_outputs2 (test_umath.TestHypotSpecialValues)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath.py", line 411, in test_nan_outputs2
    assert_hypot_isinf(np.nan, np.inf)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath.py", line 402, in assert_hypot_isinf
    "hypot(%s, %s) is %s, not inf" % (x, y, ncu.hypot(x, y)))
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 53, in assert_
    raise AssertionError(smsg)
AssertionError: hypot(nan, inf) is nan, not inf

======================================================================
FAIL: test_umath_complex.TestCabs.test_cabs_inf_nan(<ufunc 'absolute'>, inf, nan, inf)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\nose\case.py", line 197, in runTest
    self.test(*self.arg)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath_complex.py", line 523, in check_real_value
    assert_equal(f(z1), x)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 275, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 739, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 628, in assert_array_compare
    chk_same_position(x_isnan, y_isnan, hasval='nan')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 608, in chk_same_position
    raise AssertionError(msg)
AssertionError: 
Arrays are not equal

x and y nan location mismatch:
 x: array([ nan])
 y: array(inf)

======================================================================
FAIL: test_umath_complex.TestCabs.test_cabs_inf_nan(<ufunc 'absolute'>, -inf, nan, inf)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\nose\case.py", line 197, in runTest
    self.test(*self.arg)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath_complex.py", line 523, in check_real_value
    assert_equal(f(z1), x)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 275, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 739, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 628, in assert_array_compare
    chk_same_position(x_isnan, y_isnan, hasval='nan')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 608, in chk_same_position
    raise AssertionError(msg)
AssertionError: 
Arrays are not equal

x and y nan location mismatch:
 x: array([ nan])
 y: array(inf)

Я не возражаю против изменения целочисленного размера win64, но я думаю, что это
отдельная тема, которую следует отвязать от колес. Если бы это был
первый раз, когда сборки win64 numpy стали широко доступны, тогда он
имеет смысл связать их, но на данный момент уже есть тонны пользователей
в течение многих лет они просто используют cgholke или anaconda или что-то еще. Итак, начнем
рассматривать это как независимую дискуссию?

(Строго говоря, это бэккомпат-брейк, но даже в этом случае он кажется разумным.
что мы могли бы справиться с этим, поскольку это на самом деле уменьшает
несовместимость между платформами - весь переносимый код должен обрабатывать 64-битные
dtype=int уже.)

В четверг, 22 января 2015 г., в 20:59, Джулиан Тейлор, [email protected]
написал:

Между прочим, я лично хотел бы изменить размер целого числа по умолчанию в
win64 до того, как мы на самом деле предоставили официальные двоичные файлы, хотя
сопротивление тоже, когда я в последний раз предложил это, также, возможно, с анакондой и
другие сторонние двоичные файлы, вероятно, уже слишком поздно :(

также говоря об openblas, кто-то хочет немного отладки, я устал от этого
(похоже на тот же сбой, который ломает scipy с openblas):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== Неверное чтение размера 16
==31931== по адресу 0x7B28EB9: ddot_k_NEHALEM (в /usr/lib/libopenblasp-r0.2.10.so)
==31931== по 0x6DBDA90: DOUBLE_dot (arraytypes.c.src:3127)
==31931== от 0x6E93DEC: cblas_matrixproduct (cblasfuncs.c:528)
==31931== по 0x6E6B7B3: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931== по 0x6E6E29B: array_matrixproduct (multiarraymodule.c:2276)

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-71097408 .

Натаниэль Дж. Смит
Постдокторант - Информатика - Эдинбургский университет
http://vorpus.org

Я также заинтересован в этом. Есть ли способ помочь в этом процессе?

OpenBLAS можно скомпилировать с INTERFACE64=1 , а numpy можно скомпилировать с -fdefault-integer-8 для первой попытки.

Просто на голову. Использование 64-битных целых чисел в blas — ужасная идея. Остановитесь, пока не зашли слишком далеко по этой дороге. Matlab и Julia до того, как я пошел и исправил это, сделали это, и это сломало любую стороннюю библиотеку, которая предполагает обычные 32-битные целые числа в blas.

То, что мы делали в Julia в течение последних ~ 5 месяцев, на самом деле переименовывали все символы в openblas, чтобы добавить к ним суффикс _64 для 64-битной версии int, таким образом, вы можете выполнять линейную алгебру. на действительно огромных массивах, если хотите, но загрузка внешних библиотек в тот же процесс не приведет к сбою из-за затенения имени и попытки вызвать dgemm с неправильным ABI.

Эй, ребята, есть ли какое-либо обновление файлов колес, доступных для Numpy?

Не то чтобы я сейчас в курсе.
25 июня 2015 г., 4:27, «guyverthree» [email protected] написал:

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

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-115215236 .

@guyverthree Кристоф Гольке уже некоторое время выпускает NumPy, используя Intel MKL в качестве колес .

Также см. мой пост в блоге о колесах NumPy . Я сделал несколько колес NumPy в своем Dropbox, используя модифицированную цепочку инструментов mingw-w64 Карла Клеффнера и порт GotoBLAS для OpenBLAS Чжана Сяньи . Оливье Гризель искал помощь в модификации бота сборки NumPy, чтобы он повторял те же шаги, что и в ветке групп Google OpenBLAS, которую я публикую в .

Моя последняя версия доступна на binstar.org, хотя я не уверен, что сейчас anaconda.org является новым предпочтительным именем.
Колеса для ру-2.6..3.4 (32/64бит) около 2-х месяцев:

• numpy-1.9.2
• scipy-0.15.1
• scikit-изображение-0.11.2

построить с моим https://bitbucket.org/carlkl/mingw-w64-for-python и более или менее свежим OpenBLAS.
установка пипа:

• pip install -i https://pypi.binstar.org/carlkl/simple numpy
• pip install -i https://pypi.binstar.org/carlkl/simple scipy

+1 @carlkl, и я бы хотел, чтобы их можно было добавить и в сборку NumPy на сыроварне.

+1 Я бы тоже хотел, чтобы это произошло.

ИМХО: нужно решить как минимум три проблемы, прежде чем эти сборки будут приняты:

• патчи mingwpy для репозитория numpy должны быть воссозданы
• пока нет механизма сборки, кроме сборки вручную
• многие сторонние пакеты Windows (деполированные C. Gohlke) явно зависят от numpy-MKL, потому что двоичные файлы жестко связаны с DLL MKL. Это может измениться в будущем, так как scipy теперь предоставляет механизм неявной зависимости от реализации scipy BLAS/Lapack. Таким образом, установка (numpy-MKL и scipy-MKL) ИЛИ (numpy-OpenBLAS и scipy-OpenBLAS) должна быть достаточной для всех других пакетов в будущем.

@carlkl : FWIW, меня не очень беспокоят пакеты @cgohlke - они разберутся сами собой (точно так же, как сейчас нет серьезных проблем из-за того, что люди пытаются объединить scipy-MKL с anaconda numpy). И я даже не очень беспокоюсь о том, что есть какой-то причудливый механизм сборки — ручная сборка хороша, если есть текстовый файл, документирующий шаги.

Основная проблема, которая меня беспокоит, — это устойчивость: если мы не сможем получить этот материал вверх по течению, нам придется перепроверять и повторно делать исправления каждый раз, когда выходит новая версия gcc / mingw-w64 / msvc. выйдет, и, вероятно, этого не произойдет. Мы не хотим попасть в ловушку, когда начинаем предоставлять сборки, но со временем это становится все более и более обременительным, поскольку для этого нам приходится иметь дело с капризным старым компилятором.

Вот почему я пытался собрать финансирование для поддержки этого восходящего потока... +1 - это здорово и все такое, но если кто-то хочет пожертвовать немного денег или знает компанию, которая может быть заинтересована в том, чтобы сделать gcc общедоступным для python расширения для Windows, а затем пришлите мне письмо :-) ([email protected])

Если у вас нет $$, но вы все равно хотите помочь, то один из способов сделать это — отправить исправления в mingw-w64, улучшающие их поддержку трансцендентных функций, таких как sin и cos. (Оказывается, MSVC ABI не согласен со всеми остальными относительно того, как должен быть сконфигурирован блок x87 FPU, поэтому большинство математических функций бесплатного программного обеспечения работают не совсем правильно.) К счастью , в Android есть хорошие, совместимые с лицензией реализации. bionic" libc , так что это не требует никакого математического волшебства или глубокого понимания проблем ABI - это просто механический вопрос поиска и извлечения соответствующих исходных файлов, а затем добавления их в дерево mingw-w64 в нужное место. Мы также можем предоставить более подробную информацию об этом, если кому-то интересно.

Разве это не то, что numfocus должен финансировать? Если нет, то, возможно, мы можем вернуться и вернуться к подаче заявления в PSF.

О каких деньгах мы говорим?

+1 пожалуйста, опубликуйте колеса для Windows в PyPI https://pypi.python.org/pypi/numpy

Если вы попробуете pip install numpy в готовой установке Python для Windows, вы получите печально известное бесполезное сообщение об ошибке «Не удалось найти vcvarsall.bat».

+1 действительно поможет пользователям Windows.

Из-за этого не могу играть с https://github.com/glumpy/glumpy . Каковы шаги ручной сборки, чтобы заставить Numpy работать в Windows? Похоже, работа AppVeyor есть , так что не должно быть проблем с загрузкой артефактов на GitHub .

Прямо сейчас буквально невозможно создать быструю версию numpy с лицензией BSD для Windows. Мы работаем над исправлением этого, но это техническое ограничение; +1 ни на что не повлияют. (Задание appveyor основано на Windows, но использует резервную неоптимизированную библиотеку линейной алгебры, которая не совсем подходит для реальной работы.) Пока мы не разберемся с этим, я бы рекомендовал загрузить колеса с веб-сайта Кристофа Гольке или использовать Anaconda. или другой научный дистрибутив Python .

@njsmith можно поконкретнее? Желательно с точными командами, которые не работают. Сейчас этот материал недействителен.

Я думаю, что «невозможно» — это слишком сильно, но пока нет очевидного общего пути вперед. Я разместил здесь вики-страницу с текущим статусом: https://github.com/numpy/numpy/wiki/Whats-with-Windows-builds . Пожалуйста, не стесняйтесь редактировать / исправлять всех, кому это нужно.

@techtonik : нет «точных команд, которые не работают», проблема в том, что нет компиляторов, обладающих нужным нам сочетанием функций. mingwpy.github.io документирует текущий статус наших усилий по созданию такого компилятора.

@matthew-brett хорошо. We can't use MSVC++ on its own to compile scipy because we need a Fortran compiler. Это для scipy, верно? Зачем это нужно для numpy?

@njsmith http://mingwpy.github.io/issues.html — отличная инициатива с хорошим анализом. Жаль, что апстрим (Python) никогда не будет его поддерживать (вслепую продвигает использование MSVS). Но я пытаюсь получить четкое представление о текущем состоянии.

1. это проблема «наличия открытой цепочки инструментов для открытой работы» или MSVS действительно не может скомпилировать C-часть numpy?
2. есть ли еще сбои с расширениями, скомпилированными mingw?

Чтобы сузить фокус, скажем, это только Python 2.7 + Win32. Производительность не требуется (я просто хочу запустить приложение, чтобы протестировать его там), но необходимы контрольные данные об этой производительности.

Итак, какое следующее действие необходимо выполнить для этой конфигурации, чтобы колесо Windows стало доступным из PyPI?

@techtonik , теперь предварительные версии колес numpy и scipy доступны на https://anaconda.org/carlkl/numpy и https://anaconda.org/carlkl/scipy. Производительность почти такая же, как у колес gohlke +MKL. Я не сталкивался с segfaults с моей коробкой Windows дома.

Несколько вопросов, связанных с этим подходом, уже обсуждались, и их можно обобщить на http://mingwpy.github.io (в разработке). Комбинация цепочки инструментов на основе mingw-w64 под названием _mingwpy_ и OpenBLAS — это то, что нужно для платформы Windows.

_mingwpy_ имеет специальную конфигурацию, которая обеспечивает лучшую совместимость и более удобное использование по сравнению с наиболее известными наборами инструментов на основе mingw-w64, т.е. _mingw-builds_, _tdm_ ...

Все это и многое другое объясняется на https://github.com/mingwpy/mingwpy.github.io. Не стесняйтесь открывать вопросы или PR там.

@techtonik : я думаю, что это серьезное недоразумение / искажение позиции вышестоящего python.org. Я бы сказал, что они отказываются продвигать раскол поддержки Windows CPython на несколько несовместимых ABI (и я с ними согласен в этом). Стив Дауэр, который поддерживает официальные сборки Windows основной ветки разработки, помогает нам понять, как сделать mingwpy совместимым с этими сборками.

IMO обязательным условием для установки numpy Wheels на pypi является то, что они должны быть (а) производительными, (б) ремонтопригодными, (в) иметь соответствующую лицензию. Если вы хотите, чтобы проект применял другой набор критериев (например, мы должны приложить усилия для обеспечения колес с ужасной производительностью), то следующим шагом будет отправить электронное письмо в список рассылки numpy, подтверждающий, что ваши критерии лучше.

MSVS может построить сам numpy, но не может построить ни одну из высококачественных реализаций BLAS с соответствующей лицензией. Upstream mingw-w64 может собирать numpy + BLAS (с исправлениями), но результат будет аварийным, если вы попытаетесь использовать его с вышестоящим CPython. Цепочка инструментов Carl mingwpy может собирать numpy + BLAS (с исправлениями), и результат будет работать на некоторых версиях python (но не 3.5), но цепочка инструментов хрупкая и неподдерживаемая в ее текущем состоянии; буквально никто, кроме Карла, не знает, как он был построен, и не может его воссоздать. Никто в проекте numpy не готов взять на себя обязательства по предоставлению «официальных сборок» с использованием цепочки инструментов с этими ограничениями, поэтому мы сосредоточены на их исправлении.

Существует несколько тривиально доступных источников высококачественных сборок numpy в Windows. Мне искренне любопытно: почему вы так настаиваете на том, чтобы мы выбрасывали некачественные сборки только для того, чтобы они были на PyPI?

@njsmith Просто хотел заявить, что мой вариант использования (который, я признаю, никоим образом не оправдывает вложения ресурсов разработчика сам по себе) заключается в распространении очень простого пакета на PyPI, который зависит от matplotlib , что, в свою очередь, зависит от numpy .

Для моего варианта использования производительность не является проблемой, но возможность иметь пользователя Windows просто pip install ____ мой пакет, который рекурсивно устанавливает matplotlib , numpy и т. д., намного проще объясните, чем указывать им URL-адреса для установки, особенно для пользователей, которые не понимают экосистему сборки Python. Так что это в основном для упрощения инструкций по установке.

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

@johnthagen : О, конечно, не беспокойтесь! Я полностью понимаю, почему это вообще желательно; если я кажусь сварливым в этих комментариях, то это именно потому, что я и другие тратили огромное количество времени за последний год, пытаясь исправить это :-). Я просто спросил @techtonik специально, потому что это звучало так, как будто они говорили: «Я просто хочу попробовать одно маленькое приложение, поэтому меня не волнует производительность», но если они просто хотят попробовать одно маленькое приложение, я не знаю, почему они заботятся о части PyPI :-)

(Важно иметь в виду, что любое колесо, которое мы установим на pypi, немедленно начнет использоваться десятками тысяч людей, большинство из которых не читают эту ветку. Поэтому я думаю, что мы обязаны убедиться, что все мы выкладываем, на самом деле будет широко использоваться для широкого круга вариантов использования.)

Я думаю, было бы тривиально начать поставлять 32-битные колеса для Python 2.7, используя ATLAS. Скорее всего, они должны быть SSE2, поэтому без инструкций SSE произойдет сбой, но это затронет лишь очень небольшую часть пользователей. Для этого мы могли бы использовать нашу цепочку инструментов текущей версии. Имейте в виду, что это будет означать, что pip предоставит двоичное колесо для 32-разрядной версии, но вернется к исходной установке для 64-разрядной версии. Было бы это полезно?

@njsmith Спасибо за информацию! Ценю всю вашу работу :)

Я думаю, было бы тривиально начать поставлять 32-битные колеса для Python 2.7, используя ATLAS. Скорее всего, они должны быть SSE2, поэтому без инструкций SSE произойдет сбой, но это затронет лишь очень небольшую часть пользователей. Для этого мы могли бы использовать нашу цепочку инструментов текущей версии. Имейте в виду, что это будет означать, что pip предоставит двоичное колесо для 32-разрядной версии, но вернется к исходной установке для 64-разрядной версии. Было бы это полезно?

@matthew-brett текущая настройка numpy-vendor нарушена, в fromfile есть segfault . Обработка дескриптора файла каким-то образом испорчена, и мы не уверены, связано ли это с изменением версии Wine, версии Ubuntu или (что маловероятно) с изменением самого numpy. Я бы сказал, что тратить больше времени на это — пустая трата времени — тратить это время на mingwpy намного продуктивнее.

У меня есть NumPy 1.10.4, скомпилированный как с OpenBLAS (Int32 Windows 64, предварительно скомпилированный двоичный файл v0.2.15), так и с MKL (используя лицензию сообщества на MKL, т.е. бесплатное распространение). Но... Я не могу скомпилировать SciPy - кажется, небольшая часть ищет компилятор gfortran "компилятор fortan не найден", если кто-нибудь знает, как решить эту проблему. Я использую ifort.exe, так как Ananconda поддерживает эти сборки как прямые плагины. Скомпилировано для Python 3.5 с Microsoft Visual Studio Community 2015, если кто-нибудь может помочь мне понять, как упаковать это для распространения... тогда я загружу на github или веб-сайт anaconda. Ценить это.

@mrslezak : вероятно, лучше всего опубликовать сообщение в списке рассылки разработчиков scipy или открыть новую ошибку в scipy, а не публиковать случайные существующие ошибки :-)

Мне искренне любопытно: почему вы так настаиваете на том, чтобы мы выбрасывали некачественные сборки только для того, чтобы они были на PyPI?

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

Уф. Наверное, самое длинное английское предложение, которое я написал за всю свою жизнь. знак равно

@techtonik - Я разделяю ваше разочарование, я думаю, что многие из нас разочарованы этим.

@carlkl - мне бы хотелось, чтобы вы оставили здесь отзыв.

На нас явно оказывается сильное давление, чтобы мы поставили колесо с пустыми окнами. Вот список самых загружаемых колес для любой платформы за пару недель назад: https://gist.github.com/dstufft/1dda9a9f87ee7121e0ee . колеса matplotlib, scikit-learn и pandas занимают позиции 3, 4 и 5. Будет большой рынок для колес numpy windows.

Я думаю, что вопросы на столе следующие:

1) Можем ли мы взять на себя обязательство получить работающее и почти оптимальное колесо numpy на pypi в краткосрочной и среднесрочной перспективе (скажем, 6 месяцев). Я бы сказал, что да (рад слышать несогласие);
2) Стоит ли тем временем ставить неоптимальное колесо numpy, чтобы другие могли строить против него?

Вопрос 2 самый сложный. «Неоптимальный» может означать медленный (нет оптимизированного blas/lapack) или сложный в поддержке (нет гарантии, что мы сможем повторить сборку через 6 месяцев).

Я вижу аргументы против "медленного". Мы должны быть осторожны, чтобы, когда колеса начинают работать для Windows, они не сразу вызывали вопросы о переполнении стека с ответами «Ни в коем случае не загружайте колеса numpy из pypi». Я думаю, что эти ответы были бы разумными, и они продержались бы достаточно долго, чтобы навредить нам.

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

Некоторое время назад я собрал двоичные файлы ATLAS для Windows: http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

Правильно ли я думаю, что мы уже можем создавать двоичные файлы numpy, которые проходят все тесты, используя эти двоичные файлы ATLAS?

В таком случае, почему бы нам их не поставить?

1) Можем ли мы взять на себя обязательство получить работающее и почти оптимальное колесо numpy на pypi в краткосрочной и среднесрочной перспективе (скажем, 6 месяцев). Я бы сказал, что да (рад слышать несогласие);

Я бы на это надеялся, иначе это означает, что к тому времени мы либо столкнемся с неожиданными проблемами с предложением mingwpy, либо не кэшируем то, что оно позволяет :)

2) Стоит ли тем временем ставить неоптимальное колесо numpy, чтобы другие могли строить против него?

Кажется, ваши сборки ATLAS сделаны с помощью Cygwin? Или это просто имя каталога, и вы использовали какую-то версию MingwPy?

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

У mingwpy нет проблем, но ему нужно время. Создание цепочки инструментов gcc, OpenBLAS, а затем numpy/scipy с различными вариантами требует времени на сборку и тестирование. И я не буду публиковать двоичные файлы без предварительной публикации всех скриптов сборки. Почти готов mingwpy на основе gcc-5.3.0, как и OpenBLAS. Следующим шагом будет создание колес numpy и scipy на основе этого.

Это обсуждение, а также последние материалы в ветке numpy «Колеса Linux с несколькими дистрибутивами — пожалуйста, протестируйте» приводят к вопросу, обладает ли OpenBLAS качеством, позволяющим развертывать колеса Windows numpy на основе OpenBLAS. Но я не уверен, что использование атласа лучше. Возможно, сначала нужно собрать numpy Wheels с обоими вариантами для этапа тестирования.

Я предполагаю/надеюсь, что мы каким-то образом дойдем до того, что OpenBLAS имеет приемлемое качество. Но до этого времени мне кажется разумным начать с колес ATLAS numpy, ожидая, что со временем мы сможем переключиться на колеса OpenBLAS. Возможно, нам придется включить проверку SSE2 для 32-битных сборок: http://mingwpy.github.io/blas_lapack.html#atlas

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

@matthew-brett, мне до сих пор не ясно, жизнеспособно ли ваше предложение что-то подбросить. Какой компилятор вы бы использовали? Если MingwPy, то у нас есть четкий план, в каком порядке делать и сейчас кажется слишком рано. Если еще один gcc, мы вернемся к проблеме статических ссылок и проблем с распространением DLL.

Моя идея состояла в том, чтобы скомпилировать numpy с ATLAS, используя MSVC. Конечно, это не сработает для scipy, но, по крайней мере, люди смогут начать поставлять свои колеса для окон, независимо от их конструкции.

Я только что попробовал это и получил несколько ошибок формы unresolved external symbol __gfortran_compare_string , поэтому я полагаю, что двоичные файлы ATLAS имеют некоторые оборванные ссылки на время выполнения gfortran. @carlkl - есть предложения по отладке?

Смешивания статических объектных файлов, полученных от разных компиляторов, следует избегать, как черт избегает святой воды. В некоторых случаях это работает, но для другого набора комбинаций компиляторов это не сработает.
Кстати: сама MS официально не поддерживает и не рекомендует смешивать статические объекты из разных версий их Visual Studio.

Я сделал несколько тестов несколько недель назад, когда возник вопрос: можно ли использовать статическую библиотеку npymath.a, созданную mingwpy, с компиляторами MSVC? В принципе , это может работать, если в эту библиотеку добавить некоторые выбранные объекты из библиотек времени выполнения gcc. Я пришел к выводу, что такой подход нестабилен и хрупок.

Если атлас - это вариант для создания колес, я бы попытался построить его как DLL, есть возражения?

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

Я чувствую, что на странице https://mingwpy.github.io/motivation.html (почему) не хватает какого-то очень простого и понятного объяснения проблемы для динамически загружаемых модулей . Я разговаривал с ребятами из Far Manager, чей файловый менеджер родной для Windows, построен на плагинах, которые загружаются из .dll, написанных на разных языках, и у них нет этой проблемы с "точно таким же компилятором". Интересно, почему у Python это есть - он также загружает модули из .dll.

@techtonik , мой комментарий был о связывании объектных файлов, созданных разными компиляторами, в один двоичный файл (DLL или EXE). Именно это я имел в виду под _смешиванием статических объектных файлов_. Такой подход _может_ работать в некоторых проверенных ситуациях, если обращаться с ним осторожно. Но это далеко не надежный способ создания двоичных файлов.

Интероперабельность DLL от разных компиляторов в общем пространстве процессов — это совсем другое дело. Обычно такой подход работает нормально, как правило. Необходимо убедиться, что эти двоичные файлы связаны с одной и той же DLL среды выполнения MS, если они, например, имеют общие файловые дескрипторы. Существуют и другие возможные проблемы с ABI, которые необходимо решить. И, конечно же, вам нужен другой набор отладчиков для отладки в зависимости от используемых компиляторов.

minwgpy — это проект поддержки создания расширений Python с помощью mingw-w64 для использования внутри стандартных сборок MSVC CPython.

ОК - мне удалось собрать numpy с привязкой MSVC к сборке ATLAS.

Сборка ATLAS здесь:

http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/atlas-3.10.1-sse2-32.tgz

Там есть несколько простых инструкций по сборке ATLAS dll.

Все тесты numpy проходят, кроме проверки сценария f2py , я думаю, что это доброкачественный сбой.

Последний шаг — поставка динамической библиотеки внутрь колеса. @carlkl - какой твой любимый способ сделать это сейчас?

Приятно слышать, я также хотел бы выяснить, как создать колесо с помощью
включены двоичные файлы - можно опубликовать сборку MKL и попросить других протестировать OpenBlas
один.
11 февраля 2016 г., 13:28, «Мэттью Бретт» [email protected] написал:

ОК - мне удалось собрать numpy с привязкой MSVC к сборке ATLAS.

Сборка ATLAS здесь:

http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/atlas-3.10.1-sse2-32.tgz

Там есть несколько простых инструкций, как собрать ATLAS.
dll.

Все тесты numpy проходят, кроме проверки скрипта f2py, я думаю, что это
доброкачественная недостаточность.

Последний шаг — поставка динамической библиотеки внутрь колеса. @карлкл
https://github.com/carlkl - какой ваш любимый способ делать сейчас
тот?

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-183021728 .

Последний шаг — поставка динамической библиотеки внутрь колеса.

А проверка SSE2 и изящная помощь?

@mrslezak - проще всего поместить его в папку numpy/core, так как он автоматически загружается в пространство процесса при импорте multiarray.pyd.

Последний шаг — поставка динамической библиотеки внутрь колеса.

@matthew-brett: я на 99% уверен, что «правильный» способ сделать это - использовать сборки SxS, документация которых крайне скудна, но, вероятно, выполнима ... Я знаю, что вы потратили время, пытаясь понять их, и я Я тоже читал, поэтому, если вы хотите в какой-то момент сесть и попытаться проработать детали, дайте мне знать :-).

(Проблема со всеми другими подходами заключается в том, что процессы Windows IIUC обычно поддерживают единое глобальное пространство имен для всех импортированных dll. Это означает, что если оба расширения отправляют файл с именем foo.dll, то любое расширение, загруженное первым, будет иметь свою версию. foo.dll "выиграет", и другое расширение в конечном итоге будет использовать его - классическая проблема "dll hell". И IIUC единственный способ избежать этого поведения - использовать механизм SxS, каким бы уродливым он ни был.)

Натаниэль - я описал свое понимание сборок SxS здесь: https://github.com/numpy/numpy/wiki/windows-dll-notes#side-by-side-assemblies

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

Ральф - предложение формализовать способ добавления хуков SSE2 и т. д. в процесс установки: https://github.com/numpy/numpy/pull/7231

@matthew-brett: Я читал эти заметки, да.... и, ох, безнадежно, почему? Из-за проблем с одним и тем же каталогом? И есть ли у вас какие-либо идеи о том, как выполнить это переименование? (Я еще не нашел никакого эквивалента patchelf --replace для файлов PE, а регенерация файлов .lib нетривиальна — хотя я думаю, что при использовании mingw-w64 это не так уж плохо, потому что вы можете напрямую ссылаться на .dll .По крайней мере, если вам не нужно переименовывать libgfortran или подобное...)

(Возможно, где-то в этом списке есть PE-эквивалент patchelf --replace : http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors)

Я не вижу проблем с загрузкой satlas.dll (или альтернативно libopenblaspy.dll ) вместе с multiarray.pyd, так как этот каталог предпочтительнее при поиске DLL. Такой подход работает за счет того, что эта DLL загружается через LoadLibraryEx из python в пространство процесса. Должна использоваться папка numpy/core , так как это самое первое появление зависимого от blas расширения Python во время импорта. Любые дальнейшие попытки загрузить DLL с тем же именем просто игнорируются, поскольку эта DLL уже загружена в пространство процесса. Windows просто ищет имя DLL BTW.

Начало ада DLL Если такая библиотека зависит от _дальнейших_ DLL, но это не так, поскольку и satlas.dll , и libopenblaspy.dll являются автономными и зависят только от стандартных системных DLL Windows. Это то, что обычно называют статически связанными DLL - это означает, что код среды выполнения gcc статически связан.

_Для сравнения_: чтобы импортировать библиотеки MKL, можно временно расширить PATH до numpy/core . К сожалению, это не удается, если старые библиотеки MKL размещены в системных папках Windows.

@matthew- brett @njsmith : Переименование DLL: для чего это нужно?

@carlkl : нас беспокоит случай, когда numpy включает atlas.dll , а также scipy включает atlas.dll , и в какой-то момент пользователь обновляет scipy (и получает более новую версию atlas.dll ), но затем scipy использует старую версию atlas.dll из пакета numpy. Это плохо, потому что scipy может зависеть от наличия более новой версии, поэтому все будет случайным образом ломаться в зависимости от того, какие именно сборки каких пакетов задействованы, и в каком порядке пользователь их импортирует. Это происходит потому, что если numpy включает в себя DLL с именем atlas.dll , то это «заявит» имя atlas.dll в пространстве имен DLL для всего процесса и заблокирует любые другие пакеты от использования других DLL с этим название.

Два возможных решения: (а) если можно заставить работать материал SxS/activation-contexts, он предоставляет способ отключить пространство имен DLL для всего процесса или (б) если numpy содержит numpy-atlas.dll , а scipy содержит scipy-atlas.dll , то они могут использовать одно и то же пространство имен для всего процесса без конфликтов.

Или оба зависят от отдельного пакета clib_atlas , который предоставляет dll? Затем требования зависимости от версии могут быть выражены, как обычно для пакетов Python.

@tkelman : Нам нужно выяснить, как поддерживать как сторонние библиотеки DLL, так и отдельно распространяемые библиотеки DLL, я думаю, поскольку оба варианта подходят в разных ситуациях. А с вендорным корпусом начинать намного проще :-)

Я считаю, что параллельное решение потребует прав администратора для установки в Windows system32. Пожалуйста, не делайте этого.

Существуют также «частные» параллельные сборки, в которых сборки располагаются в вашем собственном двоичном дереве, но существует ограничение в два маркера пути в верхнем каталоге, которые вы можете использовать для указания на сборку, т. е. вы можете указать на ..\..\some_assembly но не ..\..\..\some_assembly .

Так, например, scipy/first/second/third/something.pyd может указывать на параллельную сборку только в каталогах third или second или first , но не в scipy (или другие каталоги внутри этого.

Хорошо, я построил несколько колес для тестирования, вот:

http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

Как обычно:

pip install -f https://nipy.bic.berkeley.edu/scipy_installers/atlas_builds numpy

Очень грубая автоматизация сборки здесь: https://github.com/matthew-brett/np-wheel-builder

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

Ральф - проверка SSE2 здесь: https://github.com/matthew-brett/np-wheel-builder/blob/master/_distributor_init.py

Я также создал 64-битные установщики для Python 2.7, 3.4, 3.5 по тому же веб-адресу.

@matthew-brett, у меня нет доступа к этим файлам.

@matthew-brett, технология сборки SxS больше не используется (начиная с VS2010), см . https://en.wikipedia.org/wiki/Side-by-side_assembly.

Как насчет добавления номеров версий к именам файлов DLL: libopenblaspy_0.15..dll или libatlas_3.10.1.dll или аналогичный. А затем используйте _прокси-DLL_, которая используется в качестве DLL-пересылки для версионных библиотек DLL. Расширения Numpy и scipy должны быть созданы для прокси-библиотеки DLL, которая называется, например, _libblaslapack.dll_.

Если используется атлас, это, в принципе, позволяет загружать оптимизированную библиотеку DLL атласа во время выполнения. (не обязательно при использовании openblas)

Со всем этим можно справиться с помощью пакета clib_openblas и/или clib_atlas. (Теперь мне нужно научиться генерировать код для DLL пересылки). Сам Numpy может быть оснащен как atlas, так и openblas. Это должно быть загружено, если ни clib_openblas, ни clib_atlas не доступны.

@carlkl : я думаю, что страница в Википедии сбивает с толку и пытается сказать, что VS 2010 не использует SxS _для определенных библиотек_, но SxS в целом, безусловно, все еще используется (например, позже на той же странице: «Начиная с Vista и далее, операционная система также использует WinSxS для своих основных компонентов.")

Я считаю, что способ создания dll пересылки с помощью msvc заключается в написании специального файла .def, а затем его использовании при создании .dll. Но как может помочь dll пересылки? (Я думаю, что в osx или Linux это может быть полезным инструментом, но в Windows у вас все еще есть эта раздражающая проблема с глобальным пространством имен dll.)

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

(1) ИМХО, самое простое решение - статически связать Blas Lapack. Этот подход создает огромные двоичные файлы и поэтому не рекомендуется (по крайней мере, мной).
(2) Второе самое простое решение — установить DLL в numpy/core и все.
(3) Третье решение состоит в том, чтобы _принудительно_ установить зависимость от внешнего пакета Blas/Lapack, который имеет версию и просто предварительно загружает DLL Blas Lapack. Использование pip гарантирует, что доступна правильная версия DLL.
(3) Если такая ограниченная зависимость нежелательна, ее можно дополнить DLL, предоставленной самими numpy и scipy. Эти DLL следует загружать _только в тех случаях_, когда внешняя DLL не установлена. Это означает, что внешний пакет Blas/Lapack предпочтительнее, но не является строго обязательным.
Большим плюсом такого решения является то, что более новые выпуски openblas/atlas с исправленными ошибками могут быть заменены без переустановки numpy/scipy.
(4) Использование манифестов и SxS. @njsmith , можете ли вы заполнить подробности этого дела?

Извините - исправил разрешения для колес - теперь они работают?

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

Вопрос в том, должны ли мы использовать «частные» сборки SxS, которые мы размещаем в нашем собственном двоичном дереве. Сборки SxS также могут использоваться совместно. Общие сборки помещаются в системную папку Windows и должны быть установлены с помощью пакета установщика MS . Я думаю, это означает, что общие сборки не могут быть установлены через колесо, и в любом случае потребуются права администратора, поэтому я думаю, что мы можем отказаться от общих сборок как вариант.

Итак - какие проблемы с использованием приватных SxS сборок?

Первая проблема заключается в том, что если бы мы попытались сделать это, мы проложили бы новый путь. Я не знаю ни одного другого проекта с открытым исходным кодом, который их использует. Я спросил Стива Дауэра о сборках SxS. Стив работает в MS и в настоящее время занимается сопровождением Python для Windows. Он предложил мне избегать их. Казалось, никто из тех, с кем он работал, не был с ними знаком. Мои заметки, приведенные выше, были попыткой понять несколько известных ему случаев, когда кто-то (очевидно) успешно их использовал. Есть очень мало хороших ресурсов, чтобы объяснить их.

Связано с этим наблюдение, уже упомянутое Карлом, о том, что MS сама по себе неоднозначно относится к их использованию. Например, для среды выполнения MSVC, очевидного применения сборок SxS, вместо них используются уникальные имена DLL (MSVCR90.DLL, MSVCR100.DLL и т. д.).

Чтобы использовать сборки SxS, я думаю, нам пришлось бы добавить шаблонный код инициализации в каждый скомпилированный модуль, которому необходимо загрузить другую DLL, чтобы создать «контекст активации». РЕДАКТИРОВАТЬ: Натаниэль напомнил мне, что Windows автоматически запускает новый контекст активации, если увидит свидетельство «манифеста» параллельной сборки, связанного с DLL (который может быть встроен в DLL, но также может быть внешним файлом XML) .

Так что не безнадежно, а жестко.

Прошу прощения за этот очень простой вопрос, но в Windows, если я загружу библиотеку foo.dll , содержащую my_symbol в одном модуле расширения, что произойдет, если я загружу библиотеку bar.dll , также содержащий my_symbol в другом модуле расширения? Я предполагаю, что они отдельно доступны в моем процессе, поэтому первое расширение получит foo: my_symbol , а второе расширение получит bar:my_symbol ? Может ли кто-нибудь указать мне ссылку?

Если это так, то, конечно, все, что нам нужно, чтобы избежать ада DLL, - это иметь имя DLL, которое вряд ли будет случайно использовано в том же процессе (где пользователь не намеревался использовать нашу точную DLL).

При компоновке каждый символ привязывается к определенной DLL, идентифицируемой по имени. Во время выполнения необходимо обеспечить загрузку правильной DLL, если можно найти более одной DLL с одинаковым именем. Поэтому порядок поиска имеет значение.
Пример Мои колеса anaconda.org numpy используют библиотеку openblas с именем libopenblas_py_.dll, чтобы избежать конфликта имен с нестандартной libopenblas,dll, используемой Джулией.

Последние версии julia теперь используют другое имя libopenblas64_ , чтобы отразить нестандартный ABI, с которым мы строим. В 32-битной системе мы не переименовываем никакие символы или имя библиотеки, так как нет особой причины выбирать 64-битные целые числа в интерфейсе.

Затенение имен символов в общих библиотеках на самом деле было большей проблемой для Linux и OSX, чем для Windows, но мы везде делали одно и то же для согласованности.

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

Я немного усовершенствовал процесс сборки — см. https://github.com/matthew-brett/np-wheel-builder .

Теперь процесс достаточно автоматизирован, и я считаю целесообразным продолжить создание этих колес в течение следующих нескольких выпусков, если нам понадобится. Я буду рад сделать это в качестве менеджера по выпуску Windows, пока mingwpy не будет соответствовать спецификации.

Я тестировал эти колеса на 32-битных и 64-битных версиях Python 2.7, 3.4, 3.5, а также на некоторых других версиях, так что я думаю, что они в хорошем состоянии.

Могу ли я что-нибудь еще сделать, чтобы убедить вас всех в том, что их стоит разместить на pypi, как спросил ОП?

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

@matthew-brett: Этот скрипт автоматизации потрясающий . Даже если это не совсем подходит для PyPI, это кажется очень жизнеспособным способом сборки numpy из исходного кода (см. эту проблему, которую я открыл здесь ). Это также очень близко к возможности построить scipy в том смысле, что я могу собрать все, но затем тесты, кажется, вызывают segfault где-то в Python.

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

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

Я думаю, вы видели http://mingwpy.github.io — там, конечно же, есть немало материала, относящегося к проекту mingw-w64 и набору инструментов mingwpy.

Спасибо, @matthew-brett! Он проходит numpy.test() . Тест f2py.py был проблемой в test_scripts() с virtualenvs, которая была исправлена ​​в numpy-SHAd3d2f8e , но я получаю 3 предупреждения, 2 устаревания и 1 время выполнения.

Последний, надеюсь, незначительный запрос: возможно ли отобразить значок сборки в вашем репозитории np-wheel-builder и/или PyPI? Похоже, они есть в buildbot 0.8, и есть даже пакет/репозиторий Python, чтобы они выглядели красиво, BuildbotEightStatusShields-0.1 .

Также мне интересно, меня отпугнул 64-битный билд ATLAS Windows из-за отсутствия параметров настройки. Это на самом деле «заняло весь день» или есть правильный набор архитектурных значений по умолчанию?

К вашему сведению: Continuum только что выпустила Anaconda с оптимизированным mkl numpy. Думаю, они следили за этой темой.

Теперь для scipy-сборок с теми же библиотеками atlas. Требуется ли gfortran?

да. В противном случае вы не сможете скомпилировать ни один из файлов .f в scipy . Удачи в этом! Как я уже говорил ранее, я был _действительно близок_, но если вы сможете пройти тесты, это будет здорово!

Да, я боюсь, что сборка ATLAS заняла около 8 часов на машине, где больше ничего не делалось. Скрипт сборки ATLAS находится в репозитории np-wheel-builder .

Что касается новостей о MKL , это здорово, если вы являетесь пользователем conda , хотя я думаю, что использование дистрибутива Python с предустановленными numpy и scipy то, что поощрялось в течение некоторого времени. Свяжитесь со мной, когда вы также сможете бесплатно получить сами библиотеки MKL. :)

Для сборки с помощью gfortran - я думаю, что mingwpy - наша самая большая надежда.

@matthew-brett: Спасибо, что нашли время создать ATLAS! Я пытался запустить ваш скрипт раньше, но постоянно сталкивался с проблемами, вероятно, из-за несовместимости машин.

Извините за проблемы. Я только что собрал двоичные файлы ATLAS в репозитории np-wheel-builder, это была новая установка Windows Server 2012 и 64-разрядной версии Cygwin с указанием точных версий ATLAS и lapack. Исходные архивы, которые я использовал, находятся по адресу http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/. Если у вас есть другая версия ATLAS, она может легко запутаться.

Хм... наверное, так оно и есть. Опять же, очень признателен, учитывая усилия, которые вам потребовались, ребята, чтобы сделать это. Если вы, ребята, сможете найти способ развертывания совместимых с Windows сборок ATLAS, которые не требуют столько времени и ресурсов, как сейчас, это было бы здорово!

@gfyoung

Свяжитесь со мной, когда вы также сможете бесплатно получить сами библиотеки MKL. :)

См. https://software.intel.com/sites/campaigns/nest/ и https://registrationcenter.intel.com/en/forms/?productid=2558&licensetype=2 - или вы имели в виду источник?

@tkelman , только что видел это на сайте нового проекта @carlk mingwpy, но лицензия сообщества Intel Nest не имеет ifort , а без этого как scipy?

@tkelman : Упс, не знаю, почему я забыл об этом лицензировании сообщества. Тем не менее, @tkelman поднимает верный вопрос.

@tkelman : Вы могли бы попробовать MinGW, но, судя по тому, что я испытал, это, к сожалению, не работает. Это даже не поможет вам пройти numpy из-за проблем с совместимостью.

@mikofski верно, не помогает scipy, учитывая отсутствие компиляторов. Единственными вариантами сегодняшних сборок scipy будут mingwpy или сборка Python для MSYS2 all-gcc-all-the-time (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64- Python-Scipy). Последний, конечно, не будет совместим с бинарными файлами cpython или pypi, созданными msvc, поэтому он не будет охватывать все модули, кроме scipy.

@matthew-brett: какой дефицит скорости у этих колес ATLAS по сравнению с openblas и/или MKL?

Кто-нибудь заглядывал в PGI Fortran. Это не упоминается на сайте проекта @carkl mingwpy. Я пытался использовать его один раз, зашел довольно далеко в эту кроличью нору, но я не могу вспомнить, что это был за стопор шоу. Я думаю, что лицензия разрешающая, хотя исходный код закрыт. Может быть, PGI Fortran будет лучше работать с msvc?

@mikofski : у меня его нет перед собой, но когда я посмотрел на PGI в прошлом году, я помню, что пришел к выводу, что он был даже хуже, чем Intel (с точки зрения принуждения вас добавлять ограничения, несовместимые с FOSS, к вашему лицензированию) .

Хорошо, может быть, несколько целевых фондов можно направить на решение BLIS/FLAME для архитектур x86?

Судя по всему, к концу этого года Nvidia/PGI предоставит свой интерфейс Fortran в качестве открытого исходного кода для LLVM. https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

Хорошо, может быть, несколько целевых фондов можно направить на решение BLIS/FLAME для архитектур x86?

Не думайте так. BLIS выглядит очень нездоровым проектом (и тем более libflame); небольшая активность с точки зрения коммитов, трафика из списков рассылки и т. д. Кроме того, у них было значительное финансирование (https://github.com/flame/blis#funding), так что несколько тысяч долларов не волшебным образом сделают эти проекты созревают.

Я не совсем понимаю, откуда берется или уходит эта дискуссия: у нас есть временное решение, которое Мэтью почти завершил (используя ATLAS), и, что более важно, у нас есть долгосрочное решение, над которым очень активно работают (MingwPy + ОпенБЛАС). Кроме того, OpenBLAS используется гораздо шире; использование этого проекта как в стеке Scipy, так и в Julia должно ускорить его дальнейшее развитие.

@rgommers : Разговор шел своим чередом, потому что мы с @mikofski пытались использовать решение @matthew-brett для создания scipy . Однако похоже, что мы оба сталкиваемся с одной и той же проблемой: компилятором Fortran. Я сам пытался использовать установленный gfortran.exe как для MinGW32, так и для MinGW64, но без особого успеха из-за множества неразрешенных внешних по той или иной причине.

Сборка @gfyoung Мэтью использует MSVC. Нет смысла пытаться использовать gfortran с MSVC, известно, что это не работает. Резюме ситуации сборки:

• Нет Fortran, теперь вы можете использовать MSVC.
• С Fortran вы можете использовать MingwPy, MSVC + ifort или icc + ifort.
• Для стека Scipy нам нужно бесплатное решение, которое создает колеса для numpy, scipy и т. д. Для этого подойдет MingwPy.

@rgommers Прошу прощения за то, что сорвал разговор. Вы совершенно правы, решение @matthew-brett для numpy работает, а проект mingwpy от @carlk уже финансируется num focus. Я постараюсь посмотреть, смогу ли я заставить свою компанию поддержать это. Я уже являюсь участником num focus. Примерно на полпути через scipy 2829, и я думаю, что пришел к тому же выводу. Я просто надеюсь, что это сработает. В краткосрочной перспективе мы продолжим использовать @cgohlke или переключимся на anaconda. Еще раз спасибо!

Помимо отправки сборок в pypi, может быть, последняя проблема для @matthew-brett — это щит сборки в его репозитории сценариев сборки np? Спасибо! Тогда это может быть закрыто?

Прежде чем это будет закрыто, быстрый вопрос: я создал @matthew-brett numpy так, чтобы он указывал на ATLAS. Однако, когда я пытаюсь собрать scipy с помощью ifort , он также подхватывает другой файл site.cfg , который использует MKL, расположенный в моем домашнем каталоге. На самом деле я могу успешно построить против numpy , и тесты проходят, за исключением пары ошибок из-за минутных ошибок округления. Однако мне любопытно, что делал scipy , когда я его строил? Использовал ли он библиотеки MKL или пытался использовать библиотеки ATLAS, уже созданные с помощью numpy ?

В https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows есть сводка компиляторов Windows Fortran.

@gfyoung - просто используя комбинацию догадок и отдаленной памяти - я считаю, что scipy сначала подберет site.cfg в своем собственном каталоге, а если он отсутствует, подберет конфигурацию сборки numpy. Это, в свою очередь, укажет на то, где были библиотеки, когда я построил колеса. Таким образом, вам нужно переписать site.cfg для scipy, чтобы подобрать библиотеки атласа np-wheel-builder — скрипт build_numpy.py делает это для сборки numpy.

BLIS выглядит очень нездоровым проектом (и тем более libflame); небольшая активность с точки зрения коммитов, трафика списка рассылки и т. д.

Я не уверен, что назвал бы их нездоровыми, потому что они не пытаются быть общественными проектами FOSS; по сути, это шоу для одного человека, и им это нравится (по крайней мере, на данный момент). Я был в контакте с ними время от времени в течение последнего года, и хорошая новость заключается в том, что в настоящее время их усилия сосредоточены именно на том, что нам нужно (выбор ядра во время выполнения и конфигурация потоков во время выполнения); плохая новость заключается в том, что делать особо нечего, кроме как ждать, пока один архитектор перестроит все по своему вкусу. Может через 6 месяцев будут какие-то результаты?

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

Натаниэль - какие-нибудь предложения о том, где получить хорошие тесты? Я не думаю, что numpy.bench() больше ничего не делает. Я пытался запустить asv , но многие тесты терпят неудачу, потому что в Windows numpy нет complex256 .

Я предполагаю, что части asv , которые работают, полезны? Или даже %timeit np.dot(big_array, other_big_array) было бы полезно, чтобы получить хоть какое-то грубое представление о том, где мы находимся :-)

Кроме того, кстати, вот общее решение проблемы глобального пространства имен Windows DLL, позволяющее нам написать Windows delocate : https://github.com/njsmith/redll

К сожалению, сбой asv complex256 прерывает целые последовательности тестов по dtypes. Хотя, думаю, исправить это не составит большого труда.

Простое тестирование с этим:

def test_dot():
    """
    Test the dot product
    """
    i = 1000
    a = random((i, i))
    b = numpy.linalg.inv(a)
    result = numpy.dot(a, b) - numpy.eye(i)

предполагает, что, как ранее предупреждал Клинт Уэйли, 64-битный ATLAS плохо оптимизирован для Windows. С 64-битным MKL через колеса Кристофа Гольке:

In [9]: %timeit test_dot()
1 loop, best of 3: 764 ms per loop

С моими колесами, собранными с помощью 64-битного ATLAS:

In [10]: %timeit test_dot()
1 loop, best of 3: 2.41 s per loop

Разница намного меньше с 32-битными колесами (на другой 32-битной машине). МКЛ:

In [3]: %timeit test_dot()
1 loop, best of 3: 663 ms per loop

против АТЛАСА:

In [4]: %timeit test_dot()
1 loop, best of 3: 1 s per loop

@rcwhaley - Cпасибо, если у вас есть какие-то мысли. Это АТЛАС 3.10.1...

Вот еще одна машина с 64-битной Windows и более современным процессором, которая также показывает замедление примерно в 3 раза.

МКЛ:

In [3]: %timeit test_dot()
1 loop, best of 3: 400 ms per loop

АТЛАС:

In [3]: %timeit test_dot()
1 loop, best of 3: 1.28 s per loop

Да, сложную проблему 256 нетрудно исправить: https://github.com/numpy/numpy/pull/7251

3x — это много, но не так драматично, как с lapack_lite , верно? Я думаю, что это нормально для краткосрочного решения. И дело не в том, что старые 32-битные установщики .exe были лучше.

Кроме того, кстати, вот общее решение проблемы глобального пространства имен Windows DLL, позволяющее нам написать Windows delocate: https://github.com/njsmith/redll

хорошее заявление о лицензии :)

@gfyoung 'site.cfg' ищется в:

1) Директория основного запускаемого файла setup.py.
2) Домашний каталог пользователя, запускающего файл setup.py как ~/.numpy-site.cfg
3) Общесистемный каталог (расположение этого файла...)

@rgommers Прошу прощения за то, что сорвал разговор.

Ничего страшного, ничего не сломалось.

Вы совершенно правы, решение @matthew-brett для numpy работает, а проект mingwpy от @carlk уже финансируется num focus. Я постараюсь посмотреть, смогу ли я заставить свою компанию поддержать это. Я уже являюсь участником num focus. Примерно на полпути через scipy 2829, и я думаю, что пришел к тому же выводу. Я просто надеюсь, что это сработает. В краткосрочной перспективе мы продолжим использовать @cgohlke или переключимся на anaconda. Еще раз спасибо!

Прохладный. И приятно видеть, что вы заинтересованы в MingwPy. Обратите внимание, что теперь у него есть собственный ML, который может представлять интерес: https://groups.google.com/forum/#!forum/mingwpy .

@rgommers , @matthew-brett : Ах, да, похоже, что он заранее собирался с MKL. Я прямо указал свои site.cfg на сборку ATLAS, а сборки scipy но segfaults во время тестов. Так близко!

@rgommers - да - производительность намного хуже без ATLAS (с lapack_lite):

In [2]: %timeit test_dot()
1 loop, best of 3: 17.7 s per loop

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

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

У Numpy также совершенно другой набор допустимых рисков и компромиссов в производительности, а также соотношение пользователей и разработчиков, чем у Джулии. Поэтому я думаю, что для numpy может иметь смысл использовать более консервативный подход и использовать медленный, но надежный по умолчанию, работая над тем, чтобы разрешить выбор openblas в качестве альтернативы по умолчанию. Хотя эти 8 часов сборки не кажутся забавными, неудивительно, что никто не спрашивал нас об использовании Atlas с Джулией.

работа над тем, чтобы разрешить openblas в качестве выбора не по умолчанию

Проблема в том, что я не совсем уверен, как этот процесс может работать :-/. У нас нет хорошего способа распространять альтернативные сборки среди пользователей (в долгосрочной перспективе я надеюсь, что мы сможем получить варианты сборки на pypi как numpy[openblas] и так далее, но это произойдет не скоро) , у нас нет никакого способа улучшить сборки openblas, кроме их распространения и ожидания отчетов об ошибках, и основной альтернативой сборкам ATLAS для людей, которые заинтересованы в поиске, будут не сборки openblas, это будет MKL строит от какой-то третьей стороны :-/.

Я предполагаю, что еще один вариант, который можно предложить, - это распространять сборки BLIS с использованием их эталонного ядра / ядра SSE2. Поскольку BLIS по-прежнему имеет только конфигурацию времени сборки, он не будет конкурировать с openblas, но может конкурировать с ATLAS, а преимущества по сравнению с ATLAS заключаются в том, что время сборки _намного_ меньше, и есть шанс, что это хорошее долгосрочное решение. трудно оценить, но, безусловно, лучше, чем ATLAS, являясь хорошим долгосрочным решением (которое я бы поставил на ноль). Если мы все равно собираемся что-то контролировать, то, по крайней мере, мы направим эту энергию на то, что _может_ иметь будущее.

Некоторые вопросы, на которые необходимо ответить, прежде чем серьезно рассматривать этот вариант:

(1) Я не уверен, конкурентоспособна ли поддержка многопоточности BLIS с поддержкой ATLAS (я знаю, что в исходном коде есть несколько вариантов многопоточности, и я знаю, что главный разработчик еще не считает это «готовым» , Т.е. конкурентоспособен с MKL, но между ATLAS и MKL большой простор.)

(2) если на то пошло, я также понятия не имею, как BLIS в ненастроенном режиме справляется с приведенными выше тестами.

(3) На самом деле я не пытался создавать BLIS для Windows, и есть проблема, связанная с тем, что это просто BLAS, а не LAPACK - не уверен, насколько это проблема для numpy.

Насколько быстро BLIS реагирует на сообщения об ошибках? Openblas вроде неплох
об этом.

В понедельник, 15 февраля 2016 г., в 15:48, Натаниэль Дж. Смит <
уведомления@github.com> написал:

работа над тем, чтобы разрешить openblas в качестве выбора не по умолчанию

Проблема в том, что я не совсем уверен, как этот процесс может работать :-/.
У нас нет хорошего способа распространять альтернативные сборки среди пользователей (в
в долгосрочной перспективе я надеюсь, что мы сможем получить варианты сборки на pypi как numpy[openblas]
и так далее, но это произойдет не скоро), у нас нет возможности
улучшить сборки openblas, за исключением их распространения и ожидания ошибки
отчеты и основная альтернатива сборкам ATLAS для людей,
мотивированы искать один из них не будут сборки openblas, это будут сборки MKL
от какого-то третьего лица :-/.

Я предполагаю, что еще одним вариантом для рассмотрения будет распространение BLIS.
строит с использованием своего эталонного ядра/ядра SSE2. Потому что у BLIS пока только сборка
временная конфигурация не будет конкурировать с openblas, но может быть
конкурентоспособен с ATLAS, а преимущества по сравнению с ATLAS заключаются в том, что сборка
время _намного_ быстрее, и шансы на то, что это будет хорошая долгосрочная перспектива
решение трудно оценить, но, безусловно, лучше, чем ATLAS, будучи хорошим
долгосрочное решение (которое я бы поставил на ноль). Если мы собираемся быть QAing
что-то в любом случае, тогда, по крайней мере, мы бы направили эту энергию на что-то
что _might_ есть будущее.

Некоторые вопросы, на которые необходимо ответить, прежде чем серьезно рассматривать это
вариант:

(1) Я не уверен, поддерживает ли BLIS многопоточность.
конкурентоспособен с ATLAS (я знаю, что в
источник, и я знаю, что главный разработчик не считает это
"сделано" еще, т.е. конкурентоспособно с MKL, но между
АТЛАС и МКЛ.)

(2) если на то пошло, я также понятия не имею, как BLIS в ненастроенном режиме поживает
на этих контрольных показателях выше.

(3) На самом деле я не пытался создавать BLIS для Windows, и есть
проблема с тем, что это просто BLAS, а не LAPACK - не знаю, как
большая часть проблемы это для numpy.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-184387401 .

Я считаю, что libflame является эквивалентом lapack в blis. Интерфейс совместимости с lapack2flame описан в справочной документации .

Насколько быстро BLIS реагирует на сообщения об ошибках?

Мы еще не знаем.

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

Я еще не видел в этой теме веских причин для отклонения от плана MingwPy + OpenBLAS. Двоичные файлы No-scipy-ATLAS-MSVC-хорошо иметь временное решение, но оно менее важно, чем среднесрочное/долгосрочное решение MingwPy, и если временное решение само по себе превращается в серьезное усилие, то я бы сказал, что это не стоит усилий. .

Документы BLIS/libflame предполагают, что если бы я собирался собрать полную библиотеку BLAS/LAPACK в Windows, это был бы одинокий путь.

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

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

@tkelman - спасибо за ваш анализ - я думаю, вы правы, что numpy должен сосредоточиться на правильности. Но было бы хорошо объединить усилия, чтобы положиться на некоторые из наиболее утомительных ошибок OpenBLAS и разработать более полные тесты. На ум приходит эта ошибка OpenBLAS - несколько неясная, очень сложная для отладки.

Я считаю, что для этой конкретной проблемы необходимо предоставить колеса numpy на pypi, чтобы случайный пользователь пакета «x», который зависит от «y» (например, matplotlib), который зависит от numpy, устанавливался с использованием pip, не заставляя случайного пользователя бросать поднимите руки вверх и скажите что-то вроде: «Python слишком сложен». и вернитесь в MATLAB. Дзен Python говорит, что должен быть один очевидный способ сделать это. Тем не менее, все, что связано с pypi от numpy, в частности, имеет определенный вес, что оно _является_ стабильным, или более того, чем случайный сторонний проект, за исключением, возможно, cgohlke. Очевидно, что enthight и anaconda воспринимаются, по крайней мере, в промышленности как более стабильные.

Я думаю, что в краткосрочной перспективе сборка ATLAS должна появиться с предупреждением о том, что сборка с помощью scipy невозможна. Если этот строительный робот можно автоматизировать, значит, дело сделано, верно? Будем надеяться, что будущие 8-часовые сборки ATLAS будут редкостью. Возможно, однажды проблема с 64-битной Windows будет решена. Проблема с исключением SSE2 — это облом, поэтому еще одно предупреждающее сообщение о pypi. Кроме того, ATLAS уже является стандартом для Linux и был стандартом в предыдущих пакетах superpack bdist_winst, что обеспечивает еще большую поддержку этого пути.

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

В долгосрочной перспективе я рад, что blis/flame — это будущее. Немного пугает, что многие из наших математических инструментов зависят от кода FORTRAN из 70-х. Решение только для переменного тока — это крупный прорыв, и я хочу его с энтузиазмом поддержать.

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

Если вы не попытаетесь использовать одно из оптимизированных ядер в blis, то вы, вероятно, не столкнетесь с проблемой (отредактируйте: единственное число). Я открыл там с 2014 года. Я думаю, что система сборки использует символические ссылки только для оптимизированного ядра, так что вы не перепутаете git msys2, если попытаетесь собрать там только эталонную конфигурацию. Сборка из cygwin работала в последний раз, когда я пытался, хотя это было некоторое время назад, и я не могу вспомнить, что мне, возможно, нужно было изменить локально. Стоит построить, протестировать и сравнить, если альтернативой является Atlas, но считайте его недоказанным и, следовательно, по-своему высоким риском, пока вы этого не сделаете.

@mikofski , чтобы быть справедливым, Лапак из 90-х, это действительно слон Фортрана в комнате.

@tkelman : чтобы было ясно, проблемы, которые вы зарегистрировали, были конкретно с собственной системой сборки Windows, верно? Из любопытства я только что попробовал выполнить кросс-компиляцию blis для Windows из Linux (используя кросс-компилятор mingw-w64, установленный из пакетов Debian), и я был удивлен, обнаружив, что это заняло всего ~ 2 минуты. Я сделал "./configure reference; make -j4 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar CPICFLAGS=" и все просто заработало. ( CPICFLAGS= просто для подавления кучи предупреждений об «игнорировании -fPIC , потому что это значение по умолчанию», и, возможно, мне даже не нужно было переопределять AR , но эй почему бы и нет.) Есть несколько предупреждений о printfs в bli_pool.c и bli_fprintm.c , которые используют %ld для печати целых чисел intptr , так что, вероятно, есть несколько перегибов LLP64. работать.

@rgommers :

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

Ты совершенно прав! Проблема в том, что все наши варианты ужасны :-(.

Так что очевидно, что у MKL определенно плохая лицензия.

У ATLAS явно плохая производительность, которая никогда не улучшится.

И OpenBLAS, я думаю, у нас есть доказательства, чтобы сказать на данный момент, просто не ремонтопригоден и вряд ли станет так скоро :-(. Проекту пять лет, в нем все еще есть фундаментально неработающие вещи, такие как пример случайного volatile Джулиана.

Поэтому причина, по которой я продолжаю упоминать BLIS, не в том, что я думаю, что BLIS определенно является решением, а в своего рода расчетливом оптимизме: BLIS _может_ стать такой же быстрой, как MKL/OpenBLAS, такой же надежной, как ATLAS/MKL, и такой же открытой для сообщества. вклады как OpenBLAS; а может и нет. Но, похоже, нет других проектов, которые действительно надеются соответствовать всем этим критериям. [И это даже не говоря о других преимуществах, таких как тот факт, что он может изначально поддерживать массивы с шагом; не исключено, что мы сможем удалить весь наш ужасный специальный код отправки BLAS.]

IIUC, GotoBLAS поддерживался одним штатным разработчиком (Казушиге Гото), работавшим в UT Austin с Робертом ван де Гейном в качестве PI. BLIS поддерживается одним штатным разработчиком (Филд Дж. Ван-Зи), работающим в UT Austin с Робертом ван де Гейном в качестве PI. Так что это не значит, что это не может работать :-) Но да, это не произойдет просто по волшебству, если мы подождем — если вокруг этого когда-либо и возникнет сообщество разработчиков, то это произойдет потому, что какое-то сообщество показало свои лужайка перед домом с палатками типа «эй, вот мы и въезжаем и заставляем эту работу работать на нас, надеюсь, вы не возражаете». И что нам действительно нужно знать, чтобы определить его долгосрочную жизнеспособность, так это, например, «насколько он надежен на самом деле» и «насколько они поддаются исправлениям» и тому подобное, чего мы не можем знать, пока не начнем его тестировать и отправлять. патчи и так далее.

В заключение: я серьезно не знаю, какой для нас лучший вариант, но засунуть пальцы ног в воду BLIS кажется хорошей идеей; даже если мы решим, что хотим подождать, то, по крайней мере, чему-то научимся.

Я подал несколько выпусков и один или два PR. Тот факт, что в репозитории есть символические ссылки, означает, что сборка из msys2 не работает (или работает только в том случае, если вы установите параметры msys2 определенным образом). Кросс-билдинг из cygwin или linux (хотя я бы не стал доверять вину для запуска тестов) должен работать, но в 2014 году были проблемы с выровненным malloc, а ядра Sandy Bridge дали сбой в тесте. Я только что пересобрал ядра Sandy Bridge на последнем мастере blis с помощью cygwin cross (на более новом ноутбуке Skylake), и segfault теперь может исчезнуть. Кто знает, когда или что это исправило, придется разделить пополам.

Я думаю, что это упоминалось ранее, но мы могли бы собрать двоичные файлы ATLAS для SSE2, SSE3, AVX и поместить их в структуру каталогов, например:

numpy/.lib/sse2/numpy-atlas.dll
numpy/.lib/sse3/numpy-atlas.dll
numpy/.lib/avx/numpy-atlas.dll

Затем мы могли бы использовать numpy/_distributor_init.py для проверки текущего процессора и предварительной загрузки соответствующей библиотеки.

Я предложил сделать в принципе то же самое, но для блис вместо атласа @njsmith. Также стоит сравнить, насколько хорошо работает многопоточность в blis и atlas. Эталонная конфигурация blis по умолчанию не включает многопоточность, хотя для ее переключения достаточно настроить определение в заголовочном файле.

Я настроил Appveyor для сборки бинарных файлов. Текущая версия сборки находится здесь: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10 .

Готовые колеса поступают сюда: https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

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

@rgommers , @matthew-brett : Что касается site.cfg , похоже, ваш ответ относится только к numpy . Кажется, что scipy не ищет site.cfg в том же каталоге, что и setup.py , только начинает поиск site.cfg сначала в вашем домашнем каталоге, прежде чем по умолчанию numpy Конфигурация

OK - скрипт сборки работает без ошибок, включая тесты установленного колеса: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Колеса здесь: http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com/

Я установил и протестировал их на другой 64-битной машине и на другой 32-битной машине.

Итак, я думаю, что они готовы к работе. Есть возражения против того, чтобы я загрузил их в pypi?

Было бы неплохо иметь примечание о pypi, объясняющее/ссылающееся на объяснение разницы между этими колесами и колесами от gohlke (mkl), чтобы предотвратить путаницу у людей, задающихся вопросом, почему колеса теперь появляются на pypi и в чем разница. между ними есть.

Побочный вопрос, извините, но мне было интересно, что

  # Pin wheel to 0.26 to avoid Windows ABI tag for built wheel
  - pip install wheel==0.26

в аппвейоре имеется в виду скрипт?

Хорошее предложение по объяснению - я постараюсь решить, как добавить это для этого существующего выпуска.

Колесо > 0,26 добавляет дополнительный тег ABI к колесу Windows. Wheel==0.26 дает такое имя колеса:

numpy-1.10.4-cp27-none-win32.whl

При колесе > 0,26 вы получаете дополнительный тег ABI, например:

numpy-1.10.4-cp27-cp27m-win32.whl

(я думаю) - который указывает Windows ABI. Это раздражает, потому что более ранний pip не будет устанавливать этих парней, поэтому мне кажется, что имя без ABI лучше на данный момент.

ОК — предлагаю добавить этот текст на текущую страницу pypi:

Все колеса numpy, распространяемые из pypi, имеют лицензию BSD.

Колеса Windows связаны с библиотекой ATLAS BLAS / LAPACK, ограничены инструкциями SSE2, поэтому могут не обеспечивать оптимальную производительность линейной алгебры для вашей машины. См. http://docs.scipy.org/doc/numpy/user/install.html для альтернатив.

Я бы сказал иначе:

Эти колеса Windows имеют субоптимальную производительность линейной алгебры (ссылка на эталонный тест, например http://speed.python.org), потому что они связаны с библиотекой ATLAS BLAS/LAPACK, которые ограничены инструкциями SSE2 (и какие неограниченные инструкции должны будь там?). Если вам нужна производительность, вы можете поддержать проект mingwpy, целью которого является повышение производительности расширений Python, скомпилированных на этой платформе. Видеть ??? для получения подробной информации и http://docs.scipy.org/doc/numpy/user/install.html для альтернатив.

Что ж, текущие версии mingwpy numpy / scipy действительно используют openblas, но я думаю, что это не связано с mingwpy vs MSVC в качестве компилятора. Мы также могли бы поставлять openblas с этими колесами, но я беспокоился, что openblas еще недостаточно надежен для использования в стандартном колесе, которое мы поддерживаем.

OpenBlas кажется достаточно стабильным, я знаю, что Anaconda использует его для своего Linux.
строит сейчас. Нет обновленных сборок Windows Python 3.5 x64.
там тесты показывают, что он примерно равен MKL. я бы обязательно попробовала, если
кто-то может собрать колесо.
16 февраля 2016 г., 22:36, «Мэттью Бретт» [email protected] написал:

Что ж, текущие версии mingwpy numpy/scipy используют openblas, но я
думаю, что это не связано с mingwpy и MSVC в качестве компилятора. Мы также можем отправить
openblas с этими колесами, но я переживал, что openblas еще не было
достаточно надежен для использования в стандартном колесе, которое мы поддерживаем.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-185017546 .

В порядке. Я просто запутался в источнике неоптимальной производительности - я не использую эти библиотеки BLAS и не знаю, что они делают и в чем разница, поэтому объяснение этих вариантов для смертных помогает стать.. эээ, более научным, вы знаете . =) Я думал, что проблема в отсутствии открытого компилятора с оптимальной производительностью.

@mrslezak : что касается OpenBLAS, я, конечно, могу согласиться. Предоставленный пакет OpenBLAS на Cygwin в сочетании с пакетом Lapack, по-видимому, способен без проблем создавать как NumPy, так и SciPy.

@mrslezak : где я могу найти информацию о тестах? Я пытаюсь написать документацию по сборке исходного кода из Windows за scipy.org , и это будет отличным справочником для всех, кому нужна производительность с этими библиотеками.

Может быть, подход дробовика - правильная идея? Что-то типа:

• Стабильный: ATLAS с производительностью, предостережения sse2
• Разработчик: OpenBLAS см. mingwpy и binstar
• Альтернативный вариант: MKL @cgohlke , MKL @continuum и @enthought
  Предупреждение: двоичные файлы несовместимы.
  Ссылки для получения дополнительной информации на scipy и github numpy wiki Мэтью Бретта

@techtonik Я ожидаю, что GCC будет работать несколько хуже, чем MSVC или ICC, с эквивалентным кодом, который способны создавать все эти компиляторы. Проблема заключается в отсутствии бесплатного (совместимого с python.org-cpython) компилятора, который может создать конкурентоспособную версию Lapack, которая находится на Fortran (у SciPy также есть другие компоненты Fortran). Чистая BLAS-часть OpenBLAS (и, возможно, Atlas тоже) на самом деле может быть построена с помощью MSVC, но MSVC не может создавать какие-либо части, требующие встроенной сборки, поэтому он также не будет конкурентоспособным.

У меня нет под рукой 64-битного MKL (у меня может быть 32-битный от conda, если я покопаюсь), но вот несколько тестов, выполненных в Джулии, сравнивающих dll Atlas, созданную @matthew-brett, с эталоном и sandy- мостовые конфигурации BLIS и сборка OpenBLAS, которая поставляется с Julia https://gist.github.com/54da587b01b7fb163103

Резюме: openblas (на скайлейке новейшее ядро ​​openblas haswell) в 23 раза быстрее, чем atlas, в 44 раза быстрее, чем эталонный blis, и в 5,5 раз быстрее, чем sandybridge blis. Я мог бы попробовать haswell blis, чтобы увидеть, насколько он ближе.

Хм - я не думаю, что у вас завалялись скрипты сборки для ваших компиляций BLIS?

Как вы думаете, стоит ли делать сборки BLIS для ряда процессоров и выбирать один во время выполнения? Существует ли небольшое подмножество процессоров, обеспечивающее большую часть производительности большинства процессоров?

Это в комментариях, а здесь (запуск в cygwin 64)

cd build
for i in reference dunnington sandybridge haswell bulldozer piledriver carrizo; do
  mkdir -p ../build64$i
  cd ../build64$i
  ../configure $i
  cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/lib* .
  make -j8 all test CC=x86_64-w64-mingw32-gcc CPICFLAGS="" BLIS_ENABLE_DYNAMIC_BUILD=yes
done

Вот что у них есть: https://github.com/flame/blis/tree/master/config .

С точки зрения Intel x86 эталон, dunnington, sandybridge и haswell охватывают довольно хороший диапазон. Также бульдозер, пиледрайвер и карризо для AMD (которая недавно прекратила разработку ACML в пользу BLIS, так что, по крайней мере, это голосование за).

В https://github.com/flame/blis/tree/master/build/auto-detect есть некоторый код автоматического обнаружения, который можно использовать повторно (в настоящее время он запускается только во время настройки в BLIS, но это не означает, что он не может быть повторно использован для других целей), в зависимости от того, есть ли уже фрагмент кода идентификации семейства процессоров в Python, который вы хотите использовать.

в зависимости от того, есть ли уже фрагмент идентификационного кода семейства процессоров в Python

Это помогает? http://stackoverflow.com/a/35154827/239247

В основном вам нужно семейство процессоров, полученное из него, но https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c не совсем длинный или сложный. Источник numexpr, связанный с SO, выполняет сопоставление регулярных выражений с выводом строки (по крайней мере, в Linux), и не похоже, что в нем перечислены многие последние архитектуры.

openblas в 3,4 раза быстрее, чем Haswell blis, и в 17 раз быстрее, чем dunnington (в основном то же самое, что и nehalem penryn, я думаю) blis. Что интересно, я не думаю, что многопоточность работает в blis на этих прогонах. Настройка по умолчанию включает openmp для sandybridge и haswell, возможно, потоки mingw будут работать лучше. Установка OMP_NUM_THREADS , похоже, не имеет большого значения.

Я считаю, что ATLAS 3.11 должен работать намного лучше на 64-битной версии, чем версия 3.10, но я не могу собрать ее в данный момент, надеясь на помощь Клинта Уэйли.

Тони, полагаю, у тебя нет времени/энергии на тестирование 32-битного колеса ATLAS? Это должно быть намного лучше, относительно.

Лично я предпочитаю использовать эти колеса ATLAS, чтобы другие упаковщики могли рассчитывать на то, что мы отправим какое-либо колесо. Если мы разработаем хороший способ повышения производительности, скоро у нас появится новый выпуск numpy, и даже для 1.10.4 мы всегда можем сделать отладочный выпуск для обновления колес.

@matthew-brett: быстрый вопрос, почему numpy не может обнаружить сборки ATLAS на Cygwin? Я смог обнаружить их прекрасно в родной среде Windows, но когда я попытался запустить ваш скрипт в Cygwin, numpy не скомпилировался с ATLAS .

Если вы используете Cygwin python, вам, вероятно, понадобится версия atlas, созданная Cygwin, чтобы вещи были совместимы.

32-битная Джулия, похоже, не может открыть 32-битную атласную dll. Не знаю, почему, может быть, потому что у нас уже есть 32-битный openblas, и имена символов конфликтуют?

Но версия @matthew-brett построена на Cygwin, поэтому я в замешательстве.

Среда сборки Cygwin, кросс-компилированная в библиотеку mingw. Видите, как он связан с msvcrt.dll, а не с cygwin1.dll?

Как только я разместил комментарий, я внезапно заподозрил, что это может быть так. Увы, похоже, мне придется строить его с нуля. Спасибо @tkelman !

Проблема с dlopen решена (ссылка https://github.com/matthew-brett/np-wheel-builder/pull/1, а https://github.com/JuliaLang/julia/issues/15117 скрывала полезную версию сообщение об ошибке).

На 32-битной версии atlas в 3,6 раза медленнее, чем openblas. 32-битный openblas в 3 раза медленнее, чем 64-битный openblas для того же размера проблемы. Последние несколько семейств ядер не включены в openblas на 32-битных системах.

...
В заключение: я серьезно не знаю, какой для нас лучший вариант, но засунуть пальцы ног в воду BLIS кажется хорошей идеей; даже если мы решим, что хотим подождать, то, по крайней мере, чему-то научимся.

Это, вероятно, полезно, по крайней мере, какое-то тестирование/бенчмаркинг. Но на данный момент это почти не связано с нашими проблемами с _Windows_. BLIS на данный момент доступен только для Linux; есть открытый PR для поддержки сборки OSX, а до Windows очень далеко. И что еще хуже, вчера я попробовал это на 32-битном Linux, и даже это не сработало. ./configure auto && make ужасно аварийно завершает работу с некоторым кодом на ассемблере (для sandybridge ). Я могу построить только reference .

Итак, я думаю, что шаг 0 — добавить поддержку BLIS в numpy.distutils (в основном это уже работает), шаг 1 — протестировать на Linux, чтобы убедиться, что по крайней мере reference работает, шаг 2 — немного бенчмаркинга, ..., шагчто-то в винде.

@matthew-brett, предложенный вами текст для PyPI мне кажется приемлемым. Какие версии pip игнорируют имя с тегом ABI? В наши дни Pip часто требует обновления, поэтому я ожидаю, что у многих людей будет последняя версия. А версии старше 1(.5) лет вообще не устанавливали колеса по умолчанию.

@rgommers мои тесты выше были на Windows. Не MSVC, но mingwpy или openblas не будут сильно отличаться там - clang, вероятно, сработает, но требует реорганизации репо в blis, чтобы избежать символических ссылок.

Я не запускал тесты Джулии или numpy против blis, но blis проходил свои собственные модульные тесты. Дела пошли намного лучше, чем я предполагал из своего опыта 2014 года. Все еще нужно выяснить, как заставить многопоточность работать должным образом, но при этом у вас может быть уже конкурентоспособная производительность.

Похоже, эталонная конфигурация — единственная вещь в blis, которая сейчас работает для 32-битной x86. Это потребует написания новых микроядер сборки, я думаю, может быть, нет, см. комментарии njsmith ниже.

@tkelman , относительно ядер OpenBLAS для 32-битных https://github.com/numpy/numpy/issues/5479#issuecomment -185096062: согласно приват. сообщение, которое я получил от Вернера Саара некоторое время назад, что никто не работает над 32-битными ядрами Intel для более новых архитектур. Так что это факт, который вряд ли изменится в будущем. Основное внимание уделяется 64-битным процессорам Intel и ARM.

@tkelman , по поводу C-runtime https://github.com/numpy/numpy/issues/5479#issuecomment -185055210: ИМХО это не критично, так как ATLAS и OpenBLAS не разделяют ресурсы C-runtime (файловые дескрипторы и куча ). _Надеюсь, я прав_. Для сборок ATLAS может быть полезно увеличить размер стека. Это может быть задано как флаг во время связывания, т.е.:

-Wl,--stack,16777216

относительно обсуждений ATLAS и OpenBLAS: благодаря @matthew-brett теперь доступны библиотеки ATLAS на основе SSE2. Эту сборку Atlas следует сравнить со сборкой OpenBLAS с целью с поддержкой SSE2 (или просто установить OPENBLAS_CORETYPE=NORTHWOOD — в основном PENTIUM4), чтобы отключить обнаружение времени выполнения ЦП. Конечно, общая сборка OpenBLAS может использовать гораздо больше вариантов ЦП благодаря обнаружению ЦП во время выполнения. Это одна из причин, по которой OpenBLAS более эффективен по сравнению с ATLAS. Другой вопрос в надежности OpenBLAS. Может поможет репозиторий с собранными тестами BLAS, LAPACK.

по поводу BLIS/Flame: интересно, но по крайней мере на сегодняшний день это высоко висящий плод.

Однако принятие решения о том, как выбрать между ATLAS и OpenBLAS, для меня не ясно.

Ральф - пункт 8 установит колеса с новыми тегами Windows ABI, пункт 7 - нет. Пункт 7 и пункт 8 установят колеса без тегов ABI без предупреждения.

Есть еще много 7-ки, он был выпущен в августе 2015 года, поэтому я бы предпочел придерживаться более совместимого имени, по крайней мере, какое-то время.

+1 при расследовании BLIS. Это кажется хорошим долгосрочным решением. Мы вообще рассматривали Эйгена? Они поддерживают построение частичного интерфейса LAPACK, и для большей части кода используется лицензия MPL2. Этого может быть достаточно для NumPy.

Из кода обнаружения процессора BLIS я заметил, что он очень часто возвращается к эталонной реализации, если не находит инструкции AVX, которые все еще довольно недавние.

Ян: это состояние Эйгена примерно год назад: http://mingwpy.github.io/blas_lapack.html#eigen — поэтому я считаю, что было бы неплохо создать полезную библиотеку для numpy.

И что еще хуже, вчера я попробовал это на 32-битном Linux, и даже это не сработало. ./configure auto && make ужасно аварийно завершает работу с некоторым кодом на ассемблере (для sandybridge). Я могу только построить ссылку.

Если вы посмотрите на содержимое config/ , то увидите, что различные именованные «конфигурации» (например, «sandybridge», «haswell») на самом деле являются готовыми «стартовыми» конфигурациями, включающими в себя набор предварительно заданных настроек (а не только настройки, связанные с настройкой процессора, а также настройки режима многопоточности, настройки компилятора и т. д.). А конфигурация под названием «sandybridge» — это конфигурация x86-64. Похоже на ошибку, которую выбрала автоконфигурация, но да, это не будет работать на x86-32 :-). Похоже, что BLIS поставляется с 32-битными ядрами x86 (см. kernels/x86 ), хотя похоже, что на данный момент ни одна из готовых конфигураций не использует их. Создание новых конфигураций в основном тривиально; одна часть магии находится в файле bli_kernel.h , который называет внутреннее ядро ​​+ несколько размеров буфера. Мы могли бы узнать у воспитателей, есть ли у них предложения по x86-32.

Также:

BLIS на данный момент доступен только для Linux; есть открытый PR для поддержки сборки OSX, а до Windows очень далеко

Несколько комментариев выше, @tkelman создает и тестирует BLIS для Windows :-)

Предыдущий сырой бенчмарк test_dot с OpenBLAS 0.2.12:

In [2]: %timeit test_dot()
1 loop, best of 3: 449 ms per loop

По сравнению с (предыдущим результатом) MKL

In [9]: %timeit test_dot()
1 loop, best of 3: 764 ms per loop

64-битный АТЛАС:

In [10]: %timeit test_dot()
1 loop, best of 3: 2.41 s per loop

Поэтому, когда я сравниваю openblas и MKL (спасибо, conda) в последовательном соединении с конфигурацией Haswell BLIS, все они отличаются не более чем на 10-20% друг от друга на dgemm. Вот файл докеров, который успешно создан на концентраторе докеров для кросс-компиляции dll Windows каждой конфигурации (кроме бульдозера, который неправильно связал https://github.com/flame/blis/pull/37#issuecomment-185480513, да ладно) : https://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

Вы можете попробовать подключить что-то похожее на конфигурацию Трэвиса services: docker и поиграть с развертыванием бинарных артефактов в релизы github/bintray/что угодно.

Я смотрел на обнаружение ЦП BLIS -> код шаблона: https://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

Вот переписанный Python, который должен быть немного более либеральным в принятии одного из расширенных шаблонов (более вероятно, что ОС может использовать AVX, чем код C): https://gist.github.com/matthew-brett /a53778f99b7062cc332d

На всех машинах, на которых я тестировал, этот алгоритм возвращает «ссылку» — вероятно, потому, что у меня есть старые машины, которые никто не хотел использовать, чтобы спасти мою ферму билдботов.

Компиляция numpy по эталонному BLIS без lapack дает следующее на моем грубом тесте:

In [6]: %timeit test_dot()
1 loop, best of 3: 16.2 s per loop

Просто скалярное произведение двух (1000, 1000) массивов составляет 12 секунд. Итак, как также обнаружил Тони, эталонный BLIS — худший из наших вариантов, вокруг той же сборки по умолчанию без библиотеки numpy с lapack_lite.

Итак, я думаю, нам понадобится либо больше шаблонов, охватывающих старые машины, либо более либеральное определение ЦП -> сопоставление шаблонов, чтобы обеспечить разумную производительность на широком диапазоне машин.

@matthew-brett, когда мы можем ожидать появления новых 64-битных колес Windows ATLAS? Какая версия? v1.10.2? Будут ли они только в pypi или в Source Forge? Вы собираетесь сделать какое-то объявление? Большое спасибо!

@ matthew-brett, какое у вас было соотношение между атласом и эталонным блисом на одной машине? Сопоставимо с коэффициентом около 2, который я видел? У меня есть многопоточность для работы в blis, я просто неправильно включил rtfm (https://github.com/flame/blis/wiki/Multithreading), она не включается автоматически, и есть 4 разных переменных env для игры. . С этим патчем https://gist.github.com/0fc9497a75411fcc0ec5 для включения параллельного blis на основе pthreads для всех конфигураций и установки BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 blis Haswell в основном связан с mkl и openblas на моей машине. Если я установлю только BLIS_JR_NT на 2, то параллельная ссылка blis в большинстве случаев догонит atlas и будет быстрее с 3 потоками.

@tkelman IMO, было бы полезно, если бы вы могли задокументировать свой прогресс в BLIS на страницах NumPy GitHub Wiki. Я также думаю, что было бы интересно предложить план, аналогичный mingwpy, для создания колеса NumPy-BLIS-FLAME (и колеса SciPy-BLIS-FLAME, если это вообще возможно?).

@tkelman : чтобы убедиться, что я ясно - ваш атлас с резьбой, верно?
еще одна вещь, которую следует учитывать, — это добавление -msse2 или аналогичного параметрам сборки reference — похоже, что по умолчанию он максимально совместим и не позволяет компилятору использовать SSE, но, по крайней мере, в numpy-land Я знаю, что мы все равно переходим на SSE2 как на минимальную поддерживаемую конфигурацию по другим причинам...

Я не знаю, актуален ли FLAME прямо сейчас по сравнению с обычным LAPACK — мы хотели бы спросить.

Возможно, нам следует открыть новую тему для BLIS, вместо того, чтобы продолжать захламлять эту :-)

Для этой темы - я думаю, что мы уже можем отправить колесо с различными ядрами BLIS, выбранными во время выполнения, с использованием тех же правил, которые BLIS использует во время сборки, но я думаю, что это приведет к тому, что многие машины будут иметь эталон BLIS и, следовательно, будут хуже. производительность, чем 64-битный ATLAS, хотя 64-битный ATLAS в Windows особенно плох (для ATLAS).

Но если эталонная сборка быстрее, чем 64-битный ATLAS, скажем, с параметром -msse2, то это реальный вариант.

SSE2 — это минимальная конфигурация для 64-разрядной версии, поэтому безопасно использовать что-то вроде -mfpmath=sse -msse2 для эталонной компиляции.

Возможно, нам следует открыть новую тему для BLIS, вместо того, чтобы продолжать захламлять эту :-)

Это было бы хорошей идеей (редактировать: могу ли я предложить назвать его «Захвати BLIS», учитывая отношение @njsmith к газонам в https://github.com/numpy/numpy/issues/5479#issuecomment-184472378?) . Я думаю, что если @matthew-brett продолжит загрузку своих существующих колес Atlas, будет достаточно, чтобы закрыть это на данный момент, а будущая работа будет посвящена новым проблемам.

чтобы убедиться, что я ясно - ваш атлас с резьбой, верно?

Мой атлас - это dll из https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds , но я еще не видел, чтобы он успешно использовал более 1 потока. Мне не хватает переменной среды?

еще одна вещь, которую следует учитывать, — это добавление -msse2 или аналогичного параметрам сборки reference — похоже, что по умолчанию он максимально совместим и не позволяет компилятору использовать SSE.

SSE2 является частью спецификации x86_64, поэтому это актуально только для 32-разрядных систем. В Julia мы добавляем -march=pentium4 для наших 32-битных сборок.

Я не знаю, актуален ли FLAME прямо сейчас по сравнению с обычным LAPACK — мы хотели бы спросить.

Пламя еще не трогал, но поиграть стоит. В конце концов вы сможете использовать WIndows Clang в качестве резервного плана, альтернативного mingwpy. (изменить: на самом деле это не исправляет фортран в scipy, так что, возможно, нет)

@matthew-brett: Я думаю (могу ошибаться), что для ядра dunnington требуется только SSE3, который, как утверждает Steam Hardware Survey, присутствует на 99,94% машин (по сравнению с 99,99% для SSE2). Так что это кажется неправильным, если вы обнаружите, что большинство систем не могут справиться с этим - не знаю, является ли это ошибкой в ​​​​их коде процессора, в вашем каком-то действительно нерепрезентативном наборе тестовых машин или в моем понимании того, что требует это ядро.

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

Чтобы напомнить себе, для ссылки на BLIS мне понадобился site.cfg , например:

[blas]
blas_libs = numpy-blis-reference
library_dirs = c:\code\blis\test\lib
include_dirs = c:\code\blis\test\include

Я также сделал это, я предполагаю, что это необходимо (патч относительно numpy 1.10.4):

diff --git a/numpy/distutils/system_info.py b/numpy/distutils/system_info.py
index d7eb49e..3cb7f95 100644
--- a/numpy/distutils/system_info.py
+++ b/numpy/distutils/system_info.py
@@ -1680,18 +1680,11 @@ class blas_info(system_info):
         info = self.check_libs(lib_dirs, blas_libs, [])
         if info is None:
             return
-        if platform.system() == 'Windows':
-            # The check for windows is needed because has_cblas uses the
-            # same compiler that was used to compile Python and msvc is
-            # often not installed when mingw is being used. This rough
-            # treatment is not desirable, but windows is tricky.
-            info['language'] = 'f77'  # XXX: is it generally true?
-        else:
-            lib = self.has_cblas(info)
-            if lib is not None:
-                info['language'] = 'c'
-                info['libraries'] = [lib]
-                info['define_macros'] = [('HAVE_CBLAS', None)]
+        lib = self.has_cblas(info)
+        if lib is not None:
+            info['language'] = 'c'
+            info['libraries'] = [lib]
+            info['define_macros'] = [('HAVE_CBLAS', None)]
         self.set_info(**info)

     def has_cblas(self, info):

Утилита для обнаружения процессора во время выполнения: https://github.com/matthew-brett/x86cpu

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

Всем привет. Мысль: если вы хотите опубликовать несколько разных колес numpy, созданных с помощью различных векторных библиотек, вы можете использовать разные имена пакетов PyPI.

1. https://pypi.python.org/pypi/numpy/1.8.1
2. https://pypi.python.org/pypi/numpy-mkl
3. https://pypi.python.org/pypi/numpy-атлас

Я зарегистрировал 2, чтобы попытаться загрузить колеса Гольке, но PyPI их отклонил. Добро пожаловать на URL.

gh-7294 добавляет поддержку BLIS в numpy.distutils . Было бы здорово, если бы кто-то мог проверить, что это работает так, как ожидалось.

Есть еще много 7-ки, он был выпущен в августе 2015 года, поэтому я бы предпочел придерживаться более совместимого имени, по крайней мере, какое-то время.

Pip 7.0 еще не такой старый, так что это имеет смысл.

... Похоже, что BLIS поставляется с 32-битными ядрами x86 (см. kernels/x86), хотя похоже, что на данный момент ни одна из готовых конфигураций их не использует.

Это объясняет, спасибо.

Спасибо, Ральф, я проверю.

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

Я думаю, все, что нам сейчас нужно, это рекомендуемые шаблоны для машины с SSE2 и машины с SSE3, которые работают несколько быстрее, чем 64-битная сборка Windows ATLAS.

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

Эх, технически это возможно заставить это работать, но это все еще не очень хороший план, чтобы бросать сборки через стену вот так. У нас еще даже не было серьезного тестирования BLIS на Linux или OS X. Итак, в Windows, где часто задаваемые вопросы BLIS говорят :

Support for building in Windows is also a long-term goal of ours. 
The Windows build system exists as a separate entity within the top-level
windows directory. However, this feature is still experimental and should not 
(yet) be expected to work reliably. Please contact the developers on the blis-devel 
mailing list for the latest on the Windows build system.

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

Конечно, но, как показал Тони, на самом деле несложно собрать BLIS для Windows с помощью кросс-компиляции. Я считаю, что экспериментальная вещь - это их система сборки MSVC, которую мы не используем.

На данный момент я предлагаю использовать BLIS только для колеса Windows, но, конечно, было бы очень хорошо заставить его работать и для многих сборок Linux.

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

Для корректности тоже согласен. А если мы покажем, что

а) Все тесты numpy проходят на всех версиях Windows;
б) Все тесты numpy и scipy проходят в системе manylinux?

Мы можем сделать шаблон BLIS доступным для выбора во время выполнения и протестировать все ядра на современной машине. Я также могу проверить на некоторых старых неприятных машинах.

На данный момент я предлагаю использовать BLIS только для колеса Windows, но, конечно, было бы очень хорошо заставить его работать и для многих сборок Linux.

Я думаю, что manylinux менее важен, поскольку у нас есть менеджеры пакетов с полным стеком, а также пользователи, которым гораздо проще компилировать вещи. Прежде чем беспокоиться об этом в этом контексте numpy + BLAS/LAPACK, давайте сначала посмотрим, как развивается вся концепция manylinux :)

Для Windows, я думаю, наши приоритеты:

1) решение с полным стеком (требуется MingwPy с одним из OpenBLAS/ATLAS/BLIS)
2) временные бинарные колеса (у нас есть одно, которое скоро появится в вашей сборке ATLAS)
3) повышение производительности (1). Здесь может помочь BLIS.

Так что имхо не нужно торопиться с BLIS для Windows.

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

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

Для корректности тоже согласен. А если мы покажем, что

а) Все тесты numpy проходят на всех версиях Windows;
б) Все тесты numpy и scipy проходят в системе manylinux?

Это звучит неплохо. Имеет смысл также включить scikit-learn , это довольно значительный пользователь linalg.

Я не знал, что blis и libflame были частью кодовой базы ACML, которая некоторое время назад была открыта:

http://developer.amd.com/community/blog/2015/08/07/open-source-strikes-again-accelerated-math-libraries-at-amd/
http://developer.amd.com/tools-and-sdks/opencl-zone/acl-amd-compute-libraries/

Тем не менее: как решить проблему сравнения 4 различных ускоренных реализаций BLAS/Lapack для сборки numpy/scipy с MSVC или mingwpy для тестирования на различных архитектурах ЦП: от Pentium4 до Skylake?

Хорошая находка @carlk , я помню, как они объявляли об отказе от acml и acl с открытым исходным кодом, но я не помню, чтобы они приняли blis/libflame. Лицензия bsd — это очень хорошая новость! Есть ли способ работать с AMD и shpc в Ут-Остине, чтобы ориентироваться на numpy и Julia?

Мне удалось перекрестно скомпилировать libblis.a, используя msys2 и конфигурацию haswell из коробки, и пройти все тесты, исправив символические ссылки ядра, но я не смог собрать libflame — я получил ту же ошибку «список аргументов слишком длинный», что и в мой пост в списке рассылки blis-discuss. Также я лично не мог понять, как сделать ссылку на libblis.a из lapack, но я не очень старался.

С общественным лицензированием MKL невозможно ли предоставить колесо MKL на pypi, действительно ли лицензии несовместимы? Или просто невозможно построить scipy без ifort?

Одна проблема, и она, вероятно, относится к scipy, о которой не упоминалось, - это оставшиеся файлы Fortran в scipy. Извините за нубский вопрос, но почему мы должны их использовать? Мне кажется, что Fortran и отсутствие бесплатного многоплатформенного компилятора являются настоящей проблемой. Разве это не то, что mingwpy стремится решить. Учитывая либо бесплатный MKL, либо какой-то будущий волшебный acl blis/flame, любой, у кого есть c-компилятор, мог бы собрать его стек scipy, если бы не файлы *.f.

@mikofski , приятно слышать, что blis можно скомпилировать с помощью msys2. Это также верно для libflame? Думаю, нам нужна libflame для API Lapack.
Лично _это_ возможно иметь скомпилированный MSVC numpy и использовать его вместе с скомпилированным mingwpy scipy. Вам нужно добавить -mlong-double-64 к флагам gcc, чтобы гарантировать, что long удваивается == удваивается.

Сложно сделать это поведение по умолчанию на gcc, я играю с этой проблемой уже неделю :(

Я приду завтра с scipy колесами. Они будут основаны на Atlas, предоставленном numpy Wheels от @matthew-brett.

Тем не менее, я за использование OpenBLAS прямо сейчас.

Одна проблема, и она, вероятно, относится к scipy, о которой не упоминалось, - это оставшиеся файлы Fortran в scipy. Извините за нубский вопрос, но почему мы должны их использовать?

Потому что это много очень полезного и высокопроизводительного кода. И это не только BLAS/LAPACK — многие из scipy.sparse.linalg , scipy.linalg , scipy.special и scipy.interpolate , например, на Фортране. Кроме того, Scipy — не единственный проект с кодом Fortran, есть и другие пакеты, такие как bvp_solver , а также собственный код Fortran, который они обернули с помощью f2py.

Действительно, приятно найти Карла.

Тем не менее: как решить проблему сравнения 4 различных ускоренных реализаций BLAS/Lapack для сборки numpy/scipy с MSVC или mingwpy для тестирования на различных архитектурах ЦП: от Pentium4 до Skylake?

Это действительно требует приличной автоматизированной среды сборки/тестирования/бенчмарка. Нам не нужно возиться с очень старыми архитектурами ЦП (пока там все работает, все в порядке), а также, я думаю, не с MSVC. Но все же это будет некоторая работа, чтобы настроить это правильно.

@rgommers спасибо!

Всем привет. Мысль: если вы хотите опубликовать несколько разных колес numpy, созданных с помощью различных векторных библиотек, вы можете использовать разные имена пакетов PyPI.

https://pypi.python.org/pypi/numpy/1.8.1
https://pypi.python.org/pypi/numpy-mkl
https://pypi.python.org/pypi/numpy-atlas

Я зарегистрировал 2, чтобы попытаться загрузить колеса Гольке, но PyPI их отклонил. Добро пожаловать на URL.

@hickford , пожалуйста, не делай этого. Такое распространение двоичных файлов нарушает лицензию MKL (если у вас нет личной лицензии), и это неправильный способ делать это. В будущем мы, возможно, захотим распространять некоторые варианты через дополнения ( numpy[atlas] , numpy[openblas] и т. д.).

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

Mingwpy и любые проблемы с fortran, которые зависят от ссылки на ту же среду выполнения c, что и cpython, ограничены по скорости на @carlkl , экспериментирование с BLIS решает меньше проблем, но может быть выполнено независимо кем угодно. Я, к сожалению, исчерпал свой личный запас времени для просмотра BLIS прямо сейчас, но см. # 7294.

Тони, большое спасибо за вашу помощь, она была неоценима.

Я добавил сборку более позднего ATLAS (3.11.38) на 64-битной версии.

https://github.com/matthew-brett/np-wheel-builder

Это последовательная сборка (без потоков) из-за проблем с компиляцией 3.11.38 в Windows, но она должна быть немного быстрее, чем 3.10.1, и это соответствует моему простому тесту:

In [2]: %timeit test_dot()
1 loop, best of 3: 1.65 s per loop

по сравнению с более ранней сборкой 3.10.1 (см. выше):

In [10]: %timeit test_dot()
1 loop, best of 3: 2.41 s per loop

@tkelman - можете ли вы сравнить эту сборку с Джулией?

Извините, что вмешиваюсь в предыдущую заметку о двоичных файлах MKL — Intel предлагает
версия сообщества, которая должна разрешать распространение, поскольку она бесплатна для всех...
2 марта 2016 г., 15:08, «Мэттью Бретт» [email protected] написал:

Я добавил сборку более позднего ATLAS (3.11.38) на 64-битной версии.

https://github.com/matthew-brett/np-wheel-builder

Это серийная сборка (без потоков) из-за проблем с компиляцией 3.11.38.
в Windows, но он должен быть немного быстрее, чем 3.10.1, и на моем простом
эталон:

В [2]: %timeit test_dot()
1 петля, лучшая из 3: 1,65 с на петлю

по сравнению с более ранней сборкой 3.10.1 (см. выше):

В [10]: %timeit test_dot()
1 петля, лучшая из 3: 2,41 с на петлю

@tkelman https://github.com/tkelman — можете ли вы сравнить эту сборку с
Юля?

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-191431331 .

@mrslezak - лицензия разрешает повторное распространение, но возлагает на распространителя ответственность за любые судебные издержки, если Intel будет привлечен к суду в результате использования программного обеспечения. Кроме того, полученный двоичный файл не может быть лицензирован BSD. См.: http://mingwpy.github.io/blas_lapack.html#intel-math-kernel-library .

Можно ли этого избежать, добавив «предоставляется как есть, без какой-либо ответственности за
денежные потери, которые могут возникнуть в результате его использования' или что-то на это влияет?
2 марта 2016 г., 18:22, «Мэттью Бретт» [email protected] написал:

@mrslezak https://github.com/mrslezak — лицензия позволяет
перераспределение, но возлагает на распространителя ответственность за любые судебные издержки, если
На Intel подали в суд из-за использования программного обеспечения. Также в результате
двоичный файл не может быть лицензирован BSD. Видеть:
http://mingwpy.github.io/blas_lapack.html#intel-math-kernel-library

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-191505500 .

Я не думаю, что это сработает, потому что мы должны согласиться с лицензией Intel, а в лицензии Intel говорится, что мы несем ответственность за их судебные издержки, если им предъявят иск. Я предполагаю, что мы могли бы потребовать от пользователей не подавать в суд на Intel в нашем лицензионном соглашении, и поэтому, возможно, если они подадут в суд на Intel, и Intel попросит у нас деньги, мы можем попытаться подать в суд на пользователя за эти сборы, но тем не менее - положив это на нашу лицензия увела бы нас еще дальше от BSD и потребовала бы от пользователя явного согласия, что нецелесообразно в случае колес, установленных pip.

Сборка ATLAS для SSE3 дает прирост производительности только на 5% по сравнению с ATLAS SSE2, но сборка была сложной, и мне пришлось отключить наиболее очевидные флаги включения для SSE3 и просто использовать -msse3 .

Я написал письмо в список рассылки numpy с предложением развернуть эти колеса: https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html .

@matthew-brett Как человек, поддерживающий Windows с приложениями Python, спасибо.

@matthew-brett, я добавил 2 проблемы в ваш репозиторий atlas-build-scripts.
См. https://github.com/matthew-brett/atlas-build-scripts/issues .

Первый https://github.com/matthew-brett/atlas-build-scripts/issues/1 важен, так как numpy-atlas.dll экспортирует много символов и, таким образом, предотвращает дальнейшее использование с mingwpy без взлома импорта библиотека.

@matthew-brett извините, я был немного занят, чтобы провести еще один бенчмаркинг. Были ли какие-либо из предыдущих сборок атласа многопоточными? Мне не удалось запустить первую сборку на нескольких ядрах. Суть должна быть довольно простой, даже если вы не очень хорошо знакомы с julia. Или вас в основном интересовало более новое оборудование, чем то, к которому у вас есть доступ?

Не волнуйтесь - не ожидал, что вы все бросите и проведете тесты.

На самом деле моя последняя сборка атласа не была многопоточной - очевидно, ATLAS 3.11 нуждается в дополнительной доработке, чтобы многопоточность работала в Windows.

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

Колеса Windows теперь работают на pypi: https://pypi.python.org/pypi/numpy/1.10.4

Извините, Тони, да, предыдущие сборки ATLAS 3.10 были (или казались) многопоточными.

Думаю, теперь мы можем закрыть этот вопрос. Возможно, @matthew-brett вам следует перенести свой https://github.com/matthew-brett/np-wheel-builder в numpy org или, возможно, внести его в качестве PR в репозиторий numpy в папке инструментов .

Ральф, какие-нибудь предложения о том, куда следует np-wheel-builder ? numpy/vendor может быть?

Я бы предпочел отдельное новое репо ( numpy-wheel-builder ?) Под нулевой организацией, я думаю. Есть совпадение с numpy-vendor по назначению, но не сильно по коду. Этот репозиторий довольно большой, он действительно предназначен для работы под Wine, а набор инструментов gcc в нем устарел.

Согласен со мной - согласен с вами, чтобы продолжить и создать это?

Меня это устраивает, хотя, если это специфично для Windows (прямо сейчас это AFAICT?), то в имени репо должно быть «окна» :-). Или же это может быть место, где мы поместим аналогичную инфраструктуру и для других колес. Я также был бы в порядке, если бы поместил его прямо в репозиторий numpy где-нибудь, если он достаточно мал для того, чтобы это имело смысл. Что бы ни работало :-)

В репо есть довольно большие двоичные файлы ATLAS, я думаю, это сделало бы репозиторий numpy большим, а не хорошей целью.

Как насчет win-wheel-builder ?

Как насчет windows-wheel-builder . Я не фанат win ;)

Как насчет того, чтобы не делать его специфичным для Windows и иметь конфигурацию macosx и будущей сборки колес manylinux1 в одном месте?

В противном случае +1 за «окна» вместо «победа».

Как насчет того, чтобы не делать его специфичным для Windows и иметь конфигурацию macosx и будущей сборки колес manylinux1 в одном месте?

Было бы проще изменить вещи на всех платформах. Но я ожидаю, что для OS X и Linux понадобятся только сценарии сборки, а для Windows у нас есть огромные двоичные файлы ATLAS. Если все это собирается в одном репо, можно ли как-то разделить двоичные файлы ATLAS (возможно, с помощью git-lfs)?

Используйте хранилище больших файлов (LFS) на github для двоичных файлов

@rgommers : я думаю, что скоро мы будем выпускать бинарные файлы atlas-or-some-other-blas для Linux и, возможно, также для OSX (например, если мы решим, что устали ускорять нарушение многопроцессорности).

можно было бы начать использовать выпуски github или bintray или что-то в этом роде вместо того, чтобы проверять их... не то чтобы они все такие большие, пока вы не начнете получать сборки openblas с поддержкой DYNAMIC_ARCH или эквивалентные комбинации нескольких конфигураций blis

Как насчет размещения репозитория как windows-wheel-builder на данный момент и рефакторинга/переименования, когда станет более ясно, что мы собираемся делать с Linux/OSX?

Звучит неплохо.

со мной тоже все в порядке

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

@matthew-brett: меня очень смущает страница разрешений github (и, в частности, numpy - беспорядок), но если вы хотите сделать меня администратором репозитория или передать репо мне, я могу переместить его в numpy/

Я передал репо @njsmith ...

https://github.com/numpy/виндовс-колесо-строитель

Есть ли учетная запись numpy appveyor? Может ли кто-нибудь включить сборки Appveyor для этого репо?

Кажется, мы используем учетную запись @charris на Appveyor...

Да, смотрите здесь https://ci.appveyor.com/project/charris/numpy/history

В среду, 16 марта 2016 г., в 00:15, Натаниэль Дж. Смит <
уведомления@github.com> написал:

Я думаю, что мы используем @charris https://github.com/charris Appveyor
Счет...

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -197064930

На самом деле, я только что создал новую групповую учетную запись для numpy в appveyor (все равно собирался сделать это, и это побудило меня сделать это :-)) и включил ее там:
https://ci.appveyor.com/project/numpy/windows-wheel-строитель

@njsmith Как тебе это удалось? Последнее, что я видел, кому-то нужно было попросить администраторов создать учетные записи проекта, и способ добавления других к нему был не совсем прозрачным.

Если учетная запись работает, я хотел бы передать ответственность за тестирование numpy.

@charris : проверьте свою электронную почту :-). Я только что создал индивидуальную учетную запись с numpy-steering-council @googlegroups.com в качестве физического лица. Я не знал, что проектные учетные записи существуют... Хотим ли мы их?

ради очереди вы наверное хотите разнести разные проекты по разным аккаунтам

Недостатком использования почты numpy-steering-council является то, что appveyor отправляет уведомления, когда тест слияния терпит неудачу. Если в наши дни у разработчиков есть что-то получше, было бы неплохо использовать это, но, учитывая бардак, который был в их интерфейсе в прошлом, я бы не стал на это ставить.

@tkelman Хороший вопрос. Кроме того, если мы собираемся тратить деньги на более быструю очередь, нам, вероятно, нужно что-то более официальное.

@charris : я только что попытался включить тестирование numpy/numpy в новой учетной записи appveyor, а также отключить все уведомления, а также добавить все соответствующие команды numpy github в качестве администраторов в учетной записи - посмотрим, что произойдет. предполагать...

@matthew-brett: Мне приходит в голову, что наиболее элегантным подходом может быть спрятать сборки BLAS где-нибудь, например, numpy/windows-build-tools , но запустить настоящие инструменты сборки колес из реального репозитория numpy/numpy как часть сборки appveyor — они могли выгружать бинарные файлы BLAS по требованию.

Спасибо за отличную работу! Будут ли скоро в pypi добавлены оконные колеса numpy 1.11.0? https://pypi.python.org/pypi/numpy

о да, нам, возможно, нужно выяснить, как обновить наши процедуры выпуска здесь ... IIUC пользовательский опыт прямо сейчас заключается в том, что, как только исходный выпуск 1.11 был загружен, все машины Windows там внезапно отключились от загрузки колес (ура ) до попытки загрузить и собрать исходный код (бу). Я предполагаю, что «правильный» способ сделать это состоит в том, что после того, как окончательный выпуск будет помечен, мы создадим и загрузим все бинарные колеса _перед_ загрузкой sdist. Как бы это ни раздражало...

@njsmith , это было бы неплохо, но отставание на несколько минут (или даже на несколько часов) меня устроит.

Просто чтобы уточнить, являются ли текущие файлы Windows whl на PyPI для сборки выпуска 1.11.0 против ATLAS? Есть ли сценарий сборки, которым можно поделиться?

Да, колеса настроены против ATLAS, но мы думаем о переходе на OpenBLAS, когда будем уверены в результатах.

Сборка автоматизирована через Appveyor: https://github.com/numpy/windows-wheel-builder

23735 downloads in the last day . знак равно

Возможно, удастся создать выпуск hidden — по крайней мере, в форме PyPI есть опция https://pypi.python.org/pypi?%3Aaction=submit_form и показать ее, когда все файлы будут готовы.

К сожалению, функция скрытого релиза мешает людям получить этот релиз через командную строку, она только мешает им увидеть релиз через графический интерфейс pypi:

https://sourceforge.net/p/pypi/support-requests/428/

Я пробовал 64-битную установку numpy для Windows, и это прекрасно работает, так что спасибо всем, кто потрудился над этим.

Мне интересно, есть ли еще план сделать то же самое с колесами scipy? Ожидается ли решение о переходе на OpenBLAS?

На https://bitbucket.org/carlkl/mingw-w64-for-python/downloads есть несколько тестовых колес scipy-0.17.0. Эти колеса были созданы с помощью mingwpy против сборок @matthew-brett numpy https://pypi.python.org/pypi/numpy/1.10.4 .

В четверг, 28 апреля 2016 г., в 12:48, [email protected] написал:

На https://bitbucket.org/carlkl/mingw-w64-for-python/downloads есть
некоторые тестовые колеса scipy-0.17.0. Эти колеса были построены с
mingwpy против @matthew-brett https://github.com/matthew-brett
сборки numpy https://pypi.python.org/pypi/numpy/1.10.4

Извините, если вы уже сказали, и я пропустил это - но у вас есть какой-нибудь тест
провалы для этих колес?

Вы ссылаетесь на ATLAS, поставляемый внутри numpy Wheels?

@matthew-brett, я анонсировал эти сборки месяц назад, но не помню где. В любом случае, эти сборки ссылаются на numpy-atlas, предоставленный вашими numpy Wheels.

scipy-0.17.0-cp35-cp35m-win##.whl связаны с _неправильной_ средой выполнения C msvcrt.dll. Для scipy это кажется нормальным. Журналы испытаний находятся здесь: https://gist.github.com/carlkl/9e9aa45f49fedb1a1ef7 .

Это правильный журнал? В конце стоит NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy .

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

Вы получаете меньше ошибок для 64-битной сборки? Для текущей лучшей сборки против openblas 0.2.18?

64bit имеет только 6 сбоев, все с:

FAIL: test_continuous_basic.test_cont_basic(<scipy.stats._continuous_distns.nct_gen object ...

Я знаю: это плачет по сравнению с OpenBLAS. Тем не менее, я застрял с последних 4 недель по нескольким причинам, как вы могли заметить. Надеюсь, ситуация и дальше будет улучшаться.

@matthew-brett, я был бы признателен за использование сборок numpy MSVC с OpenBLAS. Мои последние сборки здесь:

• https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/OpenBLAS-0.2.17_win32.7z
• https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/OpenBLAS-0.2.17_amd64.7z

Как будто mingwpy, conda-forge, Anaconda и Canopy было недостаточно, появился дистрибутив Intel для Python , который можно загрузить бесплатно . Он включает в себя только числовые инструменты (SciPy, NumPy, Numba, Scikit-Learn), а также некоторые дополнительные функции (интерфейс mpi4py Intel mp и анализ данных pyDAAL) и использует conda.

Не беспокойтесь, срок действия лицензии истекает 29.10.16, поэтому эти сборки Intel — всего лишь
бета-тест, за которым, вероятно, следует лицензионный сбор MKL + и т. д. Сборки OpenBLAS
останется решением с открытым исходным кодом, поэтому спасибо за предоставление этих
строит.
28 апреля 2016 г., 19:21, «Марк Микофски» [email protected] написал:

Как будто mingwpy, conda-forge, Anaconda и Canopy было недостаточно.
дистрибутив Intel для Python
https://software.intel.com/en-us/python-distribution и это бесплатно
скачать
https://software.intel.com/en-us/articles/intel-distribution-for-python-support-and-documentation.
Он включает в себя только числовые инструменты (SciPy, NumPy, Numba, Scikit-Learn).
плюс некоторые дополнения (интерфейс mpi4py Intel mp и аналитика данных pyDAAL) и
использует конду.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -215600103

В версии 1.11.1 похоже, что в PyPi отсутствует колесо Windows для Python 3.5 amd64.

Есть ли для этого особая причина? Если я перейду на 1.11.0 (https://pypi.python.org/pypi/numpy/1.11.0), колесо там.

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

Я загрузил недостающее колесо.

Я только что протестировал его, и он отлично работает!

Большое спасибо за всю проделанную работу, чтобы сделать колеса Windows доступными.

Закрытие вопроса - колеса были доступны для последних нескольких выпусков.

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

Это остается проблемой для пользователей Windows, пытающихся запустить свой научный стек, не прибегая к conda. Мне все еще нужно использовать сборки @cgohlke MKL, чтобы увидеть эту связанную проблему scipy , которая остается открытой. Хотя колеса создаются, не будучи совместимыми с scipy, они не подходят для многих.

@waynenilsen у вас есть инструкции по установке новых колес в ветке списка рассылки, связанной с проблемой, которую вы только что упомянули:

https://github.com/scipy/scipy/issues/5461#issuecomment -326744515

Итак, если вы сделаете

pip install -f https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com/ --pre scipy

это должно работать для вас.

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

Это отлично работает для меня @Juanlu001 Я действительно с нетерпением жду, когда это появится на pypi!