Windows XP 64

[joannd]

When AMD offered there 64bit CPU's to us I want to run Windows XP 64. Is there any benifit to running this verion?

 

[Pirox]

Well, there is a benefit. You can run your 32bits programs faster as they will not be aware of the extra register x86-64 has to offer. And also @ 64bit mode programs have twice the amount of registers availiable.

Yep there ya go..<P ID="edit"><FONT SIZE=-1><EM>Edited by pirox on 07/13/03 01:54 PM.</EM></FONT></P>

 

[Mephistopheles]

You can run your 32bits programs faster as they will not be aware of the extra register x86-64 has to offer.

If the 32-bit programs are unaware of the extra registers, don't you mean "just as fast" as a 64-bit unaware OS? That's not an advantage yet... Of course, 64-bit software will use the extra registers and will show performance improvements, but not 32-bit software.

Anyway, if you say "faster", you must also say "than XYZ"...

<font color=red><b>M</b></font color=red>ephistopheles

 

[Pirox]

What i meant was .. 32bit programs will be able to automatically adress more that 4gbs of memory without it knowing what extra benefits x86-64 has to offer. In other words the AMD64 will add an addition extra 32 zero's to every code speeding uit 32 app's(see AMD pdf's).

AS for Mephistopheles god you make me laugh....i beginning to like this guy and this forum...

Yep there ya go..

 

[Mephistopheles]

AS for Mephistopheles god you make me laugh....i beginning to like this guy and this forum...

Uh... thanks! ...I guess, if you're not being ironic. (You never know...)

<font color=red><b>M</b></font color=red>ephistopheles

 

[Pirox]

One more thing...

When running in 64-bit mode, x86-64 programmers will have access to eight additional GPRs, for a total of 16 GPRs. Furthermore, there are eight new SIMD registers, added for use in SSE/SSE2 code. So the number of GPRs and SIMD registers available to x86-64 programmers will go from eight each to sixteen each.

Full binary compatibility with existing x86 code, both 32-bit and older 16-bit. x86-64 accomplishes this using a nested series of modes. The first mode is legacy mode. When in legacy mode, the processor functions exactly like a standard x86 CPU--it runs a 32-bit OS and 32-bit code exclusively, and none of x86-64's added capabilities are turned on.

In long mode, legacy x86 code (both 32-bit and 16-bit) runs under a 64-bit OS in compatibility mode, and x86-64 code runs under a 64-bit OS in 64-bit mode. Only the code that run's in long mode's 64-bit sub-mode can take advantage of all the new features of x86-64. Legacy x86 code running in long mode's compatibility sub-mode, for example, cannot see the extended parts of the registers, cannot use the eight extra registers, and is limited to the first 4GB of memory.

32bit programs can still use the extra registers that the AMD64 architecture posses, but only if the code has been compiled for AMD64 on a 64bit OS capable of running 32bit precision or less. The only exception is that 32bits that are not still recompiled will still be able to adress more than 4gb on that mode without it even knowing.

http://www.x86-64.org/documentation...white_paper.pdf



Yep there ya go..<P ID="edit"><FONT SIZE=-1><EM>Edited by pirox on 07/13/03 02:48 PM.</EM></FONT></P>

 

[Mephistopheles]

32bit programs can still use the extra registers that the AMD64 architecture posses, but only if the code has been compiled for AMD64 on a 64bit OS capable of running 32bit precision or less.

Interesting. So if I got this straight, 32-bit software in general will run as well on a 64-bit aware OS as on a 64-bit unaware one. It's the 64-bit software or specifically designed ones that will shine, right? I hope they get their software support straight...

<font color=red><b>M</b></font color=red>ephistopheles

 

[Pirox]

That's right. There will not be any performance loss. In fact on a 64 OS 32 bit will still speed up. If you don't look at it technically you can also look at it in another way. Since this Windows is a newer revision it was by itself designed to run older code faster.


Yep there ya go..

 

[joannd]

So most of the software out there will run abit faster running on win xp 64. they will also run faster do to the faster clock speek of the 64 chip. but in over all for gamers and such the os and chip will not get full use of all the features until they are compiled on a 64 bit computer for a 64 bit computer?

 

[Mephistopheles]

abit faster running on win xp 64.

Yes... A very, very small bit, maybe. If I understood it correctly, most software will probably run just the same on XP 64 as on XP. If there is a small performance gain, it's really negligible...

they will also run faster do to the faster clock speek of the 64 chip.

That's not right. Most current high-end Bartons are clocked beyond 2.0Ghz, and A64 will be introduced at 2.0Ghz flat. So there is no "faster clock speed" - clock speed is actually almost unchanged (if not slower).

but in over all for gamers and such the os and chip will not get full use of all the features until they are compiled on a 64 bit computer for a 64 bit computer?

No doubt about that. The vast majority of software will not use all features at all until they get a revision that optimizes them for x86-64. That's why software support is so important.

AMD estimates that, by early 2004, 20% of all software will be optimized for 64 bit operation.

<font color=red><b>M</b></font color=red>ephistopheles

 

[imgod2u]

What i meant was .. 32bit programs will be able to automatically adress more that 4gbs of memory without it knowing what extra benefits x86-64 has to offer. In other words the AMD64 will add an addition extra 32 zero's to every code speeding uit 32 app's(see AMD pdf's).

Erm, no they won't. While pointer data is zero-extended in the GPR's they *will* return to memory as a 32-bit pointer. To not do so would violate the entire programming model. 32-bit programs will become unstable if they get a 64-bit result when a 32-bit result is expected.
Each program will be able to, however, address an entire 4 GB segment and won't need to share that 4GB with any other program (as the OS can manage to give each 32-bit program 4 GB of memory). This may or may not be a benefit depending on the reason you need more than 4 GB of memory.
If you need it because all of your programs combined takes up more than 4 GB of space, moving to 64-bit Windows will alleviate this (of course, in that case, even physical address extension used on the Xeon boxes would help just as much).
If, however, one program required more than 4 GB of address space, then your program would have to be recompiled to take advantage of more than 4 GB of address space. Of course, just recompiling alone should be fairly simple without much of a need for re-optimizing.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.

 

[Pirox]

But what about NUMA for the A64? That is if for example you go with 2 cpu's?

And also hypertransport has its benefits on the OS. For example try to put a disk in your floppy disk station then copy an .exe file to it.. while it is copying open your cd drive and put any kind of installation disk and you will see that current system's today have that kind of I/O bottleneck.

With hypertransport you will have a serial bus that you can constantly read/write from whereas today buses only allow one read/write operation. But then again you have SIS chipsets that support hyperstreaming for example like hypertransport. The only thing is that hypertranport on a K8 system has real low latency meaning you can even be doing all that even with KAZAA on and playing games e.t.c

As long as the devices are working you don't see aan I/O drop...

Yep there ya go..

 

[Mephistopheles]

Each program will be able to, however, address an entire 4 GB segment and won't need to share that 4GB with any other program (as the OS can manage to give each 32-bit program 4 GB of memory). This may or may not be a benefit depending on the reason you need more than 4 GB of memory.

In terms of resources, you could draw a reasonable analogy to having 2 cpus running a single-threaded program on a 2-cpu aware OS, right? The best the OS can hope to do is allocate 100% of one CPU to that program.

<font color=red><b>M</b></font color=red>ephistopheles

 

[noko]

Since Windows code can have a large influence on the performance of a machine due to Window routines, going to 64 bit Window code will probably speed up a number of programs. From swithcing treads faster, to accessing memory faster while Windows is using the 64 bit capability of the K-8.

 

[imgod2u]

But what about NUMA for the A64? That is if for example you go with 2 cpu's?

What about it?

And also hypertransport has its benefits on the OS. For example try to put a disk in your floppy disk station then copy an .exe file to it.. while it is copying open your cd drive and put any kind of installation disk and you will see that current system's today have that kind of I/O bottleneck.

Do this on a dual or SMT-enabled system and you won't notice the same bottleneck. The irresponsiveness is due to thread lock-up while the floppy is reading and Windows giving incredibly high priority to i/o activity such as floppy reads. Multiple threads being able to run simultaneously alleviates this.

With hypertransport you will have a serial bus that you can constantly read/write from whereas today buses only allow one read/write operation. But then again you have SIS chipsets that support hyperstreaming for example like hypertransport. The only thing is that hypertranport on a K8 system has real low latency meaning you can even be doing all that even with KAZAA on and playing games e.t.c

I have no idea what you think Hypertransport will do for gaming or Kazaa but it has nothing to do with latency.
Unidirectional point to point buses add *more* latency in a wide-use scale vs a multi-drop bus, not less. It's very easy to see why this is so. With a multi-drop bus, all chips are connected via a single bus. The time it takes for a signal to get from any one chip to any other chip is the same and usually very low in latency. A unidirectional point to point bus can only have such a low latency to one or two other chips, to get to others, they have to go through a web of busses. These disadvantages can be circumvented with a smart OS of course, but it doesn't change the fact thaty they have nothing to do with lower latency.
The main thing Hypertransport alleviates over modern interconnects is pin-count and design flexibility. Motherboards won't be restricted to certain design topologies and they won't be as expensive/taxing to test/validate.
Having 2 unidirectional busses vs a single multidrop bus has its advantages and disadvantages. Currently, I'd say the unidirectional bus has the overall upper hand.
It's a great interconnect technology and the future seems to be of serialization as more computers move to use a combination of Hypertransport for chip-to-chip interconnect and PCI Express for peripheral interconnect. Such is the progress of technology.

As long as the devices are working you don't see aan I/O drop...

I have no idea what this is suppose to mean. Modern machines communicate just fine with i/o devices. They even do so concurrently. Or have you not done an on-the-fly copy of a cd from one drive to another?

"We are Microsoft, resistance is futile." - Bill Gates, 2015.

 

[knewt]

Yesterday I was searching microsoft for some evidence of an x86-64 version of windows xp. I could find nothing. It does however support ia-64. Have you heard if MS will deliver xp for the a-64? So far I have only heard of windows server supporting x86-64.

Wanted: Large breasted live-in housekeeper. Must be a good cook, organized, and willing to pick up after me.

 

[imgod2u]

All rumors seem to point to an add-on being released for Windows XP with x86-64 support. I don't know, maybe they'll just release a whole new version. Be better for the OEM market.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.

 

[Mephistopheles]

Yes, I think Win2003 Server supports IA-64. HP sells Itanium workstations with that.

Also, I heard that a service pack is due by 2nd half 2003 that will add support for x86-64 and improve IA-64 32-bit emulation by a good deal... I don't know about an add-on to XP that supports x86-64, though...

<font color=red><b>M</b></font color=red>ephistopheles

 

[imgod2u]

HP Workstations with Itanium processors ship with WindowsXP 64-bit.......

"We are Microsoft, resistance is futile." - Bill Gates, 2015.

 

[Mephistopheles]

Really? Ooops... I should have checked... That makes more sense, BTW...

<font color=red><b>M</b></font color=red>ephistopheles

 

[wolverinero79]

<A HREF="http://www.microsoft.com/windowsxp/64bit/howtobuy/default.asp" target="_new">Try here</A>

I'm just your average habitual smiler =D