Pembandingan (python vs. c ++ menggunakan BLAS) dan (numpy)


107

Saya ingin menulis program yang memanfaatkan fungsi aljabar linier BLAS dan LAPACK secara ekstensif. Karena kinerja adalah masalah, saya melakukan beberapa pembandingan dan ingin tahu, apakah pendekatan yang saya ambil itu sah.

Bisa dibilang, saya memiliki tiga kontestan dan ingin menguji kinerja mereka dengan perkalian matriks-matriks sederhana. Para kontestannya adalah:

  1. Numpy, hanya memanfaatkan fungsionalitas dot.
  2. Python, memanggil fungsionalitas BLAS melalui objek bersama.
  3. C ++, memanggil fungsionalitas BLAS melalui objek bersama.

Skenario

Saya menerapkan perkalian matriks-matriks untuk dimensi yang berbeda i. iberjalan dari 5 hingga 500 dengan kenaikan 5 dan matriks m1dan m2diatur seperti ini:

m1 = numpy.random.rand(i,i).astype(numpy.float32)
m2 = numpy.random.rand(i,i).astype(numpy.float32)

1. Numpy

Kode yang digunakan terlihat seperti ini:

tNumpy = timeit.Timer("numpy.dot(m1, m2)", "import numpy; from __main__ import m1, m2")
rNumpy.append((i, tNumpy.repeat(20, 1)))

2. Python, memanggil BLAS melalui objek bersama

Dengan fungsinya

_blaslib = ctypes.cdll.LoadLibrary("libblas.so")
def Mul(m1, m2, i, r):

    no_trans = c_char("n")
    n = c_int(i)
    one = c_float(1.0)
    zero = c_float(0.0)

    _blaslib.sgemm_(byref(no_trans), byref(no_trans), byref(n), byref(n), byref(n), 
            byref(one), m1.ctypes.data_as(ctypes.c_void_p), byref(n), 
            m2.ctypes.data_as(ctypes.c_void_p), byref(n), byref(zero), 
            r.ctypes.data_as(ctypes.c_void_p), byref(n))

kode tes terlihat seperti ini:

r = numpy.zeros((i,i), numpy.float32)
tBlas = timeit.Timer("Mul(m1, m2, i, r)", "import numpy; from __main__ import i, m1, m2, r, Mul")
rBlas.append((i, tBlas.repeat(20, 1)))

3. c ++, memanggil BLAS melalui objek bersama

Sekarang kode c ++ secara alami sedikit lebih lama jadi saya mengurangi informasinya seminimal mungkin.
Saya memuat fungsi dengan

void* handle = dlopen("libblas.so", RTLD_LAZY);
void* Func = dlsym(handle, "sgemm_");

Saya mengukur waktu dengan gettimeofdayseperti ini:

gettimeofday(&start, NULL);
f(&no_trans, &no_trans, &dim, &dim, &dim, &one, A, &dim, B, &dim, &zero, Return, &dim);
gettimeofday(&end, NULL);
dTimes[j] = CalcTime(start, end);

dimana jloop berjalan 20 kali. Saya menghitung waktu berlalu dengan

double CalcTime(timeval start, timeval end)
{
double factor = 1000000;
return (((double)end.tv_sec) * factor + ((double)end.tv_usec) - (((double)start.tv_sec) * factor + ((double)start.tv_usec))) / factor;
}

Hasil

Hasilnya ditunjukkan pada plot di bawah ini:

masukkan deskripsi gambar di sini

Pertanyaan

  1. Apakah menurut Anda pendekatan saya adil, atau adakah biaya tambahan yang tidak perlu yang dapat saya hindari?
  2. Apakah Anda berharap bahwa hasilnya akan menunjukkan perbedaan yang sangat besar antara pendekatan c ++ dan python? Keduanya menggunakan objek bersama untuk penghitungannya.
  3. Karena saya lebih suka menggunakan python untuk program saya, apa yang dapat saya lakukan untuk meningkatkan kinerja saat memanggil rutinitas BLAS atau LAPACK?

