Re: [sage-devel] git fetch warning about /home/erik_m_bray

2016-10-05 Thread Daniel Krenn 
On 2016-10-05 17:12, Erik Bray wrote:
> On Wed, Oct 5, 2016 at 4:58 PM, Erik Bray  wrote:
>> On Wed, Oct 5, 2016 at 12:26 PM, Jeroen Demeyer  
>> wrote:
>>> When running "git fetch", I get
>>>
>>> remote: warning: unable to access
>>> '/home/erik_m_bray/.config/git/attributes': Permission denied
>>
>> Confirmed--this is only for git:// too.  I was the last person to
>> restart git-daemon on the server.  But I feel like that was over a
>> week ago.  Also it runs as user 'git' not me, obviously, so I don't
>> know why it's trying to read something (which doesn't exist) from my
>> home directory.
> 
> Fixed.  I think this is a bug in git-daemon and/or Ubuntu's init
> script for it.  It tries at some point to read a git configuration in
> someone's home directory, but rather than use the home directory of
> the user it's actually running as, it apparently uses the value of
> $HOME.  On Ubuntu the default sudo behavior is to preserve the
> original user's $HOME, hence it trying to use mine.

Thanks. Fix confirmed.

Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] git fetch warning about /home/erik_m_bray

2016-10-05 Thread Erik Bray 
On Wed, Oct 5, 2016 at 5:12 PM, Erik Bray  wrote:
> On Wed, Oct 5, 2016 at 4:58 PM, Erik Bray  wrote:
>> On Wed, Oct 5, 2016 at 12:26 PM, Jeroen Demeyer  
>> wrote:
>>> When running "git fetch", I get
>>>
>>> remote: warning: unable to access
>>> '/home/erik_m_bray/.config/git/attributes': Permission denied
>>
>> Confirmed--this is only for git:// too.  I was the last person to
>> restart git-daemon on the server.  But I feel like that was over a
>> week ago.  Also it runs as user 'git' not me, obviously, so I don't
>> know why it's trying to read something (which doesn't exist) from my
>> home directory.
>
> Fixed.  I think this is a bug in git-daemon and/or Ubuntu's init
> script for it.  It tries at some point to read a git configuration in
> someone's home directory, but rather than use the home directory of
> the user it's actually running as, it apparently uses the value of
> $HOME.  On Ubuntu the default sudo behavior is to preserve the
> original user's $HOME, hence it trying to use mine.

Well the git-daemon man page is at least explicit about this:

```
--user=--group=

Change daemon’s uid and gid before entering the service loop. When
only --user is given without --group, the primary group ID for the
user is used. The values of the option are given to getpwnam(3)and
getgrnam(3) and numeric IDs are not supported.

Giving these options is an error when used with --inetd; use the
facility of inet daemon to achieve the same before spawning git daemon
if needed.

Like many programs that switch user id, the daemon does not reset
environment variables such as$HOME when it runs git programs, e.g.
upload-pack and receive-pack. When using this option, you may also
want to set and export HOME to point at the home directory of 
before starting the daemon, and make sure any Git configuration files
in that directory are readable by .
```

Ubuntu's init script for it doesn't set HOME properly so I guess that's it.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] git fetch warning about /home/erik_m_bray

2016-10-05 Thread Erik Bray 
On Wed, Oct 5, 2016 at 4:58 PM, Erik Bray  wrote:
> On Wed, Oct 5, 2016 at 12:26 PM, Jeroen Demeyer  
> wrote:
>> When running "git fetch", I get
>>
>> remote: warning: unable to access
>> '/home/erik_m_bray/.config/git/attributes': Permission denied
>
> Confirmed--this is only for git:// too.  I was the last person to
> restart git-daemon on the server.  But I feel like that was over a
> week ago.  Also it runs as user 'git' not me, obviously, so I don't
> know why it's trying to read something (which doesn't exist) from my
> home directory.

Fixed.  I think this is a bug in git-daemon and/or Ubuntu's init
script for it.  It tries at some point to read a git configuration in
someone's home directory, but rather than use the home directory of
the user it's actually running as, it apparently uses the value of
$HOME.  On Ubuntu the default sudo behavior is to preserve the
original user's $HOME, hence it trying to use mine.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] git fetch warning about /home/erik_m_bray

2016-10-05 Thread Erik Bray 
On Wed, Oct 5, 2016 at 12:26 PM, Jeroen Demeyer  wrote:
> When running "git fetch", I get
>
> remote: warning: unable to access
> '/home/erik_m_bray/.config/git/attributes': Permission denied

Confirmed--this is only for git:// too.  I was the last person to
restart git-daemon on the server.  But I feel like that was over a
week ago.  Also it runs as user 'git' not me, obviously, so I don't
know why it's trying to read something (which doesn't exist) from my
home directory.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] git fetch warning about /home/erik_m_bray

