Alberto (git.delete@this.git.it) on August 14, 2018 2:50 am wrote:
> Doug S (foo.delete@this.bar.bar) on August 13, 2018 2:01 pm wrote:
> > Maynard Handley (name99.delete@this.name99.org) on August 13, 2018 1:27 pm wrote:
> > > Alberto (git.delete@this.git.it) on August 13, 2018 11:11 am wrote:
> > > > Per Hesselgren (perhesselgren.delete@this.yahoo.se) on August 13, 2018 8:50 am wrote:
> > > > > Threadripper on Anandtech
> > > >
> > > > Great power analysis kudos to Anandtech.
> > > >
> > > > This article gives an idea of the struggles of a many core SKU. Loved the prediction that the
> > > > new and relatively weak upcoming fine nodes will are not able to compensate enough the rising
> > > > amount of complexity and the growing power consumption in intercore and memory access trafic.
> > > >
> > > > Looks like the max core number per socket definitively has a limit and the multisocket
> > > > solution has a bright future even if someone trust the contrary.
> > > >
> > > > My bet AMD 64 cores Epyc will be suboptimal, in fact for now they try the 48 number only to stay safe.
> > >
> > > Your argument makes no sense. Why on earth would the power problem be reduced when crossing
> > > from one socket to another, rather than from one die to another across an interposer?
> > > As long as we are demanding the same things (same level of performance, same degree of snooping)
> > > from cores in a single socket and cores across multiple sockets, the socket communication
> > > is strictly more expensive than the on-die or through-interposer communication.
> > >
> >
> >
> > He doesn't care about logic, he just makes crap up such that somehow magically Intel
> > is always doing things correctly, and AMD / ARM / TSMC / etc. are doing it wrong.
>
> I don't think at all TSMC is doing incorrect things, after all its lucrative focus is very low power
> SOCs and not hot and fast clocked server SKUs, TSMC is doing pretty well even if insanely forced
> and pressed, by phone manufacturers, to make questionable miracles. Still i am pretty sure Intel
> know what is needed in its champ even if "someone" foolishly say that thousands of trusted engineers
> are suddenly transformed in a big bunch of brain damaged morons without an action plan. Not that
> this will change anything, the revenue is here to show who has done the right choice.

Intel's revenues have much to do not necessarily with Intel's right choices, but with incredible inertial forces behind x86, to begin with. Similar forces which made people buy all the crap Intel made before -- think at least Prescott and its derivatives for all market segments Intel served with them. And it could well be revenues Intel rakes in which subverted their managerial vertical into a sort of "anything goes" mentality -- as I feel what situation is like inside the company (don't work there).

But hey, when it comes to the right choice behind Intel's long-winded rise to its current position -- there was one indeed, except made not by Intel, but by IBM back in 1980.

On another unrelated note, that "someone" being apparently me, you have clearly misread one of my conclusions: while on one hand it certainly looks like Intel's engineers are unprepared to face the challenges posed by the process they design, on the other hand they are clearly victims of their senior leadership's choices for 10nm process tech, as decisions like replacing copper with cobalt are certainly not made by the "workhorse" staff. I have little doubt there are bright folks among Intel's engineering ranks who understand all of this -- the technology issues I wrote about, what kind of gamble is behind that bet on cobalt, what kind of money is involved, and just wonder why they should bother at all about someone pocketing a nice kickback as a result of their hard work teaching this pig to fly (in final part).

Intel's 10nm is their process-technology Merced all over again really.