all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: elaexuotee--- via Guix-patches via <guix-patches@gnu.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: Maxime Devos <maximedevos@telenet.be>, 48463@debbugs.gnu.org
Subject: [bug#48463] gnu: Add j.
Date: Tue, 18 Jan 2022 19:40:06 +0900	[thread overview]
Message-ID: <2GLLHI6YET96V.279HCOFQSZLLF@wilsonb.com> (raw)
In-Reply-To: <f55cd366d1fcc61303b4519da8da36f91a6ca3c8.camel@gmail.com>

> FWIW I don't quite think that fat binaries are the issue here, but that
> building AVX blows up the check phase in the way we currently do.  It's
> a similar issue w.r.t. check? for cross-compiling.  In my opinion only
> the base feature set can be checked unless the CPU supports the same
> features as the target.

Oh, good. Apparently, I mis-interpreted your original concerns.

> I think if we want to do fat binaries, the solution would be to build
> all three variants from make-j and tests only the base variants, and
> then have a non-substitutable wrapper package, that takes that as an
> input and simply provides a wrapper tuned to the current CPU features.
> If you want, you can then rerun the correct tests in the wrapper
> package.  The package returned by make-j could itself also provide
> three binaries just in case someone doesn't want to generate the
> wrapper package, but knows they can run ijconsole-avx2 just fine. 
> WDYT?

Slick. Let me check my understanding against yours with some specifics:

- Name make-j's package 'jsoftware-j-lib' which
  1. Builds all upstream stuff, and
  2. Only runs libj.so (non-avx) tests;

- Create non-substitutable 'jsoftware-j' wrapper package which
  1. Detects SSE extensions at build time and specializes the 'ijconsole'
     script accordingly, and
  2. Runs tests if and only if an avx or avx2 variant.

Does those points jibe with your thoughts on the fat binaries approach?


Glancing around at the CPU tuning stuff, it looks like tunable packages end up
getting a 'cpu-tuning' property which holds the microartecture name passed to
-march. AVX first landed in Sandy Bridge, and AVX2 in Haswell, so assuming
cpu-tuning is accessible at build time, it should be easy enough to condition
the build phase on those.

Regarding the check phase, here's a relevant comment in
guix/transformations.scm(tuned-package):552:

    ;; The machine building this package may or may not be able to run code
    ;; for MICRO-ARCHITECTURE.  Because of that, skip tests; they are run for
    ;; the "baseline" variant anyway.

Which I read to mean that the check phase should explicitly use libj.so,
ignoring libj-avx.so and libj-avx2.so. Running specialized tests in a
non-substitutable wrapper seems potentially better in this particular case.


Thoughts?


> I'm in UTC+1 and have a day job from 8am to 4pm (plus delta and bus
> routes), which normally make me unable to reply from roughly 6:30am to
> 8pm.  I'm also a little shy when it comes to letting strangers hear my
> voice and experiencing healthy vaccine side effects atm.

UTC+9 here. Okay. That's unfortunate, but I'll keep the offer open if you
change your mind.

Hope you get to feeling better soon!

Cheers,
B. Wilson




  reply	other threads:[~2022-01-18 10:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16 10:54 [bug#48463] gnu: Add j elaexuotee--- via Guix-patches via
2021-05-16 14:30 ` Leo Prikler
2021-05-24 13:37   ` elaexuotee--- via Guix-patches via
2021-05-24 14:39     ` Leo Prikler
2021-05-25  3:57       ` elaexuotee--- via Guix-patches via
2021-10-01 15:31         ` Liliana Marie Prikler
2022-01-12  9:47           ` elaexuotee--- via Guix-patches via
2022-01-12 11:06             ` Maxime Devos
2022-01-12 11:10             ` Maxime Devos
2022-01-12 12:07               ` elaexuotee--- via Guix-patches via
2022-01-12 19:55                 ` Liliana Marie Prikler
2022-01-13  7:51                   ` elaexuotee--- via Guix-patches via
2022-01-13 17:51                     ` Liliana Marie Prikler
2022-01-15 14:05                       ` elaexuotee--- via Guix-patches via
2022-01-15 15:08                         ` Liliana Marie Prikler
2022-01-16  5:29                           ` elaexuotee--- via Guix-patches via
2022-01-16  8:04                             ` Liliana Marie Prikler
2022-01-16 15:19                               ` elaexuotee--- via Guix-patches via
2022-01-16 19:53                                 ` Liliana Marie Prikler
2022-01-17  1:24                                   ` elaexuotee--- via Guix-patches via
2022-01-17 21:12                                     ` Liliana Marie Prikler
2022-01-18  4:01                                       ` elaexuotee--- via Guix-patches via
2022-01-18  8:04                                         ` Liliana Marie Prikler
2022-01-18 10:40                                           ` elaexuotee--- via Guix-patches via [this message]
2022-01-18 11:33                                             ` Liliana Marie Prikler
2022-05-28 12:44 ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2GLLHI6YET96V.279HCOFQSZLLF@wilsonb.com \
    --to=guix-patches@gnu.org \
    --cc=48463@debbugs.gnu.org \
    --cc=elaexuotee@wilsonb.com \
    --cc=liliana.prikler@gmail.com \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.