Newsgroup: it.comp.lang.visual-basic
Titolo: Visualbasic 6, compilatore e 2 processori

Salve a tutti!!!
Tra quanlche giorno avro' a disposizione un pc con 2 processori e volevo
sapere come si comporta VB6 con questo sistema... In particolare mi chiedo
se il compilatore quando crea l'exe lo fa ottimizzando l'utilizzo del
programma x questo tipo di configurazione... se fosse così vedrei dei
peggioramenti su un pc a 1 processore???
Per di + mi consigliate di installare VB6 su Win2000 pro, Win2000 server o
su un WinXP Pro???
Grazie!!!

 su un WinXP Pro???
Se supporta più processori XpPro.

 su un WinXP Pro???
Direi XP.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Se supporta più processori XpPro.
Sì, li supporta (max due)...


 mio di processori ne vede due... :-P
Ho verificato su alcuni miei server, sia con win2K che con Nt4 il sistema
vede l'esatto numero dei processori, forse mi sono confuso con qualcosa che
manco io so cosa...
Boh...?

 anche in caso di una sola CPU con Hyper-Threading)
Cos'è l'hyper-threading?
Ciao

 No, non c'č alcun tipo di ottimizzazione per i sistemi multiprocessore.
Dato che probabilmente avrň lo stesso problema, si avrebbero 
miglioramenti se si riuscisse in qualche modo a sfruttare il 
multi-threading?
Se no, perchč?
Ciao

> No, non c'č alcun tipo di ottimizzazione per i sistemi multiprocessore.
E con .NET?
Ciao


E' una tecnologia di intel che permette di far vedere un singolo processore
come se fosse una coppia processori... con un aumento di prestazioni in caso
di multitasking... se non erro...

 Direi XP.
Perche XP? Io in genere consiglio sempre win2k... cos'ha in piů XP di 2k?

 Boh...?
Non è che hai visto il grafico dell'utilizzo CPU del Task Manager senza
che fosse attivata l'opzione "mostra un grafico per CPU"?


 di multitasking... se non erro...
Multithreading non multitasking...
Si tratta di un processore che č in grado di eseguire parallelamente due
thread di uno stesso processo.
Qunidi č molto piů efficiente di un processore normale, ma meno di una
macchina dual (che č in grado di eseguire parallelamente un processo per CPU).


 multi-threading?
Direi che non serve, perché in una macchina multi hai la possibilità di
un "vero" multitasking. Quindi che la tua applicazione sia mono o multi
thread è indifferente, perché ci sono altri processi che hanno da
spartirsi il tempo della CPU...


 E con .NET?
Direi che non esiste alcuna ottimizzazione per nessun linguaggio, perché
è il SO che si occupa di tutto in modo trasparente alle applicazioni.


 Perche XP? Io in genere consiglio sempre win2k... cos'ha in più XP di 2k?
Si tratta sempre di un SO più recente ed aggiornato, poi... io non l'ho
praticamente neppure visto...


 spartirsi il tempo della CPU...
Quindi, se ho ben capito, i processori si spartiscono i processi, e non i
thread.
Dunque il multithread non serve a niente, ma occorrerebbe spezzare il
processo in più exe (anche activex?)
Giusto?
Ciao
--
Math Parser, VB.Framework : 
http://www.neodatatype.net
Sito Comune               : 
http://www.it-lang-vb.net

 processo in più exe (anche activex?)
I processori si spartiscono processi e thread, ma è il SO che gestisce
il tutto.
Tu considera che *non* hai mai una sola applicazione in esecuzione,
quindi al SO non mancano processi e thread da spartire tra i processori...
Spezzare il processo in più exe mi pare inutile, perché è facile che ad
un esecuzione parallela di più parti della stessa applicazione
corrisponda un minore tempo CPU, in favore degli altri processi che
debbono comunque girare. 


 il tutto.
