[sage-devel] Re: dense F_p matrix multiplication
On 11/5/07, Martin Albrecht [EMAIL PROTECTED] wrote: I've got a naive question: Why isn't linbox the default choice for matrix multiplication over F_p? (1) It was probably broken when we first wrapped matrix multiply with linbox. (2) Timings of linbox vary drastically depending on available BLAS. Maybe your timings are better below on your machine, but they could be much worse on another machine. Whereas the builtin sage implementation doesn't depend as much. (3) Memory leaks in linbox could make doing the multiply there undesirable. In other words, it could be time to switch to linbox if (1) the answers are right and it doesn't crash, (2) the timings are fairly uniformly better, and (3) memory leaks aren't a problem. sage: A = random_matrix(GF(127),2000,2000) sage: B = random_matrix(GF(127),2000,2000) sage: %time C = A._multiply_linbox(B) CPU times: user 4.15 s, sys: 0.00 s, total: 4.15 s Wall time: 4.19 sage: %time D = A*B CPU times: user 11.65 s, sys: 0.01 s, total: 11.67 s Wall time: 11.75 sage: C == D True Btw. MAGMA is still faster: sage: AM = A._magma_(); BM = B._magma_() sage: time magma.eval(C:=%s*%s%(AM.name(),BM.name())) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 1.68 '' Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
It certainly is machine dependent! On my (aging) laptop I get this: sage: sage: A = random_matrix(GF(127),2000,2000) sage: sage: B = random_matrix(GF(127),2000,2000) sage: sage: %time D = A*B CPU times: user 40.87 s, sys: 2.06 s, total: 42.93 s Wall time: 44.42 sage: %time C = A._multiply_linbox(B) CPU times: user 70.29 s, sys: 0.90 s, total: 71.19 s Wall time: 71.83 so linbox takes almost twice as long. John On 05/11/2007, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, Martin Albrecht [EMAIL PROTECTED] wrote: I've got a naive question: Why isn't linbox the default choice for matrix multiplication over F_p? (1) It was probably broken when we first wrapped matrix multiply with linbox. (2) Timings of linbox vary drastically depending on available BLAS. Maybe your timings are better below on your machine, but they could be much worse on another machine. Whereas the builtin sage implementation doesn't depend as much. (3) Memory leaks in linbox could make doing the multiply there undesirable. In other words, it could be time to switch to linbox if (1) the answers are right and it doesn't crash, (2) the timings are fairly uniformly better, and (3) memory leaks aren't a problem. sage: A = random_matrix(GF(127),2000,2000) sage: B = random_matrix(GF(127),2000,2000) sage: %time C = A._multiply_linbox(B) CPU times: user 4.15 s, sys: 0.00 s, total: 4.15 s Wall time: 4.19 sage: %time D = A*B CPU times: user 11.65 s, sys: 0.01 s, total: 11.67 s Wall time: 11.75 sage: C == D True Btw. MAGMA is still faster: sage: AM = A._magma_(); BM = B._magma_() sage: time magma.eval(C:=%s*%s%(AM.name(),BM.name())) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 1.68 '' Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 2:10 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, Martin Albrecht [EMAIL PROTECTED] wrote: Hello, I've got a naive question: Why isn't linbox the default choice for matrix multiplication over F_p? (1) It was probably broken when we first wrapped matrix multiply with linbox. :) (2) Timings of linbox vary drastically depending on available BLAS. Maybe your timings are better below on your machine, but they could be much worse on another machine. Whereas the builtin sage implementation doesn't depend as much. malb, are you using the gslblas or ATLAS? (3) Memory leaks in linbox could make doing the multiply there undesirable. ffpack is free of memory leaks last time I checked. If not I will fix them :) In other words, it could be time to switch to linbox if (1) the answers are right and it doesn't crash, (2) the timings are fairly uniformly better, and (3) memory leaks aren't a problem. I think this is something we should look into next week during the coding sprint. My plan is to work on ATLAS integration, so this should come up. sage: A = random_matrix(GF(127),2000,2000) sage: B = random_matrix(GF(127),2000,2000) sage: %time C = A._multiply_linbox(B) CPU times: user 4.15 s, sys: 0.00 s, total: 4.15 s Wall time: 4.19 sage: %time D = A*B CPU times: user 11.65 s, sys: 0.01 s, total: 11.67 s Wall time: 11.75 sage: C == D True Btw. MAGMA is still faster: sage: AM = A._magma_(); BM = B._magma_() sage: time magma.eval(C:=%s*%s%(AM.name(),BM.name())) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 1.68 '' I guess there is a certain overhead for LinBox, i.e. getting the matrix from Sage into LinBox and reconverting the result. We should measure that just to eliminate this benchmarketing-wise. Martin Cheers, Michael -- name: Martin Albrecht _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www:http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Monday 05 November 2007, John Cremona wrote: It certainly is machine dependent! On my (aging) laptop I get this: sage: sage: A = random_matrix(GF(127),2000,2000) sage: sage: B = random_matrix(GF(127),2000,2000) sage: sage: %time D = A*B CPU times: user 40.87 s, sys: 2.06 s, total: 42.93 s Wall time: 44.42 sage: %time C = A._multiply_linbox(B) CPU times: user 70.29 s, sys: 0.90 s, total: 71.19 s Wall time: 71.83 so linbox takes almost twice as long. Hi, this is probably due to the faster BLAS implementation on my notebook (and the standard GSL on your's). So we could remember which BLAS we use and default to LinBox if we have a fast BLAS (OSX, ATLAS, Goto). Thoughts? Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On 11/5/07, Martin Albrecht [EMAIL PROTECTED] wrote: Hi, this is probably due to the faster BLAS implementation on my notebook (and the standard GSL on your's). So we could remember which BLAS we use and default to LinBox if we have a fast BLAS (OSX, ATLAS, Goto). The current plan with Sage is to switch to including ATLAS standard with Sage. Then the Sage will always have a fast BLAS. A year ago that would be crazy talk, but building ATLAS has very *massively* improved during the last year, so this is now quite reasonable. -- william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 3:01 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, Martin Albrecht [EMAIL PROTECTED] wrote: Hi, this is probably due to the faster BLAS implementation on my notebook (and the standard GSL on your's). So we could remember which BLAS we use and default to LinBox if we have a fast BLAS (OSX, ATLAS, Goto). The current plan with Sage is to switch to including ATLAS standard with Sage. Then the Sage will always have a fast BLAS. A year ago that would be crazy talk, but building ATLAS has very *massively* improved during the last year, so this is now quite reasonable. And ATLAS also offers multi threaded BLAS Level 3 operations which could be used by ffpack for matrix-matrix multiplies depending on the algorithm used. The optional ATLAS.spkg is single threaded, but I am working on add optional support to build ATLAS multi threaded. Problem is that it takes roughly number of cores times to build since it tunes itself for 1 to number of cores each. I am trying on sage.math later on today to see if there is any benefit/how large matrices have to become before we see an improvement. I did some benchmarking with LinBox's rationalSolver and multi threaded BLAS (ATLAS, Goto as well as Intel) did run slower than single threaded, mostly due to the fact that the rational solver uses BLAS Level 2 mostly, which is usually slower when multi threaded (due to the higher overhead of setup of operations) Cheers, Michael -- william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
It would be nice if it were documented somewhere how big the optional packages are (e.g. file sizes displayed at http://www.sagemath.org/packages/optional/) ...waiting for atlas to download... and now seeing the error message sage: An error occurred while installing atlas-3.7.38 Please email sage-devel http://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/jec/sage-2.8.10/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/jec/sage-2.8.10/spkg/build/atlas-3.7.38 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/jec/sage-2.8.10 in order to set all environment variables correctly, then cd to /home/jec/sage-2.8.10/spkg/build/atlas-3.7.38 The problem seems to be no fortran compiler, so I'm now installing gfortran. Hence: optioanl packages should also tell of any new dependencies! John On 05/11/2007, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, Martin Albrecht [EMAIL PROTECTED] wrote: Hi, this is probably due to the faster BLAS implementation on my notebook (and the standard GSL on your's). So we could remember which BLAS we use and default to LinBox if we have a fast BLAS (OSX, ATLAS, Goto). The current plan with Sage is to switch to including ATLAS standard with Sage. Then the Sage will always have a fast BLAS. A year ago that would be crazy talk, but building ATLAS has very *massively* improved during the last year, so this is now quite reasonable. -- william -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 3:12 pm, John Cremona [EMAIL PROTECTED] wrote: It would be nice if it were documented somewhere how big the optional packages are (e.g. file sizes displayed athttp://www.sagemath.org/packages/optional/) ...waiting for atlas to download... and now seeing the error message sage: An error occurred while installing atlas-3.7.38 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/jec/sage-2.8.10/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/jec/sage-2.8.10/spkg/build/atlas-3.7.38 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/jec/sage-2.8.10 in order to set all environment variables correctly, then cd to /home/jec/sage-2.8.10/spkg/build/atlas-3.7.38 The problem seems to be no fortran compiler, so I'm now installing gfortran. Yep, that should fix it. ATLAS builds an f77 wrapper, that can be turned off. Last time I tried (3.7.38 or so) that was broken and resulted in an aborted compilation, so for now you need some fortran compiler in $PATH. The plan is to use sage_fortran in the future to compile that f77 wrapper, I haven't found time to teach ATLAS's build system to do so. As mentioned earlier ATLAS integration will be my project during the coding sprint at SD6, so hopefully we will have ATLAS as default in the 2.9 release. Hence: optioanl packages should also tell of any new dependencies! John SNIP Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
Thanks. After installing gfortran I found that the binary was called gfortran-4.1 in /usr/bin so I linked that to /usr/bin/gfortran and now the installation is proceeding ok. John On 05/11/2007, mabshoff [EMAIL PROTECTED] wrote: On Nov 5, 3:12 pm, John Cremona [EMAIL PROTECTED] wrote: It would be nice if it were documented somewhere how big the optional packages are (e.g. file sizes displayed athttp://www.sagemath.org/packages/optional/) ...waiting for atlas to download... and now seeing the error message sage: An error occurred while installing atlas-3.7.38 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/jec/sage-2.8.10/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/jec/sage-2.8.10/spkg/build/atlas-3.7.38 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/jec/sage-2.8.10 in order to set all environment variables correctly, then cd to /home/jec/sage-2.8.10/spkg/build/atlas-3.7.38 The problem seems to be no fortran compiler, so I'm now installing gfortran. Yep, that should fix it. ATLAS builds an f77 wrapper, that can be turned off. Last time I tried (3.7.38 or so) that was broken and resulted in an aborted compilation, so for now you need some fortran compiler in $PATH. The plan is to use sage_fortran in the future to compile that f77 wrapper, I haven't found time to teach ATLAS's build system to do so. As mentioned earlier ATLAS integration will be my project during the coding sprint at SD6, so hopefully we will have ATLAS as default in the 2.9 release. Hence: optioanl packages should also tell of any new dependencies! John SNIP Cheers, Michael -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
After installing Atlas (took 20 minutes) it runs more slowly! sage: sage: %time C = A._multiply_linbox(B) CPU times: user 72.32 s, sys: 1.02 s, total: 73.34 s Wall time: 80.09 (was 72 s wall time). John On 05/11/2007, Martin Albrecht [EMAIL PROTECTED] wrote: On Monday 05 November 2007, John Cremona wrote: It certainly is machine dependent! On my (aging) laptop I get this: sage: sage: A = random_matrix(GF(127),2000,2000) sage: sage: B = random_matrix(GF(127),2000,2000) sage: sage: %time D = A*B CPU times: user 40.87 s, sys: 2.06 s, total: 42.93 s Wall time: 44.42 sage: %time C = A._multiply_linbox(B) CPU times: user 70.29 s, sys: 0.90 s, total: 71.19 s Wall time: 71.83 so linbox takes almost twice as long. Hi, this is probably due to the faster BLAS implementation on my notebook (and the standard GSL on your's). So we could remember which BLAS we use and default to LinBox if we have a fast BLAS (OSX, ATLAS, Goto). Thoughts? Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
Hi John, On Nov 5, 3:45 pm, John Cremona [EMAIL PROTECTED] wrote: After installing Atlas (took 20 minutes) it runs more slowly! sage: sage: %time C = A._multiply_linbox(B) CPU times: user 72.32 s, sys: 1.02 s, total: 73.34 s Wall time: 80.09 On sage.math time drops from 11.86s to 10.83, but the 2000x2000 case isn't really the interesting one yet in my opinion. I am benchmarking some larger cases right now. For those small fields ATLAS can use float precision instead of double internally, so that should speed up the computation roughly by a factor of 2, but that is BLAS dependent. (was 72 s wall time). John Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On 11/5/07, John Cremona [EMAIL PROTECTED] wrote: After installing Atlas (took 20 minutes) it runs more slowly! No, it will run at exactly the same speed. You also have to rebuild linbox in such a way that it actually takes advantage of ATLAS. Right now, your linbox install is probalby built to use frickin' slow GSL. Oh, Michael will have just written the same thing but better as I write this... sage: sage: %time C = A._multiply_linbox(B) CPU times: user 72.32 s, sys: 1.02 s, total: 73.34 s Wall time: 80.09 (was 72 s wall time). John On 05/11/2007, Martin Albrecht [EMAIL PROTECTED] wrote: On Monday 05 November 2007, John Cremona wrote: It certainly is machine dependent! On my (aging) laptop I get this: sage: sage: A = random_matrix(GF(127),2000,2000) sage: sage: B = random_matrix(GF(127),2000,2000) sage: sage: %time D = A*B CPU times: user 40.87 s, sys: 2.06 s, total: 42.93 s Wall time: 44.42 sage: %time C = A._multiply_linbox(B) CPU times: user 70.29 s, sys: 0.90 s, total: 71.19 s Wall time: 71.83 so linbox takes almost twice as long. Hi, this is probably due to the faster BLAS implementation on my notebook (and the standard GSL on your's). So we could remember which BLAS we use and default to LinBox if we have a fast BLAS (OSX, ATLAS, Goto). Thoughts? Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] -- John Cremona -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 3:57 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, John Cremona [EMAIL PROTECTED] wrote: After installing Atlas (took 20 minutes) it runs more slowly! No, it will run at exactly the same speed. You also have to rebuild linbox in such a way that it actually takes advantage of ATLAS. Right now, your linbox install is probalby built to use frickin' slow GSL. Oh, Michael will have just written the same thing but better as I write this... Ignore my last email, I forgot to rebuild LinBox. I am surprised how much timings vary I get from running matrix matrix multiplies, especially since sage.math is not loaded. Do the following to get it to work: $ source local/bin/sage-env $ export SAGE_BLAS=$SAGE_LOCAL $ ./sage -f spkg/standard/linbox-20070915.p1.spkg Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On 11/5/07, mabshoff [EMAIL PROTECTED] wrote: Ignore my last email, I forgot to rebuild LinBox. I am surprised how much timings vary I get from running matrix matrix multiplies, especially since sage.math is not loaded. Do the following to get it to work: $ source local/bin/sage-env $ export SAGE_BLAS=$SAGE_LOCAL $ ./sage -f spkg/standard/linbox-20070915.p1.spkg Arrrg, I am an idiot! Please do export LINBOX_BLAS=$SAGE_LOCAL/lib and it should work. Maybe somebody like me ought to document this somewhere in the wiki :) That's why optional packages should be completely trivial to install. This should *not* be documented in the wiki. What should happen is that the atlas package installs easily, or gives a clear reason why the install fails and what somebody must do to remedy the problem. Of course, in this case the best thing will be to have atlas become a standard package. william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 5:24 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, mabshoff [EMAIL PROTECTED] wrote: Ignore my last email, I forgot to rebuild LinBox. I am surprised how much timings vary I get from running matrix matrix multiplies, especially since sage.math is not loaded. Do the following to get it to work: $ source local/bin/sage-env $ export SAGE_BLAS=$SAGE_LOCAL $ ./sage -f spkg/standard/linbox-20070915.p1.spkg Arrrg, I am an idiot! Please do export LINBOX_BLAS=$SAGE_LOCAL/lib and it should work. Maybe somebody like me ought to document this somewhere in the wiki :) That's why optional packages should be completely trivial to install. This should *not* be documented in the wiki. What should happen is that the atlas package installs easily, or gives a clear reason why the install fails and what somebody must do to remedy the problem. Of course, in this case the best thing will be to have atlas become a standard package. Actually, it is export SAGE_BLAS=$SAGE_LOCAL/lib Third time's the charm ;) I agree that ATLAS should be standard, but LinBox by itself should be smart enough to figure out that ATLAS is there in the first place. Anyway: After running benchmarks for a couple hours and recompiling linbox a couple times I am now convinced that the way we use LinBox now we do not even utilize the specialized BLAS interface: Here are two examples from the LinBox's test suite linked against ATLAS: [EMAIL PROTECTED] tests]$ nm test-ffpack | grep ATL | wc -l 454 [EMAIL PROTECTED] tests]$ nm test-zero-one | grep ATL | wc -l 0 The ATL are the ATLAS symbols, in case of ffpack we end up actually using BLAS, in zero-one we do not. Now we look at liblinboxwrap.so.0.0.0 linked against a LinBox build with ATLAS: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ldd local/lib/ liblinboxwrap.so.0.0.0 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2aef1f669000) libm.so.6 = /lib/libm.so.6 (0x2aef1f868000) libc.so.6 = /lib/libc.so.6 (0x2aef1f9ea000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2aef1fc27000) /lib64/ld-linux-x86-64.so.2 (0x4000) There is no dynamic BLAS linked against liblinboxwrap.so.0.0.0, but also: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ nm local/lib/ liblinboxwrap.so.0.0.0 | grep ATL | wc -l 0 [Even if we linked dynamically against ATLAS there would be ATL symbols referenced in liblinboxwrap] So, I am convinved that it doesn't matter which BLAS we linked in case of the current liblinboxwrap because we do not seem to wrap the specialized types in LinBox that take advantage of ffpack and then in turn of BLAS. The advantage of LinBox over the generic matrix matrix multiply seems to be algorithmic only at the moment. I would actually suggest of wrapping the interesting bits of ffpack directly without the LinBox overhead. ffpack comes with LinBox, so it is there anyway. But I have to get some work done and also want to put rc1 together tonight, so I do not have time to investigate this now. If anybody with deeper knowledge of liblinboxwrap wants to dig into this feel free to do so, there are plenty of other issues for me to play with. william Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
Totally trivial remark: use grep -c instead of piping the output to wc -l ! John On 05/11/2007, mabshoff [EMAIL PROTECTED] wrote: On Nov 5, 5:24 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, mabshoff [EMAIL PROTECTED] wrote: Ignore my last email, I forgot to rebuild LinBox. I am surprised how much timings vary I get from running matrix matrix multiplies, especially since sage.math is not loaded. Do the following to get it to work: $ source local/bin/sage-env $ export SAGE_BLAS=$SAGE_LOCAL $ ./sage -f spkg/standard/linbox-20070915.p1.spkg Arrrg, I am an idiot! Please do export LINBOX_BLAS=$SAGE_LOCAL/lib and it should work. Maybe somebody like me ought to document this somewhere in the wiki :) That's why optional packages should be completely trivial to install. This should *not* be documented in the wiki. What should happen is that the atlas package installs easily, or gives a clear reason why the install fails and what somebody must do to remedy the problem. Of course, in this case the best thing will be to have atlas become a standard package. Actually, it is export SAGE_BLAS=$SAGE_LOCAL/lib Third time's the charm ;) I agree that ATLAS should be standard, but LinBox by itself should be smart enough to figure out that ATLAS is there in the first place. Anyway: After running benchmarks for a couple hours and recompiling linbox a couple times I am now convinced that the way we use LinBox now we do not even utilize the specialized BLAS interface: Here are two examples from the LinBox's test suite linked against ATLAS: [EMAIL PROTECTED] tests]$ nm test-ffpack | grep ATL | wc -l 454 [EMAIL PROTECTED] tests]$ nm test-zero-one | grep ATL | wc -l 0 The ATL are the ATLAS symbols, in case of ffpack we end up actually using BLAS, in zero-one we do not. Now we look at liblinboxwrap.so.0.0.0 linked against a LinBox build with ATLAS: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ldd local/lib/ liblinboxwrap.so.0.0.0 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2aef1f669000) libm.so.6 = /lib/libm.so.6 (0x2aef1f868000) libc.so.6 = /lib/libc.so.6 (0x2aef1f9ea000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2aef1fc27000) /lib64/ld-linux-x86-64.so.2 (0x4000) There is no dynamic BLAS linked against liblinboxwrap.so.0.0.0, but also: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ nm local/lib/ liblinboxwrap.so.0.0.0 | grep ATL | wc -l 0 [Even if we linked dynamically against ATLAS there would be ATL symbols referenced in liblinboxwrap] So, I am convinved that it doesn't matter which BLAS we linked in case of the current liblinboxwrap because we do not seem to wrap the specialized types in LinBox that take advantage of ffpack and then in turn of BLAS. The advantage of LinBox over the generic matrix matrix multiply seems to be algorithmic only at the moment. I would actually suggest of wrapping the interesting bits of ffpack directly without the LinBox overhead. ffpack comes with LinBox, so it is there anyway. But I have to get some work done and also want to put rc1 together tonight, so I do not have time to investigate this now. If anybody with deeper knowledge of liblinboxwrap wants to dig into this feel free to do so, there are plenty of other issues for me to play with. william Cheers, Michael -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
Maybe I'll give up on this for a bit since after setting all those environment variables and redoing I get (stuff) gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING using frickin' slow GSL C-blas WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING (stuff) which suggest that it will not speed up at all! John On 05/11/2007, mabshoff [EMAIL PROTECTED] wrote: On Nov 5, 5:24 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, mabshoff [EMAIL PROTECTED] wrote: Ignore my last email, I forgot to rebuild LinBox. I am surprised how much timings vary I get from running matrix matrix multiplies, especially since sage.math is not loaded. Do the following to get it to work: $ source local/bin/sage-env $ export SAGE_BLAS=$SAGE_LOCAL $ ./sage -f spkg/standard/linbox-20070915.p1.spkg Arrrg, I am an idiot! Please do export LINBOX_BLAS=$SAGE_LOCAL/lib and it should work. Maybe somebody like me ought to document this somewhere in the wiki :) That's why optional packages should be completely trivial to install. This should *not* be documented in the wiki. What should happen is that the atlas package installs easily, or gives a clear reason why the install fails and what somebody must do to remedy the problem. Of course, in this case the best thing will be to have atlas become a standard package. Actually, it is export SAGE_BLAS=$SAGE_LOCAL/lib Third time's the charm ;) I agree that ATLAS should be standard, but LinBox by itself should be smart enough to figure out that ATLAS is there in the first place. Anyway: After running benchmarks for a couple hours and recompiling linbox a couple times I am now convinced that the way we use LinBox now we do not even utilize the specialized BLAS interface: Here are two examples from the LinBox's test suite linked against ATLAS: [EMAIL PROTECTED] tests]$ nm test-ffpack | grep ATL | wc -l 454 [EMAIL PROTECTED] tests]$ nm test-zero-one | grep ATL | wc -l 0 The ATL are the ATLAS symbols, in case of ffpack we end up actually using BLAS, in zero-one we do not. Now we look at liblinboxwrap.so.0.0.0 linked against a LinBox build with ATLAS: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ldd local/lib/ liblinboxwrap.so.0.0.0 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2aef1f669000) libm.so.6 = /lib/libm.so.6 (0x2aef1f868000) libc.so.6 = /lib/libc.so.6 (0x2aef1f9ea000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2aef1fc27000) /lib64/ld-linux-x86-64.so.2 (0x4000) There is no dynamic BLAS linked against liblinboxwrap.so.0.0.0, but also: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ nm local/lib/ liblinboxwrap.so.0.0.0 | grep ATL | wc -l 0 [Even if we linked dynamically against ATLAS there would be ATL symbols referenced in liblinboxwrap] So, I am convinved that it doesn't matter which BLAS we linked in case of the current liblinboxwrap because we do not seem to wrap the specialized types in LinBox that take advantage of ffpack and then in turn of BLAS. The advantage of LinBox over the generic matrix matrix multiply seems to be algorithmic only at the moment. I would actually suggest of wrapping the interesting bits of ffpack directly without the LinBox overhead. ffpack comes with LinBox, so it is there anyway. But I have to get some work done and also want to put rc1 together tonight, so I do not have time to investigate this now. If anybody with deeper knowledge of liblinboxwrap wants to dig into this feel free to do so, there are plenty of other issues for me to play with. william Cheers, Michael -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 6:04 pm, John Cremona [EMAIL PROTECTED] wrote: Maybe I'll give up on this for a bit since after setting all those environment variables and redoing I get (stuff) gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING using frickin' slow GSL C-blas WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING (stuff) which suggest that it will not speed up at all! Either way the BLAS used doesn't matter. We just need it to satisfy the linker, no actual static or dynamic library actually ends up getting used. Just compared the size and linked libraries of William's plain LinBox with cblas vs. my optimized with ATLAS: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ls -al /home/was/s/local/ lib/liblinboxwrap.so.0.0.0 -rwxr-xr-x 1 was was 10584961 2007-11-02 20:39 /home/was/s/local/lib/ liblinboxwrap.so.0.0.0 [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ls -al local/lib/ liblinboxwrap.so.0.0.0 -rwxr-xr-x 1 mabshoff 1090 10585769 2007-11-05 08:33 local/lib/ liblinboxwrap.so.0.0.0 [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ldd /home/was/s/local/ lib/liblinboxwrap.so.0.0.0 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2b6959fc3000) libm.so.6 = /lib/libm.so.6 (0x2b695a1c2000) libc.so.6 = /lib/libc.so.6 (0x2b695a344000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2b695a581000) /lib64/ld-linux-x86-64.so.2 (0x4000) [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ldd local/lib/ liblinboxwrap.so.0.0.0 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2b09457eb000) libm.so.6 = /lib/libm.so.6 (0x2b09459ea000) libc.so.6 = /lib/libc.so.6 (0x2b0945b6c000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2b0945da9000) /lib64/ld-linux-x86-64.so.2 (0x4000) John SNIP We should ask Clement during SD6 on which classes to wrap to get the speedup with BLAS. John: Thanks for the grep -c tip. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
