| 1 |
Peter Humphrey wrote: |
| 2 |
> On Monday, 9 December 2019 06:31:08 GMT Dale wrote: |
| 3 |
>> Howdy, |
| 4 |
>> |
| 5 |
>> As some may recall, I upgraded my rig to a 8 core CPU, expanded memory, |
| 6 |
>> added a hard drive etc etc a while back. All of which made things a bit |
| 7 |
>> faster. Each core isn't that much faster but the extra cores certainly |
| 8 |
>> help in most cases. It is a noticeable improvement. There's one thing |
| 9 |
>> tho that it just doesn't help much on. That thing is the emerge command |
| 10 |
>> itself. When I run emerge, based on gkrellm etc, it always uses one |
| 11 |
>> core and that's it. As one knows, emerge can take a while trying to |
| 12 |
>> figure out the best way to upgrade, especially when something is causing |
| 13 |
>> a road block and requires a detour. Will portage ever be able to use |
| 14 |
>> more than one core? I'd suspect that if it could use all available |
| 15 |
>> cores, it would speed things up quite a bit. It may not be 8 times |
| 16 |
>> faster in my case but even 4 times faster would be nice, more even |
| 17 |
>> better. Others that have more cores/threads/whatever could see a even |
| 18 |
>> larger speed increase. |
| 19 |
>> |
| 20 |
>> I'm sure trying to get portage to do things in parallel would be a |
| 21 |
>> programmers nightmare. It may not even be doable given how the tree is |
| 22 |
>> done or that the complexity of calculating all the options is just to |
| 23 |
>> much to run in parallel. Still, does anyone think it will be possible |
| 24 |
>> at some point? Anyone else think it would be as awesome as I do? |
| 25 |
>> Anyone know if it is something that is being worked on? I think I read |
| 26 |
>> on -dev once long ago about this but can't recall details and I'm not |
| 27 |
>> aware of any movement in that direction. I haven't seen any mention of |
| 28 |
>> it in a long while now. |
| 29 |
> Portage does indeed run as many emerge jobs as you have cores, if you let it, |
| 30 |
> but not the calculation of dependencies. That, as you say, cannot be divided |
| 31 |
> into pieces to give to separate cores, and I'm sure it never will be. Pity, |
| 32 |
> because on a slow machine like my 32-bit Atom box, it takes ages. |
| 33 |
> |
| 34 |
|
| 35 |
|
| 36 |
The other bad thing is, it seems the clocks on CPUs have pretty much hit |
| 37 |
a wall. It seems that since they can't make them faster, they just add |
| 38 |
cores/threads to make them faster by running in parallel. Of course |
| 39 |
that means emerge will get slower as things get more complicated. Other |
| 40 |
than a faster core, nothing else is going to make emerge faster it seems. |
| 41 |
|
| 42 |
I agree tho, I'd hate to be the programmer trying to make emerge |
| 43 |
calculate updates in parallel. I've got a full head of hair right now |
| 44 |
but I wouldn't if it were me trying tho. lol Heck, emerge already does |
| 45 |
some pretty amazing stuff, despite its cryptic error output at times. :/ |
| 46 |
|
| 47 |
It sure would be nice tho. |
| 48 |
|
| 49 |
Dale |
| 50 |
|
| 51 |
:-) :-) |
Archives