Le prestazioni più lente dei linguaggi di programmazione sono davvero una cosa negativa? [chiuso]

Ecco come lo vedo.

C'è un codice macchina ed è tutto ciò di cui i computer hanno bisogno per eseguire qualcosa. Ai computer non interessano i linguaggi di programmazione. Non importa se il codice macchina proviene da Perl, Python o PHP. I linguaggi di programmazione non servono i computer. Servono i programmatori.

Alcuni linguaggi di programmazione funzionano più lentamente di altri, ma ciò non è necessariamente dovuto a qualcosa di sbagliato in essi. In molti casi, è perché fanno più cose che altrimenti i programmatori dovrebbero fare (ad esempio la gestione della memoria) e facendo queste cose, sono meglio in ciò che dovrebbero fare: servire i programmatori.

Quindi, le prestazioni più lente, dei linguaggi di programmazione, sono davvero una cosa negativa?

Non penso che sia automaticamente male. Python è più lento di C ++, ma quando entrambi sono abbastanza veloci , Python potrebbe essere la scelta migliore per il problema attuale anche se è più lento .

È sempre un compromesso. Per piccole attività una tantum, è molto più veloce scrivere uno script Python rispetto a un'app C ++ che fa lo stesso (l'esempio tipico per me sarebbe una sorta di elaborazione di testo batch o camminare su un albero di directory e fare qualcosa sui file), e non mi interessa davvero se ci vogliono 10 ms o 1000 ms, anche se è 100 volte più lento, perché potrebbe richiedere la metà del tempo per scrivere e testare.

