Newsgroup: it.comp.hardware.storage
Titolo: ennesima domanda SSD

mi avete avvelenato con i vostri discorsi sulla bontà degli SSD, ma ho 
scoperto l'antidoto: ne prendo uno anch'io, per il mio compleanno
 
me ne consigliate uno buono da 240 Gb? la motherboard è una Asus 
Sabertooth P67, dotata di Serial ATA 6 Gb
 
ci devo fare photoshop con operazioni di rendering pesante
 

 ha scritto nel messaggio 
news:jnbq7v$ve6$1...@speranza.aioe.org...

il rendering pesante di photoshop pesa sopratutto su ram e cpu.. guadagnerai 
solo in fase apertura e salvataggio.
 
personalmente nel taglio 240 ho usato ocz vertex3 max iops varie volte con 
gran soddisfazione, ma ci son tante altre scelte ad esempio Corsair e 
Samsung o Hyperx... 
 

helio ha spiegato il 26/04/12 :

Per quella capacità puoi andare sul classico Crucial M4 oppure sul 
Samsung 830... entrambi sono da 256GB.
 
 

 e Samsung o Hyperx...
 
grazie
 


grazie: inizio una ricerca comparativa fra questi due e l'ocz vertex3

 a queste unità sostituisco l'SSD questo non dovrebbe notarsi?
 
si il vantaggio c'e' pero' sopratutto se adesso sei scarso a ram. se abusi 
con la ram (non so quanta ne hai) per prima cosa.. e' meglio.
 
poi dipende da cosa fai esattamente con photoshop, se lavori file 
esageratamente grandi e 32gb di ram non ti bastano...allora guadagnerai 
anche durante le elaborazioni. 
 


 
Se ci riesci, rimanda il tuo compleanno di qualche mese:
 
http://www.hwupgrade.it/news/storage/ssd-arriva-la-guerra-dei-prezzi-al-ribasso_41864.html
 
 
:-)
 

 ha scritto nel messaggio 
news:jnc41l$r4h$2...@speranza.aioe.org...

non cercare, nel taglio da 256 prendi il samsung830. Se ci lavori pensaci 
due volte prima di prendere un ocz.
 
Muzio 
 

 esageratamente grandi e 32gb di ram non ti bastano... 
 
lol
 
 

 grazie: inizio una ricerca comparativa fra questi due e l'ocz vertex3
 
alla lista aggiungi anche Corsair Performance Pro 256GB
e Plextor M3 256GB (M3S) , sono molto simili, il primo e' piu'
performante ed usa le memorie Toshiba 32nm, il secondo
usa le 24nm ed ha 5 anni di garanzia , la differenza e' la
longevita' e se lo usi anche come temp/scratch i 5000
cicli P/E del Corsair potrebbero tornarti utili
 
costano un po' di piu' rispetto a Samsung 830 e Crucial m4
(e meno dell'OCZ Vertex 3 Max IOPS), la scelta finale dipende
anche dalla disponiblita' ed il prezzo nel tuo negozio di fiducia
 
ciao
luca
 

 ha scritto nel messaggio 
news:mn.d81a7dc49...@alientech.it...

eheh..ma noi che ne sappiamo, magari e' un beta tester di Canon EOS da 
50Megapixel con colore a 96bit... 
 


 
in effetti, più cerco e più trovo critiche all'ocz, tipo questa:
"Visto il problema di cui soffrono i Vertex 3 di OCZ (ad un certo punto 
non viene più visto dal sistema con conseguente schermata blu o freeze 
di windows) non so se convenga acquistarli"
 
quindi, se è vero che la prudenza è madre della sicurezza, devo 
escluderli dai candidati
 
sul Samsung 830 sto leggendo bene: è nuovo, ha le nand fatte in casa
 
credo che seguirò il tuo consiglio, di cui ti ringrazio


ehi, non esageriamo :)
 
ho 16gb di ram (4x4gb 993995 Mushkin Blackline), ma quando comincio a 
lavorare su immagini da 10 mega con un filtro che fa rendering di 
superficie (
http://www.filterforge.com/
) a volte l'operazione dura più 
di un minuto, e siccome provo gli effetti uno dopo l'altro mi ci vuole 
un sacco di tempo


ho letto un po' di schede su Corsair Performance Pro, Plextor M3, 
Crucial M4 e Samsung 830, e quest'ultimo, anche se non è il più veloce, 
usa un controller fatto dalla Samsung stessa, mentre gli altri sono 
affidati a terze parti (Marvell)
 
perciò credo che prenderò il Samsung
 
grazie


grazie Danilo, ma proprio non ci riesco: festa grande al compleanno :-)

helio ha pensato forte :

Anche il controller è "fatto in casa"...:)
 
 

 perciò credo che prenderò il Samsung
 
non e' importante chi produce il controller ma chi implementa il miglior 
firmware ;)
 
ciao
luca
 


vedo che il firmware è "device specific", e che quindi, da questo punto 
di vista, ha poco senso paragonare device differenti come Samsung e Marvell
 
ma mi chiedo (forse perché non ho afferrato completamente quel che 
volevi dirmi): i produttori non possono tirar fuori controller, 
indipendentemente dal firmware, che straccino la concorrenza per le 
soluzioni hardware proposte?

helio scriveva il 27/04/12 :

Per fare un paragone automobilistico... se hai un ottimo controller ma 
la casa produttrice dell'SSD ha fatto con i piedi il firmware, sarebbe  
come avere una Ferrari con le ruote di una Fiat 500.
 Non so se ho reso bene l'idea ;)
 
 


certo, ma la mia idea non era diversa
 
ho detto che vorrei prendere Samsung perchè "usa un controller fatto 
dalla Samsung stessa", che è come dire una Ferrari con le ruote di una 
Ferrari
 
se poi il Samsung 830 sia una Ferrari non lo so, ma stando ai vari 
consigli (compreso il tuo) sembra che non sia neanche una 500 :)

 proposte?
 
mi sa che non ho capito io cosa vuoi dire :)
 
ciao
luca
 
 
 
 
 
 
 

 (compreso il tuo) sembra che non sia neanche una 500 :)
 
Di certo globalmente è tra i migliori in ambito consumer :)
 
 

 mi sa che non ho capito io cosa vuoi dire :)
 
avevo frainteso una tua affermazione, ma dopo il tuo chiarimento è tutto ok

 com'è scritto il software? in C? in assembler?
 
non lo so :)
 
 
per tornare all'esempio automobilistico fatto da Lorenz, puoi
paragonare un SSD ad una vettura di F1 (motore+telaio,
tutto il resto ed il pilota lasciamoli fuori) , purtroppo la
Ferrari non vince sempre eppure sono 60 anni che fa
tutto in casa :/
 
ciao
luca
 
 
 
 
 


 
vedo qui
http://goo.gl/ZBliK
 
che per un posto di Senior SSD Firmware Engineer si richiede 
"Proficiency with programming language such as C or C++"
 
quindi, indipendentemente dall'OS in cui si sviluppa il codice, opino 
che si usi il C
 

 usi il C
 
Probabile...dato che si deve operare il più possibile a basso livello 
per quanto riguarda la gestione del controller.
 
 


 
ho scaricato il Vertex Plus firmware 3.55 (
http://goo.gl/emWxS
), ed è 
solo 2.91 MB
 
a questo livello credo che sarebbe più efficiente programmare in 
assembler, ma ho trovato altre conferme che la programmazione viene 
fatta in C: chissà perchè ...

 in C: chissà perchè ...
 
il firmware e' scritto in un linguaggio ad alto livello (simile al C
ma potrebbe essere un meta linguaggio) con un tool di sviluppo
fornito dal chipmaker (framework), le librerie a corredo sono basilari
(I/O) quindi anche il codice compilato sara' estremamente compatto
 
il file a cui ti riferisci e' l'ISO che contiene diversi firmware ,
di solito un FW occupa 200-250KB per controller Indilinx originale
(Vertex) ed "Arowana" (Vertex Plus o Vertex modificati) ,
circa 750KB per il vecchio Crucial C300, circa 1MB per
il Samsung 830, ecc..
 
ciao
luca
 
 
 
 
 

 
http://www.hwupgrade.it/news/storage/ssd-arriva-la-guerra-dei-prezzi-.
..
 
era quasi ora.
Speriamo che insieme agli SSd scedna il prezzo anche degli HD
standard...
 
Ciao Jack

helio ha spiegato il 30/04/12 :

Con l'assembler ci sarebbe troppo lavoro di debug e alla fine i 
risultati non sarebbero tanto migliori rispetto all'uso di un 
linguaggio relativamente a più alto livello come il C...
 
 


 
qui (
http://goo.gl/jTnvZ
) ho trovato una descrizione dello sviluppo del 
firmware per il controller SSD Siglead:
- gli ingegneri sviluppano gli algoritmi iniziali in C o C++
- gli algoritmi vengono usati come modelli di riferimento per scrivere
   e verificare il codice HDL (che non so cosa sia, sarà il tool di
   sviluppo a cui ti riferisci tu?) per le implementazioni FPGA e ASIC
 
siccome si presenta un gap fra l'algoritmo e la sua implementazione HDL, 
gli ingegneri della Siglead usano Matlab, Simulink e HDL Coder per 
generare codice HDL ottimizzato a partire dall'algoritmo
 
ne deduco che l'uso dell C sia dovuto alle infinite capacità di 
interfaccia di questo linguaggio


 
bah, a me l'assembler sembra mostruosamente più veloce, e per un 
software di 200 Kb un po' di debug si potrebbe sopportare; credo che la 
scelta, come ho scritto a 2fast, dipenda dalla versatilità del C 
(interfaccia Windows-Unix, librerie, ottimizzazione mediante software 
dedicato)

 librerie, ottimizzazione mediante software dedicato)
 
Buttali via anche quelli...:)
 
 

 In questi ambiti il termine "mostruosamente" è un tantino fuori luogo.
 
mi è consentito dire "come minimo 2 o 3 volte più veloce"?
http://www.dspguide.com/ch28/5.htm
 

 
http://www.dspguide.com/ch28/5.htm
 
 
Dipende sempre dal contesto...in questo ambito la velocità di 
esecuzione può risultare di secondaria importanza. Oppure gli ingegneri 
che programmano i firmware utilizzando linguaggi di livello più alto 
sono tutti degli inetti.
 
Ai posteriori l'ardua sentenza...:)
 
 

 interfaccia di questo linguaggio
 
non conoscevo Siglead, per quanto riguarda l'HDL :
http://en.wikipedia.org/wiki/Hardware_description_language
 
 
secondo me, il linguaggio di programmazione usato per
scrivere il firmware e l'instruction set contano relativamente
poco, cio' che conta in questi casi e' il programma :)
 
e' ovvio che il chip deve avere una potenza di calcolo sufficiente
a garantire elevati transfer rate, bilanciando prestazioni ed
affidabilita' (esempio del controller Marvell utilizzato in modo
diverso da piu' competitor)
 
ciao
luca
 
 
 
 
 
 
 
 
 
 


 
se per programma intendi come viene effettivamente sviluppato il codice 
per uno specifico dispositivo, consentimi di eccepire: penso che, se 
tanti produttori di dispositivi diversi si affidano a determinati 
linguaggi (praticamente al C) piuttosto che ad altri, una ragione ci sarà

 fatta in C: chissà perchè ...
 
Probabilmente perché vogliono completare i firmware prima dell'avvento
dei cavalieri dell'apocalisse :-)
Seriamente, c'è ancora qualcuno in giro che scrive direttamente assembly?
 
-- 
ValeRyo 
 
 


vedo qui che ce n'è bisogno, e proprio da parte di chi produce SSD:
 
http://jobs.lsi.com/in/pune/engineering/bios_uefi-driver-engineer-jobs
 
 

 
http://jobs.lsi.com/in/pune/engineering/bios_uefi-driver-engineer-jobs
 
 
Occhio: ho detto 'che scrive direttamente' assembly, non che non
serva conoscerlo...
 
-- 
ValeRyo 
 
 

 Seriamente, c'è ancora qualcuno in giro che scrive direttamente assembly?
 
Effettivamente...:D
 
 

 serva conoscerlo...
 
nel link che ti ho mandato appare come caratteristica preferenziale 
quella di aver avuto precedenti esperienze di programmazione in 
assembly: non credo proprio che il responsabile della Divisione 
Componenti Flash della LSI faccia una richiesta cosě esplicita a uno che 
ne abbia una conoscenza solo accademica
 
