Precisione registri FPR14-31 su PowerPC 970FX

[repne scasb]

[KVL]

Purtroppo non posso aiutarti, non ho un G5, e sto preparando l'rsame di Calcolo Numerico, quindi so appena qualcosa di algritmi. Mi sembra strano che una CPU così avanzata propaghi l'errore in maniera così significativa!

Però dal poco che so, il G5 dovrebbe essere "più RISC" (passami quasta orrend affermazione) delle CPU x86.

Se il tuo calcolo è strettamente ricorsivo, non potresti "dividere" il calcolo su più matrici, in modo da poter utilizzare registri più corti, e di conseguenza sfruttare il G5?

Probabilmente ho detto una caXXata grossa come il Cray X1 :D :D

KvL

[repne scasb]

[KVL]

I dati che devi elaborare sono di tipo seriale oppure è possibile scomporli in pacchetti più piccoli? altrimenti potresti così sfruttare il G5!

[repne scasb]

[Banus]

Non immaginavo questa differenza fra PowerPC e x86... pensavo che in genere si memorizzassero solo i 64 bit degli operandi, senza bit aggiuntivi..

Se il range dei valori possibili è limitato (come spesso accade) si potrebbe sacrificare parte dell'esponente in favore della mantissa. Almeno in questo modo interpreto il punto 3.

Volendo si potrebbero ripartire gli operandi su più di un registro emulando le operazioni necessarie a precisione maggiore, ad esempio addizioni e moltiplicazioni. Viene da sé che in questo modo le prestazioni crollano inevitabilmente.

Se il limite è hardware (cioè FPU con unità più piccole) non vedo altri modi per avere precisione e velocità di esecuzione allo stesso tempo...

[repne scasb]

[alexmaz]

Puoi provare qui http://lists.apple.com/mailman/listinfo

ci sono delle mailing list, di cui una è sull'uso di Fortran su OSX, quindi così a occhio ci sarà sicuramente qualcuno che ha bisogno di calcoli a precisione elevata.

Sinceramente mi pare strano che non ci sia la possibilità di avere una precisione superiore ai 64 bit, ma in effetti da una rapida occhiata ai manuali IBM si direbbe proprio di no, bah

[alexmaz]

Se no prova a chiedere a questi, che con i G5 ci hanno fatto un supercomputer:

http://209.157.64.200/focus/f-news/1044732/posts

[repne scasb]

[alexmaz]

Originariamente inviato da repne scasb




Il problema non e' di avere un elevata precisione - come/quanto -(posso raggiungere un elevata precisione anche tramite un Commodore 64), ma avere un elevata precisione in un "tempo macchina" accettabile. Cio' si puo' ottenere solo se la FPU "nativamente" dispone di una precisione sufficiente, altrimenti sono necessarie piu' operazioni native per raggiungere la precisione che si vuole ottenere. Posso dire che sarebbe utile entrare in contatto, non con chi programma in Fortran in OSX, ma con chi ha sviluppato il compilatore Fortran per OSX su architettura PowerPC.



Ho "spulciato" tutti i manuali ufficiali senza che trapelasse la possibilita' di avere una precisione FPU superiore ai 64-bit. O e' non documentata, o e' un curioso limite hardware che di fatto "relega" la CPU IBM PowerPC 970, solo ad ambiti scientifici non "critici" (a meno di non pagare in termini di tempo macchina). Sto cominciando a rivalutare/riconsiderare il motivo che spinse Intel ad utilizzare 82-bit di precisione per la CPU Itanium.

Si si avevo capito. Comunque, molti di quelli che usano fortran lo usano per le prestazioni, vien da se che magari fra loro c'è qualcuno che ha le tue stesse esigenze ed ha usato l'assembly. Postare un messaggio sulla mailing list non ti costa nulla :)

Pare anche me un curioso limite hardware! Fosse solo riferito ai 970 potrebbe ancge starci, ma essendo i 970 dei Power4 mono core con l'aggiunta del sottosistema Altivec, il limite hardware è per forza presente anche nei Power4.
Prova a dare un'occhiata anche al sottosistema Altivec, ha registri a 128 bit, ma non so che tipi di operazioni permetta su questi registri.

[repne scasb]

[nix1]

Prova quì:

http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&group=comp.unix.aix

http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&group=comp.unix.solaris

http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&group=comp.os.linux.powerpc

