Размер памяти имеет значение, затраты на задержку нанесут вам вред:
Дано mM.shape == [159459, 159459]
,
дано mM.dtype
по умолчанию float(64)
потребуется около:
203.42 [GB]
для оригинала mM[159459, 159459]
, плюс
203.42 [GB]
для вычисленного mU[159459, 159459]
, плюс
203.42 [GB]
для вычисленных Vh[159459, 159459]
0.0013 [GB]
для вычисленных vS[159459]
Самый дешевый из когда-либо сделанных шагов - попытка линейного масштабирования в 2 раза (и не более 4) с float64
до float32
или даже float16
не меняет правила игры и даже влечет за собой серьезные штрафы. из-за неэффективности numpy
(если внутренне не выполнить обратное преобразование до float64
снова - мои собственные попытки были настолько плачевными по этому поводу, что я разделяю полученную неудовлетворенность здесь, чтобы избежать повторения моих собственных ошибок при попытке начать сначала самый низкий висящий фрукт ...)
В случае, если ваш анализ может работать только с вектором vS
, только флаг .svd( ..., compute_uv = False, ... )
позволит избежать пробела для ~ 1/2 [TB]
RAM-распределений , если не возвращать (и, следовательно, не резервировать место для них) экземпляры mU
и Vh
.
Даже такой случай не означает, что ваш SLOC выживет, как и в описанной 0.5 TB
RAM-системе. Обработка scipy.linalg.svd()
будет распределять внутренние рабочие ресурсы, которые выходят за пределы вашей области кодирования (конечно, если вы самостоятельно не переформулируете и не перепроектируете модуль scipy.linalg
, что справедливо считать весьма вероятным, если вы не уверены ) и контроль конфигурации. Поэтому имейте в виду, что даже когда вы тестируете compute_uv = False
-мод обработки, .svd()
все равно может выдать ошибку, если не удается внутренне выделить требуемые внутренне используемые структуры данных, которые не соответствуют текущей оперативной памяти.
Это также означает, что даже при использовании numpy.memmap()
, который может быть удачным трюком для разгрузки представления в оперативной памяти оригинального mM
(избегая некоторых Замечательная часть первой потребовалась 203.4 [GB]
от сидения и блокирования использования оперативной памяти хоста), но за использование этого трюка придется заплатить.
Мои эксперименты, в меньших масштабах .memmap
-s, используемых для матричной обработки и в ML-оптимизации, дают примерно 1E4 ~ 1E6
более медленную обработку , потому что, несмотря на интеллектуальное кэширование, numpy.memmap()
-экземпляры зависят от дискового ввода-вывода.
Наилучший результат будет получен при использовании усовершенствованных устройств хранения размером только 1087 * SSD, размещенных прямо на вычислительном устройстве, на некоторой шине доступа с быстрой задержкой M.2 или PCIx16.
Последний опыт, который, возможно, еще не захочется услышать здесь:
Использование большего объема оперативной памяти на базе хоста, что означает использование многотабайтного вычислительного устройства, является самым безопасным способом пойти дальше. Тестирование предложенных выше шагов поможет, если снижение производительности и дополнительные расходы находятся в пределах бюджета вашего Проекта. Если нет, обратитесь за помощью к центру HPC в своем Alma Mater или в ближайший исследовательский центр вашего Проекта, где обычно используются такие мульти-ТБ вычислительные устройства.