Microsoft rilascia dettagli e preview per WinFX

[fek]

Originariamente inviato da ^-fidel-^

Oltre a parlare di SO, parlavo pure delle applicazioni per MS scritte con linguaggi tipo C#, che non sono il massimo per quanto riguarda la gestione della memoria.

E perche' mai? Ti sfido a gestire la memoria di un'applicazione che non sia un Hello World meglio di quanto faccia il Garbage Collector di .NET oppure quello della JVM di Sun. Sai come funzionano vero?

[diabolik1981]

Originariamente inviato da ^-fidel-^

Verissimo, hai ragione. Allora puntualizzo. Penso che un SO che esce, mettiamo, nel 2006, deve girare bene sui computer che nel 2006 sono di fascai media, e meravigliosamente sui computer di fascia alta. Non dico mica che debbano girare sui 486 eh Ma MS che fa? Tira fuori un SO che gira bene sui PC di fascia alta-top della gamma e gira male (o al meglio discretamente) su pc di fascia media, ed in 5 anni tira fuori solo patch di correzione bug o 2/3 nuove features con i vari SP.

Fai qualche esempio perchè io ne ho 2 freschi freschi. XP è uscito nel 2001, l'ho installato per la prima volta su un Pentium 2 350 MHZ con 256 Ram, ed andava davvero lento,ma parlo di una macchina di fine 1997, ovvero vecchia di 4 anni e quindi di fascia bassissima. Poi l'ho installato su un Duron 800 del 2001 con 256 Ram e li andava bene, e di certo il Duron 800 non era il rop di gamma del 2001 come processore. Successivamente l'ho messo su un XP 2800+ e sull'attuale A64 3500+, con incrementi non molto avvertibile tra il 2800 e il 3500 (nonostante il raddoppio della RAM), ora 1 GB). Quindi mi sa che l'hai detta grossa.

[^-fidel-^]

Originariamente inviato da fek

E' proprio questo il punto infatti

Produrre codice a basso livello performante e' un'attivita' che il cervello umano non gradisce, perche' e' un'attivita' inerentemente algoritmica nella stragrande maggioranza delle situazioni. E il cervello umano non e' granche' con gl'algoritmi. Dove il cervello umano ha il vantaggio e' nel conoscere dettagli del problema da risolvere che permettono scorciatoie e poi deve codificare questi dettagli in un linguaggio il piu' possibile ad alto livello. Da qui in poi e' compito del compilatore il passo algoritmico per produrre il codice a basso livello migliore possibile, cosa nella quale la macchina eccelle.

Con la complessita' raggiunta dalle architetture odierne, un uomo non e' piu' in grado di fare quell'ultimo passo in maniera anche solo paragonabile a come lo puo' fare una macchina. Chiunque ha dato un'occhiata a VTune (ci ho passato le notti sigh) sa di quanti e quali parametri bisogna tenere conto e quanto sia complesso il modello prestazionale di una CPU X86. Non e' piu' un Pentium a 90mhz o un 486 a 66 sui quali scrivevo sempre codice assembly piu' veloce di qualunque compilatore, perche' il modello prestazionale era banale

Verissimo, e infatti l'asm si usa raramente. Io inizialmente parlavo di Ams sull'interfacciamento alle periferiche, oppure in alcune fasi della gestione dati. Il linguaggio di programmazione ad alto livello e' necessario (e ripeto necessario) per implementare algoritmi complessi, da qui la necessita' di utilizzare un buon compilatore (non a caso il linguaggio C/C++ con il relativo compilatore e' il piu' usato, Watcom ancora in cima, quelo MS rincorre).
Pero' vorrei aggiungere: fermo restando quelo che ho scritto nei precedenti post, non sono mica un teorizzatore del ritorno all'asm come linguaggio principale! Oltre al fatto che asm andrebbe usato sicuramente di piu' a mio avviso per alcune funzionalita', dipende pure da come una persona programma! Per implementare un algoritmo, ci sono tanti modi per farlo. Per non parlare poi dell'algoritmo stesso. Nella mia non lunghissima carriera da programmatore, ho visto algoritmi implementati in maniere molto diverse, con conseguenti diversita' di prestazioni. Ottimizzare significa proprio rendere migliore un qualcosa fatto in prima battuta. Mi limito a dire che, a mio parere, molti aspetti del SO Windows sono implementati con la finalita' "basta che funzioni", magari pero' e' lento (e non e' detto che funzioni benissimo). Infatti, se e' vero che nessun programma e' esente da bug, e' anche vero che molti programmi MS sono davvero troppo pieni di bug per essere programmi commerciali.
Sembra pero' che con Vista non stiano facendo il solito errore, a guardare il ritardo della sua uscita. Sto apsettando infatti per constatare se sara' cosi' oppure no. Sicuramente una cosa la penso: che Windows sia da molti sopravvalutato (che non vuol dire che non sia un buon prodotto eh!). Pero' non mi spiego come mai sia cosi' largamente usato (non me lo psiego se mi fermo a pensare ai motivi tecnici )

