Actual RAM use cases

[Ploki]

Would be nice, do you know of any product that lets you connect NVMe drives via TB3? I've never seen one. Technically, you also wouldn't saturate USB 3.1 unless you do NVMe RAID, which I absolutely haven't seen available for portable devices.

People do this in desktops though. You can get 4-way NVMe RAID which is starting to approach the limits of PCIe. Insanely fast data transfer rate, though probably no better for latency. This would technically be possible over TB3 as well. Would be kinda cool if Apple could offer such a peripheral. But sadly they don't, and I don't know that anyone does.

You wouldn't saturate it but usual USB3(.1) implementations are via SATA, and SATA is quantifiably worse than NVMe for high performance situations. (So was USB3.0, dont know about 3.1)

https://www.tomshardware.com/reviews/netstor-na611tb3-thunderbolt-3-nvme-portable-ssd,5359.html

What if I want to edit 4K material on final cut? Is a 13 inch with 16gb of Ram enough. PLEASE HELP

How much processing? How much row footage? What kind of codec of raw footage? How long is the end format?

I edited 4K video on my 2012 rMBP, but that doesn't really say much. More is better.
[doublepost=1532592437][/doublepost]

It's a fairly compelling argument to (almost) write once and (almost) run everywhere. I don't think this reasoning will change anytime soon.

That said I'm not sure if this direction is sustainable. Spotify taking 1.5 GB of memory just to play a song on disk? Egregious.

wow it really does?!

 

[CodeJoy]

It's a fairly compelling argument to (almost) write once and (almost) run everywhere. I don't think this reasoning will change anytime soon.

That said I'm not sure if this direction is sustainable. Spotify taking 1.5 GB of memory just to play a song on disk? Egregious.

Oh, I know. I tried making an app based on Electron. I have a pretty good use case for one. And still, the more I learned, the more it was just in the opposite direction of what I wanted. May still happen, but it's not really something I enjoy. And there are other ways of writing once and running anywhere. It's just that none are really good enough, and from my limited experience I'd include Electron in that. (though it might have some promise)

I think my coding editor was taking 80MB or so of RAM last time I looked. That seems sensible to me. 1.5GB for playing a song does not

 

[Aea]

Yeah Spotify is an absolute hog. I use Atom as my primary editor (I used Eclipse before so maybe I just like making bad decisions) and it uses around 1-2GB depending on what I have open in it.

I can say it's probably the best code highlighter I've ever used.

 

[leman]

At some point, I think programmers will need to start considering efficient use of memory. Right now the model is basically to use more memory in order to save coding time. Which is understandable, it's just not something I find appealing.

Its what Apple is trying to do with Swift. But their effort is fairly unique so far... most programming languages and frameworks are really wasteful with RAM.

 

[CodeJoy]

Yeah Spotify is an absolute hog. I use Atom as my primary editor (I used Eclipse before so maybe I just like making bad decisions) and it uses around 1-2GB depending on what I have open in it.

I can say it's probably the best code highlighter I've ever used.

Heh cool We're getting a bit off track here, but it's an interesting case that makes a good point. Atom and Sublime Text (my editor) are comparable products and largely achieve the same thing. Atom apparently takes 1-2GB of RAM, and Sublime Text fits easily under 100MB. This doesn't in itself make one good and one bad, but it's a very good example of how developer choices can have massive impact on RAM usage.

A similar case, though not for RAM, is how Adobe Premiere and Final Cut Pro perform wildly different on the exact same hardware. Contrary to popular belief, this isn't really because one is more optimised than the other. It's because of developer choices, or maybe more likely management choices.

 

[leman]

I couldn't disagree more. Many apps are moving towards an Electron (i.e. essentially a standalone web browser for every app) model which consumes memory like no tomorrow.

It could be more sustainable if these solutions would properly utilise shared memory... in the end, the core of the framework is going to be constant across such applications, which is indeed very wasteful on RAM.

 

[CodeJoy]

Its what Apple is trying to do with Swift. But their effort is fairly unique so far... most programming languages and frameworks are really wasteful with RAM.

I didn't know that about Swift, but I wouldn't be surprised. Apple are quite good with pushing towards more efficiency, which is one reason Macs often do better with slightly lesser hardware.

They were early with their task scheduler (GCD) which is very fast and efficient, Safari is very efficient with power usage for a web browser, macOS is very efficient with RAM use and allocation, etc etc. This very often is forgotten (or not even known in the first place) when people compare spec sheets.

 

[leman]

Contrary to popular belief, this isn't really because one is more optimised than the other.

Optimised is such an overused term, especially by people who themselves have no idea about algorithms and software optimisation.

 

[CodeJoy]

Optimised is such an overused term, especially by people who themselves have no idea about algorithms and software optimisation.

Haha indeed. Most coders know more about optimisation than the general public, and I have spent a lot more time than even most coders in various forms of optimisation. I hardly ever use the term myself, and when I do it's usually in the mathematical sense

 

[leman]

I didn't know that about Swift, but I wouldn't be surprised. Apple are quite good with pushing towards more efficiency, which is one reason Macs often do better with slightly lesser hardware.

Swift has a very memory-efficient representation of compiled generic code. Where almost everyone else (C++, Rust etc.) specialises (they create different versions of routines for different types), Swift uses a single abstract function that is type-agnostic. Its a memory-vs-performance tradeoff (since the type-agnostic function can't be as fast as specialised one), but most of the time it doesn't matter and reduced code cache pressure can actually counteract any drawbacks. Of course, Swift can also specialise if it helps performance (tight loops etc.).

 

[CodeJoy]

Swift has a very memory-efficient representation of compiled generic code. Where almost everyone else (C++, Rust etc.) specialises (they create different versions of routines for different types), Swift uses a single abstract function that is type-agnostic. Its a memory-vs-performance tradeoff (since the type-agnostic function can't be as fast as specialised one), but most of the time it doesn't matter and reduced code cache pressure can actually counteract any drawbacks. Of course, Swift can also specialise if it helps performance (tight loops etc.).

Very cool. Making code (and data) smaller (to fit in caches) should actually be the first optimisation on any coder's list. This is actually awesome for macOS, as iOS apps are moving to Swift, and macOS gaining the ability to run iOS apps. This is not too dissimilar from Electron apps, but the iOS apps would be far more efficient.

Yeah Spotify is an absolute hog. I use Atom as my primary editor (I used Eclipse before so maybe I just like making bad decisions) and it uses around 1-2GB depending on what I have open in it.

Oh, one thing I forgot to mention is that even when an app is listed as using a certain amount, it still probably doesn't. Apps use pages of RAM, both for code and data, and they won't all be in RAM if there's something else that needs to be there more. Which is also why large apps still start very fast. They just map in the first page of code and start executing.

 

[wallysb01]

As noted in the part you didn't bold, it's a simple way of thinking about it. I believe I mentioned it was more complicated than I stated, however to help people who don't understand, it's a simplistic way of achieving a relatively decent understanding of personal requirements. Of course they could go into frequency, IO, BUS's and all-sorts, but my post was aimed at helping those who don't actually need to go into all of that stuff to make a purchasing decision.

16GB is still a lot of RAM! Just because "My 7 year old machine had 16GB, therefore I need double" doesn't mean it's true. Your 7 year old machine was actually sold with say 4GB of RAM, you upgraded it in the not so recent past to 16GB - so today 16GB is fine. 32GB is a huge amount of RAM, and it's a great upgrade option for those who need it, but anyone even pondering whether they need it or not really doesn't need it.

Don't get me wrong, I agreed with most of what you said. I just think that, even to the complete layman, memory pressure should be explained as non-linear. If you have 40% memory pressure today on 16GB, that's actually a relatively stressed computer without a lot of head room before it blows up in your face. I would suggest to those people they get 32GB for a computer they might want to keep around for 3+ years. Now if you're getting 40% memory pressure because you have Avogadro's number of tabs open, well, you're doing it wrong and you don't need 32GB of RAM.

 

[Painter2002]

This.

Memory Pressure is where you really see the RAM Bottleneck, I use 8Gb and mine never goes above 60%

Same here, I never go above about 55-60% myself with my 8gb RAM.
[doublepost=1532623080][/doublepost]

Yeah, with faster drives and everything, it's really debatable. On my 2012 rMBP for the workflow i have, SSD speeds is a bottle neck (As in, "it could work faster") and CPU hits the ceiling.
Can't say i once said "huh i need more RAM". I'm gonna get it anyway.

When I was still using 4GB ram in a Mac Mini in 2015 (and yes I’d upgraded to an SSD already), I said I needed more RAM, because it was pretty sluggish on multitasking. But that being said, I think most people are pretty future proof with just 16gb of RAM. 8GB should be good for most in a 4-5 year lifespan, but if you expect the same fast speeds in 7-8 years, 16GB would be the minimum I’d expect to need. 32 GB is really for music and video editing, and even that is somewhat subjective on how much time you’re really saving right now with how well Macs are able to use paging protocols with their built in SSDs, IMO.