| 1 |
At Sun, 29 Jan 2006 13:03:19 -0600 Dale <dalek@××××××××××.net> wrote: |
| 2 |
|
| 3 |
> Alexander Skwar wrote: |
| 4 |
> |
| 5 |
>>Something that I always wondered about - does it |
| 6 |
>>actually *lose* speed? IOW: Is it, *IN* *TOTAL* |
| 7 |
>>slower to do multiple emerges in parallel compared |
| 8 |
>>to doing them sequentially? |
| 9 |
>> |
| 10 |
> I'm no guru for sure but here is my $.02 worth. Let's say emerge one |
| 11 |
> takes ten minutes and emerge two takes 30 minutes. If you have a single |
| 12 |
> CPU machine I would think that if both were started at the same time, |
| 13 |
> the both of them would take 40 minutes. So in my theory, "emerge one && |
| 14 |
> emerge two" should be the same as doing seperately. |
| 15 |
|
| 16 |
It is more complicated than that. |
| 17 |
|
| 18 |
1. A single CPU machine most likely has a DMA I/O controller and |
| 19 |
hence more than one action can be concurrent. |
| 20 |
|
| 21 |
2. I/O itself causes long delays while the disk is active, with a |
| 22 |
second emerge (or any other processor) the CPU can be concurrent |
| 23 |
with this delay. |
| 24 |
|
| 25 |
These two argue for the concurrent emerges to be faster, but |
| 26 |
|
| 27 |
3. The context switching between processes is not free and adds CPU |
| 28 |
(at least) requirements to the concurrent emerge situation. |
| 29 |
|
| 30 |
4. The concurrent invocation increases the cache pressure (i.e., |
| 31 |
demand) which most likely increases the cache miss rate. |
| 32 |
|
| 33 |
5. Similarly for the buffer cache. |
| 34 |
|
| 35 |
etc |
| 36 |
|
| 37 |
allan |
| 38 |
-- |
| 39 |
gentoo-user@g.o mailing list |
Archives