Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > dual core and c

Reply
Thread Tools

dual core and c

 
 
Robbie Hatley
Guest
Posts: n/a
 
      03-01-2008

"kerravon" wrote:

> Assuming I am running a C program that is doing some cpu-
> intensive work such as zip -9, I can understand:
>
> If I have 8 CPUs, then it will make no difference at all
> to the zip program, it will only run on one of the CPUs,
> although this does allow me to run 8 separate zips
> simultaneously, which would be cool on a large site.


That's only true if your compiler has no multi-threading
capability, or if it does but you don't use it. To get
multi-threading going, you have to have a compiler that
supports it, and you have to actually use its multi-threaded
capabilities by starting tasks in their own threads.
A single-threaded program is unlikely to run much faster
just because you run it on a multi-core CPU.

> But what I don't understand is the concept of a "core",
> as in "dual core".


As I understand it, a "core" is almost an entire CPU, with
it's own ALU, registers, etc; as for exactly what is shared
and what is separate, you'd have to RTFM* for your CPU.

> What implications does that have for a C program like
> zip? Does it have the ability to look at the instructions
> ahead of time and pipeline them or something? Pipelining
> is something that has been around for a long time.
> Did someone just get the bright idea to call it dual core
> instead or what?


No, generally a multi-threading compiler will run one thread
per core. Each thread is defined by an entry function, which
usually consists of a for loop which loops until either the
thread is no-longer needed or the application exits. Any
functions called by the thread function will also be a part
of that thread and run on that thread's core.

> Assume the zip in question is written in C89, no fancy
> parallelism - at least not inherent in the language itself.


The C language itself neither supports nor thwarts parallel
processing. That's a function of your compiler. RTFM* for
your compiler.

My compiler at work (National Instruments LabWindows/CVI) *does*
support parallel processing. It comes with a multi-threading
library, which I make heavy use of, because the program I'm
working on needs to be doing multiple things in real-time, and
it is not acceptable for one task to have to stop and wait for
another to complete. So I put the different tasks in different
threads.

A multi-threaded compiler such as LabWindows/CVI will first look
for multiple cores to run threads in, and if it finds them, it
will attempt to distribute one thread per core.

If it runs out of cores (or if there is only one), it then shares
multiple threads per core by time-sharing (jumping execution
rapidly back and forth between two threads on the same core).

For example, here's how one program I'm working on launches
a couple of new threads:

// Start communications thread:
CmtScheduleThreadPoolFunction
(
DEFAULT_THREAD_POOL_HANDLE, // thread pool handle
CommThread, // thread function
(void*)0,
&thrdCommunications // thread id
);

// Start background thread:
CmtScheduleThreadPoolFunction
(
DEFAULT_THREAD_POOL_HANDLE, // thread pool handle
BackgroundThread, // thread function
(void*)0,
&thrdBackground // thread id
);

If separate CPU cores are available, those will run in
separate cores; otherwise, they'll be time-shared on
the same core.

Multi-threaded programming does take some getting used to, though.
You need to watch out for booboos such as thread A getting to a
certain point then waiting for thread B to complete, with
thread B also having a point where it stops and waits for
thread A to complete. Ooops! Deadlock.

Also, you need to be aware that multiple thread can access
the same global variables. Say thread A stores "57" in
global variable "int argle" and leaves it there for a while
without changing it. Later, thread A comes back and reads
argle and finds that its value is now "87375629". What
happened??? I'll tell you what happened! Thread B wrote
to it, overwriting what thread A had written to it. Gotta
watch out for that. Only use global variables for things
which absolutely MUST be global, especially when doing
multi-threaded programming.


Footnotes:
*RTFM: "Read the Fine Manual". (Or substitute another word for
"fine" if that suits your fancy better.)

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant


 
Reply With Quote
 
 
 
 
Herbert Rosenau
Guest
Posts: n/a
 
      03-02-2008
On Fri, 29 Feb 2008 18:33:18 UTC, Paul Hsieh <(E-Mail Removed)>
wrote:

> On Feb 29, 7:13*am, kerravon <(E-Mail Removed)> wrote:
> > Assuming I am running a C program that is doing some cpu-intensive
> > work such as zip -9, I can understand:
> >
> > If I have 8 CPUs, then it will make no difference at all to the zip
> > program, it will only run on one of the CPUs,

