Dobbiamo usare C "per motivi di prestazioni" [chiuso]

StackOverflow https://stackoverflow.com/questions/1223710

Domanda

In questa epoca di molte lingue, sembra esserci una lingua fantastica per quasi ogni compito e mi trovo a lottare professionalmente contro un mantra di " nient'altro che C è veloce " ;, dove Veloce intende davvero "abbastanza veloce". Lavoro con persone di mentalità molto razionale, a cui piace confrontare i numeri, e tutto ciò che ho sono pensieri e opinioni. Potresti aiutarmi a trovare la mia strada oltre le opinioni soggettive e nel "mondo reale"?

Mi aiuterebbe a trovare delle ricerche su cosa fare se qualsiasi altra lingua potesse essere utilizzata per la programmazione di sistemi embedded e (Linux)? Potrei benissimo sostenere una falsa ipotesi e apprezzerei molto la ricerca per dimostrarmelo. Potresti collegare o includere buoni numeri in modo da aiutare a mantenere il "questo è solo il suo parere" commenti al minimo.

Quindi questi sono i miei requisiti particolari

  • la memoria non è un serio limite
  • la portabilità non è una preoccupazione seria
  • questo non è un sistema in tempo reale
È stato utile?

Soluzione

" Nient'altro che C è veloce [abbastanza] " è un'ottimizzazione precoce e sbagliata per tutti i motivi per cui le ottimizzazioni precoci sono sbagliate. Se il tuo sistema ha una complessità sufficiente da desiderare qualcosa di diverso da C, allora ci saranno parti del sistema che devono essere "abbastanza veloci" e parti con vincoli più leggeri. Se, ad esempio, scrivendo il tuo codice in Python il progetto finirà più velocemente, con un minor numero di bug, allora puoi seguire un po 'di codice C o assembly per velocizzare le parti che richiedono tempo.

Anche se risulta che l'intero codice deve essere scritto in C o assembly per soddisfare i requisiti di prestazione, la prototipazione in un linguaggio come Python può avere reali vantaggi. Puoi prendere il tuo prototipo Python funzionante e sostituire gradualmente le parti con codice C fino a raggiungere le prestazioni necessarie.

Quindi, usa gli strumenti che ti consentono di svolgere il lavoro di sviluppo nel modo più corretto e rapido, quindi usa i dati reali per determinare dove devi ottimizzare. Potrebbe essere che C sia lo strumento più appropriato per iniziare a volte, ma certamente non sempre, anche nei sistemi embedded.

Altri suggerimenti

Nella mia esperienza, l'uso di C per la programmazione integrata e di sistemi non è necessariamente un problema di prestazioni, ma spesso è un problema di portabilità. C tende ad essere il linguaggio più portatile e ben supportato su quasi tutte le piattaforme, specialmente su piattaforme di sistemi embedded.

Se desideri utilizzare qualcos'altro in un sistema incorporato, spesso si tratta di capire quali opzioni sono disponibili, quindi determinare se le prestazioni, il consumo di memoria, il supporto della libreria, ecc., sono "abbastanza buone"; per la tua situazione.

L'uso di C per sistemi embedded ha alcune ottime ragioni, di cui "prestazioni" è solo uno dei minori. Incorporato è molto vicino all'hardware, hai bisogno di indirizzare manualmente la memoria per comunicare con l'hardware. Tutte le API e gli SDK sono disponibili principalmente per C.

Esistono solo poche piattaforme in grado di eseguire una VM per Java o Mono, in parte a causa delle implicazioni sulle prestazioni ma anche dei costosi costi di implementazione.

Oltre alle prestazioni, c'è un'altra considerazione: molto probabilmente avrai a che fare con API di basso livello progettate per essere utilizzate in C o C ++ .

Se non è possibile utilizzare alcuni SDK, ci si mette solo nei guai invece di risparmiare tempo con lo sviluppo con un linguaggio di livello superiore. Per lo meno, finirai per ripetere un sacco di dichiarazioni di funzioni e definizioni costanti.

