Newsgroup: it.comp.ia
Titolo: Java e BackPropagation

Ciao a tutti , domanda :
l'utilizzo del MultiThreading ( applicato alla retropropagazione 
dell'errorre di opgni campione ) di Java puo' velocizzare l'apprendimento di
un percetrone multistrato basato su Backpropagation ?
grazie ...
( devo velocizzarlo se no' ci mette una vita !!!! e' per la tesi ..)
ciao a tutti.

( devo velocizzarlo se no' ci mette una vita !!!! e' per la tesi ..)
devi proprio usare java? E' lento di natura a causa dell'interprete.
Forse avresti piů prestazioni se programmassi il tutto con C...
Ciao!
Davide
-- 
Volontario Anti-Troll (TM) 
SecurFaq: 
http://members.nbci.com/gouldukat/
DocTrolls: 
http://it.geocities.com/roccopapaleo/faq/italiano/Troll.html
Netiquette: 
http://www.inferentia.it/netiquette/dis.html

vallo a spiegare al mio prof ....
sto facendo la tesi ( che coinvolge piu' insegnanti ) e mi sono ritrovato 
al punto che non sapevo su che piattaforma devevo sviluppare , cosi' ho 
detto "Java"  ed eccomi qua' ....
 
la rete non e' un MLP secco , ma una rete Neuro-Fuzzy ....
la BackPropagtion e' sempre quella , cambia l'utilizzo dei neuroni e le 
funzioni di trasferimento, sto cercando di fargli apprendere due funzioni 
simultaneamente, ma e' di un lento che fa paura' , 24h per un'approssimazione
che fa schifo ....sigh una cosa veramente brutta ..
pensavo cosi' al multithreading .....

 ( devo velocizzarlo se no' ci mette una vita !!!! e' per la tesi ..)
Puoi provare a cambiare linguaggio!!!
-- 
C++U,
  Gio "FrOYd" Caturano
 
http://www.dronez.com

 Puoi provare a cambiare linguaggio!!!
prova anche a vedere su it.comp.java che ti dicono. 
Ciao R.
-- 
Inviato il mar 22 mag 2001 17:18:57 CEST da 
fw01-e31.inferentia.net
[217.29.160.1]
http://www.neuromante.net/

 prova anche a vedere su it.comp.java che ti dicono. 
Non mi interessa. Certamente e' un dato di fatto che un buon compilatore 
C++ produca codice piu' veloce di qualsiasi compilatore JIT.
E JIT non e' standard.
Ci sono decine di ottimi motivi per usare Java in un progetto, ma 
nessuno di questi include la superiorita' di performance rispetto a un 
linguaggio compilato.


 Non mi interessa. [cut]
Uh?! Mica tu. Trattasi di chiosa non di polemica.
Ciao R.
-- 
Inviato il mar 22 mag 2001 18:04:29 CEST da 
fw01-e31.inferentia.net
[217.29.160.1]
http://www.neuromante.net/

 Uh?! Mica tu. Trattasi di chiosa non di polemica.
Avevi risposto al _mio_ messaggio! ;)


 Avevi risposto al _mio_ messaggio! ;)
perche' trattavasi di chiosa ;-)
Ciao R.
-- 
Inviato il mar 22 mag 2001 19:38:33 CEST da 
fw01-e31.inferentia.net
[217.29.160.1]
http://www.neuromante.net/

 wrote in message
9ee86p$c39$1...@g.l.neuromante.dyndns.org...

dai ho dato origine ad un bel thread, no !!!

un percetrone multistrato basato su Backpropagation ?
No, solo se tu avessi un sistema multiprocessore.
Augusto Pucci ( 
http://www.prospektiva.it/webmaster/
 )
Webmaster di Prospektiva On-line
http://www.prospektiva.it
Webmaster di SIPO Toscana
http://sipotoscana.supereva.it

 No, solo se tu avessi un sistema multiprocessore.
E se la JVM gestisce più processori.
(ignoranza mia, lo ammetto)
--
Alessandro Monti

 (ignoranza mia, lo ammetto)
Mmmm... non credo. Normalmente i thread dovrebbero essere gestiti dal 
S.O. Cioe', l'implementazione della JVM _deve_ passare la gestione dei 
thread al S.O., se questo li supporta.


thread al S.O., se questo li supporta.
Esattamente, in caso di processori multipli succede proprio questo la
JVM delega all'SO la gestione dei processori e la divisione del lavoro
fra essi.


 fra essi.
Non ho detto esattamente questo e non credo sia cosi'.
Ecco come mi sembra stiano le cose:
La JVM delega la gestione dei thread al S.O. in ogni caso.
Se ci sono processori multipli, e se l'affinita' del processo e' tale da 
permetterne l'utilizzo, il S.O. li sfruttera'. Se non ci sono, sara' il 
S.O. a gestire il contest swapping per i vari thread.
L'eventuale gestione del multithreading interna alla JVM puo' esserci 
solo nel caso in cui il S.O. _non_ supporti questa caratteristica.
Quindi:
Se il S.O. supporta multithreading, questi saranno gestiti dal S.O. 
indipendentemente dal numero di processori.
Resta ovviamente vero il fatto che, se il processore e' singolo, il 
multithreading non comporta aumenti di velocita', ma, anzi, rallenta il 
tutto.


tutto.
Esatto, tra l'altro il rallentamento e' anche notevole xche' il
sistema deve swappare da un thread all'altro con tempi morti annessi e
connessi di continuo.. comunque se per esempio vuoi avere una
interfaccia grafica funzionante e responsive anche mentre si stanno
eseguendo calocli complessi l'unica possibilita' resta naturalemnte
quella di far vaiggiare i calcoli su un thread separato (ad esempio
questo ti succede su un programma di dama/scacchi)


 questo ti succede su un programma di dama/scacchi)
Non e' proprio l'unica possibilita', in realta', ma e' il modo piu' 
comodo, sicuramente.
