«

I could have sworn that previous things i had read, stated that running x64
vista was generally 5-20% slower than the x86 version?

I ran some recent tests on my hardware with PerformanceTest v6.1 (an x86
version and x64 version)...

My base computer is a 1.86GHZ dual core with 4gb memory and a geforce 8600GT
pci-e x16 card.. the harddrives are all SATAII.

I kept the software set identical on each machine, each machine was bare
formatted and then only a handful of apps installed.. same configs on each:

My basic Passmark rating on x86 was 472.2 and 575.1 on x64 (so x64 was 17.9%
better overall).


I did the run all tests option (and clicked cancel when it tried to test the
Cdrom)... The x86 lagged behind the x64 in all areas except CPU find prime
numbers, CPU string sorting.. Disk sequential read (so in these 3 categories
the x86 version performed better)...

I'm guessing that x86 probably has better load times on apps, hence the
whole 20% better with x86 type statements, but not really regarding overall
peformance?

Anyone have any thoughts?



Thanks

No one here should have told you x64 was slower. Oh, it _might_ be very
slightly for a 32-bit app, depending on the app. But in most cases it will
be faster or the same even for 32-bit apps. The single biggest reason is the
I/O subsystem, which is 64bits wide and faster accessing the disks. But
overall? I would definitely expect x64 to be faster or the same on
indentical hardware. (and note that while you only have 4GB of RAM, x64 will
let you use all of it. x86 will not. And you can generally go up to 8 GB of
RAM on a typical DDR2 or DDR3 motherboard - 32-bit Windows is NOT going to
see any of that RAM past 4GB.)

--
Charlie.
http://msmvps.com/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel


"markm75" <> wrote in message
news:7F5E6B9A-F851-473C-9A71-...
>I could have sworn that previous things i had read, stated that running x64
> vista was generally 5-20% slower than the x86 version?
>
> I ran some recent tests on my hardware with PerformanceTest v6.1 (an x86
> version and x64 version)...
>
> My base computer is a 1.86GHZ dual core with 4gb memory and a geforce
> 8600GT
> pci-e x16 card.. the harddrives are all SATAII.
>
> I kept the software set identical on each machine, each machine was bare
> formatted and then only a handful of apps installed.. same configs on
> each:
>
> My basic Passmark rating on x86 was 472.2 and 575.1 on x64 (so x64 was
> 17.9%
> better overall).
>
>
> I did the run all tests option (and clicked cancel when it tried to test
> the
> Cdrom)... The x86 lagged behind the x64 in all areas except CPU find
> prime
> numbers, CPU string sorting.. Disk sequential read (so in these 3
> categories
> the x86 version performed better)...
>
> I'm guessing that x86 probably has better load times on apps, hence the
> whole 20% better with x86 type statements, but not really regarding
> overall
> peformance?
>
> Anyone have any thoughts?
>
>
>
> Thanks
>
>
>

My laptop with XP32:
http://service.futuremark.com/orb/pr...jectId=1204661

My laptop with XP64:
http://service.futuremark.com/orb/pr...jectId=4123478

Will XP64 always be faster than XP32 under every single possible set
of conditions? No.

Does XP64 have the potential to be as fast as, if not faster than,
XP32, under normal conditions? Yes.

64-bit Windows deals with more info, so yes, there is some additional
churning for that. But at least when comparing XP32 to XP64, remember
XP64 is based on the Win2K3 codebase, which is generally considered
more tweaked than XP32. It all evens out at the end I think, tho
XP64's servery style may help with server-centric operations, like
hard disk access.

Those are 3DMark06 artificial benchmarks, but unfortunately the URLs
don't work for me, prolly because I have to be logged in as you to see
your the project details. Post the SM 2.0, SM 3.0 and CPU test results
and maybe we could figure out what's going on. You do realize that
Futuremark does not officially support x64 Windows in any flavor, don't you?

In any case, the key work here is "artificial". 3DMark06 is a nice tool
for tuning your system, but it is not always a good predictor of real
world performance in specific games, etc.. My personal experience (both
with XP and Vista) is that the 32 and 64 bit versions of each OS perform
about the same with 3DMark06. You have to use the same video driver
version and keep everything else constant. When Vista first was
released, it was significantly slower than XP (again both 32 and 64 bit
versions), but as the video drivers improved and Vista was patched,
there is very little difference in performance, at least using 3DMark06
as the yardstick.