Certo, sarebbe bello se Python fosse veloce come C ++, quindi in questo senso concordo con la tua affermazione che "slow = bad". Ma poi ho piuttosto un linguaggio potente che corre più veloce che voglio non facendo alcune cose (diciamo, i limiti dell'array controllano gli array grezzi) fintanto che mi permette di decidere quando fare quel compromesso (diciamo, usando std: :vettore).

Abbastanza semplice: essere lenti è una brutta cosa

quando il programma richiede un certo livello di prestazioni

perché senza quella prestazione non si soddisfano i requisiti.

Potrebbe trattarsi di qualsiasi cosa, da un'applicazione aziendale che deve elaborare query in un periodo di tempo accettabile, fino a un gioco che deve visualizzare molte informazioni sullo schermo in qualsiasi momento. Se il programma non è abbastanza veloce, allora non funziona .

Guardalo in questo modo: i computer sono stupidi . Seguono faticosamente le istruzioni che qualsiasi idiota con un tavolo da gioco potrebbe seguire. Insistono ostinatamente nel fare quello che hai detto invece di quello che volevi dire. Non un briciolo di auto-direzione o intuizione. È orribile.

L'unica cosa che fa un computer è che è veloce. Veramente! Una testa di pugno con un casellario potrebbe fare lo stesso lavoro di un database. Qualcuno che fa girare una macchina da stampa potrebbe fare quello che fa Apache. Sul serio! E DID, per centinaia e centinaia di anni, è un dato di fatto. Perché un computer è buono per TUTTO è la sua velocità.

Quindi un linguaggio di programmazione che (rispetto ad altri linguaggi) non riesce a sfruttare a cui manca l'UNICO vantaggio dell'utilizzo dei computer.

Un linguaggio di programmazione può essere di altissimo livello, "fare molto", essere comunque molto veloce. OCaml è un linguaggio di livello superiore rispetto a PHP, ma sta producendo un codice quasi altrettanto veloce di C. Javascript è dinamico come PHP, ma può essere eseguito molto velocemente. Quindi, è principalmente un problema con un'implementazione del linguaggio, non un progetto. I linguaggi dinamici sono più difficili da implementare in modo efficiente, ma non impossibile.

La velocità può essere misurata in termini di tempo di esecuzione, tempo di sviluppo iniziale e tempo di manutenzione (tempo impiegato per risolvere problemi / bug e produrre nuovo codice e distribuirlo).

I linguaggi di scripting hanno generalmente tempi di esecuzione più lenti ma tempi di manutenzione più rapidi perché spesso è possibile apportare modifiche e distribuzioni rapide senza dover ricostruire un intero sistema e talvolta senza nemmeno dover arrestare e riavviare.

Quindi molto è un equilibrio a seconda della velocità richiesta.

Anche il contesto è importante. Caricare la configurazione iniziale in 0,5 secondi anziché 0,1 secondi non è un grosso problema, ma in fase di esecuzione, impiegare 0,5 secondi per eseguire una query anziché 0,1 secondi potrebbe essere un grosso problema se deve gestire 100 query, impiegando quindi 50 secondi anziché 10.

Semplice: i clienti adorano il software veloce. In effetti, lo scopo dei computer è calcolare rapidamente.

Lento è relativo. Se ho l'obbligo di leggere una porta 10 volte al secondo, una lingua che non è in grado di creare un binario in grado di farlo è troppo lenta. Se otoh sto scrivendo un'applicazione web in cui la sequenza richiesta / risposta tra server e browser / client viene misurata in pochi secondi e è probabile che l'utente passi minuti su uno schermo prima di fare clic su un pulsante, un linguaggio di programmazione in grado di gestire l'elaborazione della richiesta in 1 secondo è probabilmente abbastanza veloce (la maggior parte ovviamente è molto più veloce).

Naturalmente il linguaggio di programmazione potrebbe essere un fattore nel determinare la velocità di esecuzione, ma questo non sarà il linguaggio stesso ma i compilatori e / o i tempi di esecuzione che ne derivano. Ciò è evidente visto lo sviluppo di Java, dove le prestazioni delle JVM (anche su ambienti hardware identici) sono aumentate radicalmente nel corso degli anni. E ovviamente è sempre possibile scrivere codice terribilmente lento in qualsiasi ambiente tu scelga. Dato che affermazioni come "C ++ è dieci volte più veloce di Java" sono automaticamente fasulle a meno che non siano qualificate e quantificate esattamente su quali condizioni sono state testate e come. È ugualmente possibile creare un test in cui Java è più veloce di C ++, tutto dipende da cosa stai usando come codice di test e da come lo esegui.

Poiché i linguaggi di programmazione non esistono per servire i programmatori, esistono per creare programmi per servire gli utenti.

Se hai solo bisogno di un semplice piccolo strumento personale per fare qualcosa una volta, può essere lento quanto vuoi. Ma una volta che inizi a distribuire agli utenti, si preoccupano della velocità e del ridimensionamento, specialmente se lo useranno ripetutamente. (Ad esempio, un programma di installazione può essere lento; è meglio che il programma che installa non sia.) E non è solo la lingua; è il programma in generale. Se il tuo programma è lento, agli utenti non piacerà. E se hai concorrenza, gli utenti che non apprezzano il tuo programma sono una brutta cosa. Quindi una lingua che contribuisce a non piacere agli utenti (rallentandoli) è cattiva.

Faccio parte di un team che scrive software di controllo per media broadcast. Ci sono buone probabilità che la tua stazione TV o radio preferita sia in esecuzione su di essa se ti trovi negli Stati Uniti. Le prestazioni sono una delle cose di cui sentiamo parlare più spesso dai clienti. È stato originariamente scritto per piccole operazioni a stazione singola, ma ora stiamo firmando le principali reti di trasmissione e via cavo con centinaia di canali e la scala inizia a diventare un problema. Se non riusciamo a far funzionare le cose velocemente per loro, porteranno i loro contratti da milioni di dollari alle persone che possono, e finiremo senza lavoro. Ecco perché utilizziamo un linguaggio veloce e compilato e ottimizziamo il controllo dei nostri database.

Perché più veloce è meglio. Il tempo è denaro. Se si scrive un software server e si utilizza un linguaggio di programmazione più lento, si acquistano più server. Se scrivi un software termoretraibile, perdi i clienti rispetto ai rivali che sono più veloci.

Per qualsiasi tipo di software duraturo che viene utilizzato dalle persone, di solito lo desideriamo il più velocemente possibile. A livello di assemblaggio, il time-to-market aumenta troppo e non è redditizio. Sono tutti compromessi. Dal punto di vista aziendale, potrebbe essere più redditizio consentire ai programmatori poveri di eseguire il debug degli errori di memoria in C ++, facendolo per diversi mesi, se ciò significa che il prodotto è più veloce dei tuoi concorrenti.

Quindi la velocità è in realtà importante in molti software. I linguaggi lenti sono considerati "cattivi" al giorno d'oggi perché sono davvero troppo lenti (Python può facilmente essere 50x - 100x più lento, e questo è troppo)

Esistono linguaggi di programmazione per servire i programmatori.

Non so come sei arrivato a questa conclusione. Direi: gli ingegneri del software usano i linguaggi di programmazione per le loro esigenze.

Alcuni linguaggi di programmazione sono più lenti di altri, ma non perché ci sia qualcosa di sbagliato in essi.

Questa è anche un'affermazione flakey. Definisci cosa intendi usando la parola "più lento" qui. Più lento potrebbe significare:

1. I programmi finali, che ottengono la stessa cosa, funzionano "più lentamente" in una lingua rispetto a un'altra.
2. Il tempo impiegato per creare il programma finale potrebbe essere più lungo (quindi alcuni lo descriverebbero come "più lento").

Queste due questioni che vengono in mente sono anche intrecciate dove c'è una sorta di compromesso tra il tempo dedicato allo sviluppo e alle prestazioni.

Come qualsiasi software, essere lenti può essere un segno di problemi sottostanti / cattiva progettazione. Il design è un po 'uno zeitgeist, ma questo non toglie che i principi di design su cui si basa ora sono obsoleti e considerati "cattivi".

Prendi ad esempio ASP classico e ASP.net.

Qualcuno ha commentato che "I clienti adorano i software che soddisfano i requisiti e nel rispetto del budget". Bene, questo è vero, ma ha una certa influenza sul software lento e questo, quasi per definizione, significa linguaggi di programmazione (e framework) più lenti, algoritmi e configurazione. Un linguaggio di programmazione lento è forse la parte più importante di tutto quanto sopra semplicemente perché è una base dalla quale troverete più difficile cambiare. Se usi un Oracle DB e hai bisogno di più perf, puoi ottimizzare le tabelle / index / etc. Facile. Se hai un algoritmo scadente nel tuo codice, puoi scrivere codice diverso. Se il tuo framework è lento, puoi sostituirlo - non è così facile ma è fattibile senza riscrivere tutto. Se la tua lingua è troppo lenta, devi praticamente ricominciare.

Vedi Facebook per la seccatura che hanno affrontato per far funzionare PHP abbastanza velocemente quando hanno dovuto ridimensionare.

Per il resto di noi, i "requisiti prestazionali non funzionali" sono spesso scritti nelle specifiche, in particolare per le app Web scalabili. La mancata osservanza della "pagina deve essere mostrata all'utente entro 2 secondi dalla richiesta" e si perde il contratto (o si pagano penalità). Quindi, sì, i clienti adorano il software che esegue le richieste - e quelle richieste diranno che deve essere veloce (potrebbe non interessarti per quanto tempo gli utenti trascorrono a fissare la clessidra, ma il cliente lo fa sicuramente - è un costo enorme).

Ad esempio, in un grande call center mi è stato detto che avevano determinato che per ogni secondo che si poteva risparmiare sul processo di assunzione delle chiamate, 1 calltaker poteva essere "ridimensionato". Si tratta di soldi veri improvvisamente e un enorme incentivo per i capi a ottenere software più veloce, efficiente e più utilizzabile.

C'è molto tempo speso a preoccuparsi che i programmatori sfornino il codice il più velocemente possibile (e quindi test e refactoring delle unità tutto il tempo, lol). Ho scoperto che questo non è tanto un fattore come la gente pensa che sia - se sei un esperto nella tua lingua, puoi codificarlo molto più velocemente rispetto a se non hai esperienza. Quindi un esperto sviluppatore C ++ può scrivere codice più velocemente e con maggiore precisione rispetto a un sviluppatore PHP alle prime armi. Quindi penso che diventare un esperto sia più importante della scelta di una lingua "facile" ed è per questo che non mi piace il culto della "riscrittura nelle cose nuove e interessanti" che sembra essere ovunque oggi.

Sottolineerò che la maggior parte dei problemi di prestazione esistono perché il programmatore ha fatto un cattivo lavoro non perché la lingua era troppo lenta. In realtà, ci sono molte cose più pertinenti di cui preoccuparsi in termini di prestazioni rispetto alla lingua scelta. Sarebbe approssimativamente il numero 1.203.407 della mia lista.

Quindi, le prestazioni più lente, dei linguaggi di programmazione, sono davvero una cosa negativa?

A parità di altre condizioni, andare più veloce è una buona cosa. Dopotutto, nessuno vuole davvero aspettare più a lungo per alcuni risultati, e una volta fatto quel risultato può liberare risorse per altre cose.

Ma non tutto il resto è uguale. Per cominciare, è anche importante produrre il risultato giusto , o almeno abbastanza giusto. (Se sono consentiti risultati completamente sbagliati, puoi produrli davvero molto rapidamente e avranno un valore esattamente pari a zero per chiunque.) Se una modifica a un linguaggio un po 'più lento rende più probabile la produzione del risultato giusto, in genere è un grande compromesso. Le lingue di livello superiore presentano un vantaggio rispetto a quelle di livello inferiore, in quanto il loro set di modelli più ricco di solito rende più semplice esprimere un problema complesso senza troppi dettagli espliciti.

Di solito è anche importante gestire i costi di produzione del software in primo luogo, di aggiungere nuove funzionalità come desiderato e di mantenerlo funzionante quando cambiano i sistemi sottostanti. Le lingue di livello più elevato in genere consentono tempi di risposta più rapidi per la programmazione, e c'è molto valore nel mantenere i costi di programmazione nel budget. In effetti, mantenere bassi i costi consente di realizzare nel complesso più cose diverse, il che è generalmente una buona cosa.

L'ultimo punto chiave da notare è che non è necessario utilizzare solo una lingua e che molti sistemi software hanno la maggior parte dei loro componenti non critici per le prestazioni. L'uso di un linguaggio di basso livello per produrre componenti ad alte prestazioni per i bit critici è sensato, mentre lasciare le parti meno critiche in un linguaggio di alto livello (in modo da minimizzare il costo di produrli) è sensibilmente sensato. Inoltre, le caratteristiche che rendono un buon linguaggio di basso livello (la capacità di controllare esattamente ciò che fa la macchina) non sono le caratteristiche che rendono un buon linguaggio di alto livello (la capacità di inferire i dettagli da descrizioni molto più piccole): essi sono diametralmente opposti, quindi essere in grado di accoppiarli e usarli per i loro punti di forza ed evitare i loro punti deboli, è davvero una grande cosa.

Quali componenti dovrebbero ottenere il trattamento ad alte prestazioni? L'ottimizzazione? Misurali . Profilali . Trova la verità anziché indovinare. Focalizza i tuoi sforzi dove fa meglio.