Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Problems

stratechery.com

Post reply on HN
Print view View original

291–300 of 431 posts

Re: Intel Problems

#291

Post by cglace »

chaorace wrote: post #139
jng wrote: post #101

Earlier quoted context omitted.

Modern process node designations (5nm, 3nm...) are not measurements any more, they are marketing terms. The actual measure of shrinking is a lot smaller than the name would mean to indicate, and not approaching the quantum limits as fast as it may seem.

I did not know that! Though, that answer raises its own questions... If the two are entirely unlinked, what's stopping Intel from slapping "Now 3nm!" on their next gen processors? Surely some components must be at the advertised size, even if it's no longer a clear cut all-or-nothing descriptor, right? What's actually being sized down and why is it seemingly posing so many challenges for Intel's supply chain?

They can call it whatever they want but it will need to show huge performance improvements for anyone to actually care.

Re: Intel Problems

#292

Post by Shared404 »

Steltek wrote: post #275
john_alan wrote: post #272

Earlier quoted context omitted.

You can easily bring macOS up to Linux level GNU with brew. I agree generally though. I see macOS as an important Unix OS for the next decade.

"Linux" is more than coreutils. The Mac kernel is no where close to Linux in capability and Apple hates 3rd party drivers to boot. You'll end up running a half-baked Linux VM anyway so all macOS gets you is a SSH client with a nice desktop environment, which you can find anywhere really.

> all macOS gets you is a SSH client with a nice desktop environment

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"

Re: Intel Problems

#293

Post by d33lio »

ashtonkem wrote: post #10

I 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…

While I generally agree with this sentiment a lot of people don't realize how much enterprise supply chain / product chain vastly varies from the consumer equivalent. Huge customers that buy intel chips at datacenter scale are pandered to and treated like royalty by both intel and amd. Companies are courted in the earliest stages of cutting edge technical development and product development and given rates so low (granted for huge volume) that most consumers would not even believe. The fact that companies like Serve The Home exist proves this - for those who don't know, the realy business model of Serve The Home is to give enterprise clients the ability to play around with a whole data center of leading edge tech, Serve The Home is simply a marketing "edge api" of sorts for the operation. Sure it might look like intel isn't "competitive" but many of the intel V amd flame wars in the server space for un released tech have already had their bidding wars settled years ago for this very tech.

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.

Re: Intel Problems

#294

Post by ogre_codes »

WoodenChair wrote: post #110

The thing about all of these articles analyzing Intel's problems is that nobody really knows the details of Intel's "problems" because it comes down to just one "problem" that we have no insight into: node size. What failures happened in Intel's engineering/engineering management of its fabs that led to it getting stuck at 14 nm? Only the people in charge of Intel's fabs know exactly what went wrong, and to my knowle…

Intel's problem was that they were slow getting their 10nm design online. That's no longer the case. Intel's new problem is much bigger than that at this point.

Until fairly recently, Intel had a clear competitive advantage: Their near monopoly on server and desktop CPUs. Recent events have illustrated that the industry is ready to move away from Intel entirely. Apple's M1 is certainly the most conspicuous example, but Microsoft is pushing that way (a bit slower), Amazon is already pushing their own server architecture and this is only going to accelerate.

Even if Intel can get their 7nm processes on line this year, Apple is gone, Amazon is gone, and more will follow. If Qualcomm is able to bring their new CPUs online from their recent acquisition, that's going to add another high performance desktop/ server ready CPU to the market.

Intel has done well so far because they can charge a pretty big premium as the premier x86 vendor. The days when x86 commands a price premium are quickly coming to and end. Even if Intel fixes their process, their ability to charge a premium for chips is fading fast.

Re: Intel Problems

#295

Post by DoofusOfDeath »

yourapostasy wrote: post #231
DoofusOfDeath wrote: post #116

Earlier quoted context omitted.

> financialization propping up abstracted processes of how to lead massive organizations as big blocks on diagrams instead of highly fractal, constantly shifting networks of ideas and stories repeatedly coalescing around people, processes, and resources into focused discrete action in continguous and continuous OODA feedback loops absorbing and learning mistakes along the way. I had trouble reading this without falli…

Thanks for introducing me to that, it was enjoyable to listen to Allen. [1] https://www.youtube.com/watch?v=MVGoY9gom50

My pleasure :)

But to my chagrin, I just realized that the reading cadence I had in mind wasn't Allen Ginsberg's, but instead Jack Kerouac's. [0]

[0] https://youtu.be/3LLpNKo09Xk?t=197

Re: Intel Problems

#296

Post by leshow »

lambda wrote: post #287
kllrnohj wrote: post #192

Earlier quoted context omitted.

> weaknesses of x86 and CISC in general "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 pro…

RISC vs CISC isn't really about instructions doing "one simple thing period." 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 commi…

> I'm willing to bet that creates a significant bottleneck on how large of a dispatch and reorder system they can have

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...

Re: Intel Problems

#297

Post by tomp »

davish wrote: post #274
old-gregg wrote: post #270

Earlier quoted context omitted.

> 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? 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 wi…

I think we can look to mobile to see how feasible this might be: consistently over the past decade, iPhones have matched or exceeded Android performance with noticeably smaller capacity batteries. A-series chips and Qualcomm chips are both ARM. Apple's tight integration comes with a cost when it comes to flexibility, and, you can argue, developer experience, but it's clearly not just the silicon itself that leads to…

I wonder to what extent that's a consequence of Apple embracing reference counting (Swift/Objective C with ARC) while Google being stuck on GC (Java)?

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).

Re: Intel Problems

#298

Post by BanazirGalbasi »

jjoonathan wrote: post #283
rauhl wrote: post #263

Earlier quoted context omitted.

> 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 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,…

> GNU/Linux laptops 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:…

Historically, Thinkpads have had excellent support. My T430S is great (although definitely aging out), and apparently the new X1 Carbons still work well. Also, both Dell and Lenovo have models that come with Linux if desired, so those are probably good ones to look at.

Re: Intel Problems

#299

Post by jjoonathan »

mrj wrote: post #290
jjoonathan wrote: post #283

Earlier quoted context omitted.

> GNU/Linux laptops 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:…

Most companies wouldn't end up trying to shove a disk into a computer though, they would buy from a vendor with support and never have compatibility issues. I have owned 3 System76 computers for this reason...

> they would buy from a vendor with support

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.

Re: Intel Problems

#300

Post by PaulDavisThe1st »

ralph84 wrote: post #195
jorblumesea wrote: post #115

Earlier quoted context omitted.

Really, you could make the argument for any AWS service and generally using a cloud service provider. You get into the cloud, use their glue (lambda, kinesis, sqs etc) and suddenly migrating services somewhere else is a multi-year project. 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.

Heck, Amazon themselves got locked-in to Oracle for the first 25 years of Amazon's existence. Vendor lock-in for your IT stack doesn't prevent you from becoming a successful business.

True, true (and heh, it was me who pushed for Oracle, oops)

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?

Post reply on HN