From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id iIhfIfUSNGPSXwEAbAwnHQ (envelope-from ) for ; Wed, 28 Sep 2022 11:25:09 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id iBoeIfUSNGP0SgEAauVa8A (envelope-from ) for ; Wed, 28 Sep 2022 11:25:09 +0200 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 1738A3A42C for ; Wed, 28 Sep 2022 11:25:09 +0200 (CEST) Received: from localhost ([::1]:58124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odTJU-0006rG-5m for larch@yhetil.org; Wed, 28 Sep 2022 05:25:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odRhi-00060p-VF for guix-patches@gnu.org; Wed, 28 Sep 2022 03:42:05 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:60581) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1odRhi-0003vu-Ns for guix-patches@gnu.org; Wed, 28 Sep 2022 03:42:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1odRhi-0002Hf-Fq for guix-patches@gnu.org; Wed, 28 Sep 2022 03:42:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#58100] [PATCH] gnu: cbqn: factor out singeli into derivative package. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 28 Sep 2022 07:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58100 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: Christopher Rodriguez Cc: 58100@debbugs.gnu.org Received: via spool by 58100-submit@debbugs.gnu.org id=B58100.16643509028748 (code B ref 58100); Wed, 28 Sep 2022 07:42:02 +0000 Received: (at 58100) by debbugs.gnu.org; 28 Sep 2022 07:41:42 +0000 Received: from localhost ([127.0.0.1]:59657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1odRhO-0002H2-7P for submit@debbugs.gnu.org; Wed, 28 Sep 2022 03:41:42 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:44528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1odRhK-0002Gq-Ud for 58100@debbugs.gnu.org; Wed, 28 Sep 2022 03:41:40 -0400 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4McpMx6mhYz3wV7; Wed, 28 Sep 2022 09:41:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1664350894; bh=7+N62k8AfDOh2SLdEQ7aeZeVIJyFKOTUDT4l4bvlqTA=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=Ys1lBQGNkp/y+p+x7M4wMcJz8BzUhP1hA+b1POsOa2rxEQ9zJw9hfDY8OEis5V6uy KKlFkWk4c2VZflQb/YM2DlH0Www5ljJ6xSMkhzO6WJIa14uzN2f35Edzx1NwdlRVMa hKPAUKeho+sZDJyCTpINOQA3EiBdc0kfw/xrcY/g= Message-ID: <2d539eb0ba2583fba5c2ce9c339b73d7606603a3.camel@ist.tugraz.at> From: Liliana Marie Prikler Date: Wed, 28 Sep 2022 09:41:33 +0200 In-Reply-To: <87r0zwhez2.fsf@gmail.com> References: <20220926191212.30609-1-yewscion@gmail.com> <982732ff807d152d4e8c181e3c33ca03ea72ac4b.camel@ist.tugraz.at> <87r0zwhez2.fsf@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 MIME-Version: 1.0 X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" 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=1664357109; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=7+N62k8AfDOh2SLdEQ7aeZeVIJyFKOTUDT4l4bvlqTA=; b=sZIVy2azy9Dfs7QJzKDQnC6izELmbmN7eZ/BWhiPcjMwIOBsZYg70NQ6xSGjJp+7tVrqPC cI/UIzkrCmiMsid5KqS9SlKzv9gy0vpBO357d0mhm5zVeWvqDpEqymYQz8GgIPHLshX7+M EpCJiBhy5VZ1VYWMe9y25E7VplU3SmVron8KTFzi+1GcVVmHrKhx2v0RNfY6Xdwp9fGZZl MPcJ3y5nptMqkZ/hEb+iEY1R8zhq5Xo27A1gMXf1qTLPx3qdqDPvELudp4ptlF2EuHBpoV g2X1EfiqxLNNDvR/PUS8HLDBB4bY4hYHJZcb1vzc4LapB5pgrYVsabjP28BE0g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1664357109; a=rsa-sha256; cv=none; b=RpyRNMdEERcg+llk/bAEEz0AFZDnQMD+irOu65jIQ8X2efDl9AQUYY3hrGeb465otBiTcN pFPl+LNFv7n2CN5miLN1YsEH5FE5V6GoDo+47/TYBsaOjw/devbuuyvUtoSV7qJewjNGz9 FVhqd9UVcCuwM31yvL+bStrEN+yxz+HYYD/t7a30Li1utNK+tkM9v6KKPfndR7/nbNjbQh HGcmQAfNFvBk7L90lzbXUpYr5Z4NnJLRLbx/H4dod17wbrC4z1+Sj+8uIoAbBjl7PTq6KP Ew138J4JcGhCdNZGHU23w2Sz8epWWJw9cbBcN0fPNwYCP1Fii/auJP9yef7neA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=Ys1lBQGN; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 5.95 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=Ys1lBQGN; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 1738A3A42C X-Spam-Score: 5.95 X-Migadu-Scanner: scn1.migadu.com X-TUID: 0aaDNEKps1BD Am Dienstag, dem 27.09.2022 um 13:27 -0400 schrieb Christopher Rodriguez: > I am bumping the commit from 9c1cbdc99863b1da0116df61cd832137b196dc5c > to 46501ac819c8f21c69d7d2ba4b0457a7356f5e42 (another commit was made > when closing the above-linked issue) as the new commit is the most > recent one for this un-tagged project. There is no policy in Guix to tail untagged projects. For personal experimentation, use transformations, e.g. --with-branch. But even if there is a good reason to bump the package, use a separate commit for this. > There is no 'release' to package, and so in order to stay up to date > regular updates of this package's commit will likely be necessary. Staying up to date is not good in and of itself, you have to evaluate costs and benefits. Right now, you provided neither. > I can see why the bootstrap commit might stay the same, however. > Would it be better to solely amend the commit on the actual > installable package instead? I have no hard stance on this. While one could argue that it'd be better for bootstrap binaries to be unmoving, this doesn't seem to apply here. Other than that, it's better for bootstrap paths to be short, see e.g. Rust.=20 > > > =C2=A0=C2=A0=C2=A0=C2=A0 (arguments > > > -=C2=A0=C2=A0=C2=A0=C2=A0 (list #:make-flags '(list "shared-o3" "o3n-= singeli") > > > +=C2=A0=C2=A0=C2=A0=C2=A0 (list #:make-flags '(list "shared-o3" "o3") > > Okay >=20 > I have actually just re-read the documentation after the > abovementioned most recent commit, and noticed a surviving line in > the upstream `README.md`[1]: >=20 > `make PIE=3D""` on ARM CPUs (incl. Android & M1) I'm pretty sure we'd like to specify e.g. -shared instead. > Perhaps I can incorporate this into the package to allow it to build > on aarch64 as well as x86_64? Though as mentioned in the original > upstream issue, I think there is a problem with a dependent package=E2=80= =A6 > perhaps this should be saved for a separate issue, then. It ought to at very least be a separate commit. > > Instead of providing a singeli variant, would just tuning the > > package suffice? > This was actually my biggest question when making the patch. I chose > a singeli variant because there is no architecture detection at all > in the makefile; it relies entirely on the specified targets ("o3", > "c", etc) to decide what to build for. That would be handled by the tuning compiler. > As an example: Switching the target from "o3n-singeli" to "o3" > immediately changed the entire build, preventing it from looking at > all for Singeli sources, even though I had yet to unlink them from > the source directory. >=20 > Is there a preferred method for this kind of build structure in a > Guix package? I suppose I could do a (cond *) in the make flags=E2=80=A6 > maybe referencing a variable for the target? I don't know what > variable that might be, though, as we would not only be looking for > an x86_64 target, but specifically that the underlying system > supports AVX2=E2=80=A6 >=20 > In general, I would much prefer to keep it as one package. I think it > is much easier to maintain that way, and makes the user experience > much easier as well. But I'm sorry to report that I'm unaware of how > best to implement this, and would greatly appreciate some advice. My question is: what does singeli even do for cbqn? If it's a compiler, can you not simply run that compiler in a separate phase? > > If not, I think we should try to properly unbundle singeli (as in > > build an actual singeli package) before adding another package > > variant.=C2=A0 Then, you could use existing patterns to decide whether > > to use singeli by making it an input or not. >=20 > As for unbundling singeli: Running singeli requires a version of cbqn > built with or without singeli support. Building a version of cbqn > with singeli support requires the /source/ for singeli to be present > in the build directory at build time, not a precompiled binary. > Singeli itself is actually just a BQN script[2], and not a compiled > binary at all, and is a transpiler from BQN to IR/C. It's used in the > optimized version to transpile/compile the SIMD algorithms (sic, I am > unfamiliar with this concept). >=20 > In short, to unbundle singeli, we can just avoid including singeli in > the build, as in the revised cbqn package in the patch. Good to know. > We could make a package for singeli that uses an installed bqn binary > from any cbqn package, but we would still need the sources present at > build time due to the way they are used and called in the build > script. I'm pretty sure that finding the right arguments to copy-build-system would be the first problem here. As for the comment from dzaima, I don't quite understand why you'd need two versions of cbqn. Assume you already have one built without singeli, how is it expected to change once singeli is added? > Fully decoupling the optimized cbqn from singeli would require > rewriting the parts of the build that locate and run the singeli > script, and (I think) is more suited to an upstream patch than a > package definition. I have opened an issue regarding this possibility > with upstream as of this email[3]. On that note, do you even need CBQN to run singeli or does any (conforming) BQN implementation suffice? For instance, you could try building BQN with CBQN and then use that to run singeli, or use the Java BQN. > (FWIW, I've also opened an issue regarding release tagging[4], though > from my previous correspondence with upstream I'm fairly certain a > release tag is not yet something they are comfortable with). That's fair and well, but to come back to the point made earlier, we probably won't go to a newer commit unless there's an important feature, bug fix, etc. You can spend a lot of time optimizing without substantially changing anything and trailing every single step on this way would be a fool's errand. Cheers [1] https://github.com/dzaima/CBQN/issues/46#issuecomment-1259950602