>
> C, according to the standard, is not a language that is up to the task
> of doing anything about parallel or multithreaded programming.


This is not true. The standard does neither allow or forbid an
compiler to generate code that uses multiple CPUs, multiple pipelines
in parallel. So it lefts the job to paralise code for multiple CPUs
only to the compiler.

There
> has been some interesting research into compilers that perform
> automatic conversion of some loops to multithreaded object code, but
> these are silly research things that only apply to the most obvious
> cases, which LZ compression is *not* an example of.


The standard lets any freedom to an implementation if it supports
multithreading and/or any other kind of parallelism of handling
multiple CPUs. Only the implementation knows if there are multiple
CPUs avaiilable, if the multiple CPUs can work parallel in a single
thread, if it can assign only one or more CPUs to one or more
processes or threads in parallel. There is nothing in the standard
that allows or forbids that.

> With pretty much any compiler environment you will get exactly one
> core/CPU/thread usage here no matter what.


Not true. Read the standard carefully and you'll see that it does
explicity allows to parallise instructions. The only requirement on
statements is that they have to be complete done on each sequence
point. It allows even to split off multiple sequences of statements in
parallel.

> > [...] although this does allow me to
> > run 8 separate zips simultaneously, which would be cool on a large
> > site.

>
> If you want to run several instances of zip on something like a
> webserver (one per connection), then yes that's fine.


No, even a single instance of zip or something like a webserver (even
a single connection) can use multiple CPUs in parallel. Its left only
to the implementation to use these abilities when they exist.

> > But what I don't understand is the concept of a "core", as in "dual
> > core".

>
> It is essentially the same as dual processor. The difference is more
> pronounced on AMD CPUs because they use a shared core-centric memory
> controller (this means that memory shared between two different cores
> is much faster than between two different processors.) But this is
> *way* off topic with respect to the C language specification.
>
> > What implications does that have for a C program like zip?

>
> None.


No, many. It is up to the implementation to coordinate the CPUs in a
manner that at a sequence point a given statement is complete done or
at least to guarantee that it behaves exactly as if it were even as it
is not.

> > [...]*Does it have the ability to look at the instructions ahead of
> > time and pipeline them or something? *

>
> That's not what dual core means. The "out of order execution" of
> these CPUs is what it allows it to do that (and all the modern stuff
> does that on a per CPU basis.)


Not true.

> Specifically, dual core refers to the specific activity of glueing two
> CPU cores into a single microprocessor. Its a chip design thing.
> From software's point of view, it should be viewed as if there are
> multiple processors in the system.


Yes, exactly.

> > Assume the zip in question is written in C89, no fancy parallelism -
> > at least not inherent in the language itself.

>
> With such a program, just running one instance of it straight, on
> pretty much any contemporary compiler, it means your 8-core machine
> will run at one eighth capacity.


No, it depends only on the implementation. When the implementation can
split a a single instruction sequence off to multiple cores in
oarallel it can do that solong the visible result is not different
from a strict sequential one.

> To get more performance, you will need 1) To paralellize the algorithm
> (its not obvious that can even be done for zip, which is LZ based
> compression/decompression) and 2) Use a programming language/compiler
> that supports parallelism. Java supports parallelism out of the box,
> but many C compilers also support extensions for parallelism support.
>



--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      03-02-2008
Herbert Rosenau wrote:

> On Fri, 29 Feb 2008 18:33:18 UTC, Paul Hsieh <(E-Mail Removed)>
> wrote:
>
>> On Feb 29, 7:13*am, kerravon <(E-Mail Removed)> wrote:
>> > Assuming I am running a C program that is doing some cpu-intensive
>> > work such as zip -9, I can understand:
>> >
>> > If I have 8 CPUs, then it will make no difference at all to the zip
>> > program, it will only run on one of the CPUs,

>>
>> C, according to the standard, is not a language that is up to the
>> task of doing anything about parallel or multithreaded programming.

