Kıyaslama (python ve BLAS kullanarak c ++) ve (numpy)


107

BLAS ve LAPACK lineer cebir işlevlerini kapsamlı bir şekilde kullanan bir program yazmak istiyorum. Performans bir sorun olduğu için bazı kıyaslamalar yaptım ve benimsediğim yaklaşımın meşru olup olmadığını bilmek isterim.

Tabiri caizse üç yarışmacım var ve performanslarını basit bir matris-matris çarpımı ile test etmek istiyorum. Yarışmacılar:

  1. Numpy, yalnızca dot.
  2. Python, BLAS işlevlerini paylaşılan bir nesne aracılığıyla çağırır.
  3. C ++, BLAS işlevlerini paylaşılan bir nesne aracılığıyla çağırır.

Senaryo

Farklı boyutlar için bir matris-matris çarpımı uyguladım i. i5 ve matricies artışıyla 5'ten 500'e kadar çalışır m1ve m2şu şekilde ayarlanır:

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

1. Uykulu

Kullanılan kod şuna benzer:

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

2. Python, BLAS'ı paylaşılan bir nesne aracılığıyla çağırma

İşlevi ile

_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))

test kodu şuna benzer:

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 ++, BLAS'ı paylaşılan bir nesne aracılığıyla çağırma

Artık c ++ kodu doğal olarak biraz daha uzundur, bu yüzden bilgiyi minimuma indiriyorum.
İşlevi yüklüyorum

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

Zamanı şu şekilde ölçüyorum gettimeofday:

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);

j20 kez çalışan bir döngü nerede . İle geçen zamanı hesaplıyorum

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;
}

Sonuçlar

Sonuç aşağıdaki grafikte gösterilmektedir:

görüntü açıklamasını buraya girin

Sorular

  1. Yaklaşımımın adil olduğunu mu düşünüyorsunuz yoksa önleyebileceğim bazı gereksiz genel giderler var mı?
  2. Sonucun c ++ ve python yaklaşımı arasında bu kadar büyük bir tutarsızlık göstermesini bekler miydiniz? Her ikisi de hesaplamaları için paylaşılan nesneleri kullanıyor.
  3. Programım için python kullanmayı tercih ettiğim için, BLAS veya LAPACK rutinlerini çağırırken performansı artırmak için ne yapabilirim?

İndir

Karşılaştırmanın tamamı buradan indirilebilir . (JF Sebastian bu bağlantıyı mümkün kıldı ^^)


ctypes yaklaşımınızda, ölçülen fonksiyonun içinde bellek tahsisine sahipsiniz. C ++ kodunuz bu yaklaşımı izliyor mu? Ancak matris çarpımıyla karşılaştırıldığında bu çok büyük bir fark
yaratmamalı

@rocksportrocker Doğru söylüyorsunuz. rMatris için bellek tahsisi adil değil. Şu anda "sorunu" çözüyorum ve yeni sonuçları gönderiyorum.
Woltan

