[deleted]
Intel Problems
61–70 of 431 posts
Re: Intel Problems
#62I think one day we’re going to wake up and discover that AWS mostly runs on Graviton (ARM) and not x86. And on that day intel’s troubles will go from future to present. 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 ma…
Intel's fate predicted in 2014: https://pbs.twimg.com/media/ErrFtv0UwAA4JaW?format=png
Re: Intel Problems
#63> Solution One: Breakup > Solution Two: Subsidies Solution Three: lower prices/margins (temporarily) to match the value proposition of AMD on Windows PCs and Linux Cloud servers.
Solution Four: Is it even possible that Intel and AMD merge ?! With ARM based chips clearly accelerating and poised to take a big market share (Apple, Nvidia, Amazon, Qualcomm becoming major players) there is less of an antitrust issue ?
Re: Intel Problems
#64Earlier quoted context omitted.
Professional laptops don’t last that long, and a lot of developers are given MBPs for their work. I personally expect that I’ll get a M1 laptop from my employer within the next 2 years. At that point the pressure to migrate from x86 to ARM will start to increase.
You miss my point - if I am seriously optimizing something I need to be on the same chip not the same ISA. 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.
We have MBPs on our desks but our cloud are Centos Xeon machines. The problems I run into are not squeezing every last ms of performance, since it's vastly cheaper to just add more instances. The problems I care about is that some script I wrote suddenly doesn't work in production because of BSDisms, or Python incompatibilities, or old packages in brew, etc. Would be nice if Apple waved a magic wand and replaced its BSD subsystem with Centos* but I won't be holding my breath :)
* yes I know Centos is done, substitute as needed.
Re: Intel Problems
#65Earlier quoted context omitted.
If it can emulate x86, is there really a motivation for developers to switch to ARM? (I don't have an M1 and don't really know what it's like to compile stuff and deploy it to "the cloud.")
Emulation is no way to estimate performance.
Sure, but as a counter example Docker performance on Mac has historically been abysmal[0][1], but everyone on Mac I know still develops using it. We ignore the performance hit on dev machines, knowing it won't affect prod (Linux servers).
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...
Re: Intel Problems
#66Feel this piece ducks one of the most important questions - what is the future and value of x86 to Intel? For a long time x86 was one half of the moat but it feels like that moat is close to crumbling. Once that happens the value of the design part of the business will be much, much lower - especially if they have to compete with an on form AMD. Can they innovate their way out of this? Doesn't look entirely promising…
My view is that currently the only way for Intel to salvage themselves it to go ARM route and start licensing x86 IP and perhaps even open source some bits of tech. They are unable to sustain this tech by themselves nor with AMD anymore. It seems to me when Apple releases their new CPUs I am going to have to move to that platform in order to keep up with the competition (quicker the core, I can do calculations quicke…
Are they able to even do that legally? I'm pretty sure the licensing agreement for x86 with AMD explicitly prohibited this for both parties.
Re: Intel Problems
#67> This is why Intel needs to be split in two. Yes, integrating design and manufacturing was the foundation of Intel’s moat for decades, but that integration has become a straight-jacket for both sides of the business. Intel’s designs are held back by the company’s struggles in manufacturing, while its manufacturing has an incentive problem. The only comparable data point says that this is a terrible idea. AMD spun ou…
>The only comparable data point says that this is a terrible idea.
Huh, I would say completely opposite thing. AMD wouldn't have survived if it kept trying to improve their own process instead of going to TSMC.
Re: Intel Problems
#68If intel made a SBC or SOC design for low power applications, I'd consider it if they had long term support. Intel used to power all of our edge needs in POS and Security, now I see that slipping as well.
Re: Intel Problems
#69Earlier quoted context omitted.
Professional laptops don’t last that long, and a lot of developers are given MBPs for their work. I personally expect that I’ll get a M1 laptop from my employer within the next 2 years. At that point the pressure to migrate from x86 to ARM will start to increase.
You miss my point - if I am seriously optimizing something I need to be on the same chip not the same ISA. 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.
I think this is a slightly different point from the other responses, but this not true: if I am seriously optimizing something I need ssh access to the same chip.
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.
Re: Intel Problems
#70Earlier quoted context omitted.
The vast majority of developers never profile their code. I think this is much less of an issue than anyone on HN would rank it. Only when the platform itself provides traces do they take it into consideration. And even then, I think most perf optimization is in a category of don't do the obviously slow thing, or the accidentally n^2 thing. I partially agree with you though, as the penetration of Arm goes deeper into…
This isn't really about you or me but the libraries that work behind the spaghetti people fling into the cloud.
Yes, and just like Intel & AMD spent a lot of effort/funding for building performance libraries and compilers, we should expect Amazon and Apple invest into similar efforts.
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.