Ciao Repne e ben venuta da queste parti

Ti consiglio vivamente di postare in quei tre forum, dove io personalmente ho avuto modo di conoscere sviluppatori IBM e SUN con competenze per me extraterrestri che più volte mi hanno tirato fuori dai guai quando neanche il supporto tecnico IBM e SUN sapeva più cosa inventarsi.

Proverò a darti qualche spunto nella speranza di poterti essere di aiuto visto che è la prima volta che ho l'0nore di vederti alle prese con un processore serie PowerPC 970

Personalmente supporto a livello sistemistico migliaia di sviluppatori e nessuno fino ad ora mi ha mai fatto notare nulla del genere, da quì il mio profondo rispetto per i processori di classe Powerpc e Spac

Matematicamente non sono in grado di spiegartelo ma secondo me la spiegazione al problema dovresti cercarla nella quantità di istruzioni che questo processore è in grado di compiere per ciclo di clock rispetto ad un processore X86 e di conseguenza il margine di errore rispetto al tuo algoritmo testato su X86 potrebbe aumentare.

Altro dettaglio ma secondo me da tenere MOLTO in considerazione è la differenza architetturale tra un PowerPC 970FX e una Power4
Che a detta di qualcuno il 970FX dovrebbe essere esattamente uno dei 4 singoli CORE di un Power4 senza la CACHE, ma senza togliere nulla a mamma Apple questo matematicamente ed economicamente non è possibile.

Quindi non escluderei un margine di errore ritenuto inrilevante su i Powr 970FX,

Ricordati dei 486

[alexmaz]

Originariamente inviato da nix1


Altro dettaglio ma secondo me da tenere MOLTO in considerazione è la differenza architetturale tra un PowerPC 970FX e una Power4
Che a detta di qualcuno il 970FX dovrebbe essere esattamente uno dei 4 singoli CORE di un Power4 senza la CACHE, ma senza togliere nulla a mamma Apple questo matematicamente ed economicamente non è possibile.

Quindi non escluderei un margine di errore ritenuto inrilevante su i Powr 970FX,

Ricordati dei 486

E invece il 970FX è un core Power4 (uno dei 2, perchè il Power4 è un processore dual core) con l'aggiunta dell'unità Altivec. Non è un segreto, basta fare una ricerca con google:

Annuncio di IBM:

http://www.ibm.com/news/it/2004/02/162.html

Articolo breve:

http://www.realworldtech.com/page.cfm?AID=RWT101502203725

in fondo alla prima pagina trovi esattamente quello che ho detto io qualche posto sopra.

Articolo lungo (troppo :D):

http://arstechnica.com/cpu/02q2/ppc970/ppc970-1.html

Il problema di repne scasb non ha cmq nulla a che vedere con questo: nei processori x86 di classe P6 e NetBurst (quindi dal Pentium Pro in poi) i registri della FPU sono "lunghi" 80 bit e permettono un tipo di dati chiamato Double Extended Precision con 15 bit di esponente e 64 bit di precisione, quindi una precisione a 64 bit reale, contro i 53 della double precision usando il registro come se fosse di soli 64 bit.
Tutto questo semplicemente nè il Power4 nè il 970FX lo fanno, perchè i registri della FPU (delle) FPU sono a 64 bit.
Che poi esista un modo per ottenere lo stesso risultato o le prestazioni risultanti alla fine siano simili perchè la fpu dei processori x86 non è poi così efficiente, questo non so dirlo :fagiano:

Cmq, per repne scasb, questi articoli potrebbero interessarti, parlano delle FPU di P4 in comparazione con G4e (stesso "limite" di 64 bit sui registri FPU del 970FX) e poi della FPU del 970FX, il primo affronta anche gli 80 bit x87, sinceramente non ho letto tutto vista l'ora :oink: :

http://arstechnica.com/articles/paedia/cpu/p4andg4e2.ars/1

http://arstechnica.com/cpu/03q1/ppc970/ppc970-5.html#fpu

Ciao :p

[repne scasb]

[repne scasb]

[cdimauro]

Non credo che troverai il modo di uscirtene fuori: ti sei appena scontrata con i limiti intrinseci dell'architettura Power/PowerPC, come di tanti altri processori (ma non sto a dirlo a te: lo sai già. :))

Questo è uno dei casi in cui la vecchia FPU x87, pur con tutti i suoi limiti, non trova eguali nelle architetture attuali (Itanium a parte, come giustamente riporti), visto che non solo può lavorare internamente con una precisione superiore ai 64 bit (totali), ma ha pure il vantaggio di poter conservare in memoria dati con questa precisione (il tipo Extended, a 80 bit. Ma anche questo lo sai già. :D).

Ci sono alcune architetture che implementano i long double a 128 bit, ma non è il caso né dei PPC né degli x87.

Se il tuo obiettivo rimane quello di utilizzare comunque l'architettura PPC, non ti resta che scriverti delle routine (o meglio macro) ad hoc per i G5: se ti bastano 64 bit per la mantissa, per semplificare il tutto potresti usare un registro per l'esponente e l'altro per la mantissa, altrimenti c'è da considerare anche la "piaga" del un/packing di esponente e/o mantissa dei dati.

Facci sapere qualcosa: l'argomento è molto interessante.

EDIT Come non detto: alcune cose le hai già dette... :)

[KVL]

Volete dirmi che un PPC è meno performante in calcoli complessi? allora dove hanno montato 1100 Xserve si sono bevuti il cervelletto?

Capisco che sia una rottura riscrivere il tutto, ma la soluzione di cdimauro è intelligente, quella dei due registri...

Cmq facci sapere perchè anche io sono ultra-interessato!

PS: peccato che a Fondamenti di informatica e a calcolo numerico insegnino SOLAMENTE le x86 pure, senza estensioni che nel corso degli anni hanno reso queste CPU al top del mercato! (mainstream)

[alexmaz]

Originariamente inviato da repne scasb


No, questo e' escluso. La possibilita' di rendere parallela l'esecuzione di un qualsiali opcode di una qualsiasi cpu, risiede nell'indipendenza degli opcode stessi (accetto smentite sensate)...

Quello che intendevo è che la (le, ne ha 2) FPU del 970FX è più veloce di quella dei processori x86, almeno stando a quegli articoli che ti ho elencato. Quindi magari, anche una soluzione che usi più istruzioni può avere performance superiori che su x86. Questa chiaramente è solo un'ipotesi.

Partendo dal presupposto che io e la matematica siamo nemici :D e che non ho idea di quale sia il tuo livello di preparazione e nemmeno so esattamente che tipo di calcoli tu debba fare, vorrei però fare un appunto:

programmare in assembly i moderni processori non è sempre sinonimo di performance; data la complessità dei processori, con pipeline profonde, tecnologia super scalari "spinte" ecc, spesso i compilatori producono codice più efficiente, che poi può ulteriormente essere migliorato a mano in alcune sue parti. Quindi valuta anche questo aspetto, sempre che tu non lo abbia gia fatto :p

[repne scasb]

[alexmaz]

Direi che ne sai enormemente più di me :)

Io il 970FX non l'avevo mai visto fino a 3 giorni fa, i miei consigli erano solo in linea teorica più qualche ricerca in posti noti dove si parla di cpu.
Direi che le hai provate tutte, se i registri sono a 64 bit (e lo sono) non c'è molto da fare per aumentare la precisione e mantenere le stesse prestazioni.

Una domanda: come sono le pretazioni rispetto a una cpu x86 di fascia alta, sia rispetto al codice più performante su 970FX che a quello meno performante?

[cdimauro]

Originariamente inviato da KVL
Volete dirmi che un PPC è meno performante in calcoli complessi? allora dove hanno montato 1100 Xserve si sono bevuti il cervelletto?

Capisco che sia una rottura riscrivere il tutto, ma la soluzione di cdimauro è intelligente, quella dei due registri...

Cmq facci sapere perchè anche io sono ultra-interessato!

PS: peccato che a Fondamenti di informatica e a calcolo numerico insegnino SOLAMENTE le x86 pure, senza estensioni che nel corso degli anni hanno reso queste CPU al top del mercato! (mainstream)
Forse non hai capito bene: il problema FONDAMENTALE è la PRECISIONE DEI CALCOLI. In subordine c'è la velocità.

[cdimauro]

Originariamente inviato da repne scasb
Sto vagliando varie soluzioni ma quella a due registri FPU non e' ottimale. La routine e' troppo lenta.
Infatti la mia idea era di usare due registri a 64 bit interi, con operazioni intere, per "emulare" le operazioni FP a precisione più elevata di quanto disponibile nativamente coi PowerPC.

[repne scasb]

