[JevgeniT]

tere raffas!
millist mälu soovitate masinasse n-force'i alusel:
kas panna 1 moodul 512mb ddr 2700
või 2 moodulit 256 mb ddr 2700?
(koduvideo töötlemiseks)

TANX

abit nf7s
xp2000+
7200.7

[Wiltz]

no kui sul on nforce2, sis otse loomulikult 2*256 saad ju kasutada ka QDR funktsioone sis!

[m1]

Üldiselt vahet pole, sest Athloni FSB on 64 bitine. Kui nüüd võtta, et mälu jookseb samal sagedusel ja on 128 bitine (2 64-bitist mälukontrollerit), siis järelikult sellest eriti kasu ei ole. Lihtsalt FSB võimaldab ainult umbes ühe mälukontrolleri andmed üle kanda ja teine peab ikkagi ootama.

Väike kiirusevõit tegelikult on kahest mälumoodulist, aga üldiselt osta niimoodi, kuidas odavam tuleb.
Kui on sama hinnaga, siis võta 2*256

[Wiltz]

pole seda nforce'i asja veel tõesti just väga uurind, aga kas tõesti on asjast kasu sis 0? minu arvates on see ikka natuke teistmoodi, neil foorsedel ju ikka mingil määral parem perf. kui eelmistel kividel, just 2*ddr kasutades sis ka! kas sis niisama tehti see võimalus neile??? midagi väitma ei hakka, aga m1 oled 100% kindel, et pole mingit vahet?

[JevgeniT]

eile lugesin arvutikasutajat, seal testis olid ram'id ja väike vahe ikka on:
---asus a7n8x, PCmark2002---
apacer pc2700 512mb (256+256) 3330 punkti ehk 6:23:12 423mb pakkimiseks winzipiga
apacer pc2700 256mb (2*256) 3290 punkti ehk 6:21:13 samale task'le

2*256 või 1*512 hind on umbes sama
regards

[JevgeniT]

Aga siis kas video2mpeg2 kodeerimisele on vaja rohkem mälu kiirust või mälu suurust?

[Wiltz]

no kui see kiirusevahe tõesti nii väike on sis pane vast parem panus mälu suurusele 8)

[Arvo Cobrietti]

no ise eelistasks ikka 2x256, samamoodi võiks ju soovitada, et võta CL2,5 mälu, et see on odavam ja perfi vahe pole ka ju suur jne. a no eks vaata neid review'sid ja otsusta, siis ei pea pärast teisi süüdistama.

[m1]

Vahe on siis väike, kui mälu ja FSB on sama taktiga.
Kui sul näiteks FSB on 166 MHz (või kõrgem) ja mälu jookseb 133 peal, siis on kahest mälukanalist küll kasu.

Testides on kah tulemus näha ju. KT400A on korraliku ühe mälukontrolleriga, nForce2 on kahe kontrolleriga. Ja vahe on üsnagi pisikene.
nForce2 puhul on teisest mälukanalist märgatav kasu, kui kasutatakse integreeritud videot.

Kui nüüd rohkem fakte kirja panna siis:
Andmed jõuavad proseni üle põhjasilla, millega on ühendus FSB kaudu. FSB jookseb näiteks 133 MHz peal, ehk bandwidth 133(takt)*2(DDR)*8(64bit)=2128 MB/s

nForce2 puhul on põhjasilla ja mälude vahel 2 mälukanalit, kumbki 64 bitine. Ja kui need nüüd jooksevad samuti 133 MHz peal, siis tulebki välja et kumbki mälukanal on sama läbilaskevõimega kui FSB. Aga et asjast kasu oleks, siis peaks need andmed ka kiirelt proseni jõudma, praegusel juhul aga ei jõua.

Ehk kokkuvõtteks: kui hinnavahe on minimaalne, siis võtta 2*256, aga märgatavalt rohkem ei tasu maksta selle eest (juhul kui integreeritud videot ei kasutata)

[Wiltz]

selge, tnx, et asja väga hästi ära seletasid, ei pidandki seekord ise in inglisss uurima hakkama 8) krt, ma siiamaani olin arvamusel, et tyybid ikka kogu asja tegid "heax", aga vot neegreid, pool jätsid krt tegemata

[stepzter]

[Wiltz]

heh, see on mul siin praegu tõesti ise leiutatud kombinatsioon mingit qdr'i seal loomulikult ei ole, kasutasin quadrot lihtsalt esimese pähe tulnud variandina väljendamax paralleeleset ddr'i ehk veel kahekordistatud mälukanalit põmst.
kuid qdr mäludest, ehk sis tõlkes ilmselt 4 kordse data rate'ga mäludest oli mingi aeg juttu küll nagu?! pidid myyki tulema, ja ddr'i vaixelt asendama. sellest kui siukest asja kuskilt vist lugesin on muidugi juba nii mõnigi aeg mööda läinud

[cbr]

QDR peaks pigem olema DDR2

[Wiltz]

ei ütlex, qdr'i idee oli siiski nagu just mitte kiirusega seda läbilaset suurendada. ddr2 minuteada on lihtsalt kiirem ddr. aga krt, ega ma ei mäleta suurt midagi sellest, vb ajan üldse täielikku jura oma qdr'ga

[stepzter]

Kentron mõtles välja ühe asja, mille ta nimetas quad band memory'ks. See on põmst kahe realine DDR mäludega moodul, kus on veel lisakiibid, mis seavad bitte moodulitest vaheldumisi.
Suhteliselt hea populaarteaduslik kirjeldus sellest: http://www.anandtech.com/chipsets/showdoc.html?i=1709
Esimene chipset peaks nüüd millalgi välja tulema, kui seda projekti vaiba alla ei ole lükatud. Mis on üsna arvatav, kuna VIA'l ei ole minuteada ikka veel P4 litsentsi ja üldse on selle kohapealt väga vaikne olnud.

