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

Non penso che sia automaticamente cattivo. Python è più lento del C ++, ma quando entrambi sono abbastanza veloci , Python può essere la scelta migliore per il problema a portata di mano anche se è più lento .

È sempre un compromesso. Per piccoli compiti una tantum, è molto più veloce scrivere uno script Python piuttosto che un'app C ++ che faccia lo stesso (l'esempio tipico per me sarebbe una sorta di elaborazione di testo in batch o una struttura di directory e qualcosa da fare sui file), e non mi interessa davvero se ci vogliono 10 ms o 1000 ms, anche se è 100 volte più lento, perché potrebbe impiegarmi metà del tempo per scrivere e testare.

Naturalmente, sarebbe bello se Python fosse veloce come C ++, quindi in questo senso sono d'accordo con la tua affermazione che "slow = bad". Ma preferisco avere un linguaggio potente che gira veloce come voglio, non facendo alcune cose (diciamo, i limiti degli array controllando su array raw) a patto che mi permetta di decidere quando fare quel compromesso (ad esempio, usando std: :. vettore)

Piuttosto semplice: essere lenti è una brutta cosa

quando il programma richiede un determinato livello di prestazioni

perché senza quella prestazione non soddisfi i requisiti.

Potrebbe trattarsi di qualsiasi cosa, da un'applicazione aziendale che deve elaborare le query in un 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 assurdamente le istruzioni che qualsiasi idiota con una tabella trigonomica potrebbe seguire. Ostinano ostinatamente a fare quello che hai detto invece di quello che intendevi. Non un briciolo di auto-direzione o intuizione. È orribile.

L'UNICA cosa sta facendo un computer è, è veloce. Veramente! Un knucklehead con uno schedario potrebbe fare lo stesso lavoro di un database. Qualche tizio che fa girare una macchina da stampa potrebbe fare quello che fa Apache. Sul serio! E hanno fatto, per centinaia e centinaia di anni, come dato di fatto. Perché un computer fa bene a TUTTO è la sua velocità.

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

Un linguaggio di programmazione può essere di altissimo livello, "fare molto", essere comunque molto veloce. OCaml è un linguaggio di livello superiore rispetto al PHP, ma sta producendo un codice quasi veloce come C. Javascript è dinamico come PHP, ma può essere eseguito molto velocemente. Quindi, è principalmente un problema con un'implementazione linguistica, 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 necessario per risolvere problemi / bug e produrre nuovo codice e distribuirlo).

Le lingue di scripting in genere hanno tempi di esecuzione più brevi ma tempi di manutenzione più rapidi perché spesso è possibile apportare modifiche e implementazioni rapide senza dover ricostruire un intero sistema e, a volte, senza dover nemmeno fermarsi e riavviarsi.

Quindi molto è un equilibrio in base alla velocità richiesta.

Anche il contesto è importante. Caricare la configurazione iniziale impiegando 0,5 secondi invece di 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, richiedendo quindi 50 secondi invece di 10.

Semplice: i clienti amano il software veloce. In realtà, l'intero scopo dei computer è calcolare rapidamente.

Lento è relativo. Se ho il requisito di leggere una porta 10 volte al secondo, un linguaggio che non può creare un binario che può farlo è troppo lento. Se sto scrivendo un'applicazione web in cui la sequenza richiesta / risposta tra server e browser / client viene misurata in secondi e l'utente è probabile che trascorrerà minuti su una schermata 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 quello non sarà il linguaggio in sé ma i compilatori e / oi runtime che ne derivano. Questo è chiaro vedendo lo sviluppo di Java, dove le prestazioni delle JVM (anche su ambienti hardware identici) sono aumentate nel corso degli anni in modo radicale. E naturalmente è sempre possibile scrivere codice terribilmente lento in qualsiasi ambiente tu scelga. Poiché affermazioni come "C ++ è dieci volte più veloce di Java" sono automaticamente false se non sono 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 prova e come lo esegui.

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

Se hai solo bisogno di un piccolo strumento personale per fare qualcosa una volta, può essere lento come vuoi. Ma una volta che si inizia 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, il programma che installa è meglio che non lo 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 cosa molto brutta. Quindi un linguaggio che contribuisce a rendere gli utenti non gradevoli al tuo programma (rendendolo lento) è cattivo.

Sono parte di un team che scrive software di controllo per i mezzi di trasmissione. C'è una buona probabilità che la tua stazione TV o radio preferita funzioni su di esso se ti trovi negli Stati Uniti. Le prestazioni sono una delle cose che sentiamo parlare più spesso dai clienti. È stato originariamente scritto per piccole operazioni a stazione singola, ma ora stiamo firmando importanti 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, prenderanno i loro contratti multimilionari per le persone che possono, e finiremo senza lavoro. Ecco perché utilizziamo un linguaggio veloce e compilato e ottimizziamo i nostri database.

Perché più veloce è meglio. Il tempo è denaro. Se scrivi software server e usi un linguaggio di programmazione più lento, acquisti più server. Se scrivi un software compresso, perdi clienti per rivali più veloci.

Per qualsiasi tipo di software duraturo che viene utilizzato dalle persone, di solito lo vogliamo il più velocemente possibile. A livello di assemblea, il time-to-market aumenta troppo da non essere redditizio. Sono tutti trade-off. Dal punto di vista del business, potrebbe essere più vantaggioso lasciare che i poveri programmatori eseguano il debug degli errori di memoria in C ++, facendolo per diversi mesi, se significa che il prodotto è più veloce dei tuoi concorrenti.

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

Programming languages exist to serve programmers.

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

Some programming languages are slower then other but that's not because there is something wrong with them.

Questa è anche una dichiarazione flakey. Definisci cosa intendi usando qui la parola 'più lenta'. Più lento potrebbe significare:

1. Programmi finali, che realizzano il stessa cosa, eseguire 'più lento' in uno lingua rispetto ad un'altra.
2. Il tempo necessario per creare il programma finale potrebbe essere più lungo (quindi, alcuni lo definirebbero "più lento").

Questi due problemi che vengono in mente sono anche intrecciati dove c'è una sorta di compromesso tra il tempo speso per lo sviluppo e le prestazioni.

Come qualsiasi altro software, essere lento può essere un segno di problemi di fondo / cattiva progettazione. Il design è un po 'uno zeitgeist, ma questo non toglie nulla al fatto che i principi di design su cui ora si basano sono obsoleti e considerati "cattivi".

Prendi Classic ASP e ASP.net per esempio.

Qualcuno ha commentato che "I clienti amano il software che soddisfa i requisiti e il budget". Bene, questo è vero, ma ha una certa influenza sul software lento, e questo, quasi per definizione, significa linguaggi di programmazione più lenti (e framework) e algoritmi e configurazione. Un linguaggio di programmazione lento è probabilmente la parte più importante di tutto quanto sopra semplicemente perché è una base dalla quale troverai più difficile cambiare. Se usi un DB Oracle e hai bisogno di più perf, puoi ottimizzare le tabelle / indice / ecc. Facile. Se hai un algoritmo scadente nel tuo codice, puoi scrivere un 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 da capo.

Guarda Facebook per il fastidio con cui sono andati a fare in modo che PHP funzionasse abbastanza velocemente quando avevano bisogno di scalare.

Per il resto di noi, i "requisiti di performance non funzionali" sono spesso scritti in specifiche, in particolare per applicazioni web scalabili. Non riescono a soddisfare la "pagina deve essere visualizzata all'utente entro 2 secondi dalla richiesta" e si perde il contratto (o pagare penali). Quindi, sì, i clienti amano il software che esegue le richieste - e quelle richieste diranno che deve essere veloce (potrebbe non interessarti per quanto tempo gli utenti passano a fissare la clessidra, ma il cliente sicuramente lo fa - è un costo enorme).

Per un esempio, in un call center di grandi dimensioni mi è stato detto che avevano stabilito che per ogni secondo che si poteva risparmiare nel processo di presa di chiamata, 1 calltaker poteva essere 'ridimensionato'. Questo è denaro reale all'improvviso, e un enorme incentivo per i boss a ottenere software più veloce, efficiente e più utilizzabile.

C'è un sacco di tempo speso a preoccuparsi che i programmatori sfornino il codice il più velocemente possibile (e poi testare e refactoring di unità tutto il tempo, lol). Ho scoperto che questo non è un fattore tanto quanto la gente pensa che sia - se sei un esperto nella tua lingua, puoi codificarlo molto più velocemente rispetto a se sei inesperto. Quindi un esperto C ++ dev può scrivere codice più velocemente e più accuratamente di un debuttante sviluppatore PHP. Quindi penso che diventare un esperto sia più importante della scelta di un linguaggio "facile" ed è per questo che non mi piace il culto della "riscrittura nelle cose nuove e fresche" che sembra essere ovunque oggi.

Sottolineo che la maggior parte dei problemi di prestazioni esiste perché il programmatore ha fatto un brutto lavoro non perché la lingua era troppo lenta. In realtà, ci sono molte altre cose pertinenti di cui preoccuparsi nelle prestazioni rispetto alla lingua che scegli. Sarebbe circa il numero 1.203.407 sulla mia lista.

So, is slower performance, of programming languages, really, a bad thing?

A parità di condizioni, andare più veloce è una buona cosa. Dopotutto, nessuno vuole davvero aspettare più a lungo per alcuni risultati, e una volta che il risultato è finito 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 errati, è possibile produrli molto rapidamente e saranno di valore zero per chiunque.) Se un cambiamento in un linguaggio un po 'più lento rende più probabile che venga prodotto il risultato giusto, che è tipicamente un grande scambio. I linguaggi di livello superiore hanno un vantaggio rispetto a quelli di livello inferiore qui, dato che il loro insieme di modelli più ricco di solito rende più semplice esprimere un problema complesso senza un dettaglio schiacciante e molto esplicito.

Di solito è anche importante gestire i costi di produzione del software in primo luogo, aggiungere nuove funzionalità come desiderato e mantenerlo funzionante al cambiare dei sistemi sottostanti. Solitamente i linguaggi di livello superiore consentono una programmazione più veloce e c'è molto valore nel mantenere i costi di programmazione all'interno del budget. In effetti, mantenere i costi verso il basso consente di ottenere nel complesso cose più diverse, il che è generalmente una buona cosa.

L'ultimo punto chiave da tenere presente è che non è necessario utilizzare una sola lingua e che molti sistemi software hanno la maggior parte dei loro componenti che non sono critici dal punto di vista delle prestazioni. Usare un linguaggio di basso livello per produrre componenti ad alte prestazioni per i bit critici è sensato, mentre lasciare le parti meno critiche ad un linguaggio di alto livello (in modo da minimizzare il costo di produrle) è eminentemente ragionevole. Inoltre, le caratteristiche che rendono un buon linguaggio di basso livello (la capacità di controllare con precisione ciò che fa la macchina) non sono le caratteristiche che rendono un buon linguaggio di alto livello (la capacità di dedurre i dettagli da descrizioni molto più piccole): sono diametralmente opposti, quindi essere in grado di accoppiarli e usarli per i loro punti di forza ed evitare le loro debolezze, è davvero una grande cosa.

Quali componenti dovrebbero ottenere il trattamento ad alte prestazioni? L'ottimizzazione? Misura loro. Profilo loro. Trova la verità piuttosto che indovinare. Focalizza il tuo sforzo dove è più utile.