Как расположение памяти (C-order vs Fortran-order) влияет на производительность массивов NumPy?

Как проверить порядок и страйды

import numpy as np

A_c = np.array([[1, 2, 3],
                [4, 5, 6]], dtype=np.float64, order='C')

A_f = np.array([[1, 2, 3],
                [4, 5, 6]], dtype=np.float64, order='F')

print(A_c.flags['C_CONTIGUOUS'])  # True
print(A_f.flags['F_CONTIGUOUS'])  # True

# Страйды (байт между соседними элементами по каждой оси)
print(A_c.strides)  # (24, 8)  — шаг по строке 24 байта, по столбцу 8
print(A_f.strides)  # (8, 16)  — шаг по строке 8 байт, по столбцу 16

C-order и Fortran-order: что это

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

• C-order (row-major) — последний индекс меняется быстрее. Строка [i, :] лежит непрерывно. Это умолчание NumPy (order='C').
• Fortran-order (column-major) — первый индекс меняется быстрее. Столбец [:, j] лежит непрерывно. Используется в Fortran, MATLAB, R, некоторых BLAS-рутинах.

Влияние на производительность: кеш-линии

Современный CPU загружает данные в кеш блоками (cache line ~64 байта). Обращение к памяти в последовательном порядке (spatial locality) даёт максимальную скорость. Случайные прыжки по памяти вызывают cache miss и замедляют вычисления в 10–100 раз.

import numpy as np
import time

N = 4096
A_c = np.random.rand(N, N)           # C-order (умолчание)
A_f = np.asfortranarray(A_c)         # Fortran-order

# Обход по строкам — быстро для C-order
t0 = time.perf_counter()
for i in range(N):
    _ = A_c[i, :].sum()              # смежные адреса
print(f"C row-wise:    {time.perf_counter()-t0:.3f}s")

t0 = time.perf_counter()
for i in range(N):
    _ = A_f[i, :].sum()              # неконтинуальный доступ
print(f"F row-wise:    {time.perf_counter()-t0:.3f}s")

# Обход по столбцам — быстро для F-order
t0 = time.perf_counter()
for j in range(N):
    _ = A_f[:, j].sum()              # смежные адреса
print(f"F col-wise:    {time.perf_counter()-t0:.3f}s")

Влияние на операции NumPy и BLAS

• Функции numpy (sum, mean по оси) и операции BLAS (matmul) сами учитывают флаги C/F-contiguous и выбирают оптимальный путь.
• Транспонирование A.T не копирует данные — просто меняет страйды. C-order массив после транспонирования становится F-contiguous.
• При передаче массива в C-расширения или BLAS требуется contiguous буфер: используйте np.ascontiguousarray(A) или np.asfortranarray(A).

Практические рекомендации

import numpy as np

# Проверка контигуальности перед вызовом C-расширений
def safe_process(arr):
    if not arr.flags['C_CONTIGUOUS']:
        arr = np.ascontiguousarray(arr)  # копирует если нужно
    return arr

# Создание с явным порядком
A = np.zeros((1000, 1000), order='F')   # для Fortran-совместимых библиотек

# Копирование с изменением порядка
A_c = np.array(A, order='C')            # принудительно C-order

# Проверка через np.isfortran
print(np.isfortran(A))    # True
print(np.isfortran(A_c))  # False

Подводные камни

• Транспонирование не меняет физическую память: A.T — это view с изменёнными страйдами; если после этого обходить по строкам, память читается неконтинуально.
• Slicing нарушает контигуальность: срез вида A[::2, :] создаёт non-contiguous view; функции, требующие contiguous буфер, вызовут ошибку или неявно скопируют данные.
• np.ascontiguousarray копирует данные: вызов внутри горячего цикла убьёт производительность — выносите вызов наружу.
• scipy/BLAS ожидают F-order для некоторых функций (например, LAPACK routines): передача C-order матрицы приводит к скрытому копированию внутри scipy.
• Создание через reshape: A.reshape(M, N) возвращает view при C-order и копирует при F-order (или наоборот в зависимости от флага order) — результат может быть неожиданным.
• Многоядерный NumPy (OpenBLAS/MKL): при смешанном порядке в батч-операциях BLAS может не задействовать все ядра из-за неоптимального расположения данных.
• Передача в TensorFlow/PyTorch: фреймворки ожидают C-contiguous тензоры; F-order массив перед конвертацией будет скопирован.

• Объяснять memory order performance только синтаксисом без shape, dtype, состояния или режима выполнения.
• Игнорировать leakage, воспроизводимость, пустые входы и скрытые копии данных.
• Не проверять production-симптомы: latency, память, ретраи, дрейф качества и несовпадение версий.

• Может ли связать memory order performance с реальным контрактом входов и выходов.
• Упоминает ли тесты, метрики, reproducibility и диагностику ошибок.
• Видит ли различие между demo-кодом в ноутбуке и production-пайплайном.
• Предлагает ли observability, rollback, ограничения стоимости и стратегию incident replay.