Mmmm, scusa se insisto, ma mi interessa la cosa.
Tu mi stai dicendo che non c'è modo di sapere se un PC con due processori
sarà effettivamente più veloce di uno con un singolo processore?
Il mio problema è che ad oggi un nostro programma gira ciucciandosi un
mucchio di risorse (e quando dico "mucchio" intendo un *grosso* mucchio:
pensa solo che esegue un calcolo per la pianificazione della produzione di
un'azienda la notte, prendendo lui da solo qualcosa come 8-13 ore girando a
menetta.)
Adesso, si pensava di spezzare la procedura in qualche modo per sfruttare il
doppio processore e farla terminare più rapidamente.
Adesso, teoricamente parlando (lasciando da parte VB) sarebbe auspicabile un
miglioramento delle prestazioni spezzando la procedura su più processi o
thread o che altro (si può far lavorare VB su un cluster di PC? :))


 thread o che altro (si può far lavorare VB su un cluster di PC? :))
Così a prima vista è impossibile stabilirlo.
Per prima cosa, se non l'avete già fatto, occorre capire quale sia il
collo di bottiglia. Poi, una volta trovato il codice incriminato,
valutare cosa fare per ottimizzarlo.
Non è detto che sia possibile fare in modo di suddividere questo codice
su più thread o più processi, e non è neppure detto che questo riesca ad
aumentare le prestazioni in modo considerevole, perché è lo scheduler
del SO a decidere il codice da eseguire e quando farlo (puoi intervenire
solo aumentandone la priorità). Bisogna procedere per tentativi...
Potrebbe anche essere necessario riscrivere parte del codice in un
linguaggio più performante, e magari riscriverlo in modo adeguato.
Noi abbiamo avuto un problema simile, e dopo un po' di tentativi siamo,
con la sola ottimizzazione del codice, arrivati a tempi mille volte
inferiori...
Per quanto riguarda il cluster di PC, per velocizzare calcoli pesanti
bisogna utilizzare un cluster di classe Beowulf, cosa che *non* è
trasparente all'applicazione, pertanto il codice andrebbe in parte
riscritto per utilizzare le librerie necessarie. Il che può essere
un'ottima idea per aumentare le prestazioni, ma è sicuramente complesso
e non immediato.


 e non immediato.
Ok, lasciamo stare questa alternativa :)
Ciao

 per CPU).
Grazie maestro! :)

 l'ho praticamente neppure visto...
Preferisco avere un Os già consolidato (in quanto a ad aggiornamenti w2k è
giunto al SP4 mentre XP latita al SP1a) che uno impiccione come XP che
peraltro spreca risorse a manetta per gestire la grafica puffosa! ;-)

 Questo si avvantaggerebbe dei due processori o no?
[SNIP]
In linea di massima no se ProcA e ProcB girano nello stesso thread, B non
parte fintanto che A non rientra e tutto il lavoro dovrebbe essere comunque
a carico di 1 CPU.
Altrimenti si, sempre in linea di principio, perche' i due thread possono
correre parallelamente, e mentre su monoprocessore il tempo assegnato ai 2
t. e' sempre e comunque a carico di 1 CPU (quindi le risorse in piu' per uno
vanno a scapito dell'altro) su multiprocessore i 2 t. dovrebbero essere
ripartiti su CPU differenti e potenzialmente potrebbero usare entrambi il
100% del processore
Di piu', nin zo'
Ciao
-- 
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 Riscrivendo in un altro linguaggio?
No, sempre lo stesso linguaggio (C++). Abbiamo solo riscritto in modo
più efficiente alcune parti di codice (principalmente un maggior
utilizzo di puntatori).


 peraltro spreca risorse a manetta per gestire la grafica puffosa! ;-)
Sì, sono d'accordo. Però XP è *più* multiutente di Win2000... è questo è 
un vantaggio non da poco.


 possono invece essere eseguiti parallelamente.
Ooooh, finalmente mi ritrovo in quello che sapevo io :)
Ti ringrazio ancora.
Ciao