Jump to content

  • Log In with Google      Sign In   
  • Create Account


What is the difference between CPU and GPU?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
19 replies to this topic

#1 ynm   Members   -  Reputation: 168

Like
0Likes
Like

Posted 23 November 2012 - 08:30 AM

Hi everyone,

As I understand, CPU is central processing unit which I can program it to do some works, and GPU is something you can program it do do some works, in parallel but its function is limited, e.g it can add but can not multiply. But as all computer world is based on binary bits and logic functions AND, OR, NOT, so if one tries, he can program GPU to do whatever CPU can do, right? Or there are works that CPU can do but GPU can not do?

Regards

Sponsor:

#2 Tispe   Members   -  Reputation: 978

Like
8Likes
Like

Posted 23 November 2012 - 08:39 AM

The CPU is often a chip on the motherboard under a huge heatsink. The GPU is a chip (also under a heatsink) on an expansion card sitting on a PCI-e, AGP or PCI slot on the motherboard.

The CPU is where everything runs, windows etc. All programs also runs on the CPU. The GPU is an "extension" to the CPU. The GPU and CPU communicate using a bus, most often the PCIe bus. The CPU has its system memory and the GPU has its device memory.

The GPU is optimized for doing many calculations using floats. For this reason data is sent to the GPU memory to do a huge number of float operations. The bonus is that the video input to your monitor is hooked up to the GPU memory such that you can generate animation in real time on the GPU without tranferring the result back to system memory.

The GPU and CPU can do most of the same math operations, but the GPU is optimized for floats.

Edited by Tispe, 23 November 2012 - 08:43 AM.


#3 Radikalizm   Crossbones+   -  Reputation: 2766

Like
6Likes
Like

Posted 23 November 2012 - 08:47 AM

The CPU is indeed the Central Processing Unit, commonly referred to as 'the processor' of your computer. The GPU is the Graphics Processing Unit, which is a processor chip found on your graphics card.

The CPU is designed for general purpose usage and depending on its architecture it can provide security features (like protection rings in the x86 architecture), different operating modes and a whole bunch of possible extensions.

The GPU was originally designed solely for doing graphics-related jobs and can process a huge amount of floating point operations in comparison to your standard CPU. I don't know where you got your information about available operations on GPUs, but they can definitely do multiplication (would be quite terrible if they weren't able to do something this trivial).

These days the GPU is used more and more for general purpose tasks which involve heavy number crunching, but generally speaking a GPU's ISA (Instruction Set Architecture) is much more limited than your common CPU's ISA.

Edited by Radikalizm, 23 November 2012 - 08:48 AM.


#4 ynm   Members   -  Reputation: 168

Like
0Likes
Like

Posted 23 November 2012 - 08:53 AM

Thanks,


Can GPU do branch commands like 'if'? And I heard that some kinds of the best ray tracing engine can only do with CPU, is this true and why don't they use GPU for the maths?

Can a computer run on GPU alone? If not then why?


Regards

PS: @Radikalizm, the example of add and multiply is just an example because I don't know how to say it clearly

#5 Tispe   Members   -  Reputation: 978

Like
4Likes
Like

Posted 23 November 2012 - 09:02 AM

You don't write whole programs for GPU. What you do is that you have it run a small set of instructions (a kernel) in paralell many times over on a set of data.

For instance, you copy a buch of vertex data to the device memory, then ask the GPU to do math on the vertices. Then for each set of vertices you output a bunch of pixels which you also run a kernel on each pixel. These are called vertex and pixel shaders and are used to generate an image to be displayed on your monitor.

Recently, people started to use this pipeline for other purposes then generating an image. Namely number crunshing.

#6 Radikalizm   Crossbones+   -  Reputation: 2766

Like
4Likes
Like

Posted 23 November 2012 - 09:07 AM

Yes, modern GPUs are able to do branching, but I believe CPUs are generally more efficient at doing branches, or at least it used to be like that.

You have to keep in mind that a GPU is designed to do a large amount of similar jobs at once in parallel, that's why it's so efficient at doing heavy calculations. It'd be extremely hard or maybe even impossible to build an operating system kernel which could run on this kind of architecture. Working with memory would also be a major issue.

About ray tracers, there are a lot of ray tracing implementations which run on the GPU or which at least use the GPU to accelerate the process. The problem with CPU - GPU interop is that you'll encountering latency issues when uploading data to the GPU or when reading back data. It's only worth it to upload a job to the GPU if the speed improvement you'll get from it takes into account the memory latency from the data upload and potential readback as well.

#7 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
2Likes
Like

Posted 23 November 2012 - 09:22 AM

GPUs have been Turing complete for a while, so they can theoretically perform any calculation a CPU can perform.
In practice, the GPUs don't have any way to communicate with peripherals, just with the CPU, so that should make it obvious why one can't run a computer with a GPU alone.
It would also be extremely impractical to run some types of programs on a GPU - for example, a general purpose operating system - because the GPUs lack key features such as interrupts that are critical to implementing those programs in practice.

