GCShape Stenciling: El equilibrio entre binario y rendimiento

Cuando utilizas genéricos, es probable que asumas que el compilador realiza una monomorfización completa, como ocurre en C++ o Rust, donde cada tipo recibe su propia implementación optimizada y única. En Go, la realidad es más pragmática: el compilador utiliza GCShape stenciling. Esto consiste en agrupar tipos que comparten el mismo GC shape —es decir, tipos que tienen la misma representación para el Garbage Collector— para compartir el mismo código máquina. Esta técnica es lo que permite que Go mantenga binarios razonables en tamaño y un uso eficiente de la caché de instrucciones, evitando la explosión de código que genera la monomorfización pura.

En la práctica, esto significa que todos los tipos puntero comparten una única implementación de una función genérica, ya que para el GC, todos son simplemente una palabra que puede o no ser una dirección de memoria válida. Si intentas usar genéricos en un hot path extremadamente sensible a la latencia, podrías notar que la necesidad de consultar un dictionary (un objeto que el runtime usa para resolver operaciones específicas como la comparación o la copia de tipos) introduce una ligera sobrecarga en comparación con una función con un tipo concreto. Sin embargo, para la gran mayoría de los casos de uso en microservicios y herramientas CLI, el beneficio de la seguridad de tipos y la reducción del tamaño del binario compensa este costo marginal.

package main

import (
	"fmt"
)

// Container es un contenedor genérico para cualquier tipo.
type Container[T any] struct {
	value T
}

// Contains implementa una búsqueda en un slice genérico.
// Al usar 'comparable', el compilador sabe que puede realizar comparaciones.
func Contains[T comparable](slice []T, target T) bool {
	for _, item := range slice {
		// Para tipos con el mismo GC shape (como distintos tipos puntero),
		// el compilador no genera código nuevo para cada uno. 
		// En su lugar, usa un 'dictionary' para saber cómo comparar 'item' con 'target'.
		if item == target {
			return true
		}
	}
	return false
}

type User struct{ ID int }
type Product struct{ ID int }

func main() {
	// Caso 1: Tipos escalares (integers). 
	// Probablemente tengan su propio stencil o compartan uno con otros enteros.
	nums := []int{10, 20, 30, 40}
	fmt.Println("Contiene 30:", Contains(nums, 30))

	// Caso 2: Tipos puntero.
	// 'u1' y 'p1' tienen tipos distintos (*User y *Product), 
	// pero comparten el mismo GC shape (son punteros).
	// El código de 'Contains' ejecutado para ambos es exactamente el mismo binario.
	u1, u2 := &User{ID: 1}, &User{ID: 2}
	p1, p2 := &Product{ID: 1}, &Product{ID: 2}

	users := []*User{u1, u2}
	products := []*Product{p1, p2}

	fmt.Println("Contiene u1:", Contains(users, u1))
	fmt.Println("Contiene p1:", Contains(products, p1))

	// Caso 3: Comparación de estructuras (no punteros).
	// El compilador genera un stencil específico para la estructura si es lo suficientemente 
	// compleja, o utiliza el diccionario si la forma es compatible.
	fmt.Println("Contiene u2:", Contains(users, u2))
	fmt.Println("Contiene p2:", Contains(products, p2))
}

Análisis del comportamiento

En el ejemplo anterior, observa cómo Contains se utiliza con []int, []*User y []*Product. Si Go utilizara monomorfización total, el binario contendría tres copias distintas de la lógica de Contains.

Sin embargo, debido al GCShape stenciling, sucede lo siguiente:

1. Para []int, el compilador genera una implementación optimizada para enteros.
2. Para []*User y []*Product, el compilador nota que ambos son punteros. Para el GC, un *User y un *Product son idénticos: son palabras de memoria que pueden apuntar a un objeto en el heap. Por tanto, comparte el mismo código máquina.
3. Para que esa implementación compartida sepa si *User == *User (comparando la dirección) o si debe hacer algo más complejo, el runtime utiliza el dictionary. Cuando llamas a Contains(users, u1), el compilador pasa implícitamente un puntero a una tabla de funciones que le dice a la implementación genérica: “Oye, para este tipo específico, la operación de comparación == es simplemente comparar los bits de la dirección de memoria”.

Este mecanismo es lo que permite que el uso de genéricos en Go sea mucho más “barato” en términos de memoria que en C++, pero no es “gratis” en términos de ciclos de CPU en casos de máxima optimización.

El error frecuente

Un error común de rendimiento es migrar una función crítica de un tipo concreto a una función genérica pensando que la abstracción es gratuita.

// Versión concreta (Rápida: el compilador sabe exactamente qué comparar)
func FindInt(slice []int, target int) int {
	for i := range slice {
		if slice[i] == target { return i }
	}
	return -1
}

// Versión genérica (Ligeramente más lenta: requiere consulta al diccionario)
func FindGeneric[T comparable](slice []T, target T) int {
	for i := range slice {
		if slice[i] == target { return i }
	}
	return -1
}

Si FindGeneric se llama dentro de un bucle que se ejecuta miles de millones de veces en un hot path, la indirección para resolver la comparación mediante el diccionario puede degradar el rendimiento. En micro-optimizaciones extremas, la monomorfización (aunque sea costosa en binario) siempre ganará a la compartición de código por GCShape.

N° 87