Does Memory Management Suck or What?

Hehehe. You're a programmer jzdziarski?

I'm not sure what's prompting you to act like an asshole in a public forum, but if you can't be constructive, I suggest you find another forum to post in.

Make a call to malloc() for whatever size buffer you want and tell me if it's zero'ed out. It is not.

I never said it was (or should be), although the OS had better be zeroing secure pages in memory so that you can't just allocate a huge block and get access to passwords people have typed in (and such). Especially on a multi-user system. The space still has to be deallocated, returned to the pool, and then allocated to the application requesting the memory. This takes what is commonly referred to as 'overhead'. To leave the pages sitting in memory allocated is poor design, I don't care what pretty algorithms you have managing it. They should be put back on the free list and show up as free memory.

I think that's where the real slow down is: when the kernel has to manage memory and make distinctions between what is/isn't available to give to apps.

ding ding ding
 
Actually leaving lots of programs open all day will cause potential decrease in performance because THEN they will have to be paged out if you load some memory intensive program.

Inactive memory isn't paged out if the program is closed or quit when you launch some memory intensive program. The OS will release memory when it's needed and page out only programs that are actually open.


At least then, the user has some options to freeing memory - namely, closing applications. Once an application is closed, its memory should be freed up. It's a pretty simple concept, and that's one of the reasons many other *nix platforms outperform sluggish OSX. If you want to keep them in memory, but "inactive", then for goodness sake make it a configurable option.
 
I'm still wondering why you think the inactive list is a bad thing. Apps get memory off the list as they need it. It's not expensive to pull it off the list.


One pull may not be too expensive, but most applications don't allocate everything they need on startup. If you're thinking in terms of a game, you've got possibly hundreds or thousands of pulls. You've got to have super fast memory management to keep up the frame rate, and when a new player enters or a new object is created, it allocated several *small* blocks of memory for that. You don't want to have the additional overhead of grabbing memory from the inactive list when you're in the middle of what the application would consider a mission critical task.
 
jzdziarski said:
I'm not sure what's prompting you to act like an asshole in a public forum
Click to expand...
You're one to speak. I wasn't attacking your ego, nor did I do any name-calling so put that knife down.

jzdziarski said:
but if you can't be constructive, I suggest you find another forum to post in.
Click to expand...
You're complaining about something that no one here can change, how constructive do you think this conversation can be? Unless someone feels adventurous and wants to hack and recompile Mach...
 
So why are you responding to this thread if it's futile?

Apple works for us. If enough people agree this memory management approach sucks, there's a chance they'll change it.
 
jzdziarski said:
One pull may not be too expensive, but most applications don't allocate everything they need on startup. If you're thinking in terms of a game, you've got possibly hundreds or thousands of pulls. You've got to have super fast memory management to keep up the frame rate, and when a new player enters or a new object is created, it allocated several *small* blocks of memory for that. You don't want to have the additional overhead of grabbing memory from the inactive list when you're in the middle of what the application would consider a mission critical task.
Click to expand...
When an application starts up the kernel creates a heap for it, and when said app is requesting blocks of memory it's getting it from that heap. Granted the heap can grow and then that would be hitting this potential performance block you're describing. But a good developer should know ahead of time how much memory he needs and set the heap size ahead of time. Especially with a game where most of the assets are static it's easier to guess the necessary memory requirements. The kernel's memory management is just general purpose, there's lots we can do to manage memory ourselves for optimal performance.

I'm glad you used the term "mission critical task." If it really were mission critical, then you as the software developer would do everything in your power to make sure it runs optimal. Like I said, take memory management into your own hands, there are already exiting middleware memory management libraries specifically for game development that do that work for you.

EDIT:
jzdziarski said:
So why are you responding to this thread if it's futile?
Click to expand...
Actualyl I think it just got a little more interesting. I take it back, this problem is something we CAN fix afterall, just not directly into the system.
 
Well it wasn't a concern with panther, which is why I suspect nobody bothered with it. It seems rather asinine to make developers have to further optimize their applications to run on Tiger.
 
jzdziarski said:
Well it wasn't a concern with panther, which is why I suspect nobody bothered with it. It seems rather asinine to make developers have to further optimize their applications to run on Tiger.
Click to expand...

Which begs the question, why do you think it has anything to do with the way inactive memory is handled? There has been no significant change between the way inactive memory is handled.

Instead if I were to make a guess, I'd finger Dashboard and Spotlight as culprits. These are new additions to Tiger and there are known issues with Spotlight not being the most efficient beast in town. There was another thread somewhere in these forums that talk about how Spotlight was taking 100% CPU time.

Do dashboard widgets run in the background? This could be a problem too. When you first access Dashboard after a reboot, notice how it takes some time for the widgets to load and display meaningful data. I'm thinking that if the widgets are silently running in the background, this could explain why a reboot makes things go faster.

Allocating and deallocating memory isn't really a bottleneck. Go write some code to test it out. On my Powerbook, I can easily do over 580,000 allocations a second and fill over 1.1 GB/s. These are small operations but they do serve to illustrate the point. Memory management isn't really the issue. Releasing inactive memory isn't an expensive operation either, otherwise you'd have everyone complaining about it since OS 10.0. The fact that nobody has, and that memory management hasn't changed significantly is a good indication that you may be barking up the wrong tree.
 
