in reply to use dual-core or quad-core

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.


All dogma is stupid.

Replies are listed 'Best First'.
Re^2: use dual-core or quad-core
by BrowserUk (Patriarch) on May 20, 2008 at 09:35 UTC

    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.
[reply]

      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.
[reply]
[d/l]

        Interesting. I will have to look up to see if there are any equivalents on the OPs on dual-core, windows xp system.

        There are the 6 levels of processes priority which are analogous to the three described in sched_setScheduler, but they are further influenced Dynamic Priority Boosts. And that is further influenced by whether the system is configured as a workstation or server. And if it's a workstation then it's influenced once more by whether the workstation has Foreground Priority Boost enabled.

        I also think I remember reading about the NT scheduler tending to have a 'natural affinity' to keeping a cpu-bound process (or maybe thread, but same thing in a single threaded application) running on the same cpu or core, but I can't lay my hands on a reference for that just now.

        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.
[reply]

In Section Seekers of Perl Wisdom