Как strides и memory layout (C-contiguous/F-contiguous) влияют на производительность?

C-contiguous vs F-contiguous

import numpy as np

# C-contiguous (row-major) — по умолчанию в NumPy
c_arr = np.array([[1, 2, 3], [4, 5, 6]], dtype=np.float64, order='C')
print(c_arr.strides)  # (24, 8) — 3 элемента * 8 байт = 24 для следующей строки
print(c_arr.flags['C_CONTIGUOUS'])  # True

# F-contiguous (column-major) — как в Fortran/MATLAB
f_arr = np.array([[1, 2, 3], [4, 5, 6]], dtype=np.float64, order='F')
print(f_arr.strides)  # (8, 16) — 8 для следующей строки, 2*8=16 для следующего столбца
print(f_arr.flags['F_CONTIGUOUS'])  # True

Strides и memory layout в NumPy

Strides — это кортеж, описывающий сколько байт нужно пройти в памяти для перехода к следующему элементу по каждой оси. Layout определяет физический порядок элементов в памяти и напрямую влияет на эффективность кэша CPU.

Влияние на производительность через cache locality

CPU читает память блоками (cache lines, обычно 64 байта). Если данные расположены последовательно, каждый cache miss подгружает несколько полезных элементов. При несмежном доступе каждый элемент требует отдельной загрузки в кэш.

import numpy as np
import time

N = 5000
c_arr = np.random.rand(N, N).astype(np.float64)           # C-order
f_arr = np.asfortranarray(c_arr)                          # F-order

# Операция по строкам: C-contiguous выигрывает
start = time.perf_counter()
for i in range(N):
    _ = c_arr[i, :].sum()  # Последовательный доступ в C-order
print(f"C row sum: {time.perf_counter() - start:.4f}s")

start = time.perf_counter()
for i in range(N):
    _ = f_arr[i, :].sum()  # Stride-hop в F-order
print(f"F row sum: {time.perf_counter() - start:.4f}s")

# Результат: C-order в 3-5x быстрее для row-wise операций

Проверка contiguity и создание смежного массива

arr = np.random.rand(4, 4)
transposed = arr.T  # Транспонирование меняет strides, не копирует данные

print(transposed.flags['C_CONTIGUOUS'])  # False
print(transposed.flags['F_CONTIGUOUS'])  # True
print(transposed.strides)               # (8, 32) — strides поменялись

# Получить C-contiguous копию
c_copy = np.ascontiguousarray(transposed)
print(c_copy.flags['C_CONTIGUOUS'])     # True
print(np.shares_memory(transposed, c_copy))  # False — это копия

Non-contiguous strides: views через срезы

arr = np.arange(100, dtype=np.float64)
every_other = arr[::2]  # view, stride = 16 байт вместо 8
print(every_other.strides)  # (16,)
print(every_other.flags['C_CONTIGUOUS'])  # False

# NumPy ufuncs работают с любыми strides, но медленнее
# np.sort, np.concatenate создают contiguous копию при необходимости

# Для передачи в Cython/Ctypes/torch.from_numpy нужен contiguous массив
contiguous = np.ascontiguousarray(every_other)
print(contiguous.strides)  # (8,) — теперь смежный

Выбор order при создании массивов

import numpy as np

# Матричное умножение: NumPy (через BLAS) сам разберётся с layout
A = np.random.rand(1000, 1000)
B = np.random.rand(1000, 1000)
C = A @ B  # Быстро независимо от order

# Итерация по строкам — используйте C-order (по умолчанию)
data = np.random.rand(10000, 100)  # C-order by default
row_sums = data.sum(axis=1)  # Быстро: последовательный доступ

# Итерация по столбцам — используйте F-order или транспонируйте
data_f = np.asfortranarray(data)
col_sums = data_f.sum(axis=0)  # Быстрее для F-order

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

• arr.T не копирует данные: транспонирование только меняет strides и shape. Результат F-contiguous, и передача такого массива в функции, ожидающие C-contiguous, приведёт к ошибке или скрытому копированию.
• torch.from_numpy требует C-contiguous: передача F-contiguous или non-contiguous массива вызовет RuntimeError. Всегда вызывайте np.ascontiguousarray() перед конвертацией.
• Срезы с шагом создают non-contiguous views: arr[::2] или arr[:, 1::3] возвращают view с нестандартными strides.
• np.reshape может вернуть копию: если массив не contiguous, reshape() вернёт копию вместо view. Проверяйте через np.shares_memory().
• F-order и C-order в eye/zeros: параметр order влияет только на 2D+ массивы; для 1D различия нет.
• BLAS-библиотеки оптимизированы для обоих layout: матричное умножение через @ или np.dot() эффективно работает с обоими, но промежуточные операции могут делать неожиданные копии.

• Отвечать определением без production-сценария.
• Не называть runtime boundary, security boundary или failure mode.
• Игнорировать версию API, observability и тестовую проверку.

• Объясняет механизм своими словами и без выдуманных API.
• Называет реальные риски, диагностику и критерий корректности.
• Связывает ответ с текущей документацией и миграционными ограничениями.