Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

sierrablue

macrumors regular
Sep 21, 2021
107
50
I agree with Aldente. Mine is at 50% all time in clamshell with power supply. When I know I am going to use it on battery, I charge it to 80% beforehand.
 
  • Like
Reactions: oz_rkie

Unimpeachable

macrumors newbie
Nov 28, 2021
3
0
Boston
Hey guys, I just thought I'd post a semi-detailed long term review of the M1 macbook air from a software developer perspective, in case it might help others make a purchase decision. I have 2 m1 macbook airs, one is a 256gb ssd 8gb unified memory version and the other is a 512gb ssd 16gb unified memory version. Both have the 7core gpu, since I have no use for gpu cores in my use cases. I bought these fairly close to the release date, I think a couple weeks after. I've been using these laptops daily for well over a year now. These are my first apple laptops by the way. I've primarily used only windows and linux OSes in the past although I have used various other apple products like ipad and iphones.

TLDR: Good laptop with a very efficient chip but with major deal-breaking external display issues. Possibly avoid purchase. My personal summary for these laptops is that, while they are good laptops, the external display issues are complete deal breakers for my current setup. If I had known about these issues before my purchases, I would definitely not buy. Additionally, I would not buy the 8gb unified memory version for software development use cases. Also, for those that might be asking why not the macbook pro, well I bought the airs very close to the initial release, so the airs were the only choice back then.

My use case
I am a full stack developer and my main use case comprises of using mainly these programs - VScode, iTerm, Fork (git client), nodejs, npm and pnpm, docker desktop for mac, slack, microsoft teams, postman and a lot of browser tabs. I do have rosetta 2 installed but surprisingly mostly everything now has native arm builds.

My setup
I use both the airs in closed lid clamshell mode most of the time (90%+), connected to external display. I originally had them connected to my main ultrawide, an LG 38gl950b (this is a very high end gaming monitor that I also use with my windows gaming desktop) but due to the major problems I've had with the m1 macbooks on this display (more on this later), I am now using a Benq EW3270u which is a 32" 4k monitor that I had bought a while ago for my playstation. It has a usb-c connection that does dsiplay as well as charge the macbook. Thing to note is that the macbooks still have display issues even with the Benq but to a much lesser extent.

Pros
  1. Fast chip - No surprises here. The arm chips are pretty snappy. Before this, I used to use my main PC which is an i9 9900k based desktop and in most normal use cases the m1 airs seem to be cruising along no issues and I cannot notice any major differences compared to my experience on the i9 9900k desktop. I use javascript/typescript and esbuild along with dotnet core for the most part. Your mileage may vary if you use other more heavy compilers.
  2. Efficient - While the desktop chip obviously has higher raw performance, the m1 arm chips definitely do not hold you back and impressively at a fraction of the power. While the efficiency is unmatched currently by any other chips, I must point out that there are other mobile chips that will beat out the m1s (even the pro and max) for code compile performance pretty handily, especially the new alder lake chips. Obviously at a much higher power draw but whether that additional power draw is an issue or not is for you to decide. For my personal use case, our incremental dev builds using esbuild are fast enough already that a higher power CPU would not make a great deal of a difference in terms of local developer experience and our proper full builds with testing etc. are done on a cloud based CI system anyway so a quiet no fan macbook m1 air is a pretty good device for this type of use case.
  3. Build quality - As mentioned, these are my first apple laptops and I find that the build quality is extremely high. I don't think these are the best looking laptops, subjective I know but I feel something like an almost no bezel dell xps or even the lenovo carbon x1 designs look better but there is no denying that the apple build quality lives up to the hype.
  4. Display - The built in display I feel is great, no complains here. Bezels are a bit large but as noted in my use case, I have the laptops closed 90%+ of the time anyway so this is not an area where I can comment further.

Considerations
  1. RAM (unified memory) - This is not a knock on the m1 air which is why I am putting this under the 'Considerations' category. When I originally bought my first m1, I bought the 8gb version mainly based on the initial reviews that were saying the new unified memory architecture made it so that the 8gb version did a lot more than other traditional memory based devices could. Sadly, this is not strictly true. While, I do think that the 8gb version does go pretty far, there is still a point where you will start struggling. Again, I am not holding this against the m1, just noting it here to say that you should buy more RAM if you feel your use case will require it. And for programming, I can safely say that you will. For me, with multiple VScode windows open, lots of browser tabs (I've tried both the native Safari and chrome/edge), a few terminal windows, the 8gb version can quickly get to a point where its just downright unusable. Sluggish, the rainbow mouse wheel etc. Just not usable essentially. The 16gb version is fine, so far I've never seen it become sluggish under heavy use even with tons of programs and browser tabs running. So, if your use case demands it, go for the 16gb version.
  2. Battery - As mentioned, both my airs are plugged in and lid closed pretty much 24x7. One of them that gets a lot more use than the other now has its battery condition showing as 92% while the other relatively lesser used is still at 100%. As, I've not had an apple laptop before these, I don't know how this compares but I feel there is no issue here.

The Problem

This is where the entire experience just goes south for me atleast (many others also have documented the same issues). The m1 chips seem to have some very serious issues with many external displays (from various manufacturers and various different models). The issues vary from major flickering, vertical lines/bands on the screen, serious ghosting, display signal limited to YPBPR instead of full RGB and temporary image retention/burn-in issues etc. There are various forum posts all over the internet, even detailed threads here like


Unfortunately for me, I've experienced pretty much all of these issues with my main monitor the LG 38GL950B. Major flickering, vertical lines, image retention, no RGB signal, the whole 9 yards. I've been using this monitor for nearly 2 years (and still do) with my i9 9900k/rtx gpu windows gaming PC running flawlessly with full RGB signal with no issues but as soon as I bring the m1 into the equation, its just a dealbreaker. I've tried numerous things like using the caldigit TS3 dock to connect to the monitor, use various expensive 4k/8k hdmi cables, various fixes and workaround, various display setting combinations, initially even sent back the macbook m1 (in its 30 day period) and bought a new one with the exact same issue. The issue has been present from day 1 and still is even with the lastest macos version which seems to suggest to me that this is a hardware level issue. Apple obviously is completely silent on the issue. Maybe it does not affect a large enough % of users to make it worthwhile for them to fix.

I've since switched to using the m1 macbooks with a Benq EW3270u. This monitor fairs a bit better than my LG. There still are some minor temporary vertical lines and some temporary flickering but for the most part the experience is issue free, lets say 95% of the time which makes it useable.

I don't know what the exact issue is and it is possible that these monitors are also not completely blameless. Maybe they are doing something incorrectly which along with the m1s issues combine to cause these problems, no idea. But the fact is that I've been using both these monitors well before I bought the m1s and have had 0 issues using these with my windows machine or my playstations. The only machine that results in issues on both these monitors is both the m1 macbooks and other users experiencing this issue also have the m1 chip as the only common thread.

Bottomline: These laptops are overall great and if you know that you have a known good external monitor to use with these, then I can recommend it as a good laptop to buy. However, if you are not sure that you have a known good monitor to use, then its quite possible that it will become a monitor lottery issue. For me personally, the experience has been less than ideal and crucially, I feel that Apple's complete silence is a bit of a bummer. In any case, I will be waiting a bit longer to see if these issues are fixed with the m2 chips. If they are not, I will be selling my m1 airs to buy a non apple device. However, if these issues do get properly resolved with the m2 chips, then it is quite likely that I will purchase the m2 based chips.

Let me know if you have any questions and I will try my best to answer.
Anyone consider displays processing screen painting or data writes via ISRs vs polling menory ports for i/o etc.? ARM processors on general are awful for ISR context switch delays as each interrupt handling (in my limited experience using them on T1E1 Frame Relay and IP adaptation line cards for high speed broadband interfaces on broadband SW dec. - they
are inherently slow - ARMs have “tons of registers”
(50 or more?) to save w at each ISR context switch - so,
it can be —hugely- tine consuming if not polled or ISRs not hit often for displays in this case (no- I am not a video guy) which is why when using ARMS for any significant data (adaptation layers etc.) or primary user data servicing needing high speed throughout if doing wiring or iseer plane data) we always ran in “polled” vs “interrupt node “as interrupt svc processing would thrash CPU performance (and data throughput- n I am only using a few key data points on old broadband line cards we designed w HW team
back in “the day”)
- we used an old “MIPS” processor w ARM
core but I think this is still one of bigger trade offs of going w ARMs and maybe addressed w SW fixes to poll servicing of displays and use of CPU accessible “unified memory” aka RAM but I inferred w iMacs n MacBook Airs that 16g was too little to put on a comen ref designed computer imho ( hard to know but seems like legit issue may exist that’s serious flaw in
SW/HW here (given all the gripes w diff M1s idk?)
- sorry if off base here ..
Use of CPU or GPU idk partition of tasks (just a shot from hip- but fwiw - I was a pretty solid SW HW architect n did lots of code on ARMs vs other CPU types - this was worst aspect of handling voice over IP at T1E1 rates using ARM processors (w DMA n back when DRAMs were 50 nsec or faster at best mostly)
To segment or adapt framed packets from IP to say ATM or frame relay or IP directly mapped onto the STS framing in sONET STS streams need big cache as swaps in out of RAM like onteeeipt context switches were on order of marca to enter ISR b4 any inter tor service was executed making it not starter to run w inteeerots on any significant IO throughout good servicing of data or video display type items n idk about video cards uses or ASICs or video w unified men vs Video memory on molder MACs & MacBooks but rushing a huge architecture changed w so many variants to support seems risky to buy generic 8g MacBook Air (I punted on Costco discounted iMacs w 8g as knew would never keep up w CPU intensive iMovie or other pro level processing stuff) — waiting on M1 Pro w integrated 32g direct menory ref so can access men fast using full 32g to avoid pitfalls of too small “unified menory” -and yes little to know on how M1s vs M1Pro handles higher speed ops if interrupt driven seems like it would use more than one processor ir fixed the ISR register save issues for running isr based CPU n menory intensive ops but been while so not saying 4 sure as be surprised not caught if basic legacy didplay could not be handled by M1 even w 8g
PS i’ll never get another iMac without loads of RAM and direct accessing of full terabyte 4 tera urea 8 terabytes whatevere mem amount I hit w iMac want tu know it’s not bogged down by innate weaknesses in architecture. thx ?
BP
 
Last edited:

Aggedor

macrumors 6502a
Dec 10, 2020
799
939
Clamshell - I would not use a computer, especially a passively cooled one in this mode, too much heat will shorten life and throttle performance
I would normally agree, but I push my M1 MBA to full load in clamshell mode and it stays cool to the touch. I think the thermal performance of Apple Silicon really shines in a device like this.
 
  • Like
Reactions: idmean and jdb8167

Unimpeachable

macrumors newbie
Nov 28, 2021
3
0
Boston
Anyone consider displays processing screen painting or data writes via ISRs vs polling menory ports for i/o etc.? ARM processors on general are awful for ISR context switch delays as each interrupt handling (in my limited experience using them on T1E1 Frame Relay and IP adaptation line cards for high speed broadband interfaces on broadband SW dec. - they
are inherently slow - ARMs have “tons of registers”
(50 or more?) to save w at each ISR context switch - so,
it can be —hugely- tine consuming if not polled or ISRs not hit often for displays in this case (no- I am not a video guy) which is why when using ARMS for any significant data (adaptation layers etc.) or primary user data servicing needing high speed throughout if doing wiring or iseer plane data) we always ran in “polled” vs “interrupt node “as interrupt svc processing would thrash CPU performance (and data throughput- n I am only using a few key data points on old broadband line cards we designed w HW team
back in “the day”)
- we used an old “MIPS” processor w ARM
core but I think this is still one of bigger trade offs of going w ARMs and maybe addressed w SW fixes to poll servicing of displays and use of CPU accessible “unified memory” aka RAM but I inferred w iMacs n MacBook Airs that 16g was too little to put on a comen ref designed computer imho ( hard to know but seems like legit issue may exist that’s serious flaw in
SW/HW here (given all the gripes w diff M1s idk?)
- sorry if off base here ..
Use of CPU or GPU idk partition of tasks (just a shot from hip- but fwiw - I was a pretty solid SW HW architect n did lots of code on ARMs vs other CPU types - this was worst aspect of handling voice over IP at T1E1 rates using ARM processors (w DMA n back when DRAMs were 50 nsec or faster at best mostly)
To segment or adapt framed packets from IP to say ATM or frame relay or IP directly mapped onto the STS framing in sONET STS streams need big cache as swaps in out of RAM like onteeeipt context switches were on order of marca to enter ISR b4 any inter tor service was executed making it not starter to run w inteeerots on any significant IO throughout good servicing of data or video display type items n idk about video cards uses or ASICs or video w unified men vs Video memory on molder MACs & MacBooks but rushing a huge architecture changed w so many variants to support seems risky to buy generic 8g MacBook Air (I punted on Costco discounted iMacs w 8g as knew would never keep up w CPU intensive iMovie or other pro level processing stuff) — waiting on M1 Pro w integrated 32g direct menory ref so can access men fast using full 32g to avoid pitfalls of too small “unified menory” -and yes little to know on how M1s vs M1Pro handles higher speed ops if interrupt driven seems like it would use more than one processor ir fixed the ISR register save issues for running isr based CPU n menory intensive ops but been while so not saying 4 sure as be surprised not caught if basic legacy didplay could not be handled by M1 even w 8g
PS i’ll never get another iMac without loads of RAM and direct accessing of full terabyte 4 tera urea 8 terabytes whatevere mem amount I hit w iMac want tu know it’s not bogged down by innate weaknesses in architecture. thx ?
BP
sorry for typos did best can to post quick reply via iPhone (bad vision ) thx BP
 

leman

macrumors Core
Oct 14, 2008
19,521
19,677
A nice, well balanced review. Leaving it plugged in at 100% is bad for the battery over time; consider Aldente which lets you control the max percentage it charges to.


This is not necessarily true. Modern batteries are smart enough to prevent overcharging and will cycle to maximize health.
 
  • Like
Reactions: gradi

ahurst

macrumors 6502
Oct 12, 2021
410
815
2k would shred your eyes though, wouldn't it, given how macOS now handles low-res outputs? I went from a 1440p display to 4K and it was a night and day difference.
Not sure about Monterey, but at least on Mojave with my older 27" iMac you can tweak macOS's font rendering to play nice with non-Retina displays again. You just have to copy/paste some Terminal commands and relaunch Finder.

Even though I've been spoiled a little my 14" MBP's Retina display, I think macOS still looks great at 1440p once font rendering's fixed!
 
  • Like
Reactions: Argoduck

gradi

macrumors 6502
Feb 20, 2022
285
156
A nice, well balanced review. Leaving it plugged in at 100% is bad for the battery over time
I used to hear that advice years ago, but isn't that no longer true? Every laptop I have bought in the last decade controls the battery charging and does stuff to make sure that the battery is not hurt by having it plugged in. Dell, HP, etc. do this so the advice to not leave it plugged in is no longer valid on them.
 

Krevnik

macrumors 601
Sep 8, 2003
4,101
1,312
sorry for typos did best can to post quick reply via iPhone (bad vision ) thx BP

I think the bigger problem is that I can't make heads or tails of the point you are trying to make, but a couple things to point out:

  • ARM has advanced a lot since when I started my career in the early 00s. ARM64 cores are much different beasts than the stuff I started with when the most advanced stuff on ARM was running Windows Mobile, Blackberry OS or Symbian, and thumb was in heavy use. My Raspberry Pi 4 makes anything from the 00s look horrible by comparison. But my M1 Mini makes the Pi 4 look pretty bad too. ARM is covering a rather large performance and power range these days. So problems you run into in one type of ARM SoC don't necessarily apply to others.
  • Apple's ARM designs are not stock, and are generally tailored for the sort of needs that Apple's SoCs have. With the enormous caches and the desktop-class (or leading in the case of the M1 Pro/Max) bandwidth to RAM that Apple has, I'm not sure why you are focused this heavily on register saving during ISRs here.
  • The graphics compatibility issues Apple is facing with the M1 are very likely related to the display controller they choose to integrate. The architecture is that the GPU needs to feed framebuffer data to the controller, but the controller is responsible for the DisplayPort handshake and transmission. Pair that with Apple's heavily reliance on GPU compositing for UI, and the CPU really is just used for configuring the display controller (selecting video modes/etc), not feeding it any data. I wouldn't be surprised if it turned out that the controller had limitations that didn't matter as much for iPhone/iPad use, but start rearing their ugly head when you aren't just hooking it up to a TV or a conference room projector via HDMI. DisplayPort and HDMI displays are all over the place in terms of proper support of spec, so building a reliable controller does take effort. That said, I do think Apple should have gone a bit further afield with their testing.
 

Smoovejayy

macrumors 6502
Jan 20, 2012
380
258
Interesting post. I have an M1 Pro 14” MBP, base just with 16 GB of memory, hooked up to a Dell docking station with three monitors attached and no issues.
 
  • Like
Reactions: Argoduck

CheesePuff

macrumors 65816
Sep 3, 2008
1,455
1,574
Southwest Florida, USA
A nice, well balanced review. Leaving it plugged in at 100% is bad for the battery over time; consider Aldente which lets you control the max percentage it charges to.

This is incorrect, and has been for years.
 

CheesePuff

macrumors 65816
Sep 3, 2008
1,455
1,574
Southwest Florida, USA
Ah, thanks. This is good to know. I had assumed that macOS already was smart about battery charging (In the battery settings, I can see that there is an 'Optimized battery charging' setting that claims it only charges over 80% when it needs to). I might have wrongly assumed that this was all I needed even if I left the laptops plugged in all the time. Looks like it might not be based on your comment. Will definitely have a look at the app you linked, thanks for the tip.
You are correct, you don't need any third party utility. The person you're replying to is incorrect.
 

clevins

macrumors 6502
Jul 26, 2014
413
651
Interesting. I'm running on an 8/512 Air connected to a 24" LG screen and it's fine. HOWEVER, I don't think your 8gig machine is bogged down from VS Code (although Electron is crap...) but perhaps from the softrware you're developing being a high CPU or RAM load. Then again, Activity Monitor would should you what's sucking down RAM so I don't know why that wasn't mentioned... And, of course, what 'lots of browser tabs' means is open to interpretation. I keep hearing of people leaving hundreds of tabs open which is insanity to me.

On the external display... Like i said, I'm fine. Others seem to have issues. IF you've gone in and chosen different ICC profiles etc, well, revert to the default. But that's not the main display issue with the Air and lower end Pro, IMO, it's that you can't connect to 2+ external displays. Obviously, if someone doesn't do this, it's not a problem but them if someone doesn't connect to certain monitors, they won't see the issue OP describes either, so...

Personally, if I were buying again I'd get 16/512 and if I ran into the monitor issues OP lays out, I'd return the Macbook. That's why Apple has a 14 day no questions return policy, after all.
 

ahurst

macrumors 6502
Oct 12, 2021
410
815
You are correct, you don't need any third party utility. The person you're replying to is incorrect.
Is there any good source that explains *why* that's incorrect, and the actual technical reasons behind Li-Ion battery degradation in general? I've heard all sorts of conflicting things about battery health and best practices for years but have never encountered a good resource explaining the underlying technical reasons behind it all, so it's hard to filter out mythology from useful advice.
 

lcubed

macrumors 6502a
Nov 19, 2020
540
326
Anyone consider displays processing screen painting or data writes via ISRs vs polling menory ports for i/o etc.? ARM processors on general are awful for ISR context switch delays as each interrupt handling (in my limited experience using them on T1E1 Frame Relay and IP adaptation line cards for high speed broadband interfaces on broadband SW dec. - they
are inherently slow - ARMs have “tons of registers”
(50 or more?) to save w at each ISR context switch - so,
it can be —hugely- tine consuming if not polled or ISRs not hit often for displays in this case (no- I am not a video guy) which is why when using ARMS for any significant data (adaptation layers etc.) or primary user data servicing needing high speed throughout if doing wiring or iseer plane data) we always ran in “polled” vs “interrupt node “as interrupt svc processing would thrash CPU performance (and data throughput- n I am only using a few key data points on old broadband line cards we designed w HW team
back in “the day”)
- we used an old “MIPS” processor w ARM
core but I think this is still one of bigger trade offs of going w ARMs and maybe addressed w SW fixes to poll servicing of displays and use of CPU accessible “unified memory” aka RAM but I inferred w iMacs n MacBook Airs that 16g was too little to put on a comen ref designed computer imho ( hard to know but seems like legit issue may exist that’s serious flaw in
SW/HW here (given all the gripes w diff M1s idk?)
- sorry if off base here ..
Use of CPU or GPU idk partition of tasks (just a shot from hip- but fwiw - I was a pretty solid SW HW architect n did lots of code on ARMs vs other CPU types - this was worst aspect of handling voice over IP at T1E1 rates using ARM processors (w DMA n back when DRAMs were 50 nsec or faster at best mostly)
To segment or adapt framed packets from IP to say ATM or frame relay or IP directly mapped onto the STS framing in sONET STS streams need big cache as swaps in out of RAM like onteeeipt context switches were on order of marca to enter ISR b4 any inter tor service was executed making it not starter to run w inteeerots on any significant IO throughout good servicing of data or video display type items n idk about video cards uses or ASICs or video w unified men vs Video memory on molder MACs & MacBooks but rushing a huge architecture changed w so many variants to support seems risky to buy generic 8g MacBook Air (I punted on Costco discounted iMacs w 8g as knew would never keep up w CPU intensive iMovie or other pro level processing stuff) — waiting on M1 Pro w integrated 32g direct menory ref so can access men fast using full 32g to avoid pitfalls of too small “unified menory” -and yes little to know on how M1s vs M1Pro handles higher speed ops if interrupt driven seems like it would use more than one processor ir fixed the ISR register save issues for running isr based CPU n menory intensive ops but been while so not saying 4 sure as be surprised not caught if basic legacy didplay could not be handled by M1 even w 8g
PS i’ll never get another iMac without loads of RAM and direct accessing of full terabyte 4 tera urea 8 terabytes whatevere mem amount I hit w iMac want tu know it’s not bogged down by innate weaknesses in architecture. thx ?
BP

that was impossible to read.
 

leman

macrumors Core
Oct 14, 2008
19,521
19,677
Anyone consider displays processing screen painting or data writes via ISRs vs polling menory ports for i/o etc.? ARM processors on general are awful for ISR context switch delays as each interrupt handling (in my limited experience using them on T1E1 Frame Relay and IP adaptation line cards for high speed broadband interfaces on broadband SW dec. - they
are inherently slow - ARMs have “tons of registers”
(50 or more?) to save w at each ISR context switch - so,
it can be —hugely- tine consuming if not polled or ISRs not hit often for displays in this case (no- I am not a video guy) which is why when using ARMS for any significant data (adaptation layers etc.) or primary user data servicing needing high speed throughout if doing wiring or iseer plane data) we always ran in “polled” vs “interrupt node “as interrupt svc processing would thrash CPU performance (and data throughput- n I am only using a few key data points on old broadband line cards we designed w HW team
back in “the day”)
- we used an old “MIPS” processor w ARM
core but I think this is still one of bigger trade offs of going w ARMs and maybe addressed w SW fixes to poll servicing of displays and use of CPU accessible “unified memory” aka RAM but I inferred w iMacs n MacBook Airs that 16g was too little to put on a comen ref designed computer imho ( hard to know but seems like legit issue may exist that’s serious flaw in
SW/HW here (given all the gripes w diff M1s idk?)
- sorry if off base here ..
Use of CPU or GPU idk partition of tasks (just a shot from hip- but fwiw - I was a pretty solid SW HW architect n did lots of code on ARMs vs other CPU types - this was worst aspect of handling voice over IP at T1E1 rates using ARM processors (w DMA n back when DRAMs were 50 nsec or faster at best mostly)
To segment or adapt framed packets from IP to say ATM or frame relay or IP directly mapped onto the STS framing in sONET STS streams need big cache as swaps in out of RAM like onteeeipt context switches were on order of marca to enter ISR b4 any inter tor service was executed making it not starter to run w inteeerots on any significant IO throughout good servicing of data or video display type items n idk about video cards uses or ASICs or video w unified men vs Video memory on molder MACs & MacBooks but rushing a huge architecture changed w so many variants to support seems risky to buy generic 8g MacBook Air (I punted on Costco discounted iMacs w 8g as knew would never keep up w CPU intensive iMovie or other pro level processing stuff) — waiting on M1 Pro w integrated 32g direct menory ref so can access men fast using full 32g to avoid pitfalls of too small “unified menory” -and yes little to know on how M1s vs M1Pro handles higher speed ops if interrupt driven seems like it would use more than one processor ir fixed the ISR register save issues for running isr based CPU n menory intensive ops but been while so not saying 4 sure as be surprised not caught if basic legacy didplay could not be handled by M1 even w 8g
PS i’ll never get another iMac without loads of RAM and direct accessing of full terabyte 4 tera urea 8 terabytes whatevere mem amount I hit w iMac want tu know it’s not bogged down by innate weaknesses in architecture. thx ?
BP

Apple uses custom interrupt handling scheme for most stuff. Those interrupts are extremely lightweight and rely on hardware banked registers, the overhead is close to zero. The overall picture of course is more complicated since there are likely multiple processors involved in display stuff. But Apples implementation is generally optimized for extremely low latency. Your experience with old low-end ARM CPUs doesn’t apply here.

The problem, as I understand it, that displays are notoriously hard to do because they almost never follow the spec properly. There are tons of bugs and errata, and your display controller has to deal with all these crappy implementations. Other GPU makers have been dealing with this stuff for decades and have robust implementations, Apple is a newcomer here (it’s their first GPU to support third-party displays), so the initial implementation still had some issues.
 

gradi

macrumors 6502
Feb 20, 2022
285
156
Other GPU makers have been dealing with this stuff for decades and have robust implementations, Apple is a newcomer here (it’s their first GPU to support third-party displays), so the initial implementation still had some issues.
How many years have there been Mac Minis and Mac Pros? When did Apple first allow a non-Apple display? I may be mistaken, but I thought it was years ago. I am not an expert on Apple history going back a long time though.
 

leman

macrumors Core
Oct 14, 2008
19,521
19,677
How many years have there been Mac Minis and Mac Pros? When did Apple first allow a non-Apple display? I may be mistaken, but I thought it was years ago. I am not an expert on Apple history going back a long time though.

These were not Apple-made GPUs and display controllers.
 
  • Like
Reactions: Argoduck

gradi

macrumors 6502
Feb 20, 2022
285
156
Okay, I see. Well, I have my fingers crossed that when the new Mac Mini and Macbook Air finally come out that Apple (in the top 4 richest companies in the world - 2021 revenue $366b, profit $163b) can somehow find the money and employees (154k employees) to fix the problems. :) Especially since being such a big, high profile, wildly successful company they can easily hire away any talent they need. We aren't talking about a garage operation anymore. :)
 

leman

macrumors Core
Oct 14, 2008
19,521
19,677
Okay, I see. Well, I have my fingers crossed that when the new Mac Mini and Macbook Air finally come out that Apple (in the top 4 richest companies in the world - 2021 revenue $366b, profit $163b) can somehow find the money and employees (154k employees) to fix the problems. :) Especially since being such a big, high profile, wildly successful company they can easily hire away any talent they need. We aren't talking about a garage operation anymore. :)

Some things are not easy to do no matter how many resources you have. It’s more of a question of time. But it seems that Pro chips are already doing much better in respect to compatibility. At my rate, we have multiple M1 (non pro/max) machines and so far none of our employees have reported issues with the external monitors they use.
 
  • Like
Reactions: Marty_Macfly

gradi

macrumors 6502
Feb 20, 2022
285
156
Okay, I see. Well, I have my fingers crossed that when the new Mac Mini and Macbook Air finally come out that Apple (in the top 4 richest companies in the world - 2021 revenue $366b, profit $163b) can somehow find the money and employees (154k employees) to fix the problems. :) Especially since being such a big, high profile, wildly successful company they can easily hire away any talent they need. We aren't talking about a garage operation anymore. :)
I forgot to mention that Apple is valued at $2.79t. They can and do get just about anyone they want. And they can do just about anything they want. The key is the word "want" though. :) Working with various monitors is not a new, cutting edge field. It is a well trod field for decades.
 

gradi

macrumors 6502
Feb 20, 2022
285
156
Some things are not easy to do no matter how many resources you have. It’s more of a question of time. But it seems that Pro chips are already doing much better in respect to compatibility. At my rate, we have multiple M1 (non pro/max) machines and so far none of our employees have reported issues with the external monitors they use.
Yes, I am looking forward to and hoping that monitor and Bluetooth problems are fixed in the new computers coming soon.
 

archi penko

macrumors regular
Nov 6, 2007
174
210
Yeah, 8gb for sure was not enough. I was not expecting it to be even before I bought it, but the reason I did go for the 8gb version first was that I wanted to see if the hype about the unified memory created in the initial reviews had any truth to it and because I was going to buy 2 macbooks anyway (one for personal use and one for work) and I could switch the 8gb version for my personal use which I did.
Yeah.. this whole rhetoric that "unified memory is different" turns out... ummm... like maybe if you are an average consumer. But developers, No way. It's just like the previous (intel) paradigm that 16GB minimum is necessary.
 

leman

macrumors Core
Oct 14, 2008
19,521
19,677
Yeah.. this whole rhetoric that "unified memory is different" turns out... ummm... like maybe if you are an average consumer. But developers, No way. It's just like the previous (intel) paradigm that 16GB minimum is necessary.

Memory is memory, who was ever saying anything different? Sure, in memory starved situations ARM Macs will perform better but you still need to evaluate your needs and buy accordingly.
 
  • Haha
Reactions: mi7chy
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.