Welcome to our website

To take full advantage of all features you need to login or register. Registration is completely free and takes only a few seconds.

Shaping Up Nicely : Microsoft

Posted by: Jim_ on: 08/20/2004 03:53 PM [ Print | 14 comment(s) ]

Comment

HFU SMP Guru Posts: 2000 Joined: 2002-06-15

#31335 Posted on: 08/20/2004 08:06 PM It would be nice to try this latest WinXP 64-bit build. Jim will you be running this on the Nocona/DH800 review? HFU

Comment

terminalrecluse is home now Posts: 3802 Joined: 2004-08-07

#31336 Posted on: 08/20/2004 09:02 PM Downloading it now.... 121 total Ghz, 304GB in total memory... Arch Linux - stable : 3930k @ 4.4Ghz, 64GB DDR3, 120GB Samsung 840, HX850 DAS - Norco 4020 - 20x Seagate 3TB, 1KW PSU FBSD 10 ZFS server - SM Chassis, SM X8DTE, 2x L5520 Xeons, 48GB Reg DDR3 ULP, IBM 5015 w/ 512MB DDR2 cache, RAID-50 - 42TB storage Dell C6100 - 4 nodes, 2 1.1KW psu's, 2x L5520s, 6x e5530s, 192GB reg DDR3 (48GB each), F@H, etc

Comment

i_wolf labhair dom as gaelige Posts: 2097 Joined: 2002-11-19

#31337 Posted on: 08/21/2004 06:33 AM I am very surprised at the Doom3 results and the Photoshop results. Most benchmarks I have seen have always shown the AMD64 architecture to be superior in both of these applications. Photoshop fair enough probably depends onthe filters you are using, however Doom 3 (as the author does mention) does typically run faster on uniprocessor AMD64 platforms.... I would love to know what the reason for that is. Hung like a donkey. Go like a horse!

Comment

accord99 Registered User Posts: 46 Joined: 2004-06-25

#31338 Posted on: 08/21/2004 08:24 AM Originally posted by i_wolf I am very surprised at the Doom3 results and the Photoshop results. Most benchmarks I have seen have always shown the AMD64 architecture to be superior in both of these applications. The P4 has always had the edge in Photoshop versus AMD64 using the standard PSBench for both PS 7 and PS CS. And it wins in total time, geometric mean or geometric mean of the normalized sub-tests.

Comment

terminalrecluse is home now Posts: 3802 Joined: 2004-08-07

#31339 Posted on: 08/21/2004 09:18 AM Is it just me or do games like Doom 3 or the like not take advantage of NUMA? 121 total Ghz, 304GB in total memory... Arch Linux - stable : 3930k @ 4.4Ghz, 64GB DDR3, 120GB Samsung 840, HX850 DAS - Norco 4020 - 20x Seagate 3TB, 1KW PSU FBSD 10 ZFS server - SM Chassis, SM X8DTE, 2x L5520 Xeons, 48GB Reg DDR3 ULP, IBM 5015 w/ 512MB DDR2 cache, RAID-50 - 42TB storage Dell C6100 - 4 nodes, 2 1.1KW psu's, 2x L5520s, 6x e5530s, 192GB reg DDR3 (48GB each), F@H, etc

Comment

HEMI is home now Posts: 2467 Joined: 2001-12-18

#31340 Posted on: 08/21/2004 09:54 AM Originally posted by terminalrecluse Is it just me or do games like Doom 3 or the like not take advantage of NUMA? ... *sigh* Unix is user-friendly; it's just picky about its friends.

Comment

terminalrecluse is home now Posts: 3802 Joined: 2004-08-07

#31341 Posted on: 08/21/2004 10:03 AM Ok so maybe I am just too damn ignorant. But this is what I see and maybe you could clear it up. NUMA = Lots of memory bandwith. Now I am no programmer, but it would seem that games at least would love such things. 121 total Ghz, 304GB in total memory... Arch Linux - stable : 3930k @ 4.4Ghz, 64GB DDR3, 120GB Samsung 840, HX850 DAS - Norco 4020 - 20x Seagate 3TB, 1KW PSU FBSD 10 ZFS server - SM Chassis, SM X8DTE, 2x L5520 Xeons, 48GB Reg DDR3 ULP, IBM 5015 w/ 512MB DDR2 cache, RAID-50 - 42TB storage Dell C6100 - 4 nodes, 2 1.1KW psu's, 2x L5520s, 6x e5530s, 192GB reg DDR3 (48GB each), F@H, etc