Per C:

  • C è spesso l'unico linguaggio supportato dai compilatori per processori.
  • La maggior parte delle librerie e del codice di esempio è probabile anche in C.
  • La maggior parte degli sviluppatori embedded ha anni di esperienza in C ma poca esperienza in qualsiasi altra cosa.
  • Consente l'interfacciamento hardware diretto e la gestione manuale della memoria.
  • Facile integrazione con il linguaggio assembly.

C sarà presente per molti anni a venire. Nello sviluppo integrato è un monopolio che soffoca qualsiasi tentativo di cambiamento. Un linguaggio che necessita di una VM come Java o Lua non diventerà mai mainstream nell'ambiente incorporato. Un linguaggio compilato potrebbe avere una possibilità se fornisce nuove interessanti funzionalità rispetto a C.

Esistono diversi parametri di riferimento sul Web tra lingue diverse. La maggior parte di essi troverà un'implementazione C o C ++ in alto poiché ti dà più controllo per ottimizzare davvero le cose.

Esempio: The Computer Language Benchmarks Game .

È difficile discutere contro C (o altri linguaggi procedurali come Pascal, Modula-2, Ada) e assembly per embedded. C'è una grande storia di successo con quelle lingue. In generale, si desidera rimuovere il rischio dell'ignoto. Cercare di usare qualcosa di diverso da C o assembly, secondo me, è sconosciuto. Detto questo, non c'è niente di sbagliato in un modello misto in cui usi uno degli schemi che vanno in C, o Python o Lua o JavaScript come linguaggio di scripting.

Quello che vuoi è la possibilità di andare rapidamente e facilmente in C quando devi.

Se convinci il team a scegliere qualcosa che non è stato dimostrato, il progetto è il tuo cookie. Se si sbriciola, sarà probabilmente visto come colpa tua.

Questo articolo (di Michael Barr) parla dell'uso di C, C ++, assemblatore e altri linguaggi nei sistemi incorporati e include un grafico che mostra l'utilizzo relativo di ciascuno di essi.

Ed ecco un altro articolo, appropriatamente intitolato, Scarse ragioni per rifiutare C ++ .

Ci sono situazioni in cui sono necessarie prestazioni in tempo reale, specialmente nei sistemi embedded. Hai anche gravi limiti di memoria. Un linguaggio come C ti offre un maggiore controllo sui tempi di esecuzione e sullo spazio di esecuzione.

Quindi, a seconda di ciò che stai facendo, C potrebbe benissimo essere "migliore". o più appropriato.

Consulta i seguenti articoli

Ada è un linguaggio di programmazione di alto livello progettato per sistemi embedded e sistemi mission-critical.

È un linguaggio veloce e sicuro con controllo dei dati integrato ovunque. È quello in cui sono programmati i piloti automatici negli aeroplani.

A questo link hai un confronto tra Ada e C.

Potresti voler guardare il D . Potrebbe utilizzare un po 'di ottimizzazione delle prestazioni, in quanto vi sono alcune aree in cui Python può superare. Non posso davvero farti riferimento a confronti comparativi poiché non ho tenuto un elenco, ma come sottolineato da Peter Olsson, Benchmark e amp; Implementazioni linguistiche ha D Digital Mars.

Probabilmente vorrai anche dare un'occhiata a queste adorabili domande:

C è onnipresente, disponibile per quasi tutte le architetture, solitamente dal primo giorno di disponibilità di un processore. C ++ è un secondo vicino. Se il tuo sistema è in grado di supportare C ++ e disponi delle competenze necessarie, utilizzalo preferibilmente a C: è tutto ciò che è C e altro, quindi ci sono alcuni motivi per non usarlo.

Il C ++ è un linguaggio più ampio e ci sono costrutti e tecniche supportate che possono consumare risorse o comportarsi in modi inaccettabili in un sistema incorporato, ma questo non è un motivo per non usare il linguaggio, ma piuttosto come usarlo in modo appropriato.

