From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id cHdBMXkKn2EXPgEAgWs5BA (envelope-from ) for ; Thu, 25 Nov 2021 05:00:57 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 0NAJLXkKn2F/YgAAB5/wlQ (envelope-from ) for ; Thu, 25 Nov 2021 04:00:57 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E63A0311BE for ; Thu, 25 Nov 2021 05:00:56 +0100 (CET) Received: from localhost ([::1]:39314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mq5wO-0002jZ-51 for larch@yhetil.org; Wed, 24 Nov 2021 23:00:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51242) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mq5w7-0002jE-45 for guix-devel@gnu.org; Wed, 24 Nov 2021 23:00:40 -0500 Received: from mail-4317.proton.ch ([185.70.43.17]:37109) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mq5w3-0002Oy-2O for guix-devel@gnu.org; Wed, 24 Nov 2021 23:00:38 -0500 Date: Thu, 25 Nov 2021 04:00:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rixotstudio.cz; s=protonmail2; t=1637812831; bh=qa/lQ/Q6SciS38OKt9gsdwfiqGEL2JfffjVyQ59lfmE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=gZgdjnsYr0kNuaiyCXXXfKBj5qSZq2dDRt+NqNNxH9Odbw1po44JVYQV3MzcJCW/E rQswt8G9XZuTQ1Wh9SZCwCFB9d0Dbz8jKs/kZtITNEqMWmu7jZFgkSqsQVhaxbUp0R 0zwbavIflpaiJ0Tfi9wA3G7m4E1bW895mPsTGXvX9XE5e2XilUgU1bvsQxmWtSaAZC g00lnJBU4aLxYvOVt439s/jP+bJAbj9UMQdE8EJQEksYuGm063SlH/ti4BfrQict+8 KpuMJ4LICq6UQp4GqKqjbgJCvN6HjUje8tYKntgJJnTsomz9xIb6ksAL9nGZnutvQK kzzKS0jIuRsDQ== To: zimoun From: Jacob Hrbek Subject: Re: Proposal: Build timers Message-ID: In-Reply-To: <86r1b5u6pm.fsf@gmail.com> References: <868rxfwuib.fsf@gmail.com> <865ysjw0ek.fsf@gmail.com> <86r1b5u6pm.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------48359590c69f3568b48006a845c62b910b95c837b20acd87b96ad0b8b7376812"; charset=utf-8 Received-SPF: pass client-ip=185.70.43.17; envelope-from=kreyren@rixotstudio.cz; helo=mail-4317.proton.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Jacob Hrbek Cc: "guix-devel@gnu.org" Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1637812857; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=qa/lQ/Q6SciS38OKt9gsdwfiqGEL2JfffjVyQ59lfmE=; b=eMzL/D0XBW3VM8Q5EENq/ML7IARTUGm8MKa+lxgFbjKVIS2yUJAnGGrShbg5/7bGYs/Li3 OxH24smnXe2xmwNGqcxTiX+PZeBJ9f+qc8Rn0m4GQjZ8bmrIkER2rCkPFVc4aTVsX+YihW kheqzdJeeUGcejAFpNQJxY075MAnQfDq2tlyqwb0M/pHmhbAAYV5x0rgKmUKnmTi8YwAJ7 VwvKbaaiTx9WeXsYlPuoHWVdGpQmTqht601a5z6vb1ERz3yIQYKvVjGnvqPiFclTsXHVBQ KZjz2c45a6TPYXQFS6JxaI0mNUwQj7Fmu5lfn1wP3QwJQ3wVnR6it8kTDNFryA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637812857; a=rsa-sha256; cv=none; b=kHFz5xNTU6KMxMpTEUVjoAL4/l2a5VEEdUIaQe5My4UY+lnpOWD9FE1whePRR5HtPzny1s uqGDzyNCdepUo2HBcJFPrgBaSHi6OIBVlMIDQ0XlsiSNF5EWN0VvqQAQGv3j2GjHcR1Opr YYwkETGfitg68e7YcEc5NKiiP6S9l7bUW+Ba1kOHnulPIZs9ac2d5/OMYEtQ4X3LygFQL3 nXYL9HzPHFE+YohtQExzxEak6g1CrOFxmSXVPtLRHk8uvQMaU5z5I2vm+JBO+X0Qb+ty1h XV9FiH4sceEwlMb9HySdJnW/i4gnvdVnEFck09728pXr8so58C2ayP2wwXHO8Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=rixotstudio.cz header.s=protonmail2 header.b=gZgdjnsY; dmarc=fail reason="SPF not aligned (relaxed)" header.from=rixotstudio.cz (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.79 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=rixotstudio.cz header.s=protonmail2 header.b=gZgdjnsY; dmarc=fail reason="SPF not aligned (relaxed)" header.from=rixotstudio.cz (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: E63A0311BE X-Spam-Score: -3.79 X-Migadu-Scanner: scn0.migadu.com X-TUID: LaMYJ2Opvcsg This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------48359590c69f3568b48006a845c62b910b95c837b20acd87b96ad0b8b7376812 Content-Type: multipart/mixed;boundary=---------------------a8973fae46a08a67aca514f8381302c2 -----------------------a8973fae46a08a67aca514f8381302c2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 > The =E2=80=9Cpok=C3=A9mon-battle=E2=80=9D model is a simple linear model (cross-multiplication); using Jacob=E2=80=99s =E2=80=9Cnotation=E2=80=9D -= - zimoun It's not designed to be linear as the HP variable could be adjusted in rea= l time e.g. recalculating it every X amount of time as needed which can in= clude calculations for noise that influences the task. It currently seems as linear as I developed it to be a workable platform o= n which we can develop more robust solution in case the simple linear calc= ulations are not sufficiently accurate (which i think that it will be if w= e get sufficient amount of data to calculate it). > - HP: time to build on machine A -- zimoun Not time, but **COMPLEXITY** of the package as I see that as an important = destiction since it's by design never meant to store time, but "time value= " **that is converted in time**. > based on some experiments. Last, on machine B, knowing both nthread' an= d cpufreq' for that machine B, you are expecting to evaluate HP' for that = machine B applying the formula: > HP' =3D a * nthread' * cpufreq' + b -- zimoun In this context I would describe it as: CPU strenght =3D nthread * cpufreq * "other things that make the CPU to de= al more damage" HP =3D "CPU strenght" * "time it took to build in sec" Which is linear, but the components used to figure out this linear functio= n are non-linear e.g. "RAM memory" will most likely appear as exponential= , but it will eventually hit constant when the CPU's requirement for the m= emory are satisfied. Also the calculation should never contain systems values from systems a,b,= c,.. , rather interpreting the hardware resources into an equasion that sh= ould be integrated to calculate unknowns where the issue in that theory is figuring out the "time it took to build"= and "CPU strenght" which i think can be mitigated by determining how the = hardware affects the build by changing it's variables in two builds to det= ermine e.g. 4 thread =3D 5 min 3 threads =3D 10 min 2 threads =3D 15 min -> 1 threads will take 20 min. So literally following a pokemon battle system alike: Pokemon with 100 HP and you dealing 10 HP per turn -> it will take you 10 = turns to win the battle. --- Btw. The components capable of bottleneck such as the amount of RAM memory= should be probably calculated as <0.0,1.0> so that they can be applied as= **multipliers** to the "CPU strenght" since (following "the rule of compi= lation" using 2 GB of RAM per 1 thread) the CPU will function in a scenari= o of 4 threads with 4 GB of RAM function at half the efficiency (0.5) if i= t's requirements for fast memory are not satisfied. -- Jacob "Kreyren" Hrbek Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, November 24th, 2021 at 11:35 AM, zimoun wrote: > Hi, > = > On Tue, 23 Nov 2021 at 14:39, Jacob Hrbek kreyren@rixotstudio.cz wrote: > = > > > This approximation would not even be accurate enough for the same > > > = > > > machine. For instance, the test suite of the julia package runs > > > = > > > mainly sequential using one thread... > > = > > I am aware of this scenario and I adapted the equasion for it, but I > > = > > recognize that this exponentially increases the inaccuracy with more > > = > > threads and I don't believe that there is a mathematical way with the > > = > > provided values to handle that scenario so we would have to adjust the > > = > > calculation for those packages. > = > What I am trying to explain is that the model cannot work to be > = > predictable enough with what I consider a meaningful accuracy. > = > Obviously, relaxing the precision, it is easy to infer a rule of thumb; > = > a simple cross-multiplication fits the job. ;-) > = > The =E2=80=9Cpok=C3=A9mon-battle=E2=80=9D model is a simple linear model > = > (cross-multiplication); using Jacob=E2=80=99s =E2=80=9Cnotation=E2=80=9D= : > = > - HP: time to build on machine A > - DPS =3D nthread * cpufreq : =E2=80=9Cpower=E2=80=9D of machine > = > Then it is expected to evaluate =E2=80=99a=E2=80=99 and =E2=80=99b=E2= =80=99 on average such that: > = > HP =3D a * DPS + b > = > based on some experiments. Last, on machine B, knowing both nthread' > = > and cpufreq' for that machine B, you are expecting to evaluate HP' f= or > = > that machine B applying the formula: > = > HP' =3D a * nthread' * cpufreq' + b > = > Jacob, do I correctly understand the model? > = > In any case, that=E2=80=99s what LFS is doing, instead HP is named S= BU. And > = > instead DPS, they use a reference package. And this normalization is > = > better, IMHO. Other said, for one specific package considered as > = > reference, they compute HP1 (resp. HP2) for machine A (resp. B), the= n > = > for machine A, they know HP for another package and they deduce, > = > HP' =3D HP2/HP1 * HP > = > All this is trivial. :-) The key is the accuracy, i.e., the error > = > between the prediction HP' and the real time. Here, the issue is tha= t > = > HP1 and HP2 capture for one specific package the overall time; which > = > depends on hidden parameters as nthread, cpufreq, IO, and other > = > parameters from hardware. But that a strong assumption when consider= ing > = > these hidden parameters (evaluated for one specific package) are equ= ally > = > the same for any other package. > = > It is a strong assumption because the hidden parameters depends on > = > hardware specifications (nthread, cpufreq, etc.) and how the package > = > itself exploits them. > = > Therefore, the difference between the prediction and the real time i= s > = > highly variable, and thus personally I am not convince the effort is > = > worth; for local build. That=E2=80=99s another story. ;-) > = > LSF is well-aware of the issue and it is documented [1,2]. > = > The root of the issue is the model based on a strong assumption; bot= h > = > (model and assumption) do not fit how the reality concrete works, IM= HO. > = > One straightforward way =E2=80=94 requiring some work though =E2=80=93= for improving the > = > accuracy is to use statistical regressions. We cannot do really bett= er > = > to capture the hardware specification =E2=80=93 noticing that the ma= chine stress > = > (what the machine is currently doing when the build happens) introdu= ces > = > a variability hard to estimate beforehand. However, it is possible t= o > = > do better when dealing with packages. Other said, exploit the data f= rom > = > the build farms. > = > Well, I stop here because it rings a bell: model could be discussed = at > = > length if it is never applied to concrete numbers. :-) > = > Let keep it pragmatic! :-) > = > Using the simple LFS model and SBU, what would be the typical error? > = > For instance, I propose that we collectively send the timings of > = > packages: bash, gmsh, julia, emacs, vim; or any other 5 packages for > = > x86_64 architecture. Then we can compare typical errors between > = > prediction and real, i.e., evaluate =E2=80=9Caccuracy=E2=80=9C for S= BU and then decide > = > if it is acceptable or not. :-) > = > Cheers, > = > simon > = > 1: https://www.linuxfromscratch.org/lfs/view/stable/chapter04/abouts= bus.html > = > 2: https://www.linuxfromscratch.org/~bdubbs/about.html -----------------------a8973fae46a08a67aca514f8381302c2 Content-Type: application/pgp-keys; filename="publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc"; name="publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc"; name="publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQpWZXJzaW9uOiBPcGVuUEdQLmpz IHY0LjEwLjEwDQpDb21tZW50OiBodHRwczovL29wZW5wZ3Bqcy5vcmcNCg0KeGpNRVlBbDNGaFlK S3dZQkJBSGFSdzhCQVFkQVFLQXBtZFI4dEc5YUtFZHh3SEovWktPMkN2Wk1SV1B0DQpCTk5HcUpV aHAyTE5MMnR5WlhseVpXNUFjbWw0YjNSemRIVmthVzh1WTNvZ1BHdHlaWGx5Wlc1QWNtbDQNCmIz UnpkSFZrYVc4dVkzbyt3bzhFRUJZS0FDQUZBbUFKZHhZR0N3a0hDQU1DQkJVSUNnSUVGZ0lCQUFJ Wg0KQVFJYkF3SWVBUUFoQ1JDdDAzMFVxMEw4cVJZaEJCWjMyNEtUaktobGM0RWpCNjNUZlJTclF2 eXA1N1FBDQovMHRsYmRuQ0l6cmVLWG12VzJYU1lYekFKb3RKZHhDekUrWEFUTStxUERLekFRQ2Ni SHA3eXc2K0FybmcNCmVTdEdGbi9vbGh4VFBkcHU2NDFDTEdpZ1BtRW9CYzQ0QkdBSmR4WVNDaXNH QVFRQmwxVUJCUUVCQjBEYQ0KaUkzalFmU29pM0RaNC9OZm14R2RzUnN2OS9CcU1nVzVqNmpkQnFr eUlBTUJDQWZDZUFRWUZnZ0FDUVVDDQpZQWwzRmdJYkRBQWhDUkN0MDMwVXEwTDhxUlloQkJaMzI0 S1RqS2hsYzRFakI2M1RmUlNyUXZ5cEhjRUINCkFPUXhTL0ovVU0wZWU4azJqYmxpV2QvUTBJZCtY OFVIQlhoeXFWUmMyMnFyQVFETEhjVzk3V1FiU0pGbw0KMTlrd3Q3ME95SGVwRjZMV3BERDBQdUlT WkQ2SUNnPT0NCj05a1pnDQotLS0tLUVORCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQo= -----------------------a8973fae46a08a67aca514f8381302c2-- --------48359590c69f3568b48006a845c62b910b95c837b20acd87b96ad0b8b7376812 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wnUEARYKAAYFAmGfCkkAIQkQrdN9FKtC/KkWIQQWd9uCk4yoZXOBIwet030U q0L8qWT7AP9+9v0KS+CYyOAnuluddUdCnwOuMJdfI/XLFJwjk9tqeQEAvEVL +BM29uA9dSdLxYMt6JbqQgxoAAaum4TXa2lEvAU= =e79j -----END PGP SIGNATURE----- --------48359590c69f3568b48006a845c62b910b95c837b20acd87b96ad0b8b7376812--