>
> This is not true. The standard does neither allow or forbid an
> compiler to generate code that uses multiple CPUs, multiple pipelines
> in parallel. So it lefts the job to paralise code for multiple CPUs
> only to the compiler.


I think that Paul means that C does not have any built in constructs for
parallel programming. Neither does it have any standardised library
facilities for this. That's why he said "C, according to the
standard, ...".

<snip>

>> With pretty much any compiler environment you will get exactly one
>> core/CPU/thread usage here no matter what.

>
> Not true. Read the standard carefully and you'll see that it does
> explicity allows to parallise instructions. The only requirement on
> statements is that they have to be complete done on each sequence
> point. It allows even to split off multiple sequences of statements in
> parallel.


He is talking about parallelism above the instruction level.

[ ... ]
>> If you want to run several instances of zip on something like a
>> webserver (one per connection), then yes that's fine.

>
> No, even a single instance of zip or something like a webserver (even
> a single connection) can use multiple CPUs in parallel. Its left only
> to the implementation to use these abilities when they exist.


Yes, but this is rarely done without explicitly using implementation
specific constructs for threading.

<snip>

 
Reply With Quote
 
Chris Thomasson
Guest
Posts: n/a
 
      03-03-2008

"kerravon" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Assuming I am running a C program that is doing some cpu-intensive
> work
> such as zip -9, I can understand:
>
> If I have 8 CPUs, then it will make no difference at all to the zip
> program,
> it will only run on one of the CPUs, although this does allow me to
> run 8
> separate zips simultaneously, which would be cool on a large site.
>
> But what I don't understand is the concept of a "core", as in "dual
> core".
> What implications does that have for a C program like zip? Does it
> have the ability to look at the instructions ahead of time and
> pipeline
> them or something? Pipelining is something that has been around for
> a long time. Did someone just get the bright idea to call it dual
> core
> instead or what?
>
> Assume the zip in question is written in C89, no fancy parallelism -
> at
> least not inherent in the language itself.


Your not going to experience any speedup wrt concurrency and scalability
unless the thread synchronization scheme that you are using is well
engineered. For instance, you have to pad data-structures up to a L2
cacheline size and then align then on l2cache boundary's. You should
minimize the use of membars and interlocked RMW instructions (e.g., try and
avoid the LOCK prefix on x86m, and the membar instruction on SPARC). Try and
use cache friendly algorithms in creative ways (e.g., distributed
ref-counting, RCU, ect...)...

As for single-threaded applications, well they should perform just as good
as they did before. Maybe even a little bit worse. Think of a chip with many
very many cores which run under a low clock speed such that a single-thread
program could end up running on a core that is most likely slower than a
single-chip/core system...

 
Reply With Quote
 
Paul Hsieh
Guest
Posts: n/a
 
      03-04-2008
On Feb 29, 10:49*am, (E-Mail Removed)-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <(E-Mail Removed)>,Paul Hsieh*<(E-Mail Removed)> wrote:
>
> >To get more performance, you will need 1) To paralellize the algorithm
> >(its not obvious that can even be done for zip, which is LZ based
> >compression/decompression)

>
> [OT]
>
> It turns out that parallelizing LZ compression or decompression is
> not difficult. The LZ algorithms reset the code dictionary from
> time to time, in order to adapt to changes in the data. This is
> done by emitting a "flush" token and flushing out all pending
> encodings, starting the encoded data again on a byte boundary.


Oh. I had no idea. I only know it from the base theoretical ideas
behind it and just assumed that the whole thing was always self-
dependent on the entire state before any emit point. Learn a new
thing every day. Cheers.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
When to pick quad core and when to pick dual core thingy NZ Computing 6 11-21-2006 07:08 AM
From single core to dual core =?Utf-8?B?Q2FybG9z?= Windows 64bit 26 08-06-2006 09:08 PM
Core Solo & Core Duo are not Core microarchitecture; 65nm Pentium M chips bigal Hardware 0 03-22-2006 11:24 AM
Dual Core Vs Single Core Processor Real World Performance Difference Edge Computer Information 3 03-15-2006 01:30 AM
posible: dual core + single core =?Utf-8?B?TmllbHMgQ2hyLg==?= Windows 64bit 7 11-22-2005 06:11 PM



Advertisments