1. Dizilerin aynı bellek düzenine sahip olduğundan emin olun np.ascontiguousarray()(C'ye karşı Fortran sırasını düşünün). 2. np.dot()Aynı şeyi kullandığından emin olun libblas.so.
jfs

@JFSebastian Hem diziler m1ve m2sahip ascontiguousarrayolduğu bayrak True. Ve numpy, C ile aynı paylaşılan nesneyi kullanır. Dizinin sırasına gelince: Şu anda hesaplamanın sonucuyla ilgilenmiyorum, bu yüzden sıra alakasız.
Woltan

1
@Woltan: filefactory kullanmayın, servis berbat. Kriterinizi github: woltan-benchmark'a ekledim . Github kullanıyorsanız, sizi ortak çalışan olarak ekleyebilirim.
jfs

Yanıtlar:


58

Kıyaslama yapıyorum . Makinemde C ++ ile numpy arasında hiçbir fark yok:

Woltan'ın kriteri

Yaklaşımımın adil olduğunu mu düşünüyorsunuz yoksa önleyebileceğim bazı gereksiz genel giderler var mı?

Sonuçlarda fark olmadığı için adil görünüyor.

Sonucun c ++ ve python yaklaşımı arasında bu kadar büyük bir tutarsızlık göstermesini bekler miydiniz? Her ikisi de hesaplamaları için paylaşılan nesneleri kullanıyor.

Hayır.

Programım için python kullanmayı tercih ettiğim için, BLAS veya LAPACK rutinlerini çağırırken performansı artırmak için ne yapabilirim?

Numpy'nin sisteminizdeki BLAS / LAPACK kitaplıklarının optimize edilmiş sürümünü kullandığından emin olun.


4
Peki orijinal afiş neyi yanlış yaptı? Keşke bu yazıya yorum yapmış olsaydı. Numpy'nin C ++ kadar hızlı olduğunu onaylıyor mu?
wmac

C ++ kodunuz orijinal posterlerden daha yavaş çalışıyor. Optimizasyon altında mı derlediniz?
cdcdcd

@cdcdcd benim kodum değil. Bağlantıya tıklayın ve farklı optimizasyon seçenekleriyle karşılaştırmayı kendiniz çalıştırın (Makefile'a bakın). Kod ne blas ne de lapack'i yeniden derlemese de.
jfs

73

GÜNCELLEME (30.07.2014):

Karşılaştırmayı yeni HPC'mizde yeniden çalıştırıyorum. Orijinal cevapta hem donanım hem de yazılım yığını kurulumdan değişti.

Sonuçları bir google elektronik tablosuna koydum (orijinal cevabın sonuçlarını da içerir).

Donanım

HPC'mizin biri Intel Sandy Bridge CPU'lu ve diğeri daha yeni Ivy Bridge CPU'lu iki farklı düğümü vardır:

Sandy (MKL, OpenBLAS, ATLAS):

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

Ivy (MKL, OpenBLAS, ATLAS):

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

Yazılım

Yazılım yığını, her iki düğüm için de sam. Yerine GotoBLAS2 , OpenBLAS kullanılır ve ayrıca bir orada çok evreli ATLAS 8 parçacığı ayarlanır BLAS (kodlanmış).

  • İşletim Sistemi : Suse
  • Intel Derleyici : ictce-5.3.0
  • Huysuz: 1.8.0
  • OpenBLAS: 0.2.6
  • ATLAS : 3.8.4

Nokta-Ürün Karşılaştırması

Karşılaştırma kodu aşağıdaki ile aynıdır. Ancak yeni makineler için 5000 ve 8000 matris boyutları için de kıyaslama yaptım .
Aşağıdaki tablo, orijinal yanıttan karşılaştırma sonuçlarını içermektedir (yeniden adlandırılmış: MKL -> Nehalem MKL, Netlib Blas -> Nehalem Netlib BLAS, vb.)

Matris çarpımı (boyutlar = [1000,2000,3000,5000,8000])

Tek iş parçacıklı performans: tek iş parçacıklı performans

Çok iş parçacıklı performans (8 iş parçacığı): çok iş parçacıklı (8 iş parçacığı) performansı

Dişler ve Matris boyutu (Ivy Bridge MKL) : Matris boyutu vs iş parçacıkları

Benchmark Süit

kıyaslama paketi

Tek iş parçacıklı performans: görüntü açıklamasını buraya girin

Çok iş parçacıklı (8 iş parçacıklı) performans: görüntü açıklamasını buraya girin

Sonuç

Yeni kıyaslama sonuçları orijinal cevaptakilere benzer. OpenBLAS ve MKL hariç, aynı seviyede gerçekleştirmek Özdeğer testi. Özdeğer testi gerçekleştirir sadece oldukça iyi üzerinde OpenBLAS içinde tek dişli mod . Çok iş parçacıklı modda performans daha kötüdür.

"İpler grafik vs Matris boyutu" da MKL olarak OpenBLAS genellikle göbek / iplik sayısı ile de büyütülebilir rağmen, matris büyüklüğüne bağlı olduğunu gösteriyor. Küçük matrisler için daha fazla çekirdek eklemek performansı çok fazla artırmaz.

Yaklaşık olarak% 30 bir performans artışı da vardır Sandy Bridge için Ivy Bridge daha yüksek saat hızında (+ 0.8 Ghz) ve / veya daha iyi bir mimariye ya bağlı olabilir.


Orjinal Cevap (04.10.2011):

Bir süre önce numpy ve BLAS kullanarak python ile yazılmış bazı doğrusal cebir hesaplamalarını / algoritmalarını optimize etmem gerekiyordu, bu yüzden farklı numpy / BLAS konfigürasyonlarını kıyasladım / test ettim.

Özellikle test ettim:

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

İki farklı kıyaslama yaptım:

  1. farklı boyutlara sahip matrislerin basit iç çarpımı
  2. Burada bulunan kıyaslama paketi .

İşte sonuçlarım:

Makineler

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

  • İşletim Sistemi : Ubuntu Lucid 10.4 64 Bit.
  • CPU : 2 x 4 Intel (R) Xeon (R) E5504 @ 2.00GHz (8 Çekirdek)
  • RAM : 24 GB
  • Intel Derleyici : 11.1 / 073
  • Scipy : 0.8
  • Huysuz : 1.5

Mac Book Pro (Accelerate Framework):

  • İşletim Sistemi : Mac OS X Snow Leopard (10.6)
  • CPU : 1 Intel Core 2 Duo 2.93 Ghz (2 Çekirdek)
  • RAM : 4 GB
  • Scipy : 0.7
  • Huysuz : 1.3

Mac Sunucusu (Accelerate Framework):

  • İşletim Sistemi : Mac OS X Snow Leopard Server (10.6)
  • CPU : 4 X Intel (R) Xeon (R) E5520 @ 2.26 Ghz (8 Çekirdek)
  • RAM : 4 GB
  • Scipy : 0.8
  • Uyuşuk : 1.5.1

Nokta ürün karşılaştırması

Kod :

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

Sonuçlar :

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

Nokta ürün karşılaştırması - grafik

Benchmark Süit

Kod : Karşılaştırma
paketi hakkında ek bilgi için buraya bakın .

Sonuçlar :

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

Karşılaştırma paketi - grafik

Kurulum

Montajı MKL oldukça yalındır komple Intel Derleyici Suite yükleme dahil. Ancak bazı hatalar / sorunlar nedeniyle, MKL desteği ile numpy'yi yapılandırmak ve derlemek biraz güçlük çekiyordu.

GotoBlas2 , paylaşımlı bir kitaplık olarak kolayca derlenebilen küçük bir pakettir. Ancak bir hata nedeniyle, numpy ile kullanmak için oluşturduktan sonra paylaşılan kitaplığı yeniden oluşturmanız gerekir.
Bu binaya ek olarak, birden fazla hedef platform için bir nedenden dolayı işe yaramadı. Bu yüzden , optimize edilmiş bir libgoto2.so dosyasına sahip olmak istediğim her platform için bir .so dosyası oluşturmam gerekiyordu .

Eğer Ubuntu'nun deposundan numpy yüklerseniz otomatik yükleyecek ve yapılandırmak numpy kullanmak ATLAS . ATLAS'ı kaynaktan yüklemek biraz zaman alabilir ve bazı ek adımlar gerektirir (fortran, vb.).

Numpy'yi Fink veya Mac Bağlantı Noktaları olan bir Mac OS X makinesine yüklerseniz, numpy'yi ATLAS veya Apple'ın Accelerate Framework'ü kullanacak şekilde yapılandıracaktır . Ldd'yi numpy.core._dotblas dosyasında çalıştırarak veya numpy.show_config () 'i çağırarak kontrol edebilirsiniz .

Sonuçlar

MKL en iyi performansı verir ve onu GotoBlas2 izler .
Gelen özdeğer testi GotoBlas2 beklenenden daha şaşırtıcı derecede kötü bir performans sergiliyor. Neden böyle olduğundan emin değilim.
Apple'ın Accelerate Framework'ü, özellikle tek iş parçacıklı modda (diğer BLAS uygulamalarıyla karşılaştırıldığında) gerçekten iyi performans gösteriyor.

Hem GotoBlas2 hem de MKL , iş parçacığı sayısıyla çok iyi ölçeklenir. Bu nedenle, birden fazla iş parçacığı üzerinde çalışan büyük matrislerle uğraşmak zorunda kalırsanız, çok yardımcı olacaktır.

Her durumda, varsayılan netlib blas uygulamasını kullanmayın çünkü herhangi bir ciddi hesaplama işi için çok yavaştır.

Bizim kümede ben de yüklü AMD'nin ACML ve performans benziyordu MKL ve GotoBlas2 . Zor numaralarım yok.

Kişisel olarak GotoBlas2'yi kullanmanızı tavsiye ederim çünkü kurulumu daha kolay ve ücretsiz.

C ++ / C ile kodlamak istiyorsanız , bazı durumlarda MKL / GotoBlas2'den daha iyi performans göstermesi beklenen ve kullanımı oldukça kolay olan Eigen3'e de göz atın .


Bu ayrıntılı cevap için çok teşekkür ederim!
Woltan

Çok kapsamlı, teşekkürler! Merak ediyorum, üç yıl sonra, OpenBLAS'ın (bildiğim kadarıyla, GotoBLAS'ın soyundan geliyor) daha iyi performans gösterip göstermeyeceğini merak ediyorum. MKL'den daha iyi performans gösterdiğini bir yerde okudum, ancak şu anda kaynağı bulamıyorum.

Teşekkürler! Bu benim izlenimim (bunun sadece benim kurulumum olup olmadığını merak ediyordum): Matrisler köşegenleştirme söz konusu olduğunda OpenBLAS çok iş parçacıklı modda çok iyi performans göstermiyor (OpenBLAS ile bağlantılı olan scipy'de köşegenleştiriyorum).

@William: genellikle scipy'yi openblas'a özel olarak bağlamanız gerekmez çünkü yükleme sırasında numpy yapılandırmasını kullanır ve aslında çoğu BLAS / Lapack çağrısı yine de numpy'ye yönlendirilir. Yani eğer uyuşukluk openblas ile doğru bir şekilde bağlantılıysa, her şey yolunda gitmelidir.
Ümit

@ Ümit: Teşekkürler! Şimdi MKL'ye bağlanmak için numpy kurmaya çalışıyorum.

20

İşte başka bir karşılaştırma ölçütü (Linux'ta sadece yazın make): http://dl.dropbox.com/u/5453551/blas_call_benchmark.zip

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

Numpy, Ctypes ve Fortran arasında, büyük matrisler için farklı yöntemler arasında esasen herhangi bir fark görmüyorum. (C ++ yerine Fortran --- ve bu önemliyse, kıyaslamanız muhtemelen bozulmuştur.)

Sizin CalcTimeC ++ işlevi bir işareti hatası var gibi gözüküyor. ... + ((double)start.tv_usec))onun yerine olmalı ... - ((double)start.tv_usec)). Belki de karşılaştırmanızda başka hatalar da vardır, örneğin farklı BLAS kitaplıkları arasında karşılaştırma yapmak veya iş parçacığı sayısı gibi farklı BLAS ayarları veya gerçek zaman ile CPU zamanı arasında karşılaştırma yapmak?

DÜZENLEME : CalcTimeişlevdeki küme ayracı sayılamadı - sorun değil.

Bir kılavuz olarak: Eğer bir kıyaslama yaparsanız, lütfen her zaman tüm kodu bir yere gönderin . Karşılaştırmalar hakkında yorum yapmak, özellikle şaşırtıcı olduğunda, tam koda sahip olmadan genellikle verimli değildir.


Hangi BLAS Numpy'nin bağlantılı olduğunu bulmak için şunları yapın:

$ python
Python 2.7.2+ (varsayılan, 16 Ağu 2011, 07:24:41) 
Linux2 üzerinde [GCC 4.6.1]
Daha fazla bilgi için "yardım", "telif hakkı", "kredi" veya "lisans" yazın.
>>> numpy.core._dotblas'ı içe aktar
>>> 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)

