Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Well clearly something is different if the iPad Pro can handle quite a bit thrown at it with its severe limitation on RAM. What is different, I do not know. But something is.

It has to do with both the operating system and especially the application optimising for low memory use.

Very often you have several algorithms to solve a problem. Often you can decide between an algorithm with low memory use and high CPU use or vice versa. Under iOS the programmer will more often choose the low memory algorithm.

Also with more memory the application may choose to have larger buffers and keep more data in memory.

Third, your app will be rejected by Apple, run poorly or crash more often if you use a lot of memory under iOS. This creates a strong incentive for the developer to put in a lot of effort to reduce the memory usage of the app.

On the other hand, all those people saying you need a lot of memory on the Mac side tends to forget that MacOS and the applications will use more memory if its available. The mistake they are doing are looking at the usage in a 16Gb system and seeing the OS using all the RAM, thinking therefor they need more RAM.

For most regular users, 8Gb RAM will be enough.
 
It has to do with both the operating system and especially the application optimising for low memory use.

Very often you have several algorithms to solve a problem. Often you can decide between an algorithm with low memory use and high CPU use or vice versa. Under iOS the programmer will more often choose the low memory algorithm.

Also with more memory the application may choose to have larger buffers and keep more data in memory.

Third, your app will be rejected by Apple, run poorly or crash more often if you use a lot of memory under iOS. This creates a strong incentive for the developer to put in a lot of effort to reduce the memory usage of the app.

On the other hand, all those people saying you need a lot of memory on the Mac side tends to forget that MacOS and the applications will use more memory if its available. The mistake they are doing are looking at the usage in a 16Gb system and seeing the OS using all the RAM, thinking therefor they need more RAM.

For most regular users, 8Gb RAM will be enough.
And the fact that Macs will now natively run iPhone and iPad apps means apps can now use less memory. Some companies might just port over the iPad app and make it different on larger screens vs converting the x86 app to M1.

So my point is still valid that some of the optimizations can be brought over the macOS now.

And again, just to be clear, I am not saying nobody needs more than 8GB or 16GB of RAM. I know people that need 128GB or even more RAM than that. There are certainly people that need 1.5TB of RAM. Also, we have a server at work that NEEDS 4TB of RAM. Everybody's workflow is different.

However, I seriously do not think, and my tests have proved it, that my 1080p 60fps work needs even more than 8GB. Video professionals agree. So the Mac mini might be good. I will get the 16GB just because I like having more than I need.

And you are 100% correct about people looking at what memory is being used and confusing that with what memory is needed. The fact that on my 128GB computer Adobe apps take up 110 GB of it and the SAME FILE takes up 11GB of 16GB is evidence of that. Also, my 128GB system with pretty much nothing open is using 16GB of RAM.
 
Last edited:
You keep saying it, but why don’t you substantiate it. What do you know about it? Cite some sources or tell us what your background is and how it makes you a subject matter expert. Otherwise it’s just conjecture. Nothing more.
I am not the one making claims that the M1's architecture does away with all computer norms and enables the processor the ability to eliminate the need for anything above 16 GB of RAM. Therefore I do not need to substantiate anything because I am not the one making such a nonsense claim.

That said why don't you substantiate how the architecture is different thus eliminating the need for more than 16 GB of RAM?
 
Well clearly something is different if the iPad Pro can handle quite a bit thrown at it with its severe limitation on RAM. What is different, I do not know. But something is.
What is different is you're not comparing like for like.
 
@xWhiplash To your original post, FCP and Affinity are already native and presumably optimized
710E41B1-AF0A-4EBE-8778-1F32C27481F9.jpeg
As far as Adobe products:
Adobe said:

Apple Silicon compatibility​


Caution:
Running Adobe apps under Rosetta 2 emulation mode on Apple devices with Apple Silicon M1 processors is not officially supported.

Native compatibility is planned for 2021. Adobe is committed to ensuring Photoshop is available on all major platforms and surfaces, including running natively on Apple devices with M1 processors.

Photoshop 22.x will run under Rosetta 2 emulation mode on Apple devices with M1 processors running macOS BigSur
Lastly, I would suggest going with 16GB. If anything, it would provide padding, future proofing but isn’t something that would be considered extremely excessive, such as 64GB for a common consumer.
 
@xWhiplash To your original post, FCP and Affinity are already native and presumably optimized
View attachment 1668646
As far as Adobe products:

