Newsgroup: it.comp.programmare
Titolo: Simulazione "velocizzata" programma "time-dependent"

Ciao NG,
 
Scusate il titolo demenziale ma ho un problema che non so
nemmeno come si chiama.
 
Devo mettere in piedi un programma delicato (mi pare si
chiamino "life support", si tratta della modellazione del
trasporto di un farmaco in circolo) che ha parecchi thread
schedulati a passi parecchio diversi. Ovviamente il flusso
del programma a un certo istante "t" dipende da tutti i
calcoli fatti prima e i risultati dipendono dalla
schedulazione.
 
Per dare un'idea del mio problema, uno dei tanti thread,
contiene una sequenza di calcoli separati da un intervallo
fisso di tempo. La durata dei calcoli può variare di
tanto, da zero a qualche decina di secondi. Finito il
calcolo si aspetta questo intervallo fisso e si
ricomincia. E thread simili ce ne sono diversi altri, con
compiti differenti e schedulazioni dal decimo di secondo a
5 min.
 
Problemi:
 
1) Questo programma deve essere sviluppato da me su PC ma
poi girerà su un processore a 32 bit del tipo di quelli
che sono sugli smartphone e qui già non so se posso
contare sul C++, multithreading e supporto float, oppure
devo fare macchine a stati. Molto ma molto ma molto
grossomodo cosa posso aspettarmi di avere tra queste cose
(C++, multithreadin e float) e quali no?
 
2) Come testare una cosa simile: trattandosi di ore di
funzionamento, posso mettere una pietra sopra alle
possibilità del test accurato che necessiterebbe a meno
che questo tipo di problema non sia abbastanza comune da
aver indotto a creare soluzioni. Non so se ci sono
software appositi. Un debugger non mi pare quel che mi
serve; a me servirebbe al contrario una specie di
acceleratore globale che però mi preservi coerenza e
valori dei timers.
 
Nel caso che per il punto 2 non esista niente, come si fa?
Si cerca di scrivere fin dall'inizio in modo da poter fare
qualche cosa, come ad esempio wrappare le funzioni del
timer e fargli restituire valori reali in modo release o
fittizi in modo debug? Ma a questo punto come faccio a
conservare la coerenza di tutto? Non posso sapere a che
istante partirà il certo blocco di istruzioni.
 
grazie di ogni aiuto
 
Apx.
 
-- 
Computer multitasking: oggetto che
può essere messo fuori uso da più
persone contemporaneamente.
 

 [...]
 
Per il punto 2 non so aiutarti, dovrei conoscere più dettagli.
Comunque sembra una cosa abbastanza complessa.
 
 
Ciao  Manlio


 
Unit-testing sulle funzioni di calcolo, e alla fine qualche giorno a
girare da solo con tutto attivo in un ambiente controllato -
considerando che "qualche giorno" sul tempo totale di sviluppo sia un
tempo accettabile.
 
Ciao!

 Ciao NG,
 
 
grazie delle risposte! Le vedo duretta ma spero di
combinare qualcosa :D


Il 16/12/2011 12:29, Archaeopteryx ha scritto:
 > Ciao NG,
 >
 > Scusate il titolo demenziale ma ho un problema che non so
 > nemmeno come si chiama.
 >
 > Devo mettere in piedi un programma delicato (mi pare si
 > chiamino "life support", si tratta della modellazione del
 > trasporto di un farmaco in circolo) che ha parecchi thread
 > schedulati a passi parecchio diversi. Ovviamente il flusso
 > del programma a un certo istante "t" dipende da tutti i
 > calcoli fatti prima e i risultati dipendono dalla
 > schedulazione.
 >
 > Per dare un'idea del mio problema, uno dei tanti thread,
 > contiene una sequenza di calcoli separati da un intervallo
 > fisso di tempo. La durata dei calcoli può variare di
 > tanto, da zero a qualche decina di secondi. Finito il
 > calcolo si aspetta questo intervallo fisso e si
 > ricomincia. E thread simili ce ne sono diversi altri, con
 > compiti differenti e schedulazioni dal decimo di secondo a
 > 5 min.
 
Non capisco il genere di software. Si tratta di un programma di 
simulazione o un programma di controllo? Nel primo caso non vedo la 
necessità di usare un timer; basta usare la tecnica della simulazione di 
eventi discreti, che elimina i tempi morti e la non-riproducibilita' che 
si ha con i timer. Vedi:
http://en.wikipedia.org/wiki/Discrete_event_simulation
 
Nel secondo caso, si tratta di un sistema real-time, che non dovrebbe 
basarsi solamente sui timer, ma dovrebbe avere input dall'esterno per 
sincronizzarsi con il mondo reale e non scostarsene troppo.
 
 > 1) Questo programma deve essere sviluppato da me su PC ma
 > poi girerà su un processore a 32 bit del tipo di quelli
 > che sono sugli smartphone e qui già non so se posso
 > contare sul C++, multithreading e supporto float, oppure
 > devo fare macchine a stati. Molto ma molto ma molto
 > grossomodo cosa posso aspettarmi di avere tra queste cose
 > (C++, multithreadin e float) e quali no?
 
Prima di tutto dovresti appurare il tipo esatto di architettura target.
L'esistenza del compilatore C++ e il multithreading dipendono dal 
sistema operativo target, supponendo che ne vuoi usare uno.
Mi pare che i vecchi ARM non avevano unità floating-point, mentre da 
almeno 5 anni ce l'hanno tutti.
 
 > 2) Come testare una cosa simile
Un aspetto fondamentale del collaudo è la riproducibilità. Se il sistema 
da collaudare (SUT=system-under-test) si basa su eventi esterni, devi 
registrare tali eventi in un log, accompagnati da un timestamp, e poi un 
apposito programma deve risottoporre al SUT gli stessi eventi negli 
stessi istanti. Ma la cosa migliore è evitare comportamenti time-dependent.
 
-- 
 
Carlo Milanesi
http://carlomilanesi.wordpress.com/
 

 almeno 5 anni ce l'hanno tutti.
 
I nuovi core (ARM11, CortexA8-A9-A15 hanno l'unità FP integrata), su 
architetture ARM9 (ci sono anche prodotti dell'anno scorso!) non è 
standard e non molti produttori la includono, per ragioni di costo.
In generale è un punto da verificare (anche perchè il compilatore 
potrebbe supportare l'instruction set ARMv4 o ARMv5 e quindi non usare 
comunque l'unità FP).
In generale mi sembra assurda l'idea di sviluppare il software su PC 
senza conoscere l'architettura su cui dovrà girare. A maggior ragione 
se, come pare, ci sono constraints sui tempi di esecuzione.
 

 constraints sui tempi di esecuzione.
 
 
Ovviamente lo so; ma c'è un fatto ovvero che l'hardware su
cui dovrà girare cambierà con ogni probabilità nel corso
del tempo. Per questo ho previsto una struttura abbastanza
modulare in modo da garantire un nucleo minimo che occupi
poche risorse (già adesso l'algoritmo, pur diversamente
implementato, gira su un vecchio ARM con 128 MB e 7 MHz di
clock), e che poi possa essere espanso.
 
Volevo solo capire se posso riscrivere questo nucleo
contando su qualche comodità. Usare come ho fatto fin qui
macchine a stati e formulare tutto in numeri interi mi ha
fatto impazzire e ha preso il 70% dei miei sforzi. Se
posso scrivere in modo abbastanza "astratto" contando sul
C++ (usato ovviamente in modo soft), il supporto float e
il multithreading, ecco, già sarebbe molto. Poi certo, se
l'algoritmo fosse pesantissimo occorrerebbe conservare
l'implementazione con interi, ottimizzarlo per
l'hardware, eccetera. Verissimo. Adesso sto solo
guardandomi intorno, non mi sogno di iniziare a scrivere a
testa bassa.
 
ciao!


On Dec 21, 10:13 am, Archaeopteryx

Ti capisco benissimo ma sai, quando si lavora con i micro si ragiona
al contrario: non "se scrivo così girerà su quest'hardware?" ma "con
questo hardware sotto cosa posso scrivere?" :-)
E' per questo che ti hanno detto un po' tutti di informarti
addirittura prima di pensarci, altrimenti sono tutti sforzi inutili!
Ciao!

 inutili!
 
beh, ovviamente su questo e altro ne sapete tanto più di
me, e resisterò alla tentazione almeno finché non saprò
cosa hanno deciso nell'altra stanza :D
 
con l'occasione auguri a tutti per il nuovo anno!
 
Apx.