View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0009839CMakeCMakepublic2009-11-04 09:332012-02-06 06:07
ReporterSean McBride 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionCMake 2.8.6Fixed in VersionCMake 2.8.6 
Summary0009839: Official Mac OS X CMake binaries should be built as 3-way Universal (i.e. add 64 bit)
DescriptionKitware's CMake 2.8rc5 binaries are built as 2-way universal:

$ lipo -info /usr/local/bin/cmake
Architectures in the fat file: /usr/local/bin/cmake are: ppc i386

As of Mac OS X 10.6 (current), Apple recommends always building as 64 bit. Almost all processes that ship with 10.6 as 64 bit.

Advantages for CMake:
 1- performance: x86_64 has more registers that i386, generally giving a performance boost
 2- performance: launch time. since built-in apps are 64 bit, the first 32 bit app to launch suffers a performance penalty as all shared libs need to be reloaded for 32 bit.
 3- other: http://www.apple.com/macosx/technology/#64bit [^]

Note: I'm not suggesting dropping ppc and i386, just adding x86_64. Adding ppc64 is probably not worth it BTW because (1) above does not apply and because PowerPC Macs can't run 10.6 anyway.

It's too late for such a big change in 2.8.0, but maybe 2.8.1?

I have 64 bit dashboards already BTW.
TagsNo tags attached.
Attached Files

 Relationships
related to 0012460closedDavid Cole Cant edit FILEPATH variables in cmake-gui on OSX 

  Notes
(0018337)
Bill Hoffman (manager)
2009-11-04 10:14

I don't see the benefits. Is it really that much faster to have a 64 bit CMake? I would like to see the numbers, as it will take longer to build, require me to get a new build machine (32 bit is currently being used). Will it work on older Macs? People can always build it themselves, but I seriously doubt it will have any noticeable impact on any project. Do you have numbers?
(0018340)
Sean McBride (reporter)
2009-11-04 10:28

The proposed change will not affect older Macs. I'm proposing that it be built 3-way universal: ppc, i386, x86_64. Which of the 3 is chosen at run time depends on 1) the machine's capabilities 2) the OS's preference 3) the user's preference.

Your 32 bit machine would still be able to build as 64 bit (just as it builds ppc), but of course not be able to execute that 64 bit code.

I don't have any hard performance numbers for CMake itself. Average general improvement I've seen others talk about (in general) is something like 5-10%. Not a massive improvement to be sure.

The best argument really is "because this is now best practice on the platform". All apps that come with 10.6 are now 64 bit. gcc now builds 64 bit by default.

64-bit executables also have a security benefit, as the NX bit is always used:
http://en.wikipedia.org/wiki/NX_bit#Mac_OS_X [^]
(0018341)
Bill Hoffman (manager)
2009-11-04 10:49

I really don't think it is worth the effort.... Also, it makes the download that much bigger, and the build take that much longer. I may do it in the future, but I really don't see any reason to rush this. I would like to see some numbers. Perhaps configure something big like ParaView with 32 and 64, what do you get?
(0018979)
Sean McBride (reporter)
2009-12-22 13:47

I built both a 32 bit and 64 bit only cmake, and tried configuring VTK with each. There was no significant performance difference.

I agree there isn't a big rush to do this.

But I still think it should be done "soonish". If for no other reason than "marketing". 32 bit only apps will soon enough start to look like "laggards", just as PowerPC-only apps did when Macs switched to Intel.
(0018980)
Bill Hoffman (manager)
2009-12-22 14:08

So, to "look" better we should increase the download size by %50... I don't think many people will care what the binary is, as long as it does the job, and does it efficiently. That said, at some point I suppose it should be done just to make sure it works with each release of CMake.
(0018981)
Sean McBride (reporter)
2009-12-22 14:29

There is a tradeoff with file size, to be sure.

There are also forward compatibility issues. 10.6 dropped support for PPC Macs, and even the PPC emulation is now not installed by default. Mac OS will eventually be 64 bit only.

Anyway, I'm not trying to be argumentative here. :) I just wanted to get this in the bug database so that it's on your radar. It's certainly not urgent.
(0027114)
Sean McBride (reporter)
2011-07-29 11:29

Just wanted to ping this issue... 1.5 years later...

