Perché il ruby è molto più lento su Windows?

Quali sono le specifiche cause tecniche del fatto che Ruby sia molto più lento su Windows? La gente parla di un calo di velocità 3X da Linux / OSX e ci sono alcune discussioni vaghe su Ruby che utilizza un compilatore per le versioni di Windows che produce codice lento ma non riesco a trovare dettagli specifici.

Qualcuno conosce le specifiche? Non sono interessato a hurf durf Windoze fa schifo.

Direi che ci sono alcune opzioni possibili e probabilmente tutte sumno:

  1. Ruby essendo sviluppato principalmente su Linux, finisce per ottimizzarlo meccanicamente. Il codice viene regolarmente testato per Windows e tutto funziona, ma il risultato è che lo sviluppatore dedicherà più tempo all’ottimizzazione per Linux che Windows.
  2. Secondo la mia esperienza, le versioni recenti di gcc (4.3 e versioni successive) producono codice più efficiente rispetto alle versioni recenti di Visual Studio (almeno nel 2005). I miei test hanno incluso in entrambi i casi spendere circa un giorno per trovare le migliori opzioni per l’ottimizzazione del codice.
  3. In relazione al punto 1, se si compila lo stesso progetto utilizzando gcc per Windows o Linux, di solito osservo un calo delle prestazioni di circa il 20% su Windows rispetto a Linux. Anche in questo caso, suppongo sia perché Linux (o Unices in generale) è un objective primario per gcc, windows è una porta. Meno tempo è dedicato all’ottimizzazione per Windows rispetto a Linux.

Alla fine, se si volesse ottimizzare Ruby per Windows, una notevole quantità di tempo (e il denaro, per quanto ne so, i profiler di Windows non vengono gratis) dovrà essere speso usando un profiler e ottimizzando i colli di bottiglia . E tutto dovrà essere testato su Linux per assicurarsi che non ci sia alcuna perdita di prestazioni.

Certo, tutto dovrebbe essere testato di nuovo con il loro nuovo interprete YARV .

Non ho lavorato molto con il codice sorgente dell’interprete YARV, quindi i commenti seguenti riguardano solo l’interprete MIR 1.8.6.

Nel tentativo di scrivere un’estensione C per Ruby in Visual Studio, ho scoperto con mio orrore che i binari di Windows scaricati di Ruby 1.8.6 sono stati compilati usando Visual C ++ 6.0, che è stato rilasciato poco dopo la fine della Seconda Guerra Mondiale . Da allora i compilatori (e i processori che hanno scelto come target) sono avanzati considerevolmente. Mentre i build di Linux ottengono l’ultima bontà gcc, il build di Windows si affianca alla tecnologia del compilatore del secolo scorso. Questa è una delle ragioni. (Disclaimer: presumibilmente 1.9 deve essere costruito con mingw, di cui non sono un fan, ma che deve anche essere migliore di VC6)

Senza sapere quali operazioni in particolare si trovano più lente su Windows è difficile commentare ulteriormente, ma noterò che ho trovato che l’implementazione I / O su Ruby è notevolmente meno performante con I / O di rete e file locali. Non ho mai approfondito l’implementazione delle primitive di I / O abbastanza per capire perché, ma presumo che le implementazioni presuppongano che i costrutti IO veloci su Linux siano i costrutti IO veloci su Windows, che quasi sempre non è il caso.

All’inizio è necessario fare una distinzione tra il vecchio interprete MRI (versioni fino a 1.8) e il più recente YARV , che è l’interprete ufficiale di Ruby 1.9. Ci sono grandi miglioramenti delle prestazioni e un design diverso in Ruby 1.9, quindi è necessario conoscere la versione di cui si sta parlando. Sto indovinando che quello che hai letto si riferisce alla versione 1.8.x, che è l’unica che ha un programma di installazione one-click finora.

Inoltre, sarebbe bene sapere se stai parlando delle prestazioni di Ruby on Rails o di Ruby in generale. So che ci dovrebbe essere una chiara distinzione tra questi due, ma poiché Ruby on Rails è l’uso principale di Ruby, le persone parlano spesso delle sue prestazioni come se stessero parlando delle prestazioni di Ruby.

Per quanto riguarda il compilatore, Ruby può essere compilato utilizzando qualsiasi versione recente di Visual Studio, che va benissimo. Immagino che se esiste una tale differenza di prestazioni, si dovrebbe guardare all’implementazione dell’interprete e vedere se c’è qualcosa che farebbe la differenza tra un POSIX e un sistema Windows.

Non completamente alla tua domanda, ma c’è stata una grande discussione sul podcast Deep Fried Bytes che ha trattato la stessa domanda nel contesto IronPython. Capisco che la tua domanda riguardi Ruby, ma potrebbero esserci problemi correlati che riguardano anche Ruby.

Inoltre, la discussione fa un buon lavoro guardando un po ‘più a fondo di “Windows fa schifo”, quindi vale la pena di provarlo.

L’urto delle prestazioni non è del 300%, in generale, invece, è più vicino al 50% -100%. La spiegazione di Casual Jim è una delle ragioni per cui gli script di elaborazione dei dati sono più lenti su Windows rispetto alle varianti di Unix e Linux.

Nel caso più generale, l’unica cosa che posso pensare è che lo sviluppo di Ruby è centrato su Linux, il che ha portato a molti Unix-ism nel modo in cui è stato creato Ruby. Inoltre, poiché la maggior parte degli sviluppatori attivi non sono utenti di Windows, nel team è presente pochissima esperienza nell’ottimizzazione di Windows e la maggior parte delle decisioni relative all’ottimizzazione delle prestazioni si concentrano sul rendere le cose più veloci sui sistemi Unix.

Un esempio specifico di questo è che Ruby usa il parametro passing-write, che, secondo quanto ho letto, non può essere fatto correttamente su Windows, causando un sacco di overhead nelle chiamate di metodo.

Non riesco a capire, però, cosa ha fatto Casual Jim per meritare il voto -8.

La compressione automatica dei file ntfs su Windows stava rallentando tutto per me. inizia a funzionare automaticamente quando hai poco spazio su hd … e poi ha bisogno di decomprimere e ricomprimere i file al volo, mentre li accedi, sprecando cicli di CPU ..

Esegui il seguente comando per decomprimere un’intera unità ntfs dalla sua radice (ad esempio “C: \”) e vedere se ci sono delle differenze, per me ha fatto un’enorme differenza e ha ottenuto il ritorno di ruby ​​/ rails a quello a cui ero abituato prima !

il comando è:

compact /u /s /i