GÜNCELLEME : Eğer varsa edemez ithalat numpy.core._dotblas, sizin Numpy yavaştır BLAS iç geri dönüş kopyalama, kullanma ve performans hesaplama kullanılmak üzere tasarlanmamıştır! Aşağıdaki @ Woltan'dan gelen yanıt, bunun Numpy ve Ctypes + BLAS'ta gördüğü farkın açıklaması olduğunu gösteriyor.

Durumu düzeltmek için ATLAS veya MKL'ye ihtiyacınız var - şu talimatları kontrol edin: http://scipy.org/Installing_SciPy/Linux Çoğu Linux dağıtımı ATLAS ile birlikte gönderilir, bu nedenle en iyi seçenek libatlas-devpaketlerini yüklemektir (isim değişebilir) .


Benchmarkınızı çalıştırdım; sonuçlar aynı
jfs

Gönderdiğiniz için çok teşekkür ederim. Bu sonuçla kıyaslamanızı yaptım . Bu yüzden seninkini yeniden üretemem. Uyuşturucumun hangi BLAS'ı kullandığını kontrol etmek için: Yapamam import numpy.core._dotblas. burdaki problem ne olabilir? Diğerlerinin test etmesi için kıyaslamamı temizlemeye ve bir makefile yazmaya çalışacağım.
Woltan

