Processori AMD quad-core nel 2007?

[frankie]

Io dal fronte degli HD mi chiedo come mai nesuna azienda abbia pensato a mettere all'interno della stessa unità due HD in Raid. Ovvero due HD indipendenti che raddoppiano le prestazioni. E non lasciare come gli attuali che lavorano uno dopo l'altro i dischi. Tanto dentro ci sono sempre 2 o più dischi, perchè allora non utilizzarli in raid, magari 5 per la sicurezza per quei casi che importa la sicurezza, con un proprio controller interno.

[Raid0]

Originariamente inviato da frankie

Io dal fronte degli HD mi chiedo come mai nesuna azienda abbia pensato a mettere all'interno della stessa unità due HD in Raid. Ovvero due HD indipendenti che raddoppiano le prestazioni. E non lasciare come gli attuali che lavorano uno dopo l'altro i dischi. Tanto dentro ci sono sempre 2 o più dischi, perchè allora non utilizzarli in raid, magari 5 per la sicurezza per quei casi che importa la sicurezza, con un proprio controller interno.

Quoto in pieno...

P.S.
Vi prego ragazzi datemi una mano, vi chiedo solo 2 minuti per un consiglio:leggete qui http://forum.hwupgrade.it/showthread.php?t=927583 PLEASE

[Alberello69]

Originariamente inviato da frankie

Io dal fronte degli HD mi chiedo come mai nesuna azienda abbia pensato a mettere all'interno della stessa unità due HD in Raid. Ovvero due HD indipendenti che raddoppiano le prestazioni. E non lasciare come gli attuali che lavorano uno dopo l'altro i dischi. Tanto dentro ci sono sempre 2 o più dischi, perchè allora non utilizzarli in raid, magari 5 per la sicurezza per quei casi che importa la sicurezza, con un proprio controller interno.

...semplicemente perchè costerebbe di più del doppio del singolo disco.

[Dix 3]

Ma le MRAM se le sono scordate TUTTI.......

CACCHIO SONO LE COSE CHE CAMDBIERANNO il mondo dell'hardware

[Banus]

Originariamente inviato da k-Christian27

Sig. Stroboscopico , Neo_ , adynak etc..
-quest'altranno usciranno gli HD olografici (mi sembra della toshiba, non ricordo bene) con capienza di 300gb minimo, per il 2007 previsti da oltre 1 TB.

Ma questa tecnologia non doveva essere usata per i dischi ottici?
Hanno preferito riciclarla per gli HD?

Originariamente inviato da Dix 3

Ma le MRAM se le sono scordate TUTTI.......

IBM fa ricerca da anni in quel settore, ma ultimamente sento poche novità... o hanno trovato problemi di difficile soluzione, oppure non sono competitive rispetto ad altre tecnologie allo studio.

[sinadex]

oppure vogliono spremerci ancora soldi con le tecnologie vecchie

[lepre84]

i dischi negli attuali hd sono già usati parallelamente...il problema sta nell'interfaccia credo

[JohnPetrucci]

Originariamente inviato da enjoymarco

Bè le piattaforme multiprocessore hanno costi decisamente più elevati rispetto ad una dual core, e le prestazioni dei dual core sono identiche se non superiori, paragonando ad es. 2 opteron 2Ghz single core su mobo dual processor e un opteron dual core 2Ghz su mobo single processor.

Verissimo.
Ma non è che si può aggiornare il software ad ogni generazione di core aggiunti.
Non mi sembra una soluzione ideale, visto che adesso si parla addirittura di quad-core.

[erupter]

Originariamente inviato da lepre84

i dischi negli attuali hd sono già usati parallelamente...il problema sta nell'interfaccia credo

Decisamente non è l'interfaccia il problema dato che può arrivare a 160mb e più con le nuove revision

[xeal]

[OT]

Originariamente inviato da Banus
Ma questa tecnologia non doveva essere usata per i dischi ottici? :surprised:
Hanno preferito riciclarla per gli HD?

Ricordo di aver letto un articolo tempo fa (forse su lithium). Si diceva che l'idea originaria era quella di creare hd olografici con capienza elevata, fino a 1 TB (mi pare) per pollice cubo (con questa tecnologia si ragiona tridimensionalmente), con un particolare sistema di lenti per calibrare alcuni laser, i quali, interferendo, vanno a leggere/scrivere una determinata "pagina" di memoria (una sorta di matrice di dati, se ricordo bene) in una certa direzione dello spazio, naturalmente all'interno del mezzo di storage. Non essendoci, praticamente, parti in movimento, la velocità di accesso ai dati sarebbe elevatissima, ma, di contro, si dovrebbe realizzare un sistema di "pilotaggio" dei laser estremamente sofisticato e delicato, con un margine di tolleranza infinitamente piccolo, e di conseguenza estremamente costoso da realizzare (superati i problemi tecnici).

Per questo motivo si parlava, in quell'articolo, di possibili soluzioni/implementazioni alternative, tra cui l'uso combinato con parti meccaniche in dispositivi ottici, in modo da limitare la precisione del laser ad un volume ristretto e far ruotare il disco di storage per accedere a tutte le sue parti. Francamente non sapevo nulla dei dischi di cui parla k-Christian27, non so se implementino il sistema "originario", oppure se effettivamente "riciclino" la variante per dischi ottici "classici" anche nel campo degli hd. Può darsi che questa soluzione, seppur decisamente più lenta di quanto potrebbe essere un disco olografico senza il disco in movimento, porti comunque un incremento notevole del transfer rate, oltre che della quantità di dati immagazzinabile, rispetto alle tecnologie attuali, per cui potrebbe essere un'ottimo sostituto dei dischi magnetici staremo a vedere...

IBM fa ricerca da anni in quel settore, ma ultimamente sento poche novità... o hanno trovato problemi di difficile soluzione, oppure non sono competitive rispetto ad altre tecnologie allo studio.

Oppure ancora sono troppo rivoluzionarie... Ho letto qualcosa al riguardo più o meno nel periodo in cui si cominciava a parlarne, e ricordo che si diceva, sullo "stato dell'arte", che erano allo studio dei sistemi di impacchettamento delle celle di memoria con densità molto vicina (di poco inferiore) a quella delle DRAM (quindi, probabilmente, abbastanza economiche da produrre almeno come ram), e che i tempi di accesso erano piuttosto simili alle Static RAM, attualmente usate nella cache dei processori e costose da produrre (ovvero, ci ritroveremmo con una RAM, a parità di costo e di frequenza, molto più veloce di quella attuale, non saprei, però, quanto converrebbe, in termini economici, usarla come HD). Non ho idea, comunque, di come si comportino nel salire in frequenza...

Bye

[/OT]

[xeal]

Originariamente inviato da erupter
Già allo stato attuale si può dire ad un certo programma di usare una certa cpu piuttosto che un'altra.

Vero, ma non sempre è conveniente, anzi, lo è solo in casi molto particolari, in genere si rischia di peggiorare le prestazioni del sistema operativo.

Il problema non è tanto dei programmi quanto dei sistemi operativi: oramai tutti i programmi sono threaded,

Questo non è vero: moltissimi programmi non sono threaded, alcuni problemi sono intrinsecamente non parallelizzabili, in altri casi semplicemente non ha senso (vedi un qualsiasi word processor...). Che poi alcuni sistemi operativi aprano almeno un thread per ogni processo, è un altro discorso: per uniformità e semplicità si considerano i programmi "monolitici" che non producono alcun thread come costituiti da un unico thread.

se il sistema operativo fosse in grado di smistare i vari thread su tutte le cpu...

Il sistema operativo lo fa, è compito suo, che io sappia sono ormai pochi i casi in cui è l'applicazione ad avere carta bianca nella gestione dei thread.

Bhè non ci sarebbe bisogno di software apposta.

Un programma va sempre scritto apposta per poter essere eseguito su più di una cpu, in maniera parallela. Però questo non vuol dire che il programma debba scegliere per forza le cpu da gestire, generalmente basta che sia threaded, e la maggior parte dei software attuali, in ambito desktop, non lo è.

[Banus]

Originariamente inviato da xeal

Però questo non vuol dire che il programma debba scegliere per forza le cpu da gestire, generalmente basta che sia threaded, e la maggior parte dei software attuali, in ambito desktop, non lo è.

Perchè in genere i PC montano un singolo processore, e non si è mai sentita l'esigenza di creare programmi paralleli (con tutte le complicazioni del caso). Inoltre la maggior parte dei programmi desktop usano relativamente poco la CPU.
Vedo che la maggior parte dei programmi CPU-intensive possono essere parallelizzati senza grandi difficoltà, come DBMS, applicazioni scientifiche, programmi di rendering, quindi il passaggio ai multicore non dovrebbe penalizzare le prestazioni, negli ambiti in cui sono necessarie.

