From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 64A3B1381F3 for ; Sun, 16 Jun 2013 21:27:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3B357E0919; Sun, 16 Jun 2013 21:27:07 +0000 (UTC) Received: from jacques.telenet-ops.be (jacques.telenet-ops.be [195.130.132.50]) by pigeon.gentoo.org (Postfix) with ESMTP id EA11AE08DC for ; Sun, 16 Jun 2013 21:27:05 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by jacques.telenet-ops.be with bizsmtp id p9T51l0012khLEN0J9T5yz; Sun, 16 Jun 2013 23:27:05 +0200 Date: Sun, 16 Jun 2013 23:24:27 +0200 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Packages up for grabs Message-ID: <20130616232427.063566d4@TOMWIJ-GENTOO> In-Reply-To: References: <1371376191.10717.15.camel@localhost> <1371390923.28535.67.camel@big_daddy.dol-sen.ca> <20130616164445.0c8f8f55@TOMWIJ-GENTOO> <1371402560.28535.79.camel@big_daddy.dol-sen.ca> <1371403298.22480.8.camel@localhost> <20130616202324.45cb3262@TOMWIJ-GENTOO> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Ny/7=G022Jtj4XfkCQZHlPp"; protocol="application/pgp-signature" X-Archives-Salt: c1f97e9e-1239-49b5-bf11-8588940fe40c X-Archives-Hash: 62122621f98623276ea8972452a634a5 --Sig_/Ny/7=G022Jtj4XfkCQZHlPp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 16 Jun 2013 19:33:53 +0000 (UTC) Duncan <1i5t5.duncan@cox.net> wrote: > TL;DR: SSDs help. =3D:^) TL;DR: SSDs help, but they don't solve the underlying problem. =3D:-( I have one; it's great to help make my boot short, but it isn't really a great improvement for the Portage tree. Better I/O isn't a solution to computational complexity; it doesn't deal with the CPU bottleneck. Sadly, an improvement to the CPU as good as the switch from HDD to SSD, I'm yet to see such a hardware improvement. Maybe if we stack the transistors into the third dimension, something Intel was working on. > Quite apart from the theory and question of making the existing code=20 > faster vs. a new from-scratch implementation, there's the practical=20 > question of what options one can actually use to deal with the > problem /now/. Don't rush it: Do you know the problem well? Does the solution properly deal with it? Is it still usable some months / years from now? > FWIW, one solution (particularly for folks who don't claim to have=20 > reasonable coding skills and thus have limited options in that > regard) is to throw hardware at the problem. Improvements in algorithmic complexity (exponential) are much bigger than improvements you can achieve by buying new hardware (linear). > I recently upgraded my main system to SDD. ... SNIP ... Between that > and the 6-core bulldozer[3] I upgraded to last year, I'm quite happy > with portage's current performance, ... SNIP ... Ironically, you don't even fully use the CPU, but only one core of it; I'm glad you have a 6-core processor, but to Portage it is a 1-core during dependency tree calculation. Portage becomes slower at a faster rate than your hardware get faster; this will continue to be that way until you make Portage benefit of it, or failing that you would need to come up with an alternative PM. I didn't get my short boot from upgrading hardware alone; quite the opposite, it was rather the results of the efforts spent on it. > --- > [1] I'm running ntp and the initial ntp-client connection and time > sync takes ~12 seconds a lot of the time, just over the initial 10 > seconds down, 50 to go, trigger on openrc's 1-minute timeout. Why do you make your boot wait for NTP to sync its time? How could hardware make this time sync go any faster? > [2] ... SNIP ... runs ~1 hour ... SNIP ... Sounds great, but the same thing could run in much less time. I have worse hardware, and it doesn't take much longer than yours do; so, I don't really see the benefits new hardware bring to the table. And that HDD to SSD change, that's really a once in a lifetime flood. > [3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs. Sounds all cool, but think about your CPU again; saturate it... Building the Linux kernel with `make -j32 -l8` versus `make -j8` is a huge difference; most people follow the latter instructions, without really thinking through what actually happens with the underlying data. The former queues up jobs for your processor; so the moment a job is done a new job will be ready, so, you don't need to wait on the disk. Something completely different; look at the history of data mining, today's algorithms are much much faster than those of years ago. Just to point out that different implementations and configurations have much more power in cutting time than the typical hardware change does. Though, this was pretty much OT; we're talking about the dependency tree calculation, not about emerging which is rather a result of building (eg. your compiler) than it has anything to do with the package manager. PS: A take home thought: What if the hardware designers decided to not R&D storage, then we wouldn't have a SSD; same story, different level. Another level higher; we have physics, maybe CERN can improve hardware? But when will that happen? Can we rely and wait on that to happen? --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/Ny/7=G022Jtj4XfkCQZHlPp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJRvi0OAAoJEJWyH81tNOV9dUQH/1yD4x94ixV1dWnugPPPEN1X PvJpizdL7UopOdAXwRkyomevMlnx/0zoN/y+xBfZLlAWUBIbzyVuLBbWlsL3ZTYW XZaUqTItKtVu8aioE5sW0H/RZ8VrxFx2MUAlIH/diRo/CyaAu7tE4gmwlRFUQasP 7VW3YIoWSSAwl0khXtt6Xj5ZCF72pl6FA/LlrwpN+lO0V4XrweoQlvQLOCuqmbQ6 6gMTDeZFO3Ug/DkVhSf0xCjqOB92k4ftykatFyibqy2CGlA3eoyaIb56iy/yyo0H PHl1c86XUTa2H+1iFO5K2MgdTdL2vQCRg4icyMFYwKVVsiVkZfLupqlNNhxFHlw= =aFS2 -----END PGP SIGNATURE----- --Sig_/Ny/7=G022Jtj4XfkCQZHlPp--