1 |
On Sun, 16 Jun 2013 19:33:53 +0000 (UTC) |
2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
3 |
|
4 |
> TL;DR: SSDs help. =:^) |
5 |
|
6 |
TL;DR: SSDs help, but they don't solve the underlying problem. =:-( |
7 |
|
8 |
I have one; it's great to help make my boot short, but it isn't really |
9 |
a great improvement for the Portage tree. Better I/O isn't a solution |
10 |
to computational complexity; it doesn't deal with the CPU bottleneck. |
11 |
|
12 |
Sadly, an improvement to the CPU as good as the switch from HDD to SSD, |
13 |
I'm yet to see such a hardware improvement. Maybe if we stack the |
14 |
transistors into the third dimension, something Intel was working on. |
15 |
|
16 |
> Quite apart from the theory and question of making the existing code |
17 |
> faster vs. a new from-scratch implementation, there's the practical |
18 |
> question of what options one can actually use to deal with the |
19 |
> problem /now/. |
20 |
|
21 |
Don't rush it: Do you know the problem well? Does the solution |
22 |
properly deal with it? Is it still usable some months / years from now? |
23 |
|
24 |
> FWIW, one solution (particularly for folks who don't claim to have |
25 |
> reasonable coding skills and thus have limited options in that |
26 |
> regard) is to throw hardware at the problem. |
27 |
|
28 |
Improvements in algorithmic complexity (exponential) are much bigger |
29 |
than improvements you can achieve by buying new hardware (linear). |
30 |
|
31 |
> I recently upgraded my main system to SDD. ... SNIP ... Between that |
32 |
> and the 6-core bulldozer[3] I upgraded to last year, I'm quite happy |
33 |
> with portage's current performance, ... SNIP ... |
34 |
|
35 |
Ironically, you don't even fully use the CPU, but only one core of it; |
36 |
I'm glad you have a 6-core processor, but to Portage it is a 1-core |
37 |
during dependency tree calculation. |
38 |
|
39 |
Portage becomes slower at a faster rate than your hardware get faster; |
40 |
this will continue to be that way until you make Portage benefit of |
41 |
it, or failing that you would need to come up with an alternative PM. |
42 |
|
43 |
I didn't get my short boot from upgrading hardware alone; quite the |
44 |
opposite, it was rather the results of the efforts spent on it. |
45 |
|
46 |
> --- |
47 |
> [1] I'm running ntp and the initial ntp-client connection and time |
48 |
> sync takes ~12 seconds a lot of the time, just over the initial 10 |
49 |
> seconds down, 50 to go, trigger on openrc's 1-minute timeout. |
50 |
|
51 |
Why do you make your boot wait for NTP to sync its time? |
52 |
|
53 |
How could hardware make this time sync go any faster? |
54 |
|
55 |
> [2] ... SNIP ... runs ~1 hour ... SNIP ... |
56 |
|
57 |
Sounds great, but the same thing could run in much less time. I have |
58 |
worse hardware, and it doesn't take much longer than yours do; so, I |
59 |
don't really see the benefits new hardware bring to the table. And that |
60 |
HDD to SSD change, that's really a once in a lifetime flood. |
61 |
|
62 |
> [3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs. |
63 |
|
64 |
Sounds all cool, but think about your CPU again; saturate it... |
65 |
|
66 |
Building the Linux kernel with `make -j32 -l8` versus `make -j8` is a |
67 |
huge difference; most people follow the latter instructions, without |
68 |
really thinking through what actually happens with the underlying data. |
69 |
The former queues up jobs for your processor; so the moment a job is |
70 |
done a new job will be ready, so, you don't need to wait on the disk. |
71 |
|
72 |
Something completely different; look at the history of data mining, |
73 |
today's algorithms are much much faster than those of years ago. |
74 |
|
75 |
Just to point out that different implementations and configurations have |
76 |
much more power in cutting time than the typical hardware change does. |
77 |
|
78 |
Though, this was pretty much OT; we're talking about the dependency tree |
79 |
calculation, not about emerging which is rather a result of building |
80 |
(eg. your compiler) than it has anything to do with the package manager. |
81 |
|
82 |
PS: A take home thought: What if the hardware designers decided to not |
83 |
R&D storage, then we wouldn't have a SSD; same story, different level. |
84 |
Another level higher; we have physics, maybe CERN can improve hardware? |
85 |
But when will that happen? Can we rely and wait on that to happen? |
86 |
|
87 |
-- |
88 |
With kind regards, |
89 |
|
90 |
Tom Wijsman (TomWij) |
91 |
Gentoo Developer |
92 |
|
93 |
E-mail address : TomWij@g.o |
94 |
GPG Public Key : 6D34E57D |
95 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |