Hacker News Reader

Comment by 013a | Hacker News Reader

Intel is a hot mess even without these security disasters.

Just look at their product release lifecycle: In years past, they'd get maybe one extra product release off each new arch (tick/tock); for example, Sandy Bridge bore Ivy Bridge and Haswell bore Broadwell.

Skylake has born SIX new product lines; Goldmont, Goldmont Plus, Kaby Lake, Kaby Lake Refresh, Coffee Lake, and the upcoming Cannonlake. Their failed 10nm shrink has forced product delays; remember, Cannonlake (the 10nm shrink of Skylake) was supposed to be released in 2016, and its not even out yet. Just at CES this week they said they've shipped mobile Cannonlake CPUs.

They have zero presence in mobile. Their best efforts involve competent Y-series processors. Then Apple comes around and, seemingly without even trying, destroys them [1] with a product that's more thermally efficient and, in some ways, more powerful than Intel's best mobile processors, not just their thermally efficient ones.

They have little presence in HPC/AI, where Nvidia is slaughtering everyone and its not even close.

Its completely inevitable they're going to lose Apple as a customer for consumer products; its just a matter of time. AMD is gaining traction with Zen, and they're moving in the direction enterprise cloud provider want (lots of cores, not much $$). How much longer can Intel keep holding on? Do they have an ace they've been hiding? Will people even trust their ace after Meltdown?

[1] https://9to5mac.com/2017/06/14/ipad-pro-versus-macbook-pro-s...

View on HN

I agree with your general thrust though I think you are overstating a few points significantly.

> Skylake has born SIX new product lines; Goldmont, Goldmont Plus

Goldmont, Goldmont Plus are Atom products and are not "Skylake-derived" in any really major sense.

> zero presence in mobile

This is true only if you disregard the traditional laptop and newer convertible and chromebook markets. More importantly, Intel has an admittedly-indirect but financially very significant presence in the mostly-ARM cell phone and tablet markets, in that the backend for pretty much every cellphone app runs on an x86_64 server core somewhere. Every cell phone and tablet sold helps sell a modest fraction of an x86_64 core too.

> little presence in HPC/AI

Again, every major HPC/AI deployment that I've heard of still has a huge number of Intel cores. Though - as with the cell phone and tablet markets - you can definitely fault Intel for not capturing these markets in their entirety; they certainly had the talent, IP and the capital to do so, but they screwed up strategically in a way that will almost certainly become a cliched business school study at some point, if it's not already.

Regarding HPC I think people here are missing the real problem for Intel: Yes, they still have a strong showing in Top500 systems. But this could easily change soon because there is not that much keeping system developers from switching to AMD, potentially rven ARM. At the same time NVIDIA is essentially in a hard to replace position because an increasing percentage of applications is written to get their FLOPS from their GPUs instead of Intel‘s offerings.

The way Intel tries to fight back I find questionable. Both their MIC lineups and many-core Xeons suffer from a crucial flaw: Almost laughably low memory bandwidth when compared to NVIDIA, even compared to Epic. They rely so heavily on caching that it would require tremendous software efforts to get even in the range of 50% of the performance of GPU ports - I‘d argue it‘s significantly more difficult and less performance portable to do that rather than just do a basic GPU implementation, even with manually handled data transfers.

Add to this the increasingly successful efforts by GPU makers to automate data handling and Intel‘s attractiveness only dwindles further.

And now people are told that they might loose 20% performance? There‘s applications that use these chips like it were real-time systems (because it‘s the only thing financially possible for them). For these use cases, 20% will hurt, a lot.

/rant

There‘s applications that use these chips like it were real-time systems (because it‘s the only thing financially possible for them). For these use cases, 20% will hurt, a lot.

Applications that use these chips in a realtime capacity don’t share hardware with other apps, so it will be possible to deploy them on unpatched machines, even if inconvenient. Those workloads are also not big on context switching and so not affected much by the patch.

I think cloud hosting providers will hurt the most, because that tends to be a context-switch-heavy workload, and their pricing model assumes a certain level of performance per core. They’ll mix in AMD in significant quantities just to diversify and avoid getting burned in the same way. They’re probably also the biggest market for intel’s server line.

This incident will seriously hurt intel even if they handle it perfectly, which they’re not doing.

Yes, that's a good point. The sharing of hardware over the internet (aka the 'cloud') is the most critical market here. Though, I think there's a lot of cross pollination between cloud and HPC markets - if AMD is financially successful with Zen they'll be able to pour more R&D money into fortifying their position. The question is of course whether that's going to be enough - Intel came back and beat out all competition after their last big loss of market share (~2005, 95nm process spawning AMD64 / Opteron). I'd argue that the Intel of 2018 is not the Intel of 2005. From what I'm hearing/reading, they've had an ongoing brain drain from being too much focused on short term profits versus taking real risks in developing new technologies as well as putting up the finances to actually secure and test their cash cows.

But this could easily change soon because there is not that much keeping system developers from switching to AMD, potentially rven ARM

Right, you can very easily imagine a machine whose CPU merely marshals and dispatched work to compute elements, be they GPUs, FPGAs, ASICs, TPUs, whatever. You don’t need an all-singing all-dancing Xeon for that...

… Or a Threadripper.

There might be other reasons Intel isn't doing it the nVidia way. Patents are good at blocking progression for example.

