Come on now, get your facts correct. This is the specs on Apple website:
Macbook Pro 14"
Up to 11 hours wireless web
Up to 17 hours Apple TV app movie playback
Macbook Pro 13"
Up to 17 hours wireless web
Up to 20 hours Apple TV app movie playback
Despite having a bulkier case with more volume for batteries, the 14" MacBook Pro still can't beat the battery life of the 13", according to Linus on his Youtube channel, the 13" actually exceeded 20 hrs of battery life. This is expected as the M1 Pro/Max doubles the power consumption. Besides price, battery life is a selling point of the 13".
Not sure who/what post you are replying to.
For your 1st post, maybe you should better understand what you are talking about.
Just because the M1 Pro/Max has a higher maximum power rating, does NOT mean it always uses that much power. Wireless Web & Movie playback will most likely not consume any more power/CPU on the M1 Pro/Max, than it does on the plain M1. The screen on the 14" (mini-LED & 1" larger) will consume much more power. And there's not so much "more volume for batteries" in the 14" - it has a bigger SoC with the M1 Pro or M1 Max, and a bigger cooling solution.
Does the integration of the memory and GPU on the M-series SoCs not create issues for multiple CPU architectures? Seems like it might (I claim no expertise here, just guessing).
It depends on what problems you are trying to solve and how you are going about solving those problems. At the most fundamental level it comes down to two basic factors: the number of computational elements you are trying to apply to solve a problem and the cost of communicating between and synchronizing those computational elements to solve the problem. It’s really no different than trying to organize the work being done by a large number of people trying to solve a single big problem, for example an army fighting a large battle.
Having a large number of computational elements is great if they can all work independently and not waiting (blocked) on one another, or blocked waiting on something that they all share. In the most common computer architectures one of the biggest shared thing is the system memory that all CPUs share. The on-chip caches in each CPU are optimized to exploit the statistical properties of spatial and temporal locality, i.e., the probability that the next chunk of memory a process (or thread) asks for will be near-to (spatial) or fairly recently (temporal) accessed memory. The on-chip caches try to minimize how often a process/thread has to go to main shared memory, some of which is paged to the storage subsystem to accommodate the virtualized large memory models needed by preemptive multiprocessing architectures. So in a multi-CPU architecture you have issues with accessing shared memory but also keeping all CPU caches synchronized (coherent) when they are all working against a shared main memory.
Apple’s M1 is a system on a chip so they have to contend with all of the synchronization issues including cache coherency on the chip. When you bring multiple M1s into the mix to solve a common problem you’ll have to perform synchronization at the SoC level, much like what’s done in a clustering server architecture. How to communicate between the SoCs is something Apple’s architects will decide. They could do it in several ways including sharing/mapping portions of on-chip unified memory between SoCs, some sort of external memory, or a high speed messaging subsystem between SoCs. Of course all of the SoC-SoC communication will have to be synchronized.
Whenever you mention the word “synchronized” or “coherent” or “shared” in a multiprocessing architecture you are talking about things that greatly hamper the speed up potential of a system with multiple computational elements, be it threads, processes, CPUs, SoCs, or whatever. It means that at some point somebody is waiting, doing no work, because they don’t have everything they need to do their job. This kills the potential speed up in a very big way.
The best strategy against speed up killing synchronization is to lay out the solution in a way that avoids having computational elements blocked/waiting on each other and to minimize the cost of being blocked. Some of the best tools against these types of issues (besides the hardware itself) include software compilers, linkers, and OS runtimes that need to make sure that the totality of problems you are trying to solve can be efficiently distributed across all of the computational elements in ways that minimize synchronization delays. Whether it’s on-chip cores/hyperthreads or multiple CPUs or multiple SoCs it’s always about deciding how to break up the problem at the right level of granularity to get the most effective and efficient use of the “workers” who are doing the work, without getting in each other’s way or stepping on each others toes.
So yeah, there are big issues to be solved. But solving big issues is what computer architects and engineers have been doing for more than 50 years. The underlying fundamentals (which are heavily based on probability) that bound these problems are no different today than they were 50 years ago, they simply occupy an infinitesimally smaller space/volume and run at much faster absolute speeds than they did back then.
It's a shame that the switch to Apple silicone has resulted on a free for all price gouge by Apple. Bye bye dreams of Apple silicon meaning better pricing.
You know this how? Source? No one has any idea what it costs to produce the M1 Pro & M1 Max.
You're right of course, I don't know what the actual cost (R&D and manufacturing) is for the new Apple Silicon. What I do know is that they added $300 to the 2016 MacBook Pro line when they added the Touch Bar, a Touch Bar that is not on these new machines. They also don't have to pay a hefty fee to Intel and yet raised the cost of these MacBooks by what, $200?
If the Touch Bar costs $300 and the new price is $200 more we are paying $500 more for the MacBook Pro than the one that shipped back in 2015.
So yeah, rightly or wrongly I think Apple know they have a good thing going with Apple Silicon and they are asking us all to get lubed up and prerpare for penetration with their pricing.
There is no way the touch bar cost $300. Apple made other changes as well. It’s likely the chips in that machine cost somewhat more too. These new chips are pretty large, as large as Intel chips. They likely cost as much, or even more to produce, with the custom ram packages. Additionally, are you not thinking about the screen? My iPad Pro 12.9” cost an additional $100 because of the new miniled screen. That’s a 12.9” screen, while these are 14.2”.
The TouchBar obviously didn’t cost Apple $300, but it is the additional they charged. The key selling point of the 2016 MacBook Pro without TouchBar is that it cost $300 less not to have it.
Every MacBook Pro is “the best we have ever shipped” and it’s true. Screen technology, as well as everything else moves on.
Apple will charge whatever they think the market will bear. With the Apple Silicon they have a huge advantage and have decided to increase their legendary margins accordingly.
It’s a shame they didn’t create a 14” M1 MacBook Pro as the new base model.
No. A new 14” with an M1 would be highly criticized. My 13.3 Macbook Pro is just .9” smaller in screen size. How much more would someone want to pay for a slightly bigger one with a miniLED display? $1,500, $1,600?
Come on now, get your facts correct. This is the specs on Apple website:
Macbook Pro 14"
Up to 11 hours wireless web
Up to 17 hours Apple TV app movie playback
Macbook Pro 13"
Up to 17 hours wireless web
Up to 20 hours Apple TV app movie playback
Despite having a bulkier case with more volume for batteries, the 14" MacBook Pro still can't beat the battery life of the 13", according to Linus on his Youtube channel, the 13" actually exceeded 20 hrs of battery life. This is expected as the M1 Pro/Max doubles the power consumption. Besides price, battery life is a selling point of the 13".
Not sure who/what post you are replying to.
For your 1st post, maybe you should better understand what you are talking about.
Just because the M1 Pro/Max has a higher maximum power rating, does NOT mean it always uses that much power. Wireless Web & Movie playback will most likely not consume any more power/CPU on the M1 Pro/Max, than it does on the plain M1. The screen on the 14" (mini-LED & 1" larger) will consume much more power. And there's not so much "more volume for batteries" in the 14" - it has a bigger SoC with the M1 Pro or M1 Max, and a bigger cooling solution.
Comments
For your 1st post, maybe you should better understand what you are talking about.
Just because the M1 Pro/Max has a higher maximum power rating, does NOT mean it always uses that much power. Wireless Web & Movie playback will most likely not consume any more power/CPU on the M1 Pro/Max, than it does on the plain M1. The screen on the 14" (mini-LED & 1" larger) will consume much more power. And there's not so much "more volume for batteries" in the 14" - it has a bigger SoC with the M1 Pro or M1 Max, and a bigger cooling solution.
Having a large number of computational elements is great if they can all work independently and not waiting (blocked) on one another, or blocked waiting on something that they all share. In the most common computer architectures one of the biggest shared thing is the system memory that all CPUs share. The on-chip caches in each CPU are optimized to exploit the statistical properties of spatial and temporal locality, i.e., the probability that the next chunk of memory a process (or thread) asks for will be near-to (spatial) or fairly recently (temporal) accessed memory. The on-chip caches try to minimize how often a process/thread has to go to main shared memory, some of which is paged to the storage subsystem to accommodate the virtualized large memory models needed by preemptive multiprocessing architectures. So in a multi-CPU architecture you have issues with accessing shared memory but also keeping all CPU caches synchronized (coherent) when they are all working against a shared main memory.
Apple’s M1 is a system on a chip so they have to contend with all of the synchronization issues including cache coherency on the chip. When you bring multiple M1s into the mix to solve a common problem you’ll have to perform synchronization at the SoC level, much like what’s done in a clustering server architecture. How to communicate between the SoCs is something Apple’s architects will decide. They could do it in several ways including sharing/mapping portions of on-chip unified memory between SoCs, some sort of external memory, or a high speed messaging subsystem between SoCs. Of course all of the SoC-SoC communication will have to be synchronized.
Whenever you mention the word “synchronized” or “coherent” or “shared” in a multiprocessing architecture you are talking about things that greatly hamper the speed up potential of a system with multiple computational elements, be it threads, processes, CPUs, SoCs, or whatever. It means that at some point somebody is waiting, doing no work, because they don’t have everything they need to do their job. This kills the potential speed up in a very big way.
The best strategy against speed up killing synchronization is to lay out the solution in a way that avoids having computational elements blocked/waiting on each other and to minimize the cost of being blocked. Some of the best tools against these types of issues (besides the hardware itself) include software compilers, linkers, and OS runtimes that need to make sure that the totality of problems you are trying to solve can be efficiently distributed across all of the computational elements in ways that minimize synchronization delays. Whether it’s on-chip cores/hyperthreads or multiple CPUs or multiple SoCs it’s always about deciding how to break up the problem at the right level of granularity to get the most effective and efficient use of the “workers” who are doing the work, without getting in each other’s way or stepping on each others toes.
So yeah, there are big issues to be solved. But solving big issues is what computer architects and engineers have been doing for more than 50 years. The underlying fundamentals (which are heavily based on probability) that bound these problems are no different today than they were 50 years ago, they simply occupy an infinitesimally smaller space/volume and run at much faster absolute speeds than they did back then.
Have you not read the article related to this post?
https://appleinsider.com/articles/21/10/18/compared-new-14-inch-macbook-pro-versus-13-inch-m1-macbook-pro-versus-intel-13-inch-macbook-pro
The comparison chart listed both machines with the same battery life, which is false information. Check out the tech specs on Apple's website.