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

301–310 of 431 posts

Re: Intel Problems

#301

Post by acdha »

Slartie wrote: post #132
treve wrote: post #107

Earlier quoted context omitted.

Maybe I'm missing something, but don't the vast majority of applications don't care about what architecture they run on? The main difference for us was lower bills.

Even if the applications don't care, there's still the (Docker) container, which cares very much, and which seems to be the vehicle of choice to package and deliver many cloud-based applications today. Being able to actually run the exact same containers on your dev machine which are going to be running on the servers later is definitely a big plus.

Docker has had multiarch support for a while and most of the containers I’ve looked at support both. That’s not to say this won’t be a concern but it’s at the level of “check a box in CI” to solve and between Apple and Amazon there’ll be quite a few users doing that.

Re: Intel Problems

#302

Post by kllrnohj »

adrian_b wrote: post #254
kllrnohj wrote: post #243

Earlier quoted context omitted.

> To achieve its very high IPC, M1 multiplies a lot of internal resources and also uses very large caches. All those require a huge number of transistors. Yes & no. Most of the M1 die isn't spent on CPU, it's spent things like GPU, neural net, and SLC cache. A "basic" dual-core CPU-only M1 would be very manufacturable back in 2011 or so. After all, Intel at some point decided to spend a whole lot of transistors addin…

True, but the M1 CPU, together with the necessary cache and memory controller still occupies about a third of the Apple M1 die. In the Intel 32-nm process, the area would have been 30 to 40 times larger than in the TSMC 5 nm process. The 32-nm die would have been as large as a book, many times larger than any manufacturable chip. By 2011, 2-core CPUs would not have been competitive, but even reducing the area in half…

Where are you getting your M1 CPU + memory controller is about a third of the M1 die from? Looking at this die shot + annotation: https://images.anandtech.com/doci/16226/M1.png The firestorm cores + 12MB cache is far less than 1/3rd the die, and the memory controller doesn't look particularly large.

The M1 total is 16B transistors. A 2700K on Intel's 32nm was 1.1B transistors. You're "only" talking something like ~4x the size necessary if that. Of course the 2700K already has a memory controller on it, so you really just need the firestorm cores part of the M1. Which is a _lot_ less than 1/3rd of the die size.

But lets say you're right and it is 1/3rd. That means you need ~5B transistors. Nvidia was doing 7B transistors on TSMC's 28nm in 2013 on consumer parts (GTX 780)

Re: Intel Problems

#303

Post by yesbabyyes »

agloeregrets wrote: post #84
BenoitEssiambre wrote: post #71

Earlier quoted context omitted.

Yeah and I assume we are going to see Graviton/Amazon linux based notebooks any day now.

Honestly, if Amazon spun this right and they came pre-setup for development and distribution and had all the right little specs (13 and 16 inch sizes, HiDPI matte displays, long battery life, solid keyboard, macbook-like trackpad) they could really hammer the backend dev market. Bonus points if they came with some sort of crazy assistance logic like each machine getting a pre-setup AWS Windows server for streaming wi…

Like a Bloomberg machine for devops.

Re: Intel Problems

#304

Post by ogre_codes »

rauhl wrote: post #263
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…

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

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

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.

Re: Intel Problems

#305

Post by tgtweak »

mdasen wrote: post #253
tgtweak wrote: post #182

Earlier quoted context omitted.

I don't feel that there is a meaningful TSMC alternative today. Samsung, Intel and GlobalFoundries are not suitable replacements for TSMC with regards to throughput or technology. The world does need some meaningful fabs outside of Taiwan/South Korea. All of the 10nm semiconductor fabrication takes place within a 750km/460mile radius circle today. That is risky. Israel, Mexico, Germany, Canada, Japan (not that it wou…

I mostly agree that there isn't a great alternative to TSMC, but I would point out that the 2021 Qualcomm Snapdragon 888 processors are being made by Samsung with their 5nm process (in addition to their new Exynos 2100). Intel and GlobalFoundries aren't really replacements, but Samsung has been winning business for latest-generation flagship processors. Maybe it isn't as advanced as TSMC and maybe Samsung will have p…

It's still within that circle. Samsung is a great fab, probably the only real contender to TSMC. Samsung is 17% global semiconductor demand vs TSMC at 50%+. Included in that 17% is all of Samsung's demand (Exynos, SSD/storage, memory, etc).

Further agitating the issue, South-Korean SK-Hynix is buying Intel's nand business this year and will likely shift production out of intel's US fabs when it comes time.

Re: Intel Problems

#306

Post by jjoonathan »

BanazirGalbasi wrote: post #298
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:…

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.

I'll have to look into modern thinkpads. I had a bad experience about ~10 years ago, but it wouldn't be fair to bring that forward.

> both Dell and Lenovo have models that come with Linux

Like the Dell Precision M6800 above? Yeah. Mixed bag.

Re: Intel Problems

#307

Post by willtim »

tomp wrote: post #297
davish wrote: post #274

Earlier quoted context omitted.

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

Java can be slow for many complex reasons, not just GC. Oracle are trying to address some of this with major proposals such as stack-allocated value types, sealed classes, vector intrinsics etc, but these are potentially years away and will likely never arrive for Android. However, a lot of Androids slowness is not due to Java but rather just bad/legacy architectural decisions. iOS is simply better engineered than Android and I say this as an Android user.

Re: Intel Problems

#308

Post by jjoonathan »

tomp wrote: post #297
davish wrote: post #274

Earlier quoted context omitted.

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

Not to mention it took Android about a decade longer than iPhone to finally get their animations silky smooth. I don't know if the occasional hung frames were the results of GC, but I suspect it.

Re: Intel Problems

#309

Post by kllrnohj »

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…

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

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.

Re: Intel Problems

#310

Post by majormajor »

rauhl wrote: post #263
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…

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

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

Sadly, fewer of my coworkers use Linux now than they did 10 years ago.

Post reply on HN