---

Hej med jer,

Er der forskel i hastigheden på om man køber 2 RAM-blokke eller 1?
Selvfølgelig forudsat at den samlede mængde RAM samt bus-hastighed og cache
latency er ens.

Devast8or

---

Devast8or skrev bl.a.:

> Er der forskel i hastigheden på om man køber 2 RAM-blokke eller 1?
> Selvfølgelig forudsat at den samlede mængde RAM samt bus-hastighed og
> cache latency er ens.

Ja, og den er så markant, at du skal sørge for at have massivt læsestof
liggende ved siden af computeren, når du skal arbejde......

DÅÅÅHH!

Hvordan havde du forestillet dig, at du på nogen måde kan registerer
hastighedsforeskelle som måles i brøkdele nanosekunder??

Nogle gange er I ret langt ude...

Claus

---

"Claus Tersgov" <nospamnews@tersgov.dk> wrote in
news:485fdc19$0$90265$14726298@news.sunsite.dk:

> Devast8or skrev bl.a.:
>
>> Er der forskel i hastigheden på om man køber 2 RAM-blokke eller 1?
>> Selvfølgelig forudsat at den samlede mængde RAM samt bus-hastighed og
>> cache latency er ens.
>
> Ja, og den er så markant, at du skal sørge for at have massivt læsestof
> liggende ved siden af computeren, når du skal arbejde......
>
> DÅÅÅHH!
>
> Hvordan havde du forestillet dig, at du på nogen måde kan registerer
> hastighedsforeskelle som måles i brøkdele nanosekunder??
>
> Nogle gange er I ret langt ude...
>
> Claus
>
>
Måske en bus-chauffør kan svare på bussens nogenlunde hastighed, meeeen
de plejer aldrig at kravle over 80-100, hurtigere er fy

--
Henrik Laursen

---

On Mon, 23 Jun 2008 18:31:27 +0200, "Devast8or"
<invalid@invalid.invalid> wrote:

>Er der forskel i hastigheden på om man køber 2 RAM-blokke eller 1?
>Selvfølgelig forudsat at den samlede mængde RAM samt bus-hastighed og cache
>latency er ens.

Det kommer helt an på den specifikke hardware.

Hvis hardwaren understøtter dual-channel, så vil to RAM-blokke
fordoble den hastighed hvormed CPU'en kan flytte data til/fra RAM'en.

http://en.wikipedia.org/wiki/Dual_channel

Men det er summen af mange forskellige faktorer der bestemmer ydelsen
af det samlede system. I praksis kan du nok forvente at dual channel
vil forbedre computerens ydelse med 4 - 8 %.

<mlr>

---

Michael Rasmussen skrev bl.a.:

> Hvis hardwaren understøtter dual-channel, så vil to RAM-blokke
> fordoble den hastighed hvormed CPU'en kan flytte data til/fra RAM'en.

Så man man da håbe, at cpuen ved, at nu skal den pludselig arbejde dobbelt
så stærkt!

Dit udsagn er IKKE korrekt..

Claus

---

On Mon, 23 Jun 2008 22:43:46 +0200, "Claus Tersgov"
<nospamnews@tersgov.dk> wrote:

>> Hvis hardwaren understøtter dual-channel, så vil to RAM-blokke
>> fordoble den hastighed hvormed CPU'en kan flytte data til/fra RAM'en.
>
>Så man man da håbe, at cpuen ved, at nu skal den pludselig arbejde dobbelt
>så stærkt!

Næh, CPU'en arbejder ikke hurtigere. Den får bare lidt hurtigere
adgang til RAM'en...

>Dit udsagn er IKKE korrekt..

Du er hård i dine udtalelser, Claus. Lidt mere ydmyghed ville ikke
skade dig

Moderne CPU'er har clock-frekvens i giga-hertz området. Det kan RAM'en
slet ikke følge med til. Clock-frekvensen til en hukommelses celle
ligger fortsat nede omkring 200 - 266 MHz....

Hvis ikke CPU'en skal sidde uvirksom det meste af tiden og vente på
RAM'en, må man derfor finde teknikker der kan øge data båndbredden til
RAM'en.

Det kan f.eks være DDR-RAM (Double Data Rate) der kan overføre 2 bit i
hver clock cyclus. En videre udvikling DDR2-RAM flytter 4 bit i hver
clock cyclus

http://en.wikipedia.org/wiki/DDR2_SDRAM

En anden teknik er dual channel hvor RAM'en opdeles i to kanaler der
kan addresseres skiftevis

http://en.wikipedia.org/wiki/Dual_channel


<mlr>

---

"Michael Rasmussen" <michael@invalid> wrote in message
news:gn6064ts0eal9fl400ckr4rta2eh2p7bnu@4ax.com

> Du er hård i dine udtalelser, Claus. Lidt mere ydmyghed ville ikke
> skade dig

Han har jo ret.


> En anden teknik er dual channel hvor RAM'en opdeles i to kanaler der
> kan addresseres skiftevis

Og derved opstår der ingen hastigheds forøgelse.

--
MVH. N_B_DK
KVM consol købes (1024X768 eller højere)
Pioneer CLD-D925 købes.

---

N_B_DK wrote:

>> En anden teknik er dual channel hvor RAM'en opdeles i to kanaler der
>> kan addresseres skiftevis
> Og derved opstår der ingen hastigheds forøgelse.

Jo, for CPU'en kan hente/skrive data i stedet for at indføre wait states.

Det kræver dog at de data der skal bruges rent faktisk ligger på den
anden channel.


--
Mvh
Jesper Poulsen

---

"Jesper Poulsen" <nospam@ingensteder.dk> wrote in message
news:4861ec7c$0$15886$edfadb0f@dtext01.news.tele.dk
> Det kræver dog at de data der skal bruges rent faktisk ligger på den
> anden channel.

nemlig.

--
MVH. N_B_DK
KVM consol købes (1024X768 eller højere)
Pioneer CLD-D925 købes.

---

Claus Tersgov wrote:

> Michael Rasmussen skrev bl.a.:

>> Hvis hardwaren understøtter dual-channel, så vil to RAM-blokke
>> fordoble den hastighed hvormed CPU'en kan flytte data til/fra RAM'en.

> Så man man da håbe, at cpuen ved, at nu skal den pludselig arbejde
> dobbelt så stærkt!

nja, færre wait-states er nok en mere korrekt måde at se på det på,
afhængigt af andre ting, som andre har skrevet bedre om end jeg kan.

Med venlig hilsen

Peter Larsen

---

Michael Rasmussen wrote:

> af det samlede system. I praksis kan du nok forvente at dual channel
> vil forbedre computerens ydelse med 4 - 8 %.

Det afhænger også af om programmerne er optimeret til dual channel. Far
Cry er feks. ikke optimeret til dual channel og vil derfor yde bedst på
et single channel system.


--
Mvh
Jesper Poulsen

---

Jesper Poulsen wrote:
> Michael Rasmussen wrote:
>
>> af det samlede system. I praksis kan du nok forvente at dual channel
>> vil forbedre computerens ydelse med 4 - 8 %.
>
> Det afhænger også af om programmerne er optimeret til dual channel. Far
> Cry er feks. ikke optimeret til dual channel og vil derfor yde bedst på
> et single channel system.
>
>

Hvorhenne har du dét der fra? (really curious to know :))
Det lyder besynderligt at interleaving mellem RAM skulle skade ydelsen
og at programmørerne af det spil blander sig i hvordan RAM er
konfigureret... tager spillet også skade af SLI så ?


mvh.
Claus

---

Claus Albæk (Kbh.) wrote:

> Hvorhenne har du dét der fra? (really curious to know :))

Søg lidt på Google, min ven.
http://www.behardware.com/articles/531-6/testing-12-athlon-64s.html
Læg især mærke til forskellen mellem A64 3000+/3200+ for de to sockets.

> Det lyder besynderligt at interleaving mellem RAM skulle skade ydelsen

Jeg har været inde på problemstillingen her i gruppen for ca. 2-3 år
siden. Data bliver gemt/hentet i følgende rækkefølge blok0 -> blok1 ->
blok0 -> blok1 -> etc. - right?
Hvis programmet så forventer at data hentes/gemmes i rækkefølgen blok0
-> blok0 -> blok0, så vil der opstå et ydelsestab.

> konfigureret... tager spillet også skade af SLI så ?

Ja, hvis spillet ikke er forberedt på SLI.

Utallige tests har vist markant performancenedgang, når spil ikke har
været optimeret til at kunne anvende SLI.


--
Mvh
Jesper Poulsen

---

Jesper Poulsen wrote:
> Claus Albæk (Kbh.) wrote:
>
>> Hvorhenne har du dét der fra? (really curious to know :))
>
> Søg lidt på Google, min ven.
> http://www.behardware.com/articles/531-6/testing-12-athlon-64s.html
> Læg især mærke til forskellen mellem A64 3000+/3200+ for de to sockets.
>

