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

311–320 of 431 posts

Re: Intel Problems

#311

Post by okl »

spideymans wrote: post #257
WoodenChair wrote: post #158

Earlier quoted context omitted.

> We actually have a lot of insight in that Intel still doesn't have a good grasp on the problem. Their 10nm was supposed to enter volume production in mid 2018, and they still haven't truly entered volume production today. Additionally Intel announced in July 2020 that their 7nm is delayed by at least a year which means they figured out their node delay problem. Knowing something happened is not the same as knowing…

I'll also add that it's fascinating that both 10 nm and 7 nm are having issues. My understanding (and please correct me if I'm wrong), is that the development of manufacturing capabilities for any given node is an independent process. It's like building two houses: the construction of the second house isn't dependent on the construction of the first. Likewise, the development of 7 nm isn't dependent on the perfection…

I think that's not quite right. While it's true that for each node they build different manufacturing lines, generating the required know-how is an iterative/evolutionary process in the same way that process node technology usually builds on the proven tech of the previous node.

Re: Intel Problems

#312

Post by surajrmal »

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

I develop on GNU/Linux begrudgingly. It has all of my tools, but I have a never-ending stream of issues with WiFi, display, audio, etc. As far as I'm concerned, GNU/Linux is something that's meant to be used headless and ssh'd into.

Re: Intel Problems

#313

Post by geogra4 »

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 think there are serious concerns about Qualcomm's commitment to competitive performance instead of just being a patent troll. I think if AWS Graviton is followed by Microsoft[0] and Google[1] also having their own custom ARM chips it will force Qualcomm to either innovate or die. And will make the ARM landscape quite competitive. M1 has shown what's possible. MS and Google (and Amazon) certainly have the $$ to match what Apple is doing.

0:https://www.datacenterdynamics.com/en/news/microsoft-reporte... 1:https://www.theverge.com/2020/4/14/21221062/google-processor...

Re: Intel Problems

#314

Post by adrian_b »

kllrnohj wrote: post #302
adrian_b wrote: post #254

Earlier quoted context omitted.

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…

I was looking at the same image.

A very large part of the die is not labelled and it must include some blocks that cannot be omitted from the CPU, e.g. the PCIe controller and various parts from the memory controller, e.g. buffers and prefetchers.

The area labelled for the memory channels seems to contain just the physical interfaces for the memory, that is why it is small. The complete memory controller must include parts of the unlabelled area.

Even if the CPU part of M1 would be smaller, e.g. just a quarter, that would be 30 square mm. In the 32 nm technology that would likely need much more than 1000 square mm, i.e. it would be impossible to be manufactured.

The number of transistors claimed for various CPUs or GPUs is mostly meaningless and usually very far from the truth anyway.

The only thing that matters for estimating the costs and the scaling to other processes is the area occupied on the die, which is determined by much more factors than the number of transistors used, even if that would have been reported accurately. (The transistors are not identical, they can have very different sizes and the area of various parts of a CPU may be determined more by the number of interconnections than by the number of transistors.)

Re: Intel Problems

#315

Post by eitland »

ogre_codes wrote: post #304
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,…

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

> Has Linux desktop share been increasing lately?

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.

Re: Intel Problems

#316

Post by mitjam »

oblio wrote: post #229
cozzyd wrote: post #222

Earlier quoted context omitted.

it will probably be a similar situation to x86, with various vendors implementing various instructions in some processors that won't be supported by all. I guess the difference is that there may be many more variants than in x86, but performance-critical code can always use runtime dispatch mechanisms to adapt.

It's true that there are extensions to x86, but 99,99% of software out there (the one you'd commonly install on Windows or find in Linux distribution repos) doesn't use those instructions or maybe just detects the features and then uses it. 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 :-)

Audio software usually runs better on Imtel than on AMD.

Re: Intel Problems

#317

Post by Koshkin »

surajrmal wrote: post #312
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,…

I develop on GNU/Linux begrudgingly. It has all of my tools, but I have a never-ending stream of issues with WiFi, display, audio, etc. As far as I'm concerned, GNU/Linux is something that's meant to be used headless and ssh'd into.

Try a Raspberry Pi. It just works.

Re: Intel Problems

#318

Post by rurp »

ogre_codes wrote: post #304
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,…

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

As much as I would like it to happen, I think it's unlikely Linux will be taking any market share away from Macs. That said, I could imagine it happening a couple ways. The first being an increasingly iPhonified and restricted Mac OS that some devs get fed up with.

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.

Re: Intel Problems

#319

Post by koheripbal »

mc10 wrote: post #251
npunt wrote: post #209

Earlier quoted context omitted.

Ben missed an important part of the geopolitical difference between TSMC and Intel: Taiwan is much more invested in TSMC's success than America is in Intel's. Taiwan's share of the semiconductor industry is 66% and TSMC is the leader of that industry. Semiconductors helps keep Taiwan from China's encroachment because it buys them protection from allies like the US and Europe, whose economies heavily rely on them. To…

> Semiconductors helps keep Taiwan from China's encroachment because it buys them protection from allies like the US and Europe, whose economies heavily rely on them. Are there any signed agreements that would enforce this? If China one day suddenly decides to take Taiwan, would the US or Europe step in with military forces?

https://en.wikipedia.org/wiki/Taiwan_Relations_Act

> The Taiwan Relations Act does not guarantee the USA will intervene militarily if the PRC attacks or invades Taiwan

Re: Intel Problems

#320

Post by benibela »

singhrac wrote: post #69
mhh__ wrote: post #20

Earlier quoted context omitted.

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

I profile in valgrind :/
Post reply on HN