Embedded systems programmers worldwide earn failing grades in C

[TheKaneB]

• 

Dimenticavo:

per poter fare i dump, l'allocatore dovrà tenere in memoria l'intero log delle allocazioni, quindi sta roba è fattibile solo in fase di sviluppo e poi va disattivata.
Ad esempio su PS3 quando lavoravo su WRC non ci bastava la Ram per contenere tutta questa massa di Log e dovevamo fare il debug della memoria bloccando i LOD e le MIPMAP al livello più basso.
Poi avevo affibbiato al "quadrato" l'azione di dump su console, per cui non potevo usare il freno a mano mentre debuggavo (e per debuggare il freno a mano ho dovuto sacrificare il tasto della retromarcia)

[Z80Fan]

• 

Ora ha già tutto più senso.

Ecco vedi però che era più o meno quello che dicevo di fare io! (dovevo trovare qualcosa da obiettare )

Anche l'identificazione dei leak é veramente interessante... praticamente vedi le allocazioni che si accumulano nel tempo.
Bravo bravo.

[TheKaneB]

• 

Sì quello che avevi suggerito era buono nell'idea,  ma orrido nella forma. Il software engineering altro non é che lo studio della forma migliore da dare al codice.  Gli algoritmi sono il cuore di tutto,  ma un cuore senza un corpo ben fatto non può mica andarsene a spasso 

[TheKaneB]

• 

puoi usare quello che vuoi, io ho citato il primo che mi passava per la testa

[TheKaneB]

• 

@dsar: leggiti il link che ho postato riguardo l'allocatore TLSF. Ha un costo di allocazione O(1). Su x86 garantiscono 168 istruzioni macchina per allocazione.

EDIT: riporto il link per comodità: http://www.gii.upv.es/tlsf/

[TheKaneB]

• 

Io per ridurre a quasi zero la frammentazione (un videogame non deve mai crashare in 24 ore continue di utilizzo, altrimenti Sony non te lo approva) avevo implementato l'object caching.

Quegli oggetti che necessitavano obbligatoriamente di allocazioni a tempo di frame venivano buttati in un pool la cui dimensione veniva determinata sperimentalmente in modo da azzerare le allocazioni fuori dal pool.

Ad esempio quello che ci dava problemi era Bullet Physics, che allocava degli oggetti ogni volta che si verificava una collisione tra mesh. Altro rompipalle era il sistema di GUI che generava stringhe temporanee ogni volta che mandava qualcosa a schermo.

Una volta fixati questi problemi con degli object pool, il resto veniva deallocato totalmente dopo un ciclo di gioco. Ad esempio, dopo una gara buttavo giù l'intero reparto della fisica e reinizializzavo la propria "arena" di memoria, in modo da averla perfettamente pulita per la gara successiva.

Ovviamente questo non si presta ad un utilizzo "general purpose", perchè devi conoscere come funziona il ciclo di vita dell'applicazione, ma nel campo embedded non avrai mai un sistema general purpose, sono sempre sistemi fatti su misura per un compito specifico e quindi ti permette di ottimizzare.

[TheKaneB]

• 

Se lavori su roba tipo CUDA / OpenCL, può capitare che, per ottimizzare le prestazioni, allochi un buffer sulla "Device Memory" (la memoria locale della GPU) ma l'allocatore risponde picche perchè non ha spazio, allora come fallback allochi lo stesso buffer su "Host Memory" (la memoria di sistema) e ti accolli la maggiore latenza di letture e scritture tramite bus PCI-Express, oppure cambi algoritmo e ne sfrutti uno che usa buffer più piccoli, ecc...

Insomma, in situazioni particolari ha ancora senso una gestione dell'evento "allocazione fallita" fatta a mano, ma per il general purpose sono d'accordo con @dsar.

[fulvio]

• 

Non ho letto tutto il thread ma ho fatto i due test, entrambi 8/10 ma devo dire che nel test per il C ci sono due errori nelle risposte che loro ritengono corrette.

[TheKaneB]

• 

uhm, io errori non ne ho trovati, a quali ti riferisci?

[fulvio]

• 

uhm, io errori non ne ho trovati, a quali ti riferisci?

mmm adesso non ricordo la seconda ma di sicuro quella sul volatile era inesatta. La risposta giusta secondo loro era tutte e tre, ma in realtà nel caso di variabile globale usata da più thread aggiungere volatile non serve. Le variabili volatile non sono atomiche, quindi il codice che non ci mette un mutex intorno non è protetto da race conditions in caso di più thread.

[TheKaneB]

• 

ma la domanda chiedeva quali erano i costrutti validi da un punto di vista del linguaggio. Non parlava di come si usano.

[fulvio]

• 

ma la domanda chiedeva quali erano i costrutti validi da un punto di vista del linguaggio. Non parlava di come si usano.

Non ne sarei così sicuro, è proprio uno di quei punti dove parecchi programmatori C avevano credenze particolari...certo è valido usare volatile in quei casi, come è anche valido non utilizzarlo in tutti e tre i casi, solo che poi ti trovi con un programma che non funziona.

[TheKaneB]

• 

Ripeto: Non chiedeva di elencare i casi "funzionanti", ma dichiarazioni grammaticalmente valide.

[fulvio]

• 

Ripeto: Non chiedeva di elencare i casi "funzionanti", ma dichiarazioni grammaticalmente valide.

Recuperato la domanda:

Which of the following items should generally be declared using C's volatile keyword?
A memory-mapped peripheral status register
A global variable used within an interrupt service routine
A global variable used by multiple tasks in a multi-threaded application
All of the above

la 3 è errata, nel senso che ce lo puoi anche mettere il volatile ma non ti mette al riparo dai problemi. Finisci per usare le variabili atomiche fornite dalla piattaforma oppure ti affidi al C11 se sei forutnato che ce le ha nello standard. Ma la domanda non è sulla grammatica, piuttosto sulle situazioni dove il volatile semanticamente ci vuole.

[TheKaneB]

• 

Ah no, sorry, pensavo ti riferissi alla domanda sulle keywords "static" e "volatile", che chiedeva se è possibile usarle insieme.