Jeg kan se hvad du mener, men her mener jeg måske at der er for megen
disparitet i hardware. jeg har fundet et andet link som måske er mere
homogent:
http://www.tcmagazine.com/articles.php?action=show&showarticle=128
De bemærker også at der er besynderligt at DC skulle give mindre ydelse
end SC, bevares at DC's forbedring af ydelsen over SC kan være minimal,
men ligefrem dårligere stiller jeg mig også undrende overfor.

>> Det lyder besynderligt at interleaving mellem RAM skulle skade ydelsen
>
> Jeg har været inde på problemstillingen her i gruppen for ca. 2-3 år
> siden. Data bliver gemt/hentet i følgende rækkefølge blok0 -> blok1 ->
> blok0 -> blok1 -> etc. - right?
> Hvis programmet så forventer at data hentes/gemmes i rækkefølgen blok0
> -> blok0 -> blok0, så vil der opstå et ydelsestab.

Helt enig, men jeg mener... Far Cry er vel skrevet til et API hvor
spilprogrammøren ikke har nogen reel kontrol over hvor data bliver
skrevet til hvilken hardware.

>> konfigureret... tager spillet også skade af SLI så ?
>
> Ja, hvis spillet ikke er forberedt på SLI.
>
> Utallige tests har vist markant performancenedgang, når spil ikke har
> været optimeret til at kunne anvende SLI.

Også til en sådan grad at ydelsen har været mindre end non-SLI?

Mvh.
Claus

---

Claus Albæk (Kbh.) wrote:

>> Læg især mærke til forskellen mellem A64 3000+/3200+ for de to sockets.
> Jeg kan se hvad du mener, men her mener jeg måske at der er for megen
> disparitet i hardware. jeg har fundet et andet link som måske er mere

Vi er enige om at s939 er nyere og bedre end s754, ikk'?

> end SC, bevares at DC's forbedring af ydelsen over SC kan være minimal,
> men ligefrem dårligere stiller jeg mig også undrende overfor.

DC giver en teoretisk forbedring. Hvis man skriver programmer specifikt
til at udnytte det vil man også få et markant boost i performance.

> Helt enig, men jeg mener... Far Cry er vel skrevet til et API hvor
> spilprogrammøren ikke har nogen reel kontrol over hvor data bliver
> skrevet til hvilken hardware.

Derfor kan man stadig indbygge et forbehold for at sekventielle data
(set fra programmets side) ikke skal hentes i det samme RAM-modul. Det
er langt hen ad vejen muligt at forudsige hvor data gemmes, såfremt man
håndterer dem i passende størrelser. Hvis alle data internt håndteres
som 128 bit, så vil de også blive gemt som 128 bit (2x64 bit). Hvis ikke
man tager dette forbehold, så kan man risikere at 2 på hinanden følgende
datalæsninger skal foretages i det samme modul.

Blev det forståeligt?

>> Utallige tests har vist markant performancenedgang, når spil ikke har
>> været optimeret til at kunne anvende SLI.
> Også til en sådan grad at ydelsen har været mindre end non-SLI?

Ja, det er jeg også faldet over.


--
Mvh
Jesper Poulsen

---

On Tue, 24 Jun 2008 13:08:51 +0200, Jesper Poulsen
<nospam@ingensteder.dk> wrote:

>> end SC, bevares at DC's forbedring af ydelsen over SC kan være minimal,
>> men ligefrem dårligere stiller jeg mig også undrende overfor.
>
>DC giver en teoretisk forbedring. Hvis man skriver programmer specifikt
>til at udnytte det vil man også få et markant boost i performance.
>
>> Helt enig, men jeg mener... Far Cry er vel skrevet til et API hvor
>> spilprogrammøren ikke har nogen reel kontrol over hvor data bliver
>> skrevet til hvilken hardware.
>
>Derfor kan man stadig indbygge et forbehold for at sekventielle data
>(set fra programmets side) ikke skal hentes i det samme RAM-modul. Det
>er langt hen ad vejen muligt at forudsige hvor data gemmes, såfremt man
>håndterer dem i passende størrelser. Hvis alle data internt håndteres
>som 128 bit, så vil de også blive gemt som 128 bit (2x64 bit). Hvis ikke
>man tager dette forbehold, så kan man risikere at 2 på hinanden følgende
>datalæsninger skal foretages i det samme modul.

Her tror jeg du er på vej langt ud af en tangent, Jesper.

CPU'en, og dermed programmet / programmøren, ser RAM'en gennem L1 / L2
cachen, paging arkitekturen mv....

Jeg kan ikke se hvordan programudvikleren skal kunne forudsige hvornår
og hvordan data gennem til RAM'en.....

<mlr>

---

Michael Rasmussen wrote:

> Her tror jeg du er på vej langt ud af en tangent, Jesper.

Næ, nej.

> CPU'en, og dermed programmet / programmøren, ser RAM'en gennem L1 / L2
> cachen, paging arkitekturen mv....

Korrekt, og?

> Jeg kan ikke se hvordan programudvikleren skal kunne forudsige hvornår
> og hvordan data gennem til RAM'en.....

Man kan tvinge den til at gemme data i begge moduler ved at angive alle
datastørrelser som 128 bit. Det er ikke hardwarens opgave at splitte
data op. Det er heller ikke OS'ets opgave at splitte data op. Derfor vil
man få fuld udnyttelse af DC hvis man sikrer 128 bit data _altid_.


--
Mvh
Jesper Poulsen

---

On Wed, 25 Jun 2008 08:56:02 +0200, Jesper Poulsen
<nospam@ingensteder.dk> wrote:

>> Her tror jeg du er på vej langt ud af en tangent, Jesper.
>
>Næ, nej.
>
>> CPU'en, og dermed programmet / programmøren, ser RAM'en gennem L1 / L2
>> cachen, paging arkitekturen mv....
>
>Korrekt, og?
>
>> Jeg kan ikke se hvordan programudvikleren skal kunne forudsige hvornår
>> og hvordan data gennem til RAM'en.....
>
>Man kan tvinge den til at gemme data i begge moduler ved at angive alle
>datastørrelser som 128 bit. Det er ikke hardwarens opgave at splitte
>data op. Det er heller ikke OS'ets opgave at splitte data op. Derfor vil
>man få fuld udnyttelse af DC hvis man sikrer 128 bit data _altid_.

Her forudsætter du at cachen er write-through og CPU'en dermed skriver
direkte til system RAM'en. Det er nok ikke tilfældet.

Mig bekendt fungerer cachen på Intels CPU'er som write-back. CPU'en
skriver altså til cachen. Det er memory controlleren der overfører
data mellem cache og system-RAM, og det sker i blokke á 4 Kbyte.

Jeg skal læse tlidt på emnet i aften. Vender tilbage hvis jeg finder
et passende link

<mlr>

---

Michael Rasmussen wrote:

> Her forudsætter du at cachen er write-through og CPU'en dermed
> skriver direkte til system RAM'en. Det er nok ikke tilfældet.

Nej, det gør jeg ikke.

Jeg tvinger blot systemet til at håndtere data så de ende skiftevis på
den ene og den anden channel. En 128 bit datastreng vil ende på begge
channels, hvis hardwaren er rigtigt lavet.


--
Mvh
Jesper Poulsen

---

On Thu, 26 Jun 2008 00:11:35 +0200, Jesper Poulsen
<nospam@ingensteder.dk> wrote:

>> Her forudsætter du at cachen er write-through og CPU'en dermed
>> skriver direkte til system RAM'en. Det er nok ikke tilfældet.
>
>Nej, det gør jeg ikke.
>
>Jeg tvinger blot systemet til at håndtere data så de ende skiftevis på
>den ene og den anden channel. En 128 bit datastreng vil ende på begge
>channels, hvis hardwaren er rigtigt lavet.

Du misser pointen...

Hvis CPU'ens cache fungerer som write-back, så sker skrivning til
system-RAM i større blokke på måske 512 - 4096 bytes, ikke som bytes,
words, dwords el.

Og dermed kan du ikke "tvinge den til at gemme data i begge moduler
ved at angive alle datastørrelser som 128 bit".

<mlr>

---

On Thu, 26 Jun 2008 00:11:35 +0200, Jesper Poulsen
<nospam@ingensteder.dk> wrote:

>Jeg tvinger blot systemet til at håndtere data så de ende skiftevis på
>den ene og den anden channel. En 128 bit datastreng vil ende på begge
>channels, hvis hardwaren er rigtigt lavet.

Hermed det lovede link der forklarer lidt om CPU cachen

http://lwn.net/Articles/252125/

Som jeg læser teksen overføres data mellem cache og system-RAM ganske
rigtigt i større blokke (her kaldet cache line), ikke som
bytes/words/dwords.

<mlr>