[todd]

Has anyone seen any technical details on the pros and cons of running the 32 vs 64 bit kernel? I set my MacBook Pro to use the 64bit kernel, and had to update one kext, but after that it works great. But, I'm wondering if there are any non-obvious efficiencies or drawbacks to using 64 bit.

I have seen people throw around the common claims, like "using 64 bit pointers wastes memory/cache", and others refuting those claims. Having the 32bit kernel running 64bit apps confuses the issue a bit (at least for me the implications are not obvious). Has anyone seen good resources addressing things like:

- Does the 32bit kernel have access to the larger number of registers available in x86_64 mode?
- Are there any extra operations / translations needed in the mixed mode (32bit kern/64bit app; or the opposite)?
- The apple site claims security advantages for 64 bit (NX bit, different function passing). Are these effected by the kernel?

[mduell]

Got to love a company that shipped a bunch of computers with 64-bit capable CPUs, but won't support them booting a 64-bit kernel.

[olePigeon]

Originally Posted by mduell 

Got to love a company that shipped a bunch of computers with 64-bit capable CPUs, but won't support them booting a 64-bit kernel.

It's probably transitional to make sure hardware drivers are written and available for people that boot into 64-bit.

I think it's smart, actually. Even if you boot into 32-bit you can still run the 64-bit software. Later on I'm sure the default kernel will be 64-bit. Otherwise you run into the problem that Microsoft has with Windows and hardware support for their 64-bit OSes.

[Simon]

It is smart. It's actually pretty much the smartest approach to 64 bit we've seen so far.

[Spheric Harlot]

I think that an apple-centric board is an EXCELLENT place to criticise apple.

It's not like he's trolling or doesn't have a point...

[Eug]

Agreed. I'm very happy with Apple's 64-bit implementation (except for the fact that it took longer than it should have). I get 64-bit Safari speed for example (and yes, the 64-bit is significantly faster), while keeping backwards compatibility for all the old 32-bit drivers.

Basically it's a painless upgrade, unlike the pure 64-bit implementations elsewhere.

[todd]

Originally Posted by Eug 

Agreed. I'm very happy with Apple's 64-bit implementation (except for the fact that it took longer than it should have). I get 64-bit Safari speed for example (and yes, the 64-bit is significantly faster), while keeping backwards compatibility for all the old 32-bit drivers.

I see in the 'everything apple' blog linked from your post the 64 bit Safari numbers.. Does anyone have an explanation for why this would be? I am also running the 64 bit kernel, but I didn't do any A-B testing between the kernels, and I really didn't expect much of a performance difference.

Is the speedup something specific to the Safari 64 bit version, or just a symptom of efficiency of running the 64 bit kernel, or efficiency of a 64 bit app on a 64 bit kernel?

[besson3c]