2016-10-05 Thread Daniel Krenn 
On 2016-10-05 12:26, Jeroen Demeyer wrote:
> When running "git fetch", I get
> 
> remote: warning: unable to access
> '/home/erik_m_bray/.config/git/attributes': Permission denied

I get the same.

(posted at
https://groups.google.com/d/msg/sage-release/gPJzDIKgkbM/vpmw872OCQAJ)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] hash of QQbar inefficient

2016-10-05 Thread Clemens Heuberger 

Hi,

Am 2016-10-05 um 01:33 schrieb Thierry:
> Could you reproduce your issue with sufficiently enough other polynomials
> or is it just that one ?

I can offer to more such polynomials:

x = polygen(QQ, 'x')
rho1 = QQbar.polynomial_root(x^7 + 37985/2366*x^6 + 116073/2366*x^5 -
34406/1183*x^4 + 13707/2366*x^3 - 1299/2366*x^2 + 29/1183*x - 1/2366,
CIF(RIF(0.04, 0.05), RIF(-0.02, -0.01)))

rho2 = QQbar.polynomial_root(x^7 - 481/816*x^6 + 2198345/15092736*x^5 -
226333/11319552*x^4 + 72937/45278208*x^3 - 193/2515456*x^2 + 5/2515456*x -
1/45278208,
CIF(RIF(0.03, 0.04), RIF(-0.02, -0.01)))

Computation of the hash takes very long (I stopped after a few minutes);
changing QQbar_hash_offset leads to an immediate answer.

Best regards,

Clemens

> 
> Ciao,
> Thierry
> 
> 
> 
> 
> On Tue, Oct 04, 2016 at 07:57:37PM +0800, Clemens Heuberger wrote:
>> Hashing of QQbar elements seems to be quite inefficient:
>>
>> sage: R. = AA[]
>> sage: rho = QQbar.polynomial_root(
>> : x^5 - 1/3*x^4 + 1/30*x^3 - 1/600*x^2 + 1/24000*x - 1/240,
>> : CIF(RIF(0.02, 0.03), RIF(-0.009, -0.007)))
>> sage: %time hash(rho)
>> CPU times: user 14 s, sys: 36 ms, total: 14.1 s
>> Wall time: 14 s
>> -382033038487191199
>> sage: %time hash(rho)
>> CPU times: user 9.18 s, sys: 32 ms, total: 9.21 s
>> Wall time: 9.12 s
>> -382033038487191199
>>
>> It seems that the hashing code at some stage exactifies the rho.imag() 
>> (which is
>> an algebraic number of degree 20).
>>
>> In qqbar.py, we have the comment
>>
>> # All of this effort to avoid exact computation is probably wasted,
>> # anyway... in almost all uses of hash codes, if the hash codes
>> # match, the next step is to compare for equality; and comparing
>> # for equality often requires exact computation. (If a==b,
>>
>> However, IMHO, the unfortunate thing is that rho.real() and rho.imag() are
>> exactified instead of rho itself (so involving higher degree numbers) and 
>> that
>> these results are then lost.
>>
>> Any thoughts?
>>
>> Regards,
>>
>> Clemens
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-devel@googlegroups.com.
>> Visit this group at https://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
> 


-- 
Univ.-Prof. Dr. Clemens HeubergerAlpen-Adria-Universität Klagenfurt
Institut für Mathematik, Universitätsstraße 65-67, 9020 Klagenfurt, Austria
Tel: +43 463 2700 3121Fax: +43 463 2700 99 3121
clemens.heuber...@aau.athttp://wwwu.aau.at/cheuberg

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] git fetch warning about /home/erik_m_bray

2016-10-05 Thread Jeroen Demeyer 

When running "git fetch", I get

remote: warning: unable to access 
'/home/erik_m_bray/.config/git/attributes': Permission denied


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] multithreading performance issues

2016-10-05 Thread Clement Pernet 

To follow up on Jean-Pierre summary of the situation:

The current version of fflas-ffpack in sage (v2.2.2) uses the BLAS provided as is. Running it with a 
multithreaded BLAS may result in a slower code than with a single threaded BLAS. This is very likely 
due to memory transfer and coherence problems.


More generally, we strongly suggest to use a single threaded BLAS and let fflas-ffpack deal with the 
parallelization. This is common practice for example with parallel versions of LAPACK.


Therefore, after the discussion https://trac.sagemath.org/ticket/21323 we have decided to let 
fflas-ffpack the possibility to force the number of threads that OpenBLAS can use at runtime. In 
this context we will force it to 1.

This is available upsteam and I plan to update sage's fflas-ffpack whenever we 
release v2.3.0.

Clément

Le 05/10/2016 à 11:24, Jean-Pierre Flori a écrit :

Currently OpenBlas does what it wants for multithreading.
We hesitated to disable it but prefered to wait and think about it:
see https://trac.sagemath.org/ticket/21323.

You can still influence its use of threads setting OPENBLAS_NUM_THREADS.
See the trac ticket, just note that this is not Sage specific.
And as you discovered, it seems it is also influenced by OMP_NUM_THREADS...

On Wednesday, October 5, 2016 at 9:28:23 AM UTC+2, tdumont wrote:

What is the size of the matrix you use ?
Whatever you do, openmp in blas is interesting only if you compute with
large matrices.
If your computations are embedded  in an @parallel and launch n
processes, be careful  that your  OMP_NUM_THREADS be less or equal to
ncores/n.

My experience is (I am doing numerical computations)  that there are
very few cases where using openmp in blas libraries is interesting.
Parallelism should generally be searched at a higher level.

One of the interest of multithreaded blas is for constructors: with
Intel's mkl blas, you can obtain the maximum possible performances of
tah machines  when you use DGEMM (ie product of matrices), due to the
high arithmetic intensity of matrix vector products. On my 2x8 core
sandy bridge à 2.7GHZ, I have obtained more that 300 giga flops, but
with matrices of size > 1000 ! And this is only true for DGEMM

t.d.

Le 04/10/2016 à 20:26, Jonathan Bober a écrit :
> See the following timings: If I start Sage with OMP_NUM_THREADS=1, a
> particular computation takes 1.52 cpu seconds and 1.56 wall seconds.
>
> The same computation without OMP_NUM_THREADS set takes 12.8 cpu seconds
> and 1.69 wall seconds. This is particularly devastating when I'm running
> with @parallel to use all of my cpu cores.
>
> My guess is that this is Linbox related, since these computations do
> some exact linear algebra, and Linbox can do some multithreading, which
> perhaps uses OpenMP.
>
> jb12407@lmfdb1:~$ OMP_NUM_THREADS=1 sage
> [...]
> SageMath version 7.4.beta6, Release Date: 2016-09-24
> [...]
> Warning: this is a prerelease version, and it may be unstable.
> [...]
> sage: %time M = ModularSymbols(5113, 2, -1)
> CPU times: user 509 ms, sys: 21 ms, total: 530 ms
> Wall time: 530 ms
> sage: %time S = M.cuspidal_subspace().new_subspace()
> CPU times: user 1.42 s, sys: 97 ms, total: 1.52 s
> Wall time: 1.56 s
>
>
> jb12407@lmfdb1:~$ sage
> [...]
> SageMath version 7.4.beta6, Release Date: 2016-09-24
> [...]
> sage: %time M = ModularSymbols(5113, 2, -1)
> CPU times: user 570 ms, sys: 18 ms, total: 588 ms
> Wall time: 591 ms
> sage: %time S = M.cuspidal_subspace().new_subspace()
> CPU times: user 3.76 s, sys: 9.01 s, total: 12.8 s
> Wall time: 1.69 s
>
> --
> You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+...@googlegroups.com
> .
> To post to this group, send email to sage-...@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/sage-devel
.
> For more options, visit https://groups.google.com/d/optout 
.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to
sage-devel+unsubscr...@googlegroups.com 
.
To post to this group, send email to sage-devel@googlegroups.com 
.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups

Re: [sage-devel] multithreading performance issues

2016-10-05 Thread Jean-Pierre Flori 
Currently OpenBlas does what it wants for multithreading.
We hesitated to disable it but prefered to wait and think about it:
see https://trac.sagemath.org/ticket/21323.

You can still influence its use of threads setting OPENBLAS_NUM_THREADS.
See the trac ticket, just note that this is not Sage specific.
And as you discovered, it seems it is also influenced by OMP_NUM_THREADS...

