# Threaded programs don't use several cores?

## progo

This problem (if it's such a thing) arose when I noticed mplayer can't use both of my dual cores of Athlon64 X2 3800+, even if I try setting the number via -lavdopts threads=2. Someone mentioned that there could be a kernel configuration issue, or a option that would enable this behaviour.

Otherwise my system scales well, multiple programs can use my cpu up to 100. But a lonely app just can't. 

```
Linux pihlaja 2.6.23-gentoo-r6 #2 SMP Sat Feb 9 16:29:00 EET 2008 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux

```

Is there a threaded cpu stress program so I'd know for sure there's a problem? Portage's stressers all seem to be single-threaded. Thanks for replies!

----------

## anxt

this is expected behaviour.

there is no reason to run mplayer across two cores on a modern chip.  well threaded apps are tricky to write (from little i have tried).  weird bugs manifest and it just isn't worth it.

where you see a huge perfomance boost is thinks like running parallel make jobs, a job goes to a core is finished and returned.

for example portage run parallel makes.  i think transcode also does this well i haven't tried.  there is a lot of overhead to have one thread share variables and data to another,

and a lot of room for error.

----------

## progo

Uh-hu.   :Confused: 

Windows seems to cope well with those threaded apps (or is it just being inefficient?) Yes -- most apps that need performance split up with forks and such, but then there's some apps that don't. Umm, I've coped with it the last 8 months so I guess I can live with this.

Thank you for answering.

----------

## sundialsvc4

It's entirely up to the operating-system to determine what the cores and/or CPUs will be given to do.  You cannot control that.

Devise your application as efficient and well-designed threads and let the operating-system decide how to execute it on the hardware.

----------

## Mad Merlin

```
grep aaaaaaaaaaaaaaa /dev/urandom & grep aaaaaaaaaaaaaaaaaaaaa /dev/urandom & top
```

That should give you 2 processes using ~100% each.

----------

## Hu

 *progo wrote:*   

> Uh-hu.  
> 
> Windows seems to cope well with those threaded apps (or is it just being inefficient?) Yes -- most apps that need performance split up with forks and such, but then there's some apps that don't.

 

Windows has always been very slow to create Win32 processes, so Windows developers tend to prefer threads where Linux developers will fork and use a separate process.  Also, the Windows API has a great many functions that do not provide a good way to multiplex waiting for disparate events, so it is common to see Windows programs use a thread just to sleep waiting for an event.  I use event in the generic English sense, not in the sense of a Windows "event object".  The corresponding Linux program might have all its work handled by a single thread using select, epoll, or a similar function to sleep waiting for any of several interesting events.

----------

## progo

So it's a matter of design.. I understand. 

[quote=Mad Merlin]That should give you 2 processes using ~100% each.[/quote]Well that's going to be two processes.  :Smile: 

----------

## Mad Merlin

 *progo wrote:*   

> So it's a matter of design.. I understand. 
> 
> [quote=Mad Merlin]That should give you 2 processes using ~100% each.

 Well that's going to be two processes.  :Smile: [/quote]

Yes, of course, but that hardly matters. I thought the original issue was that you could only use 100% CPU time (ie, not 200% (ie, 100% of each core)). If you want to see ~200% CPU usage for a single process, try this:

```

cat <<_EOF_ >mthread.cpp

#include <pthread.h>

#include <stdio.h>

#define THREADS 16

void *busy(void *arg);

int main(void)

{

   pthread_t t[THREADS];

   for (int i = 0; i < THREADS; i++)

   {

      pthread_create(&t[i], NULL, busy, NULL);

   }

   for (int i = 0; i < THREADS; i++)

   {

      pthread_join(t[i], NULL);

   }

   printf("all done\n");

   return 0;

}

void *busy(void *arg)

{

   for (long long i = 0; i < 1000000000; i++);

   printf("done\n");

}

_EOF_

g++ -lpthread -o mthread mthread.cpp

./mthread

```

Make sure there's no leading whitespace before you paste that into a terminal (at the very least, _EOF_ cannot have leading whitespace). Also don't compile that with optimizations, GCC will optimize away the busy loop and it'll finish too quickly.

----------

## progo

 *Mad Merlin wrote:*   

> 
> 
> Yes, of course, but that hardly matters. I thought the original issue was that you could only use 100% CPU time (ie, not 200% (ie, 100% of each core)). If you want to see ~200% CPU usage for a single process, try this:

 

Hey wow, that works and utilitizes both cores! This is getting very weird now... So threads are working like they should and kernel distributes them somewhat interestingly.

----------

## phsdv

 *progo wrote:*   

> This problem (if it's such a thing) arose when I noticed mplayer can't use both of my dual cores of Athlon64 X2 3800+, even if I try setting the number via -lavdopts threads=2.

 From man mplayer:

```
 threads=<1-8> (MPEG-1/2 and H.264 only)

                      number of threads to use for decoding (default: 1)
```

What type of file did you play, or better how was this file encoded?

----------

## progo

It seems to be my bad... I was told the file is x264 so I presumed it belongs to h264. midentify tells it is avc1. It's wrapped in matroska along with dts. So I think I've just presumed it wrong.

----------

