Le 19/08/2013 17:08, William Stein a écrit :
> Hi,
>
> For anybody reading this thread, a reminder about how to use the
> systemwide ATLAS (at least on Ubuntu 12.04 LTS). Just do this before
> building Sage:
>
> apt-get install libatlas3gf-base liblapack-dev
> cd /usr/lib/
>
On 19 August 2013 16:08, William Stein wrote:
> Hi,
>
> For anybody reading this thread, a reminder about how to use the
> systemwide ATLAS (at least on Ubuntu 12.04 LTS). Just do this before
> building Sage:
>
> apt-get install libatlas3gf-base liblapack-dev
> cd /usr/lib/
>
Hi,
For anybody reading this thread, a reminder about how to use the
systemwide ATLAS (at least on Ubuntu 12.04 LTS). Just do this before
building Sage:
apt-get install libatlas3gf-base liblapack-dev
cd /usr/lib/
ln -s libatlas.so.3gf libatlas.so
ln -s libcbla
I am worried about that message "Architecture configured as HAMMER
(32)" since wikipedia tells me that Hammer was the name of an AMD
processor released in 2003. The actual cpuinfo is
vendor_id : AuthenticAMD
cpu family : 21
model : 2
model name : AMD Opteron(tm) Processor 6380
stepping : 0
micro
My atlas build did finish ok in 5h++ so I am letting the rest of the
build finish before seeing what the new spkg does.
real 322m12.706s
user 303m50.211s
sys 21m50.834s
Successfully installed atlas-3.10.1.p3
OK, it has now finished and Sage runs fine. But it would be nice not
to have to wait ano
On 08/19/2013 04:25 PM, Volker Braun wrote:
Yes, shoud be fixed by http://trac.sagemath.org/ticket/15045
Confirmed: the build with
sage -f
http://boxen.math.washington.edu/home/vbraun/spkg/atlas-3.10.1.p4.spk
has just succeeded.
Thanks,
Christian
--
You received this message because y
Yes, shoud be fixed by http://trac.sagemath.org/ticket/15045
On Monday, August 19, 2013 2:47:41 PM UTC+1, Christian Nassau wrote:
>
> On 08/19/2013 03:30 PM, Volker Braun wrote:
> > Can you post the ATLAS bulid log, not the whole log that has
> > everything munged together?
>
> Here it is: ht
On Monday, August 19, 2013 3:05:02 PM UTC+1, John Cremona wrote:
> I could try that (though my log file has no occurrence of
> ATL_SetAtomicCount). Would that mean to kill the build under way with
> Ctrl-C and then install the alternative spkg as above?
>
The new spkg is not faster in any way
On 19 August 2013 15:05, John Cremona wrote:
> On 19 August 2013 14:43, Volker Braun wrote:
>> On Monday, August 19, 2013 2:33:52 PM UTC+1, John Cremona wrote:
>>>
>>> I don't know how to extract that from the munged version (which is
>>> still being written to).
>>
>>
>> $SAGE_ROOT/logs/pkgs/atl
On 19 August 2013 14:43, Volker Braun wrote:
> On Monday, August 19, 2013 2:33:52 PM UTC+1, John Cremona wrote:
>>
>> I don't know how to extract that from the munged version (which is
>> still being written to).
>
>
> $SAGE_ROOT/logs/pkgs/atlas-3.10.1.p3.log
>
Here's mine (so far): http://ferm
On 08/19/2013 03:30 PM, Volker Braun wrote:
Can you post the ATLAS bulid log, not the whole log that has
everything munged together?
Here it is: http://nullhomotopie.de/atlas-3.10.1.p3.log.gz
Cheers,
Christian
--
You received this message because you are subscribed to the Google Groups
"sag
On Monday, August 19, 2013 2:33:52 PM UTC+1, John Cremona wrote:
> I don't know how to extract that from the munged version (which is
> still being written to).
>
$SAGE_ROOT/logs/pkgs/atlas-3.10.1.p3.log
> > Also, please try
> anything!
>
I meant:
sage
-f http://boxen.math.washington.ed
On 19 August 2013 14:30, Volker Braun wrote:
> Can you post the ATLAS bulid log, not the whole log that has everything
> munged together?
I don't know how to extract that from the munged version (which is
still being written to).
>
> Also, please try
>
anything!
John
> On Monday, August 19, 2
On 19 August 2013 14:23, Volker Braun wrote:
> Without the new atlas you won't be able to use AVX so that shiny new CPU
> will not get even close to maximum floating point performance.
>
> If you just want to compile Sage quickly then use an atlas that you compile
> once (or your OS version) and s
Can you post the ATLAS bulid log, not the whole log that has everything
munged together?
Also, please try
On Monday, August 19, 2013 1:30:01 PM UTC+1, Christian Nassau wrote:
>
> The full build log is at
>
> http://nullhomotopie.de/sage512build.log.gz
>
> Cheers,
> Christian
>
--
You
Without the new atlas you won't be able to use AVX so that shiny new CPU
will not get even close to maximum floating point performance.
If you just want to compile Sage quickly then use an atlas that you compile
once (or your OS version) and set SAGE_ATLAS_LIB when building Sage.
--
You re
On 19 August 2013 13:18, Jeroen Demeyer wrote:
> On 08/19/2013 02:01 PM, John Cremona wrote:
>>
>> That seems a real killer to me. Nice new machine, lots of cores able
>> to build Sage-5.11 in about 20 minutes, suddenly goes up to infinity
>> with 5.12.beta1?
>
> Just to understand you better and
On 08/19/2013 02:34 PM, Jeroen Demeyer wrote:
This looks like http://trac.sagemath.org/ticket/15045
Two questions:
1. Can you give details on the CPU please?
2. Is this a reproducible problem, does it occur every time you try to
build ATLAS?
So far I tried to build two or three times, and it
On 08/19/2013 02:30 PM, Christian Nassau wrote:
g++ -g -c cf_algorithm.cc -Wall -fno-implicit-templates -I. -I.. -I.
-I/waste/cn/sage-5.12.beta0/local
-I/waste/cn/sage-5.12.beta0/local/include -DHAVE_CONFIG_H
-I/waste/cn/sage-5.12.beta0/local/include
-I/waste/cn/sage-5.12.beta0/local/include -o
On 08/19/2013 01:36 PM, John Cremona wrote:
What would make atlas suddenly decide to start running its tuning code
(building 5.12.beta1) on a machine which a few days ago built 5.11
without that happening? It's frustrating since even though I am using
make -j32 the tuning code is taking forever.
On 08/19/2013 02:01 PM, John Cremona wrote:
That seems a real killer to me. Nice new machine, lots of cores able
to build Sage-5.11 in about 20 minutes, suddenly goes up to infinity
with 5.12.beta1?
Just to understand you better and not judging you: why is it a "real
killer"? Why does it matter
On 19 August 2013 12:56, Jeroen Demeyer wrote:
> On 08/19/2013 01:36 PM, John Cremona wrote:
>>
>> What would make atlas suddenly decide to start running its tuning code
>> (building 5.12.beta1) on a machine which a few days ago built 5.11
>> without that happening?
>
> The ATLAS update at #14754.
On 08/19/2013 01:36 PM, John Cremona wrote:
What would make atlas suddenly decide to start running its tuning code
(building 5.12.beta1) on a machine which a few days ago built 5.11
without that happening?
The ATLAS update at #14754.
--
You received this message because you are subscribed to th
What would make atlas suddenly decide to start running its tuning code
(building 5.12.beta1) on a machine which a few days ago built 5.11
without that happening? It's frustrating since even though I am using
make -j32 the tuning code is taking forever...
Would killing the make and rerunning it sa
24 matches
Mail list logo