S.SubZero wrote:
> My laptop with XP32:
> http://service.futuremark.com/orb/pr...jectId=1204661
>
> My laptop with XP64:
> http://service.futuremark.com/orb/pr...jectId=4123478
>
> Will XP64 always be faster than XP32 under every single possible set
> of conditions? No.
>
> Does XP64 have the potential to be as fast as, if not faster than,
> XP32, under normal conditions? Yes.
>
> 64-bit Windows deals with more info, so yes, there is some additional
> churning for that. But at least when comparing XP32 to XP64, remember
> XP64 is based on the Win2K3 codebase, which is generally considered
> more tweaked than XP32. It all evens out at the end I think, tho
> XP64's servery style may help with server-centric operations, like
> hard disk access.

"about the same" is what I'd generally expect. Any benchmark that is highly
disk I/O centric, however, I'd expect to be faster in XP x64.

--
Charlie.
http://msmvps.com/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel


"jabloomf1230" <> wrote in message
news:%...
> Those are 3DMark06 artificial benchmarks, but unfortunately the URLs don't
> work for me, prolly because I have to be logged in as you to see your the
> project details. Post the SM 2.0, SM 3.0 and CPU test results and maybe we
> could figure out what's going on. You do realize that Futuremark does not
> officially support x64 Windows in any flavor, don't you?
>
> In any case, the key work here is "artificial". 3DMark06 is a nice tool
> for tuning your system, but it is not always a good predictor of real
> world performance in specific games, etc.. My personal experience (both
> with XP and Vista) is that the 32 and 64 bit versions of each OS perform
> about the same with 3DMark06. You have to use the same video driver
> version and keep everything else constant. When Vista first was released,
> it was significantly slower than XP (again both 32 and 64 bit versions),
> but as the video drivers improved and Vista was patched, there is very
> little difference in performance, at least using 3DMark06 as the
> yardstick.
>
> S.SubZero wrote:
>> My laptop with XP32:
>> http://service.futuremark.com/orb/pr...jectId=1204661
>>
>> My laptop with XP64:
>> http://service.futuremark.com/orb/pr...jectId=4123478
>>
>> Will XP64 always be faster than XP32 under every single possible set
>> of conditions? No.
>>
>> Does XP64 have the potential to be as fast as, if not faster than,
>> XP32, under normal conditions? Yes.
>>
>> 64-bit Windows deals with more info, so yes, there is some additional
>> churning for that. But at least when comparing XP32 to XP64, remember
>> XP64 is based on the Win2K3 codebase, which is generally considered
>> more tweaked than XP32. It all evens out at the end I think, tho
>> XP64's servery style may help with server-centric operations, like
>> hard disk access.

Charlie Russel - MVP wrote:
> No one here should have told you x64 was slower. Oh, it _might_ be very
> slightly for a 32-bit app, depending on the app. But in most cases it
> will be faster or the same even for 32-bit apps. The single biggest
> reason is the I/O subsystem, which is 64bits wide and faster accessing
> the disks. But overall? I would definitely expect x64 to be faster or
> the same on indentical hardware. (and note that while you only have 4GB
> of RAM, x64 will let you use all of it. x86 will not. And you can
> generally go up to 8 GB of RAM on a typical DDR2 or DDR3 motherboard -
> 32-bit Windows is NOT going to see any of that RAM past 4GB.)
>

Dear Charlie:

I'm a compiler writer. I spent about 8 months porting a 32-bit compiler
to 64 bits a year-and-a-half ago. My software is used for
discrete-event simulation, which is almost always 100% CPU-bound and
does lots of list processing and logic, and a modest amount of floating
point. In my experience, these applications generally run roughly 6-7%
slower in 64-bit mode, compared to 32-bit mode. Since pointers are
twice as wide, it's understandable that heavy list-processing might be
slower.

I also do some 3D graphics work that's long on linear algebra. While I
haven't done any benchmarking, I've stepped through a lot of X87 code.
I've seen instances in which C++ (Visual Studio 2005) falls all over
itself trying to intelligent floating point register allocation. I
surmise that using SSE floating point arithmetic (required under X64)
would result in much cleaner code generation; however, since I have no
need to go to 64 bits, that's just a guess on my part.

In addition, almost all math/trig functions are done in software in
64-bit mode, where many of these can exploit X87 built-in instructions
in 32-bit mode. Some of the 64-bit software math/trig functions are
faster than their hardware-based 32-bit equivalents, and vice versa, and
of course, performance varies from chipset to chipset.

As we all know, the bottom line is to look before you leap and benchmark
the kind of code that's near and dear to you.

Regards,
Jim

And yet, many who have moved to 64bit have found that the extra registers
make their software noticeably faster, even when memory isn't an issue.

Yes, it matters what the application does, and how it uses what's in the
processors. There will be applications on both sides of the divide, but
overall? I think we'll see increasing improvements as the quality of the
software for 64bit improves.

--
Charlie.
http://msmvps.com/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel


"Jim Henriksen" <> wrote in message
news:...
> Charlie Russel - MVP wrote:
>> No one here should have told you x64 was slower. Oh, it _might_ be very
>> slightly for a 32-bit app, depending on the app. But in most cases it
>> will be faster or the same even for 32-bit apps. The single biggest
>> reason is the I/O subsystem, which is 64bits wide and faster accessing
>> the disks. But overall? I would definitely expect x64 to be faster or the
>> same on indentical hardware. (and note that while you only have 4GB of
>> RAM, x64 will let you use all of it. x86 will not. And you can generally
>> go up to 8 GB of RAM on a typical DDR2 or DDR3 motherboard - 32-bit
>> Windows is NOT going to see any of that RAM past 4GB.)
>>
>
> Dear Charlie:
>
> I'm a compiler writer. I spent about 8 months porting a 32-bit compiler
> to 64 bits a year-and-a-half ago. My software is used for discrete-event
> simulation, which is almost always 100% CPU-bound and does lots of list
> processing and logic, and a modest amount of floating point. In my
> experience, these applications generally run roughly 6-7% slower in 64-bit
> mode, compared to 32-bit mode. Since pointers are twice as wide, it's
> understandable that heavy list-processing might be slower.
>
> I also do some 3D graphics work that's long on linear algebra. While I
> haven't done any benchmarking, I've stepped through a lot of X87 code.
> I've seen instances in which C++ (Visual Studio 2005) falls all over
> itself trying to intelligent floating point register allocation. I
> surmise that using SSE floating point arithmetic (required under X64)
> would result in much cleaner code generation; however, since I have no
> need to go to 64 bits, that's just a guess on my part.
>
> In addition, almost all math/trig functions are done in software in 64-bit
> mode, where many of these can exploit X87 built-in instructions in 32-bit
> mode. Some of the 64-bit software math/trig functions are faster than
> their hardware-based 32-bit equivalents, and vice versa, and of course,
> performance varies from chipset to chipset.
>
> As we all know, the bottom line is to look before you leap and benchmark
> the kind of code that's near and dear to you.
>
> Regards,
> Jim

On Jan 8, 4:05 pm, jabloomf1230 <jablo...@nycap.rr.com> wrote:
> Those are 3DMark06 artificial benchmarks, but unfortunately the URLs
> don't work for me, prolly because I have to be logged in as you to see
> your the project details. Post the SM 2.0, SM 3.0 and CPU test results
> and maybe we could figure out what's going on. You do realize that
> Futuremark does not officially support x64 Windows in any flavor, don't you?
>
> In any case, the key work here is "artificial". 3DMark06 is a nice tool
> for tuning your system, but it is not always a good predictor of real
> world performance in specific games, etc.. My personal experience (both

XP32:
Main Test Results
3DMark Score 3544 3DMarks
SM 2.0 Score 1370 Marks
SM 3.0 Score 1381 Marks
CPU Score 1713 Marks

XP64:
Main Test Results
3DMark Score 3551 3DMarks
SM 2.0 Score 1366 Marks
SM 3.0 Score 1378 Marks
CPU Score 1778 Marks

While you can completely blow off 3DMark as just an artificial
benchmark, it's an artificial benchmark that can always run 100% the
exact same way every single time it's run. The "real world"
performance you are looking for is exactly what 3DMark is providing.
It's telling you that everything else being equal, in a stressing 32-
bit benchmark tool, XP64 generates the same numbers.