The kernel is not Mach, and it doesn't even use the Mach microkernel model.
This isn't a semantic issue. If someone were to say the kernel is Mach, everyone would expect the kernel to be THE Mach microkernel.
There are many design philosophies.
The kernel is essentially the OS, the whole purpose of which is to allow multiple programs to run on one computer. One way to do this is to virtualize and multiplex everything so every program runs as if it were the only one running. Another way to do this is to provide limited access to hardware, merely controlling what programs have access and how. Various kernels take a different approach depending on what hardware is being accessed and what the purpose of the computer is. All the UNIX kernels use the former method of virtualizing everything while real-time OSs tend to do the latter.
NeXT--er, I mean Apple--decided to go UNIX, and they also decided to use Mach which is a slow, bloated research "microkernel" which was never designed for multimedia. It's like the worst of all worlds.
What Apple should do (since you asked) is replace the Mach underpinnings with a true microkernel (or better yet, exokernel), using some kind of ABI emulation to run legacy stuff.
It's very interesting that you keep saying that. So then, what is it. And as you keep saying yourself that Apple uses the Mach microkernel, what are they using it for? Or is it that I didn't refine my statement so as to say that it's a "micro" kernal?
BTW the reason Apple adopted Mach was because Avie Tevanian was one of the original Mach developers. He also was the one who decided to keep the Mach-O format and ABI.
FYI Mach was designed in the 1970s for running time-sharing programs on mainframes, not multimedia. It was only practical for this purpose and ran on things like multiprocessor VAX machines.
Its an ancient kernel which is no longer being developed by anyone outside Apple. The rest of the world has moved on. Interestingly I found a project porting HURD to the L4 microkernel (instead of Mach). L4 IPC calls take 1/20th as long to execute as Mach. Newer microkernels like L4 are delivering what projects like Mach only promised, but ultimately never delivered.
You may be wondering if Mach could ever be improved, but I doubt it. The problem is Mach tries to do too much. It has around 140 functions while L4 only has 7. The reason is L4 doesn't handle permissions, but that should be handled at higher levels anyway. Because BSD and Mach overlap these functions it makes it hard (nearing impossible) to make it perform well.
Well we aren't talking about HPC, instead we where talking about OS/X'es feel on intel hardware. Specifically that it feels much faster.
I still don't see any indication that the primary cause for this would be integer performance. If you have CHUD installed, do a time profile with Shark while doing stuff in Finder, look at the disassembly, and see for yourself how much of the hot code is actually made up of integer ops.
Quote:
I think you are gravely mistaken with respect to the above statements. Certainly system as a whole comes into play but that does not forgive the reality that the finder has an incredible amount of data to deal with and present to the user. In any event all one has to do is to slam a faster processor into a machine running linux say, to see how much an increase in processor performance helps the browser there.
When you say "present to the user," are you really talking about the Finder? Aren't you really talking about Quartz?
Quote:
The Mac is much the same you have a code base that can see considerable improvements with a speed up of the processor. Now that isn't to imply that system itself (hardware & software) can't be improved just that much of it is CPU bound at the moment.
If the Finder were really limited by raw integer performance, you should easily be able to get CPU utilization to 100% -- not sure if I use my system in a different way than you do, but I have a hard time doing that.
Quote:
Taken another way people that upgrade their machines processor to get better overall performance are all wet according to your reasoning. Clearly this isn't the case as the upgrade market for CPU's is still alive and well.
You do realize there are other types of instructions than Integer and FP Ops? In particular, there's Load/Store instructions and control instructions (branches etc.), both of which have far higher potential for hurting performance than the former (e.g. compare what a stall due to a d-cache miss costs you as opposed to waiting for an add instruction to finish).
(On a slightly different note, though: Yes, I do have slight difficulties comprehending how people are willing to pay close to the cost of a complete new system for CPU upgrades for stone-age Macs...)
Quote:
The fact that GCC might generate better code for x86 has nothing to do with the real issues here. Its the hardware!!!. More so the G4 is dependant to a greater extent on the compiler generating good code vs the latest i86 hardware. I86 just runs sloppy integer code better.
The G5 actually depends on good code generation as well, e.g. due to its instruction grouping and the restrictions placed on it.
Finder performance sucks due to design and thread locking, not integer performance.
Again, the KERNEL is at fault for a lot of this, not the Finder or the ISA. For example, where is kqueue/kevent? These functions allow programs to be notified when other things happen, like filesystem changes. The Finder currently has to poll the filesystem to know it has changed.
Also, due to the kernel design (which I'm not going to repeat here), the way Apple implement real-time threads is to pre-empt the kernel! Hopefully I don't have to explain how this can f-up the whole system, making everything perform like a meth junkie being tasered.
It's stupid crap like this which has everything to do with poor responsiveness, not the ISA.
Again, the KERNEL is at fault for a lot of this, not the Finder or the ISA. For example, where is kqueue/kevent? These functions allow programs to be notified when other things happen, like filesystem changes. The Finder currently has to poll the filesystem to know it has changed.
As far as I know, this is also no longer true as of Tiger -- at least one Framework (DesktopServicesPriv) the Finder links in uses kqueue/kevent.
Finder performance sucks due to design and thread locking, not integer performance.
Again, the KERNEL is at fault for a lot of this, not the Finder or the ISA. For example, where is kqueue/kevent? These functions allow programs to be notified when other things happen, like filesystem changes. The Finder currently has to poll the filesystem to know it has changed.
Also, due to the kernel design (which I'm not going to repeat here), the way Apple implement real-time threads is to pre-empt the kernel! Hopefully I don't have to explain how this can f-up the whole system, making everything perform like a meth junkie being tasered.
It's stupid crap like this which has everything to do with poor responsiveness, not the ISA.
at least it's still better than windoze \ i find that even in winxp2pro it really isn't smart at all on setting process priorities. everything is set to normal and then windoze is just way way stupid when it comes to multitasking.
however, i find that if i manually set say, azureus, quicktime encoding, x264encoding, to be low priority, with firefox below normal, and then a game just as default normal priority, winxp2pro actually starts to behave alright.
but again, having to manually set process priorities in this day and age is just silly. so at least our crappy Mach kernel does alright in a general multitasking sense. i really don't know how apple would rewrite the whole thing, the best they can do is continue to address critical issues such as the thread locking thing, etc, etc.
OK, I just did some real-world tests and conclude that this problem has been partially fixed.
If you create a file (using vi) in a directory listed in the Finder in Panther, Finder will fail to show the file until you do something like delete a file in that directory in the Finder. In other words it polls.
In Tiger, however, the Finder shows the file immediately after I send the ":w" command.
Unfortunately the Finder in Tiger still isn't notified of all changes. For example if I delete a large file in a folder which is NOT displayed, the free space info in the Finder window won't change until clicked.
Unfortunately the Finder in Tiger still isn't notified of all changes. For example if I delete a large file in a folder which is NOT displayed, the free space info in the Finder window won't change until clicked.
This is actually a longstanding bug that has nothing to do with polling. You can sometimes close and reopen the window a bunch of times and do a bunch of stuff for an entire day and the free space info won't change.
Unfortunately the Finder in Tiger still isn't notified of all changes. For example if I delete a large file in a folder which is NOT displayed, the free space info in the Finder window won't change until clicked.
Yeah, the "available space" info for Desktop-mounted drives also frequently doesn't update; very annoying.
Comments
Originally posted by strobe
The kernel is not Mach, and it doesn't even use the Mach microkernel model.
This isn't a semantic issue. If someone were to say the kernel is Mach, everyone would expect the kernel to be THE Mach microkernel.
There are many design philosophies.
The kernel is essentially the OS, the whole purpose of which is to allow multiple programs to run on one computer. One way to do this is to virtualize and multiplex everything so every program runs as if it were the only one running. Another way to do this is to provide limited access to hardware, merely controlling what programs have access and how. Various kernels take a different approach depending on what hardware is being accessed and what the purpose of the computer is. All the UNIX kernels use the former method of virtualizing everything while real-time OSs tend to do the latter.
NeXT--er, I mean Apple--decided to go UNIX, and they also decided to use Mach which is a slow, bloated research "microkernel" which was never designed for multimedia. It's like the worst of all worlds.
What Apple should do (since you asked) is replace the Mach underpinnings with a true microkernel (or better yet, exokernel), using some kind of ABI emulation to run legacy stuff.
It's very interesting that you keep saying that. So then, what is it. And as you keep saying yourself that Apple uses the Mach microkernel, what are they using it for? Or is it that I didn't refine my statement so as to say that it's a "micro" kernal?
FYI Mach was designed in the 1970s for running time-sharing programs on mainframes, not multimedia. It was only practical for this purpose and ran on things like multiprocessor VAX machines.
Its an ancient kernel which is no longer being developed by anyone outside Apple. The rest of the world has moved on. Interestingly I found a project porting HURD to the L4 microkernel (instead of Mach). L4 IPC calls take 1/20th as long to execute as Mach. Newer microkernels like L4 are delivering what projects like Mach only promised, but ultimately never delivered.
You may be wondering if Mach could ever be improved, but I doubt it. The problem is Mach tries to do too much. It has around 140 functions while L4 only has 7. The reason is L4 doesn't handle permissions, but that should be handled at higher levels anyway. Because BSD and Mach overlap these functions it makes it hard (nearing impossible) to make it perform well.
Originally posted by wizard69
Well we aren't talking about HPC, instead we where talking about OS/X'es feel on intel hardware. Specifically that it feels much faster.
I still don't see any indication that the primary cause for this would be integer performance. If you have CHUD installed, do a time profile with Shark while doing stuff in Finder, look at the disassembly, and see for yourself how much of the hot code is actually made up of integer ops.
I think you are gravely mistaken with respect to the above statements. Certainly system as a whole comes into play but that does not forgive the reality that the finder has an incredible amount of data to deal with and present to the user. In any event all one has to do is to slam a faster processor into a machine running linux say, to see how much an increase in processor performance helps the browser there.
When you say "present to the user," are you really talking about the Finder? Aren't you really talking about Quartz?
The Mac is much the same you have a code base that can see considerable improvements with a speed up of the processor. Now that isn't to imply that system itself (hardware & software) can't be improved just that much of it is CPU bound at the moment.
If the Finder were really limited by raw integer performance, you should easily be able to get CPU utilization to 100% -- not sure if I use my system in a different way than you do, but I have a hard time doing that.
Taken another way people that upgrade their machines processor to get better overall performance are all wet according to your reasoning. Clearly this isn't the case as the upgrade market for CPU's is still alive and well.
You do realize there are other types of instructions than Integer and FP Ops? In particular, there's Load/Store instructions and control instructions (branches etc.), both of which have far higher potential for hurting performance than the former (e.g. compare what a stall due to a d-cache miss costs you as opposed to waiting for an add instruction to finish).
(On a slightly different note, though: Yes, I do have slight difficulties comprehending how people are willing to pay close to the cost of a complete new system for CPU upgrades for stone-age Macs...)
The fact that GCC might generate better code for x86 has nothing to do with the real issues here. Its the hardware!!!. More so the G4 is dependant to a greater extent on the compiler generating good code vs the latest i86 hardware. I86 just runs sloppy integer code better.
The G5 actually depends on good code generation as well, e.g. due to its instruction grouping and the restrictions placed on it.
Again, the KERNEL is at fault for a lot of this, not the Finder or the ISA. For example, where is kqueue/kevent? These functions allow programs to be notified when other things happen, like filesystem changes. The Finder currently has to poll the filesystem to know it has changed.
Also, due to the kernel design (which I'm not going to repeat here), the way Apple implement real-time threads is to pre-empt the kernel! Hopefully I don't have to explain how this can f-up the whole system, making everything perform like a meth junkie being tasered.
It's stupid crap like this which has everything to do with poor responsiveness, not the ISA.
Originally posted by strobe
Again, the KERNEL is at fault for a lot of this, not the Finder or the ISA. For example, where is kqueue/kevent? These functions allow programs to be notified when other things happen, like filesystem changes. The Finder currently has to poll the filesystem to know it has changed.
As far as I know, this is also no longer true as of Tiger -- at least one Framework (DesktopServicesPriv) the Finder links in uses kqueue/kevent.
Originally posted by RazzFazz
As far as I know, this is also no longer true as of Tiger -- at least one Framework (DesktopServicesPriv) the Finder links in uses kqueue/kevent.
Good to know.
My comment regarding kernel pre-emption still stands.
I think Avie's big head got in the way of sound engineering decisions.
Originally posted by strobe
Finder performance sucks due to design and thread locking, not integer performance.
Again, the KERNEL is at fault for a lot of this, not the Finder or the ISA. For example, where is kqueue/kevent? These functions allow programs to be notified when other things happen, like filesystem changes. The Finder currently has to poll the filesystem to know it has changed.
Also, due to the kernel design (which I'm not going to repeat here), the way Apple implement real-time threads is to pre-empt the kernel! Hopefully I don't have to explain how this can f-up the whole system, making everything perform like a meth junkie being tasered.
It's stupid crap like this which has everything to do with poor responsiveness, not the ISA.
at least it's still better than windoze
however, i find that if i manually set say, azureus, quicktime encoding, x264encoding, to be low priority, with firefox below normal, and then a game just as default normal priority, winxp2pro actually starts to behave alright.
but again, having to manually set process priorities in this day and age is just silly. so at least our crappy Mach kernel does alright in a general multitasking sense. i really don't know how apple would rewrite the whole thing, the best they can do is continue to address critical issues such as the thread locking thing, etc, etc.
Originally posted by RazzFazz
As far as I know, this is also no longer true as of Tiger -- at least one Framework (DesktopServicesPriv) the Finder links in uses kqueue/kevent.
whether the Finder is notified or it has to poll for changes in Tiger, it certainly seems much more sensible and responsive in 10.4.3
If you create a file (using vi) in a directory listed in the Finder in Panther, Finder will fail to show the file until you do something like delete a file in that directory in the Finder. In other words it polls.
In Tiger, however, the Finder shows the file immediately after I send the ":w" command.
Unfortunately the Finder in Tiger still isn't notified of all changes. For example if I delete a large file in a folder which is NOT displayed, the free space info in the Finder window won't change until clicked.
So I guess some things have improved, others not.
Originally posted by strobe
Unfortunately the Finder in Tiger still isn't notified of all changes. For example if I delete a large file in a folder which is NOT displayed, the free space info in the Finder window won't change until clicked.
This is actually a longstanding bug that has nothing to do with polling. You can sometimes close and reopen the window a bunch of times and do a bunch of stuff for an entire day and the free space info won't change.
Originally posted by strobe
Unfortunately the Finder in Tiger still isn't notified of all changes. For example if I delete a large file in a folder which is NOT displayed, the free space info in the Finder window won't change until clicked.
Yeah, the "available space" info for Desktop-mounted drives also frequently doesn't update; very annoying.