Mac OS X 10.7 Lion is now out. It drops support for 32 bit hardware, i.e. a 64 bit Intel CPU is now required to run the OS. 32 bit executables are still supported however.

Let's review history:

10.5 dropped support for Classic (to run OS 9 apps in emulation)
10.6 dropped support for PPC hardware
10.7 dropped support for Rosetta (to run PPC apps in emulation), and for 32 bit Intel hardware

I would expect 10.8 to drop support for 32 bit intel apps.

If binary size is a big concern, you could provide two Mac binaries:

1) as currently: 10.4+, ppc and i386
2) 10.6+, i386 and x86_64
(0027145)
Bill Hoffman (manager)
2011-08-01 13:13

Can someone actually profile CMake for 64 bits? I just don't see it making a big difference or anyone really noticing or caring. It will take some work to move this to a new machine and changing the release process. We have lots of other issues that seem more important.
(0027146)
Sean McBride (reporter)
2011-08-01 13:26

I did profile it (see previous comment). Indeed, it does not make a big difference to performance.

Again, I agree this is not urgent.

IMHO, the issue is one of 1) marketing and 2) compatibility.

For (1), everything these days is expected to be 64 bit, and it reflects poorly that CMake is not. Certainly, CMake does not need a 64 bit address space, etc. etc., it's a question of perception.

(2) is more important. Apple is renowned for deprecating/obsoleting things quickly. As I said, I'd wager that 10.8 won't support 32 bit apps. That means the binaries that you are distributing today won't work tomorrow. This could be problematic for 10.8 users of the future that need to run older CMakes for compatibility reasons or regression testing.

I don't feel strongly that this needs to be in a 0.0.1 release (thought it would be nice), but I do feel strongly that it should be done for the next 0.1 release.
(0027323)
David Cole (manager)
2011-09-02 17:29

As of CMake 2.8.6-rc1 there are now "Darwin64*" installers in addition to the "Darwin*" installers...

The Darwin64* installers are 2-way universal binaries of "x86_64;i386" built with a deployment target of 10.5. Unfortunately, they don't appear to work on Mac OS X 10.5 because of a Qt library issue. They do work on 10.6 and 10.7 machines, though. Built against Qt 4.6.4.

The Darwin* installers are the same as they ever were: 2-way universal binaries of "ppc;i386" built on a 10.4 system with default deployment target (therefore, deployment target of 10.4). Built against Qt 4.3.3.

As of this writing there is one other difference between these two builds. The older Darwin builds have the C++ runtime library statically linked in. The Darwin64* builds depend on the dynamic version of the C++ runtime library. That may change if we can figure out how to statically link the C++ runtime in to the newer build... For now, the 64-bit builds depend on the dylib.
(0028489)
David Cole (manager)
2012-02-06 06:07

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2009-11-04 09:33 Sean McBride New Issue
2009-11-04 10:14 Bill Hoffman Note Added: 0018337
2009-11-04 10:14 Bill Hoffman Status new => assigned
2009-11-04 10:14 Bill Hoffman Assigned To => Bill Hoffman
2009-11-04 10:28 Sean McBride Note Added: 0018340
2009-11-04 10:49 Bill Hoffman Note Added: 0018341
2009-12-22 13:47 Sean McBride Note Added: 0018979
2009-12-22 14:08 Bill Hoffman Note Added: 0018980
2009-12-22 14:29 Sean McBride Note Added: 0018981
2011-07-29 11:29 Sean McBride Note Added: 0027114
2011-07-29 12:02 David Cole Assigned To Bill Hoffman => David Cole
2011-07-29 12:02 David Cole Target Version => CMake 2.8.6
2011-08-01 13:13 Bill Hoffman Note Added: 0027145
2011-08-01 13:26 Sean McBride Note Added: 0027146
2011-09-02 17:29 David Cole Note Added: 0027323
2011-09-02 17:29 David Cole Status assigned => resolved
2011-09-02 17:29 David Cole Fixed in Version => CMake 2.8.6
2011-09-02 17:29 David Cole Resolution open => fixed
2011-09-16 11:24 David Cole Relationship added related to 0012460
2012-02-06 06:07 David Cole Note Added: 0028489
2012-02-06 06:07 David Cole Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team