Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Terrific look
- Thread starter cube
- Start date
- Sort by reaction score
There's no "Alternatives to OS X and Macs" forum.
Before the alternative to iOS forum, Android threads went into the iPhone forum.
This is sister hardware to what will appear in the next Mac Pro.
Some will Hackintosh this hardware.
MSI having a release date of August 29th is of potential interest to those who are waiting for a Mac Pro refresh and those who like to speculate dates.
Overclockers.co.uk are already selling DDR4 kits.
Looking forward to overall performance of the new CPU's combined with DDR4.
I was under the impression that the current (2013) Mac Pro sports a quad-channel design..?!
Nope. If you add a third RAM stick, you could actually get a performance loss.
Myself, I tend to favor performance over sheer RAM capacity, which makes that configuration awkward.
I haven't been following for too long, but the motherboards that support the Devil's Canyon refresh of the Haswell i7s (Z97) were out about a week before the chips were being sold.
Not sure what you're trying to say there, but... on a Mac Pro (2013), it will operate in dual channel if two DIMMs are installed, triple channel if three DIMMs are installed, and quad channel if four DIMMs are installed.
While memory performance is technically better the more channels it's working with, additional RAM capacity is almost always more beneficial than configuration in RAM hungry applications (though having more RAM than you'll ever use if of course of no benefit). Memory channels (and memory speed for that matter) is much less important in real-world usage.
Huh, you're right, I just looked it up. The nMP is a quad channel memory controller. I wonder why I thought otherwise. I guess the oMP was a triple channel?
Yeah that is generally the case and they haven't said Xeons will be later than i7s either so a November release is perhaps perfectly doable for Apple, although I would still expect it to be next year.
Of course this is true - but.
One might take your comment and think that if your app (or all your concurrent apps) need 15 GiB, then 16 GiB of RAM is enough - getting 24 GiB or 32 GiB is a waste.
However, suppose that your app makes two passes reading a 4 GiB input file, writes a 4 GiB work file, then reads the work file and renders a 1 GiB output file.
With 16 GiB of RAM, it will:
- read 4 GiB from disk
- read 4 GiB from disk
- write 4 GiB to disk
- read 4 GiB from disk
- write 1 GiB to disk
- to check the output, read 1 GiB from disk
If you had 24 GiB of RAM, it will:
- read 4 GiB from disk, and put it in cache
- read 4 GiB from cache - not touching the disk
- write 4 GiB to disk, and put it in cache
- read 4 GiB from cache - not touching the disk
- write 1 GiB to disk, and put it in cache
- to check the output, read 1 GiB from cache - not touching the disk
File system caches in DRAM are far better than SSDs.
So, you're not at all wrong - but the workload that you think *needs* 15 GiB might actually *use* 24 GiB quite handily.
Last edited:
Hi Aiden, that is entirely true about needing RAM, and you bring up an important distinction. So, when I say "need", I mean "need". To take your example, thinking you only need 16GB when you actually need 24GB means that you "need" 24GB.
A user should also anticipate that RAM needs may increase in the future and figure that in for the anticipated longevity of the system.
The reason I like to throw in the "not more than you need" disclaimer is there's a tendency for less knowledgeable users to think that RAM in itself makes things faster, so if 16GB is good, 32GB is better... which is not the case (unless the additional RAM is actually needed).
Hi Aiden, that is entirely true about needing RAM, and you bring up an important distinction. So, when I say "need", I mean "need". To take your example, thinking you only need 16GB when you actually need 24GB means that you "need" 24GB.
A user should also anticipate that RAM needs may increase in the future and figure that in for the anticipated longevity of the system.
The reason I like to throw in the "not more than you need" disclaimer is there's a tendency for less knowledgeable users to think that RAM in itself makes things faster, so if 16GB is good, 32GB is better... which is not the case (unless the additional RAM is actually needed).
That's why I said "So, you're not at all wrong" and added some extra depth to the discussion.
I do think that it would be useful to look at "need" vs "can use", though.
The 15 GiB workload that I suggested might run at:
- 4 hours with 12 GiB of RAM due to hard physical page faults
- 15 minutes with 16 GiB of RAM - far fewer page faults, but data rereading because of no room for cache
- 10 minutes with 24 GiB and good caching
Anyone would say that the difference from 4 hours to 15 minutes is huge, and you "need" that.
However, knocking 5 more minutes off is "nice", not "need".