#8 Hodgman   Moderators   -  Reputation: 26995

Like
10Likes
Like

Posted 23 November 2012 - 09:28 AM

You can think of a GPU of basically being a very-very-very-wide SIMD CPU.
Normally when you compute x = y + z, those 3 variables represent single values.
e.g. 2 + 2, results in 4.
With SIMD, those 3 variables represent arrays.
e.g. [2,7,1] + [2,1,1] results in [4,8,2].

Each instruction is simultaneously executed over a large number of values, so that you get more work done faster.

You want to avoid branching with this kind of architecture, because you end up wasting a lot of your SIMD abilities.

e.g. take the code
if( y > 5 )
  x = y;
else
  x = z;
If we execute that with our data of y=[2,7,1] and z=[2,1,1], this results in:
if( y > 5 ) [false, true, false]
  x = y; [N/A, 7, N/A]
else [true, false, true]
  x = z; [2, N/A, 1]
//finally x = [2, 7, 1]
The GPU has had to execute both the 'if' and the 'else', but ignoring some parts of it's arrays for each branch, and merging the results at the end. This is wasteful -- e.g. say the GPU has the capability to work on 3 bits of data at once, in this example it's only working on 1 or 2 bits of data at once.
The more nested branches you add, the more wasteful this becomes... so those kinds of programs are better of running on regular CPU's (or being redesigned to better suit this style of hardware).

In practice, the GPUs don't have any way to communicate with peripherals, just with the CPU
... the GPUs lack key features such as interrupts that are critical to implementing those programs in practice.

Out of interest's sake, GPUs can generate CPU interrupts and write to arbitrary addresses (which might be mapped to peripherals), but these abilities aren't exposed on PC's (outside of the driver).

Edited by Hodgman, 23 November 2012 - 09:32 AM.


#9 ynm   Members   -  Reputation: 168

Like
0Likes
Like

Posted 23 November 2012 - 10:20 PM

Many thanks guys.

Oh, and thank you Hodgman, for detailed explanation

Regards

#10 superman3275   Crossbones+   -  Reputation: 1976

Like
2Likes
Like

Posted 23 November 2012 - 11:03 PM

I think about it like this:

CPU does the math, GPU does the rendering.

