Final consensus on 64 bit kernel on Mac Pro 1,1 -- any way, or no way?
I just posted this same message on the Apple discussion groups. My apologies to anyone who is seeing this twice, but I'm trying to get an answer within a rather short period, and the AppleInsider forums seem to have a larger concentration of people who have knowledge in this area.
Let me start by explaining in general terms why I think I need to do this, to head off the usual responses of "you don't need to do this" or "it doesn't matter."
I am trying to run an program I have developed that is crunching a very large amount of data over a long period of time. I am running on an original Mac Pro with 15GB of memory and a 2TB hard disk.
The amount of memory required increases to about 63GB and at that point I am still getting pretty good performance (not much thrashing) but I can't go further because the OS starts complaining about running out of Application Memory. Quitting all applications helps for a few minutes but eventually the program stops running.
I am guessing that this is running into a virtual memory addressing limit, either per app or for applications over all. I've heard about a 96GB limit overall for the 32 bit kernel, and I am thinking there is a specific 64GB limit for apps from the evidence I am seeing.
My questions are:
1) Would running the 64 bit kernel allow me to go beyond the current limits on virtual memory? (Eventually performance would prohibit going further, but I would at least like to let VM grow up to the performance limits).
2) Is there ANY way, even a hack, to run the 64 bit kernel on Mac Pro 1,1?
I have googled the heck out of this question, but unfortunately, most of the hits are from the discussion when Snow Leopard was still in developer seed stage. The early ideas for doing it don't seem to have panned out.
My question is, is there any final consensus about whether this is possible? I realize that in 99.9% of the cases running the 64 bit kernel gets you little appreciable advantage, not enough to warrant going to the trouble. I am part of the 0.1% of the cases where there would be a real advantage.
My other alternative is to rewrite the program to do my own "memory management" which I will in fact embark on doing, but on top of everything else I am working under a time constraint, so if I could find a way to get around the VM limit right away so that I could start running the program again, that would be a big help to me.
Let me start by explaining in general terms why I think I need to do this, to head off the usual responses of "you don't need to do this" or "it doesn't matter."
I am trying to run an program I have developed that is crunching a very large amount of data over a long period of time. I am running on an original Mac Pro with 15GB of memory and a 2TB hard disk.
The amount of memory required increases to about 63GB and at that point I am still getting pretty good performance (not much thrashing) but I can't go further because the OS starts complaining about running out of Application Memory. Quitting all applications helps for a few minutes but eventually the program stops running.
I am guessing that this is running into a virtual memory addressing limit, either per app or for applications over all. I've heard about a 96GB limit overall for the 32 bit kernel, and I am thinking there is a specific 64GB limit for apps from the evidence I am seeing.
My questions are:
1) Would running the 64 bit kernel allow me to go beyond the current limits on virtual memory? (Eventually performance would prohibit going further, but I would at least like to let VM grow up to the performance limits).
2) Is there ANY way, even a hack, to run the 64 bit kernel on Mac Pro 1,1?
I have googled the heck out of this question, but unfortunately, most of the hits are from the discussion when Snow Leopard was still in developer seed stage. The early ideas for doing it don't seem to have panned out.
My question is, is there any final consensus about whether this is possible? I realize that in 99.9% of the cases running the 64 bit kernel gets you little appreciable advantage, not enough to warrant going to the trouble. I am part of the 0.1% of the cases where there would be a real advantage.
My other alternative is to rewrite the program to do my own "memory management" which I will in fact embark on doing, but on top of everything else I am working under a time constraint, so if I could find a way to get around the VM limit right away so that I could start running the program again, that would be a big help to me.