From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M9nCp-0005MM-8k for garchives@archives.gentoo.org; Thu, 28 May 2009 21:32:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B07F7E06A5; Thu, 28 May 2009 21:32:05 +0000 (UTC) Received: from smarthost03.mail.zen.net.uk (smarthost03.mail.zen.net.uk [212.23.3.142]) by pigeon.gentoo.org (Postfix) with ESMTP id 8AFC8E06A5 for ; Thu, 28 May 2009 21:32:05 +0000 (UTC) Received: from [62.3.120.141] (helo=NeddySeagoon) by smarthost03.mail.zen.net.uk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1M9nCm-00080W-TB for gentoo-dev@lists.gentoo.org; Thu, 28 May 2009 21:32:05 +0000 Date: Thu, 28 May 2009 22:31:58 +0100 From: Roy Bamford Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28 To: gentoo-dev@lists.gentoo.org In-Reply-To: <20090528205411.6aaa7e00@snowcone> (from ciaran.mccreesh@googlemail.com on Thu May 28 20:54:11 2009) X-Mailer: Balsa 2.3.28 Message-Id: <1243546324.3439.4@NeddySeagoon> 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: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Originating-Smarthost03-IP: [62.3.120.141] X-Archives-Salt: 640a6871-7241-461d-b136-04c12041dd6c X-Archives-Hash: ef1c99a53df4646e994ec398ba4282ab -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009.05.28 20:54, Ciaran McCreesh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On Thu, 28 May 2009 20:42:30 +0100 > Roy Bamford wrote: > > I don't see any objective measurements of performace in GLEP 55 > > either. perhaps you could point me to a version and pargraph in > GLEP > > that details these benchmarks ? >=20 > It's not a question of benchmarks. It's a question of being slower by > design. Allow me to explain: >=20 > If GLEP 55 were to include benchmarks, they would be dismissed as > "well > we can make that code faster", which would be missing the point -- > that > it's a design penalty regardless of implementation. >=20 > - --=20 > Ciaran McCreesh > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) >=20 > iEYEARECAAYFAkoe6+kACgkQ96zL6DUtXhGqbwCg5Ye1CC5V+WjQ1nArN/eM1hpR > 3qwAniS95KnP7FBbnbUiEVJnO5LLIXgF > =3DFFMi > -----END PGP SIGNATURE----- >=20 Ciaran, Having the benchmarks allows consideration of the design trade offs to=20 be made. It moves the GLEP one step closer to acceptance, in one form=20 or another. Like tonight at the council meeting, the meeting acknowledged that=20 there is one or more problems to be addressed, thats the first step. The benchmarks are only one piece of the pursuavie evidence. Speed isn't everything. Let me remind you of an old playground joke, There is an old bull and a young bull in a field on a hillside, next to=20 a herd of cows .... I'm sure you know it.=20 - --=20 Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkofAtQACgkQTE4/y7nJvat16QCg2KkRt8+veYkgKiuBvwY6Sgam 7toAoIMdbtTMHR34OkqcxMUxV6Ggi9/u =3DaJF8 -----END PGP SIGNATURE-----