Lastly, I would suggest going with 16GB. If anything, it would provide padding, future proofing but isn’t something that would be considered extremely excessive, such as 64GB for a common consumer.
Thank you. Do you think this would be better than my 2019 i9 iMac for 1080p work? As I mentioned earlier, I really did not notice a difference between my 2010 Mac Pro and my 2019 i9 iMac, but I heard the T2 chip can make things much faster.
 
Thank you. Do you think this would be better than my 2019 i9 iMac for 1080p work? As I mentioned earlier, I really did not notice a difference between my 2010 Mac Pro and my 2019 i9 iMac, but I heard the T2 chip can make things much faster.
Short answer: Apparently, the T2 makes a significant difference.

Long answer: I couldn’t find any simple direct benchmarks, but we can do some rough estimates, chained. Let’s make the i9 iMac a baseline of 4. the above video says an iMac Pro is 2.25x as fast as the i9 iMac thanks to the T2. We’ll say 2x, making the iMac Pro score 8. This article says an i7 mini is about 4x slower than an iMac Pro, which would put the i7 mini at a 2 in this exampke equation. Let’s assume — oddly, I couldn’t find a comparison — an i3 mini is 2x slower than an i7 mini in FCP rendering. That would mean the i3 is at 1 (presumably 4x slower than the iMac i9). However, now let’s go back to my previous post. Apple claims the M1 Mac mini is more than 6x faster than the i3 mini (but we will round down for simplicity/ease. The score 1 i3 Mac mini multiplied by 6 (or 6x) equals 6. Therefore, according to this rough math, the M1 Mac mini could be 1.5x the i9 iMac. Alternatively, you could fairly confidently be safe and conclude they may be ar least equal. If so, very impressive.
 
  • Like
Reactions: Ethosik
Short answer: Apparently, the T2 makes a significant difference.

Long answer: I couldn’t find any simple direct benchmarks, but we can do some rough estimates, chained. Let’s make the i9 iMac a baseline of 4. the above video says an iMac Pro is 2.25x as fast as the i9 iMac thanks to the T2. We’ll say 2x, making the iMac Pro score 8. This article says an i7 mini is about 4x slower than an iMac Pro, which would put the i7 mini at a 2 in this exampke equation. Let’s assume — oddly, I couldn’t find a comparison — an i3 mini is 2x slower than an i7 mini in FCP rendering. That would mean the i3 is at 1 (presumably 4x slower than the iMac i9). However, now let’s go back to my previous post. Apple claims the M1 Mac mini is more than 6x faster than the i3 mini (but we will round down for simplicity/ease. The score 1 i3 Mac mini multiplied by 6 (or 6x) equals 6. Therefore, according to this rough math, the M1 Mac mini could be 1.5x the i9 iMac. Alternatively, you could fairly confidently be safe and conclude they may be ar least equal. If so, very impressive.
Wow that is a nice post! Thank you. I am definitely on the fence, it would be nice to get a headless mac again as I like my other screens over the iMac's screen.
 
Anyone making the claim that an ARM processor magically reduces a 64 GB memory requirement down to 16 GB. I am willing to listen, are you willing to tell me why?
ill field this one.

its doesn't, and doesn't need to.

ARM is far more efficient than intel CISC cpu's. its really that simple. i would never say more ram is bad. but i also would not talk someone down on 8gb , that should be plenty for most folks. 16gb would be great for people doing photo and video editing , multiple apps on arm. 32gb would be even better....but i doubt it would be as significant as you would think vs 16gb.

the world living in x86 is always about more memory , more memory.

ill catch alot of flak for what i say. but when the machines hit peoples hands , i think the true story will come to light....and if im wrong , ill eat my own shoes.
 
ill field this one.

its doesn't, and doesn't need to.

ARM is far more efficient than intel CISC cpu's. its really that simple. i would never say more ram is bad. but i also would not talk someone down on 8gb , that should be plenty for most folks. 16gb would be great for people doing photo and video editing , multiple apps on arm. 32gb would be even better....but i doubt it would be as significant as you would think vs 16gb.

the world living in x86 is always about more memory , more memory.

ill catch alot of flak for what i say. but when the machines hit peoples hands , i think the true story will come to light....and if im wrong , ill eat my own shoes.
ARM is intended to be more efficient than CISC primarily due to the reduced number of instructions and orthogonal instruction set. Each instruction was intended to do less work but perform what work is does very fast. The end result was faster executing instructions but more of them may be required depending on the task. The side effect of this was increased code size as, on average, more instructions were required to complete the same task.

CISC, OTHO, was designed to provide a richer instruction set and therefore perform more work per instruction. Due to this additional work an instruction may require more cycles to complete. The side effect of this was, on average, the reduced code size as the processor could perform the same task with less instructions.

Clearly the RISC based system is not more efficient than CISC when it comes to code size. Therefore, when it comes to application memory usage, on average RISC is less efficient. However this is really not much of an issue with today's memory sizes. Whether an applications uses 200MB or 250MB is not much of a concern with most modern systems starting out with 4GB minimum.

Where memory consumption becomes an issue is with user data. If I have a 16GB data set that consumes 16GB of data no matter whether the system processing it is RISC or CISC. To the system it's data and there is nothing more efficient about processing it merely because the processor is based on a RISC architecture. Either system is going to have to retrieve the information from secondary storage (i.e. a disk), load it into memory, perform whatever operations on it that need to be performed, and write the results back to secondary storage.

A processor with a specific RISC implementation may perform the "perform whatever operations on it that need to be performed" faster than a specific CISC processor but that advantage would be lost the moment the system needs to retrieve additional information from secondary storage. Secondary storage is, even with modern SSDs, much slower than memory. It doesn't matter how fast a given processor is if its starved for data. That's why we have CPU caches as processors can process data at a rate even memory systems cannot support.

RAM can be viewed as a cache for secondary storage. If the system can load the data into RAM the hit to secondary storage is eliminated. If ones data set is 16GB and the system has 64GB of RAM then the entire data set can be cached into RAM (assuming nothing else is competing for those resources). However the opposite cannot be true. One cannot cache 64GB of data into a 16GB system. At a minimum at least 75% is going to have to be retrieved from secondary storage and thus incurring all the delays associated with doing so. No matter how fast the processor this latency will be present.

With that explanation provided please detail to me how a 16GB M1 Mac can retrieve information faster from secondary storage than an Intel based Mac to the point where a 64GB working set would have the same performance as a 64GB Intel Mac. The typical responses of "ARM is more efficient" that I've received to date will not suffice. I want details.
 
  • Like
Reactions: mlykke

Reality check. Everyone is on the new shiny bandwagon... wait until next year and you will have far more options. If you could wait all summer for this announcement, you can wait another 6 months for their next big announcement.
 
Short answer: Apparently, the T2 makes a significant difference.

Long answer: I couldn’t find any simple direct benchmarks, but we can do some rough estimates, chained. Let’s make the i9 iMac a baseline of 4. the above video says an iMac Pro is 2.25x as fast as the i9 iMac thanks to the T2. We’ll say 2x, making the iMac Pro score 8. This article says an i7 mini is about 4x slower than an iMac Pro, which would put the i7 mini at a 2 in this exampke equation. Let’s assume — oddly, I couldn’t find a comparison — an i3 mini is 2x slower than an i7 mini in FCP rendering. That would mean the i3 is at 1 (presumably 4x slower than the iMac i9). However, now let’s go back to my previous post. Apple claims the M1 Mac mini is more than 6x faster than the i3 mini (but we will round down for simplicity/ease. The score 1 i3 Mac mini multiplied by 6 (or 6x) equals 6. Therefore, according to this rough math, the M1 Mac mini could be 1.5x the i9 iMac. Alternatively, you could fairly confidently be safe and conclude they may be ar least equal. If so, very impressive.
For H.265 encoding the T2 chip can be viewed as analogous to QuickSync found in Intel processors.

As for the 6x faster claim that is for GPU performance, processor performance is only 3x faster than the i3 Mini. The M1 chip has a number of different types of processing cores making a direct comparison to Intel processors difficult.
 
As for the 6x faster claim that is for GPU performance, processor performance is only 3x faster than the i3 Mini. The M1 chip has a number of different types of processing cores making a direct comparison to Intel processors difficult.
I was referring to Apple's claim specifically for FCP highlighted in a previous post.

Nevertheless, my conclusion is a rough estimate based on what is known. Obviously, it'd be best to compare an identical FCP project workflow on the exact system configurations, which will indeed eventually happen.
 
In the next 3-4 weeks, I’ll have the opportunity to compare performance between the new 2020 iMac with 8-core CPU and 5700XT, plus 64GB of ram with the base model Mac Mini 512GB/8GB memory and build to order 1TB/16GB memory variant.

There is no doubt that in any meaningful benchmark, the iMac will outperform both minis. At least that’s what I expect, aside from perhaps the CPU give what we know. GPU will be a no contest, but that isn’t the point here. The point is how well can the mini handle the workload I have. Will it be enough? Will it be too slow? How much difference will I see between the 8GB and 16GB versions of the mini? These are the practical answers I’ll hope to have.
 
  • Like
Reactions: MacCheetah3
In the next 3-4 weeks, I’ll have the opportunity to compare performance between the new 2020 iMac with 8-core CPU and 5700XT, plus 64GB of ram with the base model Mac Mini 512GB/8GB memory and build to order 1TB/16GB memory variant.

There is no doubt that in any meaningful benchmark, the iMac will outperform both minis. At least that’s what I expect, aside from perhaps the CPU give what we know. GPU will be a no contest, but that isn’t the point here. The point is how well can the mini handle the workload I have. Will it be enough? Will it be too slow? How much difference will I see between the 8GB and 16GB versions of the mini? These are the practical answers I’ll hope to have.
I'm sure (most) readers will appreciate whatever comparisons you can share. Nevertheless, I do feel (optimistically hope) you'll be pleasantly surprised and Apple's claims aren't far off.

For example:
Apple said:
The four high-efficiency cores deliver outstanding performance at a tenth of the power. By themselves, these four cores deliver similar performance as the current-generation, dual-core MacBook Air at much lower power.

I realize the following are only Geekbench scores, but the 10th generation i3 in the MBA outscores the 8th generation i3 in the 2018 mini and doesn't sit far back from the i9 in the recent iMac -- single core scores, of course.
But, again, if we do some rough math... The MBA i3 scored a total of ~2000, divide that by 4 to equal a score of ~500 per M1 HE core. Then, if we assume, the high-performance (HP) cores are double the performance of the HE that would make each HP core score ~1000, multiplied by 4 equals about 4000, not quite half of the i9's 8950 multi-core score. However, if the M1's HP cores are 4x the HE, that would push the M1's Geekbench 5 MC score to ~8000. This doesn't weigh a lot as there are assumptions and Geekbench doesn't account for a lot of factors... Even so, it's still interesting.
 
I'm sure (most) readers will appreciate whatever comparisons you can share. Nevertheless, I do feel (optimistically hope) you'll be pleasantly surprised and Apple's claims aren't far off.

For example:


I realize the following are only Geekbench scores, but the 10th generation i3 in the MBA outscores the 8th generation i3 in the 2018 mini and doesn't sit far back from the i9 in the recent iMac -- single core scores, of course.
But, again, if we do some rough math... The MBA i3 scored a total of ~2000, divide that by 4 to equal a score of ~500 per M1 HE core. Then, if we assume, the high-performance (HP) cores are double the performance of the HE that would make each HP core score ~1000, multiplied by 4 equals about 4000, not quite half of the i9's 8950 multi-core score. However, if the M1's HP cores are 4x the HE, that would push the M1's Geekbench 5 MC score to ~8000. This doesn't weigh a lot as there are assumptions and Geekbench doesn't account for a lot of factors... Even so, it's still interesting.
Geekbench scores are only good for determining how fast a given system can run Geekbench. Any correlation between its results and real world applications is nothing more than coincidence. I'm waiting for real world application tests, that's where the real proof is.
 

Reality check. Everyone is on the new shiny bandwagon... wait until next year and you will have far more options. If you could wait all summer for this announcement, you can wait another 6 months for their next big announcement.
The longer I wait, the less trade in or value I will get for my 2019 i9 iMac which as I mentioned is not any faster than my 2010 Mac Pro for my workflows.
 

Reality check. Everyone is on the new shiny bandwagon... wait until next year and you will have far more options. If you could wait all summer for this announcement, you can wait another 6 months for their next big announcement.
There will always be better tech available 6-12 months in the future.
 
  • Like
Reactions: MacCheetah3
Plus I waited 9 years to upgrade my 2010 Mac Pro and did not see any significant improvements.
I know the feeling. My Mac mini is 8+ years old, and according to the single core benchmarks, the 8th generation Intel in the 2018 mini is only ~2x faster then this Mac's 3rd generation Intel, which I can believe.

With that said, someone should launch a real benchmark app. Not this 30-second test stuff. Maybe 2.5 - 5 minutes example workflows/projects as tests for the top 25 apps or something. Perhaps that'll be one of my app projects some day. :)
 
I know the feeling. My Mac mini is 8+ years old, and according to the single core benchmarks, the 8th generation Intel in the 2018 mini is only ~2x faster then this Mac's 3rd generation Intel, which I can believe.

With that said, someone should launch a real benchmark app. Not this 30-second test stuff. Maybe 2.5 - 5 minutes example workflows/projects as tests for the top 25 apps or something. Perhaps that'll be one of my app projects some day. :)
Well I think worst case its the same as my iMac is now right? It would definitely be better than my 6-core Mac Pro and as I mentioned things are not that much improved with my 2019 i9 iMac. That would mean I could trade in my iMac, pocket some cash and get the Mac mini with the same performance.
 
  • Like
Reactions: MacCheetah3
ARM is intended to be more efficient than CISC primarily due to the reduced number of instructions and orthogonal instruction set. Each instruction was intended to do less work but perform what work is does very fast. The end result was faster executing instructions but more of them may be required depending on the task. The side effect of this was increased code size as, on average, more instructions were required to complete the same task.

CISC, OTHO, was designed to provide a richer instruction set and therefore perform more work per instruction. Due to this additional work an instruction may require more cycles to complete. The side effect of this was, on average, the reduced code size as the processor could perform the same task with less instructions.

Clearly the RISC based system is not more efficient than CISC when it comes to code size. Therefore, when it comes to application memory usage, on average RISC is less efficient. However this is really not much of an issue with today's memory sizes. Whether an applications uses 200MB or 250MB is not much of a concern with most modern systems starting out with 4GB minimum.

Where memory consumption becomes an issue is with user data. If I have a 16GB data set that consumes 16GB of data no matter whether the system processing it is RISC or CISC. To the system it's data and there is nothing more efficient about processing it merely because the processor is based on a RISC architecture. Either system is going to have to retrieve the information from secondary storage (i.e. a disk), load it into memory, perform whatever operations on it that need to be performed, and write the results back to secondary storage.

A processor with a specific RISC implementation may perform the "perform whatever operations on it that need to be performed" faster than a specific CISC processor but that advantage would be lost the moment the system needs to retrieve additional information from secondary storage. Secondary storage is, even with modern SSDs, much slower than memory. It doesn't matter how fast a given processor is if its starved for data. That's why we have CPU caches as processors can process data at a rate even memory systems cannot support.

RAM can be viewed as a cache for secondary storage. If the system can load the data into RAM the hit to secondary storage is eliminated. If ones data set is 16GB and the system has 64GB of RAM then the entire data set can be cached into RAM (assuming nothing else is competing for those resources). However the opposite cannot be true. One cannot cache 64GB of data into a 16GB system. At a minimum at least 75% is going to have to be retrieved from secondary storage and thus incurring all the delays associated with doing so. No matter how fast the processor this latency will be present.

With that explanation provided please detail to me how a 16GB M1 Mac can retrieve information faster from secondary storage than an Intel based Mac to the point where a 64GB working set would have the same performance as a 64GB Intel Mac. The typical responses of "ARM is more efficient" that I've received to date will not suffice. I want details.
proof is in the pudding


i just did this on my intel mac , 6.8gb for the same applications, fresh install.

let me guess....next your going to say they were written more efficiently....and better?

so magically , 3gb of ram was created...
 
  • Haha
Reactions: iMi
proof is in the pudding


i just did this on my intel mac , 6.8gb for the same applications, fresh install.

let me guess....next your going to say they were written more efficiently....and better?

so magically , 3gb of ram was created...
Yeah same with my test on the iPad Pro Affinity Photo and iMac Affinity Photo with the same amount of layers with the same effects. On the iMac it was using more RAM than the iPad was even capable of.
 
Yeah same with my test on the iPad Pro Affinity Photo and iMac Affinity Photo with the same amount of layers with the same effects. On the iMac it was using more RAM than the iPad was even capable of.
we can win against copy and paste warriors on these forums.

i build daily on arm arch. , i know very much in detail how it operates. but you cant convince people who think they know more.

ahhh well....we tried....
 
proof is in the pudding


i just did this on my intel mac , 6.8gb for the same applications, fresh install.

let me guess....next your going to say they were written more efficiently....and better?

so magically , 3gb of ram was created...
This tells me nothing. There's no controlled test here and I see no data to compare.

That said please provide the requested information. I provided technical information, I expect you to do the same if you are going to dispute it.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.