Hi

Im wondering if two processes can run at the same time when running a dual-core processor. Im well aware that normally only one process can run at a time usually, but i dont know how this is working when youre running a dual-core processor.

Yes they can. Whether they do or not depends on the OS you are using. Linux can use both at the same time. There would be no point in having more than one id the OS couldn't use more than one. A kernel with SMP support indicates the OS is capable of using more than one processor.

Here is what uname shows on my dual core system.

That depends on how you define "run at a time". If you mean
"completely dedicated to the one task", then no, you'd need
three CPUs at least, otherwise at least one of the cores will
be running the kernel as well. If that's what you need, use
DOS ;} and two stand-alone machines.
If you mean run in parallel with time-slices a human won't
notice - by all means - Linux can run many processes "at the
same time" on a single CPU.


Cheers,
Tink

I don't see anything in the original question that requires all that qualification.

The answer is simple: Yes

"can" would not be interpreted as meaning "will 100% of the time".

Maybe one of the processes has multiple threads and sometimes two threads of one process will be running at the same time instead of one thread each of two processes. Of course, interrupts must still be serviced and there is other kernel CPU time that you might or might not consider to be part of the CPU time of one of those processes. None of that changes the "yes" to the question asked.

It sounds like you're saying "at the same time" can't mean any more for dual core than it means for single CPU. That would not be correct. Linux uses time-slices to run multiple processes "at the same time" where "at the same time" does not mean what the OP clearly meant. But with dual core it can and often does run two processes "at the same time" where "at the same time" does mean really at the same time as the OP meant.

I disagree. When someone asks a simple question, we can't know all the underlying assumptions or the context.

The normal single-CPU machine--by definition--only does one thing at a time. But it does keep track of multiple processes--allowing each one to take it's turn.
2 CPUs can indeed do two things at the same time--thus (theoretically) increasing the speed.

From another angle: A modern computer can run many processes concurrently---but not because it has more than one processor.

Do you always give a "simple answer", or one that
may be close to correct?


Again - it depends on how it's defined. Whether the OP was
specific on that or not. And in the strictest possible inter-
pretation it's a NO, because there's always kernel code in
the mix.


Cheers,
Tink

Generally not. (You can look at my many answers given on remote control questions at RemoteCentral). I'm usually the first to suggest that a question might not mean what it seems to mean, or even that the questioner is not asking the question he should be asking.

But this time, we all know exactly what the OP meant. We don't need to invent possible alternate meanings to justify a more confusing answer.

Nonsense. The strictest possible interpretation of "can run at the same time" still means "can run at the same time" so the answer is Yes.

There may be other ways of interpreting "can run at the same time" to inject "always" somewhere in there. But that would not be a strict interpretation of the original phrase.

I have a dual core CPU. I use a software build system that runs compiles in two processes "at the same time". During most of the time those compiles are "running" there are two processes really running really at the same time (really), not just seeming to run at the same time as would be the case with a single core CPU. When something does happen a lot, it is pretty distorted to respond to "can it happen" with some interpretation that makes the answer "no".

Not to all, apparently. There's at least two people who don't
think that it's quite clear what the OP meant.

You obviously haven't read my first response ... oh well.
Figures.



Cheers,
Tink

I certainly read it. I'm sure I understand what the OP meant. But that doesn't mean I'm sure I understand what you meant. I expect I don't understand what you mean. I really can't tell whether you are wrong about the underlying facts or just wrong about what the original question might have meant (sorry, but those are the only two possibilities I can still see).

I'm quite sure the OP did not mean that.

I'm equally sure the OP did not mean that.

If you mean those are the plausible ways to look at the question, then maybe you don't even agree with me about the answer to the question I think the OP asked. Obviously you don't agree regarding what question was asked. I expect you would at least understand what question I think he asked and you seem to be going to some effort to avoid answering that and to throw confusion on top of camorri's original answer to that.

When my dual core CPU is running two processes at once, those are not just "at the same time" within some chunk of time too small for me to notice (as would happen with a single core CPU). They are not just at the same time within a single microsecond. They are not just at the same time within a single nanosecond. They are not even just at the same time within a single CPU clock (less than a nanosecond). They are really at the same time, even as individual electrons move seperately in the two cores to charge some gates whose switchings are tiny parts of the execution of two unrelated machine instructions, one in each core.

I also don't even know whether you mean to be answering the question of the original post "if two processes can run at the same time when running a dual-core processor" or whether you are "answering" the background statement he put in for contrast "normally only one process can run at a time". That statement would be subject to all manner of reinterpretation and disagreement (such as you have done) if it weren't present just as contrast to the real question.

I'm quite sure that contrast statement is there just to make extra sure that the real question can't be misinterpreted in ways such as:

I'm not technically advanced enough to address the issue at the level entered into above, but here's an experiment you can replicate, and I think it addresses the OP's question.

In the Grip setup is a question of how many processors you want Grip to use. Select one (1), give it a CD, and it'll rip all the files to .wav, then convert each .wav file to .mp3, .ogg, or whatever. Tell Grip you want it to use two (2) processors, and it'll use one to rip the files to .wav, and the 2nd processor to concurrently convert the .wav files to .mp3s. Using two processors, the entire process takes only half as long.

I only have 2 processors, but I am curious to know how it would deal with 3 or 4.

Sorry, but I think it doesn't.

Long ago, I made a lot of use of a program that alternated small chunks of CPU usage with small chunks of disk I/O. The mix turned out to be about 50/50. There were no dual core CPUs. I didn't have any kind of multi-processor system. But I made it run two copies of that process in parallel and the total time was reduced to barely over half the original time.

In such a situation, the two processes tend to fall into an optimal syncronization in which one is using CPU time while the other is waiting for disk I/O and vice versa. So running two copies in parallel is much faster than running just one, even with just one CPU core.

Your example mixes CPU usage and disk I/O in a similar way. I expect the mix isn't near 50/50. I expect a modern OS's file caching will gain much of the overlap even for a single process that I needed two processes to achieve. So if you ran two processes in parallel with a single core CPU I wouldn't expect the total time to be near as low as half of the single process time. But I don't know the values of any of those unknowns. So if on some unknown system, you found that two processes in parallel do the job twice as fast as one process, I wouldn't jump to the conclusion that two cores are at work. That would be suggested, but not proven. It could just be an unusually good example of CPU vs. I/O overlap of two processes.

How about we give the OP a chance to clarify? It's mote
for us to argue about what either of us thinks he's asking.

You're wrong. While they may both be in the kernels scheduler
queue as high priority tasks one processes execution may be
stopped for the kernels scheduling activities for several jiffies
on one CPU while the other is stopped for a few jiffies for IO
tasks on the other ...


I'm fairly certain (probably about as certain as you) that
I got the right end of the stick, but I can't be bothered
to expend any more time on this logorrhea ...



Cheers,
Tink