The weak line between PROCESS & THREAD

[dreampeppers99]

Well,

I've been searching for understanding about distributed computation. So I saw some interesting therms: Process and Thread.

Both are almost the same thing, except by, process is composite by one or more threads, create process is more expensive (for hardware) than a thread.
Reading this things I had the impression that only the Process could use a "new" multicore feature(CPU).

Question:

If I dev a program that creates multiThread for many task, my program will take the advantage of multi-core? Or it will used just when I creat one process for each task (sub-rotine, method, function, whatever)

Just developer an application with many thread/process my application will use the feature multicore?


ps: I know is not "just" dev system with so many task,,, you need to manage it and this is hard...

[MiretanK]

This belongs to Web dev/programming. =)

[dreampeppers99]

Thanks MiretanK and sorry for my mistake

[Phil]

well first things first. multi threading does not equate to multi core. to code a program with multi core, you have to write instructions for each of the execution cores (which is a pain to do)

[cottonvibes]

nah, actually phil, multi-threading does allow the different cores of the CPU to be used.

an application usually runs in 1 process who's priority is handled by the OS, and the application can set up functions that run in their own threads.

the difference between threads and processes is that a process is independant from other processes, and a thread is used if there will be communication between other threads.

a thread can use the same variables another thread is using if its part of the same process.

heres more information since i'm too tired to explain anymore
Threads vs. Processes

i'll be honest, i'm not an expert on multi-threading, i've only written a few programs that use threads.

but the art of multi-threading and taking advantage of multiple CPU cores isn't like,

use core 0 for function 1;
use core 1 for function 2;

its more like this

make a thread for function 1;
make a thread for function 2;

meaning that you don't get to choose what CPU core is being used, the operating system handles all that for you. You just tell your functions to run in their own thread and the OS chooses the core it wants (usually the core thats doing less work.)

[mudlord]

meaning that you don't get to choose what CPU core is being used, the operating system handles all that for you. You just tell your functions to run in their own thread and the OS chooses the core it wants (usually the idle core.)

Partially true.

You can pragmatically specify which cores threads run on.

Research SetThreadAffinityMask().

[Phil]

exactley: like i said....if you want true optimization, you must assign specific code to each core

like

Core 0: specific action
Core 1: specific action
Core 2: specific action
Core 3: specific action

anyway wheres mud? he knows this stuff better then both of us

Edit: Beat me to it lol

[cottonvibes]

Originally Posted by mudlord

Partially true.

You can pragmatically specify which cores threads run on.

Research SetThreadAffinityMask().

interesting.

like i said, i've only used threads a few times in code, didn't know you can choose the core it runs on.


i guess thats what PCSX2 does when you select the "Dual Core Mode" option.

Originally Posted by Phil

exactley: like i said....if you want true optimization, you must assign specific code to each core

well not necessarily phil.


think about if a user is running your multi-threaded application, and hes also watching a video in windows media player.

say WMP takes up ~99% of core 0's processing time, and core 1 is idle using ~1% of its processing power.


say you told your application to use core 0 to do one thing, and core 1 to do another thing.


since core 0 is being used at 99%, the application will take forever.

but had you let windows choose what core to use, then it would have set both threads to use core 1, and then the application would most-likely run faster.

[Phil]

you mean "offloading"

hmmm i hear Nehalem will be stronger in that regard..

[dreampeppers99]

First thanks so much dude,

Originally Posted by cottonvibes

1 process who's priority is handled by the OS...

I always think that way.

Originally Posted by mudlord

You can pragmatically specify which cores threads run on.
Research SetThreadAffinityMask().

Good point I'd never know about it, however observe the word can not must.

Originally Posted by Phil

exactley: like i said....if you want true optimization, you must assign specific code to each core
...

Not must but can.

Originally Posted by cottonvibes

but had you let windows choose what core to use,...

I prefer let the OS choose this too.

[KillerShots]

In general, you will get much better performance if you let the OS decide which core or CPU to run on. It also makes coding a bit easier as you simply don't have to worry about it.

For most developers, threading was simply a methodology of being able to do stuff while I/O was going on... it was always flawed, but it was all they could see because they never owned or had access to multi-CPU machines. On a single-CPU/core machine, that's really all that threading does for you.

On the other hand... things just don't work that way any more. Hardly anyone has a single-core machine. Consequently, you can now use threading to do simultaneous non-I/O related tasks that are truly simultaneous (as long as the data they're working on fits in the cache of the core they're working on, or cache updates never happen simultaneously).

At any rate, back to the original point, in general the OS does a good job of distributing active threads across idle CPUs. Some OS's do a much better job of this (Sun, for example... been doing large CPU arrays for decades)... and this is one of the few things that at an OS level, MS does better than linux (linux does not support threads, only LWPs (Light-Weight Processes) masquerading as threads).

[runawayprisoner]

Originally Posted by cottonvibes

interesting.

like i said, i've only used threads a few times in code, didn't know you can choose the core it runs on.

You can choose which core(s) a process runs on as well (so why not threads?). Actually, the end user might even be able to do that if you let Windows handle it.

i guess thats what PCSX2 does when you select the "Dual Core Mode" option.

Indeed. It would be nice to have a setting to let users set which cores they want PCSX2 to run on, though. That will come in handy when you have more than 3 cores or 3 processors, and you absolutely must run something else beside PCSX2.

think about if a user is running your multi-threaded application, and hes also watching a video in windows media player.

say WMP takes up ~99% of core 0's processing time, and core 1 is idle using ~1% of its processing power.

say you told your application to use core 0 to do one thing, and core 1 to do another thing.

since core 0 is being used at 99%, the application will take forever.

That's the case with PCSX2, though. In which case... instead of running the said application in the background first, specify your user to run the background applications second, so Windows will switch to other cores instead. If your program doesn't back down, others will. If others don't back down, the only way to do it is set others' affinity to core 2 or beyond. This is my trick for running WMP, Firefox, and Photoshop all at once alongside PCSX2.

but had you let windows choose what core to use, then it would have set both threads to use core 1, and then the application would most-likely run faster.

I see to it this way: you let your proggy load core 0 and core 1 to their fullest, then run the other application and let Windows choose core 2 for that application. Alternatively, you can inquire Windows about which cores are being loaded (kinda like adding a process monitor) and then dynamically switch to free cores on-the-fly (if there are free cores, of course). It's just a simple check at the beginning of the application for a much hassle-free experience. In case you can't switch to free cores (when you are on a dual-core system), you can always live with the others like usual. No harm done.

[mudlord]

You can choose which core(s) a process runs on as well (so why not threads?). Actually, the end user might even be able to do that if you let Windows handle it.

As I said earlier, there is a WinAPI function that allows setting the processor/core affinity for threads.

[cottonvibes]

Originally Posted by runawayprisoner

You can choose which core(s) a process runs on as well (so why not threads?).

well i wasn't sure because lots of times windows limits the control of the programmer to prevent problems.

for instance, in PCSX2, the VM hack of it uses some way to bypass Window's OS layer and directly accesses the memory; which windows dosn't usually allow.

i was thinking if the coder personally assigns the core the thread should be run on, then it might conflict with something windows is doing or something...


plus, i've only done threads in java. And i'm not sure if theres a way to manually assign a thread to a core in Java.

[BigIg]

Not to go too off topic, but if you design an application that is expressly designed to use multicore, and contains no code for what to do if the end user has a single core, how would this be handled? Would it just use threads?

I'm not a programmer, but this kind of interests me.

[cottonvibes]

Originally Posted by BigIg

Not to go too off topic, but if you design an application that is expressly designed to use multicore, and contains no code for what to do if the end user has a single core, how would this be handled? Would it just use threads?

I'm not a programmer, but this kind of interests me.

if you specifically programmed it to run on 2 cores, then most-likely you would code the application to say something like "Error: Single-core detected" and then exit out if the user only has a single-core CPU.


but if you use threads, and don't tell windows to specifically have the threads run on 2 different cores, than the program will still work.

however, it's behavior could be pretty odd.


this is because Window's will decide how much CPU time to give each thread. And it might not give them both 50-50, it might give one of the threads 90% CPU power and the other ~10%.


heres a perfect example. I was looking at some code for a cell-phone game.

and the author had the character animation being done in 1 thread, and the game logic done in another thread.

when i ran the code on my cell-phone, which only has 1 CPU, the animation wasn't fluent at all, and it lagged.

then i re-coded the code to have both the animation and the game logic be done in just 1 thread, and the animation was nice and in-sync.


so its usually not a good idea to have code in threads, if you're on a single-cored CPU.
(well at least from my experience )

[BigIg]

Originally Posted by cottonvibes

if you specifically programmed it to run on 2 cores, then most-likely you would code the application to say something like "Error: Single-core detected" and then exit out if the user only has a single-core CPU.


but if you use threads, and don't tell windows to specifically have the threads run on 2 different cores, than the program will still work.

however, it's behavior could be pretty odd.


this is because Window's will decide how much CPU time to give each thread. And it might not give them both 50-50, it might give one of the threads 90% CPU power and the other ~10%.


heres a perfect example. I was looking at some code for a cell-phone game.

and the author had the character animation being done in 1 thread, and the game logic done in another thread.

when i ran the code on my cell-phone, which only has 1 CPU, the animation wasn't fluent at all, and it lagged.

then i re-coded the code to have both the animation and the game logic be done in just 1 thread, and the animation was nice and in-sync.


so its usually not a good idea to have code in threads, if you're on a single-cored CPU.
(well at least from my experience )

Interesting stuff. Makes me wanna pick up all the programming books I've bought. I don't have the patience though.

[cottonvibes]

Originally Posted by BigIg

Interesting stuff. Makes me wanna pick up all the programming books I've bought. I don't have the patience though.

well if you're just starting out, multi-threading programming isn't really going to be an issue.

you'll need alot of patience to get to the point of learning multi-threaded programming, since its usually taught after you've learned the programming basics.


anyways, programming is fun once you're familiar with it...
but i find learning it to be kindoff boring; especially since lots of programming books are written in such a boring way, and make you code stupid applications just to learn how to use a programming concept.