Is there any reason to choose a 64bit debian over a 32bit debian instance on Amazon EC2?
64bit Apps simply take more memory (which is crucial & has a high premium in VPS & Cloud servers).
Are there any other things that I should consider in making this choice?
64-bit apps will use the 64-bit instruction set which carries a great deal more optimisations than default x86 packages Which can result in better performance as compared to its x86 counterpart.
Related
I'm a long-time user of Cygwin. I'm running Win7/x64, but my Cygwin installation is 32-bit. At the time I installed it, 64-bit version was considered experimental. Now the Cygwin website lists 32-bit and 64-bit versions on their website without any special mentions or recommendations on which one to use.
As a programmer, my experience is: unless specifically designed for capabilities of 64-bit CPUs, very few applications can get any gains by being recompiled for a 64-bit CPU. They might use more memory, though, since each memory pointer now uses 8 bytes rather than 4.
So, my question is: is there any benefit to choose 64-bit Cygwin over 32-bit ones? Should I upgrade my 32-bit installation sooner or later?
Performance/memory benchmark results for common usage patterns (e.g. running common UNIX commands, particular shell scripts etc.) would be very welcome.
If you've upgraded your 32-bit Cygwin to 64-bit, please tell your story - was the upgrade worth it?
EDIT: I've been using 64-bit Cygwin for a while now, and haven't really noticed any differences - good or bad - from the 32-bit version.
After running 32-bit Cygwin at work for a number of years, I recently upgraded to 64-bit. It was quite painless as you can run the two installations side-by-side. For me, there was no noticeable difference in performance though I did not run any benchmarks. The biggest gain for me in upgrading was starting with a new fresh install without any of the cruft that built up over the last few years.
The one disadvantage that I had when running 32-bit Cygwin was that the WoW64 subsystem filesystem redirector silently redirects 32-bit applications. This has the result that running ls /cygdrive/c/Windows/System32/ in 32-bit Cygwin doesn’t actually display the contents of %WINDIR%\System32, but instead %WINDIR%\SysWOW64. Attempts to access files in the %WINDIR%\System32 directory, e.g., ls /cygdrive/c/Windows/System32/nbtstat.exe fail with the error message:
ls: cannot access /cygdrive/c/Windows/System32/nbtstat.exe: No such file or directory
This means that Windows commands installed in %WINDIR%\System32 such as nbtstat and dnscmd aren’t available without modifying the PATH. The work-around for accessing 64-bit Windows files was that the %SystemRoot%\sysnative pseudo-directory had to be used, e.g., to run the nbtstat command, use /cygdrive/c/Windows/Sysnative/nbtstat.
32-bit applications on 64-bit Windows
WoW64 (Windows 32-bit on Windows 64-bit) is a subsystem capable of running 32-bit applications. It is included on all 64-bit versions of Windows and creates a 32-bit environment to run unmodified 32-bit applications on a 64-bit system using DLLs to provide the necessary interfaces.
Windows uses the %SystemRoot%\system32 directory for its 64-bit library and executable files. This is done for backward compatibility reasons, as many legacy applications are hardcoded to use that path. When executing 32-bit applications, WoW64 transparently redirects 32-bit DLLs to SystemRoot%\SysWoW64, which contains 32-bit libraries and executables.
32-bit applications are generally not aware that they are running on a 64-bit operating system. 32-bit applications can access %SystemRoot%\System32 through the pseudo directory %SystemRoot%\sysnative.
For 64-bit applications (such as Windows Command Prompt, cmd.exe) there’s no filesystem redirection:
See also: File System Redirection
I ran one I/O heavy benchmark, but even for this the noticeable performance gain is well worth it.
On a cygwin bash shell on Windows 7, I ran a find of many patterns piped to grep and then redirected to a file on the same hard drive in 32 and 64 bit:
32 bit
real 1m58.57s 68% more time
user 0m11.95s 41% more time
sys 0m40.83s 23% more time
64 bit
real 1m10.36s
user 0m8.50s
sys 0m33.05s
This question is for the G-WAN development team.
I know that you've discontinued G-WAN 32-bit due to the very low demand of G-WAN for the Linux 32-bit platform.
But, with regard to both the worldwide success of the Rapsberry low cost computer and the very low footprint of the G-WAN web applicaton server, does the G-WAN folks plan to make a G-WAN release (for now, only in 32-bit but sooner than later for 64-bit for this computer) that could be used on the last Rapsberry Pi3 machine (using an ARM CPU) and running the Raspbian OS?
TIA for your (Gil) answer.
They are two incompatible platforms for the binary executable files so the fact that we discontinued the 32-bit release for x86 CPUs does not have relations with any release compiled for ARM CPUs, 32 or 64-bit.
G-WAN releases for other platforms than x86-AMD64 may come at a later stage but this greatly depends on business opportunities. For now a VHDL port is under progress.
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 am pricing a new software development machine and looking at the dell precision series.
When I get to this screen:
http://www.dell.com/content/topics/reftopic.aspx/pub/products/precn_kat?c=us&cs=555&l=en&s=biz&~section=T7400
The first choice is: Buy a Precision WorkStation T7400 32bit Now!
and the second choice is: Buy a Precision WorkStation T7400 64bit Now!
am I really at that point just deciding which software I want installed? or is there actually a different chipset depending on the choice.
I don't want to limit my options down the road by picking the wrong one - I can always upgrade the software - but I don't want to have to replace hardware.
BTW: This will be for SD of a Microsoft stack, asp.net, vs 2008, sql server etc and I would like to start using virtualization (probably from MS) with this machine purchase.
Both options give you the same choice of processors, they are all 64-bit capable. It's just a matter of whether a 32-bit or 64-bit version of the OS is preinstalled on it.
I would go with the 64-bit option simply because, in my experience, you can easily run both 32-bit and 64-bit VMs on a 64-bit platform, but are limited to 32-bit VMs on a 32-bit platform.
64-Bit, but just not XP64 (Which Dell offers as a downgrade). Driver situation is quite awful, and there are some incompatibilities in Software. If you need/want to stick to XP, go 32-Bit, if you want to use Vista or Windows Server 2008, 64-Bit is fine.
The only difference is the operating system anyway, so you can freely switch between installing 32 or 64 Bit Windows, you may just need to buy another License.
100% 64bit. RAM is cheap and you'll eventually want to use more than 4GB of it, especially if you've going to be running virtual machines.
64bit all the way. Vista64 is mature at this point, I haven't run into any issues. If you need 32bit for any older peripherals you might have, install XP32 as a VM.
As far as I know you can't really buy a 32-bit PC nowadays. I think the OS is the only different between the 32bit and 64bit version.
For .NET development it doesn't matter whether you're using a 64-bit OS or not. However 64-bit SQL Server maybe running faster.
And you'll also need more than 4GB RAM (especially if you run virtual machines), so I don't really see any reason to choose a 32-bit OS over a 64-bit one.
I would go for 64bit with 64bit Operating System. Only problem i encountered so far is that 32bit apps cannot access 64-dlls -> For example the context menu of TotalCommander won't show 64bit apps (e.g subversion) which might be inconvenient for development.
It can be difficult to get 64bit drivers for exotic or very new hardware, so if that's a concern for you, you might want to stick to the 32bit OS.
Actually I will want to use that JeOS for our webserver. Is it a good choice?
Thanks for piquing my interest. From the Ubuntu website:
Ubuntu Server Edition JeOS (pronounced
"Juice") is an efficient variant of
our server operating system,
configured specifically for virtual
appliances. Currently available as a
CD-Rom ISO for download, JeOS is a
specialised installation of Ubuntu
Server Edition with a tuned kernel
that only contains the base elements
needed to run within a virtualized
environment.
It looks promising to me - I run several full Ubuntu 8.04 VMs so I'll certainly check it out. Why not just try it?
Be aware that the kernel it installs is striped down to only have the stuff required for virtual machines, therefore you might have problems accessing the network from a real machine. (Note that the install-CD kernel isn't the same as the installed kernel as well).
If you can bypass that (IIRC I booted from the CD, and downloaded the normal server kernel and it all worked fine), then you end up with an absolutely minimal Linux system, but backed by the full Ubuntu repositories, so it's an excellent base for a server.
Also note minimal really means minimal - no cron by default for example.
Is it a good choice?
If you plan to run JeOS in a virtual machine, then yes, this is a good choice.