Ta-Da :) (I'm not a smart programmer Posted Image ).

I'm a game programmer and computer science ninja ph34r.png!

Here's Breakout:
Breakout!

Want to ask about Python and / or Pygame? What about HTML5 / CSS3 / JavaScript? What about C++ and / or SFML 2 (and 1.6)? Recruiting for a game development team and need a passionate programmer? Just want to talk about programming? Email me here:

Superman3275@Gmail.com

or Personal-Message me on here smile.png!


#11 Bacterius   Crossbones+   -  Reputation: 7970

Like
2Likes
Like

Posted 24 November 2012 - 12:09 AM

I think about it like this:

CPU does the math, GPU does the rendering.

Ta-Da Posted Image (I'm not a smart programmer Posted Image ).

GPU does the math too. I would say it's more like, CPU does the logic that brings everything together, and GPU is the powerhouse that drives rendering, and possibly physics (and perhaps other stuff too).

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#12 Toothpix   Crossbones+   -  Reputation: 810

Like
2Likes
Like

Posted 24 November 2012 - 12:59 AM


I think about it like this:

CPU does the math, GPU does the rendering.

Ta-Da Posted Image (I'm not a smart programmer Posted Image ).

GPU does the math too. I would say it's more like, CPU does the logic that brings everything together, and GPU is the powerhouse that drives rendering, and possibly physics (and perhaps other stuff too).

Also audio processing can be done on the GPU

C dominates the world of linear procedural computing, which won't advance. The future lies in MASSIVE parallelism.


#13 ynm   Members   -  Reputation: 168

Like
0Likes
Like

Posted 24 November 2012 - 07:01 AM

Hi,

I want to write some simple programs like hello world for GPU, how can I do this? I have here an old ATI card 4330 on my laptop, can I write program using it?

Regards

#14 Hodgman   Moderators   -  Reputation: 26995

Like
6Likes
Like

Posted 24 November 2012 - 07:20 AM

If you want to learn how to write graphical programs for a GPU, you'll use HLSL (via Direct3D), GLSL (via OpenGL), or Cg (via either).
However, you don't write full programs in these languages -- you only write small functions (such as to colour in a pixel, or move a vertex) which are called by Direct3D or OpenGL, so you also have to learn how to write D3D/GL programs on the CPU as usual.

The small GPU programs/functions are called "shaders", and GLSL/HLSL are "shader languages".
Your GPU supports Direct3D 10.1 and OpenGL 3.3, which both in turn support fairly modern versions of the above shader languages.

If you want to learn how to use the GPU for non-graphical uses, then you're in the same boat, except the CPU-side APIs that you first need to learn are (one of) DirectCompute, OpenCL or CUDA.

Edited by Hodgman, 24 November 2012 - 07:27 AM.


#15 Matt-D   Crossbones+   -  Reputation: 1410

Like
4Likes
Like

Posted 24 November 2012 - 07:56 AM

In addition to the libs mentioned by Hodgman, for GPGPU in C++ context you may also be interested in taking a look at the following:
- Thrust: http://thrust.github.com/
- C++ AMP: http://en.wikipedia.org/wiki/C%2B%2B_AMP http://www.gregcons.com/KateBlog/DidYouNoticeCAMPYouReallyNeedTo.aspx
// MS implementation (DX11-based) is Windows-only, but the specification is open and there's already an OpenCL-based PoC in the works: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/11/16/introducing-shevlin-park-a-proof-of-concept-c-amp-implementation-on-opencl.aspx

Edited by Matt-D, 24 November 2012 - 08:03 AM.


#16 6677   Members   -  Reputation: 1058

Like
2Likes
Like

Posted 24 November 2012 - 01:15 PM

May I ask why you wish to program onto the GPU directly? Chances are if you have an actual reason (and know this reason etc) then you already have knowledge of the GPU surpassing most of us here which (no offense intended here) it is obvious you do do not.


The actual lettering GPU stands for Graphics Processing Unit. This shows what its intended for pretty well.
Usually it has many many many cores (hundreds on several gaming cards, my own has over 300), these cores are capable of floating point maths natively (many CPU's are not and instead have additional circuitry for that). 1 processor core can only run a single task at a time, any code you ever write will also only ever use 1 core at a time (even GPU programming I believe) unless you specifically program it to make use of all the cores.
Something like a program that just takes 2 numbers, adds them together and spits the result back out will have no benefit to being parallelised. Something like graphics where you need to be doing a million things at once will see a huge benefit.
A single GPU core isn't actually very powerful with the exception of its floating point abilities, infact it wouldn't surprise me if the primary core of some of the higher end smart phones is more powerful (although I admit, I did not go online and check that). In theory as a GPU is what is referred to as turing complete it can do anything a CPU can, in practice a GPU has no way of interfacing with things like your keyboard etc, it can only spit out video data and only when its told to. In theory linux or something could be compiled to run on a GTX560, in practise though it would be running on just one of its several hundred cores with a ridiculous amount of limitations.

Some other tasks now done on the GPU are physics/biology/chemistry simulations and certain mathematical problems on large amounts of data although per core may be slower to do on the GPU than the CPU can of course be done on 100 or more pieces of data at once unlike your CPU where you can hope to do it on 4 at most maybe.


OpenCL can be hardware accelerated on both AMD and NVidia GPU's (aswell as some other more obsure hardware) or it can be run in pure CPU mode. NVidia have their CUDA library which works on NVidia GPU's and PPU's only (PPU's are rare and I don't think NVidia actually make them any more), for some things CUDA is faster, some OpenCL is faster, NVidia's PhysX physics library can use CUDA when present. The Bullet physics library can optionally use OpenCL or CUDA when possible too. OpenCV can use OpenCL aswell.

Generally any purpose you will need hardware acceleration from yourself will have a library available. GPU programming is a highly specialised field. For the majority of this post I am ignoring programmable shader pipelines because although they are still technically programming on a GPU it isn't what you appear to be after.

#17 ynm   Members   -  Reputation: 168

Like
0Likes
Like

Posted 24 November 2012 - 10:56 PM

@ all: many thanks,

I am learning about ray tracing because I love it, so I am trying to write on GPU (cast many rays at once) to test its limit. It is not my main job just hobby but I want to understand the concept. I am leaning to directcompute now but it seems tutorial on this field is very limited.

Regards

#18 Cagnazzo   Members   -  Reputation: 140

Like
1Likes
Like

Posted 24 November 2012 - 11:32 PM


I think about it like this:

CPU does the math, GPU does the rendering.

Ta-Da Posted Image (I'm not a smart programmer Posted Image ).

GPU does the math too. I would say it's more like, CPU does the logic that brings everything together, and GPU is the powerhouse that drives rendering, and possibly physics (and perhaps other stuff too).


Perhaps the best way to say it is that a CPU is a generalized processor, and a GPU is a processor designed to efficiently operate on graphical entities. It's more or less a very specialized CPU - what it is designed to do, it does much faster than a general CPU, and what it wasn't designed to do, it does much, much, much slower.

#19 powly k   Members   -  Reputation: 628

Like
1Likes
Like

Posted 26 November 2012 - 12:13 PM

... and a GPU is a processor designed to efficiently operate on graphical entities.


The rasterizer is pretty much the only thing that's really graphics-centered in GPUs anymore, they're good at all problems that can be solved in a massively parallel manner and with similar loop counts etc (little branching)

#20 Matt-D   Crossbones+   -  Reputation: 1410

Like
0Likes
Like

Posted 08 December 2012 - 03:38 PM

This is a readable total-newbie-style overview: https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU

BTW, there's a new class that launched in Coursera which deals with GPGPU:
https://class.coursera.org/hetero-2012-001/




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS