Dummond D. Slow (mental.delete@this.protozoa.us) on September 25, 2021 12:49 pm wrote:
> Doug S (foo.delete@this.bar.bar) on September 24, 2021 11:46 pm wrote:
> > --- (---.delete@this.redheron.com) on September 24, 2021 7:06 pm wrote:
> > > Doug S (foo.delete@this.bar.bar) on September 24, 2021 2:12 pm wrote:
> > > > dmcq (dmcq.delete@this.fano.co.uk) on September 24, 2021 1:05 pm wrote:
> > > > > SVE is in multiples of 128 bits so not so bad! I' guess
> > > > > the first hetrogenous system with a size greater than
> > > > > 128 bits will be an Apple one and I guess they'l go for having the same size in both, perhaps they'll share
> > > > > an SVE unit amongst the small cores like ARM. But they haven't even announced a system with SVE yet.
> > > >
> > > >
> > > > Considering Apple was able to ship millions of ARMv8 CPUs less than a year after ARM released the
> > > > spec (a FAR more difficult accomplishment than adding SVE) if Apple was going to ship CPUs with SVE
> > > > they probably would have. SVE was announced as an optional extension to ARMv8.2 over five years ago,
> > > > and SVE2 over two years ago - they also submitted patches for SVE2 to LLVM in late 2019.
> > > >
> > > > Now it is possible that the ARM Mac effort with M1 and soon Jade-C took up too much engineering
> > > > bandwidth and they put SVE2 on the back burner, but if they were planning on introducing
> > > > it at all doing so with the very first ARM Macs (i.e. making that something developers
> > > > could assume exist in every ARM Mac) would be the most logical course.
> > >
> > > Not necessarily.
> > > Until now Apple has debuted new cores with iPhones; so inertia made people believe
> > > this would always be the case. But nothing says it has to be this way!
> > >
> > > Going forward a more logical pattern would be
> > > - new cores introduced via a Mac high-end product, which is a more logical place to ooh and ahh over all
> > > the new whatsits and thingamajigs that have been added to make this core X% faster than its predecessor.
> > >
> > > - two year cadence on cores. This allows for deeper changes, and doesn't have
> > > to mean two year cadence on SoC's, as we saw this year with, essentially,
> > > last year's core but improved GPU, NPU, SLC and who knows what else.
> > >
> > > - this scheme also allows more flexibility in timing. Everyone expects iPhones in September; it
> > > will be tough to break that. But high end Macs arrive when they arrive. The schedule can plan for
> > > the core to be ready in January, but if it slips two months that won't be a catastrophe.
> > >
> > > - Apple already have a scheme of multiple cores and SoCs
> > > of different ages across different products. Expanding
> > > this from the current scheme of two SoC "levels" (good, A#; and better M#) to three including a best level
> > > (new random letter#), and having a given year's products
> > > spread over these three SoCs and two or three cores
> > > is no serious change (look at either iPhones, or at iPads, right now using M1, A15, and A13)
> > >
> > > In other words, I'm not yet convinced that the A15 represents
> > > any sort of intrinsic slow-down in core design,
> > > more that it's just the first SoC of Apple's Phase 3, and
> > > like any such transition it's hard to see the pattern
> > > with only one example. I'd say let's wait for the high end
> > > machines before getting excited. (And high-end means
> > > high-end. I expect the same pattern of a minor upgrade
> > > to the M1 -- pick up the new GPUs, perhaps get either
> > > more RAM or LPDDR5 -- but essentially the A15 core. I'm referring to the iMac Pro/Mac Pro class machines.)
> >
> >
> > Personally I think A15 has a completely unchanged big core from A14. The little cores may be different,
> > or may have gained relatively more clock rate than the big cores, since the MT scores improved a lot
> > more than the ST scores. It is almost impossible the A15 has a new big core - all evidence is that the
> > IPC "gain" is exactly 0%. A new design would improve IPC or at least CHANGE it in various workloads,
> > but the odds changes of IPC across all workloads would cancel out to exactly 0% are pretty long.
> >
> > Why reuse the A14 core? I think it is probably like you're
> > saying - assuming the Jade-C rumors are true they
> > will be releasing some higher end Macs later this year or
> > early next year. i.e. the ones using a single Jade-C
> > - the ones using multiple Jade-Cs as chiplets will be announced at WWDC next June if I had to guess.
> >
> > I think Jade-C gets the new core, which may also appear
> > in the A16 in next year's iPhone, depending on whether
> > that uses N4 or N3. There are rumors about Apple using N4 for Macs, if Apple targeted N4 for the new core
> > that would explain why A15 got a recycled core since it
> > is using N5P. N4 reportedly enters volume production
> > next month, so depending on how many working Jade-C dies they could get from risk production they might be
> > able to ship some new Macs for Christmas but by January
> > for sure. With N3 not entering volume production until
> > July it may not be feasible for A16, unless they are willing
> > to delay their normal September launch or accept
> > the potential for greater initial shortages of iPhones than they've had the last few years.
> >
> > However I still think if Apple was going to add SVE2 it would be stupid to have missed adding
> > it to the M1 when we know they easily could have based on their record with ARMv8. It makes
> > too much sense to make SVE2 a guaranteed feature of every ARM Mac so developers could assume
> > its existence. So I don't expect to see it in Jade-C, or the A16 for that matter. Had they
> > put a 128 bit SVE2 in M1 they might put a wider one in Jade-C for the higher end stuff.
>
> I agree with the reasoning but when Apple transitioned to x86, they did the opposite of this too.
> They launched without 64bit even if it was close toebing available by that point, and precisely
> missed the opportunity to have a more advanced baseline setup that would guarantee 64bit etc.

I criticized Apple for not going strait to 64 bit x86, which meant AMD at the time.
But Intel undoubtedly offered a sweet deal, and most of the developers had 32 bit code, and it was laptops where PowerPC was not competitive, which means 32 bit code.

Apple may have been concerned with developer porting fear, the jump to 64 bits is a high bar and many may have abandoned Mac development instead. Safer to make the port a simple rebuild and debug, than a complete rewrite for 64 bit.

There was a big fight with Adobe who refused to port its 32 bit code, and waited until a competitor showed up on Apple and then ported the 64 bit code, and bought out the competitor.

> Perhaps Apple doesn't give a damn about the longevity of the first generation again? I think some people
> like Maynard even used to say something like "1st gen is early adopters so this is fine" iirc.

Early Apple adopters buying desktops did get screwed, having to replace those machines with 64 bit quickly.