in generale direi che tutto l'enorme mondo dell'embedded software usa 
l'assembly, oltre al C
 
ad esempio, i microcontrollers 8051 della Maxim possono interfacciarsi a 
un sacco di cose, e il produttore illustra come farlo utilizzando  solo 
esempi in assembly (un paio di volte in Pascal), mai in C
 
http://www.maxim-ic.com/products/microcontrollers/software/#example
 
 
 
c'č poi costui, che mi sembra raccomandabile come persona che scrive 
direttamente in assembly :)
 
http://www.shervinemami.info/armAssembly.html
 
 
un elenco degli attuali usi dell'assembly:
http://en.wikipedia.org/wiki/Assembly_language
 

 
http://www.maxim-ic.com/products/microcontrollers/software/#example
 
 
Senza neppure aprire il link (se mi dici che ne vale la pena lo faccio)
gli esempi in assembly saranno di 20 righe l'uno.
In assembly ci puoi scrivere una funzione specifica, un accesso
a basso livello a dei registri, ma AFAIK non ci scrivi un firmware per un 
SSD.
 
-- 
ValeRyo 
 
 

 SSD.
 
e chi l'ha mai detto?
 

 beh, so programmare in assembly (Synertek 6502, 8 bit)
 
Ah ecco perchè "sponsorizzi" così l'assembly...:))
 
 


lo considero il "linguaggio del cuore", perché per lavorare devo 
conoscere sempre meglio l'architettura del processore
 
questo però rende impossibili alcune cose, per esempio fare un programma 
che giri su due processori diversi; ed è il motivo per cui, se mi chiedi 
di programmare su un'architettura che non conosco, lo specifico 
assembler che uso non serve più
 
invece il linguaggio C è indifferente all'hardware, e presenta molti 
vantaggi, fra cui la possibilità di programmare con "concetti" per la 
realizzazione dei quali in assembly ci sarebbe da impazzire; il prezzo 
che si paga è il tempo di esecuzione e l'utilizzo di un maggior numero 
di risorse
 
 
 
 
 
 

 e chi l'ha mai detto?
 
Io e la (poca) documentazione che ho letto al riguardo.
Pensa che scomodità scrivere una routine di GC in assembly e
poi riscriverla perché usi un nuovo processore che esegue
in hw alcune funzioni.
Oltre alla scomodità intrinseca di scriverla in assembly, intendo :-P
 
Troverei più sensato scrivere gran parte del fw in un linguaggio
d'alto livello e scrivere in assembly solo le parti per cui la
velocità di esecuzione è essenziale.
 
-- 
ValeRyo 
 
 

 velocità di esecuzione è essenziale.
 
infatti, credo che si faccia proprio così
 
 

 Seriamente, c'č ancora qualcuno in giro che scrive direttamente assembly?
 
purtroppo si.
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 esempi in assembly (un paio di volte in Pascal), mai in C
 
questo perche' il produttore non fornisce un compilatore C.
ma di compilatori C per gli 8051 ce ne sono a bizzeffe.
Fermo restando che chi usa un 8051 per un progetto nuovo sarebbe da
licenziare in tronco.


 di risorse
 
palle.
se usi un compilatore C appena appena decente e' piu' probabile che sia
lui a creare del codice assembly migliore del tuo scritto a mano.



 
se quel che dici è vero, trovami un articolo sul web che lo sostenga non 
per semplice affermazione ma con argomentazioni tecniche
 
mi auguro, viceversa, che quest'elenco di applicazioni critiche in cui 
l'assembly viene attualmente preferito al C sia sufficiente a dimostrare 
il contrario:
 
