Originally Posted by Mister_X If anyone else can comment on X-Fi and Vista 64 success please PM me ! ( had enough of the distinctly mediocre on board sound I'm using at present but at least it worked with vista from day one)
Seems to be fine to me, played a few games on it last night with no issue and what seem liked the same level of quality as before, personally I didn't find the X-Fi to be that much better than my old card and the positional stuff not as effective as I remember the old A3D stuff being so I may not be the best person to comment on X-Fi sound quality, it sounds normal, non pops or crackles, on first install of the driver the sound when mental sounded like an old spectrum game loading but on a reboot all was good.
Quote:
Originally Posted by BioSniper I've actually yet to see a 64-bit app (actually ANYTHING that I've installed so far) that didn't install to the "Program files (x86)" and run as a 32 bit app according to task manager :/
Same here apart from Source (Lost Coast) and Far Cry thats all I have seen using 64bit though there were quotes from the Crytek guy saying that Crysis would be better in 64bit so perhaps thats another that will benefit.
An interesting read fitten, thanks. As the author of the article, I have quite a few grievances with that forum thread (as well as a couple points on Digg) that claim issues with my article. There are two points out of that which ARE correct though in the ARS discussion, which I had chosen to simplify in my writing.
Point 1 - 8086 cannot handle instructions smaller or larger than 16 bit.
The entire point of having a 16-bit word is that it's the largest a processor can handle. The 8086 WAS capable of an odd type of pipelining up to a 6-byte instruction, but it's not the way it's done today so much - therefore, I simplified this down, possibly to the point of incorrectness. As well, there were a couple of 8-bit instructions used - again, simplified down to the point of incorrectness. If I can think of a good way to explain it without going on for another 2 pages, I would.
Point 2 - Itanium does not process 8 to 32 bit instruction.
I was unaware that the itanium, which runs exclusively on IA-64 (i.e., NO x86) had instructions that ran down to 8-bit. As far as I was/am aware, the instructions are padded during the compiling process to a proper 64 bits with forced precision. If I am wrong on this one, I do apologise even though it's actually misreading my point anyways. My idea was more to elaborate that the instructions are totally different in ia64 than they are in x86 in a way that didn't get into all of that.
NOW...as for the rest of it:
A couple people at Ars seem to not even be able to define a register, which is quite frightening if they wish to school me in it. Don't worry, Digg is way worse and at least the Ars forumites have a couple valid points that are actually well above my level. Then again, I would expect that from Ars and they aren't really the target market for this sort of thing.
People keep saying my G5 analysis is wrong. I'm sorry, G5 is not a true 64-bit processor. It has a 32-up and 32-down stream. It can process SOME 64-bit instruction by segmenting them and using 2 clock cycles instead of 1. Why the instruction set was even included on the processor, I'm not entirely sure, but then again I don't work for IBM.
My limitation of the AMD HyperTransport bus is correct, full stop. You may ask AMD, or if you would like I can pull the docs. Anyone who would like to argue with me on it is MORE than welcome to attempt to.
More people than anything seem to love to confuse "relative pointers" with "virtual memory" and the two are simply not at all the same thing. The idea of relative pointers was included on-cpu in the x86-64 architecture exclusively and denotes the lack of need for specific addressing WITHIN THE CPU, not within the memory. There is a huge difference there that speeds up the efficiency of processing by a significant degree. It seems the Ars forum is the first one NOT to have this argument, so go you. ;)
ANYHOW:
A lot of this nitpicking is exactly that - nitpicking. There is ONE place where there is a verifiable oversimplification, and that's in the limits of an 8086.
The whole purpose to this article was simply to explain just SOME of the behind-the-scenes issues going on in 64-bit computing to NON-programmers. I am not writing a computer science course, and I can't condense every tiny aspect of YEARS of computer engineering into a 5 page article. My goal was to highlight some of the speed improvements, background benefits and detriments to moving to 64-bit over current 32-bit solutions.
In that, I think I reached my goal. If you or anyone else feel that you can somehow condense the same massive info into something still readable and understandable by someone who doesn't do regular assembly code (and therefore wouldn't be reading this, but instead the very excellent but way-over-the-head-of-most treatise on Ars), I welcome your additions. :) You can find my email on the "About" page, and I hope you will use it.
Just for other data... the original DEC Alpha didn't 'do' bytes either... string processing on them were aweful as the libraries had to do all sorts of fun mask+shift tricks to do simple string manipulation. This was 'fixed' in future versions of the processor. Bytes are just too useful and you can't get rid of them just yet ;) Also, when talking about 64-bit processors and availability, MIPS (R4000) at least deserves a mention ;)
The register bit has always been a confusion for naming processors. The 68000 (as mentioned) had 32-bit registers and the ISA had many instructions for manipulating the full width of the register with one instruction. That the implementation of that instruction required multiple clock cycles or multiple runs through the ALU is an implementation detail.
This "discussion" has been around for a *long* time (over 30 years now for sure) and *still* hasn't been 'settled'. Another case... what about the 8086 and the 8088? 16-bit or 8-bit? The 8088 *is* the 8086 with the exception of an 8-bit external memory interface. Similarly, the 68000 and the 68008. The 68008 *is* the 68000 except only 8 data lines external. Additionally, the 68000's memory bus was designed so that, although it had 16 data pins, could interface directly to memory that was only 8-bits wide. You could build a 68000 with nothing but 8-bit wide memory. Does that mean that the 68000 was 32-bit because of the register file? 16-bit because of the external data bus width and when connected to 16-bit wide memory, or 8-bit only when connected to only 8-bit wide memory? Can one chip be classified as all three at once when not plugged into a socket? The 80386 and the 80386SX... 32-bit or 16-bit? See... it can be confusing ;)
Going internally, this is similar to the Pentium4 discussion about the double-pumped adders in it. They were double pumped but were only 1/2 the width of the 32-bit register. Does that mean the P4 was really only a 16-bit processor? Odd... because it ran a 32-bit OS just fine. Also, the external data bus is 64-bits wide (wider than the GPRs). Does that mean the P4 Willamette and Northwood were 64-bit processors?
The G5, like the 68000, had an external bus width that was smaller than the register size. That's an implementation detail of sorts. The fact of the matter is that the G5 had an ISA that worked just fine with 64-bit data that was stored in its 64-bit wide GPRs. The G5 used 64-bit addressing as well.
The 68020 was the 68000 with the ISA extended a little but a 32-bit external datapath. So, the "add.l d0, d1" in the 68000 wasn't a 32-bit instruction but the exact same bit pattern instruction in the 68020 is a 32-bit instruction because of extra pins on the outside of the chip (even though this instruction doesn't require the use of those pins)? Even if you say it's the width of the pathways inside the chip, there are lots of chips with 256-bit wide pathways inside for forwarding stuff around (cache-lines, for exmaple). Even if you limit it to the width of the ALU, it's still hairy as the ALU is simply called a few times.
To run it even further off into the weeds, you could say that if you compile your program to only use 16-bit operations (at the max), that program turns your processor into a 16-bit processor for some amount of time. After all, 32-bit math can be performed by using the 16-bit instructions, just more of them... (for example: add followed by adds with carry can synthesize as big of an add as you want... I guess I can turn my 6502 based Atari 130XE into a 1024-bit wide processor doing that pretty easily by using an add followed by 127 adds with carry ;))
I actually think writing in ways to initiate less tech-inclined people into technical subjects is a good thing. After all, the more you know about your computer, the more you can figure out stuff to do with it and even fix it when it isn't working right. Additionally, the more you know, the less likely you are to be misinformed by people such as computer salesmen in some of the large chain electronics stores who just want to sell you more expensive computers. So I think your efforts and intentions are good. The only real problems are when opinion creeps in disguised as fact (arguably your classification of the G5, for example - which, because you've seemed to classify it based solely on the external memory interface, the original Pentium must also be classified as a 64-bit processor, for example).
Originally Posted by Hells_Bliss load up all the 64bit drivers, and see if it crashes when you use the network in any way :)
nope, it's working, just like my last time, where it stopped working just as a friend who loves Mac came over :( (now it's keep telling people 64bit Vista is crap, get the new 64bit Mac) he's comming over this weekends as well, so let's hope the 64bit lasts.
Unfortunately I think you're wrong about Adobe Photoshop CS3 - its a fully native 32bit app. Having said that it is smart enough to use extra available RAM (provided by a 64bit OS on the right hardware) as its scratch disk so there are still huge improvements for 64bit users with Photoshop (I use it with Vista64 and 8BG RAM - great for huge images like stitched panaramas).
Photoshop users are hoping that there'll be a CS3.5 or something with 64bit support but I don't think Adobe have promised anything yet.
Allocating memory above 2 GB with 64-bit processors
Photoshop CS3 is a 32-bit application. When it runs on a 32-bit operating system, such as Windows XP Professional and some versions of Windows Vista, it can access the first 2 GB of RAM on the computer.The operating system uses some of this RAM, so the Photoshop Memory Usage preference displays only a maximum of 1.6 or 1.7 GB of total available RAM. If you are running Windows XP Professional with Service Pack 2, you can set the 3 GB switch in the boot.ini file, which allows Photoshop to use up to 3 GB of RAM.
Important: The 3 GB switch is a Microsoft switch and may not work with all computers. Contact Microsoft for instructions before you set the 3 GB switch, and for troubleshooting the switch. You can search on the Microsoft support page for 3gb for information on this switch.
When you run Photoshop CS3 on a computer with a 64-bit processor (such as a, Intel Xeon processor with EM64T, AMD Athlon 64, or Opteron processor) running a 64-bit version of the operating system (Windows XP Professional x64 Edition or Windows Vista 64-bit) and with 4 GB or more of RAM, Photoshop will use 3 GB for it's image data. You can see the actual amount of RAM Photoshop can use in the Let Photoshop Use number when you set the Let Photoshop Use slider in the Performance preference to 100%. The RAM above the 100% used by Photoshop, which is from approximately 3 GB to 3.7 GB, can be used directly by Photoshop plug-ins (some plug-ins need large chunks of contiguous RAM), filters, or actions. If you have more than 4 GB (to 6 GB), then the RAM above 4 GB is used by the operating system as a cache for the Photoshop scratch disk data. Data that previously was written directly to the hard disk by Photoshop is now cached in this high RAM before being written to the hard disk by the operating system. If you are working with files large enough to take advantage of these extra 2 GB of RAM, the RAM cache can speed performance of Photoshop. Additionally, in Windows Vista 64-bit, processing very large images is much faster if your computer has large amounts of RAM (6-8 GB).
Originally Posted by djambalawa Unfortunately I think you're wrong about Adobe Photoshop CS3 - its a fully native 32bit app. Having said that it is smart enough to use extra available RAM (provided by a 64bit OS on the right hardware) as its scratch disk so there are still huge improvements for 64bit users with Photoshop (I use it with Vista64 and 8BG RAM - great for huge images like stitched panaramas).
Photoshop users are hoping that there'll be a CS3.5 or something with 64bit support but I don't think Adobe have promised anything yet.
Good article by the way! I agree with your sentiments - you see that typical post you quoted at the start of your article so many times on forums and I agree its not even close to being accurate.
Comments 51 to 67 of 67
Seems to be fine to me, played a few games on it last night with no issue and what seem liked the same level of quality as before, personally I didn't find the X-Fi to be that much better than my old card and the positional stuff not as effective as I remember the old A3D stuff being so I may not be the best person to comment on X-Fi sound quality, it sounds normal, non pops or crackles, on first install of the driver the sound when mental sounded like an old spectrum game loading but on a reboot all was good.
Same here apart from Source (Lost Coast) and Far Cry thats all I have seen using 64bit though there were quotes from the Crytek guy saying that Crysis would be better in 64bit so perhaps thats another that will benefit.
Here's a discussion of this article: http://episteme.arstechnica.com/eve/forums/a/tpc/f/77909774/m/226003997831 that covers a few of the issues with this article.
An interesting read fitten, thanks. As the author of the article, I have quite a few grievances with that forum thread (as well as a couple points on Digg) that claim issues with my article. There are two points out of that which ARE correct though in the ARS discussion, which I had chosen to simplify in my writing.
Point 1 - 8086 cannot handle instructions smaller or larger than 16 bit.
The entire point of having a 16-bit word is that it's the largest a processor can handle. The 8086 WAS capable of an odd type of pipelining up to a 6-byte instruction, but it's not the way it's done today so much - therefore, I simplified this down, possibly to the point of incorrectness. As well, there were a couple of 8-bit instructions used - again, simplified down to the point of incorrectness. If I can think of a good way to explain it without going on for another 2 pages, I would.
Point 2 - Itanium does not process 8 to 32 bit instruction.
I was unaware that the itanium, which runs exclusively on IA-64 (i.e., NO x86) had instructions that ran down to 8-bit. As far as I was/am aware, the instructions are padded during the compiling process to a proper 64 bits with forced precision. If I am wrong on this one, I do apologise even though it's actually misreading my point anyways. My idea was more to elaborate that the instructions are totally different in ia64 than they are in x86 in a way that didn't get into all of that.
NOW...as for the rest of it:
A couple people at Ars seem to not even be able to define a register, which is quite frightening if they wish to school me in it. Don't worry, Digg is way worse and at least the Ars forumites have a couple valid points that are actually well above my level. Then again, I would expect that from Ars and they aren't really the target market for this sort of thing.
People keep saying my G5 analysis is wrong. I'm sorry, G5 is not a true 64-bit processor. It has a 32-up and 32-down stream. It can process SOME 64-bit instruction by segmenting them and using 2 clock cycles instead of 1. Why the instruction set was even included on the processor, I'm not entirely sure, but then again I don't work for IBM.
My limitation of the AMD HyperTransport bus is correct, full stop. You may ask AMD, or if you would like I can pull the docs. Anyone who would like to argue with me on it is MORE than welcome to attempt to.
More people than anything seem to love to confuse "relative pointers" with "virtual memory" and the two are simply not at all the same thing. The idea of relative pointers was included on-cpu in the x86-64 architecture exclusively and denotes the lack of need for specific addressing WITHIN THE CPU, not within the memory. There is a huge difference there that speeds up the efficiency of processing by a significant degree. It seems the Ars forum is the first one NOT to have this argument, so go you. ;)
ANYHOW:
A lot of this nitpicking is exactly that - nitpicking. There is ONE place where there is a verifiable oversimplification, and that's in the limits of an 8086.
The whole purpose to this article was simply to explain just SOME of the behind-the-scenes issues going on in 64-bit computing to NON-programmers. I am not writing a computer science course, and I can't condense every tiny aspect of YEARS of computer engineering into a 5 page article. My goal was to highlight some of the speed improvements, background benefits and detriments to moving to 64-bit over current 32-bit solutions.
In that, I think I reached my goal. If you or anyone else feel that you can somehow condense the same massive info into something still readable and understandable by someone who doesn't do regular assembly code (and therefore wouldn't be reading this, but instead the very excellent but way-over-the-head-of-most treatise on Ars), I welcome your additions. :) You can find my email on the "About" page, and I hope you will use it.
The register bit has always been a confusion for naming processors. The 68000 (as mentioned) had 32-bit registers and the ISA had many instructions for manipulating the full width of the register with one instruction. That the implementation of that instruction required multiple clock cycles or multiple runs through the ALU is an implementation detail.
This "discussion" has been around for a *long* time (over 30 years now for sure) and *still* hasn't been 'settled'. Another case... what about the 8086 and the 8088? 16-bit or 8-bit? The 8088 *is* the 8086 with the exception of an 8-bit external memory interface. Similarly, the 68000 and the 68008. The 68008 *is* the 68000 except only 8 data lines external. Additionally, the 68000's memory bus was designed so that, although it had 16 data pins, could interface directly to memory that was only 8-bits wide. You could build a 68000 with nothing but 8-bit wide memory. Does that mean that the 68000 was 32-bit because of the register file? 16-bit because of the external data bus width and when connected to 16-bit wide memory, or 8-bit only when connected to only 8-bit wide memory? Can one chip be classified as all three at once when not plugged into a socket? The 80386 and the 80386SX... 32-bit or 16-bit? See... it can be confusing ;)
Going internally, this is similar to the Pentium4 discussion about the double-pumped adders in it. They were double pumped but were only 1/2 the width of the 32-bit register. Does that mean the P4 was really only a 16-bit processor? Odd... because it ran a 32-bit OS just fine. Also, the external data bus is 64-bits wide (wider than the GPRs). Does that mean the P4 Willamette and Northwood were 64-bit processors?
The G5, like the 68000, had an external bus width that was smaller than the register size. That's an implementation detail of sorts. The fact of the matter is that the G5 had an ISA that worked just fine with 64-bit data that was stored in its 64-bit wide GPRs. The G5 used 64-bit addressing as well.
The 68020 was the 68000 with the ISA extended a little but a 32-bit external datapath. So, the "add.l d0, d1" in the 68000 wasn't a 32-bit instruction but the exact same bit pattern instruction in the 68020 is a 32-bit instruction because of extra pins on the outside of the chip (even though this instruction doesn't require the use of those pins)? Even if you say it's the width of the pathways inside the chip, there are lots of chips with 256-bit wide pathways inside for forwarding stuff around (cache-lines, for exmaple). Even if you limit it to the width of the ALU, it's still hairy as the ALU is simply called a few times.
To run it even further off into the weeds, you could say that if you compile your program to only use 16-bit operations (at the max), that program turns your processor into a 16-bit processor for some amount of time. After all, 32-bit math can be performed by using the 16-bit instructions, just more of them... (for example: add followed by adds with carry can synthesize as big of an add as you want... I guess I can turn my 6502 based Atari 130XE into a 1024-bit wide processor doing that pretty easily by using an add followed by 127 adds with carry ;))
I actually think writing in ways to initiate less tech-inclined people into technical subjects is a good thing. After all, the more you know about your computer, the more you can figure out stuff to do with it and even fix it when it isn't working right. Additionally, the more you know, the less likely you are to be misinformed by people such as computer salesmen in some of the large chain electronics stores who just want to sell you more expensive computers. So I think your efforts and intentions are good. The only real problems are when opinion creeps in disguised as fact (arguably your classification of the G5, for example - which, because you've seemed to classify it based solely on the external memory interface, the original Pentium must also be classified as a 64-bit processor, for example).
Anyway, thanks for replying.
load up all the 64bit drivers, and see if it crashes when you use the network in any way :)
Sorry.
nope, it's working, just like my last time, where it stopped working just as a friend who loves Mac came over :( (now it's keep telling people 64bit Vista is crap, get the new 64bit Mac) he's comming over this weekends as well, so let's hope the 64bit lasts.
any recommendations of a 64bit codec pack??
how did you configured them, i meant
Photoshop users are hoping that there'll be a CS3.5 or something with 64bit support but I don't think Adobe have promised anything yet.
Allocating memory above 2 GB with 64-bit processors
Photoshop CS3 is a 32-bit application. When it runs on a 32-bit operating system, such as Windows XP Professional and some versions of Windows Vista, it can access the first 2 GB of RAM on the computer.The operating system uses some of this RAM, so the Photoshop Memory Usage preference displays only a maximum of 1.6 or 1.7 GB of total available RAM. If you are running Windows XP Professional with Service Pack 2, you can set the 3 GB switch in the boot.ini file, which allows Photoshop to use up to 3 GB of RAM.
Important: The 3 GB switch is a Microsoft switch and may not work with all computers. Contact Microsoft for instructions before you set the 3 GB switch, and for troubleshooting the switch. You can search on the Microsoft support page for 3gb for information on this switch.
When you run Photoshop CS3 on a computer with a 64-bit processor (such as a, Intel Xeon processor with EM64T, AMD Athlon 64, or Opteron processor) running a 64-bit version of the operating system (Windows XP Professional x64 Edition or Windows Vista 64-bit) and with 4 GB or more of RAM, Photoshop will use 3 GB for it's image data. You can see the actual amount of RAM Photoshop can use in the Let Photoshop Use number when you set the Let Photoshop Use slider in the Performance preference to 100%. The RAM above the 100% used by Photoshop, which is from approximately 3 GB to 3.7 GB, can be used directly by Photoshop plug-ins (some plug-ins need large chunks of contiguous RAM), filters, or actions. If you have more than 4 GB (to 6 GB), then the RAM above 4 GB is used by the operating system as a cache for the Photoshop scratch disk data. Data that previously was written directly to the hard disk by Photoshop is now cached in this high RAM before being written to the hard disk by the operating system. If you are working with files large enough to take advantage of these extra 2 GB of RAM, the RAM cache can speed performance of Photoshop. Additionally, in Windows Vista 64-bit, processing very large images is much faster if your computer has large amounts of RAM (6-8 GB).