Re: kupic xp czy czekac na viste?

Autor: Michal Kawecki <kkwinto_at_o2.px>
Data: Mon 15 Jan 2007 - 02:11:31 MET
Message-ID: <9gkeoe.f9m.ln@kwinto.prv>
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=response

> "Michal Kawecki" <kkwinto@o2.px> wrote in message
> news:lc1doe.stc.ln@kwinto.prv...
>> "Wojtek" <wojtek_84wywalto@poczta.onet.pl> wrote in message
>> news:45a9d1fa$0$13186$f69f905@mamut2.aster.pl...
[...]
>> Zgoda. Limit 4 GB za dwa-trzy lata może się okazać przykrym
>> rozczarowaniem.

Zacytuję jednak pewien post z innej grupy dyskusyjnej (MS):

"Some comments and observations after reading through this thread:

1. most desktop applications (including those that are built to use 64
bit
hardware) will not benefit very much if at all from the larger virtual
or
real address space available in 64 bit Windows. Most such applications
typically use considerably less than 1 GB of address space anyway (use
Task
Manager, or Performance Monitor to verify this for yourself) so the
larger
virtual address space available is not relevant to them.

2. most desktop users don't have more than 4 GB of RAM, so having the
"ability" (in the OS) to support more won't be relevant to them. This
will
change over time, but there a quite a few "current product" (desktop)
motherboards that support a maximum of 4 GB RAM or less anyway. I agree
that the "average" or "typical" RAM complement in desktops and laptops
is
bound to increase as times go by, but it will be a while before most
"typical" users will benefit from more than 4 GB RAM.

3. The larger registers (word size) used in 64 bit processors will be of
most benefit, speed wise, to applications that perform a large number of
high precision arithmetic operations or otherwise are designed to use
the
larger registers, such as scientific data modeling, high performance
games
and image processing. The "Panorama Factory" mentioned in some of the
posts
is one such application. Typical desktop applications (e.g. word
processors) will most likely not benefit appreciably from being re-built
(re-compiled) to use 64 bit instructions because of the byte (character)
oriented nature of their processes. Some current Intel and presumably
AMD
or other processors do have specific instructions for performing
multiple
byte oriented operations concurrently which may also provide a speed
boost
for applications built (compiled) for 64 bit operation - for more
information about this stuff, see for example
ftp://download.intel.com/technology/architecture/new-instructions-paper.pdf)
 - keep in mind that applications have to be specifically coded (or
built
with a development tool that knows how to use them) to use these
"enhanced"
instructions to actually benefit from these architectural "advances".

4. 64 bit operating systems will, generally speaking, require more RAM
to
support the same workload than 32 bit operating systems. This is
because
the data structures used by the OS to manage virtual memory, processes
etc.
have larger "rows" (e.g. 8 bytes instead of 4 bytes per "item"). The
impact
of this will increase as the number of processes increases (for example
in a
Terminal Server supporting a large number of users). Switching from 32
bit
to 64 bit OS for such systems may be actually reduce performance unless
there is sufficient RAM in the hardware. If the hardware is RAM rich
(e.g.
16 GB or more), then the additional real memory capacity will help such
systems to support higher loads if they are memory constrained on 32 bit
systems.

5. Applications (systems) that can benefit from lots of virtual address
space and lots of RAM (e.g. database management, mail servers, search
engines etc.) can really take advantage of 64 bit systems because of the
much larger virtual address spaces available per process and the
increased
maximum RAM supported by the hardware and the operating system. Systems
used to support multiple Virtual Machines will benefit from more RAM.
Keep
in mind that 32 bit Windows servers can use more than 4 GB of RAM quite
effectively using Processor Address Extensions (the PAE option), so 64
bit
Windows is not a pre-requisite for this, although it may be
advantageous.
Be aware that there are no currently available processors or operating
systems in the "Windows/Intel" line that actually implement a full 64
bit
real or virtual address space. See
http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm#64Bit
for more information about this.

6. 64 bit Windows is still relatively new, particularly so in the
desktop
(client) market. This means that there is lots of hardware for which
there
are no 64 bit drivers yet. Some "older" (the meaning of "older" is
subjective - different vendors interpret it differently!) will never
have
drivers for 64 bit Windows. So, just as when Windows 2000 and later
Windows
XP was released, early adopters often find their existing (and newly
purchased) hardware is "not supported".

7. the bottleneck in many cases is disk access, not processor or memory
speed or capacity. Additional RAM can help to provide optimization of
directory and file caching, but the only solution to the disk bottleneck
is
more physical disks (e.g. using "spanning") or disks, controllers and
chipsets with higher data transfer rates.

Two conclusions:
A. 64 bit system overall is not necessarily "faster" or more responsive
than
a 32 bit system on the same or equivalent hardware. In some cases (when
RAM
is in short supply), 64 bit system may be slower or have less capacity.

B. if you are prepared to deal with frustration, search for drivers,
interact (often with little success) with vendor support organizations,
and
want to be on the leading (bleeding?) edge, then by all means use 64 bit
Windows. On the other hand if you just want your system, peripherals
(e.g.
scanners, printers or whatever) to work "out of the box" without
hassles,
for the time being at least, stick to 32 bit Windows.

C. Generally and for "typical" uses, don't expect any big difference in
performance with 64 bit over 32 bit Windows."

-- 
M.   [MS-MVP]
/odpowiadając na priv zmień px na pl/ 
Received on Mon Jan 15 02:20:09 2007

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Mon 15 Jan 2007 - 02:42:02 MET