On Wednesday, October 5, 2016 at 9:28:23 AM UTC+2, tdumont wrote:
>
> What is the size of the matrix you use ? 
> Whatever you do, openmp in blas is interesting only if you compute with 
> large matrices. 
> If your computations are embedded  in an @parallel and launch n 
> processes, be careful  that your  OMP_NUM_THREADS be less or equal to 
> ncores/n. 
>
> My experience is (I am doing numerical computations)  that there are 
> very few cases where using openmp in blas libraries is interesting. 
> Parallelism should generally be searched at a higher level. 
>
> One of the interest of multithreaded blas is for constructors: with 
> Intel's mkl blas, you can obtain the maximum possible performances of 
> tah machines  when you use DGEMM (ie product of matrices), due to the 
> high arithmetic intensity of matrix vector products. On my 2x8 core 
> sandy bridge à 2.7GHZ, I have obtained more that 300 giga flops, but 
> with matrices of size > 1000 ! And this is only true for DGEMM 
>
> t.d. 
>
> Le 04/10/2016 à 20:26, Jonathan Bober a écrit : 
> > See the following timings: If I start Sage with OMP_NUM_THREADS=1, a 
> > particular computation takes 1.52 cpu seconds and 1.56 wall seconds. 
> > 
> > The same computation without OMP_NUM_THREADS set takes 12.8 cpu seconds 
> > and 1.69 wall seconds. This is particularly devastating when I'm running 
> > with @parallel to use all of my cpu cores. 
> > 
> > My guess is that this is Linbox related, since these computations do 
> > some exact linear algebra, and Linbox can do some multithreading, which 
> > perhaps uses OpenMP. 
> > 
> > jb12407@lmfdb1:~$ OMP_NUM_THREADS=1 sage 
> > [...] 
> > SageMath version 7.4.beta6, Release Date: 2016-09-24 
> > [...] 
> > Warning: this is a prerelease version, and it may be unstable. 
> > [...] 
> > sage: %time M = ModularSymbols(5113, 2, -1) 
> > CPU times: user 509 ms, sys: 21 ms, total: 530 ms 
> > Wall time: 530 ms 
> > sage: %time S = M.cuspidal_subspace().new_subspace() 
> > CPU times: user 1.42 s, sys: 97 ms, total: 1.52 s 
> > Wall time: 1.56 s 
> > 
> > 
> > jb12407@lmfdb1:~$ sage 
> > [...] 
> > SageMath version 7.4.beta6, Release Date: 2016-09-24 
> > [...] 
> > sage: %time M = ModularSymbols(5113, 2, -1) 
> > CPU times: user 570 ms, sys: 18 ms, total: 588 ms 
> > Wall time: 591 ms 
> > sage: %time S = M.cuspidal_subspace().new_subspace() 
> > CPU times: user 3.76 s, sys: 9.01 s, total: 12.8 s 
> > Wall time: 1.69 s 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "sage-devel" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to sage-devel+...@googlegroups.com  
> > . 
> > To post to this group, send email to sage-...@googlegroups.com 
>  
> > . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] multithreading performance issues

2016-10-05 Thread Thierry Dumont 
What is the size of the matrix you use ?
Whatever you do, openmp in blas is interesting only if you compute with
large matrices.
If your computations are embedded  in an @parallel and launch n
processes, be careful  that your  OMP_NUM_THREADS be less or equal to
ncores/n.

My experience is (I am doing numerical computations)  that there are
very few cases where using openmp in blas libraries is interesting.
Parallelism should generally be searched at a higher level.

One of the interest of multithreaded blas is for constructors: with
Intel's mkl blas, you can obtain the maximum possible performances of
tah machines  when you use DGEMM (ie product of matrices), due to the
high arithmetic intensity of matrix vector products. On my 2x8 core
sandy bridge à 2.7GHZ, I have obtained more that 300 giga flops, but
with matrices of size > 1000 ! And this is only true for DGEMM

t.d.

Le 04/10/2016 à 20:26, Jonathan Bober a écrit :
> See the following timings: If I start Sage with OMP_NUM_THREADS=1, a
> particular computation takes 1.52 cpu seconds and 1.56 wall seconds.
> 
> The same computation without OMP_NUM_THREADS set takes 12.8 cpu seconds
> and 1.69 wall seconds. This is particularly devastating when I'm running
> with @parallel to use all of my cpu cores.
> 
> My guess is that this is Linbox related, since these computations do
> some exact linear algebra, and Linbox can do some multithreading, which
> perhaps uses OpenMP.
> 
> jb12407@lmfdb1:~$ OMP_NUM_THREADS=1 sage
> [...]
> SageMath version 7.4.beta6, Release Date: 2016-09-24
> [...]
> Warning: this is a prerelease version, and it may be unstable.
> [...]
> sage: %time M = ModularSymbols(5113, 2, -1)
> CPU times: user 509 ms, sys: 21 ms, total: 530 ms
> Wall time: 530 ms
> sage: %time S = M.cuspidal_subspace().new_subspace()
> CPU times: user 1.42 s, sys: 97 ms, total: 1.52 s
> Wall time: 1.56 s
> 
> 
> jb12407@lmfdb1:~$ sage
> [...]
> SageMath version 7.4.beta6, Release Date: 2016-09-24
> [...]
> sage: %time M = ModularSymbols(5113, 2, -1)
> CPU times: user 570 ms, sys: 18 ms, total: 588 ms
> Wall time: 591 ms
> sage: %time S = M.cuspidal_subspace().new_subspace()
> CPU times: user 3.76 s, sys: 9.01 s, total: 12.8 s
> Wall time: 1.69 s
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com
> .
> To post to this group, send email to sage-devel@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
<>