[^-fidel-^]

Originariamente inviato da fek

E perche' mai? Ti sfido a gestire la memoria di un'applicazione che non sia un Hello World meglio di quanto faccia il Garbage Collector di .NET oppure quello della JVM di Sun. Sai come funzionano vero?

Secondo me JVM gestisce meglio che .NET. Poi se proprio dobbiamo fare un raffronto, la gestione "classica" della memoria (fatta cioe' a mano, con le 'malloc' in C o con le 'new' in C++) per poi liberare i puntatori ancora a mano e' cmq piu' efficiente (non a caso i programmi 'mission critical' non sono mica scritti in .NET o Java...). Magari tra uno o due d'anni, quando la differenza tra un uso della memoria automatico ed uno manuale non sara' percettibile (data la crescente velocita' dei pc) allora tutti useranno .NET (o framework similari, che garantiscono un progetto di programma complesso a fronte di una semplicita' realizzativa).
Poi perche' sfidarmi? Se la gestione della memoria in .NET fosse cosi' grandiosa, tutti lo userebbero, ma non mi sembra sia cosi' al momento. Sembra che questo discorso lo faccia solo io in tutto il mondo...

[fek]

Originariamente inviato da ^-fidel-^

Verissimo, e infatti l'asm si usa raramente. Io inizialmente parlavo di Ams sull'interfacciamento alle periferiche, oppure in alcune fasi della gestione dati. Il linguaggio di programmazione ad alto livello e' necessario (e ripeto necessario) per implementare algoritmi complessi, da qui la necessita' di utilizzare un buon compilatore (non a caso il linguaggio C/C++ con il relativo compilatore e' il piu' usato, Watcom ancora in cima, quelo MS rincorre).

Veramente per architetture Intel il VC2005 e' secondo solo al compilatore Intel (per ovvi motivi). Sia come codice prodotto sia come aderenza allo standard, il VC2005 e' un mostro. E lo comprendo visto che il team lead e' il chairmain del comitato di standardizzazione del C++ (Herb Sutter).

Oltre al fatto che asm andrebbe usato sicuramente di piu' a mio avviso per alcune funzionalita', dipende pure da come una persona programma!

Ma proprio no. Uno puo' programmare un po' come gli pare ma non riuscira' nel 99.99% dei casi a produrre codice migliore di un ottimo compilatore C++. Non ha piu' alcun senso scrivere praticamente nulla in assembly. Ho scritto alcune centinaia di migliaia di righe di codice in BW2 e ne ho scritte forse una decina in assembly, ma giusto perche' non avevo alcun modo di fare quella cosa li'. E non posso dire di non aver avuto alcune strette necessita' prestazionali

Infatti, se e' vero che nessun programma e' esente da bug, e' anche vero che molti programmi MS sono davvero troppo pieni di bug per essere programmi commerciali.

E di nuovo. Hai delle statistiche precise o parli per sentito dire? Mi fai vedere l'analisi dei difetti per linea di codice sul software Microsoft dal quale stai attingendo per questa affermazione?

[^-fidel-^]

Originariamente inviato da diabolik1981

Fai qualche esempio perchè io ne ho 2 freschi freschi. XP è uscito nel 2001, l'ho installato per la prima volta su un Pentium 2 350 MHZ con 256 Ram, ed andava davvero lento,ma parlo di una macchina di fine 1997, ovvero vecchia di 4 anni e quindi di fascia bassissima. Poi l'ho installato su un Duron 800 del 2001 con 256 Ram e li andava bene, e di certo il Duron 800 non era il rop di gamma del 2001 come processore. Successivamente l'ho messo su un XP 2800+ e sull'attuale A64 3500+, con incrementi non molto avvertibile tra il 2800 e il 3500 (nonostante il raddoppio della RAM), ora 1 GB). Quindi mi sa che l'hai detta grossa.

Non credo, dal momento che mi sembra che hai ribadito il concetto che ho espresso prima.
Mi dici che XP andava bene su un pc di fascia media del 2001, e magari andava meravigliosamente (che e' diverso da 'bene' per me) su un pentium 3. Ovvio che poi sui pc del 2004 il SO non puo' piu' migliorare come prestazioni, se lo stesso rimane immutato: prima o poi raggiunge il massimo delle prestazioni.
O ho capito male?
Io asserivo proprio che, a mio parere, doveva andare benissimo su un Duron 800 del 2001, per poi essere potenziato con i SP per sfruttare al meglio un Athlon tra il 2800 ed il 3500. Senno' il nuovo PC non te lo godi
Invece cosi' te lo godi al meglio uno/due anni dopo che e' uscito il SO, e poi negli anni successivi il PC piu' potente ti serve solo per o videogiochi (o con programmi mission critical come Photoshop ad alti livelli o Matlab)

[fek]

Originariamente inviato da ^-fidel-^

Secondo me JVM gestisce meglio che .NET. Poi se proprio dobbiamo fare un raffronto, la gestione "classica" della memoria (fatta cioe' a mano, con le 'malloc' in C o con le 'new' in C++) per poi liberare i puntatori ancora a mano e' cmq piu' efficiente (non a caso i programmi 'mission critical' non sono mica scritti in .NET o Java...).

Eh ma grazie, quasi tutti i mission critical devono avere garanzie strette sui tempi di esecuzione, non possono avere un GC sotto che interrompa il processo per definizione in maniera asincrona e non possono neppure girare sotto Windows o Linux (non sono kernel real-time).
E leggi bene, avere garanzie sui tempi di esecuzione non vuol dire che debbano essere il piu' ottimizzati possibile, significa che se un task deve terminare entro un tempo X, devo essere garantito che lo faccio e non mi interessa che termini in meta' di X.
La cosa si puo' comunque risolvere parzialmente con .NET 2.0 ma mi sembra che il GC ancora non garantisca tempi di esecuzione fissi per ogni sweep di generazione. Ci devo guardare.

Dal punto di vista dell'efficienza, invece, sta dicendo un'enormita'. Specifica in quali condizioni la gestione esplicita' della memoria e' piu' efficiente di un garbage collector. Nella maggior parte dei casi e' vero l'esatto contrario (modelli con frequenti allocazioni di oggetti di piccole dimensioni). Lo sai che matematicamente non esiste un algoritmo di allocazione/deallocazione della memoria che e' sempre piu' efficiente di tutti gl'altri? C'e' sempre un caso patologico che stende qualunque algoritmo di allocazione.

Sembra che questo discorso lo faccia solo io in tutto il mondo...

E la cosa dovrebbe farti sorgere un dubbio

[^-fidel-^]

Originariamente inviato da fek

Veramente per architetture Intel il VC2005 e' secondo solo al compilatore Intel (per ovvi motivi). Sia come codice prodotto sia come aderenza allo standard, il VC2005 e' un mostro. E lo comprendo visto che il team lead e' il chairmain del comitato di standardizzazione del C++ (Herb Sutter).

Si' hai ragione, sono rimasto a vecchi dati Il VC2005 e' ottimo (tra l'altro anch'io uso quello), e Watcom l'ho abbandonato. Ho scritto una cosa che magari andava bene 4 anni fa

Originariamente inviato da fek

Ma proprio no. Uno puo' programmare un po' come gli pare ma non riuscira' nel 99.99% dei casi a produrre codice migliore di un ottimo compilatore C++. Non ha piu' alcun senso scrivere praticamente nulla in assembly. Ho scritto alcune centinaia di migliaia di righe di codice in BW2 e ne ho scritte forse una decina in assembly, ma giusto perche' non avevo alcun modo di fare quella cosa li'. E non posso dire di non aver avuto alcune strette necessita' prestazionali

Si', infatti ho parlato anche di "come una pesona programma" nel senso di scrivere un codice efficiente. Oltre ad usare un buon compilatore (e siamo d'accordo), ok, si puo' usare Asm a mio parere per migliorar ulteriormente, ma gia' programmando bene senza sare l'asm sarebbe un grande passo in avanti (e molti a mio parere programmano senza tenere conto dell'ottimizzazione). Vorrei chiarire, non intendo ottimizzazione=scrivere in asm! Asm puo' aiutare (e molto inalcune situazioni) ma non e' lo strumento necessario per scrivere codice ottimizzato. Spero di essere stato piu' chiaro ora

Originariamente inviato da fek

E di nuovo. Hai delle statistiche precise o parli per sentito dire? Mi fai vedere l'analisi dei difetti per linea di codice sul software Microsoft dal quale stai attingendo per questa affermazione?

Vedo di postartele a breve. Onestamente, a parita' di complessita', non ho ancora visto un qualunque programma cosi' pieno di bug come un SO MS appena uscito (almeno prima di Vista). Anche loro sanno fare meglio! (vedi le varie suite Office). Se solo conti quante patch sono uscite negli anni per WinXP... Cmq ripeto, vedo di postarti i dati, se parliamo piu' approfonditamente dei difetti per riga di codice.

[fek]

Originariamente inviato da ^-fidel-^

Si', infatti ho parlato anche di "come una pesona programma" nel senso di scrivere un codice efficiente. Oltre ad usare un buon compilatore (e siamo d'accordo), ok, si puo' usare Asm a mio parere per migliorar ulteriormente, ma gia' programmando bene senza sare l'asm sarebbe un grande passo in avanti (e molti a mio parere programmano senza tenere conto dell'ottimizzazione). Vorrei chiarire, non intendo ottimizzazione=scrivere in asm! Asm puo' aiutare (e molto inalcune situazioni) ma non e' lo strumento necessario per scrivere codice ottimizzato. Spero di essere stato piu' chiaro ora

Ripeto: non c'e' alcun modo tale che tu possa produrre codice asm per Intel migliore di quello prodotto da un VS2005 oppure dal compilatore Intel. Questo e' proprio insuperabile perche' usa nozioni sull'architettura che loro non rendono note all'esterno.

Prova, prendi un qualunque algoritmo in C++ e prova a scriverlo piu' velocemente in asm. Poi postami il codice C++ e la tua versione asm che controllo

Vedo di postartele a breve. Onestamente, a parita' di complessita', non ho ancora visto un qualunque programma cosi' pieno di bug come un SO MS appena uscito (almeno prima di Vista). Anche loro sanno fare meglio! (vedi le varie suite Office). Se solo conti quante patch sono uscite negli anni per WinXP... Cmq ripeto, vedo di postarti i dati, se parliamo piu' approfonditamente dei difetti per riga di codice.

Mi faresti un favore a postare quei dati perche' io non li ho mai visti. E francamente non penso che li vedro' mai visto che questa analisi non esiste pubblica

[^-fidel-^]

Originariamente inviato da fek

Eh ma grazie, quasi tutti i mission critical devono avere garanzie strette sui tempi di esecuzione, non possono avere un GC sotto che interrompa il processo per definizione in maniera asincrona e non possono neppure girare sotto Windows o Linux (non sono kernel real-time).

Emh puoi essere piu' chiaro? Il discorso mi interessa particolarmente

Originariamente inviato da fek

Dal punto di vista dell'efficienza, invece, sta dicendo un'enormita'. Specifica in quali condizioni la gestione esplicita' della memoria e' piu' efficiente di un garbage collector. Nella maggior parte dei casi e' vero l'esatto contrario (modelli con frequenti allocazioni di oggetti di piccole dimensioni). Lo sai che matematicamente non esiste un algoritmo di allocazione/deallocazione della memoria che e' sempre piu' efficiente di tutti gl'altri? C'e' sempre un caso patologico che stende qualunque algoritmo di allocazione.

Si lo so, ma evidentemente ho usato in modo errato la parola "efficienza". Parlavo della rapidita' dell'esecuzione di un processo in media, poi e' normale che alcuni modelli vadano meglio con una gestione di tipo garbage, soprattutto quando la quantita' di memoria presente sulla macchina non e' un problema. Parlavo semplicemente dei porgrammi usati comunemente, ma anche di molte apps mission critical (non riesco a farti nomi espliciti giacche' mi riferisco ad apps 'ad hoc' scritte per le aziende su richiesta, caso per caso. Convengo quindi quando parli di allocazione manuale come il sistema non assolutamente migliore: pero' nella media si'