Comment

HEMI is home now Posts: 2467 Joined: 2001-12-18

#31342 Posted on: 08/21/2004 10:10 AM [url="http://lse.sourceforge.net/numa/faq/"]NUMA[/url] isn't always the best solution for everything. Unix is user-friendly; it's just picky about its friends.

Comment

rmn oh my, it's huge! Posts: 6013 Joined: 2002-01-26

#31343 Posted on: 08/21/2004 10:42 AM No, NUMA != "lots of memory bandwidth". NUMA = Non-Uniform Memory Architecture. It simply means that not all RAM is connected to the same controller, it has nothing to do with memory bandwidth. In some situations (multiple independent threads acessing independent working sets), it's possible to take advantage of NUMA to operate simultaneously on different areas of RAM. But the speed of individual transfers is the same. Very few applications keep a separate working set for each of its threads (even assuming the application is multi-threaded, which is rare in itself), since this would require twice the RAM (for 2 threads), and makes it harder to keep the data synchronised between the threads. So, in practical terms, the only place where you're likely to see NUMA optimisations on a desktop PC is when running two or more (single-threaded) processes under a multi-tasking OS. RMN ~~~

Comment

HFU SMP Guru Posts: 2000 Joined: 2002-06-15

#31344 Posted on: 08/21/2004 11:00 AM Originally posted by HEMI [url="http://lse.sourceforge.net/numa/faq/"]NUMA[/url] isn't always the best solution for everything. Thx HEMI, this is good read on NUMA. HFU

Comment

Hydra Performance Junkie Posts: 174 Joined: 2001-03-09

#31345 Posted on: 08/22/2004 12:31 AM Originally posted by HEMI [url="http://lse.sourceforge.net/numa/faq/"]NUMA[/url] isn't always the best solution for everything. This FAQ is hopelessly outdated and only applies to old NUMA systems, e.g. Altix, and not Opteron systems. There's a major difference in NUMA systems with memory controllers on-chip (Opteron) and those NUMA systems with external memory controllers (Altix). There is no way that a NUMA capable Opteron system will take longer to access some regions of memory than others compared to a non-NUMA capable Xeon system for instance. Overclocking is a blast! Do I smell something burning?

Comment

mattsteg Senior Member Posts: 990 Joined: 2000-05-07

#31346 Posted on: 08/22/2004 12:50 AM Originally posted by Hydra There is no way that a NUMA capable Opteron system will take longer to access some regions of memory than others compared to a non-NUMA capable Xeon system for instance. I wouldn't go that far. In general terms accessing the other CPU's memory included communicating with what is functionally an off-die memory controller. There is no guarantee that it will be more effective than other contemporary memory controllers, although it certainly shouldn't be *significantly* slower. If you want to quantify the difference just take an Opteron board that uses only one memory controller and perform the single-threaded memory latency benchmark of your choice with affinity set to first one cpu, then the other. Obviously when using the local controller memory performance will be better, and when using the other controller I would expect similar numbers to contemporary Xeon systems, but it's certainly quite possible that a modern Xeon chipset could beat those numbers. Hello.

Comment

XWRed1 Registered User Posts: 185 Joined: 2001-08-27

#31347 Posted on: 08/22/2004 02:47 AM There is no way that a NUMA capable Opteron system will take longer to access some regions of memory than others compared to a non-NUMA capable Xeon system for instance. Huh. Thats not what an AMD rep told me. He told me that it can take longer, but even the longer time of a cpu hitting a memory bank connected to another one is still short compared to the competition because the controllers are so low latency in the first place.

Comment

rmn oh my, it's huge! Posts: 6013 Joined: 2002-01-26

#31348 Posted on: 08/22/2004 04:00 AM I think that's exactly what he was saying: that even when going "the long way", the Opteron still has lower latency. RMN ~~~