AMD o Intel così come la marca di memoria - pagina 42
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Se stiamo parlando specificamente di SSD (non solo di chiavette USB o di varie SD/MMC/CF ecc.), i controller moderni programmano le operazioni di scrittura in modo tale da distribuire uniformemente il carico su tutte le celle. Cioè, anche se lo stesso file viene sovrascritto di continuo, le celle sono quasi sempre diverse. Quindi anche ~10 000 cicli (per MLC) dureranno molto a lungo.
In particolare Intel per i suoi SSD serie M garantisce che l'unità sarà in grado di scrivere fino a 100GB al giorno per 5 anni. È vero, sono "solo" garantiti per 3 anni, ma è improbabile che avremo presto 100GB al giorno nei test.
Per quanto riguarda la velocità di accesso a QUALSIASI file (grande/piccolo), gli SSD moderni possono essere inferiori a QUALSIASI HDD moderno solo su operazioni lineari (sequenziali). Ma in queste operazioni la loro velocità è già abbastanza buona. Allo stesso tempo durante l'accesso casuale (principale "freno") anche gli HDD del server "15 millesimi" non sono in grado di avvicinarli almeno in qualche modo alla velocità. Beh, il tempo di accesso differisce per ordini di grandezza! Lo stesso vale per il numero di operazioni di input-output al secondo.
Quindi l'unico fattore limitante è il prezzo.
Wow, che dettagli... grazie per la leccata senza - non lo sapevo) l'ho letto con la coda dell'occhio, ma non ho una conoscenza così profonda... Grazie, forse ora risparmierò per un SSD senza paura =)
a proposito, secondo le recensioni, il primo eee pc aveva un SSD schifoso... quindi in termini di velocità e qualità penso che non fossero così buoni come ....
Testato il portatile. Intel Mobile Core 2 Duo P8600 @ 2.4 GHz, cache 3072 KB L2, DDR2 4GB PC-6400
Script test 44.99s, ottimizzazione 201s, su ticks 29:46
Il terminale in RAM mostrerà 45.14, l'ottimizzazione 185s e 29:38 in tick.
a Olga_trader. Per i test usa SuperSpeed RamDisk 9.0.1.0, il primo disponibile. In entrambi i casi ho creato un disco da 800 Mb, perché il tester crea la storia in anticipo. 1 anno è circa 524 Mb. Per 5 anni sono 2,5 gb più la cartella history, che ho già gonfiato a 1,85 gb, e devo ancora lasciare 3-4 gb di RAM per il terminale e il disco rigido. Totale 8 gb. Un aumento della produttività grazie a queste azioni è discutibile, ma non posso comunque lavorare con questa roba.
Se faccio funzionare 2 terminali sul mio atlonchik, i test al minuto saranno 188s e 166s - scegliete il risultato più alto. Ho 1:23:24 e 1:18:23 ticks (era 1:09:06 su un core) - la mia RAM era bassa e il computer stava usando attivamente il disco rigido.
Su laptop ottimizzazione di minuti 113s e 96s, di tick 20:26 e 16:48.
Sì, Imp120, metti il test del portatile nella tabella.
Если на моем атлончике запустить сразу 2 терминала, то тест по минутам будет 188с и 166с - выбираем больший результат. По тикам 1:23:24 и 1:18:23 (было 1:09:06 на одном ядре) - не хватило RAM и комп стал активно пользоваться хардом.
Il portatile è ottimizzato da minuti 113s e 96s, da tick 20:26 e 16:48.
È qui che non capisco. Quali risultati dovrei lasciare nella tabella? E com'è che l'esecuzione di due terminali migliora i risultati?
Imp120, a proposito, ho notato che il tuo portatile e il mio desktop sono molto vicini in termini di prestazioni tabellari. E i risultati sono simili (il tuo è più veloce, ma non di molto).
Mathemat, извините я не точно выразился. Я разделил оптимизацию на два терминала. 102 цикла в одном и столько же в другом. Значения второй переменной в первом были 1 и 4, а во втором 7 и 10. Думал будет в 2 раза быстрее, а получилось в 1.5 ) Просто наводит на размышления, что при равной цене оптимизация быстрее будет на двух компах, чем на одном, но мощном.
Sarebbe più veloce, beep-beep, se gli sviluppatori smettessero di fare beep-beep e facessero un normale tester multithreaded. Altrimenti, bip-bip, dobbiamo moltiplicare i terminali come bip-bip per impegnare i core.
E ciò che è caratteristico, il problema principale del coinvolgimento dei multicore è la cattiva parallelizzabilità dell'algoritmo. Un tester è perfettamente parallelizzabile, cosa che facciamo idioticamente eseguendo copie di esso. Ma ce l'hanno tutti, non i nostri cari sviluppatori! Hanno un altro problema - a giudicare dalla reazione - il personale qualificato. OOP, chiaramente il pioniere, è più importante! (A proposito, non un solo codice pubblicato su 5 usando OOP - tutto procedurale!)
Perdonatemi - sono 20 ore di ottimizzazione in corso, è questo che mi rende nervoso.
Ho questa stupida e ingenua ipotesi che questo è ciò che gli sviluppatori stanno cercando di fare con il tester. Il pulsante del tester di strategia è ancora disabilitato, e c'è una ragione per questo, vero?
Ho questa stupida e ingenua ipotesi che questo è ciò che gli sviluppatori stanno cercando di fare con il tester. Il pulsante del tester di strategia è ancora disattivato, e c'è una ragione per questo...
L'ottimismo è l'essenza di una visione allegra e positiva della vita.
>> È stato detto ripetutamente e inequivocabilmente che non lo farà.
All'inizio, gli sviluppatori hanno anche detto che non ci sarebbe stata alcuna eredità.
E che non ci sarebbero oggetti nei tacchini.
Ma non funziona così...
P.S. Beh, è vero quello che dici: il tester (o meglio l'ottimizzatore) è il più facile da parallelizzare. Mi chiedo se è possibile controllare questo processo, cioè impostare direttamente come distribuire i set di parametri tra i core?
Se Dio vuole...
Con gli oggetti, o piuttosto la loro assenza negli indicatori, è chiaro - l'idiozia della situazione era evidente.
A proposito, la nuova costruzione è già consentita?