mboost-dp1
Microsoft
#13
Har du et link til en benchmark som viser at flere cores
giver mere ved Vista end med XP ?
Og en forklaring på hvilken af ændringerne i Vista som
giver forbedringen ?
Og et bud på hvorfor XP har været crippled ? (hint: Windows 2003
Datacenter Edition understøtter op til 64 CPU'er så MS har vist
i en del år, hvordan man skalerer langt højere end Vista
understøtter)
vista skalerer klart bedre på moderne platforme
Har du et link til en benchmark som viser at flere cores
giver mere ved Vista end med XP ?
Og en forklaring på hvilken af ændringerne i Vista som
giver forbedringen ?
Og et bud på hvorfor XP har været crippled ? (hint: Windows 2003
Datacenter Edition understøtter op til 64 CPU'er så MS har vist
i en del år, hvordan man skalerer langt højere end Vista
understøtter)
#41
Når du skifter til rene 64 bit applikationer bør du opleve
en vis performance forbedring.
Ikke p.g.a. de 64 bit i sig selv, men da AMD alligevel skulle
lave en ændring der gjorde at nye programmer ikke kunne køre
på gammelt hardware, så lagde de lige 8 ekstra registre ind.
Jeg mener at det typisk giver en 10-15%.
Når du skifter til rene 64 bit applikationer bør du opleve
en vis performance forbedring.
Ikke p.g.a. de 64 bit i sig selv, men da AMD alligevel skulle
lave en ændring der gjorde at nye programmer ikke kunne køre
på gammelt hardware, så lagde de lige 8 ekstra registre ind.
Jeg mener at det typisk giver en 10-15%.
#55: Programmerne skal helst være lavet specifikt til 64-bit før det giver nogen forbedring. Lame encoderen kører fx. nogenlunde samme hastighed i 32 og 64 bit. En memcopy operation eller beregninger med 64-bit tal burde dog gå doppelt så stærkt i 64 bit, så vi skal nok få gavn et 64-bit på et tidspunkt, når først koderne begynder at tænke i de baner.
[url]#55[/url] Rent faktisk er der mange områder hvor et 32-bit program kan blive langsommere når det kompileres på 64-bit. Der kan være problemer med cpu cache, bloat i datastrukturer[1] og data alignment problemer.
[1] Et eksempel i C.
struct test {
int i; // 4 bytes data + 4 bytes padding
long l; // 8 bytes
int ii; // 4 bytes data + 4 bytes padding
char *cp; // 8 bytes
}
Vi kan forbedre datastrukturen til 64-bit arkitekturen ved at gruppere i og ii.
De 8 registre er kun relevante når vi snakker floating point operationer og kun i store mængder.
[1] Et eksempel i C.
struct test {
int i; // 4 bytes data + 4 bytes padding
long l; // 8 bytes
int ii; // 4 bytes data + 4 bytes padding
char *cp; // 8 bytes
}
Vi kan forbedre datastrukturen til 64-bit arkitekturen ved at gruppere i og ii.
De 8 registre er kun relevante når vi snakker floating point operationer og kun i store mængder.
#58
Gentag efter mig: et X bit system er et system med X bit
adersser - det er ikke et system med X bit data
typer - det er ikke et system med X bit alignment.
Det er ikke sikkert at long er 64 bit på et 64 bit system.
Faktisk er long kun 32 bit med MS VC++ i 64 bit mode. Man skal
bruge long long eller __int64 for at få en 64 bit integer både
i 32 bit mode og i 64 bit mode.
Det er ikke sikkert at en 32 bit type efterfulgt af en 64 bit
type bliver packed uden padding på et 32 bit system.
Faktisk padder MS VC++ i 32 bit mode i det tilfælde. Default alignment både
i 32 bit mode og 64 bit mode er 64 bit.
Så ikke noget specielt godt eksempel.
En pointer fylder dog mere i 64 bit mode end i 32bit mode.
:-)
Gentag efter mig: et X bit system er et system med X bit
adersser - det er ikke et system med X bit data
typer - det er ikke et system med X bit alignment.
Det er ikke sikkert at long er 64 bit på et 64 bit system.
Faktisk er long kun 32 bit med MS VC++ i 64 bit mode. Man skal
bruge long long eller __int64 for at få en 64 bit integer både
i 32 bit mode og i 64 bit mode.
Det er ikke sikkert at en 32 bit type efterfulgt af en 64 bit
type bliver packed uden padding på et 32 bit system.
Faktisk padder MS VC++ i 32 bit mode i det tilfælde. Default alignment både
i 32 bit mode og 64 bit mode er 64 bit.
Så ikke noget specielt godt eksempel.
En pointer fylder dog mere i 64 bit mode end i 32bit mode.
:-)
#58
Helt forkert.
Der er udvidet fra 8 til 16 GPR, som kun bruges til integer
aritmetik og adressering.
De bør give en lille forbedring.
Størrelsen på forbedringen afhænger af applikation. De fleste
tests i den mest brugte benchmark SPEC viser stor udsving, men
gennemsnitligt næsten ingen forbedring. Men dhrystone og diverse
block ciphers udviser meget store forbedringer.
Overalt må det give en mindre men alligevel klar forbedring
i integer performance.
Floating point performance stiger kraftigt i 64 bit mode.
Der er stadig kun 8 FPR. Men i 64 bit mode bruger den slet ikke FPR men
derimod XMM registre, som også er øget fra 8 til 16. De 8->16 giver ca. samme stigning
som den GPR giver for integer. Men FPR er stack based hvor XMM
er rigtige registre og den ændring giver lige en 30-40% oveni.
De 8 registre er kun relevante når vi snakker floating point operationer og kun i store mængder.
Helt forkert.
Der er udvidet fra 8 til 16 GPR, som kun bruges til integer
aritmetik og adressering.
De bør give en lille forbedring.
Størrelsen på forbedringen afhænger af applikation. De fleste
tests i den mest brugte benchmark SPEC viser stor udsving, men
gennemsnitligt næsten ingen forbedring. Men dhrystone og diverse
block ciphers udviser meget store forbedringer.
Overalt må det give en mindre men alligevel klar forbedring
i integer performance.
Floating point performance stiger kraftigt i 64 bit mode.
Der er stadig kun 8 FPR. Men i 64 bit mode bruger den slet ikke FPR men
derimod XMM registre, som også er øget fra 8 til 16. De 8->16 giver ca. samme stigning
som den GPR giver for integer. Men FPR er stack based hvor XMM
er rigtige registre og den ændring giver lige en 30-40% oveni.
#61
64 bit betyder at memory adresser er 64 bit.
32 bit betyder at memory adresser er 32 bit.
At man gaar fra 32 bit til 64 bit adresser behøver ikke at
betyde at det er hurtigere at ligge to 64 bit hel tal sammen.
Specifikt for x86-64 boer da dog vaere en paen hastigheds
foroegelse, da man ogsaa gaar fra 32 bit registre til 64 bit
registre.
Men der er ingen grund til at tro at det vil vaere lige
praecists dobbelt saa hurtigt. Det kan vaere mere eller
mindre.
Tilsvarende behøver det ikke at vaere hurtigere at flytte
N bytes fra adresse A til adresse B bare fordi A og B er
64 bit adresser.
Specifik for x86-64 vil jeg ikke forvente nogen stor forskel
(jeg mener at der er en speciel instruktion til det).
64 bit betyder at memory adresser er 64 bit.
32 bit betyder at memory adresser er 32 bit.
At man gaar fra 32 bit til 64 bit adresser behøver ikke at
betyde at det er hurtigere at ligge to 64 bit hel tal sammen.
Specifikt for x86-64 boer da dog vaere en paen hastigheds
foroegelse, da man ogsaa gaar fra 32 bit registre til 64 bit
registre.
Men der er ingen grund til at tro at det vil vaere lige
praecists dobbelt saa hurtigt. Det kan vaere mere eller
mindre.
Tilsvarende behøver det ikke at vaere hurtigere at flytte
N bytes fra adresse A til adresse B bare fordi A og B er
64 bit adresser.
Specifik for x86-64 vil jeg ikke forvente nogen stor forskel
(jeg mener at der er en speciel instruktion til det).
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund