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

381–390 of 431 posts

Re: Intel Problems

#381

Post by mulmen »

alsetmusic wrote: post #364
mulmen wrote: post #362

Earlier quoted context omitted.

Big Sur has me more worried about iOS-ification than ever before. The UI is a train wreck. It looks designed for touch and I have no idea why. I guess Sidecar? 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 deskt…

> 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? 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. T…

Yeah exactly. I understand what is going on here. I’m just frustrated I have to suffer through it for the vanity of Not-Jony-Ive.

Re: Intel Problems

#382

Post by ogre_codes »

mulmen wrote: post #362
ogre_codes wrote: post #324

Earlier quoted context omitted.

> The second would be Apple pushing all MacBooks to M1 too soon, breaking certain tools and workflows. 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,…

Big Sur has me more worried about iOS-ification than ever before. The UI is a train wreck. It looks designed for touch and I have no idea why. I guess Sidecar? 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 deskt…

> My biggest frustration is that they were willing to make such drastic changes to the desktop UI at all.

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.

Re: Intel Problems

#383

Post by dogma1138 »

altcognito wrote: post #89
TheOtherHobbes wrote: post #76

Earlier quoted context omitted.

The point is Intel can't compete as a fab or as a design house. 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 exist…

AMD looked just as bad not so long ago.

AMD looked far worse... if Intel is “dying” with a yearly revenue of ~$70B or so AMD should’ve been bankrupt 10 times already.

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.

Re: Intel Problems

#384

Post by jayd16 »

wmf wrote: post #196
jayd16 wrote: post #135

Earlier quoted context omitted.

I guess I don't understand why the M1 makes developing on Graviton easier. It doesn't make Android or Windows ARM dev any easier. 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?

It's not hope; ARM64 is compatible with ARM64 by definition. The same binaries can be used in development and production. Windows ARM development (in a VM) should be much faster on an M1 Mac than on an x86 computer since no emulation is needed.

>It's not hope; ARM64 is compatible with ARM64 by definition

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.

Re: Intel Problems

#385

Post by rapsey »

jlawer wrote: post #321
rapsey wrote: post #220

Earlier quoted context omitted.

The vast majority of code running is in python, js, jvm, php, ruby, etc. Far removed these concerns.

Some of those languages (especially python & php) utilise C based modules or packaged external binaries. Both of which have to be available / compatible with ARM. 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.

Those are pretty minor issues that will be fixed as arm servers get more popular

Re: Intel Problems

#387

Post by [deleted] »

azinman2 wrote: post #334
sanxiyn wrote: post #271

Earlier quoted context omitted.

I think it's just a difficult problem. Intel is trying to do 10 nm without EUV. TSMC never solved that problem because they switched to EUV at that node size.

Why do they not want to use EUV?

[deleted]

Re: Intel Problems

#388

Post by jabl »

ineedasername wrote: post #354
MangoCoffee wrote: post #221

Earlier quoted context omitted.

>As for moves again at Taiwan, China hasn't given up that prize. CCP hasn't give up since KMT high-tailed to Taiwan. for more than 40+ yrs American cozy up with the Chinese govrt and doing business with China. American told Taiwan govrt not to "make trouble" but we all know China is the one who make all the troubles with military threat and flying aircraft over Taiwan, day in and day out. Taiwan have build up a impre…

Taiwan's defenses can hold up against minor probing from China, nothing truly sustained. The true deterrent to China isn't any treaty agreement to protect Taiwan, which doesn't exist. It's the realpolitik of 30,000 US troops in Taiwan. Any significant & sustained attack against Taiwan would harm US troops. They'd be little more than a speedbump for China if China acted quickly & in force, but that speedbump would req…

> Taiwan's defenses can hold up against minor probing from China, nothing truly sustained.

It's the same for every small country bordering a potentially hostile much larger neighbor. Nobody excepts the small country to be able to withstand a full-scale invasion. The point is to make that invasion expensive enough to not be worth it.

Re: Intel Problems

#389

Post by Zardoz84 »

dragontamer wrote: post #98
Const-me wrote: post #92

Earlier quoted context omitted.

Building server software on Graviton ARM creates a vendor lock-in to Amazon, with very high costs of switching elsewhere. Despite using A64 ISA and ARM’s cores, they are Amazon’s proprietary chips no one else has access to. Migrating elsewhere gonna be very expensive. 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…

I'm not necessarily disagreeing with you, but... maybe elaborating in a contrary manner? 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..…

> I'd expect that migrating between Graviton and Ampere Altra is going to be easier than Intel Skylake -> AMD Zen.

Could you explain what migration problems are between Skylake and Zen, beyond AVX-512 ?

Re: Intel Problems

#390

Post by jabl »

usefulcat wrote: post #225
exmadscientist wrote: post #171

Earlier quoted context omitted.

That doesn't make any sense. The ROB is after instructions have been cracked into uops; the internal format and length of uops is "whatever is easiest for the design", since it's not visible to the outside world. This argument does apply to the L1 cache, which sits before decode. (It does not apply to uop caches/L0 caches, but is related to them anyway, as they are most useful for CISCy designs, with instructions tha…

Maybe it wasn't clear, but the article I linked is saying that compared to M1, x86 architectures are decode-limited, because parallel decoding with variable-length instructions is tricky. Intel and AMD (again according to the linked article) have at most 4 decoders, while M1 has 8. So yes the ROB is after decoding, but surely there's little point in having the ROB be larger than can be kept relatively full by the dec…

Well intentioned as that article may be, it makes plenty of mistakes. For a rather glaring one, no, uops are not linked to OoO.

Secondly, it ignores the existence of uop caches that x86 designs use in order to not need such wide decoders. Some ARM designs also use uop caches, FWIW, since it can be more power efficient.

That doesn't mean that fixed width decoding like on aarch64 isn't an advantage; it certainly is. Also, M1 is certainly a very impressive design, though of course it also helps that it's fabbed on the latest and greatest process.

Post reply on HN