Native CPU: transforms' width by rows and row length, not element count

Abierto
  • ¿Algo no está bien?
#587 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, performance

Línea de trabajo

Start by inspecting State.execution_sizing for the line problem and grin_nonlinear to confirm rows, row length, and thread counts. Then read operation_threads for the fft class and the SEP 46 grain calibration path, especially grain.TIMED. Done when width thresholds depend on shape, built-in values preserve current choices, and the grain stage calibrates the transforms again; validate the stated no-slower requirement on the Xeon Gold 6240 and EPYC 7763.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What

The native CPU transforms choose their width from one threshold in elements (fft_threshold, fft_full), and transforms of the same element count want opposite widths depending on their shape. SEP 46's calibration (#582) therefore leaves the transforms' thresholds at the built-in table.

Evidence

On AMD EPYC 7763 and 9B45 cores (16 of each), SEP 46's grain stage admitted a full width from 98304 elements (fft_full 98304 in place of 131072):

  • the calibration's one-dimensional free-space problem (many short rows) ran 0.56 of the table;
  • grin_nonlinear on the tracking set ran 1.08–1.10 times slower; with the grain alone (no FFT wisdom) on the EPYC 9B45, 1.10 (range 1.08–1.29 over three rounds); on the EPYC 7763, 1.087;
  • on 16 cores of a Google Axion the same move came with no loss on grin_nonlinear (1.005).

That grin_nonlinear's rows are few and long (about 16 × 6144) and the line problem's many and short is the likely explanation, still to be confirmed from both problems' execution_sizing.

To do
  • Confirm the two transforms' shapes (rows, row length, threads) from State.execution_sizing.
  • Key the transforms' width on rows and row length (for example, a full team only when every thread gets at least a minimum number of rows, with the row length as a second axis), in operation_threads for the fft class.
  • Give the new thresholds built-in values reproducing today's choices, and let SEP 46's grain stage calibrate them again (grain.TIMED).
Done when

The transforms' width depends on their shape, grin_nonlinear and the line problem both run no slower than today at every width on an Intel Xeon Gold 6240 and an AMD EPYC 7763, and SEP 46's grain times the transforms' thresholds again.

Lenguaje dominante
Python
Estrellas
3
Forks
3
Merge medio
8 h 36 min
PR fusionados (30 d)
165

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de LupoLab/solprop

Todos los issues de LupoLab/solprop

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.