Including code in a non-Guile language into Guix

Including code in a non-Guile language into Guix

[Evan Cooney]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

Hello everyone,

My name is Evan Cooney. I use GNU Guix but I'm pretty new to it, I'm also
not a professional, I mostly program for fun and I'm mostly self-taught. I
was watching some videos about software performance and optimization, which
brought to mind that, at least on my computer, guix package commands
(particularly search, install, and remove) run much slower than the
equivalents on other distros I've used. I know that Guix is mainly written
in Guile, but has much thought gone into optimizing these commands by
rewriting some of the code in a more performance-oriented language like C?
Guile is designed for interoperability with C code, and many other GNU
programs (gcc, coreutils, gdb, bash, etc.) are written in C or similar
languages. C is also more widely taught and known than Guile, so adding C
might help bring developers to Guix. I would love to try to work on
optimizing the performance of these commands and any help would
be appreciated.

Thanks,
Evan Cooney

[-- Attachment #2: Type: text/html, Size: 1108 bytes --]

Re: Including code in a non-Guile language into Guix

[Daniel Littlewood]

[-- Attachment #1: Type: text/plain, Size: 3470 bytes --]

Hi Evan,

Some guix commands are indeed quite slow. This has been the subject of
discussion on the mailing list previously. I found one example from a year
ago, but I guess there are others:

https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00085.html

That being said, I would recommend caution in your conclusions for two
reasons:

1. Most distributions are not a like-for-like comparison with Guix. The
only distro I would consider directly comparing with in terms of
performance would be NixOS. Installation of software on guix requires
strictly more work than, say, on Debian or Arch, because it provides more
guarantees than those distributions do in terms of reproducibility. Others
on the list can probably speak more to the details of why or how much
slower it should be expected to be. However, Guix *is* noticeably slower
than Nix is, so your observation is still correct.

2. Programme performance is a complex topic, and it is a common
misconception that programs written in C are always, or typically, faster
than counterparts in garbage-collected languages. This is not really true
in many cases, particularly when costs of development are considered.

I assume that having a C core, or splitting out parts of Guix into C, was
considered early on in development. After all it is kind of the point of
guile that it interfaces well with C. Other members of the lost may be able
to give the historical context.

Having said that, I wonder (and could not find out) whether there is
quantitative data on how fast/slow Guix is for common operations. If you
could do some timings of what you think "too slow" means (e.g. for a guix
pull, or guix shell PKG).

Some data from me, using Guix on a foreign distro (Debian)

guix pull ("38k new commits"): 21m45s
guix pull immediately after: 2m25s
guix shell emacs (fresh): 1m49s
guix shell emacs (cached): <1s

apt update: 2s
apt install emacs: 2s

nix-channel --update: 0m23s
nix shell -p emacs (fresh): 0m24s
nix-shell -p emacs (cached): 4s

The apt commands are really not a fair comparison. In particular I noticed
the Guix command had to pull in all dependencies, while apt seemingly had
everything readily available. Note that I did apt remove emacs before
installing, but nothing else.

I'm not sure whether the nix/guix comparisons are fair. I might have more
installed in Guix vs nix.

All the best,
Dan

On Thu, Oct 31, 2024, 06:50 Evan Cooney <evancooney71@gmail.com> wrote:

> Hello everyone,
>
> My name is Evan Cooney. I use GNU Guix but I'm pretty new to it, I'm also
> not a professional, I mostly program for fun and I'm mostly self-taught. I
> was watching some videos about software performance and optimization, which
> brought to mind that, at least on my computer, guix package commands
> (particularly search, install, and remove) run much slower than the
> equivalents on other distros I've used. I know that Guix is mainly written
> in Guile, but has much thought gone into optimizing these commands by
> rewriting some of the code in a more performance-oriented language like C?
> Guile is designed for interoperability with C code, and many other GNU
> programs (gcc, coreutils, gdb, bash, etc.) are written in C or similar
> languages. C is also more widely taught and known than Guile, so adding C
> might help bring developers to Guix. I would love to try to work on
> optimizing the performance of these commands and any help would
> be appreciated.
>
> Thanks,
> Evan Cooney
>

[-- Attachment #2: Type: text/html, Size: 4766 bytes --]

Re: Including code in a non-Guile language into Guix

[Suhail Singh]

Daniel Littlewood <danielittlewood@gmail.com> writes:

> guix pull ("38k new commits"): 21m45s
> guix pull immediately after: 2m25s
> guix shell emacs (fresh): 1m49s
> ...
>
> nix-channel --update: 0m23s
> nix shell -p emacs (fresh): 0m24s

Those are some interesting comparisons.  Is the reason guix pull takes
so long as compared to updating nix-channel primarily due to the
authentication of commits?  Or something else?

-- 
Suhail

Re: Including code in a non-Guile language into Guix

[Ricardo Wurmus]

Suhail Singh <suhailsingh247@gmail.com> writes:

> Daniel Littlewood <danielittlewood@gmail.com> writes:
>
>> guix pull ("38k new commits"): 21m45s
>> guix pull immediately after: 2m25s
>> guix shell emacs (fresh): 1m49s
>> ...
>>
>> nix-channel --update: 0m23s
>> nix shell -p emacs (fresh): 0m24s
>
> Those are some interesting comparisons.  Is the reason guix pull takes
> so long as compared to updating nix-channel primarily due to the
> authentication of commits?  Or something else?

It's "something else".  This is a comparison between apples and
giraffes.  "guix pull" does a different job than "nix-channel"; the
latter only needs to download a new version of inert data whereas the
former computes a trampoline and then updates Guix itself.

The fundamental difference is that Guix is a library, not merely
"package metadata" that would be independent of the Guix executable.

Comparing "guix shell" and "nix shell" is fair game, though, but I
cannot reproduce the above numbers.  Here's my crude test:

    time guix shell --no-substitutes emacs-minimal -- ls
    real	0m2.386s
    user	0m1.489s
    sys 	0m0.141s

This is without the "guix shell" cache, but with Emacs present in /gnu/store.

-- 
Ricardo

Re: Including code in a non-Guile language into Guix

[Suhail Singh]

Ricardo Wurmus <rekado@elephly.net> writes:

>>> guix pull ("38k new commits"): 21m45s
>>> guix pull immediately after: 2m25s
>>> ...
>>>
>>> nix-channel --update: 0m23s
>>
>> Those are some interesting comparisons.  Is the reason guix pull takes
>> so long as compared to updating nix-channel primarily due to the
>> authentication of commits?  Or something else?
>
> It's "something else".  This is a comparison between apples and
> giraffes.  "guix pull" does a different job than "nix-channel"; the
> latter only needs to download a new version of inert data whereas the
> former computes a trampoline and then updates Guix itself.
>
> The fundamental difference is that Guix is a library, not merely
> "package metadata" that would be independent of the Guix executable.

Thank you for that explanation.

-- 
Suhail

Re: Including code in a non-Guile language into Guix

[Runciter via Development of GNU Guix and the GNU System distribution.]

Suhail Singh <suhailsingh247@gmail.com> writes:

> Daniel Littlewood <danielittlewood@gmail.com> writes:
>
>> guix pull ("38k new commits"): 21m45s
>> guix pull immediately after: 2m25s
>> guix shell emacs (fresh): 1m49s
>> ...
>>
>> nix-channel --update: 0m23s
>> nix shell -p emacs (fresh): 0m24s
>
> Those are some interesting comparisons.  Is the reason guix pull takes
> so long as compared to updating nix-channel primarily due to the
> authentication of commits?  Or something else?

As far as the local machine computations go, clearly, authenticating the
commits is not the bottleneck. On all machines, indexing the received
git objects locally is much longer than authenticating the commits.

On my X60, when I pull for the first time after I delete the cache, the
indexing step alone takes more than 40 minutes.

The 2m25s that Daniel had for his second git pull, that had to be spent
mostly on computing the Guix derivation. This time is in large part
in-compressible I guess. Not that I know of a lot about this, but by
reading the output, it's clear that every time guix pull has to compute
the whole derivation of the latest commit of all the
channels. Apparently, in a pull where Guix determines that it has
nothing to do, this step is required before Guix can make the
determination that it has nothing to do...

Re: Including code in a non-Guile language into Guix

[Evan Cooney]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

Would it be useful for me to wrote a script to collect performance data for
various stages? Like downloading, computing derivations, building profile
etc?

On Thu, Oct 31, 2024, 11:18 AM Runciter via Development of GNU Guix and the
GNU System distribution. <guix-devel@gnu.org> wrote:

> Suhail Singh <suhailsingh247@gmail.com> writes:
>
> > Daniel Littlewood <danielittlewood@gmail.com> writes:
> >
> >> guix pull ("38k new commits"): 21m45s
> >> guix pull immediately after: 2m25s
> >> guix shell emacs (fresh): 1m49s
> >> ...
> >>
> >> nix-channel --update: 0m23s
> >> nix shell -p emacs (fresh): 0m24s
> >
> > Those are some interesting comparisons.  Is the reason guix pull takes
> > so long as compared to updating nix-channel primarily due to the
> > authentication of commits?  Or something else?
>
> As far as the local machine computations go, clearly, authenticating the
> commits is not the bottleneck. On all machines, indexing the received
> git objects locally is much longer than authenticating the commits.
>
> On my X60, when I pull for the first time after I delete the cache, the
> indexing step alone takes more than 40 minutes.
>
> The 2m25s that Daniel had for his second git pull, that had to be spent
> mostly on computing the Guix derivation. This time is in large part
> in-compressible I guess. Not that I know of a lot about this, but by
> reading the output, it's clear that every time guix pull has to compute
> the whole derivation of the latest commit of all the
> channels. Apparently, in a pull where Guix determines that it has
> nothing to do, this step is required before Guix can make the
> determination that it has nothing to do...
>
>
>

[-- Attachment #2: Type: text/html, Size: 2286 bytes --]

Re: Including code in a non-Guile language into Guix

[Simon Tournier]

Hi,

On Thu, 31 Oct 2024 at 12:31, Daniel Littlewood <danielittlewood@gmail.com> wrote:

> Some data from me, using Guix on a foreign distro (Debian)
>
> guix pull ("38k new commits"): 21m45s
> guix pull immediately after: 2m25s
> guix shell emacs (fresh): 1m49s
> guix shell emacs (cached): <1s

Just to be sure,

 1. Have you allowed substitutes?
 2. Do you have SSD or HDD hard disk?
 3. What is your link speed? kiB/s or MiB/s or more or less?

Thanks,
simon

PS: As explained elsewhere, comparing "guix pull" with "apt-get update"
is compared apple to giraffe.  In order to compare the same in Debian
world, it would mean: compile apt-get itself then process the
debian/control file of all packages
.

Re: Including code in a non-Guile language into Guix

[Ricardo Wurmus]

Evan Cooney <evancooney71@gmail.com> writes:

> I know that Guix is mainly written in Guile, but has much thought gone
> into optimizing these commands

Yes.

> by rewriting some of the
> code in a more performance-oriented language like C?

No.

Guile is not the bottleneck.

> C is also more widely taught and known than Guile, so adding C might
> help bring developers to Guix.

I find this doubtful.

-- 
Ricardo

Re: Including code in a non-Guile language into Guix

[Simon Tournier]

Hi,

On Thu, 31 Oct 2024 at 17:15, Ricardo Wurmus <rekado@elephly.net> wrote:

>> by rewriting some of the
>> code in a more performance-oriented language like C?
>
> No.
>
> Guile is not the bottleneck.

For what it is worth, some months ago I gave a look to ’sort’.

The current implementation provided by Guile is written in C.  Guess
what?  I wrote some pure Guile as fast as such C (if not faster!).

https://simon.tournier.info/posts/2024-02-05-guile-sort/index.html

To make explicit my understanding of Ricardo’s answer: no it’s not the
Scheme compiler provided by Guile that is the current performance
bottleneck but there is still room of improvement for the whole Guile
(Garbage Collection, Standard Library, etc.).

Cheers,
simon

Re: Including code in a non-Guile language into Guix

[Maxim Cournoyer]

Hello,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Thu, 31 Oct 2024 at 17:15, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>>> by rewriting some of the
>>> code in a more performance-oriented language like C?
>>
>> No.
>>
>> Guile is not the bottleneck.
>
> For what it is worth, some months ago I gave a look to ’sort’.
>
> The current implementation provided by Guile is written in C.  Guess
> what?  I wrote some pure Guile as fast as such C (if not faster!).
>
> https://simon.tournier.info/posts/2024-02-05-guile-sort/index.html
>
> To make explicit my understanding of Ricardo’s answer: no it’s not the
> Scheme compiler provided by Guile that is the current performance
> bottleneck but there is still room of improvement for the whole Guile
> (Garbage Collection, Standard Library, etc.).

Thanks for sharing; that was a fun (and impressive!) read.  Congrats for
the blog post and new sort Scheme implementation!

-- 
Thanks,
Maxim

Re: Including code in a non-Guile language into Guix

[Attila Lendvai]

> I know that Guix is mainly written in Guile, but has much thought
> gone into optimizing these commands by rewriting some of the code in
> a more performance-oriented language like C?


this is a slow-dying, but completely unjustified stereotype of C and "highlevel" languages like lisp.

the truth is that for any non-trivial problem/domain it's easier to write faster lisp code than C.

the reason is that even if a FOR loop runs twice as fast in C (it's not), if the programmer can spend more time thinking/experimenting with the domain, and come up with a better optimization *in the domain*, then he may gain *orders of magnitude*, not a mere doubling that "more performance-oriented languages" provide.

and if the task is about the most efficient use of the hardware at hand (think of simulations), then i have way more tools to profile my lisp code, and it's way easier to extend the lisp compiler under me with some custom-made primitives to peephole optimize my hotspots. or run the same code with and without custom made instrumentation to gain more insights about the bottlenecks. or compile my hotspots at runtime, if e.g. i have a task that rarely changes, but must be repeated endlessly (think of a firewall). or if the domain is such, then straight out write a custom compiler for a DSL that is specific to the task at hand, and seamlessly integrates into the the rest of my lisp codebase.

when coding in C you're wasting a lot of your attention on manually translating the domain to a verbose mess of C code that can't really encode much of the domain abstractions. writing C code is much more of a manual, lossy translation from domain-to-C than writing a lisp solution to the same problem, which is much more about converging lisp and your domain from both directions. and on top of this all, what a timesink debugging C code can be!

</rant>

PS: note though that the above is written from experience with more capable lisps like SBCL + Slime.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Government is the great fiction through which everybody endeavors to live at the expense of everybody else.”
	— Frédéric Bastiat (1801–1850), 'The State' (1848)