Print 78 comment(s) - last by hstewarth.. on Apr 12 at 5:31 PM

Peak growths for DRAM memory have occured with major Windows launches - Courtesy SEC Marketing
How Vista will affect your next memory purchase...

With Windows Vista’s anticipated launch later this year, a concern on everyone’s mind is how Vista will tax existing PC platforms.  Although the new graphical user interface will require DirectX 9 support, and Intel G965 (or better) graphic accelerators, the real question mark in everyone’s minds is where DRAM requirements will head for Windows Vista.  Baseline Vista offerings will require 512MB of DRAM just to install, with a 1GB recommendation -- but is there more to this story?
Integrated graphics from ATI, Intel, and NVIDIA all use shared memory architectures. This means that even though the graphics core is on the motherboard Northbridge, the graphics controller accesses memory from the system main memory.  Low end, PCIe 3D accelerations from ATI, and NVIDIA also use shared memory support, using in excess of 256MB of system DRAM in exchange for a dirt cheap graphics accelerator.  On these systems the Vista recommendation for 512MB is not acceptable as a significant amount of main memory is consumed by the graphics accelerators.
Furthermore, Windows Vista will come with a new feature called Superfetch.  With Windows XP, Microsoft included a feature called Prefetch: a dynamic service that preemptively loads files into the pagefile in order to speed up application load time.  Superfetch advances further in two steps.  Step one is to build profiles of frequently used applications and store those profiles into the pagefile, and system memory.  Step two is to pool NAND and all other available memory to move as much of the pagefile as possible off the hard drive and onto the solid state memory.  As a result, anyone with a heavy usage profile will have a significant portion of their system memory dedicated to application data.  
At IDF we recently had the opportunity to talk to Tom Trill, Samsung Semiconductor's Director of DRAM Marketing.  An interesting point Trill mentioned to us is that system integrators generally spend 6-8% of the system cost on memory. Retail DDR2-667 crossed over into the $80 USD per gigabyte range a few months ago with the price for system integrators hovering around $60.  AMD and Intel both have new processors expected to utilize DDR2-800 before the Q4 launch of Windows Vista. By conservative estimates, we can expect to see the average system integrator bundle new computers with 1GB of DDR2-667 by the end of this year.
Samsung’s internal research recently published a figure claiming that the average PC system (including SI, OEM and home built computers) averages 871MB of DRAM in 2005, up from 620MB the year before.  The DRAM industry has traditionally seen large growth around the launches of Windows operating system such as Windows 95, Windows 98, and Windows XP.  With large growth come large economies of scale, and ultimately lower prices for DRAM are on the horizon.  Furthermore, with cheaper DRAM prices, system integrators are free to integrate more memory into the magic 6-8% budget. With such favorable trends, seeing 2GB of memory as a standard in every PC by the end of this year would be of no surprise to us at all.

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

RE: .
By masher2 on 3/20/2006 12:30:27 PM , Rating: 2
> "No - pointers are 64-bit, but integers/dwords are still 32-bit. "

No, integers are 64 bit, and dwords are 32-bit. This is the ANSI default-- bytes and words are fixed size units, whereas integers depend on the base allocation unit. In 16-bit programming an "int" was only 16 bits.

Still, I believe most if not all development tools will have an option to force ints to 32-bit.

> "I haven't seen any reasons yet that 64-bit anything will require any more memory than 32-bit."

64 bit code *will* require more memory. In the worst case, twice as the best case, a negligible increase. But it will always be larger.

RE: .
By stephenbrooks on 3/20/2006 2:46:45 PM , Rating: 2
Yep, a friend and I compared the size of various default windows utilities between XP and XP 64-bit. There was something like a 30% increase in size going to 64-bit executables.

And now Vista is going to load all those larger executables into RAM. Great. Maybe I might actually want to use my RAM for something other than trying to hide the bloat of such programs as Acrobat Reader or Office, which would load much faster if they were programmed with a "load modules only when needed" approach.

RE: .
By stephenbrooks on 3/20/2006 2:57:22 PM , Rating: 2
RE: .
By TomZ on 3/20/2006 3:48:40 PM , Rating: 2
Are we still talking about Windows?

This page from Microsoft on the topic of 64-bit Windows pretty clearly states "only pointers expand to 64 bits; all other basic data types (integer and long) remain 32 bits in length." default.asp?url=...

RE: .
By masher2 on 3/20/2006 4:26:42 PM , Rating: 2
> "This page from Microsoft on the topic of 64-bit Windows pretty clearly states "only pointers expand to 64 bits"

As already said, this is true only in the LLP64 programming model. Use ILP or LP and its no longer true. And even when LLP is chosen, you still must remember that pointers are also stored as data. So if pointers expands, data storage requirements do as well.

So its more than just code that increases under Win64; data does as well.

RE: .
By TomZ on 3/20/2006 4:34:13 PM , Rating: 2
Microsoft only talks about supporting LLP64. Are you saying that people will be using other models with Win64, or that it is even possible?

RE: .
By masher2 on 3/20/2006 4:55:54 PM , Rating: 2
Sure it is-- its up to the compiler, not the OS. And just think about it...if you couldn't use 64 bit data values when you needed them, there wouldn't be much purpose in 64-bit computing. Sure you get more address space, but if that was the only reason for it, we'd just keep using PAE forever.

Obviously, when interfacing to the Win64 API, you need to adhere to their model. So if you're not using LLP64, you'll need to do some casting or otherwise ensure alignment of data types.

RE: .
By drebo on 3/20/2006 7:31:17 PM , Rating: 2
If 64-bit memory addresses are to be used, pointers MUST be 64-bits long.

Why? Because pointers store memory addresses. You cannot fit a 64-bit memory address into a 32-bit pointer.

Unless, of course, you're talking about relative memory addresses, similar to the way MIPS handles jumps. But, we're not.

RE: .
By masher2 on 3/20/2006 11:39:08 PM , Rating: 2
> "If 64-bit memory addresses are to be used, pointers MUST be 64-bits long."

There's no confusion here; we've already stated just this several times. The issue is over the size of *other* fundamental data types. In LLP64, ints and longs remain at 32-bits.

"Young lady, in this house we obey the laws of thermodynamics!" -- Homer Simpson

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki