I know that the additional consideratiosn when compiling for x64 is that some data types, like ints, can hold larger values. Are there any concerns?
VS2010, released a few days ago, can support compiling for x64 and x32, just like VS2008. The app is x32/86 only. I keep thinking that the app needs to be 64 bit however. What am I missing? Obviously this is not the case.
Thanks
Regarding VS2010 (IDE & plugins) not being a 64 bit app, i believe there are 2 main reasons -
If the app is 64 bit, then pointers and ints would consume twice more memory which would be worse for most folks.
Parts of Visual Studio are already ported to .NET. It would be simpler to finish porting rest of it to .NET rather than port C/C++ code to x64.
http://blogs.msdn.com/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx
Reasons to build for x86-64:
your app needs > 4 GB address space
your app is performance-critical and could benefit from ~30% performance improvement due to increased size and number of registers
If neither of the above applies then there is no compelling reason to make an app 64-bit.
Related
Using NDK r8c, Eclipse 4.2, Windows 7 64
I've used remote debuggers before (on other platforms, via gigabit ethernet) for large C++ codebases that felt no different than local debugging. The Java debugger that comes with the SDK runs fast too. Therefore I'm quite baffled why gdb is so slow to connect and step over lines of code.
In my current application, which is around 20 static libraries and 1500 source files, it takes about 15 seconds to connect, and about 2 seconds to step. I'm more concerned about stepping.
Has anyone ever profiled gdb to see what the problem is? If so, any suggestions?
I have. My cohorts and I at NVIDIA have contributed several commits to AOSP to address this problem, although our focus has been on shared libraries (symbol load performance, and pending symbol resolution.) We have sped up solib load processing by a factor of 6x. (Although, after doing our own work we discovered that 3x of that 6x had already been solved upstream by GNU, in 7.5... so we abandoned our reinvention, and submitted the relevant 7.5 patches up to Google's NDK repository, which was based on the older 7.3 GDB.) I believe all of our speedups are present in r8d... but I haven't checked.
I cannot think of any reason why static libraries would slow things down, but I must admit I haven't given any thought to them. Do you have a specific reason for believing so, or was that just comment to give perspective about the size and scope of your debugging needs?
We have begun to work on the stepping problem, but don't have anything to share yet. Basically, the bottleneck is ADB (especially on Windows.) Additionally, there is a lot of chatty communication between GDB and gdbserver, when stepping, especially if you are using an IDE with local window, register window, expression window, stack window, etc., all updating with each step. That's a lot of chatter that could likely be optimized for the IDE use-case.
Just some of the fixes that we are considering for speeding up stepping will be IDE-specific:
Using python scripting to pre-process watch expressions in GDB, rather than in the IDE.
Implementing "super-packets" communicating between GDB and gdbserver... packets that encapsulate IDE-specific communications in a way that minimizes chatter between GDB and gdbserver.
We intend to share all of this with the Android community.
I remember hearing that for performance a development machine should be 32 bit, while servers should be 64 bit. I think it was Richard Campell on Dot Net Rocks! that mentioned this.
Why would 32-bit be faster than the 64-bit for a development box and vice versa for servers?
One major reason is the fact that 32-bit OSs can't address 4GB of RAM. 4-8GB can be crucial in a lot of development environments where virtual machines are involved, or even heavy lifting in general. This is why I always stick with 64-bit where possible, and all modern CPUs support it.
It depends in part on your tools - for example, Visual Studio is still a 32 bit app (but usable from x64 - just no huge gain).
However, if you are using your main OS to host VMs, then you can probably benefit from a ton of memory for your various virtuals - and then you can choose 32-bit and 64-bit VMs to suit your needs (it is harder to have a 64-bit guest VM in a 32-bit host).
Personally, I'm still on 32-bit for development. For most of what I do, it is fine.
I run 64-bit 2008 Server and see not performance issues whatsoever. In fact, it's much better than 32-bit XP. It performs generally faster. In a funny way, file operations are quicker on my laptop 5400rpm drive running 64-bit 2008 Server than on a office PC with a 7200rpm drive running 32-bit XP.
I can think of only one thing why you would want to run a 32-bit OS (XP being the latest): you get there IE6 to debug your sites.
The other thing is that a 32-bit OS is incapable of addressing RAM capacity over ~3,4 Gb. If your PC has 4+ Gb of RAM you only loose with a 32-bit OS. Recollecting that even consumer laptops are sold these days with 4, 6 and 8 Gb of RAM, one can safely say goodbye to a 32-bit OS.
If you are talking about non-Windows OS then my experience may not apply.
Having a lot of memory changes the way you work, sometimes dramatically. I run 8 virtual screens with 4 different development environments (1 trunk, 2 branches and a fourth environment for external projects). Just with 12GB mem and a 30" screen.
I don't think that 32 bit machines are faster then 64 machines for developers. It is true that your development environment on a 64 bit OS is running in an emulated 32 bit environment and that creates a slight overhead. On the other hand you will find that the 64 bit OS is slightly faster as the internal data paths are 64 bit enabling the OS to move twice as much data in a single operation. This makes the 64 bit OS slightly faster than a 32 bit OS. The downside of a 64 bit OS is that pointers are twice as big.
What really matters is that 64 bit OS'es are very stable, have access to much more physical memory, and can run both 64 bit and 32 bit applications and virtual machines without sacrificing performance. The 32 bit OS belongs to the past.
I have a 64-bit Ubuntu installed in my laptop. I use it for development and I have no performance issues at all. I have the feeling that computer resources are better used this way.
The only reason I can think of to choose 32-bit OS is that you know that what you develop will work on 32-bit and 64-bit machines. But VS let you choose your target machines...
His point was if you develop for 32bit you will have less than 4GB of ram to work with. And on a 64bit server you may have much more than 4GB of RAM. Basically tricking you into being more frugal with your memory requirements. It had more to do with memory usage than raw number crunching on the CPU.
Although I can't quantify it in numbers, I have noticed the same thing as 'new in town'. I used to run XP x86, and later vista x86 on my notebook. After I upgraded to Vista X64 it is a lot snappier. Don't know if it is a driver issue, the fact that I run SQL Server x64 etc, that it can use twice the amount of cpu registers, optimizations in 'internal' stuff in windows or what, but I can notice the difference...
I'd think the obvious suggestion would be to use whatever OS your code is going to be deployed on. If your development environment is as close as possible to the deployment environment, there's less chance of bugs showing up only in the deployment environment.
I have a small office, and I currently use a Visual Foxpro Application that I wrote to handle all the data.
It is time to buy a new server. It seems that there are problems with VFP and 64 bit operating system. Should I make the move to 64 bit and try to deal with the problems that arise, or buy a new server running the older 32 bit acrhitecture?
The latter would of course require that I use Exchange 2003 instead of 2007 or 2008. Probably no big deal?
Maybe you could use virtualisation products to set up an appropiate environment on the modern server which still is compatible to VFP.
That way you could run the conflicting applications in a virtual 32bit-environment on the new server and the modern applications outside on the real 64bit-environment.
The main reason to upgrade to 64-bit is to allow the OS to utilize more than 4 Gigabytes of RAM. In a 32-bit architecture, the CPU registers are only able to address 2^32 memory locations. In 64-bit processors, you get up to 2^64 memory locations. This is plenty for a long time to come.
Buy two cheap servers instead of a single one. :)
But in all seriousness, if there are issues, you might want to buy a 64 bit box, and then load a 32 bit OS on it.
Then when the issues are cleared up, or you can clear them up yourself, you can do the change over. That's just one idea though.
My other opinion though is to replace the Visual FoxPro Application with something a bit more modern and maintained. ;) You might be amazed how much more efficient some of the dev stacks are - especially for smaller offices.
...as Kosi2801 says about virtualization. That could be applied with my suggestion also. Buy a nice 64 bit box and use VMWare's ESX Server. It might even work out BETTER than actually trying to run all the services on a single box. The tools VMWare has out are VERY impressive these days.
I am looking to purchase a new development PC. My budget is not more than $1,000 USD (including monitor). I am open to laptop (desktop replacement type) or the traditional desktop PC would do just fine.
My primary development environment will be Microsoft, Visual Studio 2008 (and support of older Visual Studio 6 code as well). SQL Server 2005, 2008 as well as legacy support of SQL Server 2000. Microsoft Office 2003, potential to install 2007 but support as far back as Office 2000. The software I will wrote and support will be Windows XP mostly, but some Vista. I am going to have to assume there are 64-bit implementations out there to install to.
My first confusion begins with choosing AMD or Intel. My concern is that there is a compatibility issue with building software using Visual Studio in an AMD environment. I dont have any evidence, its just a concern that hopefully someone will clear up for me.
Last, I am confused about 32-bit and 64-bit installations. Should I stick with the least common denominator (32-bit) even though 64-bit is steadily gaining ground? I am aware that the 64-bit operating systems will address over 4G of RAM and that I like because I would like to set up as many Virtual Machines for test environments as possible, and may have many active at once..
I am not looking for the dream machine, just a machine with a monitor and the best processor for about $1000 that will allow me to write software for the majority of machines out there.
There are some instruction level differences between AMD and Intel but nothing that Visual Studio is going to uncover. Perhaps if you were developing with Sun Studio you might run into them (I have!).
I would go for a 64 bit machine and run 32 bit VMs on it if you feel the need to do testing in that environment. The common feeling around here seems to be that the highest level of Vista you can afford is the platform on which to develop.
With 32-bit XP and Vista, you might not have access to much more than 3GB or RAM, but possibly quite less (My home machine could only access 2.25GB with Vista 32). If you can afford getting a machine with 4GB of RAM, I would recommend using Vista-64 (Home Premium or Ultimate).
Depending on what kind of development you are doing hard drive speed can make a big difference in compile times. Get 10,000 RPM hard drives if possible for a desktop machine and 7200 RPM drives for a laptop, but they do cost more.
AMD smoothed out their incompatibilities long ago. Your decision on that should simply be which brand you feel has better performance/features. I would definitely go with 64 bit because you can always emulate 32 bit for VM's and apps and so on. The ability to use extra memory will pay dividends later when you're just spending $100 for another 2-4 gigs instead of another $1000 to finally buy a 64 bit machine.
Given you're interested in running multiple VM's RAM is going to be key, as is the CPU.
Currently Intel are ahead on performance for dollar (especially if you are interested in overclocking) however AMD's options are acceptable and the batch of phenoms seem to be better at true quad core applications than the Intel quads.
The quality and speed of the RAM is largely unimportant. Generic DDRII 800mhz will be fine, just make sure you've got 4 or 8 GB of it.
In terms of operating systems, xp 64bit is fairly wanting on driver support even though it's been around for a while. Vista 64bit however has almost all the driver support of Vista 32bit. While this means that some of your older devices wont work, you should have much less hassles with Vista than XP. In terms of versioning, I recommend premium, however you'd need to look into the added feature list to determine if it's worth it or not (to me, it's not worth it at all).
In terms of issues that may occur due to specific processors? I agree with stimms that while there may be slight differences, it's not something you'd encounter in VS development. However my experience in that arena is by no means extensive.
If you look for a not-too-expensive dev machine, AMD should be better.
AMD 780G/790G mainboard has on-board integrated VGA, out-perform most nvidia/intel video integrated mainboard at a reasonable price. AMD Phenom CPU's performance is not as good as those of Intel. But considering you can get a AMD 3-core CPU at the price that Intel offers you only 2-core, it's a good deal.
Intel's CPU has great overclock potential. However as a developer, I suppose you like a solid-as-a-rock machine and not like to take risk geting a blue death screen while compiling your code.
Hardware virtualization is important if you like to paly with X64 virutal machine for testing. Most modern AMD CPUs have hardware virtualization feature built in, while Intel cut this feature from its low-end CPUs.
Get 4 gigs rams minimum equal that you need a system that can handle more than 3 gigs (so 64bits OS). Rams is cheap and IDE with all others software (debugging, testing, database client, etc) will require you some rams if you want something fast.
For the cpu, you can get a Quad Core for less than 190$, with a board that can handle it (about 125$) you have a strong start. You do not need to have the latest video card...
A lot of already build PC can be nice for you under your budget (under 720$). See this example:
Vista Home Premium 64-bit
320 gig hard drive
3 gig rams
GeForce 7100 graphics
22" Acer LCD included
Core 2 Duo E4700
I have just installed a build server with a 64 bit windows server 2008 for continuous integration.
The reason I choose a 64 bit server was to have more than ~3Gb of RAM. I had hopes that this machine would provide blazing fast builds.
Unfortunately, the result are lacking greatly to say the least. My desktop provides faster builds than this server equipped with a Xeon quad core, 15k RPM SAS and 8 Gigs of RAM.
We use Visual C++ 2005 to compile our 32 bit application with Cygwin.
Could the WOW64 emulator be the bottleneck that is slowing down the build process?
Any pointers, comments would be greatly appreciated.
Regards,
We use Visual C++ 2005 to compile our
32 bit application with Cygwin.
I think that's the problem. I like Cygwin a lot, but it is really slow when it comes to file I/O. It helps a bit to deactivate the NTFS filesystem feature to keep track of the last file-access.
To get a better speed boost port your build-script / makefile to use the native command shell if pssible and only call cygwin-tools if there is really no replacement available.
If you use the gcc compiler try the mingw version. That one is a lot faster.
WOW64 is not an emulator on x64. The processor natively executes 32-bit x86 code. At the bottom of the user-mode stack, under kernel32 et al, are DLLs which map system calls to the 64-bit call interface.
See WOW64 Implementation Details.