Posso acelerar o garfo da cygwin?

15

Me deparei com um post discutindo a velocidade de bifurcação no Cygwin, fornecendo uma 'taxa de garfo' esperada no Windows XP em torno de 30 a 50 por segundo ( link )

Eu tenho um Core 2 duo (1.79GHz) que eu esperaria obter resultados comparáveis, mas ele gerencia apenas 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 age muito mais devagar no Cygwin do que outras que eu usei antes, e na verdade eram muito mais lentas.

Atualizar

Deixe-me justificar minha pergunta: não acredito que ter uma bifurcação mais rápida melhore minha vida magicamente, 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. Percebo que percebo uma velocidade notável no Cygwin examinando meus scripts de inicialização do shell e completando o bash e tentando substituir comandos externos por internos; no Linux, isso não é um problema. Muitas vezes, porém, isso não é possível, e meu PC está atualmente com ~ 14s para iniciar um shell com um cache quente e sem carga.

speed cygwin

— Andrew Aylett
fonte

1

Cygwin será sempre lento, mais lento. Mesmo o VirtualBox / VMWare daria um desempenho mais rápido ou, se você precisar de um ambiente de desenvolvimento, use msys. Mas isso ... não sei ... nunca achei o cygwin realmente utilizável.

— Shiki

+1 para o bom e simples benchmark de garfo! Apenas executei isso em um VPS Linux de 5 $ / mês para comparar com o meu laptop Windows i7, e o VPS obteve uma pontuação 30x maior.

— Mark K Cowan

2

Isso não tem nada a ver com o garfo ser lento.

Eu vi o cygwin rodar devagar quando o diretório "home" do Windows estava em uma unidade de rede. Cada comando procuraria ali binários que atrasavam tremendamente as coisas.

Veja se

while (true); do /bin/date --utc; done | uniq -c

é mais rápido; nesse caso, esse provavelmente é o seu problema

caso contrário, tente executar o bash via strace / ltrace (se eles funcionam no cygwin) e veja o que está fazendo quando leva 1 segundo para executar a data.

— user23307
fonte

1

Infelizmente, a codificação dos caminhos não faz diferença significativa. strace funciona em Cygwin, mas nada me salta quando olho para o traço.

— Andrew Aylett

1

Receio que não haja muito que você possa fazer sobre isso.

O Windows não possui um fork()syscall nativo, portanto, o Cygwin precisa emular isso. A implementação desta emulação é muito ineficiente. (Consulte as Perguntas frequentes sobre o Cygwin )

O MSYS2, que geralmente é usado em aplicativos em que se deseja um ambiente de linha de comando semelhante ao Linux, com todas as funcionalidades do Windows, é baseado no Cygwin, e é por isso que também é afetado por isso.

Na verdade, é tão ruim que um fork()no Windows seja pelo menos uma ordem de magnitude mais lento 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 do Windows 10 Pro de i5-2500k @ 4GHz e 32GiB de RAM e uma VPS de 1GiB de RAM de um núcleo e fraca

— luxifer
fonte

0

Você não está vendo garfos; você está vendo fork, exec, chamada do sistema para ler a hora do dia, formatar e converter a saída. Sem mencionar o que mais é o tempo compartilhado em paralelo.

Em que base você diz que as outras máquinas " eram realmente mais lentas"? Há muitas coisas que contribuem para a velocidade real de um computador e para a percepção do usuário sobre a velocidade do computador. Que tipo de coisa você está fazendo, onde garfos / s é uma boa medida de desempenho? Qual é a velocidade, arquitetura e quantidade de memória? Velocidade de E / S do disco e buffer?

O que você acha que fará mais forks / s: um Core i7 executando o Vista com 512 MB de RAM ou um Celeron executando um Linux mínimo com 2 GB?

— mpez0
fonte

@ mpez0: Por favor, veja minha justificativa atualizada. Para responder às suas perguntas especificamente, minha base para dizer que elas eram mais lentas é que elas eram de uma arquitetura mais antiga, com uma velocidade de clock mais lenta, menos (e mais lenta) RAM e um disco mais antigo e mais lento, mas ainda XP. O Linux quase sempre será mais rápido na bifurcação, porque usa um modelo de bifurcação no kernel onde o Windows não. Eu tenho um P3 que pontua ~ 60 nesse benchmark :).

— Andrew Aylett