Originariamente inviato da fek

E la cosa dovrebbe farti sorgere un dubbio

Di dubbi ne ho piu' di uno Per ora penso questo, ma sono sicuro che i metodi automatici saranno non tra molto tempo davvero efficienti (e si studia proprio questo, dal momento che le apps, sempre piu' complesse, non possono essere scritte allocando la memoria manualmente, senno' si finisce di scrivere codice in 2 anni invece che in 6 mesi!).

[^-fidel-^]

Originariamente inviato da fek

Prova, prendi un qualunque algoritmo in C++ e prova a scriverlo piu' velocemente in asm. Poi postami il codice C++ e la tua versione asm che controllo

Ci provo, e ti mando tutto. magari pero' meglio se mi dici che algoritmo devo usare per questo test!
Esattamente un anno e mezzo fa la prova l'ho gia' fatta, e quello in asm risultava piu' rapido. Sicuramente ora lo stesso algoritmo andra' in modo identico sia fatto in C che in asm, vista la potenza acquisita dai PC in un anno e mezzo (roba che quelle 100 istruzioni in piu' ovviamente non vedi neanche che ci sono...). Magari ora le cose non stanno piu' cosi', e quindi scrivere in Asm e' perfettamente inutile (per quanto riguarda l'ottimizzazione intendo, perche' come anche hai detto tu prima per alcune cose va ancora usato necessariamente se si vuole risparmiare tempo). Sicuramente provero'
Cmq poi stiamo parlando di C/C++, che e' il miglior compilatore, per come genera il codice eseguibile. Ma credi che tutti usano il C/C++? Per quanto riguarda il SO, sicuramente si', ma poi bisogna vedere COME si programma in C. Per le altre apps invece... Vedo molti usare ancora Visual Basic Per grosse apps...
Comunque ribadisco, a prescindere se asm possa rendere piu' efficiente un programma, il modo migliore per creare un programma efficiente e' saper scrivere bene il codice (e non tutti sono preparati come te purtroppo).

[fek]

Originariamente inviato da ^-fidel-^

Emh puoi essere piu' chiaro? Il discorso mi interessa particolarmente

L'idea di un task real time (per un'applicazione mission critical) e' quella di garantire che il suo tempo di esecuzione sia minore di un tempo X. Immagina un software che gestisce l'ABS: se un task calcola che da qui all'impatto passeranno 0.5s e fa partire il task che agisce sui freni, il task deve garantire di finire entro 0.5s, altrimenti la macchina si schianta
Allo scheduler non interessa che il task finisca in 0.4s o in 0.000001s, gli interessa che finisca prima di 0.5s. Ovvero, non gli interessa quanto sia ottimizzato, gli interessa che garantisca il tempo di esecuzione. Se durante l'esecuzione del task entra un GC asincrono che magari impiega un secondo, la macchina si schianta

Ecco perche' i GC asincroni senza garanzie non sono adatti ad applicazioni real time. Nota che ne' Linux ne' Windows ti garantiscono che nessun interrupt venga lanciato e gestito e non ti garantiscono i tempi di esecuzione degl'handler: sia Linux sia Windows possono teoricamente prendersi tutta la CPU per un tempo indefinito.

Il software mission critical e real time non devono essere necessariamente ottimizzati, devono essere "precisi".

Si lo so, ma evidentemente ho usato in modo errato la parola "efficienza". Parlavo della rapidita' dell'esecuzione di un processo in media, poi e' normale che alcuni modelli vadano meglio con una gestione di tipo garbage, soprattutto quando la quantita' di memoria presente sulla macchina non e' un problema. Parlavo semplicemente dei porgrammi usati comunemente, ma anche di molte apps mission critical (non riesco a farti nomi espliciti giacche' mi riferisco ad apps 'ad hoc' scritte per le aziende su richiesta, caso per caso. Convengo quindi quando parli di allocazione manuale come il sistema non assolutamente migliore: pero' nella media si'

Non lo e' neppure nella media. Diciamo che non lo e' quasi mai. In un modello di programmazione OOP si tende a fare molte allocazioni di piccole dimensioni e questo scenario e' proprio il caso patologico degl'algoritmi implementati nelle malloc, che vanno bene in scenari con poche allocazioni di grandi dimensioni e disalocazione in ordine inverso.