A stand-alone executable of compact size is required that must execute 
without recourse to the run-time components or libraries associated with 
a high-level language; this is perhaps the most common situation. For 
example, firmware for telephones, automobile fuel and ignition systems, 
air-conditioning control systems, security systems, and sensors.
Code that must interact directly with the hardware, for example in 
device drivers and interrupt handlers.
Programs that need to use processor-specific instructions not 
implemented in a compiler. A common example is the bitwise rotation 
instruction at the core of many encryption algorithms.
Programs that create vectorized functions for programs in higher-level 
languages such as C. In the higher-level language this is sometimes 
aided by compiler intrinsic functions which map directly to SIMD 
mnemonics, but nevertheless result in a one-to-one assembly conversion 
specific for the given vector processor.
Programs requiring extreme optimization, for example an inner loop in a 
processor-intensive algorithm. Game programmers take advantage of the 
abilities of hardware features in systems, enabling games to run faster. 
Also large scientific simulations require highly optimized algorithms, 
e.g. linear algebra with BLAS[18][23] or discrete cosine transformation 
(e.g. SIMD assembly version from x264[24])
Situations where no high-level language exists, on a new or specialized 
processor, for example.
Programs need precise timing such as
real-time programs such as simulations, flight navigation systems, and 
medical equipment. For example, in a fly-by-wire system, telemetry must 
be interpreted and acted upon within strict time constraints. Such 
systems must eliminate sources of unpredictable delays, which may be 
created by (some) interpreted languages, automatic garbage collection, 
paging operations, or preemptive multitasking. However, some 
higher-level languages incorporate run-time components and operating 
system interfaces that can introduce such delays. Choosing assembly or 
lower-level languages for such systems gives programmers greater 
visibility and control over processing details.
cryptographic algorithms that must always take strictly the same time to 
execute, preventing timing attacks.
Situations where complete control over the environment is required, in 
extremely high security situations where nothing can be taken for granted.
Computer viruses, bootloaders, certain device drivers, or other items 
very close to the hardware or low-level operating system.
Instruction set simulators for monitoring, tracing and debugging where 
additional overhead is kept to a minimum
Reverse-engineering and modifying program files such as
existing binaries that may or may not have originally been written in a 
high-level language, for example when trying to recreate programs for 
which source code is not available or has been lost, or cracking copy 
protection of proprietary software.
Video games (also termed ROM hacking), which is possible via several 
methods. The most widely employed is altering program code at the 
assembly language level.
Self modifying code, to which assembly language lends itself well.
Games and other software for graphing calculators.
 
http://en.wikipedia.org/wiki/Assembly_language
 

 Games and other software for graphing calculators.
 
si e' dimenticato di citare che l'assembler e' anche utile per l'hacking
delle mothership degli alieni cattivi che vogliono distruggere la Terra.
 
Ovviamente si e' dimenticato di dire che per scrivere compilatori serve
scrivere roba in assembler (che poi e' l'utilizzo piu' importante
dell'assembler IMHO).
 
Tornando a noi.
Quello che ho detto e che pare non hai capito (se vuoi te lo ridico in
inglese) e' che se scrivi qualcosa in assembler e poi lo riscrivi in C
(ad esempio eh, puoi usare altri linguaggi se vuoi) in genere il codice
assmbler che esce dal compilatore e' migliore o comunque non peggio di
quello scritto da te.
Questo principalmente perche' i compilatori sanno fare delle
ottimizzazioni che per noi umani sono complicate.
 
Inoltre visto che la manutenzione del codice scritto in linguaggi
superiori, ma anche solo l'implementazione stessa del programma e' molto
piu' semplice, veloce e c'e' meno rischio di fare errori. Si tende a
preferire l'utilizzo di questi linguaggi invece dell'assembly.
Ed e' proprio nelle applicazioni critiche (automotive, aviazione,...)
che e' caldamente sconsigliato (a volte proprio proibito) l'assembler
proprio perche' e' molto facile fare errori scrivendo ed e' molto
difficile trovarli e risolverli.
 
Giusto un'ultima cosa: a parte situazioni dove non se ne puo' fare a
meno (non esiste un compilatore di linguaggi a livello piu' alto, oppure
il compilatore non usa delle istruzioni importanti) se bisogna mettersi
a scrivere codice in assembler per strizzare ogni minimo clock del
processore allora di solito e' perche' si e' sbagliato alla grande il
dimensionamento del processore nella fase di analisi e design del
progetto...


 progetto...
 
ti ripeto, sono il primo ad essere convinto della maggior efficienza in 
generale dello C rispetto all'assembly, anche se ci� comporta un 
sacrificio in termini di velocit� e risorse; ma (e qui non capisco 
perch� scrivi che "purtroppo" esistono ancora programmatori in assembly) 
sono il primo ad essere convinto della superiorit� attuale dell'assembly 
rispetto allo C in molte applicazioni critiche per motivi di tempo e di 
risorse