PS: grazie per le info su dischi olografici e MRAM

[xeal]

Originariamente inviato da Banus
Vedo che la maggior parte dei programmi CPU-intensive possono essere parallelizzati senza grandi difficoltà, come DBMS, applicazioni scientifiche, programmi di rendering, quindi il passaggio ai multicore non dovrebbe penalizzare le prestazioni, negli ambiti in cui sono necessarie.

Se il problema risolto dal programma è parallelizzabile, non dovrebbero esserci problemi, poi, molti dei programmi professionali di quel tipo credo siano già parallelizzati, gli altri, essendo simili, non dovrebbero presentare problemi, sono d'accordo, comunque è un problema che in genere riguarda il software, non il sistema operativo, volevo sottolineare questo

Il discorso temo potrebbe complicarsi nel passare da 2 a 4 core se saranno realmente diversificati e specializzati, e non più tutti "general purpouse", in tal caso non basterà un lavoro al più di affinamento di un problema già parallelizzato (laddove si potessero ancora aumentare nel numero i thread da eseguire in parallelo), ma temo sarà necessario riscrivere tutto da capo. D'altra parte, sarebbe un po' come cambiare l'architettura "target" del programma (chissà che non cambi anche l'ISA, o non venga modificata...). Staremo a vedere

PS: grazie per le info su dischi olografici e MRAM

Non c'è di che . Peccato che le MRAM non si vedranno a breve sul mercato sarebbe fantastico abbattere la distinzione tra RAM e memoria secondaria, come velocità soprattutto, magari facendo lavorare in sincrono processore e memoria, potrebbe diventare superflua la cache, praticamente non più necessario il paging, la deframmentazione diventerebbe velocissima (laddove ancora necessaria), i file system migrerebbero verso un'allocazione contigua o ibrida, praticamente non ci sarebbero colli di bottiglia... OK, sto correndo un po' troppo con la fantasia, forse anche oltre le possibilità di questa tecnologia, torno con i piedi per terra...

[lepre84]

Originariamente inviato da erupter

Decisamente non è l'interfaccia il problema dato che può arrivare a 160mb e più con le nuove revision

mi pare che i dati di lettura interna sono nell'ordine dei centinaia di MB/s che si trasformano in 60/70 nei casi + fortunati all'esterno (raptor)

almeno così ricordo

[Dreadnought]

+ o -
Su questo sito c'è un database prestazionale.
http://www.storagereview.com/php/ben...bench_sort.php

Se prendete i primi 3, il più veloce, il maxtor atlas 147GB fa 75-95MB/s, mentre il raptor è ancora attestato sui 55-70MB/s
http://www.storagereview.com/php/ben...2=259&devCnt=3

[lepre84]

Originariamente inviato da Dreadnought

+ o -
Su questo sito c'è un database prestazionale.
http://www.storagereview.com/php/ben...bench_sort.php

Se prendete i primi 3, il più veloce, il maxtor atlas 147GB fa 75-95MB/s, mentre il raptor è ancora attestato sui 55-70MB/s
http://www.storagereview.com/php/ben...2=259&devCnt=3

lo so che il raptor è attestato su quella velocità....ce l'ho e fa 65MB/s sul mio pc.
ovviamente escludevo gli SCSI.

edit:
ecco ho trovato una review in cui viene specificata la velocità interna del raptor che è di 816Mbit/s alias 102MB/s che sono evidentemente di più dei 72MB/s teorici buttati nel canale SATA. Questa quantità di dati persa è quella a cui mi riferivo nell'altro post...30MB/s in + dove finiscono?
con interfaccia non intendevo SATA ma intendevo il passaggio dai dati letti dalla testina a quelli mandati sul canale SATA.

[Dreadnought]

I primi 2 non vanno di più perchè sono SCSI, ma perchè hanno una densità di dati sui piatti maggiore die 74GB, o meno così mi viene da dire ad occhio.

Originariamente inviato da lepre84

ecco ho trovato una review in cui viene specificata la velocità interna del raptor che è di 816Mbit/s alias 102MB/s che sono evidentemente di più dei 72MB/s teorici buttati nel canale SATA. Questa quantità di dati persa è quella a cui mi riferivo nell'altro post...30MB/s in + dove finiscono?
con interfaccia non intendevo SATA ma intendevo il passaggio dai dati letti dalla testina a quelli mandati sul canale SATA.

Puo' essere che ci sia un overhead dei dati letti direttamente dalla testina rispetto a quelli che evvettivamente trasmette.