#6750: [with spkg, needs review] New version of optional Group Cohomology spkg
-------------------------------+--------------------------------------------
Reporter: SimonKing | Owner: SimonKing
Type: enhancement | Status: assigned
Priority: major | Milestone:
Component: optional packages | Keywords: cohomology ring p-group
Reviewer: | Author: Simon King
Merged: |
-------------------------------+--------------------------------------------
Comment(by SimonKing):
It turned out that building libmtx.a twice was an artifact of my previous
attempts to find a proper optimization.
My test case: Compute the cohomology for all groups of order 64 from
scratch, and compare with the known result.
I tested it with four different package versions. In all cases, I was
first building libmtx.a with -O1, so that David's executables work. Then,
I built libmtx.a again, with -O0, -O1, -O2, -O3, and -Os. Note that the
Cython extensions are build with -O3 anyway.
In Galway (Intel Core Duo) and on sage.math, I got the following CPU
times:
* -O0, Galway: 18.73 min, sage.math: 29.73 min
* -O1, Galway: 18.32 min, sage.math: 27.76 min
* -O2, Galway: 18.31 min, sage.math: 28.70 min
* -O3, Galway: 18.48 min, sage.math: 29.20 min
* -Os, Galway: 18.74 min, sage.math: not finished yet.
This indicates that indeed a thorough -O1 optimization is good, perhaps
best.
I got similar results a few months ago. So, the logical consequence should
have been to build libmtx.a only once, namely with -O1. But then I forgot
to remove the double build approach.
'''Summary'''
Updated spkg is at
[http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-1.1.spkg]
The build process is now probably cleaner, namely searching for
database_gap both in spkg/optional and spkg/installed, and building
libmtx.a only once. I hope that the problems on MacBook, where the
resource libmtx.a wasn't available, are resolved by now.
I use this occasion for another change: The "public cohomology data base",
that is shared by all users of a Sage install, is now located in
SAGE_DATA/pGroupCohomology/, rather than in
SAGE_ROOT/local/pGroupCohomology/db. William wrote on sage-devel that this
is a better location. I guess so far I am the only user who really did
extensive computations with the package. So, I think there is no need for
a warning message concerning the potential need of relocating the user's
data.
John, of course I'd appreciate if you could try it on your Intel Mac
again. Since the build process changed, I am now asking William whether he
thinks that a thorough test (on all machines in William's park) is needed.
Cheers,
Simon
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6750#comment:21>
Sage <http://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
-~----------~----~----~----~------~----~------~--~---
