O teste em si, o relatório e o resto do site estão em inglês por enquanto.
Para desenvolvedores
O build está lento. É o código ou a refrigeração?
Compilações e suítes de teste carregam todos os núcleos por minutos e punem a latência de memória. O SystemCheck mede as duas coisas, de forma repetível, para que um build lento seja culpado pela coisa certa.
O que o relatório diz a você
Três números, cada um com sua leitura.
Todos os núcleos, sustentado
ops/s
Um worker por núcleo lógico pela duração da execução. Este é o número que um build paralelo vê, não o boost de núcleo único da caixa.
Latência de memória
ns
A ida e volta até a memória e até o cache. Linkers, gerenciadores de pacotes e qualquer coisa pesada em ponteiros rodam nesta velocidade.
Repetibilidade
%
Rode o estágio de CPU duas vezes e o relatório declara a dispersão. Uma mudança dentro da dispersão não é uma mudança, diga o que disser o cronômetro do build.
O diagnóstico
A forma da curva, lida para o seu caso.
01Sustentada
A máquina não é o problema. Olhe o grafo do build, o cache e o que mais está rodando.
02Um único degrau para baixo
Um limite de potência, na maioria das vezes a potência sustentada de um notebook. Builds longos rodam no nível depois do degrau, não antes.
03Errática
Outra coisa está nos núcleos. Um indexador, um cliente de sincronização, um contêiner que nunca fica ocioso. O número de compartilhamento de núcleos do relatório nomeia a escassez quando consegue vê-la.
Cada classe vem com uma confiança declarada e o piso de ruído da própria medição. Como a forma é lida
Onde um navegador para
O que ele não pode dizer a você.
- Sem clock por núcleo: o navegador vê vazão, não frequência. A curva mostra o efeito de uma mudança de clock sem nomear os megahertz.
- Sem detecção de disputa dentro de uma execução: um programa que divide os núcleos discretamente é indistinguível de uma máquina mais lenta. A comparação antes/depois é o instrumento para isso.
- Contagem de núcleos conforme informada: o Firefox a limita, o Safari a limita em oito, e o relatório diz qual contagem usou.
Qual execução
Padrão, 3 minutos.
Para uma linha de base repetível, a execução padrão, repetida, dá uma dispersão rapidamente. Use a execução profunda uma vez para encontrar o nível estável num notebook.
Os dois tipos são grátis. A escolha fica na tela de configuração.
Perguntas
Feitas com estas palavras.
- Por que meu build é mais lento do que o benchmark sugere?
- Tempos de build refletem vazão sustentada em todos os núcleos e latência de memória, não o boost de núcleo único que a maioria dos benchmarks destaca. O teste informa os dois, e a curva mostra se a máquina mantém seu nível em todos os núcleos pela duração de um build ou dá um degrau para baixo depois da janela de boost.
- Posso usar isso para comparar duas máquinas?
- Sim, nos números medidos: vazão sustentada, queda, largura de banda e latência de memória, tempo de quadro. Rode cada máquina duas vezes para que o relatório possa declarar a dispersão; uma diferença dentro da dispersão é ruído.
- Docker ou uma VM afetam o resultado?
- Qualquer coisa usando os núcleos durante a execução reduz a vazão e aumenta o ruído, e o relatório sinaliza workers em escassez quando consegue vê-los. Feche o que puder antes de uma linha de base, depois rode de novo com a carga habitual para medir o custo dela.