Assembly Hall of Shame
Um projeto open source que cataloga as instruções x86 mais lentas destaca como certos padrões — como acessos MMIO e operações de ponto flutuante subnormais — podem travar CPUs modernas por milissegundos ou até segundos. Os comentaristas conectam isso a preocupações mais amplas com desempenho de software e latência, observando como camadas de abstração, pipelines de entrada do SO e taxas de atualização do monitor podem fazer máquinas de hoje parecerem menos responsivas do que hardware muito mais antigo, apesar de um throughput enormemente maior. O trabalho é visto tanto como uma exploração divertida do comportamento da CPU quanto como um recurso prático para entender armadilhas de desempenho e até possíveis implicações de segurança, como abusar de instruções de longa duração para interferir em system management interrupts.
Projeto e ferramentas relacionadas
- Repositório visto como um catálogo divertido, mas sério, de instruções e padrões patológicos de x86.
- Ligado a um corpo de trabalho mais amplo: brute force do espaço de opcode para instruções não documentadas, compiladores “mov-only”, arte em fluxo de controle na desmontagem, ferramentas de visualização binária e demos que quebram SMI.
- Alguns perguntam se ele descobre armadilhas práticas ou se é principalmente por diversão; outros apontam motivações explícitas de segurança e confiabilidade.
Instruções lentas, MMIO e arquitetura
- Muitas das sequências de pior caso dependem de operações de ponto flutuante subnormais e interações com MMIO, especialmente via PCIe e portas de E/S ACPI.
- Um destaque é
fxrstor64em MMIO, aparentemente capaz de travar o caminho PCIe por dezenas de segundos; a discussão observa a falta de garantias de progresso. - Alguns acham que truques baseados em MMIO são “trapacear” e preferem resultados restritos à memória principal; uops.info é mencionado para timings de instruções mais “puros”.
Latência, throughput e UX
- Debate sobre quantas instruções cabem em 1 ms e por que sistemas modernos ainda parecem lentos.
- Limiares clássicos de tempo de resposta (0,1 s “instantâneo”, 1 s fluxo, 10 s atenção) são citados, mas אחרים observam que humanos conseguem detectar diferenças muito menores (dezenas de ms ou menos, dependendo do contexto).
- Detalhes do pipeline de entrada (polling USB, refresh do monitor, camadas do SO) são discutidos; sistemas mais antigos às vezes têm latência de entrada até exibição bem menor do que stacks modernos.
- É enfatizada a distinção entre otimizações de throughput (loteamento) e latência, com projetos modernos frequentemente favorecendo o primeiro.
Bloat de software e regressões
- São invocadas leis sobre software inchando para consumir os ganhos de hardware.
- Reclamações sobre o Notepad/MSPaint modernos alterando comportamentos há muito estabelecidos e quebrando a memória muscular; alguns usuários evitam versões mais novas do Windows por esse motivo.
Semântica de NOP e pedantismo microarquitetural
- Vai-e-vem prolongado sobre se
nop“não faz nada” versus “incrementa o ponteiro de instrução”, e como isso interage com a decodificação e a implementação microarquitetural. - A discussão toca em codificações legadas (
XCHG AX,AX), NOPs reservados e detalhes do tratamento especulativo de RIP.
Instruções de timing e peculiaridades de medição
- É discutido o overhead de
rdtsc; um comentarista observa ~25 ciclos em certas microarquiteturas, enquanto o custo maior relatado no repositório provavelmente reflete muitas chamadas derdtscem voo interferindo umas com as outras. - Os papéis de
rdtsc/rdtscpcomo barreiras de timing e instruções de ordenação são brevemente contrastados.
Truques de baixo nível e casos extremos
- Ideias levantadas sobre usar misses de TLB, scatter/gather e até comportamento de tabela de páginas / MMU para criar operações arbitrariamente longas ou em loop.
- PCIe descrito como uma rede de pacotes; latências extremas via bridges exóticos são observadas como teoricamente possíveis.