Looking at the patent landscape of 3D memory [1] I don't really see the issue that Intel would be facing. First of all, as a chip maker they seem to have completely withdrawn from the base level science in memory in the first place, which probably hurts them from getting favourable patent deals - but this seems to be a management level blunder, maybe an overreaction to the Pentium 4 proprietary RAM flop.

In any case it would IMO be better to just now license 3D memory at market cost rather than just sitting on the hands and let HPC markets fade away.

Remember, it has historically only taken 8-10 years for HPC developments to scale down to people's pockets - it could well be that the next iPads outperform what Intel can offer as x86 based laptops, which will not be a good look for software developers deciding which platform they should choose for the next potential killer app.

[1] http://www.wipo.int/edocs/plrdocs/en/lexinnova_plr_3d_stacke...

>Pentium 4 proprietary RAM flop

You mean RDRAM?

yes. even googling it everyone just talked about DDR back then, that‘s why I couldn‘t find it anymore.

> the backend for pretty much every cellphone app runs on an x86_64 server core somewhere

Intel is not the entirety of x86_64 servers, and as the GP notes, AMD is going in the better direction with Zen for serving all those requests than Intel is at the moment.

As an aside, because it doesn't really matter to the point, x86_64 is actually an AMD extension that Intel licenses from them.[1]

1: https://en.wikipedia.org/wiki/X86-64#Licensing

I agree there is a good chance they will lose a material share over the coming 1-2 years to epyc, but at the moment, the x86_64 server market is almost 100%-Intel.

Old Opterons are still around too. Heck, cheap dedicated servers at Hetzner are repurposed desktop Athlon 64s :D

> "In years past, they'd get maybe one extra product release off each new arch (tick/tock)"

Intel has moved away from the tick/tock release cycle. They now work to what they call process/architecture/optimization, or in more familiar unofficial terms tick/tock/tweak.

Moore's law is essentially broken now, and this isn't just an Intel problem, this is a problem for all the major chip manufacturers. Furthermore, the challenges and cost of future node shrinks is also causing a slowdown in progress in integrated circuit manufacturing. We may get a couple more node shrinks, but we should prepare ourselves for the brick wall that we're likely to hit in the next decade.

«They now work to what they call process/architecture/optimization, or in more familiar unofficial terms tick/tock/tweak.»

For this cycle it's been tick/tock/tweak/tweak. Sounds like a broken clock.

As the bitkeeper guy, I'm watching this with amusement. Intel used BitKeeper for over a decade for their RTL and when they used BK things seemed fine. We did everything that Intel wanted, at one point I realized we had taken $7M of revenue from other customers over the years and spent it on doing work for Intel. And that was still not enough for them.

They switched to git because free is better (we were a rounding error on a rounding in terms of cost to Intel, the most they ever paid us in a year is .00000004 of their revenue).

But that was too much so they switched to git and it's been downhill for them ever since.

I'm not an idiot, I don't think that the switch to git is the cause of their problems, their problems are self inflicted. I'm just one of many many vendors that Intel has fucked over. So I like seeing them squirm.

Karma is a bitch Intel.

Edit: yup, knew I'd get down voted. Don't care. Try being an Intel vendor and get back to me about how much you like that.

I don't really get it. You seem to be complaining that a party chooses to no longer be your customer? Isn't it their full right to decide so? What makes discontinuing a business relationship more "fucking you over" than you "fucking over the supermarket" by choosing to go to another supermarket?

McFly's right, if a bit sensational (ehhh, it's his style.)

However, as poorly as they treat their vendors, it's nothing compared to what they do to their employees and sadly large segments of their first line and middle management not only buy into that but have spent time making that into an art form.

What do they do to their employees?

Ask them to sign NDAs.

@luckydude isn't just some random troll.

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

It seems unfair that you are taking it out on Intel for dropping your product-- when in fact, the entire industry dropped your product. Git is free, more widely supported, open-sourced, and doesn't get angry when a user stops using it. Technology evolves - best not to pick at old scabs.

I could go into details about how they screwed us but that is perhaps a thread of its own. We bitch slapped them at the end when I finally grew a pair (after years and years of just doing whatever they wanted).

If you are an Intel vendor you will like this tidbit, they were on our paper. Not their agreement, they agreed to our paper. I think we are the only small vendor that they ever did business with where they didn't force their terms into the deal.

Looking at CVs, everyone knows git. Using anything else would require not just licence costs. Also training and potentially reducing the pool of possible hires.

BK predates Git by quite a while. The free alternatives then were sccs, cvs, rcs, etc.

That doesn't change anything. Older or not, people use git.

Because you came up randomly with your disappointment absolutely unrelated to today's topic, I'm tempted to give you another unrelated news: the Linux project has stopped using Bitkeeper too.

This is super uncalled for.

In some ways it's been closer to tick/tock/tweak/tweak/tweak, which is just another sign that improving process nodes isn't something that we should rely on anymore.

For this cycle the 'tick' (Cannon Lake) was pushed back a year (with two 'tweaks', Kaby Lake Refresh and Coffee Lake, taking its place). Cannon Lake devices are due to be released to the mass market this year, and according to Intel it was able to manufacture some Cannon Lake devices last year:

https://en.wikipedia.org/wiki/Cannon_Lake_(microarchitecture...

"At CES 2018 Intel announced that they had started shipping mobile Cannon Lake CPUs at the end of 2017 and that they would ramp up production in 2018."

The present evidences show that one should not trust Intel announcements. They may ship CPUs based on their 10nm process, but it is not clear that they managed to resolve all their yield issues.

If Mores law could be broken, mabe the continued economic growth is in danger too?

unlikely to be linked... increasing cache or writing better algorithms will make things faster...

Many industries are held back by lack of interoperability, rather than raw computer power.

> "increasing cache or writing better algorithms will make things faster"

There are performance ceilings on those as well. Best case scenario we come up with a new architecture that is more efficient than the current ones (something built around reconfigurable chips could be ideal). However, we will eventually reach a point where computers don't get significantly faster. Maybe it takes 20 years, maybe it takes 30 years, but there will come a point where that happens.

> However, we will eventually reach a point where computers don't get significantly faster.

Help me understand why. Even if individual computational units cannot get faster, can we not benefit from additional computational units? I know that these don't scale linearly but I suspect there remains work that can be done to improve scaling. Isn't that where GPUs get their computational power?

> "Isn't that where GPUs get their computational power?"

GPUs get their power from being able to execute multiple calculations in parallel. Rendering a 3D scene is something that lends itself to being processed in parallel, for example on a simple level you can have different cores each rendering a different section of the overall image (tile-based rendering is one example of an approach that benefits from this: https://en.wikipedia.org/wiki/Tiled_rendering ).

The GPGPU uses of GPUs (i.e. non-graphics uses) also take advantage of this parallel processing power.

The issue is, not all computing workloads are easy to split up into smaller workloads that can run in parallel. Some workloads are easiest to manage sequentially. For example, consider some code that had a lot of conditional logic (such as "if" statements), where the code executed depended on validating a condition was met. What advantages would you gain from running this code in parallel?

tons of algorithms and software don't run any faster with more cores. Plus each core has a n+1 cost associated with it, whereas with how scaling worked previously you got better performance for cheaper because of size decreases.

The most significant cost in making an ASIC is the silicon wafer, which is extremely expensive, so anything that uses it more efficiently [ less space] makes things cheaper, faster (easier to keep a faster clock synced over a small area), and use less power (less power means you can go faster too, because you have more power/head headroom for cranking clock speeds).

Scaling by going smaller is extremely synergistic, and has super exponential performance impact, whereas in the very best case adding more cores is linear, and in almost every real world case, sub linear. It also costs more, not less.

The fact is baring major breakthroughs, we are stuck with roughly today's level of performance for the foreseeable future.

> tons of algorithms and software don't run any faster with more cores.

> The fact is baring major breakthroughs, we are stuck with roughly today's level of performance for the foreseeable future.

That's obviously false. Otherwise graphics wouldn't get any faster when you add more GPU cores, to name one common embarrassingly parallel problem.

Our software is just really bad at making use of those extra cores. Measure real-world use cases with a well-tuned work stealing engine and you'll see how much performance we're leaving on the table.

(Source: I wrote the first version of possibly the largest consumer deployment of a major software component backed by a work stealing engine.)

>The fact is baring major breakthroughs, we are stuck with roughly today's level of performance for the foreseeable future.

Maybe finally we stop wasting hardware and use the supercomputers we have in our pockets for greater things.

Another thing to consider is that memory access is still the most prevalent speed problem. If we can work on these bottlenecks we can still get significant performance increases without actually increasing CPU performance that much.

Intel having little presence in HPC is a laughable claim. There are plenty of Intel Xeons on the TOP 500 https://www.top500.org/list/2017/06/ and these Nvidia GPUs don't run themselves.

> these Nvidia GPUs don't run themselves

It's only a matter of time before they do. Nvidia's Drive PX platform is Intel-free and something derived from it might look interesting for HPC and/or high-end workstations in the next few years.

Serious question. How likely is for Nvidia to become relevant in the CPU space in the next 10-15 years? (talking specifically about their attempts in this market with things like Tegra)... OR is their goal to keep optimizing form factor, thermal efficiency, energy consumption, etc...to the point they can make a case for a stand-alone GPU effectively replacing a CPU?

They've already build their own ARM cpu's, they are in the TX1, Nintendo Shield for example. Their most recent Volta GPU made significant progress in terms of general purpose programmability, it gained a much more flexible memory and concurrency model compared to previous chip generations. They also partner with IBM by supporting OpenCAPI for HPC.

*Nintendo Switch, Nvidia Shield

> https://riscv.org/wp-content/uploads/2016/07/Tue1100_Nvidia_...

It’s a controller, but if risc-v become established, then the acquired knowledge might be applied in CPU development.

I've long felt that nVidia is going to rise from the ashes of Intel, not AMD.

They are also capable of integrating with Power9 via OpenCAPI, which is the configuration in which many of the Volta based HPC cards by Nvidia will be used in.

Correction: While Nvidia is a member of the OpenCAPI Consortium and thus doing work on OpenCAPI, at present the interface between the Nvidia Teslas and POWER9 chip is NVLink 2.0.

On POWER9, both NVLink 2.0 and OpenCAPI are implemented using the same PHY. However, above that level they're completely separate protocols.

(I work on OpenCAPI drivers and firmware at IBM)

Thanks for the info! Can you tell me how many nvlink Lanes are used? Do you have any benchmarks showing performance of copies compared to pcie?

Geekbench is a somewhat odd collection of benchmarks, I'd be careful reading too much into it.*

Furthermore, the site you link to, which is clearly rather gung-ho about macs, still shows that the ipad was not able to keep up with the intel chips, not even in multithreaded mode, even though the intel has 2 cores to the a10x's 3+3. The ipad beat the MBP on the GPU tests, and I don't think anybody is going to dispute that intel's gpu's are... not exactly record-breaking.

Still, you're totally right that apple demonstrated that intel's tech isn't the uniquely fast chip you might think it to be! It's not a small achievement to come this close, especially if the ipad is using less power (which isn't actually clear - battery capacity is roughly similar, at any rate).

* The reason I don't like geekbench as a cpu test is that it includes a great many tests like FFTs, gaussian blurs, jpeg with DCTs, image processing, and crypto (even in the noncrypto segment!) etc - i.e. workloads that are very, very vectorizable. The problem with that is that such workloads are really tricky to get right - small differences in code can make considerable difference in perf, and what's right for one CPU isn't for another (notably, geekbench is necessarily running completely different code on these processors). Secondly, those kinds of workloads are very, very amenable to special-purpose instructions, which leads me to the related point that I don't think they're representative of what is typically annoying slow today, and much less what is likely to matter tomorrow: these kind of workloads are either good enough on the CPU as-is, or they're going to be moved to the GPU (or even more specialized hardware), which happens to excel at that.

> Their failed 10nm shrink has forced product delays

This is the most important thing. AMD has already made the switch to Multi Chip Modules which makes it much much easier to produce chips for 10nm (what TSMC/GF/Samsung call 7nm).

Right now Intel cant even make a dual core low speed mobile chip on 10nm. How are they going to make a giant 30+ core server processor? This is extremely bad news for them that has not been fully realized by the markets because they have faith that Intel will figure it out, but they may not.

AMD may ship 7/10nm server chips before Intel and Intel may never ship them before switching to MCM themselves.

MCM is as revolutionary as AMD64 was but most people dont realize yet how important it is and how much of an advantage AMD has because of leading with it.

AMD may be shipping server CPUs as MCMs while Intel isn't, but that doesn't mean AMD has a meaningful lead. Intel's Embedded Multi-Die Interconnect Bridge (EMIB) [0] technology is far more advanced than any MCM tech AMD has available, to the point that AMD is using Intel's EMIB to connect an AMD GPU to its DRAM in an upcoming Intel product [1].

When Intel gets around to making a multi-die CPU using EMIB, it'll blow away AMD's EPYC in terms of bandwidth between dies.

[0] https://www.intel.com/content/www/us/en/foundry/emib.html

[1] https://www.anandtech.com/show/12003/intel-to-create-new-8th...

> AMD is using Intel's EMIB to connect an AMD GPU to its DRAM in an upcoming Intel product

It is Intel's CPU using AMD's GPU. I am not sure how this is evidence that EMIB is superior tech. Of course Intel is going to use their own tech wherever possible.

> When Intel gets around to making a multi-die CPU using EMIB, it'll blow away AMD's EPYC in terms of bandwidth between dies.

Do you have any bandwidth numbers on EMIB to support this? There are other sources saying that EMIB is crap and doesn't interface with HBM without using a bridge provided by TSMC. [1]

[1] https://semiaccurate.com/2017/12/19/intels-claims-fpgas-hbm-...

Make sure to take SemiAccurate's name seriously.

That article doesn't say EMIB is broken, it just says that the FPGA product Intel/Altera announced wasn't actually natively designed to use EMIB to interface with HBM. This is not relevant to a discussion of whether two Intel CPU dies could be connected over EMIB.

We do know that the Intel CPU with an AMD GPU on-package will have a much faster interconnect between the dGPU and its HBM2 over EMIB than AMD's EPYC and Threadrippper manage between CPU dies with a conventional MCM. It's also faster than Intel's old Crystalwell parts that used a conventional MCM to add an eDRAM L4 cache to a consumer CPU.

The limits of conventional MCM packaging are well-known across the industry and are a problem for everyone who's trying to use HBM-style DRAM or otherwise make high-speed inter-die links. Full-scale silicon interposers with TSVs are really expensive and would not have been adopted in high-end GPUs and FPGAs over the past several years if there was an alternative. Likewise, AMD wouldn't have adopted EMIB for their project with Intel if conventional MCM packaging were sufficient, because EMIB is still more expensive than not using two kinds of interconnects within the package.

> Likewise, AMD wouldn't have adopted EMIB for their project with Intel if conventional MCM packaging were sufficient

Once again, you are talking about an Intel CPU, so what you are saying makes no sense. It is not AMD's project. It is Intel's CPU that happens to use an AMD component.

> Once again, you are talking about an Intel CPU, so what you are saying makes no sense. It is not AMD's project. It is Intel's CPU that happens to use an AMD component.

The only EMIB in that product is between AMD's GPU and that GPU's DRAM; the Intel CPU die in that product is not using EMIB. The fact that the AMD GPU is using EMIB is significant—it's a somewhat external validation that EMIB has value as an alternative to conventional MCM packaging or large scale silicon interposers, both of which AMD uses for products of their own.

If EMIB wasn't saving money while offering sufficient performance, then Intel would have integrated the AMD GPU into this product using the off-the-shelf silicon interposers that AMD's own products use to connect the GPU to its HBM DRAM.

> If EMIB wasn't saving money while offering sufficient performance, then Intel would have integrated the AMD GPU into this product using the off-the-shelf silicon interposers that AMD's own products use to connect the GPU to its HBM DRAM.

That is a nice claim, based on no evidence.

Intel spends billions subsidizing non-competitive products in order to try to build market share all the time. (mobile, ultrabook, etc, etc)

Unless you can present any evidence to the contrary (still no bandwidth numbers) it is just as likely that this product has EMIB because they couldn't get anyone else to use it and they need some shipping products with the tech to try and sell it.

> Intel spends billions subsidizing non-competitive products in order to try to build market share all the time.

The concept of market share does not apply to EMIB. It's an internal implementation detail, and Intel gains nothing from using EMIB in one of their own products over a cheaper solution that would still result in the end product being an Intel-branded part.

The only motivation that Intel could possibly have to use EMIB as any kind of loss-leader would be to entice third-party foundry customers to use Intel for the sake of EMIB. But attracting foundry customers is clearly not a priority for Intel, and Intel's primary goal with EMIB is to produce Intel products that may incorporate some third-party silicon, not to produce silicon to be incorporated into third-party products.

I don't understand. How does the CPU talk to the GPU on that product? What bridge the GPU die to the CPU die? Sounds like you are saying the CPU doesn't talk to the GPU over EMIB.

> Sounds like you are saying the CPU doesn't talk to the GPU over EMIB.

Correct. There's a conventional link through the package substrate carrying the PCIe signals from the CPU to the GPU. The only EMIB on that product is between the GPU and its DRAM. That's why the GPU and its DRAM are adjacent, while the CPU is about 1cm away from them: https://images.anandtech.com/doci/12003/intel-8th-gen-cpu-di...

Intel would need to redesign the CPU die to accommodate an EMIB connection to the CPU. As it stands, an EMIB link would probably get in the way of lots of contacts that need to go to something other than the GPU, and EMIB wouldn't be worth the trouble for a relatively narrow and slow link like PCIe. The point of EMIB is to enable very wide and fast links between dies, so that inter-die communication is almost as fast as communication across a single die.

> Intel may never ship them before switching to MCM

Fantastic claims require fantastic evidence.. history shows that there are many ways of fixing or designing-around manufacturing yield problems. Do you have any actual evidence that their 10nm fabs will never yield a competitive monolithic server part in a financially-viable way?

> MCM is as revolutionary as AMD64

I would disagree somewhat, as AMD64 clearly benefits every customer with very little downside, while it is fair to say that MCM CPUs can create or exacerbate irritating performance problems for the customer by being "much more NUMAed". [All else equal, most customers would prefer a monolithic part, or 2 NUMA domains instead of 8-16].

Not quite. 64 bit ran behind 32 bit for a long time after introduction. The rule of thumb was to ask whether more ram or more speed was important. 64bit felt slower to people for a long time. (I swear I can still see the difference 10 years later.) 64 bit didn’t really pull away until 8 gig became common. Something similar may hold for MCM, I don’t know about mcm to speak to that.

We saw substantial performance improvements from the increased register count of AMD64 when I lead the porting effort of a video editing/compositing suite back in the early days.

Because our engine took advantage of memory-mapped unnamed file handles to cache frames, we didn't really need the extra address space of larger pointers. I was able to exhaust system memory by manually managing whether or not buffers were mapped into our address space.

Though it had been made for something else, I lucked into being able to use that same engine for interprocess legacy plug-in support. AMD64 support also wasn't necessary to get more physical memory support out of the chips of the era. Operating systems supported 36 and 40 bit physical address spaces, and applications could use higher (would-be negative) addresses by indicating support for it. Those wanting to really cut loose could turn to manual mapping. (See: PAE, LAA)

In the end, we shipped AMD64 support because there were substantial performance wins. And, yes, I profiled every possible software/hardware combination to determine where gains and losses were coming from.

I'm not saying that things were universally faster/better. RIP-relative addressing, though generally quicker than absolute 64-bit, is a headache, and the loss of 80-bit floating point intermediates broke some rare code (which would have broken in strict mode, anyway). I'd love to see some evidence of slow-down now, but, until then, I'm unconvinced. I had a dev bring me "evidence" of huge performance differences between ARMv7 and ARMv8 a couple of years ago (and there are some if you dig). I asked him if he had compiled with or without thumb in the linked modules.

He let me know of his new results a few days later, a little red-faced.

I'm not saying that your detection of slowness is the same thing, but many aspects of performance are measurable (and measured). If it's slower, we can probably measure just how much.

Yes, if someone said anything about video editing I would suggest a 64 bit system.

To clarify my point: an AMD64 CPU could still run in 32-bit mode, if the customer preferred. Much later, the x86_32 ABI work also retained small pointer sizes while providing additional benefits. Whereas there is no way for a customer to fully "unNUMA" an MCM CPU.

When you say "MCM is as revolutionary as AMD64", does that mean Debian and RedHat and Windows and macOS, and all 3rd party applications, have to be recompiled for a new architecture? Or is it simply an incremental speed-up of existing systems?

I'm led to believe that if we're going to recompile The World as well as build new JIT javascript++ compilers, it will be for ARM64?

> does that mean Debian and RedHat and Windows and macOS, and all 3rd party applications, have to be recompiled for a new architecture? Or is it simply an incremental speed-up of existing systems?

Neither. Multi-chip modules simply make it more economical to manufacture large processors. When you can make a 32-core CPU by connecting two 16-core silicon dies together, you'll have higher yields than if you try to make a monolithic 32-core die. There isn't necessarily any consequence visible to software, with the possible exception of having multiple NUMA nodes per physical socket.

So not an architectural paradigm shift, then - a mostly "invisible" incremental CPU improvement instead?

It's a pretty big increment that Intel has been unable to or unwilling to advance to. The message here is that if Intel drags their feet long enough then it'll take that much longer to catch up -- or, more to the point, they'll be forced to take more drastic (read: expensive) measures to catch up.

Intel has produced multi-die CPUs in the past. They aren't doing it now because their fabrication advantage allows them to make bigger monolithic CPU dies than AMD can afford, so Intel doesn't have to incur the performance penalties that AMD's multi-die CPUs suffer from. At the same time, Intel has been very publicly preparing for the day that it makes sense for them to once again make multi-die CPUs, by making sure they have the technology to do it without the performance hit that is currently necessary. There's no heel-dragging from Intel on this issue.

Once Intel's fab advantage is actually eliminated, they'll be forced to make multi-die CPUs to compete against AMD's multi-die CPUs. But every indication is that Intel will be ready to do multi-die better than AMD is doing multi-die. How much better is up for some debate, but it does look like Intel will have a leg up on EPYC's biggest weakness.

Multi-Chip-Module (Epyc) is just 4 separate dies wired together. (As Intel would derisively point out if is basically 4 Ryzen desktop chips glued together).

The advantage of this architecture is that smaller chips are easier to manufacture because the probability of a random defect rendering the chip useless is lower and when a chip is bad it is not as great of a loss.

Epyc chips run all existing software. There is extra work involved with Non-Uniform Memory Access (NUMA) where if you want software to actually use 32 or 64 cores simultaneously it has to be purposefully designed to take into account the architecture but that is not really any different than developing for multi-processor systems in the past.

The point is that we have hit the ceiling on frequency scaling, which means more cores, and now we have hit the ceiling on core count scaling, so now it is going to be more CPUs, and the best way to do more CPUs is with MCMs.

MCM in itself is old: Xenos in XBox 360 was MCM, IBM's POWER chips have been MCM's in many generations, Intel's Pentium Pro was MCM 1995, etc. Going back to the 80's/70's.

MCM has been relatively unpopular because of cost and that's why most of its applications could justify it only to put chips from different silicon proceseses in same package (cache or EDRAM + CPU usually). Except for some high end chips like the POWER stuff.

The interesting bit is how and why AMD put logic chips in low cost MCMs. Probably involves the time or $$ budget to make and validate additional high end variations of the silicon.

> 10nm (what TSMC/GF/Samsung call 7nm)

What’s the reason for this? From my understanding of numbers, 10 is not 7

"10nm" and "7nm" are marketing terms that are not directly comparable across foundries.

How? I thought the number was the size of the smallest transistor?

The numbers are almost pure marketing, these days.

From https://en.wikipedia.org/wiki/7_nanometer#7_nm_process_nodes

> The naming of process nodes by different major manufacturers (TSMC, Intel, Samsung, GlobalFoundries) is partially marketing driven and not directly related to any measurable distance on a chip – for example TSMC's 7 nm node is similar in some key dimensions to Intel's 10 nm node.

well yeah not really. it's a bit of a long read but it comes down to whom you ask. https://www.extremetech.com/computing/246902-intel-claims-th...

They are measuring different things and use different transistor designs.

> How much longer can Intel keep holding on? Do they have an ace they've been hiding?

They do have an ace. $17 billion in operating income the prior four quarters. And about $17 billion in cash on hand.

Who knows if they'll put it to appropriate use to recover from their present mess. They very clearly have the resources to do so. Intel's $17 billion in operating income is over 4x the revenue of AMD, and 2x the revenue of nVidia. It's a pretty fantastical premise to be already counting Intel out, they've recovered from dramatically worse business situations in their past.

They had $XX billions in income, and were Nx the revenue of AMD for the last 5 years - and, frankly, nothing spectacular/interesting to show. Some arch tweaking, process improvements, that's about it

Under your premise of prior situations predicting future actions, Microsoft should be collapsing about right now as Windows fades. IBM should not exist at all, the largest US corporate loss in history (at the time) that they produced in 1992 should have spelled their nearing end, with them fading into oblivion. Oracle should have died in the software wars, they survived several bet the ranch situations.

You know what was missing the last five years for Intel? Desperation. The need to fight back from a situation that threatens their well-being. They've done it before, usually when they were put in a desperate situation. That's also typical of human behavior in general (which is where the corporate behavior derives from).

> Microsoft should be collapsing about right now as Windows fades.

Microsoft has been reinventing themselves; partly successfully, partly failing (Windows Phone / Nokia acquisition was arguably a recent example of a failure in this regard). Windows and Office are still the primary income for Microsoft, but cloud has gained traction, percentage-wise. Xbox is profitable (it wasn't for a long time). The Surface line is another example of Microsoft reinventing themselves.

> IBM should not exist at all

IBM has been relatively marginalised, and could've been so much more rich if the IBM-PC didn't backfire them with the clones getting popular, plus them getting tricked by Bill Gates with MSDOS and Windows (the failure to collaborate with Microsoft on OS/2). But as the B in IBM suggests, IBM never cared much about the consumer space.

Note, I'm not sure about POWER, how competitive that is with Intel's high-end products. Perhaps someone can comment on that.

I think what a company like Intel needs (or any company, really) is direct competition. Ie they need AMD. The competition with ARM and such is far more vague, less opaque. To be fair, Intel did try to compete on low end, with Atom. I remember they were busy with Moblin/MeeGo in the mid '00s. Never took off AFAIK.

well, that is true, but

- they need to capture/create product niche with volume of sales in XX billions per quarter, otherwise it is not worth the effort

- in their traditional niche they have 90+%, the only way is down, basically

we'll see, but signs are not good. F.e., this idiot (https://www.fool.com/investing/2018/01/19/intel-corps-upcomi...) is hyping some 6/12 cores notebook CPU, while for any reasonable analyst this should be sign of desperation - Intel does NOT KNOW WHAT TO DO WITH SILICONE, so it's just slapping more cores together

> they've recovered from dramatically worse business situations in their past.

Such as?

They abandoned their primary business in memory chips, it was eroding out from under them rapidly (Japanese dumping, tanked their margins and was quickly slashing their share of the market). They bet the company on switching focus instead to the microprocessor business, per Moore & Grove (they both recount the story in various ways in interviews). Had they not done so, Intel would have likely gone out of business.

https://www.realworldtech.com/intel-dram/

Here's a pretty good cover of it from 2012 by NPR, interviewing Grove, in a series they did:

https://www.npr.org/2012/04/06/150057676/intel-legends-moore...

Well, then they still had alternatives. There is not much in terms of alternatives for a broken reputation. Intel's management of this particular crisis hurts them precisely in the one place where they can not afford it.

Three, prior attempts at better CPU's plus one bug if we just go by the numbers. BiiN alone lost at least $300 million. They had to do a straight-up recall over the FDIV at a cost of who knows how many millions. Then, they and HP spent at least half a billion on Itanium over time. So, yeah, they've had some rough times with reactions or losses that are way worse than I've seen so far with this with some microcode updates and bad press. It certainly could get worse but not as bad yet.

Aside from those, I added a link to Intel i960 that spun out of the BiiN project since it was a nice, little RISC that you might like. It had object-based security and fault-tolerance built into it. There was still potential for reviving that before RISC-V ecosystem, CHERI, and so on obsoleted it. Too bad.

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

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

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

https://www.wired.com/2012/02/hp-itanium/

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

It remains to be seen what the business impact of this latest fiasco is, but PR is easier to deal with than the physical recalls experienced with the FDIV bug or the intel SSDs a few years back.

This situation may become worse for them over time due to the attitudes of their partners in response to this fiasco, but as it stands (AT THIS POINT IN TIME) I think the FDIV bug was probably worse financially.

That said : I hope it hurts them just to help turn the industry away from such single-vendor dependence.

> with the FDIV bug or the intel SSDs a few years back.

I lived through both of those, they did not come even close to the sense of brand damage that I have right now regarding how I personally perceive Intel, they have mis-handled this from day #1 and they are not doing much better than when it started.

There was that time they went all-in on Rambus, and then their supplier couldn't keep up with demand. That gave AMD a big opening that they took full advantage of.

They were further behind AMD in the P3/P4 days, and especially in the early days of 64-bit.

Goldmont is the atom line and not related to skylake. Apple has been building cpus for years now and it's unfair to claim that the apple chips blow the intel ones out of the water based on some simple int/fp benchmarks. I agree that they will lose apple in time, but "in time" could be on the order of 10 years.

10 years isn't that long in a fab-scale company.

I would be absolutely shocked if Apple did not already have MacBook-level ARM cores running macOS in their development labs. Just as Apple had OSX running on Intel hardware for years while developing/selling PPC.

I think there's a very good chance we see a MacBook form factor laptop running an ARM chip in the next few years. I'd buy one, having a laptop with multi-day battery life would be awesome. I don't need super performance on my MacBook.

You can get their MacBook Retina with low TDP cpu's already (A1534 model). Reality is - usage experience is hardly acceptable, everything is way too slow.

Intel seems to be way above everyone in pushing performance/TDP. Apple might have comparable CPU's in iPhones, but they are only comparable for first 10 seconds - then they overheat and throttle. If we put good cooling on their CPU's then you have TDP in 15+ watt class which means poor battery life regardless of who made the CPU (Intel or Apple).

The only reason why all of this works with iOS in a first place is super insane power awareness on OS level: as soon as an app is not in view it basically stops almost all work (except for background handlers), and also their browser capabilities are very limited. To achieve 20h+ class of performance on laptops we either must accommodate the same principles (but hey that will probably kill almost any background web apps, like soundcloud) or invent better battery tech :(

The A10X in iPad Pro is pretty damn good, and it doesn't throttle as much as in the old Ax SoC. So I think A10X is close or already on par with Intel's low TDP CPU.

Then you have to realize on Intel's roadmap, there is nothing substantial changes in the next two years at those TDP SKUs apart from 10nm. While Apple already has A11x lined up and 7nm from TSMC. First time Apple and Intel SoC has Fab features size parity.

> multi-day battery life would be awesome. I don't need super performance on my Macbook.

I think the smartphone market shows that multi-day battery life is not something the average person will trade a decrease in device performance for. And that's on phones, where you also don't have much practical opportunity to use the device plugged in, unlike a macbook. I'd be really surprised to see this tradeoff made on macbooks.

Not to mention that Apple has been running their OSs on ARM for years now so it wouldn't exactly be groundbreaking for them. Kind of like how when they switched to Intel they had already has x86 builds running for years prior. It's only a matter of time really.

There are a fair number of people buying Apple Laptops that use them for virtualizing Windows. I'd expect that a transition to ARM would only be able to happen for some of the lineup. It couldn't be across the board as it wouldn't run Windows. That would present a new challenge for folks who don't understand much about tech and wouldn't be able to differentiate the product lines properly.

Isn't Windows ARM ready now? A bunch of ARM laptops w/ Windows 10 are coming out this year.

Yes, but the two things that keep people using Windows are legacy applications and games. They’d also have to be ported to ARM, and I don’t see that happening in a hurry.

Microsoft has been demoing x86 emulation on ARM for a while now (https://channel9.msdn.com/Events/Build/2017/P4171)

I think it requires special hardware (x86 emulation, which is 32 bit only), and many apps won't be ported to ARM for a while.

That being said Apple might find x86 emulation useful too.

So you run on ARM just to do x86 emulation? How does it work?

Windows might have been recompiled to ARM but it will take a while before all apps have. That's also why WinRT was a failure. You couldn't run anything useful on it.

RT's big problem was the lockdown. They wanted everyone to use the Windows Store. You can't even run architecture-neutral .NET apps on the desktop in RT without a developer unlock.

> I'd buy one, having a laptop with multi-day battery life would be awesome

Apple wouldn't use the technology for a multi-day battery life, they'd use it to make the laptop thinner/lighter (they've already started making MBP batteries smaller than they need be, leaving empty space in the case)

There are windows laptops with ARM chips as well running full Windows:

https://www.digitaltrends.com/laptop-reviews/hp-envy-x2-2017...

That being said, Apple has been waiting for Cannonlake for LPDDR4 support.

Goldmont's arch is essentially just Skylake scaled down; in the words of the Wikipedia article "The Goldmont architecture borrows heavily from the Skylake Core processors"

> Their failed 10nm shrink has forced product delays

Previously [1], from 2012 (starting around t=49:52): "Lots of problems here [at 11nm]. Intel and IBM have publicly discussed solving the problems with 11nm by skipping it", i.e., going straight to 7nm with never-been-used-before EUV lithography.

[1]: https://news.ycombinator.com/item?id=16175949

Were people realistically expecting Intel to hit deadlines at 10nm? This sounded more like a research project than a product line.

I always got confused with how companies like Intel planned on getting past a 10nm transistor size. How does one get around the issue of electron tunneling at that threshold (or close to that threshold)? Granted, I only understand CPUs and quantum physics at a very abstract level.

Direct tunneling in the channel becomes a problem < 4nm. the gate insulator can be even thinner since they use high dielectric constant ones which limits the tunneling current.

As GP mentioned the main problem with 10nm is the photolithographic process. Currently they're using 193nm ArF lasers. EUV "light" is very difficult to generate and handle. There aren't even lenses for it, only lossy mirrors, so each optics step will lose you a fraction of the input power and heat the mirrors.

10nm doesn't actually means that the transistors are 10nm-sized

>> They have little presence in HPC/AI

Huh? The Xeon Phi is used regularly in the industry. Nvidia is dominant but to call Intel's presence small is very odd.

Did you miss that Intel's stopped developing the Xeon Phi's?

I did, since that's not true. Knights Landing is discontinued and Knights Hill is suspended, but they are continuing development for DOE Aurora and other projects and targeting 2020-2021 - while existing stock is used regularly and the used market is plenty active. I get a lot of use out of the x200 line.

It is more or less true. Xeon Phi is being replaced by regular high core count Xeons with HBM MCM on one end, and a traditional GPU on the other. While the brand name lives on, it's not at all a continuation of the product line.

A lot of the Xeon phi usage in HPC is due to non technical reasons (e.g. Intel subsidies).

The memory bandwidth is just crushingly bad.

I guess? I mean it is not poorly represented in the Top500 and Top50 for "crushingly bad" memory bandwidth, I'll say that much.

>Do they have an ace they've been hiding?

They will fall back on their old tried and tested tactic of anti-competitive practices.

Come on. Just think little bit about what Intel (and their competitors) have given us. It is obvious that they are straining against the inevitable end of Moore’s prediction. I salute them. This despite of Spectre etc.

"They have zero presence in mobile." is false: Infineon.

It's only a matter of time before Intel makes a huge chip acquisition, possibly of AMD itself to compete with Nvidia. I think they could now make the case that this wouldn't be an anti-trust issue because...there are more competition than ever in the space now. AMD is small potatoes compared to Nvidia, Qualcomm, etc. I am fairly certain that MacOS will eventually be switched to ARM, as they begin to merge MacOS and iOS but in an effort to avoid what Microsoft has encountered in developing for ARM and x86.

anti-trust makes this unlikely.

how unlikely is it that nvidia won't be the center of their own "meltdown" in the future though?

They could be saved, but I will not speak their rescue here. There is nobody who would ask or hear it.

They could have been saved, and still might.

I gave them more than they deserved, better than they could have asked and they turned it to crap.

Curious if you currently you hold a position in AMD?

Reply on news.ycombinator.com