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.
Related
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.
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.
This is only a half-way programming question. First of all I have a PCI-Express card and 32/64 bit drivers. The target operating system has to be a Windows 64 bit system. I read that under Vista64 all drivers have to be certified 64 bit drivers. Is this a general restriction under 64 bit operating systems and does this also apply to "XP 64" or any Linux system?
So for simplicity let's say I use a 64 bit driver for my PCIe card under Vista64 and have a bunch of 64 bit DLLs to use the cards functionality. On the other side there's a large, legacy 32 bit exe program which needs to use the PCIe device. Converting the program to 64 bit would be a really huge effort.
So what can be done to bring that 32 bit program and the 64 bit driver together? I read that mixing 32/64 bit binaries and DLLs is not possible at all but this is hard to believe for me. I'm sure you can print out a document under Vista64 from within a 32 bit app and Windows will somehow wrap this around to a 64 bit printer driver.
64-bit certification is only required under Vista; there is no certifying authority for non-Windows platforms, and I don't believe that XP or Windows Server checks for certification (not sure though, and it may depend on which service pack you're on).
If you're using the driver via the Windows API, then there shouldn't be any problem; Windows will do the 32<->64-bit translations in the kernel. If you're trying to load the driver inside your own process, that probably won't be possible. As Dirk says you'll have to run it inside its own process and communicate through a COM server. I'm not sure what hoops you'll have to jump through if you have to run your driver in a higher-privilege execution level and want to make calls to it from user mode.
Hopefully your 64-bit DLLs offer a 32-bit API, or Windows offers a standard driver interface (if it's a common I/O device like a display or network card).
Does your 32-bit application directly call the driver? (I'm guessing a simulator for the driver!)
The only way to communicate between 32-bit and 64-bit dlls is to write a COM server that manages the communication (read: wrap EITHER the applications calls OR the 64-bit driver responses) in between.
One thing that came back to bite me: When I first wrote this COM server (yes, I too had to bear many sleepless nights before I came to know of this trick) I only built the 32-bit version of the (auto-generated) proxy/stub dll. Another bout of sleepless nights ensued before I came to know of the solution: Build the proxy/stub dll for both 32-bit and 64-bit. The 32-bit side deals with the 32-bit side (in your case the application) and the 64-bit with the 64-bit side (the driver). COM manages how the differnt versions of the proxy/stub talk to each other. And oh, do get the server registered on your system. Easy, right?
I think the whole point of a driver is to abstract away the actually workings of the hardware and present a common interface to the software. In this case, the PCIe driver needs to be 64-bit so that it can act as a go-between for Windows and the hardware, but I would think that a 32-bit application could then access the device without any troubles at all.
What's meant by that incompatibility you read about is that 32 and 64-bit assemblies can't be part of the same application - an application has to target either one or the other, though 32-bit application will generally run fine on Windows x64 using WoW64, which just acts as a translator.
Are you currently experiencing problems, or are you just asking hypothetically?
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
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Can I run a 64-bit VMware image on a 32-bit machine?
I've googled this, but there doesn't seem to be a conclusive answer.
I know that it would have to be completely emulated and would run like a dog - but slow performance isn't necessarily an issue as I'm just interested in testing some of my background services code on 64-bit platforms.
The easiest way to check your workstation is to download the VMware Processor Check for 64-Bit Compatibility tool from the VMware website.
You can't run a 64-bit VM session on a 32-bit processor. However, you can run a 64-bit VM session if you have a 64-bit processor but have installed a 32-bit host OS and your processor supports the right extensions. The tool linked above will tell you if yours does.
If you have 32-bit hardware, no, you cannot run a 64-bit guest OS. "VMware software does not emulate an instruction set for different hardware not physically present".
However, QEMU can emulate a 64-bit processor, so you could convert the VMWare machine and run it with this
From this 2008-era blog post (mirrored by archive.org):
$ cd /path/to/vmware/guestos
$ for i in \`ls *[0-9].vmdk\`; do qemu-img convert -f vmdk $i -O raw {i/vmdk/raw};done
$ cat *.raw >> guestos.img
To run it,
qemu -m 256 -hda guestos.img
The downside? Most of us runs VMware without preallocation space for the virtual disk. So, when we make a conversion from VMware to QEMU, the raw file will be the total space WITH preallocation. I am still testing with -f qcow format will it solve the
problem or not. Such as:
for i in `ls *[0-9].vmdk`; do qemu-img convert -f vmdk $i -O qcow ${i/vmdk/qcow}; done && cat *.qcow >> debian.img
Yes, running a 64-bit OS in VMWare is possible from a 32-bit OS if you have a 64 bit processor.
I have an old Intel Core 2 Duo with Windows XP Professional 2002 running on it, and I got it to work.
First of all, see if your CPU is capable of running a 64-bit OS. Search for 'Processor check for 64-bit compatibility' on the VMware site. Run the program.
If it says your processor is capable, restart your computer and go into the BIOS and see if you have 'Virtualization' and are able to enable it. I was able to and got Windows Server 2008 R2 running under VMware on this old laptop.
I hope it works for you!
If your hardware is 32-bit only, then no. If you have 64 bit hardware and a 32-bit operating system, then maybe. See Hardware and Firmware Requirements for 64-Bit Guest Operating Systems for details. It has nothing to do with one vs. multiple processors.
It boils down to whether the CPU in your machine has the the VT bit (Virtualization), and the BIOS enables you to turn it on. For instance, my laptop is a Core 2 Duo which is capable of using this. However, my BIOS doesn't enable me to turn it on.
Note that I've read that turning on this feature can slow normal operations down by 10-12%, which is why it's normally turned off.
I honestly doubt it, for a number of reasons, but the most important one is that there are some instructions that are allowed in 32-bit mode, but not in 64-bit mode. Specifically, the REX prefix that is used to encode some instructions and registers in 64-bit mode is a byte of the form 0x4f:0x40, but in 32 bit mode the same byte is either INC or DEC with a fixed operand.
Because of this, any 64-bit instruction that is prefixed by REX will be interpreted as either INC or DEC, and won't give the VMM the chance to emulate the 64-bit instruction (for instance by signaling an undefined opcode exception).
The only way it might be done is to use a trap exception to return to the VMM after each and every instruction so that it can see if it needs special 64-bit handling. I simply can't see that happening.
VMware? No. However, QEMU has an x86_64 system target that you can use. You likely won't be able to use a VMware image directly (IIRC, there's no conversion tool), but you can install the OS and such yourself and work inside it. QEMU can be a bit of a PITA to get up and running, but it tends to work quite nicely.
VMware does not allow you to run a 64-bit guest on a 32-bit host. You just have to read the documentation to find this out.
If you really want to do this, you can use QEMU, and I recommend a Linux host, but it's going to be very slow (I really mean slow).
Yes, you can. I have a 64-bit Debian running in VMware on Windows XP 32-Bit. As long as you set the Guest to use two processors, it will work just fine.
You can if your processor is 64-bit and Virtualization Technology (VT) extension is enabled (it can be switched off in BIOS). You can't do it on 32-bit processor.
To check this under Linux you just need to look into /proc/cpuinfo file. Just look for the appropriate flag (vmx for Intel processor or svm for AMD processor)
egrep '(vmx|svm)' /proc/cpuinfo
To check this under Windows you need to use a program like CPU-Z which will display your processor architecture and supported extensions.