By: David Kanter (dkanter.delete@this.realworldtech.com), July 30, 2012 9:32 pm
Room: Moderated Discussions
Ingeneer (a.delete@this.b.c) on July 30, 2012 8:04 pm wrote:
> David Kanter (dkanter.delete@this.realworldtech.com) on July 30, 2012 1:11 pm
> wrote:
> > Ingeneer (a.delete@this.b.c) on July 30, 2012 9:01 am wrote:
> >
> > Thanks for
> > the new graph, I've been meaning to create one like that
> myself for a
> > >
> > while now (don't worry, I'll credit you when I
> use it).
> > >
> > > The article
> > is quite
> > > amusing
> in the way that you apparently want to say GPGPU is
> > f*cked when Haswell
>
> > > hits the street. It's going to practically double the
> > compute
> efficiency, which
> > > I'm sure you know but you must be bound by an
>
> > NDA so you can't mention
> > > it.
> >
> > Well, I'm not
> convinced that is true.
> > Yes, Haswell should double the FLOPs. However,
> at the same time, AMD and Nvidia
> > are moving to 28nm which should also
> double the FLOPs. Knights Corner is a
> > wildcard, but we know roughly
> where that will end up - around 1TFLOP/s, but the
> > die area and power
> consumption is unclear.
> >
> > I think the gap may narrow a bit,
> >
> but you won't see CPUs catching GPUs soon.
>
> The point is that CPU compute
> efficiency will double - on the same process.
I don't know if it will double, it might be a bit less. Haswell is definitely a larger core.
> So you might as well imagine it to
> be available today, to get an idea of what the compute landscape will be like in
> the near future. Indeed compute-oriented GPUs still have to move to 28 nm, but
> Intel will move to 14 nm soon after that (a 2.5x increase in density).
That's true, but Intel server chips won't be on 14nm immediately (I'm guessing). Typically, they tend to wait 2-4 quarters before producing server chips to get yields up.
I guess what I'm saying is that you can't really compare Intel's 14nm chips to TSMC 28nm chips unless the foundry market radically changes.
You can reasonably argue that TSMC is 12-24 months behind (effectively a whole node). I don't think they are 36 or 48 months behind at all and I'm not sure that big a gap will open up. Intel can press ahead of TSMC and others by a certain amount, but the costs are higher the bigger the gap is. I don't know if Intel would really want to be 2 nodes ahead (in terms of lithography)...but I haven't ever asked.
> > It's a good thing NVIDIA
> > realized that mainstream GPGPU has no
> future and
> > > they focus on graphics
> > again with GK104. Too bad
> AMD will have to learn the hard
> > > way that
> > Fusion/HSA is
> DOA.
> >
> > GK110 will be plenty compute focused and reasonably
> >
> attractive. It is good that they have a nice and efficient graphics variant
>
> > though...while the margins are great for compute, the volume is clearly
> in
> > discrete graphics.
>
> Yep. For now at least. Intel could create
> homogeneous mainstream CPUs with TFLOPS of computing/graphics power in the not
> too distant future. So although I feel sorry for AMD that HSA is DOA, NVIDIA
> will be off worse if Intel kills its mid-end graphics market. They need a strong
> line of CPUs that covers multiple market segments, soon.
Not sure HSA is dead, we'll have to see what it is first. But the shrinking GPU market is definitely a concern for Nvidia. Hence the transition to SoCs.
David
> David Kanter (dkanter.delete@this.realworldtech.com) on July 30, 2012 1:11 pm
> wrote:
> > Ingeneer (a.delete@this.b.c) on July 30, 2012 9:01 am wrote:
> >
> > Thanks for
> > the new graph, I've been meaning to create one like that
> myself for a
> > >
> > while now (don't worry, I'll credit you when I
> use it).
> > >
> > > The article
> > is quite
> > > amusing
> in the way that you apparently want to say GPGPU is
> > f*cked when Haswell
>
> > > hits the street. It's going to practically double the
> > compute
> efficiency, which
> > > I'm sure you know but you must be bound by an
>
> > NDA so you can't mention
> > > it.
> >
> > Well, I'm not
> convinced that is true.
> > Yes, Haswell should double the FLOPs. However,
> at the same time, AMD and Nvidia
> > are moving to 28nm which should also
> double the FLOPs. Knights Corner is a
> > wildcard, but we know roughly
> where that will end up - around 1TFLOP/s, but the
> > die area and power
> consumption is unclear.
> >
> > I think the gap may narrow a bit,
> >
> but you won't see CPUs catching GPUs soon.
>
> The point is that CPU compute
> efficiency will double - on the same process.
I don't know if it will double, it might be a bit less. Haswell is definitely a larger core.
> So you might as well imagine it to
> be available today, to get an idea of what the compute landscape will be like in
> the near future. Indeed compute-oriented GPUs still have to move to 28 nm, but
> Intel will move to 14 nm soon after that (a 2.5x increase in density).
That's true, but Intel server chips won't be on 14nm immediately (I'm guessing). Typically, they tend to wait 2-4 quarters before producing server chips to get yields up.
I guess what I'm saying is that you can't really compare Intel's 14nm chips to TSMC 28nm chips unless the foundry market radically changes.
You can reasonably argue that TSMC is 12-24 months behind (effectively a whole node). I don't think they are 36 or 48 months behind at all and I'm not sure that big a gap will open up. Intel can press ahead of TSMC and others by a certain amount, but the costs are higher the bigger the gap is. I don't know if Intel would really want to be 2 nodes ahead (in terms of lithography)...but I haven't ever asked.
> > It's a good thing NVIDIA
> > realized that mainstream GPGPU has no
> future and
> > > they focus on graphics
> > again with GK104. Too bad
> AMD will have to learn the hard
> > > way that
> > Fusion/HSA is
> DOA.
> >
> > GK110 will be plenty compute focused and reasonably
> >
> attractive. It is good that they have a nice and efficient graphics variant
>
> > though...while the margins are great for compute, the volume is clearly
> in
> > discrete graphics.
>
> Yep. For now at least. Intel could create
> homogeneous mainstream CPUs with TFLOPS of computing/graphics power in the not
> too distant future. So although I feel sorry for AMD that HSA is DOA, NVIDIA
> will be off worse if Intel kills its mid-end graphics market. They need a strong
> line of CPUs that covers multiple market segments, soon.
Not sure HSA is dead, we'll have to see what it is first. But the shrinking GPU market is definitely a concern for Nvidia. Hence the transition to SoCs.
David
Topic | Posted By | Date |
---|---|---|
New Article: Compute Efficiency 2012 | David Kanter | 2012/07/25 01:37 AM |
New Article: Compute Efficiency 2012 | SHK | 2012/07/25 02:31 AM |
New Article: Compute Efficiency 2012 | David Kanter | 2012/07/25 02:42 AM |
New Article: Compute Efficiency 2012 | none | 2012/07/25 03:18 AM |
New Article: Compute Efficiency 2012 | David Kanter | 2012/07/25 11:25 AM |
GCN (NT) | EBFE | 2012/07/25 03:25 AM |
GCN - TFLOP DP | jp | 2012/08/09 01:58 PM |
GCN - TFLOP DP | David Kanter | 2012/08/09 03:32 PM |
GCN - TFLOP DP | Kevin G | 2012/08/11 05:22 PM |
GCN - TFLOP DP | Eric | 2012/08/09 05:12 PM |
GCN - TFLOP DP | jp | 2012/08/10 01:23 AM |
GCN - TFLOP DP | EBFE | 2012/08/12 08:27 PM |
GCN - TFLOP DP | jp | 2012/08/13 02:02 AM |
GCN - TFLOP DP | EBFE | 2012/08/13 07:45 PM |
GCN - TFLOP DP | jp | 2012/08/14 01:21 AM |
New Article: Compute Efficiency 2012 | Adrian | 2012/07/25 04:39 AM |
New Article: Compute Efficiency 2012 | EBFE | 2012/07/25 09:33 AM |
New Article: Compute Efficiency 2012 | David Kanter | 2012/07/25 11:11 AM |
New Article: Compute Efficiency 2012 | sf | 2012/07/25 06:46 AM |
New Article: Compute Efficiency 2012 | aaron spink | 2012/07/25 09:08 AM |
New Article: Compute Efficiency 2012 | someone | 2012/07/25 10:06 AM |
New Article: Compute Efficiency 2012 | David Kanter | 2012/07/25 11:14 AM |
New Article: Compute Efficiency 2012 | EBFE | 2012/07/26 02:27 AM |
BG/Q | David Kanter | 2012/07/26 09:31 AM |
VR-ZONE KNC B0 leak, poor number? | EBFE | 2012/08/03 01:57 AM |
VR-ZONE KNC B0 leak, poor number? | Eric | 2012/08/03 07:59 AM |
VR-ZONE KNC B0 leak, poor number? | EBFE | 2012/08/04 06:37 AM |
VR-ZONE KNC B0 leak, poor number? | aaron spink | 2012/08/04 06:51 PM |
Leaks != products | David Kanter | 2012/08/05 03:19 AM |
Leaks != products | EBFE | 2012/08/06 02:49 AM |
VR-ZONE KNC B0 leak, poor number? | Eric | 2012/08/05 10:37 AM |
VR-ZONE KNC B0 leak, poor number? | EBFE | 2012/08/06 03:09 AM |
VR-ZONE KNC B0 leak, poor number? | aaron spink | 2012/08/06 04:33 AM |
VR-ZONE KNC B0 leak, poor number? | jp | 2012/08/07 03:08 AM |
VR-ZONE KNC B0 leak, poor number? | Eric | 2012/08/07 04:58 AM |
VR-ZONE KNC B0 leak, poor number? | jp | 2012/08/07 05:17 AM |
VR-ZONE KNC B0 leak, poor number? | Eric | 2012/08/07 05:22 AM |
VR-ZONE KNC B0 leak, poor number? | anonymou5 | 2012/08/07 09:43 AM |
VR-ZONE KNC B0 leak, poor number? | jp | 2012/08/07 05:23 AM |
VR-ZONE KNC B0 leak, poor number? | aaron spink | 2012/08/07 07:24 AM |
VR-ZONE KNC B0 leak, poor number? | aaron spink | 2012/08/07 07:20 AM |
VR-ZONE KNC B0 leak, poor number? | jp | 2012/08/07 11:22 AM |
VR-ZONE KNC B0 leak, poor number? | EduardoS | 2012/08/07 03:15 PM |
KNC has FMA | David Kanter | 2012/08/07 09:17 AM |
New Article: Compute Efficiency 2012 | forestlaughing | 2012/07/25 08:51 AM |
New Article: Compute Efficiency 2012 | Eric | 2012/07/27 05:12 AM |
New Article: Compute Efficiency 2012 | hobold | 2012/07/27 11:53 AM |
New Article: Compute Efficiency 2012 | Eric | 2012/07/27 12:51 PM |
New Article: Compute Efficiency 2012 | hobold | 2012/07/27 02:48 PM |
New Article: Compute Efficiency 2012 | Eric | 2012/07/27 03:29 PM |
New Article: Compute Efficiency 2012 | anon | 2012/07/29 02:25 AM |
New Article: Compute Efficiency 2012 | hobold | 2012/07/29 11:53 AM |
Efficiency? No, lack of highly useful features | someone | 2012/07/25 09:58 AM |
Best case for GPUs | David Kanter | 2012/07/25 11:28 AM |
Best case for GPUs | franzliszt | 2012/07/25 01:39 PM |
Best case for GPUs | Chuck | 2012/07/25 08:13 PM |
Best case for GPUs | David Kanter | 2012/07/25 09:45 PM |
Best case for GPUs | Eric | 2012/07/27 05:51 AM |
Silverthorn data point | Michael S | 2012/07/25 02:45 PM |
Silverthorn data point | David Kanter | 2012/07/25 04:06 PM |
New Article: Compute Efficiency 2012 | Unununium | 2012/07/25 05:55 PM |
New Article: Compute Efficiency 2012 | EduardoS | 2012/07/25 08:12 PM |
Ops... I'm wrong... | EduardoS | 2012/07/25 08:14 PM |
New Article: Compute Efficiency 2012 | TacoBell | 2012/07/25 08:36 PM |
New Article: Compute Efficiency 2012 | David Kanter | 2012/07/25 09:49 PM |
New Article: Compute Efficiency 2012 | Michael S | 2012/07/26 02:33 AM |
Line and factor | Moritz | 2012/07/26 01:34 AM |
Line and factor | Peter Boyle | 2012/07/27 07:57 AM |
not entirely | Moritz | 2012/07/27 12:22 PM |
Line and factor | EduardoS | 2012/07/27 05:24 PM |
Line and factor | Moritz | 2012/07/28 12:52 PM |
tables | Michael S | 2012/07/26 02:39 AM |
Interlagos L2+L3 | Rana | 2012/07/26 03:13 AM |
Interlagos L2+L3 | Rana | 2012/07/26 03:13 AM |
Interlagos L2+L3 | David Kanter | 2012/07/26 09:21 AM |
SP vs DP & performance metrics | jp | 2012/07/27 07:08 AM |
SP vs DP & performance metrics | Eric | 2012/07/27 07:57 AM |
SP vs DP & performance metrics | jp | 2012/07/27 09:18 AM |
SP vs DP & performance metrics | aaron spink | 2012/07/27 09:36 AM |
SP vs DP & performance metrics | jp | 2012/07/27 09:47 AM |
"Global" --> system | Paul A. Clayton | 2012/07/27 10:31 AM |
"Global" --> system | jp | 2012/07/27 03:55 PM |
"Global" --> system | aaron spink | 2012/07/27 07:33 PM |
"Global" --> system | jp | 2012/07/28 02:00 AM |
"Global" --> system | aaron spink | 2012/07/28 06:54 AM |
"Global" --> system | jp | 2012/07/29 02:12 AM |
"Global" --> system | aaron spink | 2012/07/29 05:03 AM |
"Global" --> system | none | 2012/07/29 09:05 AM |
"Global" --> system | EduardoS | 2012/07/29 10:26 AM |
"Global" --> system | jp | 2012/07/30 02:24 AM |
"Global" --> system | aaron spink | 2012/07/30 03:05 AM |
"Global" --> system | aaron spink | 2012/07/30 03:03 AM |
daxpy is STREAM TRIAD | Paul A. Clayton | 2012/07/30 06:10 AM |
SP vs DP & performance metrics | aaron spink | 2012/07/27 07:25 PM |
SP vs DP & performance metrics | Emil Briggs | 2012/07/28 06:40 AM |
SP vs DP & performance metrics | aaron spink | 2012/07/28 07:05 AM |
SP vs DP & performance metrics | jp | 2012/07/28 11:04 AM |
SP vs DP & performance metrics | Brett | 2012/07/28 03:32 PM |
SP vs DP & performance metrics | Emil Briggs | 2012/07/28 06:11 PM |
SP vs DP & performance metrics | anon | 2012/07/29 02:53 AM |
SP vs DP & performance metrics | aaron spink | 2012/07/29 05:39 AM |
Coherency for discretes | Rohit | 2012/07/29 09:24 AM |
SP vs DP & performance metrics | anon | 2012/07/29 11:09 AM |
SP vs DP & performance metrics | Eric | 2012/07/29 01:08 PM |
SP vs DP & performance metrics | aaron spink | 2012/07/27 09:25 AM |
Regular updates? | Joe | 2012/07/27 09:35 AM |
New Article: Compute Efficiency 2012 | 309 | 2012/07/27 10:34 PM |
New Article: Compute Efficiency 2012 | Ingeneer | 2012/07/30 09:01 AM |
New Article: Compute Efficiency 2012 | David Kanter | 2012/07/30 01:11 PM |
New Article: Compute Efficiency 2012 | Ingeneer | 2012/07/30 08:04 PM |
New Article: Compute Efficiency 2012 | David Kanter | 2012/07/30 09:32 PM |
Memory power and bandwidth? | Iain McClatchie | 2012/08/03 04:35 PM |
Memory power and bandwidth? | David Kanter | 2012/08/04 11:22 AM |
Memory power and bandwidth? | Michael S | 2012/08/04 02:36 PM |
Memory power and bandwidth? | Iain McClatchie | 2012/08/06 02:09 PM |
Memory power and bandwidth? | Eric | 2012/08/07 06:28 PM |
Workloads | David Kanter | 2012/08/08 10:49 AM |
Workloads | Eric | 2012/08/09 05:21 PM |
Latency and bandwidth bottlenecks | Paul A. Clayton | 2012/08/08 04:02 PM |
Latency and bandwidth bottlenecks | Eric | 2012/08/09 05:32 PM |
Latency and bandwidth bottlenecks | none | 2012/08/10 06:06 AM |
Latency and bandwidth bottlenecks -> BDP | ajensen | 2012/08/11 03:21 PM |
Memory power and bandwidth? | Ingeneer | 2012/08/06 11:26 AM |
NV aims for 1.8+ TFLOPS DP ? | jp | 2012/08/11 01:21 PM |
NV aims for 1.8+ TFLOPS DP ? | David Kanter | 2012/08/11 09:25 PM |
NV aims for 1.8+ TFLOPS DP ? | jp | 2012/08/12 02:45 AM |
NV aims for 1.8+ TFLOPS DP ? | EBFE | 2012/08/12 10:02 PM |
NV aims for 1.8+ TFLOPS DP ? | jp | 2012/08/13 01:54 AM |
NV aims for 1.8+ TFLOPS DP ? | Gabriele Svelto | 2012/08/13 09:16 AM |
NV aims for 1.8+ TFLOPS DP ? | Vincent Diepeveen | 2012/08/14 03:04 AM |
NV aims for 1.8+ TFLOPS DP ? | David Kanter | 2012/08/13 09:50 AM |
NV aims for 1.8+ TFLOPS DP ? | jp | 2012/08/13 11:17 AM |
NV aims for 1.8+ TFLOPS DP ? | EduardoS | 2012/08/13 06:45 AM |