[repne scasb]

[alexmaz]

Veramente interessante, grazie :)

[Criceto]

Questo forse ti può interessare...
http://www.apple.com/acg/pdf/oct3a.pdf

E qui puoi trovare un altro articolo simile:
http://www.apple.com/acg/

e magari qualcuno a cui chiedere...

[repne scasb]

[Criceto]

Originariamente inviato da repne scasb
Ossia il problema e' sempre quello: vorrei avere una precisione ad almeno 80-bit pagando una penale minima in termini di prestazioni. Tale libreria e' interessante, ma inadatta al mio scopo.

Avevo appena modificato il messaggio precedente per aggiungere il link all'Advanced Comuping Group di Apple che ha scritto quell'algoritmo, anche perchè ne è presente un altro a precisione arbitraria (credo).

Comunque credo che più di così non puoi fare. Se vuoi avere una precisione superiore ai 64bit su PowerPC devi usare qualcosa del genere.

[cdimauro]

Originariamente inviato da repne scasb
Questo cose non si fanno piu' dai tempi del "fractint"; un emulazione completamente "intera" a 128-bit o 80-bit senza l'aiuto dell'unita' FPU, rischierebbe di essere svariati ordini di grandezza piu' lenta di un modello a 128-bit completamente FPU.
Non so: mi sembra che la soluzione da me prospettata (esponente e mantissa ognuno in un registro intero a 64 bit) potrebbe rivelarsi meno lenta del previsto, con degli opportuni accorgimenti (in particolare, lavorando in assembly, "miscelando" opportunamente le istruzioni in modo da "mitigare" la dipendenza dei risultati).

Comunque data la tua esperienza sono sicuro che avrai già fatto le tue prove: se dici così non c'è dubbio che si tratti della soluzione più lenta.
Forse ho comunque trovato una soluzione al problema. E' una soluzione "esotica" (come nel mio stile).
Su questo non ci sono dubbi. :) Per questo è sempre un piacere leggere i tuoi messaggi...
In sostanza, l'IBM PowerPC 970FX e' in grado di utilizzare 64-bit per l'FPU in modalita' non IEEE-754 (e' possibile manipolare le dimmensioni dell'esponente e della mantissa); l'idea e' questa:

1) Riduzione dell'esponente a 0 bit, in questo modo i 64 bit verrebero utilizzati 1 per il segno e 63 per la mantissa.
2) L'esponente risiede in uno dei GPRx (registri interi).

In sostanza e' un modello misto, mantissa in FPU, esponente in interi. A "naso" direi che e' veloce.
E' simile a quello che avevo proposto, anche se usando interamente registri interi a 64 bit. Ma in questo caso alcuni problemi dovrebbero essere comuni, o mi sbaglio?

Avendo gli esponenti in due registri, fare la somma, la moltiplicazione, ecc. comporta comunque un loro "confronto" (o differenza, per meglio dire ;)), scalare opportunamente le mantisse, procedere poi con l'operazione, e infine con al normalizzazione (dell'esponente del risultato).

Il vantaggio, sempre "a naso" :), della tua soluzione sarebbe quello di evitare lo "scaling" del risultato finale a 128 bit per farlo "rientrare" nei 64 bit disponibili (sommando o moltiplicando le mantisse questo lavoro lo fa già ll'FPU), ma per contro lo scaling iniziale dei due numeri dovrebbe forse essere più oneroso, no?

Questi, per lo meno, sono i dubbi che mi vengono così, sul momento... :p

Dimenticavo: un altro vantaggio del tuo sistema è che può funzionare anche su un PowerPC a 32 bit (G3, G4), usando un registro a 32 bit per l'esponente (32 bit sono decisamente tanti in questo caso :D).

[cdimauro]

Originariamente inviato da repne scasb
Per quanto riguarda le prestazioni ho solo un dato, che si riferisce ad un PowerPC 970FX a 1.8Ghz e ad un Pentium 4(NW) a 3.2Ghz. Il PowerPC e' risultato essere il 22% (circa) piu' veloce, un valore impressionante.

C'e' da dire pero' che il Pentium 4 lavorava a 80-bit contro i 64 del PowerPC 970FX.
C'è anche da dire che l'FPU (x87) del P4 è veramente scarsa. ;)
Hai provato con un Athlon, o ancora meglio un Athlon64? La loro FPU è fully pipelined e inoltre l'utilissima istruzione FXCHG è "a costo zero" (mentre sui P4 è un'istruzione come un'altra, col suo tempo di esecuzione e introducendo una dipendenza nelle istruzioni successive, se si riferiscono agli stessi registri): cose non di poco conto in questo caso, e che fanno sicuramente la differenza...

