3 ms·

A few points to make... - the shared CPU+GPU RAM doesn't necessarily mean the GPU has to eat up system RAM when in use, because it can share addressing. So whe

by dagmx 5y ago

A few points to make... - the shared CPU+GPU RAM doesn't necessarily mean the GPU has to eat up system RAM when in use, because it can share addressing. So whereas the current Mac pro would require two copies of data (CPU+GPU) the new Mac studio can have one. Theoretically. - they do have very significant video decoder blocks. That means that you may use less RAM than without since you can keep frames compressed in flight

arcticbull 5y ago
Also, the memory model is quite different - with the ultra-fast SSD and ultra-fast on-die RAM. You can get away with significantly less RAM for the same tasks, not just because of de-duplication but because data comes in so quickly from the SSD that paging isn't nearly the hit it is on say an Intel based Mac. I'd expect it to work more like a game console, streaming in content from the SSD to working memory on the fly, processing it with the CPU and video decode blocks, and insta-sharing it with the GPU via common address space. All that is to say, where you needed 1.5TB of RAM on a Xeon, the architectural changes on Apple Silicon likely mean you can get away with far less and still wind up performing better. The "GHz myth" is dead, long live the "GB myth."
- _0w8t 5y ago
  Another thing to consider is memory compression. If Apple added dedicated hardware for that, it can effectively double the total memory with minimal performance hit.
  - rocqua 5y ago
    Memory compression only works in certain scenarios. It requires your memory to actually have low entropy.
- masklinn 5y ago
  > ultra-fast on-die RAM The RAM is not on die. It’s just soldered on top of the SoC package. > All that is to say, where you needed 1.5TB of RAM on a Xeon, the architectural changes on Apple Silicon likely mean you can get away with far less and still wind up performing better. No, it does not. You might save a bit, but most of what you save is the transfers, because moving data from the CPU to the GPU is just sending a pointer over through the graphics API, instead of needing to actually copy the data over to the GPU’s memory. In the latter case, unless you still need it afterwards you can then drop the buffer from the CPU. You do have some gains as you move buffer ownership back and forth instead of needing a copy in each physical memory, but if you needed 1.5TB physical before… you won’t really need much less after. You’ll probably save a fraction, possibly even a large one, but not “2/3rd” large, that’s just not sensible.
- martinald 5y ago
  I agree, I got a 8GB mac mini (was really just curious to see the M1 in action and the 16GB model was backordered badly) and it performs extremely well memory wise. I often use 12GB+ and I never notice unless I check activity monitor.
  - arcticbull 5y ago
    That's what I based my assessment on too. I had an 8GB M1 MacBook Pro (swapped for the 16GB M1 Pro MacBook Pro 14 since) and I had no issues developing iOS and macOS apps with it using Xcode, and Rust development with VSCode. This brought my old 16GB Intel MacBook Pro to its knees.
- fomine3 5y ago
  This is myth.

by dagmx 5y ago

arcticbull 5y ago

Also, the memory model is quite different - with the ultra-fast SSD and ultra-fast on-die RAM. You can get away with significantly less RAM for the same tasks, not just because of de-duplication but because data comes in so quickly from the SSD that paging isn't nearly the hit it is on say an Intel based Mac. I'd expect it to work more like a game console, streaming in content from the SSD to working memory on the fly, processing it with the CPU and video decode blocks, and insta-sharing it with the GPU via common address space. All that is to say, where you needed 1.5TB of RAM on a Xeon, the architectural changes on Apple Silicon likely mean you can get away with far less and still wind up performing better. The "GHz myth" is dead, long live the "GB myth."

_0w8t 5y ago
Another thing to consider is memory compression. If Apple added dedicated hardware for that, it can effectively double the total memory with minimal performance hit.
- rocqua 5y ago
  Memory compression only works in certain scenarios. It requires your memory to actually have low entropy.
masklinn 5y ago
> ultra-fast on-die RAM The RAM is not on die. It’s just soldered on top of the SoC package. > All that is to say, where you needed 1.5TB of RAM on a Xeon, the architectural changes on Apple Silicon likely mean you can get away with far less and still wind up performing better. No, it does not. You might save a bit, but most of what you save is the transfers, because moving data from the CPU to the GPU is just sending a pointer over through the graphics API, instead of needing to actually copy the data over to the GPU’s memory. In the latter case, unless you still need it afterwards you can then drop the buffer from the CPU. You do have some gains as you move buffer ownership back and forth instead of needing a copy in each physical memory, but if you needed 1.5TB physical before… you won’t really need much less after. You’ll probably save a fraction, possibly even a large one, but not “2/3rd” large, that’s just not sensible.
martinald 5y ago
I agree, I got a 8GB mac mini (was really just curious to see the M1 in action and the 16GB model was backordered badly) and it performs extremely well memory wise. I often use 12GB+ and I never notice unless I check activity monitor.
- arcticbull 5y ago
  That's what I based my assessment on too. I had an 8GB M1 MacBook Pro (swapped for the 16GB M1 Pro MacBook Pro 14 since) and I had no issues developing iOS and macOS apps with it using Xcode, and Rust development with VSCode. This brought my old 16GB Intel MacBook Pro to its knees.
fomine3 5y ago
This is myth.