Java e C # (su Micro.Net o WinCE) possono essere alternative praticabili per non in tempo reale.

In realtà non sono un programmatore di sistemi / embedded, ma mi sembra che i programmi embedded in genere necessitino di prestazioni deterministiche, il che esclude immediatamente molti linguaggi raccolti, perché sono non deterministici in generale . Tuttavia, è stato svolto un lavoro sulla raccolta dei rifiuti deterministica (ad esempio, Metronome per Java: http://www.ibm.com/developerworks/java/library/j-rtj4/index.html )

Il problema è uno dei vincoli: le lingue / i tempi di esecuzione soddisfano i requisiti deterministici, di utilizzo della memoria, ecc.

C è davvero la scelta migliore.

C'è una differenza per scrivere codice C portatile e approfondire le caratteristiche del ghee whiz di un compilatore specifico o casi d'angolo del linguaggio (che dovrebbero essere evitati tutti). Ma portabilità tra compilatori e versioni di compilatori. Il numero di dipendenti che saranno in grado di sviluppare o mantenere il codice. I compilatori avranno un momento più facile con esso e produrranno un codice migliore, più pulito e più affidabile.

C non sta andando da nessuna parte, con tutte le nuove lingue progettate per correggere i difetti in tutte le lingue precedenti. C, con tutti i difetti che queste nuove lingue stanno cercando di correggere, è ancora valida.

Ecco alcuni articoli che confrontano C # con C ++:

http://systematicgaming.wordpress.com/ 2009/01/03 / prestazioni-c-vs-c /

http: //journal.stuffwithstuff. com / 2009/01/03 / debunking-c-vs-c-prestazioni /

Non esattamente quello che hai chiesto in quanto non si concentra sulla programmazione C integrata. Ma è comunque interessante. Il primo dimostra le prestazioni del C ++ e i vantaggi dell'utilizzo di "non sicuro" codice per compiti intensivi del processore. Il secondo in qualche modo ridimensiona il primo e mostra che se si scrive il codice C # in modo leggermente diverso, le prestazioni sono quasi le stesse.

Quindi dirò che C o C ++ possono essere il chiaro vincitore in termini di prestazioni in molti casi. Ma spesso il margine è ridotto. Se usare C o no è un altro argomento del tutto. Secondo me dovrebbe davvero dipendere dal compito da svolgere. Ma nei sistemi embedded spesso non hai molta scelta.

Un paio di persone hanno menzionato Lua. Le persone che conosco che hanno lavorato con i sistemi embedded hanno detto che Lua è utile, ma non è proprio il suo linguaggio in sé, ma più di una libreria che può essere incorporata in C. È mirata all'uso nei sistemi embedded e in genere vorrai chiamare il codice Lua da C. Ma la C pura semplifica la manutenzione (anche se non necessariamente), poiché tutti lo sanno.

A seconda della piattaforma incorporata, se i vincoli di memoria rappresentano un problema, molto probabilmente dovrai utilizzare un linguaggio di programmazione raccolto senza immondizia.

C in questo senso è probabilmente il più noto dal team e il più ampiamente supportato con le librerie e gli strumenti disponibili.

La verità è che non sempre.

Sembra che il runtime .NET (ma qualsiasi altro runtime possa essere preso come esempio) impone diversi MB di sovraccarico del runtime. Se questo è tutto ciò che hai (nella RAM), sei sfortunato. JavaME sembra essere più compatto, ma dipende ancora tutto dalle risorse che hai a disposizione.

I compilatori C sono molto più veloci anche sui sistemi desktop, a causa del numero limitato di funzionalità di lingue rispetto al C ++, quindi immagino che la differenza non sia banale sui sistemi embedded. Ciò si traduce in tempi di iterazione più rapidi, sebbene OTOH non abbia le comodità di C ++ (come le raccolte) che potrebbero rallentarti nel lungo periodo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top