Ci sono molti studi comparativi e disponibili online quando si tratta delle prestazioni di runtime di applicazioni costruite usando una lingua o un'altra. Alcuni guidati da società, alcuni accademici, altri solo rapporti di esperimenti personali.

Abbiamo anche una buona dose di studi comparativi sugli effetti collaterali di un linguaggio di programmazione e dei suoi strumenti, come:

• tempi di costruzione,
• probabilità di rilevamento di bug post-produzione,
• potere espressivo,
• eccetera...

Tuttavia, recentemente sono stato sempre più sconvolto dal consumo di memoria dei miei programmi più di ogni altra cosa. Ciò potrebbe derivare dal fatto che mentre la Legge di Moore è dalla nostra parte per le prestazioni allo stato puro, siamo arrivati ​​a renderci conto che gli altri colli di bottiglia contano di più. Questo, e non tendo ad aggiornare il mio hardware ogni tanto, e ho un po '"vecchio" (leggi Pentium 4 2005-2006 3,6 GHz con 4 GB di RAM) che al giorno d'oggi sono difficili da usare per applicazioni di grandi dimensioni senza richiedendomi di affrontare grossi problemi per spremerli ogni volta (scelta del sistema operativo, interfaccia utente, ottimizzazione dei servizi e dei demoni, scelta delle applicazioni da utilizzare per un'attività o per un altro ...). Onestamente, a volte accendo topo procexppiango alla vista della memoria usata dai programmi più innocenti.

Posso affrontarlo continuando a spingere nella direzione sopra elencata, e essenzialmente cercando di limitare me stesso e i programmi che uso (ho un caro amore per i programmi di cli per questo motivo, immagino), ma non posso fare a meno di pensare che forse stiamo sbagliando.

Strumenti moderni per esigenze moderne

Naturalmente, le lingue di livello superiore sono probabilmente migliori e giustificano il loro peso morto. Alcune scelte progettuali sono state fatte per buone (o presumibilmente ben intenzionate) ragioni al momento, in molte toolchain. Librerie condivise, modelli di memoria, pre-processori, sistemi di tipo, ecc ... Ma alcuni potrebbero essere più praticabili di altri con il nostro hardware moderno, e sarei curioso di leggere alcuni studi seri sull'argomento.

Quindi, la mia domanda è: esiste un ciondolo per il Benchmarks Game e altri che si concentrano su un confronto del consumo di memoria di runtime di base delle lingue?

E ancora di più, ci sono alcuni studi che fanno riferimento a questo parametro con altri parametri (simile a quello che ha fatto questo articolo , ad esempio, per altri criteri, basato anche sul gioco dei benchmark )?

^{Ho trovato alcune informazioni parziali, quindi inizierò a compilare i miei risultati nella mia risposta. Per favore, non lasciare che ciò ti impedisca di contribuire con le tue risposte (o di modificarle).}

Letteratura esistente:

• Un confronto empirico di 7 linguaggi di programmazione - Prechelt (2000) [ PDF ]

  Un po 'datato, ma copre parte del materiale che mi interessa e offre una visione dell'utilizzo della memoria di runtime ed espressività. I risultati possono ora differire notevolmente, ma è un inizio interessante.

• Velocità, dimensioni e affidabilità dei linguaggi di programmazione - Marceau (2009) [ blog ]

• Codice usato, forme usate nel tempo dal gioco Benchmarks [ u32 , u32q , u64 , u64q ]

  Sebbene non riguardi il consumo di memoria di runtime, il lavoro di Marceau è più o meno il tipo di riferimento o studio empirico che sarei disposto a trovare per quei criteri, in termini di contenuto e qualità. Un buon esempio di ciò che sto cercando, solo per metriche diverse. Il secondo articolo è un follow-up trovato sul sito di Benchmarks Game e che è stato pubblicato poco dopo (e che fa riferimento) al lavoro di Marceau, con schermate più recenti e più lingue, sebbene ancora senza dettagli sulla memoria di runtime. Ogni grafico su queste pagine porta poi a confronto la lingua a lingua che fanno fornire ad alto livello informazioni della memoria però.

Questo non sta rispondendo alla domanda per dire, ma forse cambia un po 'la prospettiva. Sto tenendo presente la trascrizione della chat, per impostare il tono di questo commento-risposta che sarà sicuramente oggetto di molti voti negativi.

Ci sono persone, fornitori di hardware, fornitori di strumenti e programmatori che sono preoccupati per l'efficienza. Per il momento, sarà una preoccupazione crescente per loro e per tutti noi. Tali preoccupazioni sono radicate nei dispositivi mobili, in particolare i mostri che divorano batteria ad alta potenza con gli schermi più grandi e le radio più potenti.

Per fare un altro passo indietro, parte del motivo per cui ci troviamo nella situazione in cui ci troviamo oggi, con framework relativamente massicci e un leggero disprezzo per l'efficienza generale, oltre ai miglioramenti hardware è l'eredità. La compatibilità con i sistemi legacy ci rafforza con la compatibilità oltre alla compatibilità. Non è tanto colpa di un runtime di livello superiore, in quanto sono essenzialmente lo stesso runtime che agisce abbastanza efficiente e performante quando utilizzato in un ambiente operativo diverso (ad esempio Xbox, Windows Mobile pre 7/8 / superficie, micro framework Java , eccetera).

Confronta l'estensione della compatibilità di un desktop con il suo software legacy con la compatibilità di un dispositivo mobile.

Con i dispositivi mobili, i produttori di dispositivi fanno qualche sforzo per garantire una certa compatibilità, ma non hanno fatto della compatibilità un fondamento fondamentale. Quando la scelta è tra continuare a fornire compatibilità e spostare il design del sistema mobile in avanti, il sistema mobile avanza.

Per i desktop, è vero il contrario. Se un significativo cambiamento di rottura colpisce erroneamente i marketer o i primi utenti, spinge molte volte le funzionalità necessarie e la riprogettazione nella stanza sul retro. Ad un certo punto ricordo le voci secondo cui noi come utenti di Windows troveremmo un file system completamente e drammaticamente nuovo con Windows XP, poi in Vista, poi lo stesso per Seven, e infine di nuovo in Otto, ma no, appena migliorato in modo progressivo da l'abbiamo visto per la prima volta su Windows 2000? Il nuovo file system è rimasto in circolazione per molto tempo, è stato demolito, e comunque le voci decidono la storia dopo, non posso dire. Questo è probabilmente il più grande caso noto, ma sono sicuro che non è l'unico caso importante.

Anche con i tablet e i sistemi operativi mobili più recenti, Microsoft che una volta ha plasmato il mercato, ora è intrecciata in un incontro mortale con non solo i consumatori, ma un'ombra di se stessa dal reparto desktop. Il tablet doveva avere una notevole interoperabilità con la controparte desktop. No, non poteva giocare perfettamente con esso, a causa delle differenze di architettura, ma anche a causa della natura arcaica delle basi del desktop ha fatto sacrifici significativi.

Ora certamente, Windows è il bersaglio facile per qualsiasi tipo di critica per questa situazione, ma altre piattaforme sono tutt'altro che "senza peccato". Ci sono molte reliquie in agguato nell'ecosistema Linux che sono sicuro che causano grande costernazione per un miglioramento sistematico.

L'economia gioca un ruolo importante in questa equazione; il modo in cui finanziamo i nostri computer e le nostre applicazioni su uno e il modo in cui sono finanziati sull'altro seguono schemi sorprendentemente diversi. Laddove una volta Wintel ha fortemente influenzato l'obsolescenza, Apple e Google lo hanno trasformato in un programma quasi rigoroso. Questo è più lontano del previsto, quindi me ne andrò così com'è e lascio che i lettori lo prendano da lì.

Se e quando i grandi fornitori cambiano la loro obsolescenza e i loro modelli di prezzo, allora possono iniziare ad andare avanti con cambiamenti su larga scala a un tasso più uniforme. Quei quadri di livello superiore che sono guidati dalle lingue di ordine più elevato si ridurranno in un certo senso, in quanto saranno in grado di svolgere il loro compito di alto livello con un'efficienza più di basso livello perché l'inefficiente compatibilità intermedia e i livelli di basso livello si ridurranno essere drasticamente ridotto, se non eliminato.