[Pc_Support] Re: Vista hardware requirements - MS speaker full of it? (YES)

[Bryan J. Smith]

Damien McKenna <dmckenna at thelimucompany.com> wrote:
> http://www.apcstart.com/teched/pivot/entry.php?id=6
> "If you move from 32 to 64 bit, you basically need to at
> least double your memory. 2 gigs in 64 bit is the
equivalent
> of a gig of RAM on a 32bit machine. That's because you're
> dealing with chunks that are twice the size..."
> My take on this is that the extra bloating is due to code
> inefficiency and not a 32bit vs 64bit thing.  Am I correct?
 

Yes, for the most part.  It's the same issue Microsoft has
with Windows NT 3.1 and Win16 on Win32 (WoW), only now for
NT5.1/6.0's Win32 on Win64 (WoW, again).  But we'll get to
that in a moment.

To start, here's the FUD busting ...

1.  Pointers are _still_ 48-bit

Even in 32-bit and PAE 36-bit (what I call PAE36) memory
models, pointers are _always_ 48-bit.  Even if they are
"normalized" into 32-bit physical values, or 3-level pages
for PAE 36-bit, they are 48-bit.  The PAE 52-bit (what I call
PAE52, even though the CPU's addressing is fully PAE 36-bit
compatible) memory model is known as "Long" mode for a reason
-- the 16-bit segment + 32-bit offset registers do _not_
change.  This is why AMD's current x86-64 model is limited to
48-bit/256TiB physical memory (which is a long story, but
x86-64 basically adds a level-4 page for full 48-bit/PAE52
addressing).

2.  Registers can still be 32-bit

There's _nothing_ forcing use of 64-bit registers.  EAX, EBX,
etc... still exist.  Furthermore, IIRC, x86-64 4K paging is
still optimized just as x86, on 4-bytes (32-bits).  There are
only 2 things that would use more memory:  

A.  Greater use of stack space

Events, interrupts, etc... will often cause the full 64-bit
ALU registers to be saved, consuming more stack space.  This
adds much of the 10+% memory usage when a PAE52 kernel is
executing.

B.  Poor compiler targetting, library standards

The other issue is poor compiler targetting/usage.  Compilers
that change the default integer data type to 64-bit on an
x86-64 target will, obviously, change usage.  In the GNU
world, portability guidelines typically force coders to want
to use the int32[s|u], int64[s|u], etc..., endianness, byte
order, etc... explicitly.  In the x86-only Windows world,
Microsoft itself writes generic C code based on assumptions
in the 32-bit x86 architecture (which is why non-x86 NT died
rather quickly), and that includes the massive history of
win16/win32 that will _not_ be re-written.

This, in fact, goes to the heart of why Win32 is not Win64
portable, and the resulting, new generation WoW subsystem. 
I.e., the clusterfsck is self-perpetuating into one massive
circle-jerk.

Which is where 80% of the problem comes from.  The overhead
of the WoW subsystem -- loading a WoW "virtual machine" (of
sorts) for _every_single_ Win32 application that runs on
Win64.  And when I say "Win32 application," I mean about 90%
of the libraries and applications that come with 64-bit
editions of Windows itself!  That's the problem.

In GNU/Linux, distros are either shipping less than 10% of
additional, 32-bit libraries under /lib, and all PAE52
libraries under /lib64 -- or they are shipping a "pure" PAE52
distro, with a chroot environment for a few 32-bit
binaries/libraries.  Because the OS is almost entirely
"64-bit clean," it is not a self-clusterfsck'ing OS.

> It just sounds strange.
> Does Linux have the same problem, its been 64bit-clean for,
> what, ten years?

Exactomundo.  Digital produced a 64-bit (40-bit physically)
addressing version of Windows for Alpha 164A/264, but porting
Win32 became a nightmare.

> His comment on gfx card requirements pretty much follows
> BS's comments on Microsoft's graphics subsystem to a T.
> Basically because their code / subsystems are so bad it'll
> take a seriously high end system to do the graphical
touches
> compared to the efficient systems in OSX and OSS (GLX,
> Looking Glass, etc) graphical environments which get much
> more results from much less resources.

The NT Graphical Display Interface (GDI) and DirectX were
_never_ supposed to co-exist.  In fact, the GDI was designed
with OpenGL in mind, complementary.  It wasn't until DirectX
7 (1999) was integrated in NT5 (2000) that Microsoft could
even do "hardware acceleration" of DirectX alongside GDI --
because Direct DOS Memory Map started on DOS 7.x (Win95/98). 
And even now, DirectX 9.1 for seemless 3D objects atop of the
GDI is still _slower_ than OpenGL on Windows itself.

Now you're going to have the Avalon subsystem, which will not
only have an incomplete DirectX 9.1 in the Windows Graphics
Foundations (WGF) 1.1, but the whole GDI/MultiWin atop of it
for compatibility with the majority of applications -- even
from Microsoft itself.  Microsoft is going its best to come
up with various "hacks" in WGF 1.1 to offset the overhead.

One is what X11 did pre-Cairo/LookingGlass (can't remember
the extension, is it Xv?), to just use video memory as "dumb
memory" to store things, and map that as virtual memory.  In
other words, you're still _not_ using the graphics processor
unit (GPU) to manage windows directly, which is the ultimate
in performance -- not just 2D, but especially for 3D.  But
instead of using main memory to handle overlapping windows,
which is what would normally happen, it uses memory on the
video card.  I.e., the X11 server fools the system so memory
copies don't have to go back and forth over the AGP/PCIe bus
to the video card -- drasically improving simple 2D window
(e.g., GDI, standard X11, etc...) performance.  It's a very
simple hack that drastically cuts down on overhead, but it
_requires_ a video card with a lot of memory.   Meaning on a
video card with little memory -- or worse yet, the
"TurboCache" -- performance will actually be _reduced_ versus
not using the hack.

> But the general public is used to having to
> upgrade their systems so won't think twice about it,

Exactomundo.

Most consumers believe when they upgrade just 1 of the 4: 
OS, applications, system or peripherals -- they have to
upgrade _all_ 4 at the same time.  And that's where the OEMs
_and_ superstores come together.

> meanwhile the PC manufacturers are kept happy because
> there's yet another reason to push people to upgrade.

Exactomundo.  Sadly enough, what WGF 1.1 will do with a
nVidia G70 (GeForce 7800GTX) can be _blown_away_ with an old
NV11 (GeForce2 MX200) on MacOS X with QuartzExtreme, or
FreeDesktop.ORG Cairo or Sun's LookingGlass.

Hacks like Xv, which is basically what Microsoft is doing in
WGF 1.1, are rather _pathetic_ in comparison to true GPU
2D/3D control of the framebuffer and 0 by the graphics
server.


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)