Sage 5.7 on ARM

[Julien Puydt]

Hi,

sage 5.7 compiles on ARM (but libm4rie's conversion.c is still
problematic), and I made a bdist available as
/home/jpuydt/bdist/sage-5.7�armv7l-Linux.tar.gz.

I'll run "make ptestlong" later, and report in this thread.

Snark on #sagemath

[Julien Puydt]

Le 02/03/2013 08:16, Julien Puydt a écrit :
> I'll run "make ptestlong" later, and report in this thread.

Ok, here are the results:
- two gamma-related errors (were already there, don't really hurt)
- a psage failing test (looks horrible)
- a timeout (haven't looked at it yet)

Snark on #sagemath

PS: here are the details:
sage -t --long -force_lib devel/sage/sage/functions/other.py
sage: gamma1(float(6))
Expected:
120.0
Got:
119.99999999999997


sage -t --long -force_lib devel/sage/sage/symbolic/expression.pyx
sage: SR(10.0r).gamma()
Expected:
362880.0
Got:
362880.00000000047


sage -t --long -force_lib devel/sage/sage/interfaces/psage.py
**********************************************************************
File "/home/jpuydt/sage-5.7/devel/sage/sage/interfaces/psage.py", line 37:
sage: print "ignore this"; w # long time, random output
Exception raised:
Traceback (most recent call last):
File "/home/jpuydt/sage-5.7/local/bin/ncadoctest.py", line 1231,
in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/home/jpuydt/sage-5.7/local/bin/sagedoctest.py", line 38,
in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/home/jpuydt/sage-5.7/local/bin/ncadoctest.py", line 1172,
in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_0[5]>", line 1, in <module>
print "ignore this"; w # long time, random output###line 37:
sage: print "ignore this"; w # long time, random output
File
"/home/jpuydt/sage-5.7/local/lib/python/site-packages/sage/misc/displayhook.py",
line 190, in __call__
self.oldhook(obj)
File
"/home/jpuydt/sage-5.7/local/lib/python/site-packages/sage/interfaces/interface.py",
line 880, in __repr__
s = s.replace(self._name, self.__dict__['__custom_name'])
KeyError: '__custom_name'
**********************************************************************

sage -t --long -force_lib
devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py # Time out

[Jeroen Demeyer]

This is a test which sometimes fails. Is it reproducible on ARM?

[leif]

Julien Puydt wrote:
> Le 02/03/2013 08:16, Julien Puydt a �crit :

>> I'll run "make ptestlong" later, and report in this thread.
>

> - a timeout (haven't looked at it yet)

> sage -t --long -force_lib
> devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py # Time out

That's not very surprising, as testing this file doesn't only take
pretty long [now?], but also eats up *a lot* of memory (> 1 GB resident,
at least 1.8 GB virtual IIRC, on Linux x86_64 at least).


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[leif]

leif wrote:
> Julien Puydt wrote:
>> Le 02/03/2013 08:16, Julien Puydt a �crit :
>>> I'll run "make ptestlong" later, and report in this thread.
>>
>> - a timeout (haven't looked at it yet)
>
>> sage -t --long -force_lib
>> devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py #
>> Time out
>
>
> That's not very surprising, as testing this file doesn't only take
> pretty long [now?], but also eats up *a lot* of memory (> 1 GB resident,
> at least 1.8 GB virtual IIRC, on Linux x86_64 at least).

This seems to be a regression introduced in some Sage 5.7.*, but most
probably not by changes to the file itself, but to modules it uses.

Haven't yet retested the file separately, but from ptestlong logs the
test time recently went up from about 70-80 seconds to more than 1000
seconds(!) on my netbook at least (where swapping still isn't an issue).


Sorry for perhaps hijacking your thread...

[John H Palmieri]

On Thursday, March 7, 2013 10:05:05 AM UTC-8, leif wrote:

leif wrote:
> Julien Puydt wrote:

>> Le 02/03/2013 08:16, Julien Puydt a �crit :

>>> I'll run "make ptestlong" later, and report in this thread.
>>
>> - a timeout (haven't looked at it yet)
>
>> sage -t  --long -force_lib
>> devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py #
>> Time out
>
>
> That's not very surprising, as testing this file doesn't only take
> pretty long [now?], but also eats up *a lot* of memory (> 1 GB resident,
> at least 1.8 GB virtual IIRC, on Linux x86_64 at least).

This seems to be a regression introduced in some Sage 5.7.*, but most
probably not by changes to the file itself, but to modules it uses.

Haven't yet retested the file separately, but from ptestlong logs the
test time recently went up from about 70-80 seconds to more than 1000
seconds(!) on my netbook at least (where swapping still isn't an issue).

I don't think it's a regression: there were new tests added to that file in 5.7, and I think they account for the added time. (On my computer, using sage 5.8.beta3 to doctest files in older Sage versions (which I don't think I'm supposed to do): testing the version of this file from the Sage 5.6 library: 30 seconds. Testing this file from the Sage 5.7 library: 300 seconds.)

--
John

[Julien Puydt]

Le 07/03/2013 18:12, Jeroen Demeyer a �crit :

Ah, I had run the test a few times and it was always failing, but this
evening, I saw it pass, and several times too!

I would say there's something fishy in that code if it's that sensitive...

Snark on #sagemath

[Julien Puydt]

Le 07/03/2013 18:24, leif a �crit :

> Julien Puydt wrote:
>> Le 02/03/2013 08:16, Julien Puydt a �crit :
>>> I'll run "make ptestlong" later, and report in this thread.
>>
>> - a timeout (haven't looked at it yet)
>
>> sage -t --long -force_lib
>> devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py #
>> Time out
>
> That's not very surprising, as testing this file doesn't only take
> pretty long [now?], but also eats up *a lot* of memory (> 1 GB resident,
> at least 1.8 GB virtual IIRC, on Linux x86_64 at least).

Indeed that thing also fails on my main (non-ARM) box...

Snark on #sagemath

[leif]

John H Palmieri wrote:
> On Thursday, March 7, 2013 10:05:05 AM UTC-8, leif wrote:
>
> leif wrote:
> > Julien Puydt wrote:

> >> Le 02/03/2013 08:16, Julien Puydt a �crit :
> >>> I'll run "make ptestlong" later, and report in this thread..

> >>
> >> - a timeout (haven't looked at it yet)
> >
> >> sage -t --long -force_lib
> >> devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py #
> >> Time out
> >
> >
> > That's not very surprising, as testing this file doesn't only take
> > pretty long [now?], but also eats up *a lot* of memory (> 1 GB
> resident,
> > at least 1.8 GB virtual IIRC, on Linux x86_64 at least).
>
> This seems to be a regression introduced in some Sage 5.7.*, but most
> probably not by changes to the file itself, but to modules it uses.
>
> Haven't yet retested the file separately, but from ptestlong logs the
> test time recently went up from about 70-80 seconds to more than 1000
> seconds(!) on my netbook at least (where swapping still isn't an

> issue)..

>
>
> I don't think it's a regression: there were new tests added to that file

> in 5.7, and I think they account for the added time.. (On my computer,

> using sage 5.8.beta3 to doctest files in older Sage versions (which I
> don't think I'm supposed to do): testing the version of this file from
> the Sage 5.6 library: 30 seconds. Testing this file from the Sage 5.7
> library: 300 seconds.)

Ok, comparing 5.6.beta3 to 5.7.beta4 *a few* doctests (although marked
"long time") have been added (and between these two releases the test
time differs significantly); I probably should have said "at first
glance" above, as I had only looked at the Mercurial log of that file,
and none of the commit messages seemed related to such.

Anyway, as is, testing the file IMHO takes far too much memory (>= 1 GB
python, and in addition >= 1.4 GB gp, which is used by some tests).

I'll investigate further, especially whether it's really only the added
doctests.

[mmarco]

I have copied this bdist in my android tablet (in a chroot
environment), and it works.

Thanks a lot, Julien.

[Julien Puydt]

Le 08/03/2013 00:21, mmarco a �crit :

> I have copied this bdist in my android tablet (in a chroot
> environment), and it works.

Excellent!

Snark on #sagemath

[Julien Puydt]

Le 07/03/2013 20:15, Julien Puydt a �crit :

What is the point of an automated test which reliably fails on many boxes?

Snark on #sagemath

[Jeroen Demeyer]

On 2013-03-09 09:58, Julien Puydt wrote:
> What is the point of an automated test which reliably fails on many boxes?

It doesn't *reliably* fail, it *rarely* fails.

I think the worst tests in this regard are
* r.py: #9970
* expect.py: #10476

[Julien Puydt]

Le 09/03/2013 10:54, Jeroen Demeyer a �crit :

> On 2013-03-09 09:58, Julien Puydt wrote:
>> What is the point of an automated test which reliably fails on many boxes?
> It doesn't *reliably* fail, it *rarely* fails.

I have three computers here which can't pass that test. Only one of them
is an ARM box : that leaves two boxes where all tests were passing and
which now fail on that file.

What is the turning point where a test is seen as "testing whether the
code is valid" and as "testing whether the box is powerful / has a big
memory" ?

Snark on #sagemath

[Jeroen Demeyer]

On 2013-03-09 17:17, Julien Puydt wrote:
> Le 09/03/2013 10:54, Jeroen Demeyer a �crit :
>> On 2013-03-09 09:58, Julien Puydt wrote:
>>> What is the point of an automated test which reliably fails on many
>>> boxes?
>> It doesn't *reliably* fail, it *rarely* fails.
>
> I have three computers here which can't pass that test.

Really? That's extremely interesting as it would give us a way to
actually debug that issue. You mean that the test literally fails every
time? Details on the systems please.

[leif]

Well, at least testing the whole file is likely to time out on slow (or
heavily loaded) machines. The user could of course increase
SAGE_TIMEOUT[_LONG] on such, but to me that doesn't make much sense when
(almost) all other files don't need that, because then speed (not
necessarily performance) regressions get harder to notice.

More importantly, about three (I think^TM) of the added twelve tests /
test lines will fail if the system doesn't have enough resources (i.e.,
memory), perhaps limited by 'ulimit' or in a VM. And these tests
consume *much* more memory (python *and* gp) than most of all other tests.

I remember tickets (or patches) had been rejected in the past because
their doctests took too much time and/or memory, so w.r.t. this, it can
be considered a regression.

IMHO doctesting the whole Sage installation isn't much different to
building the docs (which one could by the way easily grab from somewhere
else), i.e., we shouldn't require (much) more RAM for the former than
for the latter. (And IIRC you complained about Sphinx needing too much
memory for building some of the docs.)

[Julien Puydt]

Le 10/03/2013 10:51, Jeroen Demeyer a �crit :

The most promising is:
(1) /proc/cpuinfo says AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
(2) /proc/meminfo says: MemTotal: 1995288 kB

and I have noticed that while I run:
./sage -t --long -force_lib
devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py

looking at "top" with 'M' as sort key, I don't see anything unusual :
the memory isn't full, the load doesn't go through the roof, I don't see
anything abnormal.

It looks like the test just sits there... until it gets killed by the
timeout.

Snark on #sagemath

[leif]

Julien Puydt wrote:
> Le 10/03/2013 10:51, Jeroen Demeyer a �crit :
>> On 2013-03-09 17:17, Julien Puydt wrote:
>>> Le 09/03/2013 10:54, Jeroen Demeyer a �crit :
>>>> On 2013-03-09 09:58, Julien Puydt wrote:
>>>>> What is the point of an automated test which reliably fails on many
>>>>> boxes?
>>>> It doesn't *reliably* fail, it *rarely* fails.
>>>
>>> I have three computers here which can't pass that test.
>> Really? That's extremely interesting as it would give us a way to
>> actually debug that issue. You mean that the test literally fails every
>> time? Details on the systems please.
>
> The most promising is:
> (1) /proc/cpuinfo says AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
> (2) /proc/meminfo says: MemTotal: 1995288 kB
>
> and I have noticed that while I run:

> ../sage -t --long -force_lib

> devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py
>
> looking at "top" with 'M' as sort key, I don't see anything unusual :
> the memory isn't full, the load doesn't go through the roof, I don't see
> anything abnormal.
>
> It looks like the test just sits there... until it gets killed by the
> timeout.

Strange. That's apparently a different issue, or maybe in addition your
top / xload / whatever are broken...

You may try to run some lines of the tests in an interactive Sage
session and see what happens, perhaps after first running the doctests
with --verbose (although output is currently not flushed properly).


In any case, as is, 2 GB are certainly not enough to run the (long)
doctests of that file.

[Julien Puydt]

Le 13/03/2013 10:41, leif a �crit :

> You may try to run some lines of the tests in an interactive Sage
> session and see what happens, perhaps after first running the doctests
> with --verbose (although output is currently not flushed properly).

I have seen strange things.

First, sometimes, I don't get a timeout: it ends (in less than five
minutes), but some tests fail.

Second, what are the failure when it doesn't get stuck?

Here is one trace:

Exception raised:
Traceback (most recent call last):
File

"/home/jpuydt/sage-5.7-x86_64-Linux/local/bin/ncadoctest.py", line 1231,

in run_one_test
self.run_one_example(test, example, filename, compileflags)
File

"/home/jpuydt/sage-5.7-x86_64-Linux/local/bin/sagedoctest.py", line 38,

in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File

"/home/jpuydt/sage-5.7-x86_64-Linux/local/bin/ncadoctest.py", line 1172,

in run_one_example
compileflags, 1) in test.globs

File "<doctest __main__.example_2[18]>", line 1, in <module>
any( eval_v_cython(*v) == Integer(2) * Integer(22955664) for v
in vec_list ) # 22955664 > 22953421 = len_bound #long time###line
219:_sage_ sage: any( eval_v_cython(*v) == 2 * 22955664 for v in
vec_list ) # 22955664 > 22953421 = len_bound #long time
File "<doctest __main__.example_2[18]>", line 1, in <genexpr>
any( eval_v_cython(*v) == Integer(2) * Integer(22955664) for v
in vec_list ) # 22955664 > 22953421 = len_bound #long time###line
219:_sage_ sage: any( eval_v_cython(*v) == 2 * 22955664 for v in
vec_list ) # 22955664 > 22953421 = len_bound #long time
NameError: global name 'eval_v_cython' is not defined


and here is another:

Exception raised:
Traceback (most recent call last):
File

"/home/jpuydt/sage-5.7-x86_64-Linux/local/bin/ncadoctest.py", line 1231,

in run_one_test
self.run_one_example(test, example, filename, compileflags)
File

"/home/jpuydt/sage-5.7-x86_64-Linux/local/bin/sagedoctest.py", line 38,

in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File

"/home/jpuydt/sage-5.7-x86_64-Linux/local/bin/ncadoctest.py", line 1172,

in run_one_example
compileflags, 1) in test.globs

File "<doctest __main__.example_2[17]>", line 1, in <module>
eval_v_cython = cython_lambda( ", ".join( "int a{0}".format(i)
for i in range(Integer(2)) ), " + ".join( "{coeff} * a{i} *
a{j}".format(coeff = mat[i,j], i = i, j = j) for i in range(Integer(2))
for j in range(Integer(2)) ) ) #long time###line 218:_sage_ sage:
eval_v_cython = cython_lambda( ", ".join( "int a{0}".format(i) for i in
range(2) ), " + ".join( "{coeff} * a{i} * a{j}".format(coeff = mat[i,j],
i = i, j = j) for i in range(2) for j in range(2) ) ) #long time
File
"/home/jpuydt/sage-5.7-x86_64-Linux/local/lib/python/site-packages/sage/misc/cython.py",
line 661, in cython_lambda
create_local_c_file=False)
File
"/home/jpuydt/sage-5.7-x86_64-Linux/local/lib/python/site-packages/sage/server/support.py",
line 473, in cython_import_all
create_local_c_file=create_local_c_file)
File
"/home/jpuydt/sage-5.7-x86_64-Linux/local/lib/python/site-packages/sage/server/support.py",
line 450, in cython_import
**kwds)
File
"/home/jpuydt/sage-5.7-x86_64-Linux/local/lib/python/site-packages/sage/misc/cython.py",
line 496, in cython
log = open('%s/log'%build_dir).read()
IOError: [Errno 2] No such file or directory:
'/home/jpuydt/.sage/temp/newton/10029/spyx/_home_jpuydt__sage_temp_newton_10029_tmp_xXPiqf_spyx/log'


As far as I know, what happens in .sage/temp/newton/<pid> is that some
functions get compiled on the fly, and the two traces seem to mean
something goes wrong there. The fact that sometimes I get a timeout on
the file could also be a case of that.

Does that make someone go "Oooooohhhh!" ?

> In any case, as is, 2 GB are certainly not enough to run the (long)
> doctests of that file.

That is a lot of memory. Can't those tests be modified to need less?

Snark on #sagemath