Hi Nick,
thanks for looking into it. It's great to see Rakudo on more small devices.
Am 30.07.2012 10:30, schrieb Nicholas Clark:
With QAST and PIRT merged, I can build Rakudo on a Raspberry Pi in about 12
hours, albeit with a lot of swapping (to a real disk)
This was NQP at 6bd8bc5eb0f7cd29, Rakudo at c1bfbbb233c86036.
On Thu, Jun 28, 2012 at 09:49:32PM +0100, Nicholas Clark wrote:
Still need this:
It seems that dyncall doesn't recognise arm6el as a class of ARM architecture
which it supports. Given that it supports iOS, and has a configure option for
ARM, it seems pretty clear that it does, so I bodged it this this:
nick@raspberrypi ~/Perl/rakudo/nqp $ git diff
diff --git a/Configure.pl b/Configure.pl
index 5539471..f1a1c00 100644
--- a/Configure.pl
+++ b/Configure.pl
@@ -125,7 +125,7 @@ MAIN: {
system_or_die('cd 3rdparty\dyncall && Configure.bat' .
$configure_a
$config{'dyncall_build'} = "cd 3rdparty/dyncall && $make
BUILD_DIR=
} else {
- system_or_die('cd 3rdparty/dyncall && sh configure');
+ system_or_die('cd 3rdparty/dyncall && sh configure --target-arm-arm
if ($^O eq 'netbsd') {
$config{'dyncall_build'} = "cd 3rdparty/dyncall && BUILD_DIR=.
} else {
I guess we should take that upstream to the dyncall folks.
Still see this, and I really don't have time to dig into it:
NQP fails 1 test:
Test Summary Report
-------------------
t/nqp/60-bigint.t (Wstat: 0 Tests: 34 Failed: 3)
Failed tests: 28-29, 34
Files=64, Tests=584, 773 wallclock secs ( 5.03 usr 0.61 sys + 751.26 cusr
11.36 csys = 768.26 CPU)
This might very well be related to some bit fiddling in our own bigint
ops, which were done by somebody with no experience whatsoever on
bigendian platforms (me).
Still need this:
So, I commandeered a mobile phone charger to power an external USB hard drive,
and now with 512Mb of swap tried this:
$ /usr/bin/time -v ./perl6 --setting=NULL --optimize=3 --target=pir
--stagestats --output=src/gen/CORE.setting.pir src/gen/CORE.setting; sleep 30;
killall vmstat
Stage parse: 52535.669
Stage syntaxcheck: 0.387
Stage past: 0.221
Stage optimize: 9936.757
So those were the times a month ago. Following Jonathan's excellent work on
QAST and PIRT, the numbers now are:
The following step can take a long time, please be patient.
./perl6 --setting=NULL --optimize=3 --target=pir --stagestats --output=src/gen/C
ORE.setting.pir src/gen/CORE.setting
Stage start : 0.000
Stage parse : 5220.855
Stage syntaxcheck: 0.048
Stage past : 0.015
Stage optimize : 14076.714
Stage post : 11584.416
Stage pir : 1077.496
The relative time breakdown is interesting. Here's the output on an 8Gb
FreeBSD machine, which (probably) isn't swapping:
Stage start : 0.000
Stage parse : 258.672
Stage syntaxcheck: 0.000
Stage past : 0.000
Stage optimize : 10.648
Stage post : 88.219
Stage pir : 20.760
Note how "parse" is roughly twice the time of everything else. Whereas on
the Raspberry Pi, "otimize" is almost 3 times as bad as "parse", "post"
twice as bad, and even "pir" is 20% of it. I observed that vmstat was
showing only about 80% of time consumed by swapping at the end of "parse",
whereas as soon as "optimize" started it was 99% swap hell. Jonathan
commented on IRC that this will be because the optimiser is running all over
the parse tree in memory.
Even watching memory consumption on a non-swapping machine shows that it
grows significantly after stage parse, which is very much consistent
with your observation.
I didn't log enough to get the stat reliably, but maximum swap usage I could
spot in screen's scrollback of vmstat was 314792K, which seems plausible.
>
[Oh, "bug" report - the formatting assumes that no stage takes more than 999
seconds. That's two orders of magnitude optimistic :-)]
Cheers,
Moritz
