Во-первых, матрица 10 миллионов x 10 миллионов просто огромна. Предполагая удвоения для каждой ячейки и не перегружая хранилище, каждая из этих вещей будет 800 терабайт. Простое чтение каждой ячейки из основной памяти (если она каким-то образом волшебным образом туда поместится, чего явно не происходит), заняло бы дни. Выполнение этого из любого вероятного SAN (мы поместим его в 10GbE) с большей вероятностью займет месяцы. И никакое умножение матриц не имеет сложности O (n) - нормальные подходы O (n ^ 3). Итак ... вы не делаете это с файлами, отображенными в память, общими базами данных или чем-то в этом роде.
Код, выполняющий что-то подобное, будет жить или погибать от эффективности кеша, где «кеш» включает в себя эффективное использование основной памяти, локальных дисков. Поскольку любой интерфейс хранилища, содержащий более одной 800-терабайтной матрицы, обязательно является своего рода SAN, вы почти наверняка задействуете несколько серверов, которые читают и работают с разными его частями.
Существует множество хорошо известных способов распараллеливания умножения матриц (по существу, умножения подматриц различного размера и последующего объединения результатов) и изменения структуры, чтобы шаблоны доступа имели разумную локализацию кэша путем организации данных вокруг * 1005. * кривые заполнения пространства вместо расположения строк / столбцов. Вам наверняка захочется взглянуть на классические LAPACK интерфейсы и дизайн, MKL , GotoBLAS от Intel в качестве реализаций функций BLAS, настроенных на конкретное современное оборудование и после этого вы, вероятно, отправляетесь на неизведанную территорию: -)