Unduh

Benchmark lengkapnya bisa diunduh disini . (JF Sebastian memungkinkan tautan itu ^^)


dalam pendekatan ctypes Anda, Anda memiliki alokasi memori di dalam fungsi yang diukur. Apakah kode c ++ Anda mengikuti pendekatan ini? Tetapi dibandingkan dengan perkalian matriks, ini seharusnya tidak membuat perbedaan besar ....
rocksportrocker

@rocksportrocker Anda benar. Alokasi memori untuk rmatriks tidak adil. Saya sedang menyelesaikan "masalah" sekarang dan memposting hasil baru.
Woltan

1. pastikan bahwa array memiliki tata letak memori yang sama np.ascontiguousarray()(pertimbangkan urutan C vs. Fortran). 2. pastikan bahwa np.dot()menggunakan sama libblas.so.
jfs

@JFSebastian Keduanya array m1dan m2memiliki ascontiguousarrayflag sebagai True. Dan numpy menggunakan objek bersama yang sama seperti C. Adapun urutan larik: Saat ini saya tidak tertarik dengan hasil penghitungan sehingga urutannya tidak relevan.
Woltan

1
@Woltan: jangan gunakan filefactory, layanannya buruk. Saya telah menambahkan patokan Anda ke github: woltan-benchmark . Jika Anda menggunakan github, saya dapat menambahkan Anda sebagai kolaborator.
jfs

Jawaban:


58

Saya telah menjalankan patokan Anda . Tidak ada perbedaan antara C ++ dan numpy di mesin saya:

patokan woltan

Apakah menurut Anda pendekatan saya adil, atau adakah biaya tambahan yang tidak perlu yang dapat saya hindari?

Sepertinya adil karena tidak ada perbedaan hasil.

Apakah Anda berharap bahwa hasilnya akan menunjukkan perbedaan yang sangat besar antara pendekatan c ++ dan python? Keduanya menggunakan objek bersama untuk penghitungannya.

Tidak.

Karena saya lebih suka menggunakan python untuk program saya, apa yang dapat saya lakukan untuk meningkatkan kinerja saat memanggil rutinitas BLAS atau LAPACK?

Pastikan numpy menggunakan versi perpustakaan BLAS / LAPACK yang dioptimalkan di sistem Anda.


4
Jadi, apa kesalahan poster asli? Saya berharap dia mengomentari posting ini. Apakah dia mengkonfirmasi bahwa Numpy secepat C ++?
wmac

Kode C ++ Anda berjalan lebih lambat dari pengepos asli. Apakah Anda mengkompilasi di bawah pengoptimalan?
cdcdcd

@cdcdcd itu bukan kode saya. Klik link tersebut dan jalankan benchmark sendiri dengan pilihan optimasi yang berbeda (lihat Makefile). Meskipun kode tidak mengkompilasi ulang baik blas maupun lapack.
jfs

73

UPDATE (30.07.2014):

Saya menjalankan kembali benchmark pada HPC baru kami. Baik perangkat keras maupun tumpukan perangkat lunak berubah dari pengaturan dalam jawaban asli.

Hasil saya taruh di google spreadsheet (berisi juga hasil dari jawaban aslinya).

Perangkat keras

HPC kami memiliki dua node berbeda, satu dengan CPU Intel Sandy Bridge dan satu lagi dengan CPU Ivy Bridge yang lebih baru:

Sandy (MKL, OpenBLAS, ATLAS):

  • CPU : 2 x 16 Intel (R) Xeon (R) E2560 Sandy Bridge @ 2.00GHz (16 Core)
  • RAM : 64 GB

Ivy (MKL, OpenBLAS, ATLAS):

  • CPU : 2 x 20 Intel (R) Xeon (R) E2680 V2 Ivy Bridge @ 2.80GHz (20 Core, dengan HT = 40 Core)
  • RAM : 256 GB

Perangkat lunak

Tumpukan perangkat lunak untuk kedua node yang sama. Alih-alih GotoBLAS2 , OpenBLAS digunakan dan ada juga ATLAS BLAS multi-utas yang disetel ke 8 utas (hardcode).

  • OS : Suse
  • Intel Compiler : ictce-5.3.0
  • Numpy: 1.8.0
  • OpenBLAS: 0.2.6
  • ATLAS :: 3.8.4

Tolok Ukur Produk Titik

Benchmark-code sama seperti di bawah ini. Namun untuk mesin baru saya juga menjalankan benchmark untuk ukuran matriks 5000 dan 8000 .
Tabel di bawah ini mencakup hasil benchmark dari jawaban asli (berganti nama: MKL -> Nehalem MKL, Netlib Blas -> Nehalem Netlib BLAS, dll)

Perkalian matriks (ukuran = [1000,2000,3000,5000,8000])

Kinerja ulir tunggal: kinerja ulir tunggal

Kinerja multi utas (8 utas): kinerja multi-utas (8 utas)

Benang vs ukuran Matriks (Ivy Bridge MKL) : Ukuran matriks vs utas

Suite Benchmark

benchmark suite

Kinerja ulir tunggal: masukkan deskripsi gambar di sini

Kinerja multi utas (8 utas): masukkan deskripsi gambar di sini

Kesimpulan

Hasil benchmark baru mirip dengan yang ada di jawaban asli. OpenBLAS dan MKL bekerja pada level yang sama, kecuali tes nilai Eigen . The Eigenvalue melaksanakan uji hanya cukup baik pada OpenBLAS di modus threaded tunggal . Dalam mode multi-utas, kinerjanya lebih buruk.

The "Matrix ukuran vs benang bagan" juga menunjukkan bahwa meskipun MKL serta OpenBLAS umumnya baik skala dengan jumlah core / benang, itu tergantung pada ukuran matriks. Untuk matriks kecil menambahkan lebih banyak inti tidak akan banyak meningkatkan kinerja.

Ada juga peningkatan kinerja sekitar 30% dari Sandy Bridge ke Ivy Bridge yang mungkin disebabkan oleh clock rate yang lebih tinggi (+ 0.8 Ghz) dan / atau arsitektur yang lebih baik.


Jawaban Asli (04.10.2011):

Beberapa waktu yang lalu saya harus mengoptimalkan beberapa perhitungan / algoritma aljabar linier yang ditulis dengan python menggunakan numpy dan BLAS jadi saya melakukan benchmark / uji konfigurasi numpy / BLAS yang berbeda.

Secara khusus saya menguji:

  • Numpy dengan ATLAS
  • Numpy dengan GotoBlas2 (1.13)
  • Numpy dengan MKL (11.1 / 073)
  • Numpy dengan Accelerate Framework (Mac OS X)

Saya menjalankan dua tolok ukur yang berbeda:

  1. produk titik sederhana dari matriks dengan ukuran berbeda
  2. Benchmark suite yang dapat ditemukan di sini .

Ini hasil saya:

Mesin

Linux (MKL, ATLAS, No-MKL, GotoBlas2):

  • OS : Ubuntu Lucid 10.4 64 Bit.
  • CPU : 2 x 4 Intel (R) Xeon (R) E5504 @ 2.00GHz (8 Core)
  • RAM : 24 GB
  • Kompiler Intel : 11.1 / 073
  • Scipy : 0.8
  • Numpy : 1.5

Mac Book Pro (Accelerate Framework):

  • OS : Mac OS X Snow Leopard (10.6)
  • CPU : 1 Intel Core 2 Duo 2,93 Ghz (2 Cores)
  • RAM : 4 GB
  • Scipy : 0.7
  • Numpy : 1.3

Mac Server (Accelerate Framework):

  • OS : Server Mac OS X Snow Leopard (10.6)
  • CPU : 4 X Intel (R) Xeon (R) E5520 @ 2,26 Ghz (8 Core)
  • RAM : 4 GB
  • Scipy : 0.8
  • Numpy : 1.5.1

Tolok ukur produk titik

Kode :

import numpy as np
a = np.random.random_sample((size,size))
b = np.random.random_sample((size,size))
%timeit np.dot(a,b)

Hasil :

    Sistem | size = 1000 | size = 2000 | size = 3000 |
netlib BLAS | 1350 md | 10900 md | 39200 md |    
ATLAS (1 CPU) | 314 md | 2560 md | 8700 md |     
MKL (1 CPU) | 268 md | 2110 md | 7120 md |
MKL (2 CPU) | - | - | 3660 md |
MKL (8 CPU) | 39 md | 319 md | 1000 md |
GotoBlas2 (1 CPU) | 266 md | 2100 md | 7280 md |
GotoBlas2 (2 CPU) | 139 ms | 1009 md | 3690 md |
GotoBlas2 (8 CPU) | 54 md | 389 md | 1250 md |
Mac OS X (1 CPU) | 143 ms | 1060 md | 3605 md |
Server Mac (1 CPU) | 92 md | 714 md | 2130 md |

Tolok ukur produk titik - bagan

Suite Benchmark

Kode :
Untuk informasi tambahan tentang rangkaian benchmark, lihat di sini .

Hasil :

    Sistem | eigenvalues ​​| svd | det | inv | titik |
netlib BLAS | 1688 md | 13102 md | 438 md | 2155 md | 3522 md |
ATLAS (1 CPU) | 1210 md | 5897 md | 170 ms | 560 md | 893 md |
MKL (1 CPU) | 691 md | 4475 md | 141 md | 450 ms | 736 md |
MKL (2 CPU) | 552 md | 2718 md | 96 md | 267 md | 423 md |
MKL (8 CPU) | 525 md | 1679 md | 60 md | 137 ms | 197 md |  
GotoBlas2 (1 CPU) | 2124 md | 4636 md | 147 md | 456 md | 743 md |
GotoBlas2 (2 CPU) | 1560 md | 3278 md | 116 ms | 295 md | 460 md |
GotoBlas2 (8 CPU) | 741 md | 2914 md | 82 md | 262 md | 192 md |
Mac OS X (1 CPU) | 948 md | 4339 md | 151 ms | 318 md | 566 md |
Server Mac (1 CPU) | 1033 md | 3645 md | 99 md | 232 md | 342 md |

Benchmark suite - grafik

Instalasi

Instalasi MKL termasuk menginstal Intel Compiler Suite lengkap yang cukup mudah. Namun karena beberapa bug / masalah, konfigurasi dan kompilasi numpy dengan dukungan MKL agak merepotkan.

GotoBlas2 adalah paket kecil yang dapat dengan mudah dikompilasi sebagai perpustakaan bersama. Namun karena bug Anda harus membuat ulang pustaka bersama setelah membuatnya untuk menggunakannya dengan numpy.
Selain bangunan ini, untuk beberapa bentuk pelat target tidak berfungsi karena alasan tertentu. Jadi saya harus membuat file .so untuk setiap platform yang saya ingin file libgoto2.so dioptimalkan .

Jika Anda menginstal numpy dari repositori Ubuntu, maka secara otomatis akan menginstal dan mengkonfigurasi numpy untuk menggunakan ATLAS . Menginstal ATLAS dari sumber dapat memakan waktu lama dan memerlukan beberapa langkah tambahan (fortran, dll).

Jika Anda menginstal numpy pada mesin Mac OS X dengan Fink atau Mac Ports , numpy akan dikonfigurasi untuk menggunakan ATLAS atau Kerangka Accelerate Apple . Anda dapat memeriksa dengan menjalankan ldd pada file numpy.core._dotblas atau memanggil numpy.show_config () .

Kesimpulan

MKL berkinerja terbaik diikuti oleh GotoBlas2 .
Dalam tes nilai eigen, kinerja GotoBlas2 ternyata lebih buruk dari yang diharapkan. Tidak yakin mengapa ini terjadi.
Kerangka Accelerate Apple bekerja sangat baik terutama dalam mode single threaded (dibandingkan dengan implementasi BLAS lainnya).

Baik GotoBlas2 dan MKL berskala sangat baik dengan jumlah utas. Jadi jika Anda harus berurusan dengan matriks besar yang menjalankannya di banyak utas akan sangat membantu.

Bagaimanapun, jangan gunakan implementasi netlib blas default karena terlalu lambat untuk pekerjaan komputasi yang serius.

Di cluster kami, saya juga menginstal ACML AMD dan kinerjanya mirip dengan MKL dan GotoBlas2 . Saya tidak memiliki angka yang sulit.

Saya pribadi akan merekomendasikan untuk menggunakan GotoBlas2 karena lebih mudah untuk menginstal dan gratis.

Jika Anda ingin membuat kode dalam C ++ / C juga periksa Eigen3 yang seharusnya mengungguli MKL / GotoBlas2 dalam beberapa kasus dan juga cukup mudah digunakan.


Terima kasih banyak atas jawaban yang rumit ini!
Woltan

Sangat lengkap, terima kasih! Saya bertanya-tanya, tiga tahun kemudian, apakah OpenBLAS (sejauh yang saya tahu, ini adalah keturunan GotoBLAS) akan berkinerja lebih baik. Saya telah membaca bahwa itu mengungguli MKL, tetapi tidak dapat menemukan sumbernya sekarang.

Terima kasih! Ini adalah kesan saya untuk0 (saya bertanya-tanya apakah ini hanya instalasi saya): OpenBLAS tidak bekerja dengan baik dalam mode multi-threaded dalam hal matriks diagonalisasi (saya mendiagonalisasi dalam scipy, yang terkait dengan OpenBLAS).

@William: biasanya Anda tidak perlu secara khusus menghubungkan scipy ke openblas karena ini akan menggunakan konfigurasi numpy selama penginstalan dan sebenarnya sebagian besar panggilan BLAS / Lapack akan diteruskan ke numpy. Jadi jika numpy terhubung dengan benar ke openblas, semuanya akan bekerja dengan baik.
Ümit

@ Ümit: Terima kasih! Saya mencoba mengatur numpy untuk menautkan ke MKL sekarang.

20

Ini patokan lain (di Linux, cukup ketik make): http://dl.dropbox.com/u/5453551/blas_call_benchmark.zip

http://dl.dropbox.com/u/5453551/blas_call_benchmark.png

Saya pada dasarnya tidak melihat perbedaan apa pun antara metode yang berbeda untuk matriks besar, antara Numpy, Ctypes dan Fortran. (Fortran bukannya C ++ --- dan jika ini penting, tolok ukur Anda mungkin rusak.)

CalcTimeFungsi Anda di C ++ sepertinya mengalami kesalahan tanda. ... + ((double)start.tv_usec))seharusnya sebagai gantinya ... - ((double)start.tv_usec)). Mungkin benchmark Anda juga memiliki bug lain, misalnya, membandingkan antara perpustakaan BLAS yang berbeda, atau pengaturan BLAS yang berbeda seperti jumlah utas, atau antara waktu nyata dan waktu CPU?

EDIT : gagal menghitung tanda kurung dalam CalcTimefungsi - tidak apa-apa.

Sebagai pedoman: jika Anda melakukan benchmark, harap selalu memposting semua kode di suatu tempat. Mengomentari benchmark, terutama jika mengejutkan, tanpa kode lengkap biasanya tidak produktif.


Untuk mengetahui BLAS Numpy mana yang ditautkan, lakukan:

$ python
Python 2.7.2+ (default, 16 Agustus 2011, 07:24:41) 
[GCC 4.6.1] di linux2
Ketik "bantuan", "hak cipta", "kredit" atau "lisensi" untuk informasi lebih lanjut.
>>> impor numpy.core._dotblas
>>> numpy.core._dotblas .__ file__
'/usr/lib/pymodules/python2.7/numpy/core/_dotblas.so'
>>> 
$ ldd /usr/lib/pymodules/python2.7/numpy/core/_dotblas.so
    linux-vdso.so.1 => (0x00007fff5ebff000)
    libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007fbe618b3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbe61514000)

UPDATE : Jika Anda tidak dapat mengimpor numpy.core._dotblas, Numpy Anda menggunakan salinan cadangan internal BLAS, yang lebih lambat, dan tidak dimaksudkan untuk digunakan dalam komputasi kinerja! Balasan dari @Woltan di bawah ini menunjukkan bahwa ini adalah penjelasan untuk perbedaan yang dia lihat di Numpy vs. Ctypes + BLAS.

Untuk memperbaiki situasi ini, Anda memerlukan ATLAS atau MKL --- periksa petunjuk ini: http://scipy.org/Installing_SciPy/Linux Sebagian besar distribusi Linux disertakan dengan ATLAS, jadi opsi terbaik adalah menginstal libatlas-devpaket mereka (nama mungkin berbeda) .


Saya telah menjalankan patokan Anda; hasilnya sama
jfs

Terima kasih banyak atas kiriman Anda. Saya menjalankan patokan Anda dengan hasil ini . Jadi saya tidak bisa mereproduksi milik Anda. Untuk memeriksa BLAS mana yang digunakan numpy saya: Saya tidak bisa import numpy.core._dotblas. Apa masalahnya di sini? Saya akan mencoba membersihkan benchmark saya dan menulis makefile agar orang lain dapat mengujinya.
Woltan

2
@Woltan: fakta bahwa Anda tidak dapat mengimpor numpy.core._dotblas berarti Numpy Anda menggunakan salinan cadangan internal BLAS ( lebih lambat , dan tidak dimaksudkan untuk digunakan dalam komputasi kinerja!), Daripada perpustakaan BLAS yang Anda miliki di sistem Anda. Ini menjelaskan hasil yang Anda dapatkan dari benchmark. Untuk memperbaiki situasi ini, Anda perlu menginstal versi BLAS yang Numpy dapat bekerja dengan --- yang berarti ATLAS atau MKL. Berikut sekumpulan instruksi: scipy.org/Installing_SciPy/Linux
pv.

@pv .: Bisakah Anda menjalankan tolok ukur Woltan untuk membandingkan hasil.
jfs

1
Di Mac, Anda dapat menggunakan otool -Lselain ldddi Linux
RichVel

9

Mengingat ketelitian yang Anda tunjukkan dengan analisis Anda, saya terkejut dengan hasilnya sejauh ini. Saya menempatkan ini sebagai 'jawaban' tetapi hanya karena terlalu panjang untuk komentar dan memberikan kemungkinan (meskipun saya berharap Anda telah mempertimbangkannya).

Saya akan mengira pendekatan numpy / python tidak akan menambah banyak overhead untuk matriks dengan kompleksitas yang wajar, karena ketika kompleksitas meningkat, proporsi yang diikuti python harus kecil. Saya lebih tertarik dengan hasil di sisi kanan grafik, tetapi perbedaan urutan besaran yang ditunjukkan di sana akan mengganggu.

Saya ingin tahu apakah Anda menggunakan algoritme terbaik yang dapat dimanfaatkan numpy. Dari panduan kompilasi untuk linux:

"Build FFTW (3.1.2): Versi SciPy> = 0.7 dan Numpy> = 1.2: Karena masalah lisensi, konfigurasi, dan pemeliharaan, dukungan untuk FFTW telah dihapus dalam versi SciPy> = 0.7 dan NumPy> = 1.2. Sebagai gantinya sekarang menggunakan versi built-in dari fftpack. Ada beberapa cara untuk memanfaatkan kecepatan FFTW jika perlu untuk analisis Anda. Turunkan ke versi Numpy / Scipy yang menyertakan dukungan. Instal atau buat pembungkus FFTW Anda sendiri. Lihat http: //developer.berlios.de/projects/pyfftw/ sebagai contoh yang tidak didukung. "

Apakah Anda mengkompilasi numpy dengan mkl? ( http://software.intel.com/en-us/articles/intel-mkl/ ). Jika Anda menjalankan linux, petunjuk untuk mengompilasi numpy dengan mkl ada di sini: http://www.scipy.org/Installing_SciPy/Linux#head-7ce43956a69ec51c6f2cedd894a4715d5bfff974 (terlepas dari url). Bagian kuncinya adalah:

[mkl]
library_dirs = /opt/intel/composer_xe_2011_sp1.6.233/mkl/lib/intel64
include_dirs = /opt/intel/composer_xe_2011_sp1.6.233/mkl/include
mkl_libs = mkl_intel_lp64,mkl_intel_thread,mkl_core 

Jika Anda menggunakan windows, Anda bisa mendapatkan biner terkompilasi dengan mkl, (dan juga mendapatkan pyfftw, dan banyak algoritma terkait lainnya) di: http://www.lfd.uci.edu/~gohlke/pythonlibs/ , dengan hutang terima kasih kepada Christoph Gohlke di Laboratory for Fluorescence Dynamics, UC Irvine.

Peringatan, dalam kedua kasus, ada banyak masalah perizinan dan sebagainya yang harus diperhatikan, tetapi halaman intel menjelaskannya. Sekali lagi, saya membayangkan Anda telah mempertimbangkan ini, tetapi jika Anda memenuhi persyaratan perizinan (yang di linux sangat mudah dilakukan), ini akan mempercepat bagian numpy relatif untuk menggunakan build otomatis sederhana, bahkan tanpa FFTW. Saya akan tertarik untuk mengikuti utas ini dan melihat apa yang dipikirkan orang lain. Terlepas dari itu, ketelitian yang sangat baik dan pertanyaan yang sangat baik. Terima kasih telah mempostingnya.


Terima kasih atas "komentar" Anda yang rumit ^^. Untuk memperjelas pengaturan python / numpy / BLAS saya: Saya mengikuti panduan instalasi ini . Saya menggunakan os linux dan versinya adalah: Python 2.7, Scipy 0.9 Numpy 1.6. Sayangnya saya tidak membuat FFTW sebelumnya, saya juga tidak menggunakan mkl ...
Woltan

Di satu sisi, itu beruntung. Artinya, ada ruang besar untuk peningkatan pada hasil python dan sepertinya Anda ingin menggunakan python. Saya pikir jika Anda mengubah build Anda dengan yang ditunjukkan pada tautan, Anda akan jauh lebih senang dengan kecepatan numpy, meskipun saya masih terpesona melihat bagaimana itu dibandingkan dengan implementasi C ++ Anda.
Kotor

Anda dapat mencoba membangun ATLAS juga, tetapi kedengarannya terlalu banyak sakit kepala untuk kebutuhan kinerja saya, jadi saya belum memiliki pengalaman. Saya membayangkan jika Anda tertarik untuk menggunakan python tetapi dapat menggunakan C ++, akan ada beberapa titik di mana biaya pengaturan untuk melakukan banyak kompilasi khusus akan lebih besar daripada penghematan bahasa, dan akan lebih mudah untuk melakukan c ++. Tapi mkl dan fftw keduanya harus cukup mudah.
Kotor

1
Saat ini MKL, Accelerate dan OpenBLAS memiliki kinerja yang serupa. OpenBLAS lebih scalable dari MKL.
Sturla Molden
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.