Windows 7 x64 vs Windows 7 x86 (Fight)

fakeasdf · 16 May 2009

12eason said:

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 :P 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 · 17 May 2009

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

darkassain · 17 May 2009

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 · 18 May 2009

12eason said:

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 · 18 May 2009

jimbo45 said:

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.

jimbo45 said:

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

I didn't say it could.

jimbo45 · 18 May 2009

12eason said:

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 · 18 May 2009

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 · 18 May 2009

12eason said:

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 · 18 May 2009

jimbo45 said:

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 · 18 May 2009

12eason said:

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.