Skip to content

English · Español

Fase 1 — Cuestionarios

Espejo legible de data/quizzes/phase-01-hardware-substrate.yaml. Diseñado para que un aprendiz reflexivo se equivoque al menos en uno de estos en el primer intento.

Fuente de verdad: data/quizzes/phase-01-hardware-substrate.yaml.


q-01-01 — ¿Qué representa el punto de cresta (ridge point) del roofline?

  1. La intensidad mínima a la que el kernel pasa a estar limitado por cómputo.
  2. El tamaño máximo de cache en bytes por FLOP.
  3. El número de FLOPs por ciclo de CPU.
  4. El límite de paralelismo a nivel de instrucción del ordenador.
Respuesta **Opción 1.** La coordenada x del ridge es `π / β` — la intensidad aritmética por encima de la cual el kernel puede saturar los FLOPs, y por debajo de la cual no puede porque la memoria no es capaz de alimentar a las FPUs lo bastante rápido.

q-01-02 — Efectos del cache-line sobre el stride (opción múltiple)

Una línea de 64 bytes contiene 8 doubles. Recorres un array de 1M elementos con stride S.

  1. Stride 1 hace uso óptimo de la línea: 8 cargas útiles por línea traída.
  2. Stride 8 desperdicia la línea: 1 elemento útil por cada 64 bytes traídos.
  3. Stride 16 usa menos líneas de cache que stride 1 y por tanto es más rápido.
  4. Los prefetchers de hardware ayudan más al stride unitario que a strides grandes.
  5. Duplicar el stride de 8 a 16 reduce a la mitad el número de líneas de cache traídas, por lo que el tiempo de pared se reduce a la mitad.
Respuesta **Opciones 1, 2, 4.** Las opciones 3 y 5 confunden "líneas traídas por elemento" con "tiempo de pared". Más allá de stride 8, cada elemento útil sigue costando 1 línea de cache — el tiempo de pared se mantiene aproximadamente plano (o peor, porque la presión sobre la TLB y los fallos de predicción del prefetcher entran en juego).

q-01-03 — Cálculo de roofline (respuesta libre)

Un kernel realiza 2N FLOPs y mueve 8N bytes. Máquina: π = 100 GFLOPS, β = 25 GB/s. Calcula I, el ridge, el rendimiento alcanzable, y enuncia el régimen.

Respuesta - **I** = 2N / 8N = **0.25 FLOPs/byte**. - **Ridge** = π/β = **4.0**. - **I < ridge** → **memory-bound**. - **Rendimiento alcanzable** = I × β = 0.25 × 25 = **6.25 GFLOPS** (las FPUs corren ~94% en idle).

q-01-04 — ¿Por qué matmul es compute-bound pero la suma elemento a elemento es memory-bound? (respuesta libre)

Respuesta Intensidad de matmul = `2N³ / 12N² = N/6`, crece linealmente con N. Intensidad de suma elemento a elemento = `N² / 12N² = 1/12`, constante. Así que matmul recompensa SIMD/blocking a N grande (pasa a ser compute-bound); la suma elemento a elemento permanece memory-bound para siempre — aplicar SIMD a ella solo ayuda hasta que el subsistema de memoria se satura.

q-01-05 — NUMA: coste dominante del acceso remoto

  1. El chip de DRAM remoto es físicamente más lento.
  2. La petición debe atravesar el interconnect entre sockets (UPI/QPI), añadiendo latencia y consumiendo ancho de banda compartido.
  3. El sistema operativo marca las páginas remotas como solo lectura por defecto.
  4. La coherencia de cache está desactivada entre sockets.
Respuesta **Opción 2.** El chip de DRAM en sí no es más lento; el coste es el salto por el interconnect. La asignación NUMA-aware (política first-touch, `numactl`) mantiene hilos y datos en el mismo socket.