Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"I prefer the blunted cudgels of the followers of the Serpent God." -- Sean Doran the Younger


devel / comp.arch / Re: does area matter? was: instruction set binding time

SubjectAuthor
* does area matter? was: instruction set binding timeIvan Godard
`- Re: does area matter? was: instruction set binding timeMitchAlsup

1
does area matter? was: instruction set binding time

<suvm9b$1l9$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23727&group=comp.arch#23727

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: does area matter? was: instruction set binding time
Date: Mon, 21 Feb 2022 01:33:31 -0800
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <suvm9b$1l9$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 21 Feb 2022 09:33:33 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="292ea7d621bd2f9ee11298ee908c5ea5";
logging-data="1705"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Y0pfAKkHJdfE+t7DHoEpS"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:TBcgbkg5ge12wZjqw/qi5oEeh60=
Content-Language: en-US
 by: Ivan Godard - Mon, 21 Feb 2022 09:33 UTC

On 2/20/2022 6:05 PM, Paul A. Clayton wrote:
> Ivan Godard wrote:
>> On 2/18/2022 8:42 AM, Paul A. Clayton wrote:

<snip>

>>> I doubt the Mill will get a 12x PPA advantage over an OoO
>>> implementation of a conventional ISA like AArch64.
>>
>> 12x is not my number (see Mitch), and in any case we have given up
>> some of whatever it is to pay for width.
>
> Mitch's 12x core (including L1) area and power advantage for a scalar
> in-order core came with a 2x performance disadvantage. (He also
> mentioned that system power more nearly tracks performance. OoO
> speculation may generate excessive cache/interconnect and memory
> traffic, but such is probably not especially great. Hardware prefetching
> may have worse misspeculation energy cost. How much of the chip power is
> used by such "system" activity — L2 accesses, memory controllers, etc. —
> would seem to be workload dependent. Even including L2 caches in core
> area, it seems that more than half of the chip _area_ is used by
> non-core hardware for most great-big-OoO designs without any special
> accelerators and with significant FP SIMD 'bloating' the cores; Intel's
> Golden Cove core's 1.25 MiB L2 seems to be about a quarter of that
> "core" area, while AMD's Zen2 L2 looks to use about a sixth of the
> "core" area.)
>
> If a Mill's processing hardware is much more area efficient for a given
> level of performance, system components will be a larger fraction of
> chip area. System hardware activity would be more difficult to compare.
> The Mill's fine-grained validity seems likely to make coherence a little
> more expensive, particularly with guarantees of sequential consistency
> (if such is still expected to be provided). Avoiding read for ownership
> will provide some performance and energy advantage, but the
> read-for-ownership advantage of backless stores could — I believe — be
> provided to conventional ISAs without application changes (avoiding zero
> initialization would require application changes).
What matters in the real world is money. Translated to fabs, that is
yield per wafer. There are two factors that influence yield. One is raw
size - how many candidate chips can fit on a wafer of given diameter;
this is what Paul addresses above. As he says, this factor is heavily
weighted by the uncore part of the chip: if a Mill core is (say) 15% as
big as a OOO of same performance, and cores are only half the space of
the whole chip, then you might get 40% more chips on a wafer - not
inconsiderable, but not vital either.

But there's the other factor to consider: the defect rate. It doesn't
matter how big your chip is if you are only getting one good chip per
wafer. And here not all defects are equal. Well established tech has
found ways to deal with spot defects, but only in regular structures in
which the chip design can provide spares. It doesn't matter if there's a
bad cell in a cache - just fuse in a spare. Of course sparing has costs
too - I have heard rumors to the effect that Intel's 10nm fab troubles
arose in part because the defect rate in caches was so high that the
sparing wiring was impacting clock rate even when spares were not needed
(I have no idea whether this is true).

However, sparing only substitutes identical components: a cache cell for
another cell, or a whole core for another... except you don't have spare
cores, so you must just turn the defective core off and bin the chip as
a downgraded part, and lose the price margin from a high-end part.

In practice, the great majority of the uncore of a chip is regular
enough for sparing. The part of the chip that is random logic (e.g the
cores) can't be spared - a one transistor speck defect in the core kills
the money, while one in the cache is ignorable unless you get more
defects than spares. Mitch might know numbers for the balance of chip
fails between core and uncore in the chips he did; current numbers are
closely guarded secrets among the fabbers, but to a close approximation
we can say that *all* defects occur in the area occupied by the cores.

So smaller cores matter: in the early days of a new chip, when profits -
and defect rates - are high, an 8X smaller core is an 8x smaller defect
rate, and that's too big to be ignored. Of course later on, when the fab
has gotten its process shook out, the overall defect rate will drop to
the point where 8x fewer defects no longer matter - but by then other
fabs will have caught up and driven the margins down. And by then you
are breaking in a new process, and 8x matters again...

Fab is a tough business. Core area matters.

Re: does area matter? was: instruction set binding time

<ddc566f4-84e2-4218-bc6b-a9cd8097842an@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23737&group=comp.arch#23737

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a5d:5983:0:b0:1e5:7dd6:710 with SMTP id n3-20020a5d5983000000b001e57dd60710mr17105641wri.392.1645467012594;
Mon, 21 Feb 2022 10:10:12 -0800 (PST)
X-Received: by 2002:a05:6808:1208:b0:2d4:419d:8463 with SMTP id
a8-20020a056808120800b002d4419d8463mr111498oil.227.1645467011971; Mon, 21 Feb
2022 10:10:11 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 21 Feb 2022 10:10:11 -0800 (PST)
In-Reply-To: <suvm9b$1l9$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:4914:1ee7:1a29:43f9;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:4914:1ee7:1a29:43f9
References: <suvm9b$1l9$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ddc566f4-84e2-4218-bc6b-a9cd8097842an@googlegroups.com>
Subject: Re: does area matter? was: instruction set binding time
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 21 Feb 2022 18:10:12 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 8
 by: MitchAlsup - Mon, 21 Feb 2022 18:10 UTC

On Monday, February 21, 2022 at 1:33:36 AM UTC-8, Ivan Godard wrote:
> On 2/20/2022 6:05 PM, Paul A. Clayton wrote:
> > Ivan Godard wrote:
>
> Fab is a tough business. Core area matters.
<
Pretty reasonable summary,
<
But costs go with about x^2.3 to x^2.7 not just with area x^2.

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor