You are not logged in.

## #1 2013-07-22 16:32:04

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

Hi,

I don't know if this thread belongs here or in a different sub-forum, but I'll risk posting it here anyway. I am a Master's student currently finishing up (or trying to finish) my thesis in the area of Quantum Transport. My work involves handling large matrices and many inversions, matrix multiplications, complex numbers, etc. My code is written from scratch in Python and is as vectored as the application and physics can permit (and also my understanding of vectorization, Python, and the sorts). I am a relative newbie to Arch Linux but have been using Linux for several years.

I have found that my code (uses python3, python3-numpy, python3-scipy and python3-matplotlib) runs way faster in Ubuntu than on Arch Linux. When I say faster, I mean the following operations execute in less time: matrix multiplication, and matrix inversion.

I have tested this on 3 different systems with the following configurations:

1. Desktop
CPU = Intel Core i7 920 @ 2.66 GHz
MB = Gigabyte EX 58 Extreme
RAM = 24 GB DDR3
HDD = 500 GB x 2 (one for each distro, Arch and Ubuntu)

2. Laptop #1
CPU = Intel Core i7-2760QM @ 2.40 GHz
RAM = 12 GB DDR3
HDD = 500 GB

3. Laptop #2
CPU = Intel Core i7 Q740 @ 1.73 GHz
RAM = 6 GB DDR3
HDD = 650 GB

So there are 2 observations I cannot quite reconcile with myself:

Observation 1: Desktop is faster than both laptops. This is odd, because on paper the Core i7-2760 QM ought to be faster than Core i7 920. Right now I am not using any GPU acceleration, so I expect everything to happen on the CPU's math co-processor..

Observation 2: Laptops are actually very slow in running the code. Again odd, because it should not be hard to multiply two matrices of size 5040 x 5040, right? Or am I wrong?

To be specific, here's how long it takes to do a matrix multiplication of the form A * B * Adagger where Adagger denotes the Hermitian adjoint (conjugate transpose) of A (where A and B are both of dimension 5040 x 5040):

Ubuntu (Desktop): 3.9 minutes
Arch (Desktop)     : 34 minutes
Arch (Laptop #1)  : 25 minutes
Arch (Laptop #2)  : ---xx---- (crashes/overheats)

I know I should install Ubuntu on the laptop and also provide those specs, but if you look at the first two stats, there is an almost 10x improvement in executing the same code on the desktop in Ubuntu. Needless to say (and sadly, since I am an Arch fan) I have had to switch to Ubuntu for now on the desktop because I am hard-pressed for time.

But I really want to understand why this is happening at all! Any ideas, discussions and suggestions are strongly welcome!

Last edited by darkmav (2013-07-22 16:38:50)

Offline

## #2 2013-07-22 16:45:24

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,709
Website

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

My brain won't do a comparison until you try both Arch Linux and Ubuntu on the same computer.

Also, are you allowed to share your application? I'm curious about the differences in time it will take different computers to finish your application, because the four results you posted are WAAAY different from each other.

Offline

## #3 2013-07-22 16:52:34

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

drcouzelis wrote:

My brain won't do a comparison until you try both Arch Linux and Ubuntu on the same computer.

Oh I have, on my desktop What would you make of that? Ubuntu vs Arch on the Desktop?

drcouzelis wrote:

Also, are you allowed to share your application? I'm curious about the differences in time it will take different computers to finish your application, because the four results you posted are WAAAY different from each other.

I do plan to open-source the program once I'm done (should be in a few weeks).

Offline

## #4 2013-07-22 17:30:43

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,709
Website

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

darkmav wrote:

Oh I have, on my desktop. What would you make of that? Ubuntu vs Arch on the Desktop?

Oops! My mistake.

I can't imagine what the difference would be between the two operating systems. Maybe... Ubuntu has some special Python optimizations? But that sounds dumb.

Are the speed results the same with and without the Python cache files?

I do plan to open-source the program once I'm done (should be in a few weeks).

I wrote this in response to your post. Please understand that I'm mad not mad at you or anything. I was just in the mood for a good rant.

Last edited by drcouzelis (2013-07-22 19:06:17)

Offline

## #5 2013-07-22 17:36:22

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

Yes, it is after the cache files have been created.

drcouzelis wrote:

I wrote this in response to your post. Please understand that I'm mad at you or anything. I was just in the mood for a good rant.

I hope you mean you're not mad at me ;-)

On a serious note, there are just two .py files -- the code has been written for a small specific problem and isn't a general software or anything. To be honest, my advisor isn't happy with the idea of putting it "out there" just yet, and until I defend, it is still something I do not want to take issue with since I am anyway struggling to rectify small snags, etc. To clarify, it isn't exactly a full fledged software program to be put up there with a GNU GPL, etc. but I don't plan to keep it secret. I actually intend to make a small writeup explaining everything including the code. But I have to join grad school in less than a month, and the prospect of doing something which isn't in the mainstream is scary at best.

On average I have to wait about 475 minutes for ONE result. Even on Ubuntu. I guess I should get to PyCUDA or something.

Offline

## #6 2013-07-22 17:39:55

progandy
Member
Registered: 2012-05-17
Posts: 2,213

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

To be honest, my advisor isn't happy with the idea of putting it "out there" just yet

Can't you just put a random matrix multiplication in new python script and use that for testing purposes?

PS: You might also want to try PyPy and its JIT feature instead of pure interpreted python. (maybe you are already using it on Ubuntu?)

Last edited by progandy (2013-07-22 17:43:13)

Offline

## #7 2013-07-22 17:54:59

jakobcreutzfeldt
Member
Registered: 2011-05-12
Posts: 1,033

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

darkmav wrote:

To clarify, it isn't exactly a full fledged software program to be put up there with a GNU GPL, etc.

I'm sorry to further derail your thread (I'm genuinely curious to find out the source of the discrepancy), but I'd just like to point out that you had better add some sort of license to the code. Otherwise, when you make the source available, it defaults to "all rights reserved"...in other words, no one can do anything with it other than run it (they can't distribute it, modify it, etc). I'm not a lawyer, but I can say that this is approximately what will happen. Even if you decide to put it in the public domain, you have to effectively declare that.

Offline

## #8 2013-07-22 19:09:34

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,709
Website

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

darkmav wrote:

I hope you mean you're not mad at me

Yes. Fixed.

I hope you are able to figure out the difference between the two operating systems. The difference in those times is MASSIVE. I wonder if any other Python applications in Arch Linux are running dirt slow.

Offline

## #9 2013-07-22 19:40:18

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

drcouzelis wrote:

I hope you are able to figure out the difference between the two operating systems. The difference in those times is MASSIVE. I wonder if any other Python applications in Arch Linux are running dirt slow.

Is there some quantifiable, systematic way to check? Some standard python scientific code maybe?

The code I have is identical on both machines of course, as are the versions of python, scipy, numpy, etc. The only difference is the distro. And at any time, only this code is being executed.

Offline

## #10 2013-07-22 19:41:06

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

progandy wrote:

Can't you just put a random matrix multiplication in new python script and use that for testing purposes?

PS: You might also want to try PyPy and its JIT feature instead of pure interpreted python. (maybe you are already using it on Ubuntu?)

Ok, I'll try both, and get back to you on this thread.

Offline

## #11 2013-07-22 19:50:41

ewaller
Registered: 2009-07-13
Posts: 14,717

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

it should not be hard to multiply two matrices of size 5040 x 5040, right? Or am I wrong?

I don't know if that was meant as sarcasm or not

Are you doing any reduction, or is this a brute force operation?

I assume these are 64 bit floating numbers?  8*5050*5040 is about 200MB.  That should fit in RAM, but you might check to ensure you are not swapping; that might explain an order of magnitude in the ration of the execution times.

Have you, per chance, considered writing the matrix multiply function in C and calling it from Python?

Last edited by ewaller (2013-07-22 19:51:28)

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
----
How to Ask Questions the Smart Way

Offline

## #12 2013-07-22 19:58:11

FreeTheBee
Member
Registered: 2011-01-02
Posts: 125

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

Numba is also something to look into perhaps.  It is aimed at speeding up numpy/scipy operations and seems to be quite good at it already. It was a bit of a pain to install though, I only managed using virtualenv and pip.

Offline

## #13 2013-07-22 19:59:41

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

ewaller wrote:

it should not be hard to multiply two matrices of size 5040 x 5040, right? Or am I wrong?

I don't know if that was meant as sarcasm or not

Haha, no, it wasn't. I am genuinely bewildered.

ewaller wrote:

Are you doing any reduction, or is this a brute force operation?

I'm ashamed to admit that this is a brute force operation for now. I did optimize one of the matrix multiplications, the part with A*B*Adagger, in the case when B is a diagonal matrix:

``````Bd = diag(B)  # diagonal matrix consisting of the diagonal elements of B
C   = copy(A)
for i in range(0, len(Bd)):
C[:,i] *= Bd[i] # multiply the i-th column of C (A) with the i-th element of Bd

``````Adag = conjugate(transpose(A))
result = dot(A, dot(B, Adag) )``````

This doesn't help much.

ewaller wrote:

I assume these are 64 bit floating numbers?  8*5050*5040 is about 200MB.  That should fit in RAM, but you might check to ensure you are not swapping; that might explain an order of magnitude in the ration of the execution times.

Sorry if this is a dumb question, but how do I check to ensure they're not swapping?

ewaller wrote:

Have you, per chance, considered writing the matrix multiply function in C and calling it from Python?

I thought about it, but I haven't tried it simply because I don't know how to interface C with Python. I'll read up and try to implement it.

Last edited by darkmav (2013-07-22 20:00:38)

Offline

## #14 2013-07-22 21:49:42

ewaller
Registered: 2009-07-13
Posts: 14,717

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

You might install the package time.  This provides GNU Time, not to be confused with the crippled version baked into zsh (and I think bash).  Run your program as such:
/usr/bin/time -v theNameOfYourProgram
Type the entire path of the time command, or you will get the built in version.
At completion, it will tell you a great deal about your program.  Look at the major page fault requiring I/O statistic.  That is the one that will kill performance.
Example:

``````ewaller@localhost:/proc 1036 %/usr/bin/time -v pstree
systemd-+-3*[VBoxClient---{VBoxClient}]
|-VBoxService---7*[{VBoxService}]
|-at-spi-bus-laun-+-dbus-daemon
|                 `-3*[{at-spi-bus-laun}]
|-at-spi2-registr---{at-spi2-registr}
|-4*[autocutsel]
|-2*[dbus-daemon]
|-dbus-launch
|-dconf-service---2*[{dconf-service}]
|-2*[dhcpcd]
|-gconfd-2
|-gvfs-udisks2-vo---{gvfs-udisks2-vo}
|-gvfsd---{gvfsd}
|-gvfsd-fuse---4*[{gvfsd-fuse}]
|-i3bar---i3status
|-kactivitymanage---6*[{kactivitymanage}]
|-kded4
|-kdeinit4---klauncher
|-kglobalaccel
|-knotify4---{knotify4}
|                              `-i3
|-polkitd---5*[{polkitd}]
|-ssh-agent
|-systemd-journal
|-systemd-udevd
|-udisksd---4*[{udisksd}]
|-upowerd---2*[{upowerd}]
|-urxvt---zsh---time---pstree
`-xfconfd
Command being timed: "pstree"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 14%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.04
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 784
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 1
Minor (reclaiming a frame) page faults: 250
Voluntary context switches: 2
Involuntary context switches: 66
Swaps: 0
File system inputs: 40
File system outputs: 0
Socket messages sent: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
ewaller@localhost:/proc 1037 %``````

In this case, pstree had one major page faults.

Edit:  Also look at swaps and involuntary context switches.

Last edited by ewaller (2013-07-22 21:51:58)

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
----
How to Ask Questions the Smart Way

Offline

## #15 2013-07-23 00:57:17

Trent
Member
From: Baltimore, MD (US)
Registered: 2009-04-16
Posts: 987

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

How have you compared the versions of Python involved? I doubt they're exactly the same. Compare sys.version at least.

Performance-affecting bugs in Python are not unheard of. A factor of 10 difference in execution time, while an obstacle IRL, isn't all that great in computer time; that could easily be explained by Arch's version failing to optimize one lookup or function call that just happens to be in a deeply nested loop. (As opposed to, say, a 10,000-fold slowdown, which likely hints at more severe problems.)

In any case, I'm interested to know what it is whenever you do figure it out.

Offline

## #16 2013-07-23 14:20:54

Member
Registered: 2008-04-29
Posts: 31

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

If you make heavy use of Matrix operations in numpy the execution speed depends stronly on the underlying BLAS implementation used for the compilation of numpy.
I think the Archlinux numpy version is build against the reference BLAS version, which is extremely slow, while the Ubuntu version is build against the Atlas BLAS version and should be faster.
So I am pretty sure the difference in execution time comes from the different blas implementations.
You could try different numpy versions from the AUR build against faster blas implementations like the intel mkl or openblas.

Last edited by Radfahrer (2013-07-23 14:42:15)

Offline

## #17 2013-07-23 14:25:16

Nisstyre56
Member
Registered: 2010-03-25
Posts: 82

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

Perhaps there is a difference in the kernel scheduling algorithm or something between the two distros? Or some kernel module? I'm assuming you haven't bothered to use the same kernel versions on both.

Last edited by Nisstyre56 (2013-07-23 14:25:51)

In Zen they say: If something is boring after two minutes, try it for four. If still boring, try it for eight, sixteen, thirty-two, and so on. Eventually one discovers that it's not boring at all but very interesting.
~ John Cage

Offline

## #18 2013-07-23 15:36:38

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

If you make heavy use of Matrix operations in numpy the execution speed depends stronly on the underlying BLAS implementation used for the compilation of numpy.
I think the Archlinux numpy version is build against the reference BLAS version, which is extremely slow, while the Ubuntu version is build against the Atlas BLAS version and should be faster.
So I am pretty sure the difference in execution time comes from the different blas implementations.
You could try different numpy versions from the AUR build against faster blas implementations like the intel mkl or openblas.

``````[vivek@farpoint python_progs]\$ yaourt numpy
1 extra/python-numpy 1.7.1-1 [installed]
Scientific tools for Python
2 extra/python2-numpy 1.7.1-1 [installed]
Scientific tools for Python
3 aur/acml-python2-numpy 1.6.1-1 (0)
Scientific tools for Python
4 aur/libnpy 0.5-1 (3)
A small library that provides simple routines for saving a C or Fortran array to a data file using numpy's own binary format.
5 aur/libx32-python2-numpy 1.7.0-1.1 (0)
Scientific tools for Python (x32 ABI)
6 aur/ndarray-svn-127 1-1 (0)
a C++ multidimensional array library designed for NumPy interoperability
7 aur/pygarrayimage 1.0-1 (3)
Allow numpy arrays as source of texture data for pyglet.
8 aur/python-apgl 0.7.2-1 (0)
A simple, fast and easy to use Python graph library using NumPy, Scipy and PySparse
9 aur/python-ffvideo 0.0.9-1 (1)
FFVideo is a python extension makes possible to access to decoded frames at two format: PIL.Image or numpy.ndarray.
10 aur/python-numpy-atlas 1.7.0-1 (1)
Scientific tools for Python (built against ATLAS)
11 aur/python-numpy-doc 1.7.0-1 (6)
Documentation for NumPy
12 aur/python-numpy-git 20120523-2 (2)
Scientific tools for Python (dual python2/python3)
13 aur/python-numpy-mkl 1.7.0-4 (8)
Scientific tools for Python compiled with intel mkl
14 aur/python-quantities 0.10.1-1 (5)
Support for physical quantities based on the popular numpy library
15 aur/python2-astroml 0.1.2-1 (0)
AstroML is a Python module for machine learning and data mining built on numpy, scipy, scikit-learn, and matplotlib.
16 aur/python2-blaze-git 20130124-1 (0)
Blaze is the next generation of NumPy
17 aur/python2-bottleneck 0.6.0-2 (3)
Fast NumPy array functions written in Cython
18 aur/python2-bottleneck-git 0.6.0.37.ga88198e-1 (0)
Fast NumPy array functions written in Cython
19 aur/python2-ffvideo 0.0.9-1 (1)
FFVideo is a python extension makes possible to access to decoded frames at two format: PIL.Image or numpy.ndarray.
20 aur/python2-glumpy 0.2.1-1 (3)
Rapid visualization of numpy arrays using opengl
21 aur/python2-la 0.6.0-1 (0)
Label the rows, columns, any dimension, of your NumPy arrays
22 aur/python2-numba-git 20121231-1 (Out of Date) (4)
NumPy aware dynamic Python compiler using LLVM
23 aur/python2-numdisplay 1.5.6-2 (0)
Numdisplay provides the capability to visualize numpy array objects
24 aur/python2-numpy-atlas 1.7.0-1 (1)
Scientific tools for Python (built against ATLAS)
25 aur/python2-numpy-openblas 1.7.1-2 (1)
Scientific tools for Python - built with openblas
26 aur/python2-numpydoc 0.4-1 (10)
Sphinx extension to support docstrings in Numpy format
27 aur/python2-pyublas 2011.1-2 (1)
Seamless Numpy-UBlas interoperability.
28 aur/python2-quantities 0.10.1-1 (0)
Support for physical quantities based on the popular numpy library
29 aur/scikits-audiolab-git 20110217-3 (16)
python package for reading/writing audio files from numpy arrays
30 aur/talib-python-git 0.1-1 (0)
This is a Python wrapper for TA-LIB based on Cython and Numpy to efficiently and cleanly bind to TA-Lib -- producing results 2-4 times faster than the SWIG interface.
==> Enter n° of packages to be installed (ex: 1 2 3 or 1-3)
==> -------------------------------------------------------
==> ``````

So, say I use the Atlas or the OpenBLAS implementation. How do I call it from within Python preferentially, over the default numpy?

Nisstyre56 wrote:

Perhaps there is a difference in the kernel scheduling algorithm or something between the two distros? Or some kernel module? I'm assuming you haven't bothered to use the same kernel versions on both.

Yes, there could well be, because the kernel versions are indeed different:

``Linux farpoint 3.9.9-1-ARCH #1 SMP PREEMPT Wed Jul 3 22:45:16 CEST 2013 x86_64 GNU/Linux``
``Linux farpoint 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux``

Offline

## #19 2013-07-23 15:49:19

progandy
Member
Registered: 2012-05-17
Posts: 2,213

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

darkmav wrote:

So, say I use the Atlas or the OpenBLAS implementation. How do I call it from within Python preferentially, over the default numpy?

Just install the optimized version instead of the default package.

Offline

## #20 2013-07-23 16:00:17

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

progandy wrote:
darkmav wrote:

So, say I use the Atlas or the OpenBLAS implementation. How do I call it from within Python preferentially, over the default numpy?

Just install the optimized version instead of the default package.

Okay, you mean uninstall the one I have first.

Offline

## #21 2013-07-23 16:37:58

sitquietly
Member
From: Moscow, Tennessee
Registered: 2010-07-12
Posts: 216

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

If you make heavy use of Matrix operations in numpy the execution speed depends stronly on the underlying BLAS implementation used for the compilation of numpy.....

ATLAS is of course much faster than the Reference BLAS; I prefer OpenBLAS on my Gentoo "scientific workstation" (Gentoo is perfect for scientific computing with python), for example see some benchmarks of blas vs openblas and atlas on Ubuntu here.

Offline

## #22 2013-07-23 17:00:48

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,709
Website

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

Well, Ubuntu does offer OpenBLAS and ATLAS as dependencies of numpy. I'd say if you login to your Ubuntu installation and check which packages are installed then your original question in this thread will be pretty much as good as solved.

Offline

## #23 2013-07-23 18:04:48

Stalafin
Member
From: Berlin, Germany
Registered: 2007-10-26
Posts: 617

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

darkmav wrote:

I'm ashamed to admit that this is a brute force operation for now. I did optimize one of the matrix multiplications, the part with A*B*Adagger, in the case when B is a diagonal matrix:

``````Bd = diag(B)  # diagonal matrix consisting of the diagonal elements of B
C   = copy(A)
for i in range(0, len(Bd)):
C[:,i] *= Bd[i] # multiply the i-th column of C (A) with the i-th element of Bd

``````Adag = conjugate(transpose(A))
result = dot(A, dot(B, Adag) )``````

This doesn't help much.

That Matrix operation is terrible. You do know that the loop is basically performed in Python and you have no advantage of using NumPy? The second version is somewhat better.
In general, you should either perform loops like the above in C/Cython, or use vectorized operations on arrays (in this case, you are looking for “broadcasting”).

Offline

## #24 2013-07-23 18:10:24

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

Stalafin wrote:
darkmav wrote:

I'm ashamed to admit that this is a brute force operation for now. I did optimize one of the matrix multiplications, the part with A*B*Adagger, in the case when B is a diagonal matrix:

``````Bd = diag(B)  # diagonal matrix consisting of the diagonal elements of B
C   = copy(A)
for i in range(0, len(Bd)):
C[:,i] *= Bd[i] # multiply the i-th column of C (A) with the i-th element of Bd

``````Adag = conjugate(transpose(A))
result = dot(A, dot(B, Adag) )``````

This doesn't help much.

That Matrix operation is terrible. You do know that the loop is basically performed in Python and you have no advantage of using NumPy? The second version is somewhat better.
In general, you should either perform loops like the above in C/Cython, or use vectorized operations on arrays (in this case, you are looking for “broadcasting”).

Oh but incidentally, the first version (the one that uses one call to dot()) is something that takes less time and was suggested by the author of a Python-based computational physics textbook after we had extensive discussions about this.

What do you mean by (further) vectorized operations on arrays in this context? The single call dot(A, dot(B, conjugate(transpose(A) ) ) uses numpy through and through. What else could one do here?

Last edited by darkmav (2013-07-23 18:11:11)

Offline

## #25 2013-07-23 18:28:48

darkmav
Member
Registered: 2012-01-21
Posts: 99

### Re: Arch Linux vs Ubuntu 13.04 64-bit for Python-based simulation

drcouzelis wrote:

Well, Ubuntu does offer OpenBLAS and ATLAS as dependencies of numpy. I'd say if you login to your Ubuntu installation and check which packages are installed then your original question in this thread will be pretty much as good as solved.

Did you have to disable CPU throttling somehow to get it to work? Ref: http://www.linuxquestions.org/questions … -a-806430/

``````Architecture configured as  Corei1 (25)

Clock rate configured as 933Mhz

Maximum number of threads configured as  8
Parallel make command configured as '\$(MAKE) -j 8'
CPU Throttling apparently enabled!
It appears you have cpu throttling enabled, which makes timings
unreliable and an ATLAS install nonsensical.  Aborting.``````

Offline