[HN Gopher] Is Apple Silicon Ready?
___________________________________________________________________
Is Apple Silicon Ready?
Author : caiobegotti
Score : 232 points
Date : 2020-11-20 20:24 UTC (2 hours ago)
(HTM) web link (isapplesiliconready.com)
(TXT) w3m dump (isapplesiliconready.com)
| everyone wrote:
| Honest question. Why are people here so excited about this?
|
| What I've gathered via osmosis here about Apple silicon is. 1. It
| will only be in macs, you cant buy the chips or mobos to build
| your own machine. 2. Theyre very energy efficient. 3. Their
| performance is okish.
|
| Doesnt really seems earth shattering.. Like, if they were a super
| low energy alternative to the duopoly of amd or intel, that would
| be pretty cool. But if u buy a mac nowadays, its like a console
| with set stuff in it that u cant change or upgrade.. Now that
| stuff will be improved / updated in newer macs, does that not
| happen regularly anyway?
|
| EDIT: Several people saying the performance is amazing.. Can u
| link me to some benchmarks? The only numbers I can find are
| these. "In Geekbench 5, the A14X yields a single-core score of
| 1,634 and rakes in 7,220 in the multi-core test."
|
| These are very low scores, like, my desktop gets many times
| that.. My old work low/mid level laptop from 4 years ago had 3000
| single core and 11600 multi-core score.
| djrogers wrote:
| > But if u buy a mac nowadays, its like a console with set
| stuff in it that u cant change or upgrade
|
| That's how _most_ people buy and treat computers. We 're the
| weird ones who upgrade them and keep using them for 9 years, 3
| SSDs, and 4 RAM bumps.
|
| > Their performance is okish
|
| Nope - not even close to merely 'okish'. These first devices
| (which were clearly targeted as the cheapest, lowest-end
| devices Apple sells) outperform the vast majority of PCs (and
| Macs) sold today, and not just by a tiny bit. Look at some of
| the reviews by developers - in many cases their existing Intel
| apps and games are running better under Rosetta
| emulation/bridge/whatever you want to call it then they did on
| native Intel Macs. Compile times for a $999 MacBook Air beat a
| $6k+ iMac Pro by 30-40%. Games getting better frame rates under
| Rosetta than they did on native intel boxes.
|
| The list goes on - these chips are beasts, and this is only the
| beginning. The high-performance versions of these will make
| people who bought 8/10/12 core iMac Pros recently weep.
| macintux wrote:
| > Their performance is okish
|
| That seems an understatement. The first version, targeted at
| (for Apple) low-end devices, is much faster than most x86-64
| based computers.
| happycube wrote:
| And it's an absolute IPC monster. At 3.2ghz it keeps up with
| high 4.x-ghz x86 cores. It's been a long time since
| anything's jumped like that from a good starting point.
| _ph_ wrote:
| It seems your are comparing geekbench numbers of different
| geekbench tests. Geekbench 4 would give much higher numbers. As
| I understand it, the M1 has the highest single core result of
| all processors, and considering it only has 4 high performance
| cores, it has astonishing good multicore scores.
| acwan93 wrote:
| "Windows" should be on there too:
| https://www.macrumors.com/2020/11/20/craig-federighi-on-wind...
| rblatz wrote:
| I got an SSL error on this page. This is the second time that's
| happened today. And I can't remember this happening on my phone
| in the past. Is this something on my end or are others seeing it
| too?
| jamesbfb wrote:
| OpenSSL is partially working on M1 it seems... :)
| loeg wrote:
| SSL on the site is fine for me. It is a Let's Encrypt cert, if
| that matters.
| rblatz wrote:
| I was seeing a mcafee cert... wonder if Centurylink is
| playing games.
| GeneralTspoon wrote:
| Very cool idea! Useful for evaluating whether or not to order a
| new MBP now or later.
|
| One minor bug - Sketch shows under all apps, but not under design
| apps (I thought it was missing altogether because I didn't see it
| under Design).
| [deleted]
| uvesten wrote:
| Weird that node is listed as not running under Apple Silicon,
| since I've been running node 15 compiled for Apple Silicon
| without problems for a while now :)
| dawnerd wrote:
| Did you compile it or is there a prebuilt avail?
| ibraheemdev wrote:
| Related: https://doesitarm.com/
| saagarjha wrote:
| Sublime Text seems to be incorrectly marked as having native
| builds: https://doesitarm.com/app/sublime-text/
| loeg wrote:
| Seems a bit dubious to claim M1 isn't ready for web browsers when
| all of Chrome, Firefox, and Safari have ARM-optimized green
| checkmarks. Vivaldi, Brave, and Microsoft Edge -- who cares?
| Similarly, the "Finance" tab is 100% green checkmark and also
| says "Not yet!"
| ChuckMcM wrote:
| This web site feels to me like the Intel ARM knock-off websites
| that kept equating "the full internet experience" to "running
| flash" which was something Apple was studiously not doing on
| iOS.
|
| Bad memories aside, tracking what worked before and is in
| progress to working again, is useful service. Back during the
| 68K -> PowerPC switch this kind of information was very
| helpful.
| prh8 wrote:
| Even worse looking at the design tab. All but Sketch and
| Pixelmator Classic have optimized versions, and both of those
| work via Rosetta2
| nottorp wrote:
| Pixelmator Classic is being abandoned? I bought it but use it
| far too rarely to even think about buying Pixelmator Pro or
| whatever they're calling the latest version now.
| macintux wrote:
| I felt the same, but when I saw they offer an upgrade price
| (by bundling it with classic for a hefty discount) I
| decided it was worth supporting a good Mac app even if I
| rarely use it.
| nottorp wrote:
| Oh, 50% discount. I might bite. Sad thing is they had no
| way to tell their app store customers about this (at
| least not the very infrequent users like me), and I had
| to find out from a random HN discussion.
| macintux wrote:
| And I only discovered it indirectly through Gruber:
| reading about ML Super Resolution on Daring Fireball
| intrigued me enough to go check out the price on Pro.
|
| https://daringfireball.net/linked/2020/11/19/pixelmator-
| pro-...
| gilrain wrote:
| Edge has a higher usage share of the desktop market than
| Firefox.
| [deleted]
| jki275 wrote:
| Edge? As a Mac user for many years, I can't recall any time I
| might have even considered using Edge for anything. I guess
| they ported it to Mac not too long ago, but who cares?
| bee_rider wrote:
| Same, but in Windows. (Well, Linux is my daily driver, but
| _when_ I boot into Windows, Firefox is still there).
| loeg wrote:
| Do you have a source? The first example I found is a bit
| dated (2016), but contradicts that claim: https://zdnet1.cbsi
| static.com/hub/i/r/2016/06/18/77931904-cb...
|
| This source (2020) also claims that global Firefox use is
| about 4% while Edge is under 3%, contradicting the claim
| (even including non-MacOS devices):
| https://gs.statcounter.com/
|
| Another 2020 source gives 5.5% to Firefox and 0.5% to Edge on
| MacOS, also contradicting the claim: https://netmarketshare.c
| om/?options=%7B%22filter%22%3A%7B%22...
| gilrain wrote:
| Naturally it increased after it switched to Chromium and
| became the Windows default.
|
| Choose your own source:
|
| https://duckduckgo.com/?q=edge+surpasses+firefox
| loeg wrote:
| Apple M1 silicon will mostly or entirely run MacOS, not
| Windows.
| tester756 wrote:
| You never know - would you say that 20 years ago that
| very significant push for Linux will be done by
| Microsoft?
| bradly wrote:
| This conversation is around whether Apple Silicon is
| ready. In that context, Edge is far behind Firefox.
| mabedan wrote:
| On the Mac? Sounds unlikely
| rconti wrote:
| Yeah, I hate to throw anecdata around, but I didn't even
| know it existed for the Mac. Is Edge 'built in' to some
| other product, so it scores points on a technicality?
| apsdsm wrote:
| On mac? No.
|
| https://netmarketshare.com/browser-market-
| share.aspx?options...
| dsissitka wrote:
| That's for May 2019. Here's October 2020:
|
| https://bit.ly/2IQgrix
|
| In the last month Edge went from 0.67% to 2.09%.
| May 2019 Firefox 6.52% Edge 0.03%
| September 2020 Firefox 5.89% Edge 0.67%
| October 2020 Firefox 5.75% Edge 2.09%
| GordonS wrote:
| Huh, I had no idea Edge was even available on non-Windows
| platforms!
| wayneftw wrote:
| It's coming for Linux too [0].
|
| Unfortunately, they'll be removing the webRequest API [1]
| which was the only reason I would have wanted to use it.
| This will happen probably whenever Google deprecates
| Manifest v2 and Manifest v3 becomes the only interface
| for extensions, which will stop uBlock Origin from
| working.
|
| Other than that, when I tried Edge it didn't work
| perfectly on every site. But, it will be nice to have
| another non-Google browser to choose from.
|
| [0]
| https://blogs.windows.com/msedgedev/2020/10/20/microsoft-
| edg...
|
| [1] https://www.theregister.com/2020/10/15/microsoft_adop
| ting_go...
| jane128 wrote:
| That was a glitch, we've fixed it.
| sbuk wrote:
| I thought that when I saw the site. Surely it should be "Are
| these software developers ready?". It's not as snappy or click-
| baity though. The truth is that this is a really useful site,
| _despite_ its name.
| totalZero wrote:
| Brave is Chromium, and over ten million people use it every
| month.
|
| Also, Firefox isn't natively supported outside of beta.
| eugeniub wrote:
| To be fair, I've been having serious trouble with Firefox. The
| public version (Rosetta 2) has been freezing up on me every
| third page load, and the nightly version (ARM compiled) has
| similar issues. But I'm optimistic that these issues will be
| resolved soon.
| Aperocky wrote:
| I'm using safari until Firefox gets ready. I have pihole so
| I'm mostly unaffected by ads except for YouTube videos - I
| was reminded that YouTube had ads!
|
| Safari developer mode is actually not that bad. The only
| thing that's really awful is the complete lack of (useful)
| plugins.
|
| I was also able to run my web project without any issues with
| ARM binary.
| soapdog wrote:
| I'm running the native beta version and it has been running
| fine all day.
| [deleted]
| loeg wrote:
| That's a good argument for Firefox not getting a green
| checkmark. Taking as a given that the site operators have
| decided to give Firefox a green checkmark, I think my
| complaint makes sense.
| zachberger wrote:
| Sorting on the columns with checkboxes seems broken.
| kowlo wrote:
| Great idea, thanks for putting it together. Ordering by "Apple
| silicon optimised" doesn't seem to work as I expected it. Is it a
| bug?
|
| Great to see Office 2019 (not 365) works - was putting off
| picking up a license for that reason.
| vetinari wrote:
| Afaik only 365 and 2021 will be ARM native and 2019 won't be.
|
| Also be aware that unlike the Windows Office, Mac Office is
| supported only for 5 years and for the 2019 release, 2 years
| are already gone (it will be supported till Oct 2023, Mac
| Office 2016 is already unsupported since last October).
| tosh wrote:
| this is a sheet for tracking game compatibility and performance
| (including FPS, settings, system specs and sources) that I set up
| yesterday
|
| https://docs.google.com/spreadsheets/d/1er-NivvuIheDmIKBVRu3...
|
| first results are impressive, there are reports of games that
| were unplayable on the 2020 Intel MacBook Air that now run well
| on the M1 MacBook Air
| Traster wrote:
| I like the tick next to Firefox and you mouse-over and it says
| "Beta".
| suyash wrote:
| Missing 'Java' under programming languages / runtime. Last I
| heard it's being worked upon.
| gmaster1440 wrote:
| Table suggests that Docker can run under Rosetta 2, but the
| Docker blog post that it links to suggests Rosetta is not enough.
| Can someone confirm if it's actually possible to run Docker using
| Rosetta on M1 Macs?
| filmgirlcw wrote:
| It's not. The client might be but the actual VM is a total mess
| right now.
| [deleted]
| benatkin wrote:
| The Docker client works. It is useful, but it's not the same as
| Docker working.
| rsanheim wrote:
| It isn't, at least not in any way most developers use it. You
| cannot use docker to start a *nix container on a mac, whether
| its for a arm or x86 OS.
|
| some context:
| https://www.reddit.com/r/docker/comments/jxc1ge/docker_and_a...
| speedgoose wrote:
| I guess the Docker client works, but you still need a GNU/Linux
| running Docker. It's usually a VM on the same host but it
| doesn't have to be.
| kccqzy wrote:
| It might be that you can use docker-machine to set up a remote
| Docker machine and then use a native docker CLI to control that
| remote instance.
| hit8run wrote:
| Can you tell me if Ruby is ready?
| sohooo wrote:
| In the meantime, you could use the version shipped with macOS:
| > ruby -v ruby 2.6.3p62 (2019-04-16 revision 67580)
| [universal.arm64e-darwin20]
| WA9ACE wrote:
| I installed arm ruby via arm homebrew using `brew install ruby`
| and it's working. Anything requiring the ffi gem will not
| compile at the moment though.
| Grustaf wrote:
| Is this sponsored by spotify or why are they up at the top? How
| many people use spotify on a computer?
|
| In any case, the domain nam is incorrect. It should be
| "isitapplesiliconready". The chips are clearly ready, it's just
| that some developers haven't recompiled their apps for it yet.
| Ninn wrote:
| > In MEA and North America we see the highest preponderance of
| desktop Spotify listening, on 46%, with MEA also reporting the
| lowest mobile listening figure of 56% (compared to North
| America's 61%).
|
| https://www.businessofapps.com/data/spotify-statistics/
| Karawebnetwork wrote:
| It's sorted by "last update".
| dblooman wrote:
| Lots of people use Spotify desktop app....
| piazz wrote:
| Anybody using it with VSCode? Appreciable perf difference?
| emadabdulrahim wrote:
| It works fine on my M1 MBP. Runs intel though not ARM. Which I
| think is a mistake in the website showing it doesn't work on
| Rosetta 2
| LolWolf wrote:
| Agreed on mistake. (Rosetta 2 version runs fine, afaict.)
|
| I haven't stress tested the ARM version, but it is the one
| I'm currently using and I haven't had any issues so far.
| EugeneOZ wrote:
| Maybe not 100% yet, but it moves incredibly fast to this goal.
| tlrobinson wrote:
| I'll gladly let you fine folks sort out this mess, and I'll check
| back in next year. Thanks!
|
| Seriously though, what's the plan for Docker? Will all containers
| need to be built for ARM or will Rosetta 2 be able to run Docker
| in an x86 VM?
|
| Homebrew is my other benchmark.
| mandragon wrote:
| Unrelated to the link but related to Apple's CPU foray:
|
| Any thoughts or info on the security implications of a first
| generation CPU design? Is it safe to assume that a design focused
| on cutting edge performance may have compromised on security in
| some form? Does the fact that this is first gen indicate
| opportunity for hackers to discover low hanging fruit
| vulnerabilities possibly to the benefit of nation state or
| private actors?
|
| I feel like the long term path for silicon will converge on
| extreme compartmentalization of general purpose computing
| hardware inside chips, designed from the ground up to achieve
| physical process isolation purpose built per task, with highly
| secure hardware IPC all on a single high perf die.
|
| Interested to learn what Apple has done to build a "more secure"
| CPU design. edit: A quick web search yields relevant results on
| this topic already, e.g. work by Chinese based Tencent Security.
| stouset wrote:
| This isn't a first-generation CPU design. It's just another
| iteration of the ARM chips that Apple has been building since
| acquiring PA Semi 12 years ago.
| mandragon wrote:
| Corrected: First generation chip purpose-built for Mac.
| happycube wrote:
| ... the first one that _shipped_. I suspect they 've been
| building things like the A12X mini DTK for a few years now.
| nicoburns wrote:
| > I suspect they've been building things like the A12X
| mini DTK for a few years now.
|
| They have. And they've been shipping the chips in iPads.
| mandragon wrote:
| Apple's site says it is their first "chip" designed
| specifically for Mac:
|
| https://www.apple.com/mac/m1/
|
| I may be making a few semantical errors, regarding "first
| gen", et al
| nicoburns wrote:
| They're not technically lying, but you're better off
| thinking of it as 90% their iphone/ipad chip with a few
| tweaks for mac rather than a completely new design.
| stouset wrote:
| It's not purpose-built for Mac. All available indications
| are that it's the same chip as they've been shipping in
| devices for years, just "harder better faster stronger".
|
| This is barely different than AMD releasing yet another
| line of Zen chips or Intel shipping a new Core i9.
| chadlavi wrote:
| isn't this more like "is this app ready for apple silicon"?
| loeg wrote:
| It is exactly that.
| jane128 wrote:
| it's more like "is Apple silicon ready to be used by x?"
| mortenjorck wrote:
| The title is an odd construction, and did throw me off at
| first.
|
| "Is Apple Silicon ready?"
|
| Ready for what? Apple Silicon is the fixed quantity in this
| equation, while the software is what is changing to be ready
| for Apple Silicon, so the construction feels backward. An
| alternate construction could be "Is _it_ Apple Silicon-ready, "
| which I suppose one could stretch the title to read as a
| shortening of, but it's still awkward either way.
|
| All that said - this is the best UI I've seen yet for an Apple
| Silicon compatibility list, confusing title or not.
| wgx wrote:
| I wonder why Google didn't get File Stream ready?
| xyst wrote:
| It's amazing how fast applications are being transitioned to
| apple silicon. If this was any other company introducing a new
| architecture, I am sure adoption wouldn't have been this fast.
| johnklos wrote:
| Silly title. Apple Silicon is obviously ready. Are these software
| packages ready is the question.
| glup wrote:
| I totally thought this was going to be one of those static sites
| with a single answer in h1 fonts ("Is it snowing in San
| Francisco?" "No") but instead this is much more useful.
| DCKing wrote:
| It really seems that nearly everything that's not a full native
| ObjC/Swift stack or is not a web browser (or based on one, like
| Electron) is not ready yet right now. It really seems Apple did
| not care enough to get especially golang and Rust stuff stable
| for their hardware release. I can't escape the impression that
| they didn't really shower the wider ecosystem in DTKs and
| software support, although I'd be happy to be proven wrong there.
|
| Oh well, at least Rosetta2 seems to be working really well - you
| will be able to run a lot of software you need rather well
| despite not to the fullest potential. The execution on Rosetta2
| is really good and that's important. But I think it does go to
| show that the "Pro" in "Macbook Pro 13" does not mean all that
| much. At least not if they're going to ship with the majority of
| pro software not being native, many popular developer toolchains
| still months to be ready, and very limited I/O and RAM options.
| The Macbook Air and Mac Mini I fully get for the first releases
| on new hardware, but the Macbook Pro 13 really feels odd in this
| lineup if the word Pro is supposed to mean anything.
| filmgirlcw wrote:
| Putting aside the fact that the "Pro" label hasn't really meant
| professionals for over a decade (I would say you can see the
| beginning of the distinction becoming "plus" rather than "pro"
| with the unibody MacBook/MacBook Pro from 2008 and 2009), I
| think you misunderstand how the DTK program works.
|
| Anyone could request one and I'm not aware of any developer I
| know, no matter how small, not being able to buy one from
| Apple. I was able to get one and I don't even have anything in
| the App Store at the moment. As for Apple gifting them to OSS
| projects, I mean, I guess that would be nice, but frankly the
| corporate stewards of Go and Rust can buy their own, just as
| Electron and others did. I imagine some Debian people may have
| been given loaner machines or stuff gratis, given the custom
| Debian build proof of concept at WWDC, but I have no insight
| into that.
|
| The real challenges with AS are going to be for anything that
| uses virtualization or lots of lower level libraries that need
| to be compiled for ARM64 and to be honest, that was clear to
| anyone who watched any of the Apple Silicon sessions at WWDC
| and read the accompanying documentation.
|
| You're exactly right that many popular developer toolchains
| aren't ready right now. Most of us didn't expect that and some
| of us were screaming that loudly (and getting yelled at and
| called haters by fanbois even though we almost exclusively use
| Macs and Apple hardware) to prepare people for exactly this
| reality. The support will come over time and it's also clear to
| me at least, that the way at least some stuff works, might not
| be as nice as the way it was under Intel or even PPC, just
| because of changing priorities with macOS, and we'll need to
| come to terms with that too.
|
| You'll notice the 13" MacBook Pro that was replaced in the
| lineup, a device I've always found odd period (just get a
| MacBook Air), is the tweener device with two ports, and
| originally , no Touch Bar. This isn't the much more powerful
| 13" MacBook Pro that got a big update on Intel alongside the
| fixed keyboard this May. This is the one that got a fixed
| keyboard but was still running a two year old 8th-gen Intel
| processor, AKA, the MacBook Pro you shouldn't buy and should
| really just get a MacBook Air instead (the Intel MacBook Air
| refresh was running a newer processor than the two-port MBP).
|
| Honestly, this is a huge boon for non Apple Silicon ARM64
| projects and libraries because a lot of developers won't do
| this sort of work for Raspberry Pi or Pinebook or any number of
| ARM boards, but they will for Apple. And that will trickle
| downstream.
| leokennis wrote:
| Well...when was the last time the entry level smallest MacBook
| Pro was really pro? If it ever was?
|
| Let's face it, that MacBook Pro is mainly there to make their
| buyers _feel_ pro, while not really providing performance
| benefits over the Air.
|
| It's like you have the stock car (MacBook Air), the "sports"
| version of that car which just has some stripes sprayed on and
| a red colored gear shift knob (entry level MacBook Pro), and
| then the actual race version of that car which has a tuned
| engine etc. (other MacBook Pro's).
| johncolanduoni wrote:
| I don't think whether it's "pro" or not is well defined
| enough to litigate over, but the reviews have made clear the
| M1 air throttles after a few minutes of max CPU load while
| the Pro doesn't, which seems like a big performance
| difference to me.
| filmgirlcw wrote:
| I mean, some tests shows that the throttling takes six or
| seven minutes of pure CPU hammering to turn on. For some
| tasks, I agree, that can make a difference -- but in the
| context of these devices with these specs, I just don't see
| if. Like, if you need that much sustained CPU usage without
| throttling, I don't think the M1 is the right chipset for
| you. The M1X or M3 or whatever they call the ones that they
| put in the actual high-end machines and not the entry level
| stuff seems more apt.
|
| The biggest advantage I see between the Pro and the Air,
| based on everyone I've talked to with both, is battery
| life. That might be worth the $200 or $250 depending on
| your storage configuration.
| thebean11 wrote:
| > while not really providing performance benefits over the
| Air
|
| This is true now, but was it true before moving away from
| Intel?
| derefr wrote:
| No, but that wasn't so much Apple's choice as it was a
| consequence of Intel making promises they couldn't keep.
|
| For a while, the Air has been the form-factor Apple
| expected to be getting entry-level-MBP perf from, and
| requesting chips from Intel to satisfy that; and for a
| while now, the response from Intel has been a chip that
| thermal-throttles so hard in that form-factor that the
| performance has bombed it down to a lower class of
| computer.
|
| The base-model MBP, then, has been Apple's compromise: it's
| the result of them taking those chips that were supposed to
| be just fine running in an Air, and giving them enough
| chassis and fans to make them perform the way Intel
| originally promised they would.
|
| In other words, the base MBP is "a MacBook Air" in terms of
| what performance Apple targeted the Air to achieve each
| gen; and the Air itself is the pretty design Apple's IxD
| dept put out in anticipation of that target, mated to an
| altogether-worse processor in order to get it out of the
| gate.
|
| Now that Apple has a chip with actual thermal headroom,
| this duality will go away. You'll get base-MBP perf in Air
| chassis, and these overlapping categories will merge into
| one.
| vetinari wrote:
| > and for a while now, the response from Intel has been a
| chip that thermal-throttles so hard in that form-factor
| that the performance has bombed it down to a lower class
| of computer.
|
| Are we talking about the same computer, where the fan is
| not even thermally connected with the CPU heatsink[1]?
| That's Apple's fsckup, not Intels.
|
| [1] https://www.youtube.com/watch?v=iiCBYAP_Sgg
| filmgirlcw wrote:
| I would argue yes. The two port MacBook Pro, in my opinion,
| was launched to replace the MacBook Air when it came out in
| 2016 [1]. It didn't have a Touch Bar, for example, and
| based on my conversations with Apple at that time, I feel
| very strongly it was meant to replace the Air in the lineup
| (the 12" MacBook was another attempt to replace the Air,
| that one I think we can blame a lot more of on Intel).
| Apple never told me this outright, but that was absolutely
| the impression I got about how it was being positioned
| against the MacBook Pro with four ports and it was how I
| reviewed the first release of that model.
|
| For a variety of reasons, it didn't work. Not only was the
| price higher, the port selection (just two TB3s at a time
| when the industry hadn't moved en masse to USB-C, remember,
| this was four years ago) was really limiting. And of
| course, the keyboard drama.
|
| It is my contention, though I have no proof, that Apple
| didn't want to release the redesigned Retina MacBook Air in
| 2018, but had to based on continued sales of the older
| model and the lack of love for the Touch Bar free MacBook
| Pro. (Recall, even after the redesign, Apple was still
| selling a Broadwell-based MacBook Air, technically into
| 2019. That was essentially the same MacBook Air that was
| first released in March 2015.)
|
| Once the MacBook Air was redesigned, the two-port MBP never
| made any sense, even with the re-added Touch Bar. In fact,
| every single year, when I participate in Jason Snell's
| Apple Report card [2], I comment on this weirdness in the
| lineup. I don't think the two-port MacBook Pro needs to
| exist.
|
| [1]: https://gizmodo.com/the-pricey-touch-bar-free-macbook-
| pro-wa... [2]: https://sixcolors.com/tag/reportcard/
| kitsunesoba wrote:
| > I can't escape the impression that they didn't really shower
| the wider ecosystem in DTKs and software support, although I'd
| be happy to be proven wrong there.
|
| From all appearances, practically anybody who applied for a DTK
| got one so in many cases I would take lack of a green checkmark
| as the dev not applying for a DTK.
| egsmi wrote:
| Or got a DTK but didn't get around to using it. I know I
| stopped counting how many unused eval boards I have...
| ogre_codes wrote:
| > I would take lack of a green checkmark as the dev not
| applying for a DTK.
|
| Not entirely true. A lot of software is simply hard to port
| or has a lot of dependencies which need to be ported.
|
| A lot of developers already have a full plate and porting to
| a new platform is low on their list of priorities. As the
| user-base expands, it will move up on their list of
| priorities.
| saagarjha wrote:
| I got a DTK and the app I said I would use it for still isn't
| ready; it just means that the process is complex for some
| apps.
| stingraycharles wrote:
| Isn't this the modus operandi with a lot of stuff Apple does --
| release new things that the market hasn't quite adapted to yet,
| and let the market catch up?
|
| Removal of the audio jack in for headphones comes to mind.
| josephg wrote:
| There is a range of machines in the MacBook Pro lineup. They
| only replaced their lowest spec MacBook Pro with the new M1
| machine. And the lower model always had 2 thunderbolt ports and
| 16 gigs of lpddr4 ram maximum. The "higher end" models still
| have Intel chips, and when they get replaced with Apple silicon
| we'll see higher specs and by that point better compatibility
| from compilers and whatnot.
|
| This is the first, and worst / "least pro" Apple silicon
| machine Apple will ever make. But it absolutely won't be the
| last.
| nindalf wrote:
| > if you're going to ship with the majority of pro software not
| being native
|
| Shipping this gets M1 hardware in the hands of developers who
| can then use it to test their software. You mentioned Rust,
| which is currently blocked on getting hardware hooked up to CI
| (https://github.com/rust-lang/rust/issues/73908)
|
| Also, such an impressive release of hardware shows third party
| devs that Apple is serious about transitioning, and doing so
| quickly. Before this laptop was released we didn't know what
| the performance delta would be.
| ogre_codes wrote:
| It's early days, but so far this transition has gone massively
| better than any previous similar processor transition. The
| PowerPC->Intel transition was much worse.
|
| Not sure what you expected, but having seen previous
| transitions, this is smooth as butter. If you are a Pro, you
| _know_ that jumping onto a platform early is fraught with
| potential gotchas.
|
| > the Macbook Pro 13 really feels odd in this lineup if the
| word Pro is supposed to mean anything.
|
| There has always been a bit of a blurry line between pro and
| non-pro Apple products. This model year it means just as much
| as it has on many other model years. Apple left the "higher
| end" Intel builds in their product line to address the needs of
| developers who want 32GB or RAM or many other configurations.
|
| This Pro is exactly the machine that the developers porting Go
| or Rust over to MacOS will likely be using.
| DCKing wrote:
| I don't believe I'm saying, suggesting or hinting that this
| is not going smoothly for a transition like this. If you read
| my comment as somehow saying this transition is not going
| smoothly, I'd like to understand why you'd think that and
| I'll update my comment.
|
| What I'm commenting on is that anything that is not already
| completely bought into Apple's stack is not there yet, and
| that reveals where Apple's priorities are. Anything that's
| cross platform or depends on cross platform components needs
| to play catch up now. It's _fine_ if they have priorities
| though?
| ogre_codes wrote:
| > What I'm commenting on is that anything that is not
| already completely bought into Apple's stack is not there
| yet, and that reveals where Apple's priorities are.
|
| Not remotely.
|
| It reveals who priorities updating their software to
| Apple's new platform. Apple can't control who ports a given
| piece of software to their new platform and how quickly it
| gets done. The surface area is too large.
|
| All Apple can do is get the tools out there for the people
| who are doing the porting.
|
| Most likely Go and Rust aren't ported simply because
| porting languages is hard and time consuming.
|
| > Anything that's cross platform or depends on cross
| platform components needs to play catch up now.
|
| I'm not sure why this is remotely surprising or noteworthy.
| Apple needed Xcode, Swift, and Objective C running in order
| to build MacOS. There would not be a platform to try to
| port to if Apple's toolchain wasn't working _prior_ to day
| 1.
|
| Rust, Go, React Native, are all by necessity going to be
| rely on Apple's toolchain to run on Apple, so by nature
| they take longer to build.
| DCKing wrote:
| > I'm not sure why this is remotely surprising or
| noteworthy.
|
| It might not be for you, but then I'm curious why it's
| noteworthy enough to have two layers of comments about
| it. If you don't want to talk about that then by all
| means let's not.
|
| Apple has priorities, and these have results. I think it
| would be interesting to talk about that, as Apple could
| have invested time and money in getting some more things
| going (I'm thinking virtualization and Docker related
| things especially - you know, the stuff they demoed at
| WWDC!), but they didn't. _It 's fine_ they didn't, but we
| can still talk about that can't we?
| ogre_codes wrote:
| > It might not be, but then I'm curious why it's
| noteworthy enough to have two layers of comments about
| it.
|
| You noted it, I was trying to explain something which
| seems to me exceedingly obvious.
|
| > Apple has priorities, and these have results.
|
| The reason these tools were built/ run first is due to
| the priorities and constraints of outside individuals,
| not Apple's. If you build a graphics editor or a text
| editor using Apple's toolchain and most of your clients
| run Apple, porting is likely high priority and not super
| hard.
|
| A lot of these things you are complaining about are just
| really hard problems.
|
| Docker requires a hypervisor which wasn't part of the
| A12Z processor they shipped in the DTK. It also depends
| on Go.
|
| Go isn't available because porting languages to a new
| processor is non-trivial.
|
| Rust has the above issues, plus didn't Mozilla lay off a
| huge chunk of the Rust team?
| DCKing wrote:
| Well we can talk about this!
|
| > Docker requires a hypervisor which wasn't part of the
| A12Z processor they shipped in the DTK. It also depends
| on Go.
|
| Apple did have prerelease hardware that supported
| virtualization, which they supplied to Parallels. Docker
| has not worked with this hardware based on their press
| release and GitHub issue [1][2], although they may have
| received some specs. In any case, Docker depends on
| Golang with won't release until February.
|
| If Apple did make Docker a priority (which you'd expect
| given the namedrop at WWDC), this seems quite strange to
| me.
|
| [1]: https://www.docker.com/blog/apple-silicon-m1-chips-
| and-docke...
|
| [2]: https://github.com/docker/for-mac/issues/4733
|
| > Go isn't available because porting languages to a new
| processor is non-trivial.
|
| I'm sorry, I don't buy this at face value for Go and Rust
| which support are already highly portable and have
| extensive arm64 support on other platforms. By no means
| do I want to suggest it's a trivial matter, but these
| systems are _made_ to be portable and currently support
| both much more exotic and very similar systems to aarch64
| macOS at the same time. Rust 's current bottleneck may be
| due to CI sure, but then the question becomes why weren't
| DTKs used for CI?
|
| It seems that if Rust and Go developers were approached
| with the right tools and support, they wouldn't have had
| to figure things out now. Is it _that bad_ that they have
| to figure things out now? Not really - but I do think it
| could have been avoided, and we wouldn 't have had to
| wait for a golang release in February and a Docker
| release after that.
| egsmi wrote:
| > I can't escape the impression that they didn't really shower
| the wider ecosystem in DTKs and support, although I'd be happy
| to proven wrong there.
|
| That's interesting. I was shocked at how many green check marks
| there are for a chip that was announced in June. It takes time
| to write and test an application. A lot of teams must've really
| prioritized it.
|
| Also, Apple Silicon compatibility is not enough. One needs Big
| Sur compatibility too.
| DCKing wrote:
| I don't think the chip's announcement time really should go
| into anyone's consideration time here, since it's Apple's own
| choice to go for these timelines and release a "Pro" product
| in November :)
|
| I mean this point is largely moot by Rosetta covering all the
| basics well and still making the Macbook Pro 13 a serviceable
| Pro computer for a lot of (but not all) use cases. It just
| seems strange to me that popular developer things like Go,
| Rust, Docker, virtualization of any kind are still months
| away despite these being super important use cases of the
| Mac. Maybe Apple just doesn't feel that way, or have the
| numbers showing that my impression isn't true, but it feels
| strange that they're letting the community just figure it out
| by themselves now.
| egsmi wrote:
| Is this really a knock on Apple though? It's not like all
| this is up to them. Personally I want MATLAB support but
| Apple doesn't get to dictate Mathworks schedule.
| [deleted]
| brundolf wrote:
| Very cool. Small suggestion: it would be nice to be able to
| filter by "all apps that have native support _or_ work properly
| under Rosetta ", and maybe also the inverse of that.
| nottorp wrote:
| Can it virtualize x86 operating systems? That's when it will be
| ready.
|
| If you only use the latest version of <whatever javascript lib
| you're using> it's fine now, i guess.
|
| If you maintain legacy apps, you now need an x86 box. And then
| you have to ask yourself, why buy a Mac too? They need to fix
| that somehow. They have enough money to sponsor something based
| on QEMU, for example. They're just cheap.
| savanpatel wrote:
| Why is Apple a Developer for TensorFlow? Is that a mistake in
| list?
| rudolph9 wrote:
| Probably not but for better or worse, Apple is a big enough
| juggernaut that existing software that's not ready it now has
| significant motivation to become ready.
| canofbars wrote:
| Users will most likely blame the software for not working and
| not the hardware since all their other software will be working
| pretty soon.
| mpol wrote:
| I would think the apps will come and get optimised. That is just
| a matter of chicken and egg, sometimes you just have to release,
| and go from there.
|
| What I am worried about is if the GPU is anything worthwhile. All
| the focus in the reviews is on the CPU, but the GPU seems where
| it mostly falls short. Not enough external screens for example,
| though that can be fixed in a newer generation. But is it faster
| than what Apple hardware included in Intel, with AMD graphics?
| Some people will feel the regression in speed and capabilities
| quite hard. I don't see much focus on that in media publications.
| lumost wrote:
| It's a fair bet that it's substantially inferior to a dedicated
| gpu at present. They didn't release an M1 in any premium sku
| that would be head to head with a dgpu.
|
| However, given the investment in both the neural engine and
| integrated gpu - I wouldn't be surprised to see something
| interesting in 6-24 months.
| lucian1900 wrote:
| It's at least as impressive, if not more
| https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
| bklyn11201 wrote:
| In my small universe, this was the week of ARM. I submitted
| multiple PRs to OS projects to get ARM compilations working. I
| started moving AWS instances off of Intel instances to the new
| Graviton2 instances.
|
| I'm still surprised there isn't more server takeup of ARM
| considering the incredible power numbers. Cloudflare announced
| their current builds and it's all Epyc2 and no ARM. What about
| Azure and Google Cloud? Are ARM servers easy to launch and
| superior on a cost/performance perspective?
| bredren wrote:
| I did not realize AWS had its own ARM chipset, so thanks for
| bringing Graviton to my attention.
|
| I was wondering how other companies will compete with Apple's
| data center advantage--presumably Apple will replace most x86
| infrastructure with cheaper, lower power, faster Apple Silicon.
|
| Even if Graviton2 work is far behind the M1, it seems like
| Amazon can catch up. Particularly if they are able to hire away
| engineers from Apple's team. Even if Amazon trails Apple by
| years in performance per watt, it can still likely offer a
| compelling change from what Intel or AMD may be able to
| accomplish in the same time period.
| ajsfoux234 wrote:
| The blog post that announces Cloudflare's current builds [1]
| says they "looked very seriously at ARM-based CPUs and continue
| to keep our software up to date for the ARM architecture so
| that we can use ARM-based CPUs when the requests per watt is
| interesting to us"
|
| [1] https://blog.cloudflare.com/technical-details-of-why-
| cloudfl...
| bklyn11201 wrote:
| Is this about availability? Meaning that purchasing the Arm
| Neoverse that Graviton2 is based on, is too difficult if not
| operating at massive scale?
|
| This Anandtech review has a page called "An X86 Massacre":
|
| https://www.anandtech.com/show/15578/cloud-clash-amazon-
| grav...
|
| Are giants like Apple and AWS just making it impossible for a
| player like Cloudflare to buy enough of the leading-edge Arm
| processors? And Epyc performs so well, and it's easy to buy,
| so they wait another year?
| Xevi wrote:
| Scaleway tried ARM and failed:
| https://www.theregister.com/2020/04/21/scaleway_arm64_cloud_...
|
| But as you can see at the end of the article, other providers
| are considering/using ARM more.
| marmaduke wrote:
| I tried ARM on Scaleway and the main benefit was network
| capacity. Performance was not so good.
| bklyn11201 wrote:
| Seems like they were just too early and didn't have the
| capability of an AWS-scale company to work directly with
| ARM?
|
| It seems like the first-gen of Graviton wasn't great, but
| then they seem to have made huge leaps with Graviton2.
|
| https://pages.awscloud.com/rs/112-TZM-766/images/2020_0501-
| C...
| Thaxll wrote:
| Performance on ARM is bad compare to intel on GCP / AWS. The
| "incrediable" numbers are on M1 for Apple only which cloud
| provider don't have, also on servers Intel / AMD are still
| faster, no one cares about power consuption when renting a
| server.
| worker767424 wrote:
| I've heard some of the big tech players are actually limited
| by power and cooling in their DCs, so ARM, even if it's
| slower, could be a win.
| bklyn11201 wrote:
| For sure limited by all sorts of factors: density,
| providers, backups, UPSes, diesel availability, generators,
| fire codes, etc.
|
| Plus every watt costs money so the movement to performance
| per watt is huge for DCs!
| bklyn11201 wrote:
| AWS claims far superior performance per dollar with the
| Graviton2 processors vs the Intel equivalent processors. Look
| at the SPEC cpu2017 charts in this presentation:
|
| https://pages.awscloud.com/rs/112-TZM-766/images/2020_0501-C.
| ..
|
| This will catalyze giant migrations of workloads away from
| AWS Intel instances to the Graviton2 processors.
| Additionally, it seems clear that AWS will begin running all
| of the managed services (e.g., RDS, caches, mail, load
| balancers) with the superior ARM processors. The world is
| changing!
| kllrnohj wrote:
| > This will catalyze giant migrations of workloads away
| from AWS Intel instances to the Graviton2 processors.
|
| Or just from Intel instances to Epyc Rome instances. Which
| is a less significant migration with basically all of the
| same advantages.
| bklyn11201 wrote:
| I assume it's almost zero migration for 99% of use cases
| from an Intel instance to an Epyc Rome instance.
|
| But if they figured out performance with Graviton2, what
| makes you think ARM isn't the clear future for server
| performance per dollar?
| count wrote:
| Performance per dollar is pretty great on AWS. For an
| example: https://www.honeycomb.io/blog/observations-on-
| arm64-awss-ama...
| bklyn11201 wrote:
| Thanks for that link. I'm seeing similar results. The Arm
| instances are a no-brainer for a massive amount of
| workloads. Yes, leaving the Intel instances will take many,
| many years, but I don't see any future for buying any more
| Intel-based reserved instances from AWS. The Arm instances
| are just a clear winner when measured on performance per
| dollar.
| xeeeeeeeeeeenu wrote:
| Beta software (like Firefox) shouldn't have got green checkmarks.
| It's not "ready" yet.
| jane128 wrote:
| Thanks for the feedback, we've fixed it.
| jrlocke wrote:
| Yes.
| bigdict wrote:
| Why is World of Warcraft listed under "Developers"?
|
| Actually...
| leipert wrote:
| You can script Lua, no? Or is that some other game.
| yyyk wrote:
| It's unfortunate that the middle status (warning triangle with a
| exclamation mark) has a green background rather than a yellow
| background like warning triangles everywhere else. Makes the
| table less clear.
| jane128 wrote:
| we've fixed the warning color, thanks for your feedback.
| uxisnotui wrote:
| Please add/track Figma :)
___________________________________________________________________
(page generated 2020-11-20 23:01 UTC)