Uhm, I hate to break it to you... but, vCenter itself is NOT a native 64-bit application. Go look at the process list, vpxd is clearly running in 32-bit mode. That's been fairly consistent with how it's ran since beta 1 of 4.0. It kind of makes sense, actually.. Not everybody is ready to, or wants to go x64 for VM's unless there's a reason to do so, so being able to install on either a 32 or 64-bit O/S is kind of handy, don't you think? Frankly, I really don't think it's a step back to have to create a 32-bit DSN.... Just requires a little bit of RTFM. Can you elaborate on what isn't thorough enough? The documentation clearly tells you what to do. Is your point of frustration that vCenter is not yet a completely native x64 application?

I don't work for VMware, just a curious bystander scratching my head in confusion as to the real problem here?

I have the same question as Parker.

What is the reason for using a 32 bit DSN. If the OS and Database are 64 bit, then why using 32 bit DSN? Is that means, Vcenter is not a true 64 bit application but made it such a way that it can be installed on a 64 Bit OS?

Are there any perfromance gain by having this? I'm looking for a clear answer to the reason for using 32 bit DSN.

Thanks

DC

Possibly because it doesn't really matter. Making an application 64-bit makes it use more memory (because all the pointers, and many other datatypes, in its data structures double in size). If you don't need >2GB of RAM for your application -- and vCenter isn't anywhere close to that big -- then there really is no need to make the application 64-bit. You'd gain nothing, and probably lose some performance. OK, so 64-bit end-to-end might be "neater" but that's about it.

Tim

No, not long. Only 10 years (IRIX 6.4 on SGI Origin servers, and Digital UNIX on Alphas). You've assumed, with no knowledge of who I am, or what I do for a living, that somehow I'm an ignoramus who doesn't know my arse from my elbow. Well, I've got news for you. I run one of the world's largest supercomputers for a living, it's been 64-bit since we started, because we've need applications to use more that 4GB of RAM (we had a system with 256GB of RAM back in 2001). In other words: I do know what I'm talking about.


They've had time to fix bugs. Moving from 32 to 64 bit is completely irrelevant to that. It's just as possible to write good stable code in 32-bit as in 64-bit.


It's called "marketing". Lots of gullible punters will think "64 is bigger than 32, so 64-bit must be better, right?" without actually thinking about what it really means. The result: lots of software sales, and big fat commission bonuses.


Technical manuals, and 15 years' experience as a sysadmin and programmer in high performance scientific computing.


Agreed. Where did I say it was a buzzword? Where did I say it shouldn't be adopted? Where did I say the technology itself isn't important? I didn't. All I said was that for this particular application, the move to 64-bit is not important.


For precisely the reason that I said, which you seem to have ignored. This client is a small application. It doesn't have to handle large amounts of data. 64-bit x86_64 operating systems can run 32-bit code natively, with no performance hit. Therefore, it is quite understandable that VMware made converting this application to 64-bit a low priority. By contrast, converting the server components to 64-bit was much more important, because they do handle larger amounts of memory; ESXi itself, for example, has to be able to handle physical servers with very large amounts of RAM, and that's something which cannot be done efficiently with a 32-bit OS. So obviously they did the server components first, and left the client to last because making it 64-bit won't enable any new functionality or features.


No there isn't. The move from 32-bit does nothing to increase stability. If I write an application for a 32-bit system, and then recompile it for 64-bit, any bugs it had as a 32-bit program will still be there in the 64-bit program. There may even be more, due to invalid assumptions about the size of certain data structures. I'd like you to describe for me exactly what you think there is "more to it" than (1) doubling the number of bits in some integer types and (2) doubling the number of bits in pointers, so that they can address flat memory spaces larger than 4GB. Enlighten those of us who went through the 32->64-bit transition 10 years ago and clearly missed something. Please. The Linux community might like to know, too, since apart from these two things, there's no difference between a 32-bit version of Linux and a 64-bit version. The same source code is used to build both versions. The same is probably true of Windows 7, although of course I don't have access to the source code to check. I certainly used to compile my Windows programs for both 16- and 32-bit Windows versions from the same source code, back in the day that that was necessary.

In the high performance computing stuff that I run, we actually moved some applications back from 64-bit to 32-bit, because the extra memory required for the 64-bit versions made them slower (more RAM required leads to greater frequency of CPU cache misses leads to poorer performance). The difference can be quite significant, because cache is about an order of magnitude faster in latency terms than main memory, so if an application which manages to run almost entirely within cache then grows large than the cache, the performance hit can be enormous. Not that any of that is relevant to something like the vSphere client, because it isn't a CPU-bound application.

This isn't the same as the 16-bit to 32-bit transition of the 80's. In that transition, stability was improved, but that wasn't because of the increase in the bits. It was because of additional memory protection features available in the 32-bit modes of 386 and later processors, compared to the 8086 and 80286, and Linux, OS/2 and Windows NT all took advantage of that.

Regards,

Tim

At no time did I say 64-bit is hype. All I said is that for small
applications it isn't necessary. Surely you can't disagree with that?

And whether you disagree with me or not, the tone of your response was
quite unnecessary.

On 14 Aug 2009, at 19:30, RParker <communities-emailer@vmware.com