PDA

View Full Version : low latency memory...recamenditions..



bunkerratt
01-07-2006, 10:12 AM
just wondering who's running it and how good the performance boost is..i'm going to stash some cash away a little bit at a time and plan on dropping about 250-300 on 2 gigs of pc2 3200 ...it will be going on an asus p5gd2 deluxe.. http://forums.ubi.com/images/smilies/blink.gif

vanjast
01-07-2006, 11:00 AM
Memory is at its lowest latency for the current technology. What really improves performance is on-cpu 1st level cache and then off-cpu 2nd level cache.

As we have no choice about 1st level and very little choice about 2nd level, we are reduced to the amount of Dram memory we can plug onto the mobo. You can put tons of it on but if the OS does not utilise it efficiently it's of no use.

Hyperthreading is another story where the cpu manufacturer is usually a few OS versions ahead. You might have it on your CPU but will the OS and then the Games or software make use of these facilities.

I'll give you an example. *** THIS IS WAY OVER THE TOP *** http://forums.ubi.com/images/smilies/16x16_smiley-very-happy.gif
When doing some programming most developers rely on the compiler to produce code ready for hyper/multi-threading (parallel execution of code). This is because they program in high level languages like C++. This most times leads to code which does not take advantage of the cpu hardware. One has to read the 700+ page DOCCY on the cpu itself to understand all these intricasies and then you'll find that certain 'code sequences work much better' than others, which will allow you to make faster Hyper/multi threaded code.

So essentially we rely on 'Proper' development, and judging by all the BUGs in the games ???? http://forums.ubi.com/images/smilies/51.gif

2 weeks time maybe... http://forums.ubi.com/images/smilies/16x16_smiley-very-happy.gif

gamera67
01-07-2006, 11:02 AM
I've been using PC3200 for a long time now, so I can't really say what I had for a performance boost.
I've been using the same 2 gigs of OCZ Platinum on my last 2 builds.

I've noticed at other sites though, that Corsair seems to be a popular memory to use with Asus boards.
You'll probably be safest going with a brand listed in your M/B manual.

bunkerratt
01-07-2006, 12:04 PM
ok..i have a p-4 h/t 775 3.0 ghz cpu..i understand the program being able to use it is another story..lol..was just thinking if the so-called gaming memory is worth it ..most of my buds say it does speed things along over using what i call standard issue memory..so i might stash the cash and do some more reading..thanks .. http://forums.ubi.com/images/smilies/25.gif

bweiss
01-08-2006, 06:53 AM
I'm using Corsair TwinX1024-3200C2PT (http://www.corsairmemory.com/corsair/products/specs/cmx1024-3200c2.pdf) matched pairs. I think at this point their showing their age a tad. But I like them with my Asus A8V Deluxe since I can overclock the stock values to 2.5-3-3-6, (the 2.5 is recommended for AMD CPU's). Their performance has been rock solid stable. More pertinent to the discussion however, the overclocked values versus stock do tend to speed things up noticeably.

MickeyMouse_
01-09-2006, 09:43 PM
Originally posted by vanjast:
Memory is at its lowest latency for the current technology. What really improves performance is on-cpu 1st level cache and then off-cpu 2nd level cache.
What's off cpu L2 cache? I only know on-chip L1 and L2 cache.


As we have no choice about 1st level and very little choice about 2nd level, we are reduced to the amount of Dram memory we can plug onto the mobo. You can put tons of it on but if the OS does not utilise it efficiently it's of no use.
I think <= ME would not use > 512mb very well, but this was totally fixed with the NT kernel and XP should be able to use any amount you present to it. With the 64bit edition you can use an insane amount of memory, assuming your mobo supports it. http://forums.ubi.com/groupee_common/emoticons/icon_smile.gif Of course, if your most memory intense program uses, for example, 2gb, there's no point in getting 4 gb.


Hyperthreading is another story where the cpu manufacturer is usually a few OS versions ahead. You might have it on your CPU but will the OS and then the Games or software make use of these facilities.
Hyperthreading is mostly just a selling point. All it does is slightly speed up the thread switching on the cpu. It reduces it from like 3us to 1us, a fair percentage maybe, but in real-world use it's not noticeable. Dual-core on the other hand could give quite a speed boost.


I'll give you an example. *** THIS IS WAY OVER THE TOP *** http://forums.ubi.com/images/smilies/16x16_smiley-very-happy.gif
When doing some programming most developers rely on the compiler to produce code ready for hyper/multi-threading (parallel execution of code). This is because they program in high level languages like C++. This most times leads to code which does not take advantage of the cpu hardware. One has to read the 700+ page DOCCY on the cpu itself to understand all these intricasies and then you'll find that certain 'code sequences work much better' than others, which will allow you to make faster Hyper/multi threaded code.
Generally, a compiler won't do any multithreading for you because there are way too many race conditions and data importance conditions for the compiler to know about, it takes a human to know when and when not to multithread. Multithreading really doesn't give much of a speed boost on a single cpu system anyway. After all, the cpu can only do one thing at time, thus doing two pieces of code 'at the same time' will take twice as long. The only time multithreading is really useful is when the cpu has nothing to do, ie, when rendering a scene, reading a file, or networking. Low-level assemble-like optimizations seem to be on the way out. Modern day compilers can already use SSE/SSE2 automatically and can optimize it very well. Generally, optimizing algorithms will give huge improvements over low level optimizations. EG, if you can quickly cut out just one more object that can't be colliding in the collision detection code, you'll get much more performance than any amount of assembly optimizations.

Sorry for going OT. http://forums.ubi.com/groupee_common/emoticons/icon_smile.gif