You could use Win32::API to call the SetProcessAffinityMask() api.

I'm not sure if there are any existing modules that allow access to this API.

That said, I'm not at all sure that doing so will achieve anything given your description of what you are seeing. Using 75% of one cpu rather than 25% of three or four is not going to make your process run much more quickly. 1% or 2% at the very best (reduced task switching and increased cache coherency (maybe)).

The best way to speed your application, assuming it is amenable to the possibility, would be to thread it so that it can utilise more than one cpu concurrently. You might be able to cut your run time by 50% or 65% or 75% by using 2, 3, or 4 cpus concurrently; (in theory), but it depends a lot on the nature of your application.

I'm not sure if there are any existing modules that allow access to this API.

I think Win32-Process does.

Cheers,
Rob

What you can do is start the desired number threads or processes to keep your cores busy, and you can probably the set the priority of your processes. But you shouldn't try to decided which core executes which program. That's your operating system's job.

We could better help you if you told us why your are trying to achieve things like that, perhaps there are better solutions.

well,

i'm trying to replicate the idea behind the the BLAST program(it is an alignment program - it realy doesn't matter what kind a algorithm it is). the program is written i c and it has an option to use one, tow ... or number of cores. the program calculates the similarity of the alignment. i'm also calculating something similarly to the things BLAST calculates, and in some segments my program is even faster than blast, but i cannot compare myself to BLAST algorithm when multiple core system is turned on. so i'm looking for a way to speed up my performance.

PS

i now that perl is not intended for hard core calculations and lot of people told me not to do this in perl, but everything is in the approach.

blast is optimized to hell. If you say you are faster in perl under some circumstances, you are doing something that is not comparable ;)

Honestly, it makes not much sense to use perl for huge scientific calculations and even less trying it on multiple CPUs. In C (even without OpenMP), you are magnitudes (much more than 2,4,8 times) faster.

Here are a lot of bioinformatic guys, what do you want to do?

I think the "number of cores" is just the number of parallel threads or processes used, which shouldn't be too hard to in perl.

Beware that threads can have nasty pitfalls in perl, so if you don't have a lot of data to share between the parallel calculations you could try to start separate processes instead.

The following is for Linux (and should work this way on most *NIXes).

To have your program use one core only all you need to do is run it without forking. The OS will automatically give you as much CPU time on a single core as it can without detrimentally affecting the rest of the system. This means that, unless you're on a system that is heavily loaded by multiple processes (or your program is I/O-bound) your program will always run at 99% or 100% CPU usage on a multi-core machine. If you find that the OS scheduler occasionally assigns other tasks to the core your program is using (if e.g. you're on a desktop system which has several programs you're using interactively) you can change the process priority (the "nice" value) via the inbuilt setpriority(e.g. setpriority 0,$$,1)

For running your process on multiple CPU cores, simply fork it into as many processes. Again, the OS will take care of running your processes efficiently. Executing setpriority prior to forking will pass the nice value on to the process children.

A single tasking, non-forking, single threaded process--a bog standard program--will be run on whichever processor is available when it is next due a timeslice on any SMP system, including Linux. It just won't be able to use more than one concurrently.

Priorities have nothing to do with it. (See *).

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

In principle you are correct. But in practice, renicing a process to the highest priority is the most efficient tactic for keeping it running on a single CPU as continuously as possible while not disrupting the rest of the system (see man sched_setscheduler on why). There's also taskset, which actually influences processor affinity (which is what you are talking about), but that doesn't have much practical use for this particular case. In fact, if you want your process to run on a CPU core as continuously as possible (and you're not fussy about which exact core it is, which I don't see why the OP would be), then you want the OS scheduler to switch the process to a different core for the very rare case when this is more efficient. Thus, setting processor affinity would do more harm than good.


All dogma is stupid.