blas

Benchmark test results on the home page of Julia ( http://julialang.org/ ) shows that Fortran is about 4x slower than Julia/Numpy in the "rand_mat_mul" benchmark. I can not understand that why fortran is slower while calling from the same fortran library (BLAS)?? I have also performed a simple test for matrix multiplication evolving fortran, julia and numpy and got the similar results: Julia n = 1000; A = rand(n,n); B = rand(n,n); @time C = A*B; >> elapsed time: 0.069577896 seconds (7 MB allocated) Numpy in IPython from numpy import * n = 1000; A = random.rand(n,n); B = random.rand(n,n); %time

I want to run the following script: #python imports import time #3rd party imports import numpy as np import pandas as pd def pd_svd(pd_dataframe): np_dataframe = pd_dataframe.values return np.linalg.svd(pd_dataframe) if __name__ == '__main__': li_times = [] for i in range(1, 3): start = time.time() pd_dataframe = pd.DataFrame(np.random.random((3000, 252 * i))) pd_svd(pd_dataframe) li_times.append(str(time.time() - start)) print li_times I try it on my Macbook Air 2011 with OSX 10.9.4 and on a 16 core cloud VM running Ubuntu 12.0.4. For some reason, this takes approximately 4 seconds on my

Using Lapack with C++ is giving me a small headache. I found the functions defined for fortran a bit eccentric, so I tried to make a few functions on C++ to make it easier for me to read what's going on. Anyway, I'm not getting th matrix-vector product working as I wish. Here is a small sample of the program. smallmatlib.cpp: #include <cstdio> #include <stdlib.h> extern "C"{ // product C= alphaA.B + betaC void dgemm_(char* TRANSA, char* TRANSB, const int* M, const int* N, const int* K, double* alpha, double* A, const int* LDA, double* B, const int* LDB, double* beta, double* C, const int* LDC)

Has anyone had experience using prefetch instructions for the Core 2 Duo processor? I've been using the (standard?) prefetch set ( prefetchnta , prefetcht1 , etc) with success for a series of P4 machines, but when running the code on a Core 2 Duo it seems that the prefetcht(i) instructions do nothing, and that the prefetchnta instruction is less effective. My criteria for assessing performance is the timing results for a BLAS 1 vector-vector (axpy) operation, when the vector size is large enough for out-of-cache behaviour. Have Intel introduced new prefetch instructions? From an Intel

I was testing the cblas ddot, and the code I used is from the link and I fixed it as #include <stdio.h> #include <stdlib.h> #include <cblas.h> int main() { double m[10],n[10]; int i; int result; printf("Enter the elements into first vector.\n"); for(i=0;i<10;i++) scanf("%lf",&m[i]); printf("Enter the elements into second vector.\n"); for(i=0;i<10;i++) scanf("%lf",&n[i]); result = cblas_ddot(10, m, 1, n, 1); printf("The result is %d\n",result); return 0; } Then when I compiled it, it turned out to be: /tmp/ccJIpqKH.o: In function `main': test.c:(.text+0xbc): undefined reference to `cblas_ddot'

Background & Problem I am having a bit of trouble running the examples in Spark's MLLib on a machine running Fedora 23. I have built Spark 1.6.2 with the following options per Spark documentation: build/mvn -Pnetlib-lgpl -Pyarn -Phadoop-2.4 \ -Dhadoop.version=2.4.0 -DskipTests clean package and upon running the binary classification example: bin/spark-submit --class org.apache.spark.examples.mllib.BinaryClassification \ examples/target/scala-*/spark-examples-*.jar \ --algorithm LR --regType L2 --regParam 1.0 \ data/mllib/sample_binary_classification_data.txt I receive the following error: /usr

I'm building numpy from source on CentOS 6.5 with no root access (python -V=2.7.6). I have the latest numpy source from git. I cannot for the life of me get numpy to acknowledge atlas libs. I have: ls -1 /usr/lib64/atlas libatlas.so.3 libatlas.so.3.0 libcblas.so.3 libcblas.so.3.0 libclapack.so.3 libclapack.so.3.0 libf77blas.so.3 libf77blas.so.3.0 liblapack.so.3 liblapack.so.3.0 libptcblas.so.3 libptcblas.so.3.0 libptf77blas.so.3 libptf77blas.so.3.0 I don't know anything about how these libs came about, but I can only assume that the atlas builds would be faster than any standard BLAS/LAPACK