By: Eric (eric.kjellen.delete@this.gmail.com), July 27, 2012 3:29 pm
Room: Moderated Discussions
hobold (hobold.delete@this.vectorizer.org) on July 27, 2012 2:48 pm wrote:
> Eric (eric.kjellen.delete@this.gmail.com) on July 27, 2012 12:51 pm wrote:
> >
> hobold (hobold.delete@this.vectorizer.org) on July 27, 2012 11:53 am
> >
> wrote:
> [...]
> > > Do not rely
> > CPUs maintaining the extent of this
> relative advantage over
> > > GPUs. GPUs
> > can still harvest a few
> fruits that aren't exactly low hanging, but
> > > well
> > in reach.
> CPUs have a hard time even only touching more fruit with merely
> >
> >
> > the tips of their outstretched metaphorical fingers.
> > >
>
> > >
> >
> > But
> > wouldn't that decrease their advantage in
> compute efficiency in a rather linear
> > fashion? I.e. CPU and GPU
> architectures would converge and make it a straight-up
> > race of process
> technology, memory bandwidth, cache latency, brand predictor
> > quality etc.
> I don't see AMD or Nvidia winning that kind of contest in the long
> > run
> either.
>
> In the limit, convergence would be perfect, and everyone would have
> more or less the same product. For that reason, I don't dare to predict a winner
> either.
>
> What I am trying to say is that the race can go on for quite a while
> yet. CPUs will focus more on improving or at least maintaining good single
> thread performance for spaghetti code, and GPUs will focus more on increasing or
> at least maintaining a throughput advantage. Each will still try to invade into
> the other's markets, but has to be careful not to give up their traditional lead
> (and lose the corresponding customers).
>
> The tendency for convergence is
> strong, perhaps irresistible. But I think some repelling force will emerge as
> both try to maintain their historical advantage over the other. In some sense,
> the integration of on-chip GPUs into CPUs on the one hand, and Nvidia's
> diversification into ARM-SOCs on the other hand, is the result of both sides
> trying to avoid convergence. Instead, they mate two well differentiated types of
> processor on a single integrated piece of silicon.
>
> Of course, there is also
> Larrabee ... but it has morphed into something that is no longer expected to
> excel at neither a CPU's nor a GPU's strengths. It looks like convergence cannot
> be rushed along this particular shortcut. At least not yet.
The problem I see is that CPUs and GPUs are nowhere near each other in how well-established they are on the current market. CPUs, especially x86 CPUs, run HPC workloads as the norm and they run our operating systems and most of our programs exclusively. That means that if CPUs gain throughput as fast as GPUs gain programmability, it's still not an equal race since (GP)GPUs remain an exception (in HPC but most of all in personal computing) and have to justify their own existence whereas the CPUs will be there anyway.
That means that since the addressable market for vector-capable CPUs is much larger than that for GPGPUs, most code will be written and optimized for them and the legacy and volume advantage will only grow further. It's a self-reinforcing cycle for CPUs and I can see that extinguishing the market for GPGPUs faster than some might expect. That might not happen if GPGPUs increase in their capabilities (both raw performance and programming models) very quickly and thereby solidifiy the unique case for buying GPGPUs (and provide enough revenue for the makers to fund R&D to keep the advantage), but so far what I have seen from both AMD and Nvidia doesn't inspire much confidence in me in their ability to do so.
> Eric (eric.kjellen.delete@this.gmail.com) on July 27, 2012 12:51 pm wrote:
> >
> hobold (hobold.delete@this.vectorizer.org) on July 27, 2012 11:53 am
> >
> wrote:
> [...]
> > > Do not rely
> > CPUs maintaining the extent of this
> relative advantage over
> > > GPUs. GPUs
> > can still harvest a few
> fruits that aren't exactly low hanging, but
> > > well
> > in reach.
> CPUs have a hard time even only touching more fruit with merely
> >
> >
> > the tips of their outstretched metaphorical fingers.
> > >
>
> > >
> >
> > But
> > wouldn't that decrease their advantage in
> compute efficiency in a rather linear
> > fashion? I.e. CPU and GPU
> architectures would converge and make it a straight-up
> > race of process
> technology, memory bandwidth, cache latency, brand predictor
> > quality etc.
> I don't see AMD or Nvidia winning that kind of contest in the long
> > run
> either.
>
> In the limit, convergence would be perfect, and everyone would have
> more or less the same product. For that reason, I don't dare to predict a winner
> either.
>
> What I am trying to say is that the race can go on for quite a while
> yet. CPUs will focus more on improving or at least maintaining good single
> thread performance for spaghetti code, and GPUs will focus more on increasing or
> at least maintaining a throughput advantage. Each will still try to invade into
> the other's markets, but has to be careful not to give up their traditional lead
> (and lose the corresponding customers).
>
> The tendency for convergence is
> strong, perhaps irresistible. But I think some repelling force will emerge as
> both try to maintain their historical advantage over the other. In some sense,
> the integration of on-chip GPUs into CPUs on the one hand, and Nvidia's
> diversification into ARM-SOCs on the other hand, is the result of both sides
> trying to avoid convergence. Instead, they mate two well differentiated types of
> processor on a single integrated piece of silicon.
>
> Of course, there is also
> Larrabee ... but it has morphed into something that is no longer expected to
> excel at neither a CPU's nor a GPU's strengths. It looks like convergence cannot
> be rushed along this particular shortcut. At least not yet.
The problem I see is that CPUs and GPUs are nowhere near each other in how well-established they are on the current market. CPUs, especially x86 CPUs, run HPC workloads as the norm and they run our operating systems and most of our programs exclusively. That means that if CPUs gain throughput as fast as GPUs gain programmability, it's still not an equal race since (GP)GPUs remain an exception (in HPC but most of all in personal computing) and have to justify their own existence whereas the CPUs will be there anyway.
That means that since the addressable market for vector-capable CPUs is much larger than that for GPGPUs, most code will be written and optimized for them and the legacy and volume advantage will only grow further. It's a self-reinforcing cycle for CPUs and I can see that extinguishing the market for GPGPUs faster than some might expect. That might not happen if GPGPUs increase in their capabilities (both raw performance and programming models) very quickly and thereby solidifiy the unique case for buying GPGPUs (and provide enough revenue for the makers to fund R&D to keep the advantage), but so far what I have seen from both AMD and Nvidia doesn't inspire much confidence in me in their ability to do so.
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 |