16GB vs. 32GB -- Maximize a Mac's performance by choosing the right amount of memory
When purchasing a new Mac, customers are presented with many memory options to cater to a diverse range of needs. Here are the pros and cons of 8GB, 16GB, 32GB, and more.
The amount of Mac memory is crucial for certain tasks
The Apple Silicon series of chips for Mac, encompassing the M1 and M2 lineups, support a unified memory range from 8GB up to 96GB, varying with the product generation. As a result, Mac buyers can find themselves figuring out the best memory option to select.
While most computer firms use distinct silicon for CPUs and RAM, Apple employs a "system-on-a-chip" design, integrating various components into one unified chip.
16GB vs. 32GB RAM -- Unified memory versus discrete memory
Traditionally, Intel chips operate with separate RAM modules, a stark contrast to Apple Silicon chips, where RAM is seamlessly integrated into the chip. It facilitates quicker memory access and enhances performance across numerous tasks.
The central and graphics processors maintain individual memory reserves in discrete memory systems, operating independently. However, Apple's unified memory strategy allows different chip segments to share a common memory pool, eliminating data duplication and fostering both speed and efficiency.
Choosing the amount of memory is still a separate menu in the Mac purchasing process, and upgrading from the baseline configuration is costly.
For instance, the 2023 14-inch MacBook Pro comes with a baseline of 16GB of memory. An upgrade to 32GB of memory costs $400, and various choices are available up to the top tier of 96GB of memory, equipped with an M2 Max chip, for an added fee of $1,200.
Alternatively, choosing a MacBook Air begins with a default of 8GB of memory, which can be increased to a maximum of 24GB for an additional $400.
16GB vs. 32GB RAM -- Different types of memory
Macs can also leverage the high-speed SSD to virtually expand the RAM, a process known as memory swapping, which, while slower than accessing physical RAM, still offers impressive speeds due to the fast SSD in the MacBook Pro.
The speed of physical RAM is high, as it communicates directly with the central processing unit (CPU), ensuring a swift response and operation time. On the other hand, virtual RAM is a simulated memory space that the operating system creates on a computer's hard drive or SSD.
That virtual environment comes into play when the physical RAM is nearing its total capacity, acting as an extended memory space to store data that is not being used temporarily. However, because the speed of virtual memory is slower than the physical silicon, more is needed to guarantee that Mac users will have all the fast memory they need for their uses.
16GB vs. 32GB RAM -- Memory for different uses
Choosing the right amount of memory depends on individual computing demands and budgets. For example, an 8GB memory is good for fundamental operations like web browsing and light photo editing.
For those delving into heavier photo editing and basic 4K video editing, a range between 16GB and 32GB proves ideal. Meanwhile, the 64GB to 96GB capacity, available in high-end devices like the MacBook Pro, caters to professionals engaged in 4K and 8K video editing and 3D animation, offering a powerhouse solution for intensive projects.
Most Mac buyers will be okay with 8GB for web surfing, basic word processing, and routine tasks. If you're reading this, you probably want 16GB of RAM, as those options will cover most computing tasks you run into.
Those with unique needs, such as professional photographers and developers, may need to consider higher memory options.
Mac users who plan to keep their machines for many years may want to choose more memory to future-proof their devices.
Read on AppleInsider
Comments
It is depressing that people get paid to write such pointless crap.
16GB vs. 32GB -- Maximize a Mac's performance by choosing the right amount of memory
Choosing between 16GB and 32GB of RAM for a Mac depends on your specific needs and intended use cases. 16GB is generally sufficient for most everyday tasks such as web browsing, word processing, and light media editing. It's a good amount for typical multitasking as well.
……etc……
There's not a consistent percentage gain from unified vs split, it depends on the data. The main benefit of unified is that copying data is faster than copying between two different memory chips.
Intel systems also used to have more memory. The MBPs shipped with 16GB system memory + 8GB video memory = 24GB total. I would say it's reasonable that 16GB unified memory can perform in an equivalent way to 16GB+8GB split.
It's still the case that 8GB total memory is only suitable for basic use cases like document editing. Roughly 4GB is allocated to the system so that only leaves 4GB for all other applications.
16GB is ok for heavier usage like software development, photo editing, film editing.
32GB is best for VFX work, any kind of high resolution image/video work and light AI.
64GB+ is best for AI and running multiple heavy pro apps together. Basic image AI can use 24GB RAM on its own.
Some upcoming smartphones are rumored to have 24GB+ RAM due to using local generative AI models:
https://www.xda-developers.com/24gb-ram-smartphones/
C++ was (and still is) probably the last widely popular language that requires the programmer to be very precise about managing memory. But even with C++ there were libraries developed, like STL and Boost, that provided a layer of insulation around the intricacies of manually managing memory. Those libraries largely came about because good programmers developed best practices that helped them produce better code that was less likely to have memory issues.
So why did higher level languages, like Java, C#, and Swift come along when they were essentially hiding a lot of the grungy memory management issues from programmers, in essence allowing them to be more sloppy? These higher level languages, frameworks, and runtime engines were developed largely to increase programmer productivity as applications grew more complex. Of course this came at a cost of increased memory consumption, but it also provided more fault tolerance, or at least more graceful crashing, because there were relatively fewer programmers who had been using the lower level languages that could build large, complex applications without injecting several memory related bugs that would bring the whole application crashing down or put it in a zombie state. Trust me, crashing a program is better than letting it run in a zombie state.
The current reality is that a lot of programmers using modern programming languages, frameworks, and runtimes actually have little control over what is happening when it comes to memory management. They ask for memory (indirectly by creating objects) and they never have to give it back. Everything is reference counted and the runtime decides when the consumed memory is returned to the operating system. Add to this the fact that some frameworks like Swift UI are based on copy semantics that are great for enabling certain functional capabilities but are very memory intensive. Some language provide a way to force memory to be returned to the operating system, but using these blunt tools usually results in some other aspect of the multiprocess, multithreaded, preemptively scheduled, memory managed environment created by the operating system to run less than ideally. Some programmers think they can manage memory better than the runtime and operating system. Most of them are wrong.
Very little of the memory bloat issues in modern applications built using modern languages that are bound to certain runtime engines is the result on lazy programmers. Yes, it is helpful and smart for programmers to truly understand what's happening behind the abstractions that these modern languages provide. Knowing what is really going on under the abstractions can make their apps use memory more efficiently by avoiding using memory intensive functions when other options are available. But unless the programmer came up through their programming career having to deal with the issues that plagued C, Objective-C, and C++ (and other lower level languages) programmers, they are simply focused on getting their job done as quickly as possible and with as much customer deliverable functionality as possible. Apps have exploded in functionality and complexity so being productive has never been more of a concern as it is today. But in the vast majority of cases, this has nothing to do with laziness.
Back to the 16GB versus 32GB question ... buy whatever you can afford and learn to deal with the consequences, both good and bad.
I've seen image software that doesn't free up the image buffers after closing an image so opening more and more images keeps growing the memory usage. Those kind of buffers are usually still handled manually and mismanaged. My RSS reader uses 6GB RAM regularly just for articles because it keeps caching all the text, thumbnails etc. Photoshop can use 3GB at idle, no open documents.
Because RAM is cheap, there seems to be little thought put into resource management. Open a file, leave it open, decompress a document, leave the whole thing in memory.
Hardware memory constraints used to force people to clean up after themselves.
I don't blame them, in isolation it's a non-issue and doing this kind of cleanup is very time consuming and error prone but when almost every developer does this, it means that 10 apps each wasting 2GB starts paging out on 16GB RAM to the point that a reboot is easier than restarting apps because a reboot opens them back up automatically.
I won't expect it to improve on the software side but I'd like to see Apple bump the base RAM options at the same price. Double would be too much but their RAM is likely under $5/GB so going from 8GB->12GB is <$20 (on $1k+ models). Going from 16GB->24GB is <$40 (on $2k+ models) and it would make a big difference to upgrade pricing.