Processor and graphics card specifications are live

El test en sí, el informe y el resto del sitio están en inglés por ahora.

Para desarrolladores

El build es lento. ¿Es el código o la refrigeración?

Las compilaciones y las suites de tests cargan todos los núcleos durante minutos y castigan la latencia de memoria. SystemCheck mide las dos, de forma repetible, para que un build lento se le achaque a lo correcto.

Ejecutar el testCómo medimosGratis · sin instalar · prueba estándar, 3 min

Lo que te dice el informe

Tres cifras, cada una con su lectura.

Todos los núcleos, sostenido

ops/s

Un worker por núcleo lógico durante toda la prueba. Esta es la cifra que ve un build en paralelo, no el boost de un solo núcleo de la caja.

Latencia de memoria

ns

El viaje de ida y vuelta a memoria y a caché. Los enlazadores, los gestores de paquetes y todo lo que abusa de punteros corren a esta velocidad.

Repetibilidad

%

Ejecuta la etapa de CPU dos veces y el informe declara la dispersión. Un cambio dentro de la dispersión no es un cambio, diga lo que diga el cronómetro del build.

El diagnóstico

La forma de la curva, leída para tu caso.

  1. 01Se mantiene

    La máquina no es el problema. Mira el grafo del build, la caché y qué más se está ejecutando.

  2. 02Un único escalón hacia abajo

    Un límite de potencia, casi siempre el vataje sostenido de un portátil. Los builds largos corren al nivel de después del escalón, no al de antes.

  3. 03Errática

    Hay algo más en los núcleos. Un indexador, un cliente de sincronización, un contenedor que nunca queda inactivo. La cifra de reparto de núcleos del informe nombra la inanición cuando puede verla.

Cada clase viene con una confianza declarada y el propio suelo de ruido de la medición. Cómo se lee la forma

Dónde se detiene un navegador

Lo que no puede decirte.

  • Sin relojes por núcleo: el navegador ve rendimiento, no frecuencia. La curva muestra el efecto de un cambio de reloj sin nombrar los megahercios.
  • Sin detección de contención dentro de una prueba: un programa que comparte los núcleos en silencio es indistinguible de una máquina más lenta. La comparación antes/después es el instrumento para eso.
  • El número de núcleos tal como se informa: Firefox lo limita, Safari lo limita a ocho, y el informe dice qué cifra usó.

Qué prueba elegir

Estándar, 3 minutos.

Para una línea base repetible, la prueba estándar, repetida, da una dispersión rápidamente. Usa la prueba profunda una vez para encontrar el nivel estabilizado en un portátil.

Las dos son gratis. Se elige en la pantalla de configuración.

Preguntas

Tal como se preguntan.

¿Por qué mi build es más lento de lo que sugiere el benchmark?
Los tiempos de build reflejan el rendimiento sostenido con todos los núcleos y la latencia de memoria, no el boost de un solo núcleo que la mayoría de benchmarks destacan. El test informa las dos cosas, y la curva muestra si la máquina mantiene su nivel con todos los núcleos durante lo que dura un build o si baja un escalón tras la ventana de boost.
¿Puedo usar esto para comparar dos máquinas?
Sí, sobre las cifras medidas: rendimiento sostenido, decaimiento, ancho de banda y latencia de memoria, tiempo por fotograma. Ejecuta cada máquina dos veces para que el informe pueda declarar la dispersión; una diferencia dentro de la dispersión es ruido.
¿Afectan Docker o una VM al resultado?
Cualquier cosa que use los núcleos durante la prueba baja el rendimiento y sube el ruido, y el informe marca los workers en inanición cuando puede verlo. Cierra lo que puedas antes de una línea base, y luego ejecuta otra vez con la carga habitual para medir su coste.

Descubre por qué. 3 minutos, en la pestaña que ya tienes abierta.