By: bakaneko (nyan.delete@this.hyan.wan), October 31, 2015 7:28 am
Room: Moderated Discussions
dmcq (dmcq.delete@this.fano.co.uk) on October 30, 2015 5:12 am wrote:
> lurker (lurker9000.delete@this.realemail.mail) on October 30, 2015 2:39 am wrote:
> > > First of all - welcome to RWT, glad to hear your perspective.
> >
> > Thanks.
> >
> > > My guess is that everything you say is true...
> >
> > Eh, I just thought I'd post what I heard from a guy who supposedly worked on Zen.
> >
> > > and that AMD isn't intending to hit the HPC
> > > market. They have 128b vectors (since that's all ARM supports), which simply isn't wide
> > > enough to be competitive with Skylake. So giving up on a third AGU makes sense. The third
> > > AGU is probably most helpful for HPC (where they cannot compete anyway) and isn't a particularly
> > > small unit in terms of design complexity and impact on the load/store buffer.
> > >
> > > David
> >
> > 128bit FP pipes seem optimal for most desktop and server software. HPC is pretty
> > much the only place where latest instructions are used and even if zen was competitive
> > here I don't think anyone would want to switch from Intel.
> > Personally I just hope the lack of 3rd AGU won't cause problems in SMT. I don't think
> > normal workloads have that many operations that access memory, but SMT aims to maximize
> > utilization of all available resources and only 2 AGUs might be a problem there.
>
> I think 256 bits would be better as you can do four double precision operations at once and that is quite
> common. On the other hand with four SIMD units instead one could merge two operations to give an effective
> two by 256 bit units except for some special operations. For anything larger they'd probably be better
> off relying on GPUs I think if they can get the coherence and message passing working well. I can see
> how to save larger register sets without impacting interrupt handling too badly but it seems a lot of
> work when ARM is probably hoping to move 64 bit ARM into the embedded processor market.
Except nobody sane would work on large amounts of
doubles for most normal applications. It's really
only useful for HPC, and there some other things
probably matter even more, as floating point can be
the wrong hammer.
> lurker (lurker9000.delete@this.realemail.mail) on October 30, 2015 2:39 am wrote:
> > > First of all - welcome to RWT, glad to hear your perspective.
> >
> > Thanks.
> >
> > > My guess is that everything you say is true...
> >
> > Eh, I just thought I'd post what I heard from a guy who supposedly worked on Zen.
> >
> > > and that AMD isn't intending to hit the HPC
> > > market. They have 128b vectors (since that's all ARM supports), which simply isn't wide
> > > enough to be competitive with Skylake. So giving up on a third AGU makes sense. The third
> > > AGU is probably most helpful for HPC (where they cannot compete anyway) and isn't a particularly
> > > small unit in terms of design complexity and impact on the load/store buffer.
> > >
> > > David
> >
> > 128bit FP pipes seem optimal for most desktop and server software. HPC is pretty
> > much the only place where latest instructions are used and even if zen was competitive
> > here I don't think anyone would want to switch from Intel.
> > Personally I just hope the lack of 3rd AGU won't cause problems in SMT. I don't think
> > normal workloads have that many operations that access memory, but SMT aims to maximize
> > utilization of all available resources and only 2 AGUs might be a problem there.
>
> I think 256 bits would be better as you can do four double precision operations at once and that is quite
> common. On the other hand with four SIMD units instead one could merge two operations to give an effective
> two by 256 bit units except for some special operations. For anything larger they'd probably be better
> off relying on GPUs I think if they can get the coherence and message passing working well. I can see
> how to save larger register sets without impacting interrupt handling too badly but it seems a lot of
> work when ARM is probably hoping to move 64 bit ARM into the embedded processor market.
Except nobody sane would work on large amounts of
doubles for most normal applications. It's really
only useful for HPC, and there some other things
probably matter even more, as floating point can be
the wrong hammer.