💾 Archived View for dioskouroi.xyz › thread › 24910778 captured on 2020-10-31 at 00:54:27. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

Apple’s A14 Packs 134M Transistors/mm²

Author: jonbaer

Score: 312

Comments: 172

Date: 2020-10-27 19:17:55

Web Link

________________________________________________________________________________

ChuckMcM wrote at 2020-10-27 21:11:39:

I found this to be a pretty confusing article. I get that they are analyzing the new node, which is great, but the editorializing seems a bit premature to me.

I also don't think the author understood the TMSC presentation. TMSC clearly said that is used a "model" of a typical SOC of 60% logic, 30% SRAM, and 10% analog. Then they said that for each category of thing, you could expect 1.8x, 1.35x, and 1.2x of shrink. If you do the math, that means an overall shrink for a 'typical' SOC that conforms to their model would be 1.57x (approximately).

That Apple achieved 1.49x would suggest they got 95% of the process shrink effectiveness.

Then there is the cost per die and thus cost per transistor discussion. It is important to remember that this is likely the most expensive these wafers will ever be. The reasoning for that statement is that during a process node life-cycle the cost per wafer is set initially to capture "early movers" (who value density over cost). Much like any product where competition will emerge "later" there is a window early on to recapture value which can pay back your R&D and capital equipment investments. As a result the vendor sets the price as high as possible to make that repayment happen as quickly as possible. Once paid back, the price provides profit as long as it can be supported in the presence of other competitors (in this case, I would guess that role is played by Samsung). The GSA uses to publish price surveys of wafers on various nodes over time but they don't seem to do that any more. Anyway, so the cost per transistor will go down from this point but how much depends on how much margin is in the current wafer price.

So I agree that the cost per transistor is not going down as quickly as it has in the past, and its possible that this node may not get to be as low as the previous node. I'm curious how it compares when you look at 7nm introduction price per transistor vs todays price per transistor. And if you get the same ramp with the 5nm node what that would mean.

hedgehog wrote at 2020-10-28 02:22:48:

Apple is also probably using more SRAM than the "typical SOC", for example the A13 has much more cache than say the Snapdragon 855. I don't know the relative die areas but that would let you make a decent estimate.

ksec wrote at 2020-10-28 07:53:15:

And the economic model now requires Leading Edge Fab to capture those value in a longer period of time. What used to be two years will be lengthen closer to three.

>I'm curious how it compares when you look at 7nm introduction price per transistor vs todays price per transistor. And if you get the same ramp with the 5nm node what that would mean.

First Gen N7 being ~10K+ per wafer while N5 being around ~13K with _higher_ yield compare to N7 in the same stage. So N5 should still be cheaper.

m3at wrote at 2020-10-28 09:54:33:

The article quote ~17K for N5, do you have an other price reference or was it just a typo?

londons_explore wrote at 2020-10-27 22:48:03:

TSMC has a monopoly on the highest performance processes - so the price won't drop till there is competition. Seeing how the competition is falling behind, that will be a while...

ChuckMcM wrote at 2020-10-27 23:23:33:

I was referring to this:

https://www.anandtech.com/show/15538/samsung-starts-mass-pro...

Which has Samsung in production of their 7nm node this year as well.

DiabloD3 wrote at 2020-10-28 00:17:09:

Samsung's process seems to be consistently DOA.... by the time it is stabilized, its already behind everyone else.

Consequently, almost all of Nvidia's current troubles stem from being unable to do all of their fabrication at TSMC, and the yields for Samsung 8nm being very poor.

Nvidia recently canceled the 2x RAM variants of their 3070 and 3080 cards (and not because of insufficient GDDR6x, only the 3090 takes that), have stopped shipments of GPUs for new cards (they are only continuing to ship to fill existing orders), pushed the 3070 release date until after the RDNA2 announcement; most of this stems from Samsung's poor yields no matter how inexpensively Samsung is selling those wafers for.

This also isn't the first time Nvidia used the Samsung footgun.

websg-x wrote at 2020-10-28 01:38:35:

3080 use GDDR6x. Yes, the 20gb 3080 is cancelled, but there is a new rumor about 12gb 3080ti. So maybe GDDR6x scarcity is the culprit, not Samsung's process.

Dylan16807 wrote at 2020-10-28 03:11:36:

Surely the ram variants use the same chips. Why cancel those because of yield? I wouldn't expect total demand to change by a significant amount...

zaptrem wrote at 2020-10-28 07:10:39:

If the GPU die yield was really that much of a bottleneck wouldn’t they push even harder to launch the VRAM variants to boost margins?

Hikikomori wrote at 2020-10-28 11:02:07:

3080 also uses GDDR6x. The 3080/3090 shortage is because of GDDR6x availability from what I've been reading. We'll know when we see 3070 sales/deliveries.

reader_mode wrote at 2020-10-27 23:50:40:

If I understand correctly the current GPU supply shortage for Nvidia is caused by Samsung and they are forced to return to TSMC, meanwhile TSMC is supplying AMD and Apple just fine - so is Samsung really a viable alternative ?

MangoCoffee wrote at 2020-10-27 23:05:06:

TSMC is about to win on packaging too

https://www.digitimes.com/news/a20201026VL200.html

thornjm wrote at 2020-10-27 23:22:51:

The column is explicitly labelled "effective vs theoretical" though. There is nothing misleading there.

ChuckMcM wrote at 2020-10-27 23:31:40:

This is where I believe the author goes astray: _"Despite TSMC claiming a 1.8x shrink for N5, Apple only achieves a 1.49x shrink."_

TSMC does _NOT_ say they have a 1.8x shrink for N5, they say for LOGIC you can get that, but for SRAM and Analog the results are 1.35x and 1.2x. Had they summed that together for a "typical SOC", which they also discuss (and one presumes that Apple makes typical SOCs) then the "theoretical" shrink is 1.57x for SoCs.

The challenge is that whereas at one time the node size was that of a "gate" (which could be 4 transistors), in a marketing race for smaller numbers fabs started emphasizing "feature" size.

Because of this change, the "theoretical shrink" is a function of what kinds of circuits you're putting down. Pure logic? You get one number, two gates connected together for a flip-flop, you get another number, a voltage regulator, or ADC filter, you get another number.

So doing the analysis the author claims to do, can ONLY be done if you know what percentage of the part you are making on the new process is what. I am under the impression that they missed that.

FPGAhacker wrote at 2020-10-28 01:18:25:

Wait, when node sizes where based off of a gate that meant logic gate? I always thought it was the transistor gate width.

ChuckMcM wrote at 2020-10-28 02:18:09:

My experience with the marketing speak around process nodes.

1) In the way back times, (think Intel 8080A) the complexity of the chips was advertised in "logic gates". More gates = more impressive chip.

2) But logic gates weren't equivalent from one process to another, and so it switched from "logic gates" to "transistors." More transistors => more impressive chip. (this is when I left Intel for Sun Microsystems)

3) But not all transistors are created equal, and there were things (like copper metal layers) that made chips better even it it meant you couldn't fit as many transistors so "line size" was what was important. Smaller line size => more impressive chip.

4) But now people had redesigned transistors so that they could be packed more densely and the limiting factor was how much silicon you needed for the gate (NMOS/CMOS) and since that wasn't a whole transistor, it was just a "feature" of the transistor, "feature size" became the new marketing term. Feature size was measured in nanometers and so the smaller nanometers implied more features per unit area.

It has all evolved over time so that it is harder and harder for any sort of comparative analysis between processes seems to make any sense at all these days.

These days, much like the TSMC presentation that is excerpted in the original article, semiconductor fabs rely on comparative measures like "same stuff would be size <x> on this process vs size <y> on the previous process." All the really interesting parameters to me are things like how that effects leakage (thus idle power) and voltage thresholds (thus idle power and maximum frequencies).

I'd love it if there was some sort of SI unit you could demand which would give you a better comparison metric but I don't think we'll see that. Everybody wants to be "the best" and that is most easily achieved when you can dynamically define the metric for "best."

nazgulnarsil wrote at 2020-10-28 03:43:41:

Thank you for this elucidating comment.

pas wrote at 2020-10-28 09:43:43:

https://spectrum.ieee.org/semiconductors/devices/a-better-wa...

https://www.youtube.com/watch?v=1kQUXpZpLXI

(from 13:50, but the rest of the video is just amazing)

disillusionmnt wrote at 2020-10-28 06:34:16:

Was I the only one disappointed in the decreasing die size? In our solid state past, it was about cramming more in there. All this cost-cutting leaving gaps... it wouldn’t pass the Jobs’ fish tank test.

topspin wrote at 2020-10-27 20:31:06:

I really appreciate this analysis and the straightforward top line number 134e6/mm^2. The usual "node" figure is utterly meaningless; an electrical engineer couldn't care less about "feature" size (whatever that means.) What is the count of discrete components in a given area? There are 40 billion 5nm (the supposed "node" of these chips) squares in a millimeter of area. That's _two orders_ of magnitude more dense than 134 million.

The meaningful achievement is how many discrete electrical components are composed into a given area. Not some arbitrary dimension of some cherry picked subset of these components.

moonchild wrote at 2020-10-27 20:41:43:

> The meaningful achievement is how many discrete electrical components are composed into a given area. Not some arbitrary dimension of some cherry picked subset of these components.

I disagree. The _meaningful_ achievement is how power-efficient, fast, and cheap you can make a given chip. (Secondarily, how small and how durable wrt cosmic rays; but for most purposes these are not super important.)

If that follows as a result of many discrete electrical components being packed into a small area, great; but the latter isn't intrinsically interesting.

est31 wrote at 2020-10-27 21:16:57:

The issue with power efficiency, speed, and price is that it's even harder to measure than transistor density. Furthermore, I think metrics that measure the technological progress of the silicon manufacturing are a useful tool for enriching comparisons of chips. Yes, numbers like cache sizes (or transistor density) aren't what people ultimately need/want, they want speed, but it still helps them compare chips. Improvements of the underlying process alone could lead to improvements of power efficiency, speed, and price.

topspin wrote at 2020-10-27 20:59:40:

> If that follows

Efficiency, performance and cost are strongly related to density. Price less so; that's a function of supply and demand.

asdfasgasdgasdg wrote at 2020-10-27 21:03:46:

> Efficiency, performance and cost are strongly related to density. Price less so; that's a function of supply and demand.

They are related, of course, but the important stuff can be measured more directly by looking at how well programs work on a given computer. I think it's just a little odd to praise one cherry-picked, arbitrary metric for being less game-able than another cherry-picked, arbitrary metric. Especially when we have metrics to hand that are a lot closer to what real people care about in a computer. I certainly have never shopped for a CPU based on the number of transistors, but I have made purchasing decisions based on things like cinebench and passmark scores, which try to get at what ultimately matters to me (i.e. how many FPS a CPU will drive in the games I play).

Someone wrote at 2020-10-28 01:06:02:

That magazines, sites and fans started using density for bragging rights, just as they used to do with MHz, certainly isn’t fully the fault of manufacturers.

Manufacturers use “x nm”, yield (a metric correlated with price, but also completely uninteresting for consumers), etc. because they tell _chip designers_ what they need to know.

They avoid benchmark scores because they bring the CPU design in the picture as a variable.

topspin wrote at 2020-10-28 02:08:26:

It's a story from a site that focuses on fabrication technology and the semiconductor market place. The topic is device density. This is of interest, even if it doesn't interest you.

asdfasgasdgasdg wrote at 2020-10-28 03:51:42:

I appreciate that it's of interest to some people. So is the node figure you denigrated in your original post, though.

topspin wrote at 2020-10-28 05:02:46:

Doubtless. Angelic visitation is interesting to some people. Those and "node" figures have about the same value and credibility.

ummonk wrote at 2020-10-27 21:05:27:

Are you asserting performance benchmarks aren't gameable?

asdfasgasdgasdg wrote at 2020-10-27 21:08:10:

No.

schappim wrote at 2020-10-27 21:06:10:

Exactly this.

From the article:

“Even if SRAM scaling kept up, the cost per transistor would still have remained flat from N7 to N5.”

coherentpony wrote at 2020-10-27 21:07:09:

These things aren't _really_ two-dimensional. They're not really three-dimensional either, but they are objects built out of layers of two-dimensional things. When you measure number of transistors per unit area you will inevitably see something more dense than the "number of 5nm square in a millimeter of area".

It's the silicon equivalent of measuring one's BMI.

hinkley wrote at 2020-10-27 21:19:57:

Video games used to call their pseudo-3d display 2.5D, or if they were feeling fancy, isomorphic.

There is a little freedom in the Z axis, but not very much. But if speed of light matters to performance, then a chip design that increases the z axis decreases the euclidean distance between any two gates, which should (or at least could) matter to performance, right?

Dylan16807 wrote at 2020-10-28 03:27:42:

> But if speed of light matters to performance

It barely matters. Gate delays and thermal limits outweigh distance by a huge factor. If you need to go further distances then you can wait one cycle and cover a relatively huge length.

hinkley wrote at 2020-10-28 19:23:13:

> you can wait one cycle and cover a relatively huge length.

At the cost of increasing pipeline depth, right? We've been wrestling with that forever.

Dylan16807 wrote at 2020-10-29 09:01:50:

I would expect your pipeline steps to be far smaller than this scale.

We've been wrestling with the number of pipeline stages vs. the number of transistors in the critical path forever. Not so much physical distance.

coherentpony wrote at 2020-10-27 21:54:33:

Ultimately it depends on the design but you're basically right, yes.

hinkley wrote at 2020-10-27 21:07:56:

A cycle or two ago I asked this same question. Some people seemed to think that such a number would be gamed, but if that's a valid barrier to entry then we will never accomplish anything again, really.

As long as the measure is in mm^2, not mm^3, I think (hope?) that would avoid any perverse incentives against breakthroughs that allow you to add more layers to a chip and still maintain yields.

eightysixfour wrote at 2020-10-27 20:59:16:

> The meaningful achievement is how many discrete electrical components are composed into a given area.

Is average over an area the meaningful achievement or is the meaningful achievement the smallest individual gate length? Neither are super useful without additional context.

hinkley wrote at 2020-10-27 21:03:44:

Let's say I made a tiny transistor but to avoid leakage/interference or melting the transistor, I had to surround it by a bunch of empty silicon. There are lots and lots of cases where this could not be called a success.

I hesitate to say there are none, because I'm sure some task that is highly sensitive to latency might potentially benefit, but if you build the whole chip that way, it would actually be a regression.

eightysixfour wrote at 2020-10-27 21:07:07:

Sure but, despite the extra space around any individual transistor, you're still shoving 49% more transistors into the same overall amount of space. Then everything benefits and no one cares about the node name.

hinkley wrote at 2020-10-27 21:26:12:

> you're still shoving 49% more transistors into the same overall amount of space

What I fear is that we've hit the point where this is no longer a safe assumption. That we will be having people chase feature size numbers that don't actually result in a proportional increase in chip density.

Transistors per square millimeter is closer to a measure we actually care about (speed of light and clock speed) instead of a bench number that doesn't measure anything except perhaps instructions per watt.

eightysixfour wrote at 2020-10-27 21:30:43:

What from the article makes you think that's no longer a safe assumption? The 49% gain is exactly what happened going to 5nm.

I don't think anyone actually cares about transistors/mm^2 at all, I think what we care about is perf or perf/watt for our specific workloads. I don't care if the chip is built with vacuum tubes if it is fast, efficient (per dollar and watt), and physically fits in the device I want it in.

hinkley wrote at 2020-10-29 19:04:34:

First, because TSMC was aiming for 1.8x and Apple only saw 1.49, and I expect that not to improve going forward.

Second, one of us is reading that number wrong. They said 1.49x, not 49%.

In any other conversation, 2x is reducing feature size by 50%. 3x is 1/3 of the original, or reduced by 2/3. That means 1.8 is 45% smaller, and 1.49 is 32.9%.

Similarly, if you cut the pitch of a circuit in half you should see 4x as many transistors. If you could keep shrinking the space between transistors while shrinking the transistor, then going from "7" to "5" node should have been a 1.96x factor for areal density, not the 1.8x they claim, or the 1.49x Apple achieved.

I'm not saying they screwed up. As soon as nodes stopped measuring literal transistor size, it wouldn't take long for the names to be aspirational instead of descriptive. It's something they can name the project early on when the set of potential tech has been selected and some estimates have been made. For building a team it's fine. But I'm not on that team, I'm a customer (and current or former shareholder).

I think the consumer cares about the transistors per mm^2 (after the voltage and the instructions per second), not the node number. Especially when each foundry uses the same number to describe different densities. I shouldn't have to keep remembering that TSMC-7 = INTC-10. Numbers that are actual numbers, please.

m463 wrote at 2020-10-27 21:44:36:

_"As of 2019, the highest transistor count in any IC chip is Samsung's 1 TB eUFS (3D-stacked) V-NAND flash memory chip, with 2 trillion floating-gate MOSFETs (4 bits per transistor)."_ [1]

How about bit count? (at 4 bits per transistor)

[1]

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

narrator wrote at 2020-10-27 21:11:44:

The funny thing is is this isn't really Apple's achievement. It's TSMC's achievement. It's also Intel's failure in that they failed to get a similar process working on schedule.

robocat wrote at 2020-10-27 21:41:01:

I think you are using black and white thinking: both deserve praise.

Delivering a CPU on a new node process is not a trivial achievement, along with the significant design changes required to achieve the potential gains of the node. Neither is Apple’s business ability to lock in x months of exclusive use of that node. Apple have done an amazing job here, hand in hand with TSMC.

desiarnezjr wrote at 2020-10-27 21:26:19:

Yes, but Qualcomm, Nvidia, AMD and countless others use the same fabs or at least have access to the same fabs. It's Apple's engineering and design.

m463 wrote at 2020-10-27 21:34:50:

"Apple Books TSMC's Entire 5nm Production Capability"

https://www.extremetech.com/computing/315186-apple-books-tsm...

so it seems apple paid to get to the front of the line

desiarnezjr wrote at 2020-10-27 22:17:59:

And the problem there is? Any one of those companies are all long term TSMC customers and I have no doubt have solid working relationships with them. They would have had similar opportunity to book that fab capacity too.

kilburn wrote at 2020-10-27 22:52:01:

The problem is the assertion that "It's Apple's engineering and design". Engineering & design don't buy you the entire world's supply of the best in class fab capacity for some months: money does.

It seems to me apple's marketing and product strategy has more to do with bringing in that money than actual engineering and design, contradicting the original assertion.

dev_tty01 wrote at 2020-10-28 01:19:17:

Apple's engineering and design success is a huge part of why they have the resources to likely fund some of the 5 nm fab deployment costs and capacity. Money comes from success which came from great engineering and design coupled with great marketing.

Marketing might get you there for a short time, but maintaining that growth and long term high customer satisfaction doesn't come without great engineering and design.

dodobirdlord wrote at 2020-10-28 01:20:42:

Apple wouldn't have shelled out the money to have first crack at 5nm if their design team couldn't commit to having a CPU design done in time. It's a huge R&D achievement to have such a complex design ready to go on a new node as the node launches. It speaks to extremely tight timelines and extremely close collaboration between TSMC and Apple.

kilburn wrote at 2020-10-28 06:37:15:

I'm not saying apple's engineering isn't good, just that it doesn't seem to be that exceptional. If the other companies couldn't have a design ready for 5nm then why would apple pay for the exclusivity rights?

szundi wrote at 2020-10-28 09:24:44:

It is exceptional according to this reasoning.

They pay because there is not enough of this 5nm fab. Business does not go against engineering, that’s all.

totalZero wrote at 2020-10-28 03:20:04:

At the risk of sounding cheeky, Apple's engineering and design are the sole source of the money involved.

Apple's involvement with TSMC also provides TSMC with an opportunity to learn from Apple. Nobody books an entire pure-play foundry without taking the time to figure out what they want to do with that manufacturing capacity in the first place.

nazgulnarsil wrote at 2020-10-28 03:48:35:

Yeah, I'm tempted to say something like: it takes a while in your career before you figure out the enormous difference between companies who do engineering and design and companies who do design and engineering.

ayewo wrote at 2020-10-28 08:47:40:

Why does the difference in ordering imply a significance in difference?

skunkworker wrote at 2020-10-27 22:48:24:

I see them as Apple paid to get to the front of the line and get 5nm built faster, they'll have the capacity for now. But other companies well benefit in the coming years as they can use the 5nm process sooner, more bugs ironed out and at a lower cost. Like what's happened to the older 32nm fabs.

2muchcoffeeman wrote at 2020-10-28 02:01:16:

Comments like these and the ensuing arguments are funny. Especially considering the supposed audience.

What makes you think coordinating something like this is an easy task for anyone? As if you could ever distil this down to the efforts of a single organisation.

Nokinside wrote at 2020-10-27 21:28:58:

> straightforward top line number 134e6/mm^2

Even that number is not so straightforward.

Tr/mm^2 = 0.6 * (NAND2 Tr)/mm^2 + 0.4 * (Scan Flip-fop Tr)/mm2

talentedcoin wrote at 2020-10-27 20:17:14:

I think this is cool if they’re the future of the Mac, but aren’t these chips just wasted in the iPad? I say this as an iPad Pro (1st-gen) owner ... it’s already way more processing power than I can really use, because after trying for months to get a sensible workflow going (mostly based around Pythonista, Editorial and RealVNC) I’ve relegated it to a OneNote and Netflix machine. What’s the point other than the coolness factor? Is it some future AR-type application?

jiggawatts wrote at 2020-10-27 20:44:33:

I was just looking into optimising a large web application.

I told the customer that using a caching layer such as a CDN would help paper over the worst of the inefficiencies in their application and the network stack.

That was true! The download times halved.

However, benchmarks with F12 developer tools showed that while downloads reduced from 200ms to 100ms, the overall load times were still seconds, of which about 50% was actual CPU time.

(This is typical of large, complex sites built by non-experts or organisations where performance is not a primary concern.)

Web sites like these perform _very_ noticeably better if you have more CPU cores or faster CPU cores.

Essentially, CDNs are easy to deploy and 5G provides nearly gigabit download speeds, so the bottleneck has shifted back to the CPU for a lot of the web.

Godel_unicode wrote at 2020-10-27 21:08:14:

Sounds like the argument here is "buy an iPad pro so frontend developers don't need to learn optimization"...?

mucle6 wrote at 2020-10-27 21:38:22:

Buy an iPad pro because time and time again we have seen that optimizing is not a priority for the majority of business.

I think the cynicism here is that if only these frontend developers would just learn to optimize we would all finally be better off. I think there are two factors that push against this though. First, if you learn to optimize then you can charge more for your labor, and you will likely get a job somewhere else. Second, companies exist for profit, and optimizing is not often the most profitable next step.

Godel_unicode wrote at 2020-10-27 22:45:58:

Amazon and Google have published a truly tremendous amount of data about how fraction-of-a-second differences in loading time can have outsized impacts on bounce rate. It continues to be amazing to me that so many businesses just completely fail at understanding this basic truth. Speed is a competitive advantage. Doubly so when many of your competitors don't realize it.

Jetrel wrote at 2020-10-27 23:23:57:

The catch is that you're looking at this through the lens of "comparison shopping between two user-facing apps", decided on by a random consumer out on the net. In that context, it's absolutely true. I personally experienced this with google vs. all of the other portal search sites like yahoo, excite, etc - google loaded much faster, and on my shitty 28.8 modem that was a matter of minutes, sometimes. So I switched to google.

The thing is - most web software isn't comparison shopped. It's developed on contract. I work at a company that does a lot of this, and, hypothetically, maybe we'd get hired to do an internal app for some retailer (imagine Best Buy or Walmart). When you build something like that, there's a gun to your head about time-to-deliver. _They don't care if it's good_ — it's just got to meet a "reasonably decent" metric of quality. The only thing they really care about is getting it released on a certain timetable.

And all of this is because of contract law - timetables are provable breach-of-contract. You promised you'd make something by February, but you weren't done until April - that's something that's a provable failure-to-deliver. That's got financial penalties. But quality? Quality's gotta be astoundingly bad to be "provable". "Lag" or "the site's kinda slow" doesn't hold up in a lawsuit. (These things rarely lead to lawsuits, but do lead to 'punishment' by a refusal to renew a contract, knowing that the contractor can't sue the company because the contractor provably failed to deliver what was agreed on.) So they optimize for what's punishable according to the terms of the contract.

That's why all of this corporate enterprise software sucks - because nobody gets punished if it's slow or crappy; they just get punished if it's late, or if it's provably broken, because that's the stuff that's easy to pull out of a contract for.

jmnicolas wrote at 2020-10-28 14:17:48:

And Amazon and Google are still slow ... Google maps is almost unusable on a slow dsl connection.

bentcorner wrote at 2020-10-28 04:33:08:

You're not wrong, but if you're trying to view your local city hall meeting minutes or paying for your garbage bill, it's not like you can go somewhere else.

And it's true that the people paying for it could go elsewhere, but page performance probably weighs pretty low on that list.

sroussey wrote at 2020-10-27 23:27:16:

I’ve talked to the Google people on these reports — the effect is real when the resulting page loads are under about 1.8s all in. No difference between 7s and 3s. Big difference between 2s and 1s. At least in eCommerce.

phkahler wrote at 2020-10-27 22:14:13:

>> Second, companies exist for profit, and optimizing is not often the most profitable next step.

That's true and reasonable. And after this 5nm node, TSMC has 3nm and IIRC 2nm. We are at the point where throwing more hardware at slow software is becoming a non solution.

The good news is that in many cases there is a LOT of performance on the table on the software side.

dodobirdlord wrote at 2020-10-28 01:33:01:

The node size numbers have been made up for decades. Even if process shrinks bottom out two or three node shrinks from now there will still be improvements in process, materials, thermals, and packaging to allow things like greater z-axis stacking. And there's a ton of room for targeted improvement in things like vector instructions.

That's not to say that there isn't an enormous amount of improvement available in software. Projects like simdjson prove that there's a 2x or more improvement available for many high-performance use cases by migrating to vector instructions.

https://github.com/simdjson/simdjson

csharptwdec19 wrote at 2020-10-28 12:56:28:

You don't even have to reach for SIMD to get better performance. Just stop letting crappy software get written.

I'm currently agonizing over an application that has an 80-120ms response time for 5 hops (including db writes). Yet I know many people who code in my language would find that number amazing for the work being done in those hops.

No SIMD. Nothing too crazy. Just well thought out processing flow and proper separation of the stupid.

izacus wrote at 2020-10-27 22:01:47:

Which just means that your 1200$ iPad Pro will be slow in a year because the treadmill will continue.

saagarjha wrote at 2020-10-27 22:19:36:

I have an iPad using a four-year-old chip that's perfectly snappy. If this drift exists on iOS (it probably does) it is generally less pronounced compared to the life of the device.

jiggawatts wrote at 2020-10-27 22:49:05:

Also:

https://www.sicpers.info/2020/10/discipline-doesnt-scale/

tshaddox wrote at 2020-10-28 01:03:46:

Not any more than that all improvements to computer performance serve no purpose but to allow developers to skip optimization.

Ashanmaril wrote at 2020-10-28 02:52:28:

"What Andy giveth, Bill taketh away."

jacobolus wrote at 2020-10-27 21:07:40:

There is no speed of computer which cannot be overwhelmed by badly written code.

I guess your point is that sloppy web developers / web companies make poorly performing code and shift the burden of handling it out to visitors’ machines, so those machines have to keep improving to not be left behind?

That might be true, but is pretty depressing.

jiggawatts wrote at 2020-10-27 22:51:23:

Conversely: There is no speed of computer which cannot be utilised to reduce developer effort.

Faster computers enable easier programming strategies, which improve net productivity. People are expensive, so giving them better "power tools" improves efficiency.

We don't complain that coal miners just need to shovel more efficiently. We give them enormous trucks and hydraulic mining shovels.

ghettoimp wrote at 2020-10-27 21:45:03:

I think "fast, cheap, good, pick 2" applies. Obviously the current bloated, ad-laden state of the web is pretty horrible and indefensible. But if we can keep making compute faster, it should ultimately save programmer time, which can be used to either get cheaper or better programs.

wincy wrote at 2020-10-27 21:04:25:

I sold my 2080ti and am playing Eve Echoes (new, mobile version of EVE Online) and Among Us, and Civ VI on the 2nd gen iPad Pro I bought used with less than half of the proceeds. The battery lasts a good long time and it feels pretty good to be able to play these full sized games on a screen like this. When I'm not using it the toddler watches some kids shows, and with the keyboard case I can type almost as quickly as I can on my 15" Macbook pro. If it had XCode I'd be set, honestly.

manmal wrote at 2020-10-27 20:30:28:

Having a more-powerful-than-necessary CPU has many benefits, here are some:

- Less heat produced > allows for smaller heatsinks and, as a result, smaller devices or bigger components

- Performance bottlenecks become less likely

- Features like 120hz display refresh rate become possible without the user noticing degradation

- Faster OS boot and app starts

- Ability to do more work locally vs using a server (see the many ML features)

- Tech debt in system code is less of an issue - code can be shipped early and optimized later

Polylactic_acid wrote at 2020-10-27 21:52:33:

Not to mention it extends the life of the device. If a device is only just good enough for now, what will it be like in 4 years time. I currently use a 6 year old ipad air 2 and it feels very snappy and does everything I use it for well. Apple also tends to stop updates when the hardware is no longer capable of running the next OS smoothly.

bhj wrote at 2020-10-27 21:27:59:

Battery life. The faster a task is completed (at a given power cost) the sooner the CPU can go back to standby.

baybal2 wrote at 2020-10-27 21:59:55:

Not so fast, especially these days. CPU power consumption is highly non-linear.

You may well be benefitting from running a task longer, at a slower speed, and using less transistors.

saagarjha wrote at 2020-10-27 22:20:56:

In general time-to-sleep is still the defining factor in keeping battery life long. Sure, there are low-power cores, but I believe most UI code will not run at it since it's given high priority by the system.

Moto7451 wrote at 2020-10-27 20:19:12:

My understanding from talking to friends who work at Apple and some of the product briefs is a lot of the hardware is used for video and photo processing. Video games take advantage of the extra CPU/GPU power as well.

I don’t think that’s all that Apple specific as there are increased ISPs and security chips on other phones as well.

saagarjha wrote at 2020-10-27 22:18:28:

I work on a x86 interpreter that is only usable because of Apple's massive investment into these chips over the last couple years. I doubt that is what Apple was designing them for, but they are very useful to have as an application developer.

djxfade wrote at 2020-10-27 22:58:23:

Are you the developer of iSH by any chance? If so, very cool project. Was it hard to get it published in the App Store?

saagarjha wrote at 2020-10-28 00:18:09:

I am _a_ developer of iSH; tbodt did most of the interpreter work though. (Actually, he did most of the work on the app in general–there's a couple more of us who dabble in other parts of development, as well as support, marketing, compliance.) We're glad you like the project :)

Getting iSH on the App Store did take some work on our side; we were in contact with Apple to get it approved and in compliance with the guidelines. You may have seen that the version of iSH on the App Store had package management functionality removed. So far we've been able to keep the ability to run Linux programs, as well as import files, unchanged.

One interesting thing to see from Apple is that they are not just increasing the performance of their chips, but they are investing heavily in making _certain operations_ faster. For example, in the time since tbodt started working iSH Apple has reduced the cost of uncontended atomics to almost zero overhead (this is especially good for Apple because it immediately makes reference counting code faster, which both Swift and Objective-C spend a lot of time in). iSH doesn't currently do anything fancy there, it just uses full locks everywhere, so this is something that we would be interested in pursuing at some point.

johncolanduoni wrote at 2020-10-28 09:37:10:

Faster uncontended atomics should improve uncontended lock performance too, at least if you’re using pthread mutexes (they’re implemented via atomic operations with an os_unfair_lock fallback for the contended case on Apple platforms).

kitotik wrote at 2020-10-27 20:26:38:

Audio and Video work will take all the transistors you can throw at it. Things like GarageBand and 3rd party software synthesizers can easily max out even latest gen iPad Pros. Not to mention games…

samatman wrote at 2020-10-27 20:21:32:

Not if you start juggling several streams of 4k video, it's not.

Also, one can play games on an iPad, and games will soak up arbitrary amounts of CPU and GPU power.

urthor wrote at 2020-10-27 20:37:23:

Never underestimate the PUBG Mobile/Genshin Impact demographic basically.

There's a lot of corner cases there where certain consumers value it a lot.

Also performance per watt is a huge deal. The expanded power envelope that improved PPW brings allows 120hz displays which are battery hogs.

Reason077 wrote at 2020-10-27 20:46:45:

I wonder if Apple Silicon means we might finally get PUBG on Mac. If they can make it work on an iPad, they can make it work on a Mac with similar hardware... right?!

I'm already missing the glorious few months that PUBG could be played on Mac via Stadia.

urthor wrote at 2020-10-27 21:57:26:

Basically, no. The issue was never the instruction set, you still have to support the interface and the OS which nobody is bothered to do because cost benefit.

Changing the chip isn't going to change the code base of the operating system.

lunixbochs wrote at 2020-10-27 22:31:19:

Unless they specifically opt out, almost all iOS apps will be available on Apple Silicon macs at launch.

saagarjha wrote at 2020-10-28 00:43:58:

It will probably run, but I wonder if the UI will be usable on macOS?

lunixbochs wrote at 2020-10-28 05:36:32:

Some iOS and Android games support keyboard/mouse I think. You can also potentially map mouse movement to joystick movement for relative games like shooters. There are people who play pubg mobile on desktop with BlueShift or whatever already. Barring that maybe there will be a market for apps that make playing iOS games with keyboard and mouse easier.

Cookingboy wrote at 2020-10-27 20:27:52:

>What’s the point other than the coolness factor?

So Genshin Impact can look and run beautifully XD

fomine3 wrote at 2020-10-28 02:07:57:

Apple's SoC works really great and impressive, but I don't know why I need such spec for Phone. Even A12 is still great for most workloads. Apple improves camera functionality by its performance but just camera? I wish they find useful uses other than cameras.

centimeter wrote at 2020-10-27 20:35:19:

I bought my iPad Pro because it offered the smoothest RAW photo proofing process of any product I've used. A lot of this is obviously up to software as well as hardware, but still - the beefy processor is useful here.

mceachen wrote at 2020-10-27 22:02:18:

Faster CPUs certainly help everything go faster, but _what you're asking of the CPU_ may matter much more than how fast the CPU is.

RAW processing is actually a really interesting application, and rendering time depends heavily on what you do with the bits from the sensor.

If you use non-linear interpolation, 2-50x the time to build.

If you do highlight recovery, 2-5x the time to build.

If you only need half the native resolution, build time may be reduced 2-4x.

Basically "viewing a RAW image" can take 100 milliseconds or 15 seconds (on the same hardware!), depending on how you're interpreting the sensor data.

(Source: playing with dcraw and libraw to rasterize raw images for PhotoStructure)

megablast wrote at 2020-10-27 22:43:33:

That is the way you want it. You don’t want it the other way.

vmception wrote at 2020-10-28 00:05:35:

Even if assuming they were wasted, lower the production cost for everyone else that is not wasting them

threeseed wrote at 2020-10-27 20:52:23:

Many professionals are using iPad Pro for audio e.g. DAW and video e.g. editing.

72deluxe wrote at 2020-10-27 21:08:13:

What DAW are they using? I use my iPad as a remote for Presonus Studio One sometimes, but I couldn't consider using it as the recording system itself, since the AU and VST accessibility isn't there.

I would also use my iPad as a synthesiser (eg. Magellan) but then record the audio to a "real" computer, ie the Mac, via a recording interface.

empthought wrote at 2020-10-27 21:27:59:

GarageBand is enough for a lot of people. There’s also Cubasis and Gadget 2 (which is more synth focused).

jagged-chisel wrote at 2020-10-27 20:22:58:

I'm sure Apple consider the iPad Pro as a testing ground for these chips.

gettingsnarky wrote at 2020-10-27 21:13:36:

> I think this is cool if they’re the future of the Mac, but aren’t these chips just wasted in the iPad?

Mostly, but by putting them in iPads and iPhones they have been able to scale their chip development to the levels they need to.

hmottestad wrote at 2020-10-28 02:17:58:

As someone with an 8 year old MacBook Pro that isn’t all that much slower than my 2019 16”.... I am so glad Apple is still pushing the envelope.

Back in the old days we used to get a doubling of performance every year or two. Then Intel got into trouble and has been producing the same chips for what 4-5 years? Essentially just minor changes.

It’s not really Apple’s fault that the rest of the industry is lagging so badly on performance. My Nokia was fast enough, of course no one “needs” a faster phone. But it only appears so much faster because the rest of the industry has stagnated.

Had Intel kept their tick-tock cadence then these new "faster” phones would hardly be considered fast.

raydev wrote at 2020-10-28 02:41:01:

My 2013 high end 15" MBP gets pretty hot when I'm watching 1080p or higher videos. Chrome+YouTube is even worse, it even drops frames. Compiling Swift is even worse than that.

I have a work-provided 16" MBP that does all these things effortlessly.

Dylan16807 wrote at 2020-10-28 03:20:17:

Are they using the same amount of hardware acceleration?

If one has support for VP9 and one doesn't, then most of that is not because the cores changed in performance, it's because the video decoder got rearranged.

zachberger wrote at 2020-10-28 03:07:01:

I have an early 2013 MBP and its still a champ, none of those problems.

I'd suggest popping off the bottom and cleaning out the dust, I do this about once a year.

dmitshur wrote at 2020-10-28 05:57:22:

Another consideration when making this kind of a comparison between an older laptop and a newer one is how much dust or debris are in each of them. If it’s an unequal amount, that’ll skew the spec comparison.

hmottestad wrote at 2020-10-28 06:17:39:

I don’t use Chrome much. Safari runs YouTube perfectly fine, even while running benchmarks for a dev project I work on at home.

raydev wrote at 2020-10-28 20:40:50:

Yeah, I understand Safari is easier on the CPU, unfortunately it doesn't allow for multiple profiles with separate histories/passwords. I also spend a bit of time on a Windows machine, and like having my history there too.

titzer wrote at 2020-10-28 02:24:12:

Blaming Intel for the end to frequency scaling is overblown. The reality is that the entire field started to hit limitations imposed by physics on the current silicon trajectory. While transistors kept (and keep) getting smaller, it's diminishing returns squeezing clockspeed and single-core performance out of it. Instead, everything has been going into scaling horizontally with more cores and more cache.

hmottestad wrote at 2020-10-28 06:19:33:

The A14 scores 50% higher single core performance in geekbench compared to the i7 in my 16”MacBook Pro from 2019.

Also the current gen high end laptop CPUs from Intel are still 14nm. Which they introduced in 2015 with broadwell [1]. Others have shown that’s it’s very possible to scale beyond 14nm, so there is good reason to blame Intel here!

1.

https://ark.intel.com/content/www/us/en/ark/products/87719/i...

rdw wrote at 2020-10-27 20:10:55:

The article says that Apple isn't making full use of the 5nm process node, and blames lack of SRAM scaling for it (presumably due to the large amount of L3 cache). Is this a problem that all processors are about to hit, or is this going to be overcome once process engineers are more familiar with 5nm?

ajross wrote at 2020-10-27 20:51:24:

This bit didn't make a lot of sense to me. SRAM is routinely the MOST optimized and MOST worried-over aspect of silicon layout. SRAM cell architectures get hand-optimized carefully years in advance of any process improvements. They aren't just logic that gets spit out of generic tooling.

So while it would make sense that a new process would have new design rule that didn't map well to older EDA tooling, it's harder to see that argument holding for SRAM. If SRAM isn't scaling, why is general logic?

hajile wrote at 2020-10-27 21:38:20:

> It can be noted that the cell size reduction rate from 2017 to 2018 to 2019 is much slower than the rate for preceding years 2011 to 2017, showing that SRAM cells have not been scaling at the same rate as logic in general. At IEDM 2019, the 5nm process was quoted to have 1.84x logic density improvement compared to 1.35x SRAM density improvement[1]

0.021um per cell [1] for TSMC N5 vs 0.027um per cell [0] for TSMC N7.

Even if Apple did everything right, they'd still be behind due to the limits of the process.

[0]

https://fuse.wikichip.org/news/2408/tsmc-7nm-hd-and-hp-cells...

[1]

https://semiwiki.com/semiconductor-manufacturers/tsmc/283487...

urthor wrote at 2020-10-27 22:02:08:

It's not uncommon for different components to scale differently.

They're often literally made out of different metals that have different resistance characteristics at different wire gauges, for example.

Interconnects was a very famous case, but many aspects of electrical engineering change when you get that small, because hey if you shrink the diameter of a wire by half _guess what happens to the volume_.

Semiconductor engineering is the field of dealing with a thousand of these tiny problems, and an improvement in the photolithography wavelengths is actually an abstraction of solving the thousands of tiny problems involved with all the different materials.

FullyFunctional wrote at 2020-10-27 20:39:03:

They optimize SRAM far in advance of introducing the process, after all this is one of the most critical components. It's very unlikely you'll see any further SRAM improvement on _this_ process, but a process optimization can improve it (and everything else).

jagger27 wrote at 2020-10-27 22:27:06:

I was curious and looked up how this compared to the computer my family had 20 years ago: a Dell XPS tower with a Pentium III. The A14 has more than 1,000x as many transistors as what Intel was doing 20 years ago on a 128mm^2 die. Pretty incredible.

toddmatthews wrote at 2020-10-27 23:50:38:

Had that same computer when I was a senior in high school 1999

nimish wrote at 2020-10-27 20:39:57:

This is about 35% denser than intel 10nm, and not a theoretical number.

throwaway4good wrote at 2020-10-28 09:22:07:

For comparison. The Kirin 9000 (which includes a 5G modem) appears to have 15.3B transistors, the A14 has 11.8B transistors.

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

Has a big table listing a number of historical CPUs.

pwinnski wrote at 2020-10-27 20:10:21:

"A14 comes in at a cool 78% effective transistor density when compared to theoretical density." Wowsers. Apparently SRAM is the limiting factor.

jhloa2 wrote at 2020-10-27 20:12:06:

If SRAM is as ubiquitous throughout chip designs as the article suggests, wouldn't that mean the theoretical density prediction is off?

callesgg wrote at 2020-10-27 20:23:13:

The theoretical maximum density is probably based on some type of physical law or just a simplified model.

That is often what people talk about when they talk about theoretical maximums/minimums.

Like if you have a box of dimensions 10x10x10cm the theoretical maximum number of dice of dimension 1x1x1cm you can fit in the box is 1000 dices.

Chances are you won’t get 1000 dices in to the box as the world is more complex than the theoretical model we used for the scenario.

ineedasername wrote at 2020-10-27 20:42:25:

Which is why if you want to build a box that holds 1000 dice, you need to take into account the +/- tolerances in your build process. At a guess, you'd probably want to build at something like [dimensions] + 2*[tolerance]. So if your build process produced a 10cm cube with +/- 1mm, you'd want to build a 10.2mm cube so even a worse-case -1mm tolerance issue you'd still have +1mm of and so still be able to get the dice in without using force. And assuming the dice themselves didn't have some crazy high tolerance ranges.

I've got a side-gig/hobby making stuff, and the the 2x tolerance works pretty well as a rule of thumb for me, but the project type, material, and application probably play a big part in those considerations. Any industrial/mechanical/materials engineer care to weigh in?

Symmetry wrote at 2020-10-27 20:16:30:

Time for eDRAM! Ok, this process doesn't support eDRAM. Also, I don't understand the SRAM scaling failure here and I don't know if it would apply to eDRAM too. But it's something to think about given the increasing importance of wire delay.

FullyFunctional wrote at 2020-10-27 20:42:25:

I'm not sure you are serious, but eDRAM isn't a direct replacement for SRAM. At best it's useful for L3 or L4 cache given the inherently higher latencies.

I think we just have to accept that silicon scaling is slowing down.

Symmetry wrote at 2020-10-27 20:45:13:

I was assuming last level cache would be the majority of the usage in this case. Maybe I'm wrong.

FullyFunctional wrote at 2020-10-27 21:34:47:

For a desktop CPU that wouldn't be far off, but the A14 has a lot of other stuff so I very much doubt that. However, until we see an actual floor plan this is all speculation.

my123 wrote at 2020-10-27 22:18:24:

On the recent IBM z processors, eDRAM is used even for the L1 chip. And that's above 5GHz.

FullyFunctional wrote at 2020-10-28 00:47:47:

Thanks, I stand corrected!

Isn't eDRAM an IBM-only technology?

tpowell wrote at 2020-10-27 20:26:01:

I was curious just how many chips per wafer they net. From this 2018 article[1], it appears to be ~530 at 5nm, which would be $32ea if that yield is accurate. The same article estimated 7nm chips came out to $18ea.

Apparently, R&D spend went up 50% from 7nm to 5nm. I'm curious to see how many flavors of the A14 Apple cooks up given the comparatively high die cost.

[1]

https://wccftech.com/apple-5nm-3nm-cost-transistors/

wincy wrote at 2020-10-27 20:33:07:

This might be one of the reasons they're transitioning to Apple Silicon, as it will allow them to justify the raising R&D costs over a wider array of products.

macintux wrote at 2020-10-27 21:28:20:

Are Mac volume numbers even a rounding error relative to mobile devices?

saagarjha wrote at 2020-10-27 22:22:35:

Mac sales by volume are about 10% of iPhone sales.

sjwright wrote at 2020-10-28 03:03:45:

While 10% is small in relative terms, it's still huge in absolute terms. And the Mac also remains an important nexus for Apple's wider ecosystem, even if a significant majority of their customers will never own one. Because of the way Apple technology is developed, and by virtue of being largely untethered and unmanaged, Mac is the bootstrap platform for everything else Apple does. It doesn't always have to be so, but I don't see Apple releasing anything else which could take its place.

wmf wrote at 2020-10-27 20:52:52:

I got 656 total dies of which ~600 are good so that's $28.

https://caly-technologies.com/die-yield-calculator/

ineedasername wrote at 2020-10-27 20:36:13:

I thought it was also interesting that cost-per-transistor had remained the same as well.

tpmx wrote at 2020-10-27 20:17:58:

Foundry sale price of $238/chip seems way too high.

See e.g.

https://www.cultofmac.com/658650/iphone-11-pro-max-productio...

Apple A13 processor that (is) supposedly is priced at $64.

twoodfin wrote at 2020-10-27 20:55:28:

Yeah, that $238/chip figure can't possibly be right. Apple's putting this chip in a $700 phone with at least a 50% margin. They're not blowing more than half the BoM on the SoC.

gruez wrote at 2020-10-27 21:09:12:

The $238/chip figure probably isn't for the A14 specifically, considering that it's a chart from an unrelated report[1]

>The model is based on an imaginary 5nm chip the size of Nvidia's P100 GPU (610 mm2, 90.7 billion transistors at 148.2 MTr/mm2).

[1]

https://cset.georgetown.edu/wp-content/uploads/AI-Chips%E2%8...

throwaway4good wrote at 2020-10-28 06:37:56:

In 2004 the cost pr. chip was $2,433 which doesn't make sense either.

Is there a way to read the original report that this post was based upon?

samatman wrote at 2020-10-27 20:22:54:

That is apparently the price to assure that Apple is the only purveyor in town with a 5nm process chip.

Worth it? Apple thinks so.

wmf wrote at 2020-10-27 20:57:34:

Apple doesn't have an exclusive on 5 nm; it's also being used by Kirin 9000, Snapdragon 875, some Exynos, and a future Dimensity SoC.

samatman wrote at 2020-10-27 21:14:16:

I'm not sure how to square that claim with this sort of article:

https://www.extremetech.com/computing/315186-apple-books-tsm...

grandmczeb wrote at 2020-10-27 21:32:11:

Snapdragon 875 is 5nm, but on Samsung's process not TSMC's[1].

[1]

https://www.techpowerup.com/272139/samsung-foundry-to-become...

sroussey wrote at 2020-10-27 23:36:15:

Rumors. Qualcomm is using TMSC 5nm for the x60 this year to be used in products Q1 next year. Same rumors. Though Apple will be using X60 on iPhone 13, so maybe a relation?

SSLy wrote at 2020-10-27 21:26:40:

I believe it's about the remaining fab capacity that was available at that time

throwaway4good wrote at 2020-10-28 06:26:50:

The article is obviously wrong.

wmf wrote at 2020-10-27 21:32:49:

There's also Samsung 5 nm.

grenoire wrote at 2020-10-27 20:21:19:

Somebody has to do it and Apple has the cash, I think they can afford to.

amelius wrote at 2020-10-27 22:12:20:

Isn't this mostly TSMC's achievement?

Can't their other clients reach the same density?

Buraksr wrote at 2020-10-28 06:32:14:

Yes and no. TSMC's process node gives some hard upper limit to what can be built, but whether you can make your design that compact is an open question.

One consideration is that while we think of each transistor as individual and isolated, in reality they are simply wells of n and p type silicon with some oxides and metal thrown in. Because of this we can get unwanted parasitic components and latches. A BJT transistor for example is just a pattern of three silicon types, so it is somewhat inevitable that these will occur, whether they cause issues, and to what extent depends on the design.

Packing everything as tight as possible gives noise concerns, thermal concerns, signal integrity issues ect.

This is not to devalue the achievement of TSMC, but to state that design work is still a work as well.

[1]

https://ieeexplore.ieee.org/document/145696

amelius wrote at 2020-10-28 09:03:58:

Ok, but doesn't Apple use EDA tools for that? Or did they develop their own?

ineedasername wrote at 2020-10-27 20:34:01:

What's the relative heat dissipation between logic & SRAM on a chip? The article talks about layering as a potential way forward for SRAM, but that would come with more complex TDP management, unless SRAM isn't burning watts at the same rate as the rest of the chip.

Tuna-Fish wrote at 2020-10-27 21:47:56:

SRAM can potentially use very little power on modern processes, depending on how fast you want to be able to access it.

If you are just making a relatively low-speed L3, getting rid of the heat produced in the SRAM itself will never be a problem. In general, the problem in SRAM layered on chip is considered to be that the stacked dies are a very good insulator, so the hot active die on the bottom will have heat dissipation problems.

Symmetry wrote at 2020-10-28 11:30:26:

There's also smaller, but less efficient and slower 6 transistors cells versus larger but more efficient and faster 8 transistor cells to compare.

exabrial wrote at 2020-10-27 20:17:24:

For comparison I was trying to nail down what Intel's 7nm process is, but I've found answers between 120nm and 215nm. If anyone knows, that'd be an interesting comparison.

wmf wrote at 2020-10-27 21:34:41:

_Intel's prior CEO, Brian Krzanich, mentioned that 7-nanometer will have "2.4x the compaction ratio" of 10 nm. This puts the 7-nanometer node at around 202-250 million transistors per square millimeter._

https://en.wikichip.org/wiki/7_nm_lithography_process#P1276

kop316 wrote at 2020-10-27 20:22:47:

Considering this news:

https://finance.yahoo.com/news/intel-now-ordering-chips-tsmc...

I sincerely doubt Intel will ever disclose it.

baron816 wrote at 2020-10-27 20:40:54:

Would hate to be the guy that had to count all those transistors.

microtherion wrote at 2020-10-27 20:52:33:

It's not that hard: You just count the pins and divide by 3.

m463 wrote at 2020-10-27 21:42:05:

_"As of 2019, the highest transistor count in any IC chip is Samsung's 1 TB eUFS (3D-stacked) V-NAND flash memory chip, with 2 trillion floating-gate MOSFETs (4 bits per transistor)."_

At 4 bits per transistor and 3 pins, how do you count the samsung bits? :)

Buraksr wrote at 2020-10-28 06:34:58:

The trick is mixing in some good ol analog, and having 2^4 voltages that can be loaded and stored in each transistor

fuck_red_china wrote at 2020-10-27 21:14:40:

That's roughly 3.4B transistors/in^2