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

391–400 of 431 posts

Re: Intel Problems

#391

Post by jabl »

amluto wrote: post #356
stefan_ wrote: post #72

Earlier quoted context omitted.

Why are people so hung up about the x86 thing? ARM continues to be sold on because everyone has now understood they don't really matter; they are not driving the innovations, they were simply the springboard for the Apples, Qualcomms and Amazons to drive their own processor designs, and they are not setup to profit from that. ARMs reference design isn't competitive, the M1 is. Instruction set architecture at this poi…

I would argue that ISA does matter. Beyond the decode width issue, x86 has some material warts compared to ARM64: The x86 atomic operations are fundamentally expensive. ARM’s new LSE extensions are more flexible and can be faster. I don’t know how much this matters in practice, but there are certainly workloads for which it’s a big deal. x86 cannot context-switch or handle interrupts efficiently. ARM64 can. This comp…

> The x86 atomic operations are fundamentally expensive. ARM’s new LSE extensions are more flexible and can be faster. I don’t know how much this matters in practice, but there are certainly workloads for which it’s a big deal.

There's also the RcPc stuff in ARM 8.3 and 8.4 that could make acquire/release semantics cheaper.

> the x86 ecosystem is full of legacy baggage.

Luckily for ARM servers we have SBSA that adds things like UEFI and ACPI to the ARM platform. :)

Re: Intel Problems

#392

Post by blackrock »

npunt wrote: post #209
ineedasername wrote: post #152

I found the geopolitical portion to be the most important aspect here. China has shown a willingness to flex its muscles on enforcing its values beyond their borders. China is smart, and plays a long game. We don't want to wake up one day and find they've flexed their muscles on their regional neighbors similar to their rare earths strong-arming from 2010-2014 and not have fab capabilities to fall back on in the West…

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…

Taiwan nor TSMC cannot produce the key tool to make this all work: The photolithography device itself.

Only ASML currently has that technology.

And it turns out, the photolithography device isn’t really a plug and play device. It’s very fussy. It breaks often. And it requires an army of engineers (as cheap as possible), to man the devices, and to produce the required yield, in order to make the whole operation profitable.

This is the Achilles’ Heel of the whole operation.

I suspect that China is researching and producing their own photolithography devices, independent of American, or western technology. And when they crack it, then they will recapture the entire Chinese market for themselves. And TSMC will become irrelevant to any strategic or tactical plans for them.

Re: Intel Problems

#393

Post by blackrock »

nine_k wrote: post #237
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…

I bet TSMC has a number of bombs planted around the most critical machines, much like Switzerland has bombs planted around most critical tunnels and bridges. Trying to grab Taiwan with force alone, even if formally successful, would mean losing its crown jewels forever.

TSMC is not really that important. It’s currently only useful for the cutting edge of CPUs, and especially for mobile phones, that can get the battery boost from using a more efficient processor.

Military hardware uses CPU technology that’s 10+ years old, of which the Chinese are capable of fabricating themselves on the mainland. The stuff needs to be rugged, and likely, radiation-proofed.

And besides, isn’t it easier for Switzerland to just launch missiles at the bridges, instead of actively maintaining explosive devices on each bridge?

Re: Intel Problems

#394

Post by john_alan »

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.

The micro-kernel design on macOS has benefits over Linux's monolithic kernel.

You also get POSIX compliance.

Re: Intel Problems

#395

Post by synthc »

narrator wrote: post #285
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,…

This is why you run your environment on Linux and MacOS in Docker, so you don't have these screwy deployment issues caused by MacOs vs Linux issues.

docker om MacOs is a second class citizen, because it runs in a VM. The networking is much more complicated because of this, which causes endless amounts of hard-to-debug problems and performance is terrible.

Re: Intel Problems

#396

Post by saagarjha »

mhh__ wrote: post #20
ashtonkem wrote: post #16

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

Instruments exposes a fair number of counters, though–what's wrong with using it?

Re: Intel Problems

#397

Post by saagarjha »

ncmncm wrote: post #201
DreadY2K wrote: post #176

Earlier quoted context omitted.

Many people do code against some sort of VM, but there are still people writing code in C/C++/Rust/Go/&c that gets compiled to machine code and run directly. Also, even if you're running against a VM, your VM is running on an ISA, so performance differences between them are still relevant to your code's performance.

C, C++, Rust, & Go compile to an abstract machine, instead. It is quite hard these days to get it to do something different between x86, ARM, and Power, except relying on memory model features not guaranteed on the latter two; and on M1 the memory model apes x86's. Given a compatible memory model (which, NB, ARM has not had until M1) compiling for the target is trivial. The x86 memory model makes it increasingly hard…

> which, NB, ARM has not had until M1

This isn't true at all: other ARM cores have gone all the way to implement full sequential consistency. Plus, the ARM ISA itself is "good enough" to do efficient x86 memory model emulation as part of an extension to Armv8.3-A.

Re: Intel Problems

#398

Post by astrange »

john_alan wrote: post #394
Steltek wrote: post #275

Earlier quoted context omitted.

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

The micro-kernel design on macOS has benefits over Linux's monolithic kernel. You also get POSIX compliance.

macOS doesn't have a microkernel, but it does have userland drivers and it's pretty good at being macOS/iOS. Linux's oom-killer doesn't work nearly as well as jetsam.

Re: Intel Problems

#399

Post by astrange »

kllrnohj wrote: post #309
lambda wrote: post #287

Earlier quoted context omitted.

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…

Parallelism isn't a good idea when scaling down, nor is concurrency often. Going faster is still a good idea on phones (running the CPU at higher speed uses less battery because it can turn off faster) but counting background services there is typically less than one core free, there is overhead to threading and asyncing, and your program will go faster if you take most of it out.

Re: Intel Problems

#400

Post by astrange »

saagarjha wrote: post #396
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.

Instruments exposes a fair number of counters, though–what's wrong with using it?

I actually recommend just using 'spindump' and reading the output in a text editor. If you just want to look through a callstack adding pretty much any UI just confuses things.
Post reply on HN