DoggieHowser Posted June 13, 2013 Posted June 13, 2013 http://appleinsider.com/articles/13/06/12/compressed-memory-in-os-x-109-mavericks-aims-to-free-ram-extend-battery-life While the argument about FLAC vs WAV rages on, this comes into the picture...
hochopeper Posted June 13, 2013 Posted June 13, 2013 (edited) See I didn't think of it like 'compression is bad' ... I thought the reduced disk activity might be a potential boon for us hifi mac users less activity on the hdd and SATA bus because less is going to swap space on the disk. Keeping other OS activity to being just CPU-RAM comms is certainly a good thing IMO. Another article on it and the OS tick coalescing technology here - http://arstechnica.com/apple/2013/06/how-os-x-mavericks-works-its-power-saving-magic/ - which will help keep the CPU in low power state more often too, another win Note that the background de-prioritisation stuff doesn't happen if the app is for audio, so at the very least apple are thinking of us there! Edited June 13, 2013 by hochopeper
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 http://appleinsider.com/articles/13/06/12/compressed-memory-in-os-x-109-mavericks-aims-to-free-ram-extend-battery-life While the argument about FLAC vs WAV rages on, this comes into the picture... It is a very good thing. It turns out that the operating system can compress memory on the fly even more efficiently, reducing the need for active paging under Virtual Memory. That lets the CPU and drive power down more often, saving battery consumption. <SNIP> Apple states that its compression techniques "reduces the size of items in memory that haven’t been used recently by more than 50 percent," and states that "Compressed Memory is incredibly fast, compressing or decompressing a page of memory in just a few millionths of a second." Compressed Memory can also take advantage of parallel execution on multiple cores "unlike traditional virtual memory," therefore "achieving lightning-fast performance for both reclaiming unused memory and accessing seldom-used objects in memory." By improving the way Virtual Memory works, it's less necessary for the system to "waste time continually transferring data back and forth between memory and storage." As a result, Apple says Memory Compression improves both general responsiveness under load and improves wake from standby times, as depicted above. 1
hochopeper Posted June 13, 2013 Posted June 13, 2013 It is a very good thing. At least I'm not the only nutjob thinking that!
gz76 Posted June 13, 2013 Posted June 13, 2013 I can't help but think the OP is confusing compressed memory with (lossy) compressed music? The post isn't really clear to me regarding the link between the article and his comment.
DoggieHowser Posted June 13, 2013 Author Posted June 13, 2013 I guess we would need to wait till the OS is released. I suspect there are CPU overheads with the compression/decompression. The document says it has a penalty of 34-24 clock cycles per word of compression. So how these spikes translate to discernible differences is anyone's guess IMHO.
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 I can't help but think the OP is confusing compressed memory with (lossy) compressed music? Nope. WIth losslessly compressed music.
hochopeper Posted June 13, 2013 Posted June 13, 2013 I guess we would need to wait till the OS is released. I suspect there are CPU overheads with the compression/decompression. The document says it has a penalty of 34-24 clock cycles per word of compression. So how these spikes translate to discernible differences is anyone's guess IMHO. Remember it is only applied to items that have been in memory for some time and not used recently.
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 I guess we would need to wait till the OS is released. I suspect there are CPU overheads with the compression/decompression. The document says it has a penalty of 34-24 clock cycles per word of compression. So how these spikes translate to discernible differences is anyone's guess IMHO. To consider if 34 clock cycles is good or not.... you need to consider how expensive the alternative (page to storage is). The reason they don't state that number for the alternative, is because you cannot generalise about how the storage will respond (sleepy hardisk, busy driver, interrupts required, etc. etc)..... I can make some strong assumptions. The compress it or page it, argument is a pretty well-kicked around ball. The CPU overhead (note this is NOT, "CPU time" or %, like you would see an task manager or activity monitor).... of compressing something in RAM, is an order (or many) of magnitude less expensive than paging something out of RAM (to storage)..... (number of memory/L2 cache copies required, and interrupts triggered, when interacting with things like storage drivers) The "electrical noise" from compressing something in RAM, vs paging to storage is a lot lower (amount of, and distance travelled by any electricity) My Mac doesn't actually use any (real) paging space under normal operation.
bwhitesox Posted June 13, 2013 Posted June 13, 2013 I guess we would need to wait till the OS is released. I suspect there are CPU overheads with the compression/decompression. The document says it has a penalty of 34-24 clock cycles per word of compression. So how these spikes translate to discernible differences is anyone's guess IMHO. Not with todays/tomorrows Intel I7 and Xeons
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 Not with todays/tomorrows Intel I7 and Xeons What I wrote above has been the case for decades...
hochopeper Posted June 13, 2013 Posted June 13, 2013 My Mac doesn't actually use any (real) paging space under normal operation. Exactly and I wouldn't expect the OS to be compressing anything at all until it is above a certain memory usage threshold.
hochopeper Posted June 13, 2013 Posted June 13, 2013 Kernel tick coalescing and better management of thread priorities is a good thing, lets talk about that?
fetischizm Posted June 13, 2013 Posted June 13, 2013 (edited) wait! you mean its going to affect my audio system as much as...... FLAC decoding?!! I aint 'fraid 'o 'no 'ghost its a good thing for god sake ... as mentioned its not going to try to compress something thats playing in realtime ... Edited June 13, 2013 by fetischizm
Guest myrantz Posted June 13, 2013 Posted June 13, 2013 Anybody remember ram doubler? Everything old is new again.... 1
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 Kernel tick coalescing Hmmm... This and tickless, could do peoples heads in, heh.
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 Tickless being new to Win8 (old elsewhere) .... is there any truth to the "rumour" that turning it off is a good move. I have it off in Win8.
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 Anybody remember ram doubler? Everything old is new again.... Yep. Same idea, better (less brute force) implementation.
bwhitesox Posted June 13, 2013 Posted June 13, 2013 (edited) What I wrote above has been the case for decades... Not for much longer with Intels 12 core cpu's coming to a pc near you soon Edited June 13, 2013 by bwhitesox
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 ... as mentioned its not going to try to compress something thats playing in realtime ... I think the fear was probably more to do with "computer doing more work" during playback (potentially compressing other things). Some players like to use a lot of memory.... this could cause the condition. The "more work" idea is intuitive ... but not what's happening under the surface.
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 Not for much longer with Intels 12 core cpu's coming to a pc near you soon I don't understand why
hochopeper Posted June 13, 2013 Posted June 13, 2013 Tickless being new to Win8 (old elsewhere) .... is there any truth to the "rumour" that turning it off is a good move. I have it off in Win8. I very nearly mentioned dynticks and the new to linux CONFIG_NO_HZ_FULL as examples of alternative approaches taken in linux - http://www.phoronix.com/scan.php?page=news_item&px=MTM2NTA Linus really doesn't like the no_hz_full patch but committed it to linux kernel anyway, he must be getting soft
fetischizm Posted June 13, 2013 Posted June 13, 2013 (edited) I think the fear was probably more to do with "computer doing more work" during playback (potentially compressing other things). Some players like to use a lot of memory.... this could cause the condition. The "more work" idea is intuitive ... but not what's happening under the surface. both are nonsense, even if they were true. if for instance higher CPU load causes some kind of transient on ground, that somehow makes it through to your DAC analogue stages, you have bigger fish to fry ... bitperfect data corruption is one of the more ridiculous notions in hifi today Edited June 13, 2013 by fetischizm 1
davewantsmoore Posted June 13, 2013 Posted June 13, 2013 he must be getting soft Definitely seems to be picking his battles these days.
Recommended Posts