Carl Witty does Sage on the G1

"the entire compile took 20943 minutes of real time (about
14.5 days)"

This is just heroic, borderline legendary: compiling Sage on the Android G1. There is nothing to be done but read the post from sage-devel and see the picture.

I have compiled and run Sage 3.2.3 on my T-Mobile G1 cell phone, and
large portions of it actually work.

300 files had failing doctests; this means that all doctests passed in
864 files. A lot of the failing doctests are with pexpect (maxima,
gap, etc.); I don't know why these fail. When I try simple things
with gap and maxima, they do work. Many more tests fail due to
timeouts; the 300-second timeout is far too short for the G1.
(Doctesting any file with doctests takes >50 seconds; doctesting a
file with no doctests takes >4 seconds. The entire doctest run took
270724 seconds, or a little over 3 days.)

Unfortunately, it's far too slow to be useful for anything (just
starting Sage takes about a minute, if there's enough free memory; but
since Android likes to keep the memory full all the time, there never
is enough free memory, and it takes much longer to start). So I don't
plan to do anything further with the project.

Of course, the sensible way to do this is to find some nice fast
computer and set up a cross-compiler. I didn't do this the sensible
way; I actually did the build on the cell phone. And of course, the
build would stop every once in a while due to a bug, which I would
then patch around. So, adding up the 14 chunks of compilation
involved, the entire compile took 20943 minutes of real time (about
14.5 days) and 9438 minutes (about 6.5 days) of CPU time. You'll note
that the CPU time adds up to less than half of the real time; most of
the rest of the time was spent swapping. The G1 has about 100MB of
RAM; I set up a swap file on my micro-SD card, to allow the build to
proceed at all. On several files, the compiler uses more than 300MB.
While compiling those files, the CPU is typically less than 1% active;
I'm pretty sure that there were files that took more than a day to
compile. The phone was essentially unusable for smartphone activities
(web browsing, etc.) while the build was running. In fact, the whole
smartphone UI crashed and restarted on a fairly regular basis during
the build (I'm guessing it has some sort of watchdog timer and reboots
itself if it detects that some operation is taking an unreasonably
long time), but the build just continued anyway (running inside a
screen session).

The ATLAS tuning process took about 3.2 days (with almost as much CPU
time as real time; that didn't swap much). Skimming through the logs,
I see reports of numbers like 3 to 6 MFLOPs.

The build was performed inside a Debian armel testing chroot; it's
pretty nice being able to run real Debian on my cell phone.
(Everything works; I can ssh in and out, etc., although when it's on
the cell phone network, inbound connections are problematic because
it's behind a NAT.)

To make the whole project even more pointless, since the phone is
running real Debian (inside the chroot), I can probably just wait a
few weeks or months for Tim Abbott to get all the portability issues
fixed in the sagemath Debian package, and then install Sage on the
phone with apt-get.

Here's the processor:

cwitty@localhost:/tmp$ cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 2 (v6l)
BogoMIPS : 383.38
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant : 0x1
CPU part : 0xb36
CPU revision : 2
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 32768
I assoc : 4
I line length : 32
I sets : 256
D size : 32768
D assoc : 4
D line length : 32
D sets : 256

Hardware : trout
Revision : 0080
Serial : 0000000000000000

Carl