#9497: Fix the Singular spkg so it can take advantage of building in parallel
----------------------------------------------+-----------------------------
Reporter: was | Owner: GeorgSWeber
Type: enhancement | Status: needs_review
Priority: minor | Milestone: sage-4.7
Component: build | Keywords: singular
Author: Martin Albrecht, John Palmieri | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
----------------------------------------------+-----------------------------
Comment(by drkirkby):
Replying to [comment:8 jhpalmieri]:
> Dave: the test seems to have succeeded: each of the 100 builds reported
building successfully. I suppose to really test it, I should run full
doctests after each build, but I didn't do that.
I think {{{singular-3-1-1-4.p6}}} is OK, but I'll wait about 12 hours
before giving a positive review. That will give my tests more chance to
run. I've done some longer random delays than you, which will have more
chance of finding a bug, but due to the build times, it is not possible to
build so many of these.
I think the doctest idea, whilst nice, would take too long. It would
probably not be
necessary to run all the doctests, though sorting out what ones are
necessary would be difficult.
What would be useful, (and practical) is to compare the sizes of the
libraries created each time. They appear to be identical. Unfortunately
the md5 checksums of the files do change each time - I guess there is
date/time information in them, which is not identical on each build. But I
think if a package builds multiple times and the files built were always
of the same length, we could be reasonably sure they are OK. I've just
implemented such a change to {{{new.sh}}}, though this is only in use on
the code which has random delays of up to 5 seconds.
I think long random delays is the most likely way to find race conditions,
but of course the builds take a lot longer. But there's no problem in
building in many directories at the same time. If one builds Singular in N
different directories with Sage in them, with a maximum delay of T seconds
(mean T/2) in each directory, the mean delay is going to be T/(2*N)
seconds. The fact the delays are present should mean building lots of
copies of Singular at the same time does not overload the CPU. Memory
might be an issue though - this machine only has 12 GB. Technically that's
the maximum supported RAM in this Sun workstation, though in fact it is
possible to get 3^rd^ party 4 GB DIMMS to fit, so putting 24 GB in the
machine is technically possible, though quite costly for a home computer.
Anyway, I'll look at the test results in 12 hours or so, and unless I find
any failures, I'll be giving the {{{singular-3-1-1-4.p6}}} package a
positive review.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9497#comment:9>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
