Andriy Makukha's questions

Atualizar

Eles não! Pelo menos, não para mim.

Veja minha resposta.

Pergunta original

De acordo com os benchmarks Phoronix do ano passado , os aplicativos no FreeBSD rodam mais lentamente do que no Debian (incluindo o mecanismo de xadrez Stockfish, Node.js, codificação FLAC e outras tarefas computacionais).

O próprio artigo do Phoronix atribui algumas das diferenças de desempenho ao uso do Clang em vez do compilador GCC. Algumas outras opiniões dizem que o uso do ZFS torna o FreeBSD mais lento, pois o ZFS é inerentemente mais lento que o ext4.

Mas mesmo tarefas puramente computacionais no FreeBSD compiladas com o GCC8 eram mais lentas do que no Linux.

Qual é a causa disso? É inerente às diferenças entre os kernels do FreeBSD e do Linux, pode ser causado pela pior qualidade dos drivers ou há algum outro motivo?

PS Para torná-lo mais específico, aqui está um programa puramente computacional bastante simples que roda mais devagar no FreeBSD do que no Linux de acordo com o Phoronix: m-queens 1.2 . Compilado assim:

gcc -o m-queens.bin main.c -O2 -march=native -mtune=native -std=c99 -fopenmp

Como essa é uma tarefa multithread que foi executada em duas CPUs de 20 núcleos, suspeito que a diferença de desempenho se resume a quão bem o sistema operacional lida com vários threads.

PPS Para deixar mais claro, estou ciente de que o FreeBSD possui bons recursos de rede e que é usado pela Netflix . A questão é especificamente sobre tarefas computacionais, como a acima.

PPPS Depois de instalar o FreeBSD (TrueOS) no meu desktop de 6 núcleos junto com o Ubuntu e tentar executar o benchmark do queens, não notei nenhuma diferença significativa no desempenho multithread. Embora o Phoronix afirme que funcionou 39% mais lento no FreeBSD, em meus testes foi apenas 3,7% mais lento, o que pode ser atribuído a uma pequena diferença na versão do compilador (gcc 7.4 no TrueOS, gcc 7.2 no Ubuntu). Vou testar mais depois.

odO comando (octal dump) é implementado no Unix desde a versão 1. No entanto, não consegui encontrar um comando reverso no manual do Unix da versão 6 (1975). Maneiras modernas de reverter odcom xxdou sednão se aplicam ao Unix V6, uma vez que sede awkapareceu apenas na versão 7 (enquanto uudecode, xxde base64não estão disponíveis também).

As perguntas são:

• Como as pessoas em 1975 converteram listagens octais ou hexadecimais em arquivos binários?
• Como posso fazer isso em um emulador PDP-11 que só me permite colar texto no terminal da área de transferência? (Em outras palavras, é necessário escrever meu próprio programa para isso?)

Aqui está um exemplo de despejo hexadecimal de um arquivo binário odque eu gostaria de converter de volta em binário:

# od -h /bin/sum
0000000 0107 00ba 0000 0204 0000 0000 0000 0001
0000020 1583 0bd6 0ac3 0601 8901 0a37 00ae 15b7
0000040 0002 8905 0000 0000 8609 15c0 0001 8904
0000060 0026 0005 01ef 706f 6472 000a 1001 0a05
0000100 1040 8903 00be 0200 870b 0bc0 030e 0ab7
0000120 007a 15c2 00be 9484 6105 0b45 7e04 01f0
0000140 15c0 0001 8904 0080 0002 09f7 0026 15c0
0000160 0001 8904 0083 0001 1dc5 0050 09f7 0014
0000200 15c0 0001 8904 0082 0001 1040 8906 01c2
0000220 203f 200a 1026 1066 1141 09f7 0006 1581
0000240 1580 0087 0a00 7217 000a 1066 1001 0302
0000260 09f7 fff0 15b7 0012 65f7 0030 000c 15c0
0000300 0001 8904 00ba 0001 0087
0000312 

As primeiras versões do Unix incluíam a ferramenta de Doug McIlroy tmg("transmogrifier"), um dos primeiros compiladores-compiladores. O TMG foi implementado na linguagem assembly de Dennis Ritchie, bem como no próprio TMGL (a linguagem que o TMG traduz em assembly). Aqui está o manual do TMG (1972). Aqui está o código fonte completo da versão 6 Unix.

Como estou tentando entender como funcionava a implementação do TMG por McIlroy, estou lendo o arquivo tmgl.s, uma tradução de tmgl.tfeita pelo TMG. E estou perplexo com os seguintes trechos:

.1=.
1
.2=.
2
.3=.

E:

goto;..2
..3:null
..2:

Li os manuais do PAL-11R e do Unix Assembly , mas não me lembro de uma explicação.

Particularmente:

• .significa "contador de localização", mas o que é .3=.?
• ..significa "contador de realocação", mas o que é ..3?

(Para piorar as coisas, esse tipo de sintaxe parece ser encontrado apenas na implementação do TMG, não em qualquer outro arquivo de origem do Unix V6. E, para excluir a possibilidade de um código corrompido ou sintaxe descontinuada, as fontes do TMG compilam em um Python Emulador PDP-11 rodando Unix V6.)

Não consigo descobrir qual algoritmo foi usado no Unix V5 e V6 para o sumcomando.

A princípio, pensei que fosse uma simples soma de bytes módulo 2^16. No entanto, para uma string "1111111111\n" repetida 320 vezes, ela calcula uma soma de verificação de 28930 (usando o emulador PDP-11 de Julius Schmidt para JavaScript). Considerando que uma simples soma de bytes para ele é dois bytes menor:

$ python -c 'print(sum(bytearray(b"1111111111\n"*320)) & 0xFFFF)'
28928

Mais tarde, nas páginas man do MacOS , descobri que os comandos sume cksumtinham um longo histórico de inconsistências. No entanto, mesmo as versões "históricas" do algoritmo fornecidas no MacOS não concordam com a soma de verificação do Unix V5. A correspondência mais próxima é o comando padrão sumdo UNIX System V (invocado no Mac como cksum -o 2), que retorna a mesma soma de verificação para esta string, mas discorda para outras:

$ python -c 'print("1111111111\n"*320, end="")' | cksum -o 2
28930 7

Para ser mais específico, o cksum -o 2e o Unix V5 sumproduzem saídas diferentes para a maioria dos arquivos binários no emulador (por exemplo, na pasta /bin), embora concordem na maioria dos arquivos de texto.

Este é um comportamento genuíno ou um bug no emulador? Se for genuíno, qual é o algoritmo?

PS Aqui está o código fonte , se alguém puder ler o código assembly de 1974.