2
@Woltan: numpy.core._dotblas'ı içe aktaramamanız, Numpy'nizin sahip olduğunuz BLAS kitaplığı yerine BLAS'ın dahili yedek kopyasını ( daha yavaş ve performans hesaplamasında kullanılması amaçlanmamıştır!) Kullandığı anlamına gelir. sisteminizde. Bu, karşılaştırmadan aldığınız sonuçları açıklar. Durumu düzeltmek için, Numpy'nin çalışabileceği bir BLAS sürümü kurmanız gerekir - bu, ATLAS veya MKL anlamına gelir. İşte bir dizi talimat: scipy.org/Installing_SciPy/Linux
pv.

@pv .: Sonuçları karşılaştırmak için Woltan'ın benchmarkını çalıştırabilir misiniz?
jfs

1
Mac'te, Linux'ta otool -Lyerine kullanabilirsinizldd
RichVel

9

Analizinizle gösterdiğiniz titizlik göz önüne alındığında, şimdiye kadarki sonuçlara şaşırdım. Bunu bir 'cevap' olarak koyuyorum, ancak yalnızca bir yorum için çok uzun olduğu ve bir olasılık sağladığı için (yine de düşündüğünüzü umuyorum).

Karmaşıklık arttıkça, python'un katıldığı oranın küçük olması gerektiğinden, numpy / python yaklaşımının makul karmaşıklığa sahip bir matris için fazla ek yük getirmeyeceğini düşünürdüm. Grafiğin sağ tarafındaki sonuçlarla daha çok ilgileniyorum, ancak burada gösterilen büyüklük farklılıkları rahatsız edici olacaktır.

Acaba uyuşukluğun yararlanabileceği en iyi algoritmaları kullanıyor musunuz? Linux için derleme kılavuzundan:

"Derleme FFTW (3.1.2): SciPy Sürümleri> = 0.7 ve Numpy> = 1.2: Lisans, yapılandırma ve bakım sorunları nedeniyle, SciPy> = 0.7 ve NumPy> = 1.2 sürümlerinde FFTW desteği kaldırıldı. Bunun yerine artık fftpack'in yerleşik bir sürümü. Analiziniz için gerekirse FFTW'nin hızından yararlanmanın birkaç yolu vardır. Destek içeren bir Numpy / Scipy sürümüne geçin. Kendi FFTW paketinizi kurun veya oluşturun. Bkz. http: //developer.berlios.de/projects/pyfftw/ onaylanmamış bir örnek olarak. "

Numpy'yi mkl ile derlediniz mi? ( http://software.intel.com/en-us/articles/intel-mkl/ ). Linux üzerinde çalışıyorsanız, mkl ile numpy derleme talimatları burada: http://www.scipy.org/Installing_SciPy/Linux#head-7ce43956a69ec51c6f2cedd894a4715d5bfff974 (url'ye rağmen). Anahtar kısım şudur:

[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 

Windows'taysanız, mkl ile derlenmiş bir ikili dosya elde edebilirsiniz (ve ayrıca pyfftw ve diğer birçok ilgili algoritmayı elde edebilirsiniz): http://www.lfd.uci.edu/~gohlke/pythonlibs/ , UC Irvine Floresan Dinamikleri Laboratuvarı'ndan Christoph Gohlke'ye minnettarlık borcu.

Uyarı, her iki durumda da, pek çok lisans sorunu vb. Vardır, ancak bilgi sayfası bunları açıklar. Yine, bunu düşündüğünüzü hayal ediyorum, ancak lisanslama gereksinimlerini karşılıyorsanız (ki bunu linux'ta yapmak çok kolaydır), bu, FFTW bile olmadan basit bir otomatik yapı kullanmaya göre çok daha fazla hızlanacaktır. Bu konuyu takip etmek ve başkalarının ne düşündüğünü görmekle ilgileneceğim. Ne olursa olsun, mükemmel titizlik ve mükemmel bir soru. Gönderdiğiniz için teşekkürler.


Ayrıntılı "yorumunuz" için teşekkür ederiz ^^. Python / numpy / BLAS kurulumumu netleştirmek için: Bu kurulum kılavuzunu takip ettim . Linux işletim sistemindeyim ve sürümler: Python 2.7, Scipy 0.9 Numpy 1.6. Ne yazık ki ne ben mkl kullandı, elden önce FFTW inşa etmedi ...
Woltan

Bir bakıma şanslı. Bu, python sonuçlarında iyileştirme için çok büyük bir alan olduğu ve python kullanmak istediğiniz gibi göründüğü anlamına gelir. Bence yapınızı bağlantıda gösterilenle değiştirirseniz, numpy'nin hızından çok daha mutlu olacaksınız, ancak yine de C ++ uygulamanıza kıyasla nasıl olduğunu görmek beni büyülüyor.
Saygısız

ATLAS'ı da oluşturmayı deneyebilirsiniz, ancak bu performans ihtiyaçlarım için çok fazla baş ağrısı gibi geldi, bu yüzden hiç deneyimim yok. Python kullanmakla ilgileniyorsanız ancak C ++ kullanabiliyorsanız, çok sayıda özel derleme yapmanın kurulum maliyetinin dil tasarruflarından daha ağır basacağı ve c ++ 'ı yapmak daha kolay olacağı bir noktada olduğunu hayal ediyorum. Ancak mkl ve fftw'nin her ikisi de oldukça basit olmalıdır.
Saygısız

1
Şu anda MKL, Accelerate ve OpenBLAS performans açısından benzerdir. OpenBLAS, yine de MKL'den daha ölçeklenebilir.
Sturla Molden
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.