Me deparei com um post discutindo a velocidade de bifurcação no Cygwin, dando uma esperada 'taxa de fork' no Windows XP de cerca de 30-50 por segundo ( link )
Eu tenho um Core 2 duo (1,79 GHz), que eu esperaria obter resultados comparáveis, mas ele só está gerenciando cerca de 8 garfos por segundo (e às vezes muito menos):
$ while (true); do date --utc; done | uniq -c
5 Wed Apr 21 12:38:10 UTC 2010
6 Wed Apr 21 12:38:11 UTC 2010
1 Wed Apr 21 12:38:12 UTC 2010
1 Wed Apr 21 12:38:13 UTC 2010
8 Wed Apr 21 12:38:14 UTC 2010
8 Wed Apr 21 12:38:15 UTC 2010
6 Wed Apr 21 12:38:16 UTC 2010
1 Wed Apr 21 12:38:18 UTC 2010
9 Wed Apr 21 12:38:19 UTC 2010
Você pode sugerir algo que eu possa fazer para acelerar as coisas? Esta máquina funciona muito mais devagar no Cygwin do que outras que usei antes, o que, na verdade, era muito mais lento.
Deixe-me justificar minha pergunta: eu não acredito que ter um fork mais rápido magicamente melhorará minha vida, mas acredito que esse benchmark é um bom proxy para os problemas de desempenho que estou vendo no bash devido ao uso normal de executáveis externos para calcular valores. Acho que obtenho uma aceleração perceptível no Cygwin, passando pelos scripts de inicialização do shell e pela conclusão do bash e tentando substituir os comandos externos pelos internos; no Linux isso não é um problema. Muitas vezes, porém, isso não é possível, e meu PC está atualmente levando ~ 14s para iniciar um shell com cache quente e sem carga.
Isso não tem nada a ver com o fork sendo lento.
Eu vi o cygwin run dog lento quando o diretório "home" do windows estava em uma unidade de rede. Cada comando procuraria binários abrandando as coisas tremendamente.
veja se
while (true); do /bin/date --utc; done | uniq -c
é mais rápido, se assim for, provavelmente é o seu problema
caso contrário, tente executar o bash via strace / ltrace (se eles trabalharem no cygwin) e veja o que está fazendo quando leva 1 segundo para executar a data.
Você não está vendo garfos; Você está vendo fork, exec, system call para ler a hora do relógio, formatar e converter a saída. Sem mencionar o que mais é tempo compartilhado em paralelo.
Em que base você diz que as outras máquinas "na verdade eram mais lentas"? Há muitas coisas que contribuem para a velocidade real do computador e para a percepção que o usuário tem da velocidade do computador. Que tipo de coisas você está fazendo onde forks / seg é uma boa medida de desempenho? Qual a velocidade de memória, arquitetura e quantidade? Velocidade de E / S de disco e buffer?
Qual você acha que fará mais forks / seg: um Core i7 rodando o Vista com 512MB de RAM ou um Celeron rodando um mínimo de Linux com 2GB?
Temo que não há muito o que fazer sobre isso.
O Windows não possui uma fork() syscall nativa, então o Cygwin deve emular isso. A implementação dessa emulação é muito ineficiente. (Veja Perguntas freqüentes sobre o Cygwin )
O MSYS2, que é frequentemente usado em aplicações onde se quer um ambiente de linha de comando do Linux parecido com o do Windows, é baseado no Cygwin, e é por isso que ele também é afetado por isso.
Na verdade, é tão ruim que um fork() no Windows é pelo menos uma ordem de magnitude mais lenta que no Linux
msys2bash-windows-box$ time { date; }
Sa, 24. Feb 2018 16:51:44
real 0m0,046s
user 0m0,000s
sys 0m0,000s
msys2bash-windows-box$ while (true); do /bin/date --utc; done | uniq -c
13 Sa, 24. Feb 2018 15:57:18
17 Sa, 24. Feb 2018 15:57:19
16 Sa, 24. Feb 2018 15:57:20
bash-linux-box$ time { date; }
Sat Feb 24 15:51:54 UTC 2018
real 0m0.002s
user 0m0.000s
sys 0m0.000s
bash-linux-box$ while (true); do date --utc; done | uniq -c
211 Sat Feb 24 15:56:35 UTC 2018
286 Sat Feb 24 15:56:36 UTC 2018
260 Sat Feb 24 15:56:37 UTC 2018
O exemplo acima mostra a diferença entre uma caixa i5-2500k @ 4GHz, 32GiB RAM do Windows 10 Pro em comparação com um débil one-core, 1GiB RAM VPS