Di dubbi ne ho piu' di uno Per ora penso questo, ma sono sicuro che i metodi automatici saranno non tra molto tempo davvero efficienti (e si studia proprio questo, dal momento che le apps, sempre piu' complesse, non possono essere scritte allocando la memoria manualmente, senno' si finisce di scrivere codice in 2 anni invece che in 6 mesi!).

E' vero l'esatto contrario. Ho appena finito di lavorare su un'applicazione piuttosto complessa (alcuni milioni di righe di codice), con allocazione totalmente manuale. I bug piu' frequenti erano, in ordine:

- doppie deallocazioni
- memory scribbler
- memory leak

E se mi dici ancora che le applicazioni complesse hanno bisogno di allocazione manuale altrimenti ci vuole piu' tempo mi arrabbio, perche' le notti a cercare le doppie deallocazioni le passavo io

[fek]

Originariamente inviato da ^-fidel-^

Ci provo, e ti mando tutto. magari pero' meglio se mi dici che algoritmo devo usare per questo test!

Un loop di skinning ad una bone

Prendi un numero di vertici (posizione, normale, texture coordinate, indice nelle bone) in ingresso, un vettore di matrici e trasformi ogni vertice per la matriche indicata dal suo indice nelle bone. Sono 20 righe di codice in C++, divertiti

[^-fidel-^]

Ah un'ultima cosa sul garbage collection:

(piccola nota da un manuale .NET):
"Una cosa da ricordare però è che un'oggetto deputato alla distruzione non lo è immediatamente ma soltanto quando il garbage collector viene attivato ed inizia la ricerca di oggetti non utilizzati.
Quando si crea un nuovo oggetto ricordarsi sempre di implementare il metodo Dispose() per la distruzione delle risorse inutili."

Ergo, per rendere il garbage collection davvero efficiente (e far funzionare bene il garbage collector della piattaforma) bisogna comunque saper programmare bene. Se io no implemento il metodo Dispose() il mio programma funzionera', ma intanto utilizzera' male la memoria, addirittura peggio do come il garbage collector puo' fare se usato bene!

Sicuramente tu queste cose le sai gia', ma bisogna vedere in quanti lo sanno. E' una questione di metodo, e sicuramente non bisogna improvvisarsi programmatori: mica poi sono cose dell'altro mondo, pero' un po' di studio per chi si reputa un programmatore (e magari si e' limitato a leggere un paio di manuali rapidi) ci vorrebbe

[fek]

Originariamente inviato da ^-fidel-^

Ah un'ultima cosa sul garbage collection:

(piccola nota da un manuale .NET):
"Una cosa da ricordare però è che un'oggetto deputato alla distruzione non lo è immediatamente ma soltanto quando il garbage collector viene attivato ed inizia la ricerca di oggetti non utilizzati.
Quando si crea un nuovo oggetto ricordarsi sempre di implementare il metodo Dispose() per la distruzione delle risorse inutili."

Ergo, per rendere il garbage collection davvero efficiente (e far funzionare bene il garbage collector della piattaforma) bisogna comunque saper programmare bene. Se io no implemento il metodo Dispose() il mio programma funzionera', ma intanto utilizzera' male la memoria, addirittura peggio do come il garbage collector puo' fare se usato bene!

Sicuramente tu queste cose le sai gia', ma bisogna vedere in quanti lo sanno. E' una questione di metodo, e sicuramente non bisogna improvvisarsi programmatori: mica poi sono cose dell'altro mondo, pero' un po' di studio per chi si reputa un programmatore (e magari si e' limitato a leggere un paio di manuali rapidi) ci vorrebbe

E' verissimo che il GC non e' la panacea di tutti i mali
Ad esempio contrariamente a quanto si pensa non risolve i memory leak.

Qui sta dicendo che il metodo Dispose va implementato se l'oggetto mantiene un reference a risorse che devono essere distrutte derministicamente (oggetti non managed, connessioni, file, etc etc). Per quanto riguarda la memoria, invece, anche senza Dispose questa viene rilasciata dal GC quando l'oggetto non ha piu' reference associate.

[^-fidel-^]

Originariamente inviato da fek

L'idea di un task real time (per un'applicazione mission critical) e' quella di garantire che il suo tempo di esecuzione sia minore di un tempo X. Immagina un software che gestisce l'ABS: se un task calcola che da qui all'impatto passeranno 0.5s e fa partire il task che agisce sui freni, il task deve garantire di finire entro 0.5s, altrimenti la macchina si schianta
Allo scheduler non interessa che il task finisca in 0.4s o in 0.000001s, gli interessa che finisca prima di 0.5s. Ovvero, non gli interessa quanto sia ottimizzato, gli interessa che garantisca il tempo di esecuzione. Se durante l'esecuzione del task entra un GC asincrono che magari impiega un secondo, la macchina si schianta

Ecco perche' i GC asincroni senza garanzie non sono adatti ad applicazioni real time. Nota che ne' Linux ne' Windows ti garantiscono che nessun interrupt venga lanciato e gestito e non ti garantiscono i tempi di esecuzione degl'handler: sia Linux sia Windows possono teoricamente prendersi tutta la CPU per un tempo indefinito.

Il software mission critical e real time non devono essere necessariamente ottimizzati, devono essere "precisi".

Ecco, non consideravo un interrupt sul kernel... Si', un kernel non realtime ha questi rischi. Ora e' tutto chiaro.

Per tutto il resto che hai scritto: mi sa che hai frainteso. Che tu abia scritto un programma di milioni di righe di codice con allocazione manuale della memoria non fa che sottolineare quello che ho detto prima (e mi sa che ti sei contraddetto): al giorno d'oggi, allocare manualmente la memoria e' ancora normalmente piu' conveniente (e tu ne sei una prova ) mentre, in ambito OOP, data la complessita' dei programmi, puo' essere piu' semplice usare il garbage collector, anche se le prestazioni non saranno le stesse: pero' non perdi delle notti per correggere il tutto
Quindi dipende da come intendi la programmazione: continuo a dire che in media e' meglio il modo manuale: e' piu' complicato, ma i risultati sono normalmente migliori in termini di prestazioni. Il garbage collection e' invece piu' semplice, ma raramente garantisce una buona prestazione (se confrontata con l'allocazione manuale).

[^-fidel-^]

Si' quello che hai detto su Dispose() e' vero. Ah una domanda, ma lavori al Black&White studios?

[^-fidel-^]

Per fek:

Ah, approposito di sistemi realtime, leggiti questa:

http://www.linuxhelp.it/modules.php?...ticle&sid=3259

[fek]

Originariamente inviato da ^-fidel-^

Per tutto il resto che hai scritto: mi sa che hai frainteso. Che tu abia scritto un programma di milioni di righe di codice con allocazione manuale della memoria non fa che sottolineare quello che ho detto prima (e mi sa che ti sei contraddetto): al giorno d'oggi, allocare manualmente la memoria e' ancora normalmente piu' conveniente (e tu ne sei una prova )

E' l'esatto contrario ti dico, e' molto piu' conveniente non farlo in termini di tempi di sviluppo e anche di efficienza

Originariamente inviato da ^-fidel-^

Si' quello che hai detto su Dispose() e' vero. Ah una domanda, ma lavori al Black&White studios?

Non piu'.

[^-fidel-^]

Originariamente inviato da fek

E' l'esatto contrario ti dico, e' molto piu' conveniente non farlo in termini di tempi di sviluppo e anche di efficienza

Uhuh solo ora scopro che hai fatto la tesi con Montuschi il mio prof preferito senza dubbio!
Cmq ora capisco le tue posizioni (visto anche l'algoritmo di esempio che mi hai dato da implementare...): come 3D engineer e' normale non usare l'asm, con tutte le librerie grafiche che ci sono, e gli algoritmi 3d sono normalmente molto complessi. Nell'ambito 3D al giorno d'oggi l'asm e' praticamente inutile
Io invece mi occupo di reti, e li' l'asm mi e' tornato utile in molte occasioni (soprattutto nella gestione delle scede di rete), mentre il GC lo evito nella gestione dei buffer di comunicazione.... Sicuramente emerge questo: ogni ambiente di sviluppo ha le sue prerogative, e non c'e' metodo migliore per TUTTI gli ambiti di lavoro. Io ad esempio parlavo del non uso del GC come una buona scelta nella programmazione di rete (che e' un campo molto vasto, ma e' cmq una parte del mondo informatico).

Ciao