[Michael Lynch] ha riscontrato una situazione strana. Perché stava compilando ed eseguendo il suo programma quasi 10 volte più veloce piuttosto che eseguire semplicemente il programma da solo? [Michael] si è imbattuto in questo problema durante il benchmarking di un progetto di programmazione, lo ha ridotto ai suoi elementi essenziali per ripetibilità e analisi e ha scoperto che evidenziava un modello mentale errato di come funzionavano le pipeline bash.

Ecco la situazione. La prima cosa che fa il programma ridotto di [Michael] è avviare un timer. Quindi legge semplicemente e conta alcuni byte da stdin, quindi stampa il tempo impiegato perché ciò accadesse. Quando si esegue il programma di test nel modo seguente, occorrono circa 13 microsecondi.

$ echo '00010203040506070809' | xxd -r -p | zig build run -Doptimize=ReleaseFast
bytes: 10
execution time: 13.549µs

Quando si esegue direttamente il programma (già compilato), il tempo di esecuzione aumenta fino a 162 microsecondi.

$ echo '00010203040506070809' | xxd -r -p | ./zig-out/bin/count-bytes
bytes: 10
execution time: 162.195µs

Ancora una volta, l'unica differenza tra zig build run ed ./zig-out/bin/count-bytes è che prima compila il codice, poi lo esegue immediatamente. Il secondo esegue semplicemente il programma compilato.

Come è possibile aggiungere un ulteriore passaggio di compilazione diminuire il tempo di esecuzione? Si scopre che il modello mentale di [Michael] su come funzionano le pipeline bash non era corretto, e fa un ottimo lavoro nel spiegando come funzionano effettivamente e perché ciò ha causato lo strano comportamento stava vedendo.

In breve, i comandi in una pipeline bash non vengono lanciati in sequenza. Vengono tutti avviati contemporaneamente ed eseguiti in parallelo. Ciò significava che, quando eseguito direttamente, il programma contatore di byte di [Michael] veniva avviato immediatamente. Quindi ha aspettato in giro senza fare molto per circa 150 microsecondi mentre il echo '00010203040506070809' | xxd -r -p parte della pipeline è riuscita a fornire i propri dati affinché il programma li leggesse. Da qui deriva il tempo di esecuzione aggiuntivo quando si esegue la versione già compilata.

Allora perché compilarlo prima funziona più velocemente? Stesso motivo di base: quando il zig build run comando inizia, occorre prima un po' di tempo per compilare il programma. Quindi, quando il programma compilato viene effettivamente avviato (e inizia il timer di esecuzione), i dati di input dalla pipeline bash sono già pronti. Pertanto, il programma appena compilato viene eseguito in meno tempo perché non resta ad aspettare che i dati precedenti nella pipeline diventino disponibili.

È uno sguardo interessante su come funzionano effettivamente le pipeline di bash sotto il cofano, e siamo entusiasti del dettaglio che [Micheal] mette nell'intero viaggio e nella spiegazione. Prima o poi, dettagli come questo emergono e fanno alzare le sopracciglia, come l'utente che lo ha scoperto casi limite problematici riguardanti gli spazi nei comandi ssh.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://hackaday.com/2024/03/28/is-your-mental-model-of-bash-pipelines-wrong/