[repne scasb]

[cdimauro]

Originariamente inviato da repne scasb
Ho un Athlon64 3500(WNC)+su Microstar K8N Neo2 Platinum.
WOW. Io ho un "misero" A64 2800+ (NC) su ASUS K8N... :cry:
A "naso" direi che il PowerPC 970FX a "parita' di clock" "parrebbe" piu' veloce
Non penso sia molta la differenza: entrambi possono eseguire due istruzioni FP a doppia precisione per ciclo di clock, anche se l'Athlon è limitato a una somma e una moltiplicazione (il G5 può eseguire indifferentemente due operazioni qualsiasi) e dall'architettura x87 che non è eccezionale.

Perché non fai qualche prova? I risultati del G5 a 1,8Ghz li hai già: ti basterebbe abbassare il moltiplicare della tua scheda madre per portare la CPU a 1,8Ghz... ;)
(c'e' sempre pero' il solito problema 64/80 bit).
Indubbiamente. E gli Athlon richiedono più tempo se hai scelto anche di leggere/scrivere valori a 80 bit in memoria, anziché a 64, ma non mi pare il tuo caso, se non ho capito male (usi la precisione a 80 bit solamente per i calcoli "interni").

[repne scasb]

[cdimauro]

Originariamente inviato da repne scasb
10% (circa) a favore dell'IBM PowerPC 970FX.
Non molto, come sospettavo (e usando la vecchia FPU x87 ;)).
C'e' pero da dire che l'intera routine utilizza solo 234Kb di RAM (dati+codice) (sta tutta nei processori (x86/PowerPC)).
Il caso ideale, insomma. La cache L2 dei G5 dovrebbe anche avere una latenza minore rispetto a quella degli Athlon64, se la memoria non m'inganna (ma influenzerebbe comunque di poco i risultati).
E' possibile che l'Athlon64 possa recuperare sensibilmente in caso di massiccio uso di RAM. Da alcuni test il sottosistema RAM (Apple G5/1.8Ghz) non "sembrerebbe" essere molto efficiente.
L'accesso alla RAM non è sincrono, come avviene normalmente nei PC (e in particolare con gli A64, che sono sempre in sincrono, anche con memorie diverse dalla PC3200), perché il bus che interfaccia PPC970 e chipset lavora a una certa velocità e le memorie a un'altra; poi c'è da considerare che il bus multiplexa dati e segnali di controllo, e che la banda totale è suddivisa per metà in lettura e l'altra metà in scrittura. Inoltre l'A64 ha il controller di memoria integrato.

Lavorando con la memoria, specie con matrice/vettori "sparsi", la situazione potrebbe ribaltarsi del tutto, in particolare se gli accessi alla ram risultano "sbilanciati" (molte più letture e meno scritture, o viceversa).

Una curiosità: per il problema che stai affrontando, hai a che fare con matrici molto grandi?

[repne scasb]

[cdimauro]

Originariamente inviato da repne scasb
Ed in effetti si ribalta. In questo stesso forum, avevo affrontato una disscussione nella sezione 'programmazione'
Immaginavo seguissi questa sezione. :) Io non la seguo perché per me sarebbe come ricadere nel "buco": ci perderei troppo tempo (ma la tentazione è molto forte, specialmente sapendo di poter leggere dei messaggi tuoi... :)).
riguardo il "crivello di Eratostene" (tale routine si distingueva per il massiccio uso di RAM).
Infatti. Una curiosità: l'avevi implementato usando i bit singolarmente per segnalare i numeri primi trovati, o un intero byte (come booleano)?
In quella stessa discussione avevo anche messo a disposizione il sorgente del crivello in assembly x86. Ho riscritto tale routine per PowerPC 970FX, e da un verifica ai registri di status/monitor del PowerPC 970FX mi pare di capire che la CPU passa "molta" parte del suo tempo ad "attendere" che il sottosistema cache abbia completato le operazioni di R/W sulla RAM,
Per la lettura in memoria sicuramente, ma mi risulta molto strano che lo faccia anche per la scrittura. Mah. Non so perché gli ingegneri di IBM abbiano adottato questa politica (forse per la coerenza dei dati nei sistemi multiprocessore? Boh)
tanto che un Pentium 4/3.2Ghz(NW) su Asus P4C800 (RAM in dual), e' il 75% (e oltre) piu' veloce di un IBM PowerPC 970FX.
Questo risulta veramente sbalorditivo: il P4 con gli interi non è che sia così efficiente/performante (non quanto gli Athlon, sicuramente). :eek:
No, piccole.
Capito. Non è possibile convertire l'algoritmo con qualche altro sistema iterativo che sia meno soggetto a problemi di instabilità / malcondizionamento? Adesso non ricordo molto bene, ma quando ho studiato Calcolo Numerico ho trovato molto materiale su quest'argomento. Magari posto in un'altra forma il problema potrebbe richiedere una precisione minore per i calcoli.
La butto lì: è soltanto un'idea.

[Banus]

Avevo pensato alla possibilità (non sapendo che algoritmo sta usando repne) di correggere gli errori di arrotondamento in modo da ridurne l'incidenza sul risultato finale.
Non ho mai avuto notizia di metodi simili ma con una ricerca ho trovato questo:
http://www.inria.fr/rrrt/rr-3967.html

e da una veloce occhiata pare sia in grado di recuperare almeno un paio di cifre significative. Negli esempi di applicazione c'è l'algoritmo di Newton.
Dovrebbe incidere poco sulle prestazioni perchè è sufficiente correggere solo alcuni risultati intermedi opportunamente scelti.

[repne scasb]

[repne scasb]

[cdimauro]

Originariamente inviato da repne scasb
Sei molto perspicace ed intuitivo, e secondo me e' uno "spreco" che non t'interessi della sezione "programmazione". In quella sezione ci sono persone assai dotate (secondo me), come per esempio lo stesso Banus che leggi poco sopra.
Grazie per i complimenti. :)

Ho visto, infatti. Purtroppo è la mancanza di tempo che mi frega. Poi, a essere sincero, mi basta dover programmare già a lavoro: per il resto preferisco dedicarmi a moglie, figlia o qualche passatempo... :)

Ti sembrerà strano, ma dopo una vita passata a programmare, sento quasi il bisogno di staccare la spina da questo mondo. Trovo più appagante impiegare il tempo pensando a come trovare una soluzione a un problema piuttosto che scriverne il codice. Mah. Sarà la vecchiaia... :)
Per curiosita' questo che segue e' il link alla discussione sul crivello di Eratostene:
http://forum.hwupgrade.it/showthread.php?s=&threadid=824152
Ho perso parecchio tempo a leggerlo, ma è stato veramente un thread bellissimo... :)
L'effetto si presenta perche' le prestazioni della cache di secondo livello sono molto piu' alte del sottosistema RAM. In sostanza, in caso di "sovrassaturazione" R/W verso la RAM, la cache di secondo livello (e oltre) diviene un "peso", le prestazioni della CPU verranno limitate non solo dall'accesso in RAM ma anche dalla latenza complessiva della RAM.
[...]
Concordo. C'è da dire che probabilmente anche la suddivisione del bus (metà per la lettura e l'altra metà per la scrittura) può incidere, a volte anche pesantemente...
Anch'io sono rimasta "perlessa". Una CPU molto "performante" su un sottosistema RAM poco performante: strano. Non oso immaginare un IBM PowerPC 970FX su un'evoluzione dell'Intel 875P con 4 controller RAM (quad-channel).
Non oso immaginare il costo... ;)
Si, e' "sicuramente" possibile ridisegnare il sistema di computo con il fine di minimizzare ulteriormente la propagazione degli errori. Ci sto lavorando.
Ho visto. :) E non vedo altre strade da seguire, oltre quella.

[Sharpnel]

Repne, come mai hai cancellato tutti i tuoi post?

[alexmaz]

Curioso in effetti :confused:

[Sharpnel]

Originariamente inviato da alexmaz
Curioso in effetti :confused:

Che non voglia rivelare le sue conoscenze al pubblico?

[alexmaz]

Originariamente inviato da Sharpnel
Che non voglia rivelare le sue conoscenze al pubblico?

Bah, non c'era scritto niente di che :oink:

[Jo]

Originariamente inviato da alexmaz
Bah, non c'era scritto niente di che :oink:

Oppure quel poco che c'era non avrebbe dovuto scriverlo per qualche NDA..., boh!
Mi dispiace: non ci capivo 'na mazza, però il discorso mi interessava molto :(

Ciao, Jo

[cdimauro]

Strano in effetti. Mi spiace che l'abbia fatto, perché erano molto interessanti... :(

[borgusio]

Concordo, fortuna i mitici quote di cdimauro!!! :D
Epperò.. se andate a vedere anche nel post del crivello di eratostene li ha tolti.. non dà una bella impressione sta cosa.. chiedere aiuto e poi.. tenere i risultati tutti per se?
Mmmm... :O

[Banus]

Originariamente inviato da borgusio
Epperò.. se andate a vedere anche nel post del crivello di eratostene li ha tolti.. non dà una bella impressione sta cosa.. chiedere aiuto e poi.. tenere i risultati tutti per se?
Mmmm... :O
Non credo sia per quello. A quanto pare sono spariti tutti i post. Pensavo a un errore del server ma è da giorni che è così:
http://forum.hwupgrade.it/search.php?s=&action=showresults&searchid=9410

[cdimauro]

Questo vuol dire che repne scasb ha abbandonato del tutto questo forum e probabilmente non scriverà mai più... :rolleyes: :muro:

[andrea]

Se e' cosi e' davvero un peccato :( ...erano molto interessanti i suoi post solitamente....chissa il perche' :confused:

[Sharpnel]

Originariamente inviato da Banus
Non credo sia per quello. A quanto pare sono spariti tutti i post. Pensavo a un errore del server ma è da giorni che è così:
http://forum.hwupgrade.it/search.php?s=&action=showresults&searchid=9410

Non credo sia un errore del server, visto che i vari post sono stati cancellati in tempi differenti.

X-Files?

[Banus]

Originariamente inviato da Sharpnel
Non credo sia un errore del server, visto che i vari post sono stati cancellati in tempi differenti.
Notato, e i tempi sono compatibili con una cancellazione manuale (2-3 al minuto).

[Sharpnel]

Originariamente inviato da Banus
Notato, e i tempi sono compatibili con una cancellazione manuale (2-3 al minuto).

Ad ogni modo, in pieno stile "mi faccio i fatti tuoi" ho sbirciato un po' gli ultimi topic dove ha postato, e ho notato che nell'ultima ha a più riprese discusso animatamente (al limite del litigio) con un altro utente.

Da questo deduco che se ne sia andata.

Caso risolto :p :(

[Gold2004]

E' un progetto in sviluppo.
Qua c'erano molti dettagli al riguardo.
A qualcuno potrebbe dar fastidio.

Mi pare normale.

Saluti

[Banus]

Originariamente inviato da Gold2004
E' un progetto in sviluppo.
Qua c'erano molti dettagli al riguardo.
A qualcuno potrebbe dar fastidio.
Non capisco come mai sono stati cancellati tutti
Il thread sul crivello l'ho seguito e non ha detto proprio nulla sul suo lavoro.
Su forumzone dove parla di un progetto importante a cui ha lavorato (ne ha parlato anche qui, nel thread della protezione per portatili rubati) non è stato cancellato nulla...

[Gold2004]

Originariamente inviato da Banus
Non capisco come mai sono stati cancellati tutti
Il thread sul crivello l'ho seguito e non ha detto proprio nulla sul suo lavoro.
Su forumzone dove parla di un progetto importante a cui ha lavorato (ne ha parlato anche qui, nel thread della protezione per portatili rubati) non è stato cancellato nulla...

Avevo capito che i post cancellati erano quelli di questo topic. Ops.

Curioso.

Saluti

PS: Banus fai l'investigatore di lavoro?? :)

[Banus]

Originariamente inviato da Gold2004
PS: Banus fai l'investigatore di lavoro?? :)
No, però sono curioso :p

[alexmaz]

Originariamente inviato da Gold2004
E' un progetto in sviluppo.
Qua c'erano molti dettagli al riguardo.
A qualcuno potrebbe dar fastidio.

Mi pare normale.

Saluti

ma valà :rolleyes:

[LUVІ]

E' un progetto in sviluppo.
Qua c'erano molti dettagli al riguardo.
A qualcuno potrebbe dar fastidio.

Mi pare normale.

Saluti

Dove su forumzone? Vorrei sapere qualcosa di più.

LuVi