Nah, real-time memory management still works the same. Outside the lifespan of an app, there's not much third party developers can do, so your contempt for Tiger is understandable. The least I was trying to do is convince you that the runtime performance would not be hindered by this new memory model.

Worst comes to worst, just throw lower latency RAM at it. :)
 
i have often thought, if spotlight needs to keeps itself updated on all the meta on every file as and when each file is added, isn't that a lot of system resourses taken up to make one search a day slightly faster? i've often thought it's kinda sledgehammer-to-nut...

and this thread has turned into a troll-match.

"I AM MORE GEEK THAN YOU HAHAHAHAHAH 7331!! LOLZ!!1"
 
Well, it was a geek thread to begin with. Though hopefully it will steer away from being a troll match.
 
The important thing to note which I said before and which has been said again is that this type of memory managment isn't new to Tiger. It was done in Panther and perhaps before that as well.
 
Dear Jonathan/ALL USERS,

I believe I have a solution to your Memory Management problem and for ALL MacOS X users.... and maybe a faster response for your computer.
I have been using CPU Speed Accelerator from AlphaOmega Software(check out their other software too!) for the past 2 yrs. It handles automatically any unused memory and puts it to the foreground(running software).

see here=> http://alphaomega.software.free.fr/
(Just click the Monitor)

It should increase speed of computer from 20% to 30%. Once in a while check it to see if its still running. It is put in Top Menu. I also put a copy in the Dock too!! You have to pay for it. Its not that expensive. Make sure you get 'English Version'.

Very Truly Yours,

§§ (SoulSaxy(Internet Guru))


***************************************************
jzdziarski said:
I'm somewhat unfamiliar with how OSX deals with memory. In most *nixes, when an application exits, the entire process image (including all allocated memory) are unlinked completely and returned back to the operating system. I've noticed OSX seems to act more like windows, however, and when you quit an application the pages never get removed - they're just part of the "inactive" memory pool.

I realized this after upgrading my powerbook to 2GB of RAM, thinking I was running low. I can reboot now and have almost 90% of the memory free, play a game of UT2004, and only a mere 30% or so will be free after that - the rest "inactive". I can think of a number of reasons having inactive pages just sitting in memory would be a bad thing, so why does OSX seem to do this? Or is this whole thing one huge bug that needs to get sorted out in Tiger?

Finally, are there any tools someone can recommend that will flush inactive memory?

Jonathan
Click to expand...
;) ;) ;) ::angel::
 
No, that isn't really a solution. It just re'nices' the process so that it has a higher priority. It gives the illusion of speed, but it's actually detrimental to background processes some of which could get starved of CPU time. Doesn't deal with the memory issue either.
 
jzdziarski said:
1. I'm somewhat unfamiliar with how OSX deals with memory. In most *nixes, when an application exits, the entire process image (including all allocated memory) are unlinked completely and returned back to the operating system. I've noticed OSX seems to act more like windows, however, and when you quit an application the pages never get removed - they're just part of the "inactive" memory pool.

2. I realized this after upgrading my powerbook to 2GB of RAM, thinking I was running low. I can reboot now and have almost 90% of the memory free, play a game of UT2004, and only a mere 30% or so will be free after that - the rest "inactive". I can think of a number of reasons having inactive pages just sitting in memory would be a bad thing, so why does OSX seem to do this? Or is this whole thing one huge bug that needs to get sorted out in Tiger?

3. Finally, are there any tools someone can recommend that will flush inactive memory?
Click to expand...
1. Having things in inactive memory is to your advantage. OS X is predicting that (i.e., allowing for the idea that) your next request for instructions is likely to come from certain recently accessed instructions. There is not necessarily a problem in having a low amount of free memory in OS X. OS X has stored many instructions in RAM (in its file system buffer cache) and in inactive memory. Doing both means better performance--less disk/VM usage--assuming that one has no evidence of a physical RAM shortage.

See post 6.

2. There are no reasons that having inactive memory are bad. Inactive is as good, and often better than, free from an operating perspective. Restarting to free memory is a mistake. Doing so will purge the file system buffer cache, as well as inactive memory and, thus, decrease performance.

3. You don't want to do that unless you want slower performance.

Well I say that Ghost and all those who agree with him on what's above are right. ~:)^) Here's more.

4. Given a properly functioning machine/system, one doesn't have any kind of RAM problem unless many, or excessively long spinning, SBBODs are observed or one is having excessive pageouts. There is no accepted rule of thumb for "excessive pageouts," but I use pageouts since startup / pageins since startup > .1 as an indicator that I should start wondering if there is a physical RAM shortage. But, anyway, here is a good memory read--from top to bottom. I am not positive that everything the later writer says is true, but the vast majority of it is consistent with my understanding.

__________________
Don't worry, be happy! ~(;^)

12" 1 GHz 1.25 GB iBook G4, Tiger 10.4.1, AX; 250 GB LaCie FireWire, iPod, pBook 540c, Some Linksys WRT54GS networked XPs
 
You must log in or register to reply here.
Back
Top