Acknowledgement sent
to Ludovic Courtès <ludo@gnu.org>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Tue, 14 Apr 2020 16:24:01 GMT) (full text, mbox, link).
Subject: Poor performance on low-end ARMv7 devices
Date: Tue, 14 Apr 2020 15:59:24 +0200
Hello!
On my Olimex OLinuXino A20, here’s what I get with Guix on Guile 3.0.2:
--8<---------------cut here---------------start------------->8---
$ guix describe
Generation 1 Apr 11 2020 13:26:01 (current)
guix 6720616
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 6720616daaf711314827c157a660339990e5cb07
$ time guix build hello -d --no-grafts
/gnu/store/s0di07vhva95rl8p3gimlna5ffca7xlq-hello-2.10.drv
real 0m9.964s
user 0m8.660s
sys 0m0.810s
--8<---------------cut here---------------end--------------->8---
Most of it seems to go in loading .go files:
--8<---------------cut here---------------start------------->8---
$ guix repl
GNU Guile 3.0.2
Copyright (C) 1995-2020 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
scheme@(guix-user)> ,time (use-modules (guix) (gnu) (gnu packages base))
;; 8.104000s real time, 6.879000s run time. 0.755000s spent in GC.
scheme@(guix-user)> (define s (open-connection))
scheme@(guix-user)> ,time (package-derivation s hello #:graft? #f)
$1 = #<derivation /gnu/store/s0di07vhva95rl8p3gimlna5ffca7xlq-hello-2.10.drv => /gnu/store/z4ig2v79x3y7r5w1gs7rg7cgyvja4dn1-hello-2.10 31a5bb8>
;; 3.101000s real time, 2.493000s run time. 0.324000s spent in GC.
--8<---------------cut here---------------end--------------->8---
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#40626; Package guix.
(Tue, 14 Apr 2020 18:09:02 GMT) (full text, mbox, link).
To: Ludovic Courtès <ludo@gnu.org>,40626@debbugs.gnu.org
Subject: Re: bug#40626: Poor performance on low-end ARMv7 devices
Date: Tue, 14 Apr 2020 14:08:00 -0400
Le 14 avril 2020 09:59:24 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hello!
>
>On my Olimex OLinuXino A20, here’s what I get with Guix on Guile 3.0.2:
>
>--8<---------------cut here---------------start------------->8---
>$ guix describe
>Generation 1 Apr 11 2020 13:26:01 (current)
> guix 6720616
> repository URL: https://git.savannah.gnu.org/git/guix.git
> commit: 6720616daaf711314827c157a660339990e5cb07
>$ time guix build hello -d --no-grafts
>/gnu/store/s0di07vhva95rl8p3gimlna5ffca7xlq-hello-2.10.drv
>
>real 0m9.964s
>user 0m8.660s
>sys 0m0.810s
>--8<---------------cut here---------------end--------------->8---
>
>Most of it seems to go in loading .go files:
>
>--8<---------------cut here---------------start------------->8---
>$ guix repl
>GNU Guile 3.0.2
>Copyright (C) 1995-2020 Free Software Foundation, Inc.
>
>Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>This program is free software, and you are welcome to redistribute it
>under certain conditions; type `,show c' for details.
>
>Enter `,help' for help.
>scheme@(guix-user)> ,time (use-modules (guix) (gnu) (gnu packages
>base))
>;; 8.104000s real time, 6.879000s run time. 0.755000s spent in GC.
>scheme@(guix-user)> (define s (open-connection))
>scheme@(guix-user)> ,time (package-derivation s hello #:graft? #f)
>$1 = #<derivation
>/gnu/store/s0di07vhva95rl8p3gimlna5ffca7xlq-hello-2.10.drv =>
>/gnu/store/z4ig2v79x3y7r5w1gs7rg7cgyvja4dn1-hello-2.10 31a5bb8>
>;; 3.101000s real time, 2.493000s run time. 0.324000s spent in GC.
>--8<---------------cut here---------------end--------------->8---
>
>Ludo’.
In case it helps, I observe the same kind of timing on my cubietruck (same guile, but guix from april 1st). It's slightly faster than you, the processor is a cortex-a7.
Information forwarded
to bug-guix@gnu.org: bug#40626; Package guix.
(Tue, 14 Apr 2020 19:10:02 GMT) (full text, mbox, link).
For comparison, on a Banana Pi M2 Ultra I get:
root@bpi-iot-ros-ai:/# time guix build hello -d --no-grafts
/gnu/store/yp46hszc04dx2zy6kscy1zmjfg9y8flq-hello-2.10.drv
real 0m13.481s
user 0m11.230s
sys 0m0.900s
root@bpi-iot-ros-ai:/# time guix build hello -d --no-grafts
/gnu/store/yp46hszc04dx2zy6kscy1zmjfg9y8flq-hello-2.10.drv
real 0m11.471s
user 0m10.820s
sys 0m0.380s
root@bpi-iot-ros-ai:/# guix repl
GNU Guile 2.2.4
Copyright (C) 1995-2017 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
scheme@(guix-user)> ,time (use-modules (guix) (gnu) (gnu packages base))
;; 3.360000s real time, 3.270000s run time. 0.519000s spent in GC.
scheme@(guix-user)> (define s (open-connection))
scheme@(guix-user)> ,time (package-derivation s hello #:graft? #f)
$1 = #<derivation /gnu/store/yp46hszc04dx2zy6kscy1zmjfg9y8flq-hello-2.10.drv => /gnu/store/cp0qvs3vxrqiyyxfi8556n52x7ax8khf-hello-2.10 14fabb8>
;; 6.829000s real time, 6.579000s run time. 1.019000s spent in GC.
Processor is a Cortex A7.
Note:
You can do some RAM training and if RAM is connected better on your board,
you can sometimes have staggering speed gains.
See also https://linux-sunxi.org/A10_DRAM_Controller_Calibration
Subject: Re: bug#40626: Poor performance on low-end ARMv7 devices
Date: Tue, 14 Apr 2020 22:01:02 +0200
Hi Danny,
Danny Milosavljevic <dannym@scratchpost.org> skribis:
> root@bpi-iot-ros-ai:/# guix repl
> GNU Guile 2.2.4
This is a fairly old Guix though, so not directly comparable.
Could you try with a current Guix?
(Yeah, you’ll have to pull, and that takes verrrrry loong. Be sure to
pick a commit that’s fully built on
<https://ci.guix.gnu.org/jobset/guix-modular-master>.)
Ludo’.
Severity set to 'important' from 'normal'
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Thu, 16 Apr 2020 08:23:02 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#40626; Package guix.
(Thu, 16 Apr 2020 15:22:01 GMT) (full text, mbox, link).
Hi,
Many ARM Single Board Computers are commonly used with microSD for
storage, and some microSD cards are extremely slow (and sometimes
unreliable when they are old).
Could the performance issues be related to storage device I/Os?
Denis.
To: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Cc: 40626@debbugs.gnu.org
Subject: Re: bug#40626: Poor performance on low-end ARMv7 devices
Date: Fri, 03 Jul 2020 09:22:48 +0200
Hello,
> Many ARM Single Board Computers are commonly used with microSD for
> storage, and some microSD cards are extremely slow (and sometimes
> unreliable when they are old).
>
> Could the performance issues be related to storage device I/Os?
For those ARMv7 devices, which have few substitutes available and not
much computation power, an approach is to work from a x86 machine and
cross-compile disk-images.
We will also have network booting supported soon, which will allow to do
the same, but without having to write an SD card.
In the meantime I would propose to close this bug, as there's not much
that can be done, I think.
Thanks,
Mathieu
Information forwarded
to bug-guix@gnu.org: bug#40626; Package guix.
(Mon, 13 Jul 2020 13:35:02 GMT) (full text, mbox, link).
To: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Cc: 40626@debbugs.gnu.org
Subject: Re: bug#40626: Poor performance on low-end ARMv7 devices
Date: Mon, 13 Jul 2020 15:34:15 +0200
Hi,
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> skribis:
> Many ARM Single Board Computers are commonly used with microSD for
> storage, and some microSD cards are extremely slow (and sometimes
> unreliable when they are old).
>
> Could the performance issues be related to storage device I/Os?
It could be the reason; it’s definitely the case on the board I was
using here.
Still I wonder what could be done on our side to improve on this.
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#40626; Package guix.
(Tue, 14 Jul 2020 04:50:01 GMT) (full text, mbox, link).
On Mon, 13 Jul 2020 15:34:15 +0200
Ludovic Courtès <ludo@gnu.org> wrote:
> Hi,
>
> Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> skribis:
>
> > Many ARM Single Board Computers are commonly used with microSD for
> > storage, and some microSD cards are extremely slow (and sometimes
> > unreliable when they are old).
> >
> > Could the performance issues be related to storage device I/Os?
>
> It could be the reason; it’s definitely the case on the board I was
> using here.
>
> Still I wonder what could be done on our side to improve on this.
I guessed that was the intent.
A way to deal with that could be to validate if it's actually the case,
for instance by installing an SSD, and doing performance comparison
with the time command.
Then if it helps a lot, we probably need to trace the filesystem access
and optimize it somehow. Maybe that can be done with BPF or gprof, but
I never looked into obtimizing I/O performances, so I'm unsure if
that's the right approach. Guile may have profiling tools too.
As for benchmarking the CPU, I've patched phoronix-test-suite in a very
quick and dirty way in Parabola, so we could at least have some
benchmarks. For now we only have "compilation" benchmarks with source
code that should be FSDG compliant.
With it I've found that the compilation performances can vary a lot
between different ARM and x86 boards:
- An I.MX6 Quad with 2G of RAM is about 4.5x faster than the AM335x of a
Beaglebone Green with 512M of RAM.
- A Lime2 A20 is about 1.7x faster than the Beaglebone Green and 2.5x
slower than the board with the I.MX6 Quad.
- My smartphone (Galaxy SIII GT-I9300) is about 2x faster than my server
(PC Engines APU1) for compilation.
Denis.
To: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Cc: 40626@debbugs.gnu.org
Subject: Re: bug#40626: Poor performance on low-end ARMv7 devices
Date: Tue, 14 Jul 2020 15:05:41 +0200
Hi,
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> skribis:
> A way to deal with that could be to validate if it's actually the case,
> for instance by installing an SSD, and doing performance comparison
> with the time command.
>
> Then if it helps a lot, we probably need to trace the filesystem access
> and optimize it somehow. Maybe that can be done with BPF or gprof, but
> I never looked into obtimizing I/O performances, so I'm unsure if
> that's the right approach. Guile may have profiling tools too.
Yeah, the profiles at <https://issues.guix.gnu.org/40626#5> suggest a
couple of things to investigate in Guile.
> As for benchmarking the CPU, I've patched phoronix-test-suite in a very
> quick and dirty way in Parabola, so we could at least have some
> benchmarks. For now we only have "compilation" benchmarks with source
> code that should be FSDG compliant.
>
> With it I've found that the compilation performances can vary a lot
> between different ARM and x86 boards:
> - An I.MX6 Quad with 2G of RAM is about 4.5x faster than the AM335x of a
> Beaglebone Green with 512M of RAM.
> - A Lime2 A20 is about 1.7x faster than the Beaglebone Green and 2.5x
> slower than the board with the I.MX6 Quad.
> - My smartphone (Galaxy SIII GT-I9300) is about 2x faster than my server
> (PC Engines APU1) for compilation.
Interesting, thanks!
Ludo’.
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.