Yeah, I want to know the exact same thing. For apps that you'd think wouldn't benefit from being able to address more than 4 GB of RAM (or systems that don't even have 4 GB of RAM), how is it that the 64 bit versions are sometimes a little faster?

[mduell]

Originally Posted by mduell 

Got to love a company that shipped a bunch of computers with 64-bit capable CPUs, but won't support them booting a 64-bit kernel.

Originally Posted by olePigeon 

It's probably transitional to make sure hardware drivers are written and available for people that boot into 64-bit.

I think it's smart, actually. Even if you boot into 32-bit you can still run the 64-bit software. Later on I'm sure the default kernel will be 64-bit. Otherwise you run into the problem that Microsoft has with Windows and hardware support for their 64-bit OSes.

Originally Posted by Simon 

It is smart. It's actually pretty much the smartest approach to 64 bit we've seen so far.

Reread my comment. It's not about booting 32-bit by default (which is a good idea, that I'd even say extend to Xserves since most don't have >32GB RAM). It's about the inability to boot a 64-bit kernel with a 64-bit CPU.

Originally Posted by besson3c 

Yeah, I want to know the exact same thing. For apps that you'd think wouldn't benefit from being able to address more than 4 GB of RAM (or systems that don't even have 4 GB of RAM), how is it that the 64 bit versions are sometimes a little faster?

If you're not doing a lot of OoOE, the extra GP registers may help.

[CharlesS]

Originally Posted by besson3c 

Yeah, I want to know the exact same thing. For apps that you'd think wouldn't benefit from being able to address more than 4 GB of RAM (or systems that don't even have 4 GB of RAM), how is it that the 64 bit versions are sometimes a little faster?

In addition to the extra registers, 64-bit Cocoa apps get an improved runtime. I have no idea if there are any performance benefits to this, but there are a number of usability improvements - you don't have to declare instance variables anymore, the fragile base class problem is fixed, etc.

Also, if you are designing an app that has to be compatible with Tiger, you can #ifdef a bunch of Leopard-specific performance-enhancing features (such as foreach loops) into the 64-bit binary, since you know for sure that that one won't be running on any OS earlier than Leopard.

I have no idea if any of these have anything to do with what's being reported, but just a few things I thought I'd throw out there.

[chabig]

Originally Posted by mduell 

It's not about booting 32-bit by default (which is a good idea, that I'd even say extend to Xserves since most don't have >32GB RAM). It's about the inability to boot a 64-bit kernel with a 64-bit CPU.

Yeah. I can't figure out why Apple didn't build 64 bit EFI into the first Intel Macs. I'm sure the transition from PPC to Intel didn't require a lot of work. And we all know they had the 64 bit kernel written and debugged back in 2005, just sitting around waiting to go, and that they've been sitting on it until now.

[Simon]

Umm, no. The first Intel Macs used Core Solo and Core Duo. Without a 64 bit CPU there's no 64 bit EFI.

[Simon]

Originally Posted by mduell 

It's about the inability to boot a 64-bit kernel with a 64-bit CPU.

You really have no idea what you're talking about. SL's 64 bit kernel is about developer support. Those developers that need it (i.e. those that develop drivers for x64) already have the right hardware.

Again, the approach Apple has chosen for 64 bit OS support is by far the smartest in the entire industry. Windows and Linux folks would love having it the way SL does it.

[slugslugslug]

You're right about what chabig said, Simon. But mduell's point still stands. There are a lot of Core 2 Duo Macs out there, including many of the 13" MacBooks and MacBooks Pro, that aren't listed by Apple as capable of booting the 64-bit kernel, even though they've 64-bit CPUs. Like Mark says, it makes sense that they boot 32-bit by default, but why disable K64 on them if people want to use them?

[Edit: I just noticed Eug's post saying his 13" MBP does boot K64. But the question remains, why doesn't Apple say it's "supported"? Oversight, or intentionally narrowing their support for something which should work?]

[Simon]

It's not disabled.

Apple simply hasn't written support for that hardware. Since they never advertised 64 bit EFI on those platforms they're not obliged to put any effort into it. The people who need the 64 bit kernel are those that develop drivers for 64 bit EFI on x64. And those people are getting 64 bit support. You didn't buy a Merom MB to do x64/EFI 64 kext development that's for sure.

[mduell]

Why are you unable to read the simple text of my comments? My comments have nothing to do with the default kernel or Core Duo/Solo machines.

Originally Posted by Simon 

You really have no idea what you're talking about. SL's 64 bit kernel is about developer support. Those developers that need it (i.e. those that develop drivers for x64) already have the right hardware.

Again, the approach Apple has chosen for 64 bit OS support is by far the smartest in the entire industry. Windows and Linux folks would love having it the way SL does it.

So the developer who bought the Mac Pro in 2007 must not want to develop drivers for x64? They can't boot Snow Leopard K64.

Originally Posted by Simon 

Apple simply hasn't written support for that hardware. Since they never advertised 64 bit EFI on those platforms they're not obliged to put any effort into it. The people who need the 64 bit kernel are those that develop drivers for 64 bit EFI on x64. And those people are getting 64 bit support. You didn't buy a Merom MB to do x64/EFI 64 kext development that's for sure.

Apple advertised the 2006 Mac Pro being 64-bit in several places (not just a side note on the tech specs page or similar); archive.org has the pages. Who would expect they can't boot a 64-bit kernel for 64-bit driver development on their 64-bit processor?

[Chuckit]

That page says the processor is 64-bit. That was and is entirely accurate. They did not say the firmware was 64-bit, which is the issue here.

[Eug]

Originally Posted by todd 

I see in the 'everything apple' blog linked from your post the 64 bit Safari numbers.. Does anyone have an explanation for why this would be? I am also running the 64 bit kernel, but I didn't do any A-B testing between the kernels, and I really didn't expect much of a performance difference.

Is the speedup something specific to the Safari 64 bit version, or just a symptom of efficiency of running the 64 bit kernel, or efficiency of a 64 bit app on a 64 bit kernel?

To clarify, Safari 64 is the same speed on the 32-bit and 64-bit OS X kernels, at least according to my benchmarks. That's in the blog (linked in my sig), but there is also a MacNN thread on it here.

For this particular bench, what's faster is Safari 64 over Safari 32, not OS X 64 over OS X 32.



P.S. Here are Apple's benches:

[Chuckit]

Does it actually mean that Javascript runs at almost three times the speed under 64-bit? I think that graph is mislabeled.

[Eug]

Originally Posted by Chuckit 

Does it actually mean that Javascript runs at almost three times the speed under 64-bit? I think that graph is mislabeled.

If you mean Apple's graph, you are correct. It should be "Times as fast as 32-bit".

Apple has Safari 64 JavaScript at 50% faster (not 150% faster). I had it at 37% faster (which is still pretty damn impressive, mind you). I wonder what the speedup comes from.

[Simon]

Originally Posted by mduell 

Why are you unable to read the simple text of my comments? My comments have nothing to do with the default kernel or Core Duo/Solo machines.

Who said they did? You're not the only one participating in this thread so obviously you're not the only one I'm replying to.

And for the record, you didn't "make a comment". You dropped some flame bait in the thread. You got called for it. Now your trying to rationalize and find a way out. IMHO that's what this is all about.

So the developer who bought the Mac Pro in 2007 must not want to develop drivers for x64?

Why should he? He didn't want to develop x64/EFI64 drivers when he bought his Mac that's for sure. If he wants to now he's essentially asking for Apple to invest time and money into driver support for functionality that was never promised in the first place.

Sure, it's ok to hope for something like that, but it's a gamble. And as every gambler should know, sometimes you lose. The problem is the whining about how you lost a bet and acting as if you were entitled to what you gambled on.

This is an entirely artificial problem. I'm willing to bet that 99% of the people I see bitching about this on the net have yet to write five lines of C code in their life. Ask yourself. Do you own a Mac Pro? Do you have a kext development project going on? Has Apple promised you something they didn't deliver? Probably the answer to all of the above is no. But still you're crying bloody murder. IMHO that's trolling. And I'm an idiot for even arguing about it.

[Spheric Harlot]

I disagree.

Both with the assessment that it's trolling, and with the assessment that you're an idiot for arguing.

The 64-bit machines *were* sold partly on the premise that they were "future-proof", with the inference that they were fully 64-bit compatible.

They aren't, and the fact that this wasn't mentioned at least in a footnote is somewhat misleading marketing in retrospect, seeing as Apple chose to actively highlight the 64-bit-ness.

This *is* a problem for people who budgeted a fully-decked machine over a number of years in the assumption that they would be able to work at a state-of-the-art level over that time.

Developers who need to write 64-bit drivers ASAP are one category where this might actually be a crucial distinction.

Media pros who bought into the hype are a vastly larger group, though, and while they might not see such a drastic benefit it running a 64-bit kernel as the driver developers (who are simply flat-out unable to work), I do think that they have all the justification to feel a little stiffed on the issue.

If Apple expects me to invest a stately number of thousands of dollars into my professional future with them, it's not exactly unprofessional to expect them to fulfill the expectations raised by their own marketing at the time.

OTOH, I have yet to see anybody anywhere, including in this thread, "crying bloody murder" over the issue. Yet.

[Simon]

Those 64 bit Macs were future proof. They run today's 64 bit apps just fine.

It's crucial to understand that you don't need EFI64 to run 64 bit apps the way Apple has implemented things. Media apps may benefit from being 64 bit, but they don't need a 64 bit SL kernel to run. IOW media pros couldn't care less about the 64 bit kernel. They need 64 bit apps which is an entirely different story.

The only people who really need EFI64 are those writing drivers for it. And those people are aware of all this.

Apple never promised EFI64 on old Macs. I understand some people might have assumed 64 bit CPUs automatically meant getting EFI64. But that was their guess and never Apple's promise. As we know now that assumption was wrong. There's really nothing more to it.

[Spheric Harlot]

Originally Posted by Simon 

Those 64 bit Macs were future proof. They run today's 64 bit apps just fine.

It's crucial to understand that you don't need EFI64 to run 64 bit apps the way Apple has implemented things. Media apps may benefit from being 64 bit, but they don't need a 64 bit SL kernel to run. IOW media pros couldn't care less about the 64 bit kernel. They need 64 bit apps which is an entirely different story.

I'm aware of the difference between 64-bit apps and a 64-bit kernel.

However:

The other thing K64 has going for it is speed. The x86 instruction set architecture has had a bit of a tortured history. When designing the x86-64 64-bit extension of the x86 architecture, AMD took the opportunity to leave behind some of the ugliness of the past and include more modern features: more registers, new addressing modes, non-stack-based floating point capabilities, etc. K64 reaps these benefits. Apple makes the following claims about its performance:

250% faster system call entry point
70% faster user/kernel memory copy
Focused benchmarking would bear these out, I'm sure. But in daily use, you're unlikely to be able to attribute any particular performance boost to the kernel. Think of K64 as removing bottlenecks from the few (usually server-based) applications that actually do exercise these aspects of the kernel heavily.

I have no idea whether a faster "system call entry point" and faster "user/kernel memory copy", whatever they are, are conceivably exploitable by current or future versions of various media applications, or indeed any outside of server operation.

ARE there benefits - however slight - to using a 64-bit kernel to media professionals, or are there not?

I don't know enough about kernel design to judge.

If there are, even slightly, then owners of non-64-bit-booting machines have every right to complain.

The only people who really need EFI64 are those writing drivers for it. And those people are aware of all this.

If it's really only the developers who need be interested, then it probably could be argued that they knew - or should have known - exactly what they're buying.

Apple never promised EFI64 on old Macs. I understand some people might have assumed 64 bit CPUs automatically meant getting EFI64. But that was their guess and never Apple's promise. As we know now that assumption was wrong. There's really nothing more to it.

Yes, it's entirely the customers' fault for falling for an impression that Apple's marketing obviously had absolutely no intention of dispelling.

In fact, even now, Apple's Snow Leopard tech specs page states merely that "64-bit support requires a Mac with a 64-bit processor."

With all respect: you're taking it a little far IMHO.


On a note that may make all this moot:
Latest Snow Leopard build limits most Macs to 32-bit mode - Ars Technica

It's apparently quite possible that Apple will enable 64-bit booting even on the 32-bit-EFI machines in a later point-update.

[Simon]

Originally Posted by Spheric Harlot 

In fact, even now, Apple's Snow Leopard tech specs page states merely that "64-bit support requires a Mac with a 64-bit processor."

I think that makes sense. Apple as usual is describing things with the large majority of users in mind. Those people think of 64 bit support as meaning "able to run 64 bit apps" which is exactly what Apple is enabling with SL.

I agree with Apple's strategy. The very few experts that actually develop drivers for EFI64 an be expected to know the all the technical details. And for everybody else Apple offers the information relevant to them.

[TETENAL]

Originally Posted by Simon 

Those people think of 64 bit support as meaning "able to run 64 bit apps" which is exactly what Apple is enabling with SL.

That was already "enabled" with 10.5 Leopard.

[Spheric Harlot]

indeed.

leopard vs. Snow leopard

Mac OS X 10.6 Snow Leopard: the Ars Technica review - Ars Technica

What's this "64-bit System" block in the upper left, though?

[CharlesS]

^ I'd interpret that to represent the fact that all the binaries and libraries included with Snow Leopard that aren't there solely for backward compatibility are 64-bit.

[FireWire]

Is there any test we can run to see if we have 32-bits kexts or other code that would prevent us from booting in 64-bits mode?

[Spheric Harlot]

Originally Posted by FireWire 

Is there any test we can run to see if we have 32-bits kexts or other code that would prevent us from booting in 64-bits mode?

Apple menu --> About this Mac… --> More Info… --> Extensions, Frameworks, etc.

One of the columns is "64-Bit (Intel)", and they're all either "Yes" or "No"…

[FireWire]

Originally Posted by Spheric Harlot 

Apple menu --> About this Mac… --> More Info… --> Extensions, Frameworks, etc.

One of the columns is "64-Bit (Intel)", and they're all either "Yes" or "No"…

Excellent! Thank you!

[mduell]

Originally Posted by Simon 

And for the record, you didn't "make a comment". You dropped some flame bait in the thread. You got called for it. Now your trying to rationalize and find a way out. IMHO that's what this is all about.

Why should he? He didn't want to develop x64/EFI64 drivers when he bought his Mac that's for sure. If he wants to now he's essentially asking for Apple to invest time and money into driver support for functionality that was never promised in the first place.

Sure, it's ok to hope for something like that, but it's a gamble. And as every gambler should know, sometimes you lose. The problem is the whining about how you lost a bet and acting as if you were entitled to what you gambled on.

This is an entirely artificial problem. I'm willing to bet that 99% of the people I see bitching about this on the net have yet to write five lines of C code in their life. Ask yourself. Do you own a Mac Pro? Do you have a kext development project going on? Has Apple promised you something they didn't deliver? Probably the answer to all of the above is no. But still you're crying bloody murder. IMHO that's trolling. And I'm an idiot for even arguing about it.

"Dropped some flame bait"? "Crying blood murder"? Get a grip on reality. Here's my original post:

Originally Posted by mduell 

Got to love a company that shipped a bunch of computers with 64-bit capable CPUs, but won't support them booting a 64-bit kernel.

Which stands. A bunch of people bought Macs advertised with 64-bit processors, and can't run various 64-bit parts (kernel, drivers, extensions, etc) of OS X. There's not "rationalization" or "finding a way out."

[besson3c]

Well, since 64 bit performance gains go well beyond memory addressing, I would bet that one of the biggest losers in this transition is virtualization. I don't know what Parallels uses, but both VMWare and Qemu/KVM/Virtualbox rely on kernel extensions heavily. It will be interesting to see when these might be available to compile/install in 64 bit, and what the performance gains might be.

[Simon]

Originally Posted by mduell 

Which stands. A bunch of people bought Macs advertised with 64-bit processors, and can't run various 64-bit parts (kernel, drivers, extensions, etc) of OS X.

You're just rewording. You try to make it sound like users everywhere are missing out on lots of stuff they were somehow entitled to. But that's just bull. There's one single thing those Macs can't do and that's load a 64 bit kernel. But thanks to the way OS X handles things, there's only one small group of people who actually need that: people who develop kexts/drivers for EFI64. But here's the thing. None of those people ever bought such a Mac for that use - for the very simple reason that at that time there was no such thing as EFI64 in Apple world and Apple never promised there would be either. Apple promised 64 bit support for 64 bit apps. And that's what everybody got.

The accusation is simply baloney. And there's no reason to be surprised that slamming Apple without justification on a Mac-centric board is not going to be met with delight. It's not the first time you try this either which is why I was led to believe it's intentional. If not, at least now you should realize that this kind of uninformed "comment" leads to a lot of quarreling, but not to any technical insight or better understanding.

[CharlesS]

Originally Posted by Simon 

YThere's one single thing those Macs can't do and that's load a 64 bit kernel. But thanks to the way OS X handles things, there's only one small group of people who actually need that: people who develop kexts/drivers for EFI64. But here's the thing. None of those people ever bought such a Mac for that use

No one ever bought a Mac Pro for development?!

[Simon]

That's not what I said. What I actually said was that no one bought a 2006 MP for EFI64 development because EFI64 simply didn't exist in Apple world at that time. Apple never promised it either.

[CharlesS]

But people did buy Mac Pros for developing kexts and drivers, and with a 64-bit kernel looming on the horizon (it's available now, so it's probably going to be the default next release), their job just became 64-bit kext and driver development, since their kexts and drivers aren't going to be worth a damn if they're not working with the 64-bit kernel by the time the userbase gets shoved onto it. It's not like 64-bit kext development is some completely discrete line of work.

[Simon]

Yeah, we were talking about that further above. If those people bought a 2006 MP with the intention of developing future kernel extensions even though Apple never talked about (let alone promised) EFI64 back then, that was a really a gamble. And right now it looks like they might lose that bet. In principle, Apple could develop and release new firmware for those 2006 MPs, but personally I wouldn't count on it.

I'm curious, are you one of those people?

[CharlesS]

Originally Posted by Simon 

Yeah, we were talking about that further above. If those people bought a 2006 MP with the intention of developing future kernel extensions even though Apple never talked about (let alone promised) EFI64 back then, that was a really a gamble. And right now it looks like they might lose that bet. In principle, Apple could develop and release new firmware for those 2006 MPs, but personally I wouldn't count on it.

They advertised it as 64-bit. I don't think it's unreasonable to have expected it to run a 64-bit kernel, which any developer with half a brain could have seen was coming (heck, Windows has been 64-bit since 2003). I wouldn't be surprised if quite a few Mac Pros were in fact bought with the express purpose of being ready to develop 64-bit drivers when it became necessary.

I'm curious, are you one of those people?

Nope, and actually for the most part I agree with you that the whole 64-bit thing is overblown. It's just that the way in which you've been presenting your arguments has been really irritating as of late. As an example, look at the attempt to make this personal in the quote directly above. What's up with that? Can we stop that, please, and keep the discussions in here professional?

[Simon]

I think you're taking that question the wrong way. There's nothing personal about it. I was curious if you were in that position because I was wondering what alternatives you would now be pursuing. It's wasn't about you personally. I'm curious to hear somebody's opinion who is actually in that position and since I know you're a developer...

[CharlesS]

I have a MacBook Pro that's perfectly capable of booting the 64-bit kernel, so if I were doing driver development, which I'm not, I'd just use my MBP. As it is, I have no reason to be booting the 64-bit kernel. However, I can understand why someone who had bought a Mac Pro for driver development work would be upset. The original quad core Mac Pros were sold until January 2008. That's not really that long ago.

With that said, the thing about firmware is that it can be updated. Apple could be preparing an EFI64 firmware update for the Mac Pro for all we know - it's probably a bit premature to get angry about it at this point.

With that said, I don't really have a vested interest in this discussion. I just think you need to cool down a bit. All the "you don't know what you're talking about", accusations of "crying bloody murder", and "trolling" all in reply to a single two-line sardonic comment, etc. really aren't doing this thread any favors, and it's making other comments get read in a different light - for example, my first reaction to your question above was that you were about to accuse me of whining, panicking, trolling, or whatever. It just seems like you've been hoping for a major panic ever since the second post in this thread, but other than a bunch of sarcastic jokes on the first page, everyone's been pretty calm so far.

[msuper69]

Question:

How do you tell if the kernel is in 64-bit mode?

I have a late 2008 MBA that is capable of running the 64-bit kernel. The reason I want to try to run 64-bit kernel is to see if there is any difference in CPU usage. In 32-bit mode, kernel_task is often using over 100%, even with nothing running other than normal startup processes.

Activity Monitor shows "Kind" as Intel rather than Intel (64 bit) so that's why I don't think it is in 64-bit mode.

[Simon]

Sys Profiler will tell you.

[msuper69]

Originally Posted by Simon 

Sys Profiler will tell you.

Thanks!
Now all I gotta do is figure out why holding 6 and 4 at boot time doesn't work.

UPDATE:

System Profiler says that I have some 32-bit Kexts loading. They appear to be Apple extensions:

AppleIntelYonahProfile:

Version: 1.0.0
Last Modified: 8/1/09 1:56 AM
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/AppleProfileFamily.kext/Contents/PlugIns/AppleIntelYonahProfile.kext
Kext Version: 14
Load Address: 0x1195000
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

BSDKernel6.0:

Version: 7.9.9
Last Modified: 8/1/09 1:50 AM
Get Info String: BSD Kernel Pseudoextension, Apple Computer Inc, 7.9.9
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/System.kext/PlugIns/BSDKernel6.0.kext
Kext Version: 7.9.9
Load Address: (built-in to the kernel)
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

CHUDKernLib:

Version: 4.7.1
Last Modified: 8/1/09 1:52 AM
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/CHUDKernLib.kext
Kext Version: 203
Load Address: 0x12d4000
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

CHUDProf:

Version: 4.7.1
Last Modified: 8/1/09 1:54 AM
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/CHUDProf.kext
Kext Version: 212
Load Address: 0x12d9000
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

CHUDUtils:

Version: 4.6.0
Last Modified: 8/1/09 1:54 AM
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/CHUDUtils.kext
Kext Version: 201
Load Address: 0x12e5000
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

IOKit6.0:

Version: 7.9.9
Last Modified: 8/1/09 1:50 AM
Get Info String: I/O Kit Pseudoextension, Apple Computer Inc, 7.9.9
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/System.kext/PlugIns/IOKit6.0.kext
Kext Version: 7.9.9
Load Address: (built-in to the kernel)
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

InternalModemSupport:

Version: 2.6.1
Last Modified: 8/1/09 2:03 AM
Get Info String: Version 2.6.0, Copyright Apple 2009
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/IOSerialFamily.kext/Contents/PlugIns/InternalModemSupport.kext
Kext Version: 2.6.0
Load Address: 0x12ba000
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

Libkern6.0:

Version: 7.9.9
Last Modified: 8/1/09 1:50 AM
Get Info String: Libkern Pseudoextension, Apple Computer Inc, 7.9.9
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/System.kext/PlugIns/Libkern6.0.kext
Kext Version: 7.9.9
Load Address: (built-in to the kernel)
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

Mach6.0:

Version: 7.9.9
Last Modified: 8/1/09 1:50 AM
Get Info String: Mach Kernel Pseudoextension, Apple Computer Inc, 7.9.9
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/System.kext/PlugIns/Mach6.0.kext
Kext Version: 7.9.9
Load Address: (built-in to the kernel)
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

System6.0:

Version: 7.9.9
Last Modified: 8/1/09 1:50 AM
Get Info String: System Resource Pseudoextension, Apple Inc, 7.9.9
Kind: Intel
Architectures: i386
64-Bit (Intel): No
Location: /System/Library/Extensions/System.kext/PlugIns/System6.0.kext
Kext Version: 7.9.9
Load Address: (built-in to the kernel)
Valid: Yes
Authentic: Yes
Dependencies: Satisfied

Some of these are from the kernel itself I'm guessing.

[besson3c]

Why is this being framed as only being about driver development? Both Windows and Linux offer default 64 bit kernels on their 64 bit supported OSes, so why shouldn't this be a bit of a blow that it will be a while before we can run 64 bit VMWare and the like? It looks like some conventional thinking about 64 bits != faster has to be thrown out the window to some extent due to some other optimizations that are only available under 64 bits, so how do we know that there would not be other minor performance increases under a 64 bit kernel?

Why didn't Apple release to developers sooner a 64 bit kernel they can test with? Even if it required and ADC account and maybe a bit of legwork to boot from, this would have given developers a bit of a jump on this. Did Apple make its 64 bit kernel availability intentions known to its developers?

[Simon]

Isn't the main difference that in the Linux and Windows worlds 64 bit applications and 64 bit kernels are tried to each other whereas in Apple world you can have the 64 bit apps without the 64 bit kernel?

[besson3c]

I can't speak for Windows, but you can run 32 bit stuff on a 64 bit version of Linux and the BSDs if you have the necessary 32 bit libs. In fact, there are still many things that are in 32 bit only, perhaps even the majority of stuff in certain areas.

Here is my theory as to how this played out for Apple...

Apple has historically never been terribly good at the low level stuff, I've never gotten the sense that Apple has put too much effort into things like their kernel or file system. The way they seem to solve many problems involves higher level shims. While they've modified HFS+ a little over the years, they've also seemingly never devoted resources to replacing it with a homegrown solution. Instead, they've flirted with ZFS and possibly UFS.

In their defense, kernel programming is very hard and presumably time consuming work. It requires a lot of testing, there is great risk with making sweeping modifications. I suspect that the 64 bit kernel simply wasn't ready in time to get developers testing it sooner under Leopard so that this transition could have been started sooner.

I also suspect that Darwin has forked away from anything they could steal from the FreeBSD amd64 kernel to expedite this process too. I could be wrong on this, but I don't know that Apple takes from FreeBSD much anymore. There are all sorts of things they could have taken: the new ULE scheduler (maybe not necssary with Grand Central Dispatch or whatever it is called), soft updates, jails, ZFS userland stuff (ZFS will be bootable in FBSD 8 I believe). Some of the reverse is happening too, the Clang/LVM compiler that Siracusa talks about in his article will be included as an experimental feature in FBSD 8, DTrace I believe is already available in OS X but will make it into 8. I'm kind of talking out of my ass here, I don't know how FreeBSD impacts Apple these days, and vice versa. At any rate, I bring this up because maybe things are changing in-house within Apple as far as kernel and other low level development goes?

[Chuckit]

Originally Posted by besson3c 

Why is this being framed as only being about driver development? Both Windows and Linux offer default 64 bit kernels on their 64 bit supported OSes, so why shouldn't this be a bit of a blow that it will be a while before we can run 64 bit VMWare and the like?

I suppose that depends on how VMWare implements its 64-bit support.

Originally Posted by besson3c 

It looks like some conventional thinking about 64 bits != faster has to be thrown out the window to some extent due to some other optimizations that are only available under 64 bits, so how do we know that there would not be other minor performance increases under a 64 bit kernel?

So your question is basically, "Why are you discussing the current main use for a 64-bit kernel? There are much less important things we could be discussing!"

[mduell]

Originally Posted by msuper69 

I have a late 2008 MBA that is capable of running the 64-bit kernel. The reason I want to try to run 64-bit kernel is to see if there is any difference in CPU usage. In 32-bit mode, kernel_task is often using over 100%, even with nothing running other than normal startup processes.

I don't think that's going to solve your problem.

[Simon]

Originally Posted by Chuckit 

I suppose that depends on how VMWare implements its 64-bit support.

I'm wondering the exact same thing. Does the Mac need a 64 bit kernel for VMWare on said Mac to run a 64 bit OS that would otherwise run natively on a 64 bit kernel?