Is it not at least somewhat possible that at least some of those Apple laptops will age out and be replaced with GNU/Linux laptops? Agreed that developing on ARM and deploying on x86 is unpleasant, but so too is developing on macOS and deploying on Linux. Apple’s GNU userland is pretty ancient, and while the BSD parts are at least updated, they are also very austere. Given that friction is already there, is it likelier that folks will try to alleviate it with macOS in the cloud or GNU/Linux locally?
Mac OS X was a godsend in 2001: it put a great Unix underneath a fine UI atop good hardware. It dragged an awful lot of folks three-quarters of the way to a free system. But frankly I believe Apple have lost ground UI-wise over the intervening decades, while free alternatives have gained it (they are still not at parity, granted). Meanwhile, the negatives of using a proprietary OS are worse, not better.
Has Linux desktop share been increasing lately? I'm not sure why a newer Mac with better CPU options is going to result in increasing Linux share. If anything, it's likely to be neutral or favor the Mac with it's newer/ faster CPU.
> But frankly I believe Apple have lost ground UI-wise over the intervening decades, while free alternatives have gained it (they are still not at parity, granted).
Maybe? I'm not as sold on Linux gaining a ton of ground here. I'm also not sold on the idea that the Mac as a whole is worse off interface wise than it was 10 years ago. While there are some issues, there are also places where it's significantly improved as well. Particularly if you have an iPhone and use Apple's other services.
The second would be Apple pushing all MacBooks to M1 too soon, breaking certain tools and workflows.
While I think both of those scenarios could easily happen, most devs will probably decide just put up with the extra trouble rather than switch to Linux.
I don't think this is an issue. Apple has been fairly straight about timelines and people who want to stick with Intel have plenty of time and options to get their stuff in a row in advance. More important, Apple fixed most of the major irritations with the MacBook Pro. If they hadn't launched the 16" MBP last year, people would have been stuck with a fairly old/ compromised design.
I suspect Apple is going to maintain MacOS right where it is now. People have been worried about "iOSification" for nearly a decade now and while there have been some elements, the core functionality is fundamentally the same.
They changed a ton about the UI in Big Sur, none of it for the better as far as I can tell. They took away even more choice, I can't have a "classic" desktop experience.
My biggest frustration is that they were willing to make such drastic changes to the desktop UI at all. I have to re-learn a ton of keyboard navigation now. And there doesn't seem to be a coherent design to the workflows.
Such a drastic change seems to be an admission that they thought the previous design language was wrong but they seem to have replaced it with... no vision at all?
I am hopeful for the next generation of M1 MacBook Pros and whatever the next MacOS is. Hopefully they get their design philosophy straight and stick with it.
I see a strong vision in Big Sur, one that pulls macOS visually into line with iOS, but there are a lot of rough edges right now. Especially with some Catalyst apps bringing iOS paradigms onto Mac. Even Apple's Catalyst apps (News in particular) are just gross, can't even change the font size with a keyboard shortcut
There’s an enormous amount of wasted space. You need that 32” monitor. My 16” RMBP now has as much usable space as my 13”.
Keyboard navigation is bizarre. Try this:
1) Open Mail.
2) Cmd W.
3) Cmd 1 (or is it Cmd 0?!, hint: it’s whatever Messages isn’t!)
4) Without using your mouse select a message in your inbox.
5) Without using your mouse navigate to a folder under your inbox.
6) Without using your mouse navigate to an inbox in another account.
All of this is possible in Catalina and earlier with zero confusion (selections are highlighted clearly) and can be done “backwards” using shift. In Big Sur some of it is actually impossible and you have to just guess where you start.
When native apps aren’t even consistent in their behavior and appearance that is a trainwreck.
You may be able to read the tea leaves and see a grand vision here but I have to use a half-baked desktop environment until Not-Jony Ive is satisfied they have reminded me they are not Jony Ive. To them I say, trust me, I noticed.
I'm not a huge Mail user so I'm not up-to-speed on keyboard shortcuts. But I was able to navigate with the keyboard easily — I hit tab to focus on the correct list then use the up/down arrows to select the inbox or message (your 4/5/6). After hitting Cmd+W both Cmd+0 or Cmd+1 bring the Mail window back for me. And Cmd+Shift+D still sends mail which is the main one I use
I am a huge Xcode user and primarily use the keyboard for code navigation, and that is as good as ever on the 13" MacBook Air in Big Sur. Also use Sketch a lot, and that has been just great too
I guess we have a very different perception of Big Sur but mine is generally favourable, and I don't see the wasted space that you see. There have been a few weekends where I have done all my work on the 13" MBA, which is only just now possible due to battery life, and the experience has been really, really nice
You’d have more usable space with Catalina on that 13” screen. It was a noticeable loss of space upgrading from Catalina to Big Sur on a 16” RMBP. I used to have space for three partially overlayed windows on my 16” screen. Now I am lucky to get two. Usable space on a 16” Big Sur MacBook is similar to a 13” Catalina MacBook. I have both. My workflows changed. There is no benefit to me as a user.
Take a look at this visual comparison: https://www.andrewdenty.com/blog/2020/07/01/a-visual-compari...
Look at the “traffic light” buttons. Note how much thicker the top bar is in Big Sur. It’s 50% taller! That’s a lost row of text.
Messages does not have great keyboard navigation — I can't tab around like I can in Mail. I am putting this down to the fact it is a Catalyst app and they are a bit sloppy with consistency (not necessarily a Big Sur thing, as these were on Catalina)
But in Catalina Cmd-1 selects the inbox and full sidebar navigation including between accounts is possible with arrow keys. Nested lists can expand and collapse with left and right.
In Big Sur Cmd-1 just reopens the window with no selection. In addition you cannot navigate the full sidebar with arrow keys.
Combine this with the lack of visual indication of your selection and keyboard navigation becomes a struggle.
I have not found a UI improvement in Big Sur.
Sure, but Jonny Ive just officially left. He was head of all design (when he should have been head of hardware design only). It’s natural that there would be greater-than-usual changes as someone new took over.
Big Sur has some pretty terrible changes. There’s nothing surprising that changes occurred. The only surprise is how bad they are.
Overall though when I hear about the "iOSification" I worry foremost about locking down the OS which doesn't seem to be a big issue.
My personal computer is on Big Sur, but I've kept my work laptop on Catalina so a lot of this doesn't hit me work wise. It doesn't seem too horrible to me when working on private projects but that's a small percentage of my time.
I feel you there, one of the reasons I didn't like Windows is big, seemingly random UI changes. I don't think Bir Sur is crazy like Windows NT -> Windows Vista crazy, just feels like a big change for MacOS which has been relatively stable for a few years.
Seems like Apple tends to go long when they make big sweeping UI changes, then in the following releases they dial things back or work out the glitches. It's frustrating for certain.
At least I feel I see a lot more Linux now, not just in the company I work for but also elsewhere.
The speed advantage over Windows is so huge that it is painful to go back once you've seen it.
MS Office isn't seen as a requirement anymore, nobody think it is funny if you use GSuite and besides, last time I used an office file for work is months ago: everything exist inæ Slack, Teams, Confluence or Jira and these are about equally bad on all platforms.
The same is true (except the awful part) for C# development: it is probably even better on Linux.
People could switch to Mac and I guess many will. For others, like me Mac just doesn't work and for us Linux is an almost obvious choice.
For the rest of the company, MS Office may very well be essential. In particular, Excel is king for many business functions.
There is a procedure to get one, but so far I don't know anyone who used it. Quite on the contrary I know one of our sales guys used to install and run Linux on his laptop.
Yes, I work and an above average technical company but we do have HR, sales etc and they aren't engineers (at least not most of them).
(email in my profile ;-)
I see it far more now than I did ~5-10 years ago when it was my daily driver. I'm just not sure if it's gotten a baseline support and flatlined or if it's growing consistently now.
Fully agree with almost all of your points, and if MacOS did go off the deep end in terms of functionality, I'd be back on Linux. It's why I'm a big fan of what Marcan is doing and follow it closely.
If Linux support was as good now as it was when I switched, I'd likely have never switched to the Mac.
But now I just stick around for the hardware.
I run on Mac for desktop, Linux for projects. I don’t know that more people have been switching than before, but I thought the author of this[0] piece illustrated well that it’s easier than ever. That said, the author states that they opt not to have a phone. That’s much less lock-in than most of the market.
I had already decided that 2021 would be my year of the Linux desktop, but Apple forced my hand a bit early. My 2019 Mac’s WiFi went. Had to lose my primary dev machine for over a week as it shipped out to have a bunch of hardware replaced.
So, I built a PC with parts that have good Linux support. I think that’s the key. I imagine System76 machines would run smoothly. It’s definitely not as smooth a UX as Mac, but I like being in an open ecosystem on a machine I can repair. And it’s had a number of perks such Docker running efficiently for once.
Edit: I can now trivially repair my computer if it breaks. The entire rig cost about 1/4 what my MacBook cost, and it is much faster.
With a hybrid 1-2 days in the office and the fact that the NUC form factor has gotten smaller and higher performance, I could make a case to actually stick it in my laptop bag for the 1-2 days and do email/surf only on my train commute. I was never really that productive working on the train anyways.
And I personally hope that by then, GNU/Linux will have an M1-like processor available to happily run on. The possibilities demonstrated by this chip (performance+silence+battery) are so compelling that it's inevitable we'll see them in non-Apple designs.
Also, as it usually happens with Apple hardware advancements, Linux experience will be gradually getting better on M1 Macbooks as well.
0:https://www.datacenterdynamics.com/en/news/microsoft-reporte... 1:https://www.theverge.com/2020/4/14/21221062/google-processor...
I'm a huge fan of OCaml, Java and Python (RC but with cyclic garbage collection), and RC very likely incurs more developer headache and more bugs, but at the end of the day, that's just a question of upfront investment, and in the long run it seems to pay off - it's pretty hard for me to deny that pretty much all GC software is slow (or singlethreaded).
MacPorts and Homebrew exist. Both support M1 more or less and support is improving.
Big Sur is a Big Disaster but hopefully this is just the MacOS version of iOS 13 and the next MacOS next year goes back to being mostly functional. I have more faith in that than a serviceable Linux desktop environment.
I may be naive but that seems like hyperbole. I updated to Big Sur shortly after is was released. It was a little bumpy here and there, but not more than any other update. I'd even argue it has been as smooth or smoother than any of my Linux major upgrades in the past 20 years.
I upgraded my personal laptop and it’s so bad I’m holding off on my work laptop until I am forced to upgrade.
I agree generally though. I see macOS as an important Unix OS for the next decade.
Also proprietary software. Unfortunately, many people still need Adobe.
I personally like Krita, Shotcut, and Darktable better than any of the Adobe products I used to use, but it's a real issue.
E: Add "many people"
You also get POSIX compliance.
Recently there are some hypervisor-like things for security, and more things have been moving to userland instead of being kexts. I'd still say it's less of a microkernel than Linux since it doesn't have FUSE.
Ugh, not even.
Simple and straightforward shell scripts that work on decade-old Linux distributions don't work on Big Sur due to ancient macOS bsd tooling.
Just look at stackoverflow or similar sites: every answer has a comment "but this doesn't work on my macOS box."
(I've had to add countless if-posix-but-mac workarounds for PhotoStructure).
Sadly, fewer of my coworkers use Linux now than they did 10 years ago.
Could we do a roll call of experiences so I know which ones work and which ones don't? Here are mine.
Dell Precision M6800: Avoid.
Supported Ubuntu: so ancient that Firefox
and Chrome wouldn't install without source-building
dependencies.
Ubuntu 18.04: installed but resulted in the
display backlight flickering on/off at 30Hz.
Dell Precision 7200:
Supported Ubuntu: didn't even bother.
Ubuntu 18.04: installer silently chokes on the NVMe
drive.
Ubuntu 20.04: just works.> both Dell and Lenovo have models that come with Linux
Like the Dell Precision M6800 above? Yeah. Mixed bag.
Rules of thumb: - Use older thinkpads off business lease is great - stick to intel video graphics - max out the ram and upgrade storage (NVMe)
Like the Dell Precision 6800 above? The one where the latest supported linux was so decrepit that it wouldn't install Firefox and Chrome without manually building newer versions of some of the dependencies?
"System76 is better at this than Dell" is valid feedback, but System76 doesn't have the enterprise recognition to be a choice you can't be fired for.
Maybe ThinkPads hit the sweet spot. I'll have to look at their newer offerings.
Some definitely will. Significant enough to assume they're not well-situated other-configs? Probably not. Even the most VIM- and CLI-oriented devs I know still prefer a familiar GUI for normal day to day work. Are they all going Ubuntu? Or Elementary? I mean, I welcome any migration that doesn't fracture the universe. But I don't think it's likely.
I’ve known colleagues that tried to run Linux professionally using well reviewed Linux laptops, and their experience has been universally awful. Like “I never managed to get the wifi to work, ever” bad. The idea of gambling every developer on that is a non-starter even at my level, let alone across the org.
I wouldn’t be surprised if they sponsor their Graviton offering taking profits elsewhere. This might make it seem like a good deal for customers, but I don’t think it is, at least not in the long run.
This doesn’t mean Graviton is useless. For services running Amazon’s code as opposed to customer’s code (like these PAAS things billed per transaction) the lock-in is already in place, custom processors aren’t gonna make it any worse.
Graviton ARM is certainly vendor lock-in to Amazon. But a Graviton ARM is just a bog-standard Neoverse N1 core. Which means the core is going to show similar characteristics as the Ampere Altra (also a bog-standard Neoverse N1 core).
There's more to a chip than its core. But... from a performance-portability and ISA perspective... you'd expect performance-portability between Graviton ARM and Ampere Altra.
Now Ampere Altra is like 2x80 core, while Graviton ARM is... a bunch of different configurations. So its still not perfect compatibility. But a single-threaded program probably couldn't tell the difference between the two platforms.
I'd expect that migrating between Graviton and Ampere Altra is going to be easier than Intel Skylake -> AMD Zen.
I agree, that would what I would expect too. Still, are there many public clouds built of these Ampere Altra-s? Maybe we gonna have them widespread soon, but until then I wouldn’t want to build stuff that only runs on Amazon or my own servers with only a few on the market and not yet globally available on retail.
Also, AFAIK on ARM the parts where CPUs integrate with the rest of the hardware are custom. The important thing for servers, disk and network I/O differs across ARM chips of the same ISA. Linux kernel abstracts it away i.e. stuff is likely to work, but I’m not so sure about performance portability.
Indeed. But Intel Xeon + Intel Ethernet integrates tightly and drops the Ethernet data directly into L3 cache (bypassing DRAM entirely).
As such, I/O performance portability between x86 servers (in particular: Intel Xeon vs AMD EPYC) suffers from similar I/O issues. Even if you have AMD EPYC + Intel Ethernet, you lose the direct-to-L3 DMA, and will have slightly weaker performance characteristics compared to Intel Xeon + Intel Ethernet.
Or Intel Xeon + Optane optimizations, which also do not exist on AMD EPYC + Optane. So these I/O performance differences between platforms are already on the status-quo, and should be expected if you're migrating between platforms. A degree of testing and tuning is always needed when changing platforms.
--------
>Still, are there many public clouds built of these Ampere Altra-s? Maybe we gonna have them widespread soon, but until then I wouldn’t want to build stuff that only runs on Amazon or my own servers with only a few on the market and not yet globally available on retail.
A fair point. Still, since Neoverse N1 is a premade core available to purchase from ARM, many different companies have the ability to buy it for themselves.
Current rumors look like Microsoft/Oracle are just planning to use Ampere Altra. But like all other standard ARM cores, any company can buy the N1 design and make their own chip.
> Indeed. But Intel Xeon + Intel Ethernet integrates tightly and drops the Ethernet data directly into L3 cache (bypassing DRAM entirely).
This will be less of a problem on ARM servers as direct access to the LLC from a hardware master is a standard feature of ARM's "Dynamic Shared Unit" or DSU, which is the shared part of a cluster providing the LLC and coherency support. Connect a hardware function to the DSU ACP (accelerator coherency port) and the hardware can control, for all write accesses, whether to "stash" data into the LLC or even the L2 or L1 of a specific core. The hardware can also control allocate on miss vs not. So any high performance IP can benefit from it.
And if I understand correctly, the DSU is required with modern ARM cores. As most (besides Apple) tend to use ARM cores now, you have this in the package.
More details here in the DSU tech manual: https://developer.arm.com/documentation/100453/0002/function...
Could you explain what migration problems are between Skylake and Zen, beyond AVX-512 ?
Cross compilation is no big deal these days. Embedded devs cross compile to ARM all day every day.
The tooling will be there when it needs to be.
That is the beauty of having proper defined numeric types and memory model, instead of the C and derived approaches of whatever the CPU gives, with whatever memory model.
AWS could very well run their platform systems entirely on graviton. After all, serverless and cloud is in essence someone else's server. AWS might as well run all their paas software on in-house architecture
The main difference for us was lower bills.
There can be issues with moving to AArch64, for instance your Python code may depend on Python 'wheels' which in turn depend on C libraries that don't play nice with AArch64. I once encountered an issue like this, although I've now forgotten the details.
If your software is pure Java I'd say the odds are pretty good that things will 'just work', but you'd still want to do testing.
Any ARM licensee (IP or architecture) has access to them. They're just NeoVerse N1 cores and can be synthesized on Samsung or TSMC processes.
Do you think that vendor lock in has stopped people in the past (and future)? Thinking about those kinds of things are long term and many companies think short term.
But ... the difference is that Oracle wasn't a platform in the sense that (e.g.) AWS is. Oracle as a corporation could vanish, but as long as you can keep running a compatible OS on compatible hardware, you can keep using Oracle.
If AWS pulls the plug on you, either as an overall customer or ends a particular API/service, what do you do then?
Oh wait.
When you run pip or composer on Amd64 they often pull these down and you don't notice, but if you try on arm you discover quickly that some packages don't support ARM. Sometimes there is a slower fallback option, but often there is none.
I'm reasonably sure that you can take a binary compiled with GCC on a P4 back in the day and run it on the latest Zen 3 CPU.
I don't recall encountering a "Intel-locked" or "AMD-locked" application in more than 20 years of using x86. Ok, maybe ICC, but that one kind of makes sense :-)
But yeah, typically binaries built for redistribution use a reasonably crusty minimum architecture. Reminds me of this discussion for Fedora: https://lists.fedoraproject.org/archives/list/[email protected]...
Yes.
In theory, your software could run faster, or slower, depending upon Amazon's use of their extensions within their C library, or associated libraries in their software stack.
Maybe the wildest thing that I've heard is Fujitsu not implementing either 32-bit or Thumb on their new supercomputer. Is that a special case?
"But why doesn’t Apple document this and let us use these instructions directly? As mentioned earlier, this is something ARM Ltd. would like to avoid. If custom instructions are widely used it could fragment the ARM ecosystem."
https://medium.com/swlh/apples-m1-secret-coprocessor-6599492...
What's wild about this? Apple dropped support for 32b (arm and thumb) years ago with A11. Supporting it makes even less sense in an HPC design than it does in a phone CPU.
Also, I think there's a typo in your last phrase.
Amazon already has lock-in. Lambda, SQS, etc. They've already won.
You might be able to steer your org away from this, but Amazon's gravity is strong.
My impression is that we have been living under the cruft of x86 because of inertia, and what are mostly historical reasons, and it's mostly a good thing if we move away from it.
"RISC" and "CISC" distinctions are murky, but modern ARM is really a CISC design these days. ARM is not at all in a "an instruction only does one simple thing, period" mode of operation anymore. It's grown instructions like "FJCVTZS", "AESE", and "SHA256H"
If anything CISC has overwhelmingly and clearly won the debate. RISC is dead & buried, at least in any high-performance product segment (TBD how RISC-V ends up fairing here).
It's largely "just" the lack of variable length instructions that helps the M1 fly (M1 under Rosetta 2 runs with the same x86 memory model, after all, and is still quite fast).
I think it's time for a Mashey CISC vs RISC repost:
It's about increased orthogonality between ALU and memory operations, making it simpler and more predictable in an out-of-order superscalar design to decode instructions, properly track data dependencies, issue them to independent execution units, and to stitch the results back into something that complies with the memory model before committing to memory.
Having a few crazy-ass instructions which either offload to a specialized co-processor or get implemented as specialized microcode for compatibility once you realize that the co-processor is more trouble than it's worth doesn't affect this very much.
What ARM lacks are the huge variety of different instruction formats and addressing mode that Intel has; which substantially affect the size and complexity of the instruction decoder, and I'm willing to bet that creates a significant bottleneck on how large of a dispatch and reorder system they can have.
For a long time, Intel was able to make up this difference with process dominance, clever speculative execution tricks, and throwing a lot of silicon and energy at it which you can do on the server side where power and space are abundant.
But Intel is clearly losing the process dominance edge. Intel ceded the mobile race a long time ago. Power is becoming more important in the data center, which are struggling to keep up with providing reliable power and cooling to increasingly power-hungry machines. And Intel's speculative execution smarts came back to bite them in the big market they were winning in, the cloud, when it turned out that they could cause information leaks between multiple tenants, leading to them needing to disable a lot of them and lose some of their architectural performance edge.
And meanwhile, software has been catching up with the newer multi-threaded world. 10-15 years ago, dominance on single threaded workloads still paid off considerably, because workloads that could take advantage of multiple cores with fine-grained parallelism were fairly rare. But systems and applications have been catching up; the C11/C++11 memory model make it significantly more feasible to write portable lock-free concurrent code. Go, Rust, and Swift bring safer and easier parallelism for application authors, and I'm sure the .net and Java runtimes have seen improvements as well.
These increasingly parallel workloads are likely another reason that the more complex front-ends needed for Intel's instruction set, as well as their stricter memory ordering, are becoming increasingly problematic; it's becoming increasingly hard to fit more cores and threads into the same area, thermal, and power envelopes. Sure, they can do it on big power hungry server processors, but they've been missing out on all of the growth in mobile and embedded processors, which are now starting to scale up into laptops, desktops, and server workloads.
I should also say that I don't think this is the end of the road for Intel and x86. They have clearly had a number of setbacks of the last few years, but they've managed to survive and thrive through a number of issues before, and they have a lot of capital and market share. They have squeezed more life out of the x86 instruction set than I thought possible, and I wouldn't be shocked if they managed to keep doing that; they realized that their Itanium investment was a bust and were able to pivot to x86-64 and dominate there. They are facing a lot of challenges right now, and there's more opportunity than ever for other entrants to upset them, but they also have enough resources and talent that if they focus, they can probably come back and dominate for another few decades. It may be rough for a few years as they try to turn a very large boat, but I think it's possible.
My understanding is the reorder buffer of the m1 is particularly large:
"A +-630 deep ROB is an immensely huge out-of-order window for Apple’s new core, as it vastly outclasses any other design in the industry. Intel’s Sunny Cove and Willow Cove cores are the second-most “deep” OOO designs out there with a 352 ROB structure, while AMD’s newest Zen3 core makes due with 256 entries, and recent Arm designs such as the Cortex-X1 feature a 224 structure."
https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
Except ARM CPUs aren't any more parallel in comparable power envelopes than x86 CPUs are, and x86 doesn't seem to have any issue hitting large CPU core counts, either. Most consumer software doesn't scale worth a damn, though. Particularly ~every web app which can't scale past 2 cores if it can even scale past 1.
I would argue it isn't time for Intel to switch until we see a little more of the future as process nodes may shrink at a slower rate. Will we have hundreds of cores? Field programmable cores? More fixed function hardware on chip, or less? How will high-bandwidth high-latency gddr style memory mix with lower-latency lower-bandwidth ddr memory? Will there be on die memory like hbm for cpus?
They're trying to fix it with Windows on ARM now, but that's what people were asking for back then.
Running on the JVM, Ruby, Python, Go, Dlang, Swift, Julia or Rust and you won't notice a difference. It will be sooner than you think.
Obviously this is fairly niche but the friction to making something fast is hugely easier locally.
I partially agree with you though, as the penetration of Arm goes deeper into the programmer ecosystem, any mental roadblocks about deploying to Arm will disappear. It is a mindset issue, not a technical one.
In the 80s and 90s there were lots of alternative architectures and it wasn't a big deal, granted the software stacks were much much smaller and more metal. Now they are huge, but more abstract and farther away from machine issues.
Protip: New on the job and want to establish a reputation quickly? Find the most common path and fire a profiler at it as early as you can. The odds that there's some trivial win that will accelerate the code by huge amounts is fairly decent.
Another bit of evidence developers rarely profile their code is that I can tell my mental model of how expensive some server process will be to run and most other developer's mental models tend to differ by at least an order of magnitude. I've had multiple conversations about the services I provide and people asking me what my hardware is, expecting it to be run on some monster boxes or something when I tell them it's really just two t3.mediums, which mostly do nothing, and I only have two for redundancy. And it's not like I go profile crazy... I really just do some spot checks on hot-path code. By no means am I doing anything amazing. It's just... as you write more code, the odds that you accidentally write something that performs stupidly badly goes up steadily, even if you're trying not to.
I've found that a profiler isn't even needed to find significant wins in most codebases. Simple inspection of the code and removal of obviously slow or inefficient code paths can often lead to huge performance gains.
It’s so painful to behold.
Binary formats converted to JSON blobs, each bigger than my first hard drive (!), and then back again, often multiple times in the same process.
Apple will definitely give all the necessary tools as part of Xcode for iOS/MacOS software optimisation.
AWS is going to be more interesting – this is a great opportunity for them to provide distributed profiling/tracing tools (as a hosted service, obviously) for Linux that run across a fleet of Graviton instances and help you do fleet-wide profile guided optimizations.
We should also see a lot of private companies building high-performance services on AWS to contribute to highly optimized open-source libraries being ported to graviton.
I found it to have quite a lot of useful pointers. Specifically –https://static.docs.arm.com/swog309707/a/Arm_Neoverse_N1_Sof...
https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm....
- these two docs gives lot of useful information.
And the repo itself contain a number of examples (like ffmpeg) that have been optimized based on these manuals.
There is certainly an exception to this for chips with radically different designs and layouts, as well as folks writing very low-level performance sensitive code which can benefit from specific platform optimization ( graphics comes to mind ).
However even in the latter case, I'd imagine the platform specific and fallback platform agnostic code will be within 10-50% performance of each other. Meaning a particularly well designed chip could make the platform agnostic code cheaper on either a raw performance basis or cost/performance basis.
What fraction of products deployed to the cloud even has its developers seen doing _any_ microbenchmarking?
Graviton2 is a Neoverse core from Arm and it's totally separate from M1.
Besides, Apple don't let you play with PMCs easily and I'm assuming they won't be publishing any event tables any time soon so unless they get reverse engineered you'll have to do it through xcode.
And keep in mind this is about reducing the incentive to switch to a chip that’s cheaper per compute unit in the cloud. If Graviton 2 was more expensive or just equal in price to x86, I doubt that M1 laptops alone would be enough to incentivize a switch.
* yes I know Centos is done, substitute as needed.
I don't run my production profiles on my laptop - why would I expect to compare how my i5 or i7 chip on a thermally limited MBP to how my 64 core server performs?
It's convenient for debugging to have the same instruction set (for some people, who run locally), but for profiling it doesn't matter at all.
Most code is worked on until it'll pass QA then thrown over the wall. For that majority of people, an M1 is definitely close enough to a graviton.
Let me have my fun!
One thing to also consider is why amazon hugely prioritizes using their "services" and not deploying on bare metal is likely because they can execute their "services" on cheapo arm hardware. Bare metal boxes and VM's give the impression that customer's software will perform in an x86 esque matter. For amazon, the cost of the underlying compute per core is irrelevant since they've already solved the issue of using blazing fast network links to mesh their hardware together - in this way, the ball is heavily in Arm's court for the future of Amazon data centers, although banking and gov clients will likely not move away from X86 any time soon.
>Cloud (Intel) isn’t really challenged yet....
AWS are estimated to be ~50% of HyperScalers.
HyperScalers are estimated to be 50% of Server and Cloud Business.
HyperScalers are expanding at a rate faster than other market.
HyperScaler expanding trend are not projected to be slowing down anytime soon.
AWS intends to have all of their own workload and SaaS product running on Graviton / ARM. ( While still providing x86 services to those who needs it )
Google and Microsoft are already gearing up their own ARM offering. Partly confirmed by Marvell's exit of ARM Server.
>The problem is single core Arm performance outside of Apple chips isn’t there.
Cloud computing charges per vCPU. On all current x86 instances, that is one hyper-thread. On AWS Graviton, vCPU = Actual CPU Core. There are plenty of workloads, and large customers like Twitter and Pinterest has tested and shown AWS Graviton 2 vCPU perform better than x86. All while being 30% cheaper. At the end of the day, it is workload / dollars that matters on Cloud computing. And right now in lots of applications Graviton 2 are winning, and in some cases by large margin.
If AWS sell 50% of their services with ARM in 5 years time, that is 25% of Cloud Business Alone. Since it offer a huge competitive advantage Google and Microsoft has no other choice but to join the race. And then there will be enough of a market force for Qualcomm, or may be Marvell to Fab a commodity ARM Server part for the rest of the market.
Which is why I was extremely worried about Intel. (Half of) The lucrative Server market is basically gone. ( And I haven't factored in AMD yet ) 5 years in Tech hardware is basically 1-2 cycles. And there is nothing on Intel's roadmap that shown they have the chance to compete apart from marketing and sales tactics. Which still goes a long way if I have to be honest, but not sustainable in long term. It is more of a delaying tactics. Along with a CEO that despite trying very hard, had no experience in market and product business. Luckily that is about to change.
Evaluating ARM switch takes time, Software preparation takes time, and more importantly, getting wafer from TSMC takes time as demand from all market are exceeding expectations. But all of them are already in motion, and if these are the kind of response you get from Graviton 2, imagine Graviton 3.
Right. I suspect in time we'll look back to this time, and realize that it was already too late for Intel to right the ship, despite ARM having a tiny share of PC and server sales.
Their PC business is in grave danger as well. Within a few years, we're going to see ARM-powered Windows PCs that are competitive with Intel's offerings in several metrics, but most critically, in power efficiency.
These ARM PCs will have tiny market share (<5%) for the first few years, because the manufacturing capacity to supplant Intel simply does not exist. But despite their small marketshare, these ARM PCs will have a devastating impact on Intel's future.
Assuming these ARM PCs can emulate x86 with sufficient performance (as Apple does with Rosetta), consumers and OEMs will realize that ARM PCs work just as well as x86 Intel PCs. At that point, the x86 "moat" will have been broken, and we'll see ARM PCs grow in market share in lockstep with the improvements in ARM manufacturing capacity (TSMC, etc...).
Intel is in a downward spiral, and I've seen no indication that they know how to solve it. Their best "plan" appears to be to just hope that their manufacturing issues get sorted out quickly enough that they can right the ship. But given their track record, nobody would bet on that happening. Intel better pray that Windows x86 emulation is garbage.
Intel does not have the luxury of time to sort out their issues. They need more competitive products to fend off ARM, today. Within a year or two, ARM will have a tiny but critical foothold in the PC and server market that will crack open the x86 moat, and invite ever increasing competition from ARM.
The effort to switch over from PPC and the payoff of doing so was still a recent memory when the iPhone came out, and so they partly pivoted again to ARM, and then smart phones ate the laptop and desktop business, increasing the overall base of non-x86 competence in the world. If Apple had not walked through that door, someone else would have, but Apple has a customer relationship that gives them some liberties that others don’t necessarily enjoy.
The previous two CEO choose profits margin. And hopefully we have enough evidence today that was the wrong choice for the companies long term survival.
It is very rare CEO do anything radical. It is something I learned and observe the difference between a founder and a CEO. But Patrick Gelsinger is the closest thing to that.
I guess the idea is to run a Linux flavor that supports both the M1 and Graviton on the macs and hope any native work is compatible?
Windows ARM development (in a VM) should be much faster on an M1 Mac than on an x86 computer since no emulation is needed.
Linux, mac or windows ARM64 binaries are not cross compatible by definition, thus my question. Is everyone excited to run a Graviton supported Linux distro on these M1s or is there something else?
I would also be surprised if every M1 graphics feature was fully supported on these Amazon chips.
If we're talking about cross compatibility then we can't use any binaries compiled for any M1 specific features either...So no. Its not compatible by definition.
Also, even if you're running against a VM, your VM is running on an ISA, so performance differences between them are still relevant to your code's performance.
The x86 memory model makes it increasingly hard to scale performance to more cores. That has not held up AMD much, mainly because people don't scale things out that don't perform well when they do, and use a GPU when that does better. In principle it has to break at some point, but that has been said for a long time. It is indefinitely hard to port code developed on x86 to a more relaxed memory model, so the overwhelming majority of such codes will never be ported.
Most code should just work, maybe with some tsan testing. There's other ways to test for nondeterminism e.g. sleep the different threads randomly.
It helps if you have a real end to end testsuite; for some reason all the developers I've met lately think unit tests are the only kind of tests.
This isn't true at all: other ARM cores have gone all the way to implement full sequential consistency. Plus, the ARM ISA itself is "good enough" to do efficient x86 memory model emulation as part of an extension to Armv8.3-A.
I don't see why this pattern would fail to hold, but am open to new perspectives.
[0] https://dev.to/ericnograles/why-is-docker-on-macos-so-much-w...
[1] https://www.reddit.com/r/docker/comments/bh8rpf/docker_perfo...
That's worth, what, a few thousand unit sales?
Intel has fabs, yes it’s what maybe holding them back atm but it also a big factor in what maintains their value.
If x86 dies and neither Intel nor AMD pivot in time Intel can become a fab company they already offer these services, yes no where near the scale of say TSMC but they have a massive portfolio of fabs and their fabs are located in the west, they also have a massive IP portfolio related to everything form IC design to manufacturing.
Not unless they catch up with TSMC in process technology.
Otherwise, they become an uncompetitive foundry.
It's doubtful if Intel would have been able to design an equivalent to the M1, even with access to TSMC's 5nm process and an ARM license.
Which suggests there's no point in throwing money at Intel because the management culture ("management debt") itself is no longer competitive.
It would take a genius CEO to fix this, and it's not obvious that CEO exists anywhere in the industry.
But their choice not to invest in EUV early doesn't mean that they will never catch up. They still have plenty of cash, and presumably if they woke up and decided to, they wouldn't be any worse off than Samsung. And definitely better off than SMIC.
Similarly, plenty of smart microarch people work at intel, freeing them to create a design competitive with zen3 or the m1 is entirely possible. Given amd is still on 7nm, and are just a couple percent off of the M1 seems to indicate that if nothing else intel could be there too.
But as you point out Intel's failings are 100% bad mgmt at this point. Its hard to believe they can't hire or unleash whats needed to move themselves forward. But at the moment they seem to be very "IBM" in their moves, but one has to believe that a good CEO with a good engineering background can cut the mgmt bullcrap and get back to basics. They fundamentally just have a single product to worry about unlike IBM.
So they do have a bit of history with overcoming these predictions. We'll just have to see if they became too rusty to turn the ship around.
Intel is managing to compete in per core performance while being essentially 2-3 nodes behind, and generating times the revenue of their competitor.
Zen is awesome and we need more competition but Intel isn’t nearly as far behind as it was during the P4 days and it’s revenue is nearing ATH and it’s business more diversified it ever been, if you exclude the datacenter and client computing groups it still is bringing in more revenue than AMD.
1. Intel doesn't have to catch up. Intel's 14nm is more than enough for a lot of fabless. Not every chip needs cutting edge node
2. split up Intel foundry into a pure play allowed Intel to build up an ecosystem like TSMC.
3. Intel's 10nm is much denser than TSMC's 7nm. Intel is not too far behind. they just needs to solve the yield problem. split up Intel's design and foundry allowed each group to be more agile and not handcuffed to each other.
in fact Intel Design should licensed out x86 like ARM. why not take best biz model from the current leaders? Intel Design take ARM business model and Intel foundry take TSMC business model.
so what? yahoo was a giant in its heyday. blackberry was the king with its phone. no empire stay on top forever.
Apple/Amazon created its own cpu. ARM killing it in mobile space.
intel is the king right now but with more and more its customers design their own cpu. how long before intel fall?
If you compare net income instead of mkt. cap Intel is ahead by 70 times (instead of 6) and is relatively undervalued compared to other tech companies.
Intel can’t compete right now on the bleeding edge node but they outcompete TSMC by essentially every other factor when it comes to manufacturing.
Sometime around 5? years ago AMD was planning to have an ARM option. You'd get essentially an ARM core in an AMD chip with all the surrounding circuitry. They hyped it so much I wondered if they might go further than just that.
Further? Maybe a core that could run either ISA, or a mix of both core types. I dunno, but they dumped that (or shelved it) to focus on Zen, which saved them. No doubt the idea and capability still exist within the company. I'd like to see them do a RISCV chip compatible with existing boards.
Didn't sell very well.
Intel’s Internet of Things group alone revenue last quarter was $680M and they hit $1B IOTG revenue previously
https://www.statista.com/statistics/1096381/intel-internet-o...
My standing theory is that the m1 will accelerate it. Obviously all the wholly managed AWS services (Dynamo, Kinesis, S3, etc.) can change over silently, but the issue is EC2. I have a MBP, as do all of my engineers. Within a few years all of these machines will age out and be replaced with m1 powered machines. At that point the idea of developing on ARM and deploying on x86 will be unpleasant, especially since Graviton 2 is already cheaper per compute unit than x86 is for some work loads; imagine what Graviton 3 & 4 will offer.