code.kliu.org Posted May 26, 2009 Share Posted May 26, 2009 There's some information here that needs to be cleared up: Windows-on-windows 64 (WOW64) is an "emulation" layer only if you're using Itanium. For x86-64, there is no emulation or translation or anything of that sort since the CPU is running the 32-bit code natively. There is the registry and file system redirection, but relative to the costs of registry and file system access, the redirection's cost is a pittance. Nor is there any thunking in the mold of the old 16-bit/32-bit transition... CPU-wise, the overhead is background noise. Memory-wise, x86-64 code is larger due to longer pointer sizes, longer instructions, etc. But more significantly, the WOW64 layer means that there are two copies of system libraries loaded in memory: the 64-bit system libraries for use by 64-bit processes and 32-bit libraries used by 32-bit processes. This means more memory overhead, more disk access to stuff into memory, etc. Benefits: * Great if you have >3GB of memory. * Apps that work with 64-bit data will benefit (the canonical example is scientific computing) * Apps compiled for x86-64 will probably receive a boost due to the new registers available (amount of performance gain will vary) * Apps compiled for x86-64 can potentially benefit from a larger address space (note that address space is not the same as physical memory) * 32-bit apps will not see any appreciable benefit. Downsides: * Memory/disk overhead. * 16-bit code can no longer be run if the processor is in 64-bit mode, so say goodbye to all your legacy 16-bit apps; you can thank the guys at AMD who designed the x86-64 architecture for this downside. * If you have software that run inside a host process (e.g., shell extensions), they must match the host process. This can be a dealbreaker if you have a 32-bit-only shell extension that won't run in 64-bit Windows Explorer. Link to comment Share on other sites More sharing options...
iamwhoiam Posted May 26, 2009 Share Posted May 26, 2009 It doesn't emulate anything. All it does is restrict the address range and redirect calls from the 32-bit system folder to the 64-bit folder. The industry terminology for it is a thunking layer. It's the same concept Windows 95 used to run 16-bit Windows code. You won't convince him of that. He and I have had that discussion before. Link to comment Share on other sites More sharing options...
The_Decryptor Veteran Posted May 26, 2009 Veteran Share Posted May 26, 2009 ...* 16-bit code can no longer be run if the processor is in 64-bit mode, so say goodbye to all your legacy 16-bit apps; you can thank the guys at AMD who designed the x86-64 architecture for this downside. ... Thanks AMD! (No joke, 16-bit deserves to die already) Link to comment Share on other sites More sharing options...
hdood Posted May 26, 2009 Share Posted May 26, 2009 There's some information here that needs to be cleared up:Windows-on-windows 64 (WOW64) is an "emulation" layer only if you're using Itanium. For x86-64, there is no emulation or translation or anything of that sort since the CPU is running the 32-bit code natively. Nor is there any thunking in the mold of the old 16-bit/32-bit transition... CPU-wise, the overhead is background noise. No, the only difference between the IA64 and the AMD64 version is that the former also implements emulation of x86 instructions since it can't execute them natively. Both emulate a 32-bit environment the way I described. As for thunking, there is plenty of it, because WOW64 isn't an island. It has to interact with the 64-bit kernel and OS, and this means converting data back and forward between 32-bit and 64-bit (i.e thunking). Everytime you call something in the kernel, the contents of the stack has to be thunked. The 64-bit OS can't deal with 32-bit data and WOW64 has to thunk it. You are right that the overhead is fairly insignificant and shouldn't matter to most people, but if you were to actually benchmark it you might find that it's several percent. Link to comment Share on other sites More sharing options...
Subject Delta Posted May 26, 2009 Share Posted May 26, 2009 The overhead is nothing like in the region of several percent, in fact having actually done the benchmarks myself (32 bit version of XP vs 64 bit version of Vista) every 3D benchmark I did (using 32 bit versions of 3D mark) where actually about 2% faster on Vista than XP. Whilst that can be accounted for in the fact that there may have been some differences in the drivers, it does IMO prove that there is very little if any performance loss. According to the information I can find on the net, the redirection that occurs on X86-64 is far less computationally expensive than that which occurs on Itanium (IA64). Link to comment Share on other sites More sharing options...
code.kliu.org Posted May 26, 2009 Share Posted May 26, 2009 Both emulate a 32-bit environment the way I described. Yea, that's the file system and registry redirection that I mentioned... but it's not significant compared to the already-high costs of disk and registry access (e.g., fetching something from the registry costs something on the order of a hundred thousand cycles; fixing up the name of that request is nothing compared to that). As for thunking, there is plenty of it, because WOW64 isn't an island. It has to interact with the 64-bit kernel and OS, and this means converting data back and forward between 32-bit and 64-bit (i.e thunking). Everytime you call something in the kernel, the contents of the stack has to be thunked. The 64-bit OS can't deal with 32-bit data and WOW64 has to thunk it. I did use the weasel phrase "in the mold of". There is thunking, but not of the type, scale, or scope of the 16-32 transition. It's negligible, especially since most of the time that most applications spend is not spent talking with the kernel. Link to comment Share on other sites More sharing options...
rakeshishere Posted May 26, 2009 Share Posted May 26, 2009 There's some information here that needs to be cleared up:Windows-on-windows 64 (WOW64) is an "emulation" layer only if you're using Itanium. For x86-64, there is no emulation or translation or anything of that sort since the CPU is running the 32-bit code natively. There is the registry and file system redirection, but relative to the costs of registry and file system access, the redirection's cost is a pittance. Nor is there any thunking in the mold of the old 16-bit/32-bit transition... CPU-wise, the overhead is background noise. Memory-wise, x86-64 code is larger due to longer pointer sizes, longer instructions, etc. But more significantly, the WOW64 layer means that there are two copies of system libraries loaded in memory: the 64-bit system libraries for use by 64-bit processes and 32-bit libraries used by 32-bit processes. This means more memory overhead, more disk access to stuff into memory, etc. Benefits: * Great if you have >3GB of memory. * Apps that work with 64-bit data will benefit (the canonical example is scientific computing) * Apps compiled for x86-64 will probably receive a boost due to the new registers available (amount of performance gain will vary) * Apps compiled for x86-64 can potentially benefit from a larger address space (note that address space is not the same as physical memory) * 32-bit apps will not see any appreciable benefit. Downsides: * Memory/disk overhead. * 16-bit code can no longer be run if the processor is in 64-bit mode, so say goodbye to all your legacy 16-bit apps; you can thank the guys at AMD who designed the x86-64 architecture for this downside. * If you have software that run inside a host process (e.g., shell extensions), they must match the host process. This can be a dealbreaker if you have a 32-bit-only shell extension that won't run in 64-bit Windows Explorer. Could you pls shed some more info on this? You mean to say it consumes more disk space ? Link to comment Share on other sites More sharing options...
hdood Posted May 26, 2009 Share Posted May 26, 2009 The overhead is nothing like in the region of several percent, in fact having actually done the benchmarks myself (32 bit version of XP vs 64 bit version of Vista) every 3D benchmark I did (using 32 bit versions of 3D mark) where actually about 2% faster on Vista than XP. You compared two different OSes and want to claim that is a valid test? There are other things that make it difficult to benchmark though. The 64-bit OS might be spending less time doing other things than the 32-bit version is, thus canceling out the overhead. There is no reason to fanatically oppose the idea that there is overhead, it should just be acknowledged and accepted as insignificant enough not to matter in real world use. According to the information I can find on the net, the redirection that occurs on X86-64 is far less computationally expensive than that which occurs on Itanium (IA64). Since WOW64 on IA64 contains an emulator for the x86 instruction set, yes, it is obviously far more expensive. I don't see how that's relevant. Yea, that's the file system and registry redirection that I mentioned I think you'll find that my post had four items, the most important part being emulated being the kernel. Not sure why you felt like singling out the redirectors/reflector and ignoring the rest. I did use the weasel phrase "in the mold of". There is thunking, but not of the type, scale, or scope of the 16-32 transition. It's negligible, especially since most of the time that most applications spend is not spent talking with the kernel. Well, if you want to be pedantic the average program spends most of its time doing nothing at all. It's not that infrequent though. Anything related to graphics and windowing takes a trip through the kernel, for instance. Link to comment Share on other sites More sharing options...
hdood Posted May 26, 2009 Share Posted May 26, 2009 Could you pls shed some more info on this? You mean to say it consumes more disk space ? It does because 64-bit variables take up twice as much space. A 32-bit integer takes four bytes, while a 64-bit one takes up eight bytes. It makes files anywhere from a few percent to 50% larger. On top of that is the space taken up by the 32-bit environment. Link to comment Share on other sites More sharing options...
andy2004 Posted May 26, 2009 Share Posted May 26, 2009 havnt read whole thread here but on a 64bit system with 8GB ram you can alter the visual studio .exe with the /LARGEADDRESSAWARE flag therefore allowing VS to address up to 3GB ram so 64bit does have its advantages over 32bit but tbh i wouldnt go 64bit on anything less than 3GB ram anyway Link to comment Share on other sites More sharing options...
hdood Posted May 26, 2009 Share Posted May 26, 2009 On 64-bit, /LARGEADDRESSAWARE actually gives you 4GB if the program is up to it! Link to comment Share on other sites More sharing options...
soumyasch Posted May 26, 2009 Author Share Posted May 26, 2009 Okay, so to summarize, if the application isn't x64, then there wouldn't be any benefit of the larger memory capability unless the application is /LARGEADDRESSAWARE. But if VS is so, then I can get a gig or two more for it to use. Which would mean I would get the benefits of getting more RAM and going x64. Thanks guys. But is VS2008/VS2010 definitively large address aware? Link to comment Share on other sites More sharing options...
+ThePhoenix Subscriber² Posted May 26, 2009 Subscriber² Share Posted May 26, 2009 Visual Studio 2008 is not large address aware but can be made to be, see the following guide, works perfectly. http://stevenharman.net/blog/archive/2008/...-of-memory.aspx Link to comment Share on other sites More sharing options...
hdood Posted May 26, 2009 Share Posted May 26, 2009 2008 I don't believe, but VS2010 is marked as such although I'm not quite sure if it will actually use that much memory in practice. Do you really have problems with VS running low on RAM? Link to comment Share on other sites More sharing options...
_dandy_ Posted May 27, 2009 Share Posted May 27, 2009 Given that you're using Visual Studio...wouldn't you want to test your own apps on the real thing, so you can at least verify that they work on x64, instead of assuming everything will work transparently without any issue? To me, that's a no-brainer. Link to comment Share on other sites More sharing options...
soumyasch Posted June 2, 2009 Author Share Posted June 2, 2009 2008 I don't believe, but VS2010 is marked as such although I'm not quite sure if it will actually use that much memory in practice. Do you really have problems with VS running low on RAM? Not always, but sometimes it gets to a point where it can benefit from some more RAM. Given that you're using Visual Studio...wouldn't you want to test your own apps on the real thing, so you can at least verify that they work on x64, instead of assuming everything will work transparently without any issue?To me, that's a no-brainer. Of course I will test it. But i still prefer to know if something will work before jumping right in and spend hours setting up the system, sifting through documentation and endlessly tweaking settings only to finally discover that all the effort is wasted because it won't work. Once I see there is a chance things will work, I will definitely try it out for myself before deciding whether it is good enough for my needs. Link to comment Share on other sites More sharing options...
Recommended Posts