Windows 7 x64 vs Windows 7 x86 (Fight)

[fakeasdf]

Sorry, but how does that relate to what I've said? Do you deny that 64bit apps and OS require upto twice the hard drive space/use as 32 bit apps and OS?

How about you test boot times, application load times etc. Maybe you could factor in increased fragmentation due to larger files and slower disk reads due to having to use slower portions of the disk. These issues wouldn't affect your idealised tests, but on average joes computer that has been in regular use for a year, they are enough to bring the system to a standstill.

Of course I deny it! I believe you are a little confused on what x64 vs x86 entails... Not every instruction in an executable software is 64 bits or 32 bits in length. For example in the intel and AMD64 instruction set 1001 0000 or x90 is a NOP instruction(used in tons of buffer overflows and hacked executables). It's only 1 byte on your hard drive! On top of that the x64 instruction set is just a superset to x86, so if you aren't using any of the new x64 instructions, your file would theoretically be the exact same size. In fact there are some new x64 instructions that combine multiple x86 instructions into one instruction (possibly saving clock cycles) and are smaller in bitcode than the 2 x86 instructions! So it's possible to have an x64 app be smaller than an x86 app! And there is no reason for increased fragmentation due to an extra 100 k on an executable Don't forget the reason the x64 DVD is 3.2 vs 2.53 is because it has copies of the system libraries in both 64 bit and 32 bit (SysWOW64 and System32). Fragmentation generally ocurrs when removing files and writing new files, not while you are continuosly writing files (such as installing an OS). (granted if you are installing on a non formatted hd with other files on it, fragmentation can ocurr, but this will happen to both OSes)

 

[Win7User512]

If you need a bigger hard drive and more RAM for x64 than get those and be happy. I am.

 

[darkassain]

ok in reality you both right...
it technically it does take a big chunk (just the sysWOW64 and winsxs (there are entries there that constitute both x86 and x64 dlls) folder)

may not be exactly half but its a big chunk...
at the emulation level (OS wise)
and for the cpu wise x64 all it is is a superset of the x86 instructions...

 

[jimbo45]

Most of those result stress the cpu and memory most which are obviously going to perform better with x64. However, the biggest bottleneck on a computer nowadays is the hard-drive and that is the thing that is stressed more by x64 during typical use.

I would hazzard a guess that even the hard-drive benchmark you ran only tested read-write performance on identical filesizes on both x64 and x86. In typical use the x64 system will be pushing anything upto twice the data back and forth to the hard-drive as the x86 system. The tests should allow for that fact.

Actually it could be up to 8X as fast -- Don't forget that the CPU operates in 64 Bits so any 32 bit addressing and instructions have to be moved around to "Instruction Prefetch areas" and decoded. If you have a QUAD then you could theoretically execute 8X as fast.

The other part however which isn't always so obvious is the data path of the Mobo -- if the cache size of the CPU is large enough then the importance of this is less -- modern MOBOS should be OK here of course.

A real blockage in ANY system will be the I/O subsystem which is why SCSI disks cost so much more -- it's not only the speed of the drive itself but also the width of the "DATA BUS" which actually transfers I/O from the disk drive into and out of RAM.

Data can't be "pushed" to the disk faster or slower by the CPU -- after the instruction is decoded and executed the CPU leaves this function to the I/O subsystem which is responsible for executing this. The CPU can then process other work until the Disk I/O subsystem is ready for more work when it generates an "Interrupt". A well designed OS (and application) will try and ensure that the actual work is reasonably "overlapped" with I/O to get the maximum throughput.

Often data is actually transferred to the disks in as small a quantity as 8 bits a time -- don't panic here as quite fast hardware is used for this transfer and other processing is taking place at the same time (that's what the Disk Cache is for).

Any computer benchmark test which is highly I/O bound won't test the capacity of the OS itself, RAM or CPU if the disks are SLOW.

A SLOW disk will KILL any system -- unfortunately disks tend to be the "cinderella" part of a system and are usually overlooked. People just look at the capacity of the HD rather than all the specifications -- and disks vary HUGELY.

Cheers
jimbo

 

[12eason]

A real blockage in ANY system will be the I/O subsystem which is why SCSI disks cost so much more

The IO system only becomes a constraint on multi disk raid setups. SCSI disks are faster than ide.

Data can't be "pushed" to the disk faster or slower by the CPU

I didn't say it could.

 

[jimbo45]

The IO system only becomes a constraint on multi disk raid setups. SCSI disks are faster than ide.

I didn't say it could.

Not true -- The I/O subsystem is important in ANY computer system -- just imagine how slow your system would be if instead of hard disks you had to use large floppy disks or to take an extreme case imagine Paper tape or magnetic tape devices.

I've seen lower specced systems where just by changing the hard drives the performance has gone on to beat higher specced systems with just "ordinary cheapo drives".

Most "non gaming" and non multimedia applications are highly I/O bound -- it really won't make ANY difference to a normal user using say WORD whether you have the latest QUAD processsor or an earlier single Pentium IV.

However if you have to wait five minutes for the Network disk to deliver your document you will MOST DEFINITELY notice that.

Even in some more intensive processing like Photoshop CS4 where you can operate with HUGE files (layers etc etc) if the I/O subsytem is not optimal then the poor user is going to have to wait longish times to get data from the CS4 scratch disk areas however fast the CPU is. The user (and hence the CPU) won't be able to resume processing until the data actually arrives.

Cheers
jimbo

 

[12eason]

IO of SATA is 300MB/s while the drives output top 150 ish. SCSI disks output higher, but still an individual disk won't flood a single channel. SSds are the only drives that come close to flooding a channel.

 

[jimbo45]

IO of SATA is 300MB/s while the drives output top 150 ish. SCSI disks output higher, but still an individual disk won't flood a single channel. SSds are the only drives that come close to flooding a channel.

Hi there
you are implicitly agreeing now with the performance of the I/O subsystem. Don't forget that there are still a lot of computers being fitted with IDE disks - and people building their own might still want to use these old disks. Better disk controllers will improve the data transfer rate which is still zillions of orders slower than a CPU.

If you are building your own machine it's better to junk those IDE disks unless you install them on a domestic "File and Print" server where the speed is not so important.

SSD's look good but still expensive and not a lot out yet that have made it into "Consumer grade" platforms for testing. Any "consumer device" that is less than 100GB isn't really "fit for purpose" these days.

Cheers
jimbo

 

[12eason]

Hi there
you are implicitly agreeing now with the performance of the I/O subsystem. Don't forget that there are still a lot of computers being fitted with IDE disks - and people building their own might still want to use these old disks. Better disk controllers will improve the data transfer rate which is still zillions of orders slower than a CPU.

Wth? Throughput is dependant on spin speed, not disk controllers. And where did I agree that the IO system was the problem?

 

[jimbo45]

Wth? Throughput is dependant on spin speed, not disk controllers. And where did I agree that the IO system was the problem?

If you really think that throughput is ONLY dependent on Disk RPM speed then there really isn't any point in continuing the discussion.

I Despair at "modern Education" -- I/O systems on computers were fairly well documented way way back as far as the late 1960's -- there's nothing NEW here other than the hardware which is of course a lot lot better.

So if you want to believe what you've written without having any interest in guys who actually PUT TOGETHER one of the best OS'es ever which is STILL used as a model for a modern OS -- so be it.

But to us guys who worked on the original IBM 360 / 370 series -- we DO know what we are talking about -- and DO have a look at some of the IBM redbooks on IBM/MVS370 -- a really excellent introduction to how OS'es work -- even if we are a little bit biased.

Not trying to be nasty but you did include the word "Fight" in your title -- and I'm still standing my ground -- poor I/O subsystems will KILL the performance of ANY OS old or new.

Cheers
jimbo.

 

[12eason]

Well, that was a pretty random post 'Jimbo45'.

Today's mechanical hard disk drives can transfer data at up to 127 MB/s...
For mechanical hard drives, SATA 3 Gbit/s transfer rate is expected to satisfy drive throughput requirements for some time, as the fastest mechanical drives barely saturate a SATA 1.5 Gbit/s link. A SATA data cable rated for 1.5 Gbit/s will handle current mechanical drives without any loss of sustained and burst data transfer performance. However, high-performance flash drives are approaching SATA 3 Gbit/s transfer rate.

The controller has an affect on seek time way more than throughput.

 

[Marc Winter]

I'll never return to a x86 system

Hi!

I started using x64 with Vista and will never return to a x86 system. Everybody kept warning me about missing drivers an loads of problems, but (thank god) I was stubborn as usual and tried it.

My games worked fine (and some of them significantly faster); my development system (VS2008) worked faster and I had no problems whatsoever.

In my opinion it's quite sad that there are still companies selling hardware without any support for x64. For me this is a sign of ignorance and doesn't earn any understanding.

Unfortunately MS will (again) release a x86 version of Seven which will make room for those who don't want to understand an hold on to their beliefs.

I've come to the conclusion that there are not very much systems on the market being able to perform acceptably with Seven on one hand and not being able to provide x64 support on the other.

But there is light... My first tests with VXP performed outstandlingly and made even hardware work which has not been usable on Vista or XP 64...

 

[12eason]

Unfortunately MS will (again) release a x86 version of Seven which will make room for those who don't want to understand an hold on to their beliefs.

So, just because a few programs don't support x64, you want Microsoft to cut off all backwards compatibility just to force manufacturers into making their software x64? That's retarded frankly.

I've come to the conclusion that there are not very much systems on the market being able to perform acceptably with Seven on one hand and not being able to provide x64 support on the other.

Your conclusion is simply wrong.

 

[fakeasdf]

So, just because a few programs don't support x64, you want Microsoft to cut off all backwards compatibility just to force manufacturers into making their software x64? That's retarded frankly.
Your conclusion is simply wrong.

Actually, I agree with both arguments here. There are still plenty of machines that don't have 64 bit CPU's that can still run Win7 just dandy, and I wouldn't want to deprave them of the awesome upgrade. On the other hand, people that have certain 32 bit programs that won't run in some 64 bit OS (which are very very very very few) always have XPM. Generally it's more of a hardware issue than a software issue when it comes to something not working in x64. Which when thinking about businesses, if it's a super old hardware thing, they probably won't have 32 bit drivers for vista/7 anyway, and I hope XPM can access all of those other hardware devices (which originally VPC couldn't) or else those companies are going to be stickin to XP... (Poor Saps)

 

[Snufffed]

It is my understanding that in Win8 and Win9 MS will be pushing towards a FULL x64 (no x86) OS. My source told me that is why XP Mode is in Win7.
Just think, only 1 version of Windows, which is compatible with all forms of XP , Vista, & Win7. so be it.
click the switch (use in compatible mode).
I'm willing to try... as long as they leave DOS (Cmd mode) somewhere in there.

 

[Win7User512]

It is my understanding that in Win8 and Win9 MS will be pushing towards a FULL x64 (no x86) OS. My source told me that is why XP Mode is in Win7.
Just think, only 1 version of Windows, which is compatible with all forms of XP , Vista, & Win7. so be it.
click the switch (use in compatible mode).
I'm willing to try... as long as they leave DOS (Cmd mode) somewhere in there.

The real DOS left ages ago. CMD is a kind of emulator of it. I do like the compatibility mode option. I have several programs that rely on that feature.

 

[kpo6969]

Unfortunately MS will (again) release a x86 version of Seven which will make room for those who don't want to understand an hold on to their beliefs.

So, just because a few programs don't support x64, you want Microsoft to cut off all backwards compatibility just to force manufacturers into making their software x64?
Your conclusion is simply wrong.

I totally agree.
MS made a business decision.

 

[Jon55]

It is my understanding that in Win8 and Win9 MS will be pushing towards a FULL x64 (no x86) OS. My source told me that is why XP Mode is in Win7.
Just think, only 1 version of Windows, which is compatible with all forms of XP , Vista, & Win7. so be it.
click the switch (use in compatible mode).
I'm willing to try... as long as they leave DOS (Cmd mode) somewhere in there.

One could only hope. Keeping 32-bit for Windows 7 I can understand. Windows 8 64-bit should be pushed hardcore though. 32-bit should be left for developing countries at that point. Don't most new comps from Dell, Gateway, etc come with Vista 64-bit anyway?

 

[Win7User512]

Don't most new comps from Dell, Gateway, etc come with Vista 64-bit anyway?

It is starting to become more prevalent, but not all. I think that with sufficient driver support Win8 should just be x64 since all processors sold now are x64.

 

[MorbidGod]

Thanks jimbo, I forgot about photoshop, I have a 32 bit and 64 bit of that, I think I'll do some tests on those. I agree just posting up numbers is a tad misleading, but arguing with the facts tends to not help some people. They like to see pictures And most people can't get past the myth that you need 4 gb of RAM to run 64 bit OS...

I can asure you Photoshop CS4 64-bits is millions of years faster than the 32-bits or other version ever, even with high dpi outdoors and raw pictures. In the proper machines, of course.