Iseenesest suudaks NVidia sellega ühtteist peale hakata, kui näiteks 128bit DDR mobosse pista kaks sellist moodulit @ 166MHz, siis oleks süsteemi bandwith 10.8GB, millega saaks juba üsna arvestatava integreeritud videokiibi ära toita.

Muidu ei tea ma ühtegi QDR mälu, mis tavamasinatesse mõeldud oleks. Võrguseadmete jms jaoks toodetavast QDR SRAM kiibist olen midagi kuulnud paar aastat tagasi.
Omapärane, et Intel sellega tegelenud ei ole. 64 bit QDR mälumoodul läheks Inteli 64 bitise "quad pumped" (väga nõme termin minuarust) protsessori siiniga kokku nagu rusikas silmaauku.

[Wiltz]

njah, üks asi on muidugi int.video ära toitmine. kuid, tyybid võiks rohkem üritada ka just seda prose ja põhjakivi vahelist andmevahetust sis tõsta. kas see ei annax ka mitte kyllaltki suurt eelist teiste lahenduste ees? nagu m1 seletas jääb asi prose koha pealt just selle taha pidama. On selle osa kiiruse tõstmine tõesti nii võimatu ül? või liiga kallis?

[m1]

Seda ma täpselt ei tea, aga arvan et see on Athloni arhitektuuriga piiratud. Ehk siis kohe proset disainides otsustati ära, et kasutatakse 64 bitist siini.
Variant on muidugi FSB sagedust tõsta ja sellega nad praegu tegelevadki. Kiireimad prosed on 166 siiniga (ehk 333 marketingikeeles) ja lähiajal peaks ka 200 FSB peal töötavad prosed tulema. Aga see kiirusevõit on üsna väike, prose klokk on ju palju kiiremini kasvanud.

Eks näis, mis lahendus Opteronil ja Athlon64-l kasutusele võetakse.

[Wiltz]

no täpselt, nad peaksid kudagimoodi ka seda prose/põhja vahelist kiirust ikka vähemalt kahekordsex tõstma. sis oleks ikka kõvasti kasu nii nendest tohutu kiirusega mäludest kui ka sellest samast paralleelmälu systeemist.
int.video on ju ikkagi tegelt selline suht mõttetu asi. samas muidugi, seda ütleme meie, nö. fanaatikud nvidiat ja muid tootjaid ainult see ei koti

[stepzter]

Lisa bandwithist on ainult siis kasu, kui arvutusvõimsus on selle poolt piiratud. Ehk prosa ootab täitmisega sellepärast, et andmed ootavad järjekorras, et prosa ja mälu vahelisest torust läbi tulla. See on niimoodi osade andmemahukate algoritmide korral, kus on suurele hulgale andmetele (kus korraga töös olevate andmete hulk ei mahu vahemällu ära) vaja rakendada suhteliselt lihtsaid arvutusreegleid ja tulemused ei ole omavahel seotud. Paraku on väga suur hulk probleemide klasse pigem sellised, kus mälust hangitavad andmed sõltuvad eelmistest tulemustest. (kui a>0 siis b=c+1 muidu b=d+1 jms.) Siis hakkab rolli mängima see, et mälust lugemine on võrreldes protsessori tööga pagana aeglane. Kui käsu täitmisel avastatakse, et andmeid vahemälus ei ole ja ilma nende andmeteta lähitulevikus (nii palju, kui prosa suudab käskude järjestust muuta) midagi mõistlikku teha ei ole, siis peab prosa lihtsalt paarsada takti jalgu kõlgutama.
Seda üritatakse igasuguste meetoditega vähendada, mis kasutavad ära seda, et andmeid mahub läbi rohkem kui vaja, aga kui neid vaja on, siis on neid vaja KOHE. Üks selline variant on jälgida, kui on loetud viimsel ajal mälupesadest 1,3,5,7, siis tõmmata kohe 9,11,13 ka endale kiriesse vahemälusse ära. Kuigi neid ei pruugi vaja minna.

Mul praegu ei ole aega seletada. Ja hiljem ilmselt viitsimist Muidu ma võiks jahuda sel teemal lehekülgede kaupa

Athlon64l ja Opteronil ei olegi muideks põhjasilda kui sellist. Mälud käivad otse prosa külge. See annab natukene muule süsteemile hingamisruumi juurde, aga põhiline kasu on latentsuse vähendamisest, kuna signaal ei pea põhjasillast läbi käima.

[Wiltz]

no jutt on huvitav nagu alati, ja minu pärast lase seda kasvõi lehekylgede kaupa, minu poolt oleks teretulnud 8) ise sedasama asja just õpin nagunii, ja huvi pakub muidugi ka.
kuid asjast rääkides, kui näiteks opteronil on selline paralleel mälukanal kasutusel, sis ta saab mäluga ka kogu selle läbilaske ulatuses suhelda, aga suur osa jääx sellest sis kasutamata? kuid on ju ka võimalik seda andmevahetust nende kompode vahel niimoodi optimiseerida, et vaba ressurssi siiski rohkem kasutama hakatax?
et mälust lugemist võrreldes prosega kiirendada, ma saan aru tuleb mälu enda kiirust, ja settinguid ilmselt samuti, üles lykata. kuid, kas sellega koos ei pea ka siin vastavalt kiiremax minema, või võib näiteks siin olla 166 peal, kui mälu ise töötab juba ütleme 266 peal? just nende antud probleemide puhul sis siin takistama ei jääx nagu ma aru saan?

huvi pärast kysin, stepzter sa õppisid ttü's info teaduskonnas?