Đo điểm chuẩn (python so với c ++ sử dụng BLAS) và (numpy)


107

Tôi muốn viết một chương trình sử dụng rộng rãi các hàm đại số tuyến tính BLAS và LAPACK. Vì hiệu suất là một vấn đề, tôi đã thực hiện một số điểm chuẩn và muốn biết, nếu cách tiếp cận tôi đã thực hiện là hợp pháp.

Có thể nói, tôi có ba thí sinh và muốn kiểm tra hiệu suất của họ bằng một phép nhân ma trận đơn giản. Các thí sinh là:

  1. Numpy, chỉ sử dụng chức năng của dot.
  2. Python, gọi các chức năng BLAS thông qua một đối tượng được chia sẻ.
  3. C ++, gọi các chức năng BLAS thông qua một đối tượng được chia sẻ.

Tình huống

Tôi đã thực hiện phép nhân ma trận cho các chiều khác nhau i. ichạy từ 5 đến 500 với gia số là 5 và các ma trận m1m2được thiết lập như sau:

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

1. Numpy

Mã được sử dụng trông giống như sau:

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

2. Python, gọi BLAS thông qua một đối tượng được chia sẻ

Với chức năng

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

mã kiểm tra trông như thế này:

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 ++, gọi BLAS thông qua một đối tượng được chia sẻ

Bây giờ mã c ++ tự nhiên dài hơn một chút vì vậy tôi giảm thông tin xuống mức tối thiểu.
Tôi tải chức năng với

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

Tôi đo thời gian với gettimeofdaynhư thế này:

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

đâu jlà một vòng lặp chạy 20 lần. Tôi tính toán thời gian trôi qua với

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

Các kết quả

Kết quả được hiển thị trong biểu đồ dưới đây:

nhập mô tả hình ảnh ở đây

Câu hỏi

  1. Bạn có nghĩ rằng cách tiếp cận của tôi là công bằng hay có một số chi phí không cần thiết mà tôi có thể tránh?
  2. Bạn có mong đợi rằng kết quả sẽ cho thấy sự khác biệt rất lớn giữa phương pháp c ++ và python không? Cả hai đều đang sử dụng các đối tượng được chia sẻ để tính toán.
  3. Vì tôi muốn sử dụng python cho chương trình của mình, tôi có thể làm gì để tăng hiệu suất khi gọi quy trình BLAS hoặc LAPACK?

Tải xuống

Điểm chuẩn hoàn chỉnh có thể được tải xuống tại đây . (JF Sebastian đã biến liên kết đó thành khả thi ^^)


trong cách tiếp cận ctypes của bạn, bạn có phân bổ bộ nhớ bên trong hàm được đo. Mã c ++ của bạn có tuân theo cách tiếp cận này không? Nhưng so với phép nhân ma trận này không nên tạo sự khác biệt lớn ....
rocksportrocker

@rocksportrocker Bạn nói đúng. Việc phân bổ bộ nhớ cho rma trận là không công bằng. Tôi đang giải quyết "vấn đề" ngay bây giờ và đăng kết quả mới.
Woltan

1. đảm bảo rằng các mảng có cùng bố cục bộ nhớ np.ascontiguousarray()(xem xét thứ tự C so với Fortran). 2. chắc chắn rằng np.dot()sử dụng như nhau libblas.so.
jfs 29/09/11

@JFSebastian Cả hai mảng m1m2ascontiguousarraycờ là True. Và numpy sử dụng cùng một đối tượng được chia sẻ như C. Đối với thứ tự của mảng: Hiện tại tôi không quan tâm đến kết quả tính toán nên thứ tự không liên quan.
Woltan

1
@Woltan: không sử dụng filefactory dịch vụ thật tệ. Tôi đã thêm điểm chuẩn của bạn vào github: woltan-benchmark . Nếu bạn sử dụng github, tôi có thể thêm bạn làm cộng tác viên.
jfs

Câu trả lời:


58

Tôi đã chạy điểm chuẩn của bạn . Không có sự khác biệt giữa C ++ và numpy trên máy của tôi:

điểm chuẩn của woltan

Bạn có nghĩ rằng cách tiếp cận của tôi là công bằng hay có một số chi phí không cần thiết mà tôi có thể tránh?

Nó có vẻ công bằng do không có sự khác biệt trong kết quả.

Bạn có mong đợi rằng kết quả sẽ cho thấy sự khác biệt rất lớn giữa phương pháp c ++ và python không? Cả hai đều đang sử dụng các đối tượng được chia sẻ để tính toán.

Không.

Vì tôi muốn sử dụng python cho chương trình của mình, tôi có thể làm gì để tăng hiệu suất khi gọi quy trình BLAS hoặc LAPACK?

Đảm bảo rằng numpy sử dụng phiên bản tối ưu hóa của các thư viện BLAS / LAPACK trên hệ thống của bạn.


4
Vậy người đăng ban đầu đã làm gì sai? Tôi ước anh ấy đã bình luận về bài đăng này. Anh ta có xác nhận rằng Numpy nhanh như C ++ không?
wmac

Mã C ++ của bạn đang chạy chậm hơn các áp phích gốc. Bạn đã biên dịch dưới sự tối ưu hóa?
cdcdcd

@cdcdcd nó không phải là mã của tôi. Nhấp vào liên kết và tự chạy điểm chuẩn với các tùy chọn tối ưu hóa khác nhau (xem Makefile). Mặc dù mã không biên dịch lại, không blas hay lỗi.
jfs

73

CẬP NHẬT (30.07.2014):

Tôi chạy lại điểm chuẩn trên HPC mới của chúng tôi. Cả phần cứng cũng như phần mềm đã thay đổi so với thiết lập trong câu trả lời ban đầu.

Tôi đưa kết quả vào một bảng tính của google (cũng chứa các kết quả từ câu trả lời ban đầu).

Phần cứng

HPC của chúng tôi có hai nút khác nhau, một với CPU Intel Sandy Bridge và một với CPU Ivy Bridge mới hơn:

Sandy (MKL, OpenBLAS, ATLAS):

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

Ivy (MKL, OpenBLAS, ATLAS):

  • CPU : 2 x 20 Intel (R) Xeon (R) E2680 V2 Ivy Bridge @ 2,80GHz (20 lõi, với HT = 40 lõi)
  • RAM : 256 GB

Phần mềm

Ngăn xếp phần mềm dành cho cả hai nút sam. Thay vì GotoBLAS2 , OpenBLAS được sử dụng và cũng có ATLAS BLAS đa luồng được đặt thành 8 luồng (mã cứng).

  • OS : Suse
  • Trình biên dịch Intel : ictce-5.3.0
  • Numpy: 1.8.0
  • OpenBLAS: 0.2.6
  • ATLAS :: 3.8.4

Điểm chuẩn chấm sản phẩm

Mã điểm chuẩn giống như bên dưới. Tuy nhiên, đối với các máy mới, tôi cũng chạy điểm chuẩn cho kích thước ma trận 50008000 .
Bảng bên dưới bao gồm các kết quả điểm chuẩn từ câu trả lời ban đầu (được đổi tên: MKL -> Nehalem MKL, Netlib Blas -> Nehalem Netlib BLAS, v.v.)

Phép nhân ma trận (kích thước = [1000,2000,3000,5000,8000])

Hiệu suất luồng đơn: hiệu suất đơn luồng

Hiệu suất đa luồng (8 luồng): hiệu suất đa luồng (8 luồng)

Chủ đề so với kích thước ma trận (Ivy Bridge MKL) : Kích thước ma trận so với chủ đề

Benchmark Suite

bộ tiêu chuẩn

Hiệu suất luồng đơn: nhập mô tả hình ảnh ở đây

Hiệu suất đa luồng (8 luồng): nhập mô tả hình ảnh ở đây

Phần kết luận

Kết quả điểm chuẩn mới tương tự như kết quả trong câu trả lời gốc. OpenBLASMKL thực hiện ở cùng một cấp độ, ngoại trừ kiểm tra Eigenvalue . Các Eigenvalue Thực hiện kiểm tra chỉ khá tốt trên OpenBLAS trong chế độ đơn luồng . Ở chế độ đa luồng, hiệu suất kém hơn.

Các "kích thước Matrix vs đề Chart" cũng cho thấy rằng mặc dù MKL cũng như OpenBLAS nói chung quy mô tốt với số lượng lõi / chủ đề, nó phụ thuộc vào kích thước của ma trận. Đối với ma trận nhỏ, việc thêm nhiều lõi sẽ không cải thiện hiệu suất nhiều lắm.

Cũng có sự gia tăng hiệu suất khoảng 30% từ Sandy Bridge đến Ivy Bridge , có thể là do tốc độ xung nhịp cao hơn (+ 0,8 Ghz) và / hoặc kiến ​​trúc tốt hơn.


Câu trả lời gốc (04.10.2011):

Một thời gian trước, tôi đã phải tối ưu hóa một số phép tính / thuật toán đại số tuyến tính được viết bằng python sử dụng numpy và BLAS vì vậy tôi đã chuẩn hóa / thử nghiệm các cấu hình numpy / BLAS khác nhau.

Cụ thể tôi đã thử nghiệm:

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

Tôi đã chạy hai điểm chuẩn khác nhau:

  1. sản phẩm chấm đơn giản của ma trận với các kích thước khác nhau
  2. Bộ điểm chuẩn có thể được tìm thấy tại đây .

Đây là kết quả của tôi:

Máy móc

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

  • Hệ điều hành : Ubuntu Lucid 10.4 64 Bit.
  • CPU : 2 x 4 Intel (R) Xeon (R) E5504 @ 2.00GHz (8 lõi)
  • RAM : 24 GB
  • Trình biên dịch Intel : 11.1 / 073
  • Scipy : 0,8
  • Numpy : 1,5

Mac Book Pro (Khung tăng tốc):

  • Hệ điều hành : Mac OS X Snow Leopard (10.6)
  • CPU : 1 Intel Core 2 Duo 2.93 Ghz (2 lõi)
  • RAM : 4 GB
  • Scipy : 0,7
  • Numpy : 1,3

Máy chủ Mac (Khung tăng tốc):

  • Hệ điều hành : Mac OS X Snow Leopard Server (10.6)
  • CPU : 4 X Intel (R) Xeon (R) E5520 @ 2,26 Ghz (8 lõi)
  • RAM : 4 GB
  • Scipy : 0,8
  • Numpy : 1.5.1

Chấm điểm chuẩn sản phẩm

:

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

Kết quả :

    Hệ thống | kích thước = 1000 | kích thước = 2000 | kích thước = 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 |
Máy chủ Mac (1 CPU) | 92 ms | 714 ms | 2130 ms |

Chấm điểm chuẩn sản phẩm - biểu đồ

Benchmark Suite

:
Để biết thêm thông tin về bộ điểm chuẩn, hãy xem tại đây .

Kết quả :

    Hệ thống | eigenvalues ​​| svd | det | inv | dấu chấm |
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 giây | 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 giây | 82 ms | 262 ms | 192 ms |
Mac OS X (1 CPU) | 948 ms | 4339 ms | 151 ms | 318 ms | 566 ms |
Máy chủ Mac (1 CPU) | 1033 ms | 3645 ms | 99 ms | 232 ms | 342 ms |

Bộ điểm chuẩn - biểu đồ

Cài đặt

Cài đặt MKL bao gồm cài đặt Bộ trình biên dịch Intel hoàn chỉnh, khá đơn giản. Tuy nhiên, vì một số lỗi / sự cố, việc cấu hình và biên dịch numpy với sự hỗ trợ của MKL có một chút rắc rối.

GotoBlas2 là một gói nhỏ có thể dễ dàng biên dịch như một thư viện chia sẻ. Tuy nhiên, vì một lỗi, bạn phải tạo lại thư viện chia sẻ sau khi xây dựng nó để sử dụng nó với numpy.
Ngoài tòa nhà này, nó cho nhiều plattform mục tiêu không hoạt động vì một số lý do. Vì vậy, tôi phải tạo tệp .so cho mỗi nền tảng mà tôi muốn có tệp libgoto2.so được tối ưu hóa .

Nếu bạn cài đặt numpy từ kho lưu trữ của Ubuntu, nó sẽ tự động cài đặt và cấu hình numpy để sử dụng ATLAS . Việc cài đặt ATLAS từ nguồn có thể mất một chút thời gian và yêu cầu một số bước bổ sung (fortran, v.v.).

Nếu bạn cài đặt numpy trên máy Mac OS X có Fink hoặc Mac Ports, nó sẽ cấu hình numpy để sử dụng ATLAS hoặc Khung tăng tốc của Apple . Bạn có thể kiểm tra bằng cách chạy ldd trên tệp numpy.core._dotblas hoặc gọi numpy.show_config () .

Kết luận

MKL thực hiện tốt nhất theo sát bởi GotoBlas2 .
Trong bài kiểm tra giá trị riêng, GotoBlas2 hoạt động kém hơn mong đợi một cách đáng ngạc nhiên. Không chắc tại sao lại như vậy.
Khung tăng tốc của Apple hoạt động thực sự tốt, đặc biệt là ở chế độ đơn luồng (so với các triển khai BLAS khác).

Cả GotoBlas2MKL đều quy mô rất tốt với số lượng chủ đề. Vì vậy, nếu bạn phải đối phó với các ma trận lớn thì việc chạy nó trên nhiều luồng sẽ giúp ích rất nhiều.

Trong mọi trường hợp, không sử dụng cài đặt blas netlib mặc định vì nó quá chậm đối với bất kỳ công việc tính toán nghiêm túc nào.

Trên cụm của chúng tôi, tôi cũng đã cài đặt ACML của AMD và hiệu suất tương tự như MKLGotoBlas2 . Tôi không có bất kỳ con số khó khăn.

Cá nhân tôi khuyên bạn nên sử dụng GotoBlas2 vì nó dễ cài đặt hơn và nó miễn phí.

Nếu bạn muốn viết mã bằng C ++ / C, hãy xem Eigen3 được cho là hoạt động tốt hơn MKL / GotoBlas2 trong một số trường hợp và cũng khá dễ sử dụng.


Cảm ơn bạn rất nhiều vì câu trả lời công phu này!
Woltan

Rất toàn diện, cảm ơn bạn! Tôi tự hỏi, ba năm sau, liệu OpenBLAS (theo tôi biết, nó là hậu duệ của GotoBLAS) sẽ hoạt động tốt hơn. Tôi đã đọc ở đâu đó rằng nó tốt hơn MKL, nhưng không thể tìm thấy nguồn ngay bây giờ.

Cảm ơn! Đây là ấn tượng của tôi đối với 0 (Tôi đã tự hỏi liệu đây có phải chỉ là cài đặt của tôi không): OpenBLAS hoạt động không tốt ở chế độ đa luồng khi nói đến ma trận chéo hóa (tôi chéo hóa trong scipy, được liên kết với OpenBLAS).

@William: thường thì bạn không cần phải liên kết cụ thể scipy với openblas vì nó sẽ sử dụng cấu hình numpy trong khi cài đặt và thực tế hầu hết các cuộc gọi BLAS / Lapack sẽ được chuyển tiếp tới numpy. Vì vậy, nếu numpy được liên kết đúng cách với openblas, mọi thứ sẽ hoạt động tốt.
mit

@ Ümit: Cảm ơn! Tôi đang cố gắng thiết lập numpy để liên kết với MKL ngay bây giờ.

20

Đây là một điểm chuẩn khác (trên Linux, chỉ cần nhập make): http://dl.dropbox.com/u/5453551/blas_call_benchmark.zip

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

Về cơ bản, tôi không thấy bất kỳ sự khác biệt nào giữa các phương pháp khác nhau cho ma trận lớn, giữa Numpy, Ctypes và Fortran. (Fortran thay vì C ++ --- và nếu điều này quan trọng, điểm chuẩn của bạn có thể bị hỏng.)

CalcTimeHàm của bạn trong C ++ dường như có lỗi dấu. ... + ((double)start.tv_usec))nên được thay thế ... - ((double)start.tv_usec)). Có lẽ điểm chuẩn của bạn cũng có các lỗi khác, ví dụ: so sánh giữa các thư viện BLAS khác nhau hoặc cài đặt BLAS khác nhau như số luồng hoặc giữa thời gian thực và thời gian CPU?

CHỈNH SỬA : không đếm được dấu ngoặc nhọn trong CalcTimehàm - không sao cả.

Theo hướng dẫn: nếu bạn làm điểm chuẩn, hãy luôn đăng tất cả mã ở đâu đó. Nhận xét về điểm chuẩn, đặc biệt là khi đáng ngạc nhiên, mà không có mã đầy đủ thường không hiệu quả.


Để tìm hiểu BLAS Numpy được liên kết chống lại, hãy làm:

$ python
Python 2.7.2+ (mặc định, ngày 16 tháng 8 năm 2011, 07:24:41) 
[GCC 4.6.1] trên linux2
Nhập "trợ giúp", "bản quyền", "tín dụng" hoặc "giấy phép" để biết thêm thông tin.
>>> nhập 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)

CẬP NHẬT : Nếu bạn không thể nhập numpy.core._dotblas, Numpy của bạn đang sử dụng bản sao BLAS dự phòng bên trong, bản sao này chậm hơn và không có nghĩa là được sử dụng trong tính toán hiệu suất! Câu trả lời từ @Woltan bên dưới chỉ ra rằng đây là lời giải thích cho sự khác biệt mà anh ấy / cô ấy thấy trong Numpy so với Ctypes + BLAS.

Để khắc phục tình trạng này, bạn cần ATLAS hoặc MKL --- hãy kiểm tra các hướng dẫn sau: http://scipy.org/Installing_SciPy/Linux Hầu hết các bản phân phối Linux đều có ATLAS, vì vậy tùy chọn tốt nhất là cài đặt libatlas-devgói của chúng (tên có thể khác nhau) .


Tôi đã chạy điểm chuẩn của bạn; kết quả giống nhau
jfs 29/09

Cảm ơn bạn rất nhiều cho bài viết của bạn. Tôi đã chạy điểm chuẩn của bạn với kết quả này . Vì vậy, tôi không thể tái tạo của bạn. Để kiểm tra BLAS mà numpy của tôi đang sử dụng: Tôi không thể import numpy.core._dotblas. Vấn đề ở đây là gì? Tôi sẽ cố gắng làm sạch điểm chuẩn của mình bằng cách viết một tệp makefile để người khác kiểm tra nó.
Woltan

2
@Woltan: thực tế là bạn không thể nhập numpy.core._dotblas có nghĩa là Numpy của bạn đang sử dụng bản sao dự phòng nội bộ của BLAS ( chậm hơn và không có nghĩa là được sử dụng trong tính toán hiệu suất!), Chứ không phải thư viện BLAS mà bạn có trên hệ thống của bạn. Điều này giải thích kết quả bạn nhận được từ điểm chuẩn. Để khắc phục tình trạng này, bạn cần cài đặt phiên bản BLAS mà Numpy có thể làm việc với --- nghĩa là ATLAS hoặc MKL. Đây là một tập hợp các hướng dẫn: scipy.org/Installing_SciPy/Linux
pv.

@pv .: Bạn có thể chạy điểm chuẩn của Woltan để so sánh kết quả được không.
jfs 30/09/11

1
Trên máy Mac, bạn có thể sử dụng otool -Lthay vì lddtrên Linux
RichVel

9

Với sự nghiêm ngặt mà bạn đã thể hiện với phân tích của mình, tôi rất ngạc nhiên về kết quả cho đến nay. Tôi đặt đây là một 'câu trả lời' nhưng chỉ vì nó quá dài cho một nhận xét và không cung cấp một khả năng (mặc dù tôi hy vọng bạn đã xem xét nó).

Tôi sẽ nghĩ rằng cách tiếp cận numpy / python sẽ không thêm nhiều chi phí cho một ma trận có độ phức tạp hợp lý, vì khi độ phức tạp tăng lên, tỷ lệ mà python tham gia sẽ nhỏ. Tôi quan tâm nhiều hơn đến kết quả ở phía bên phải của biểu đồ, nhưng sự khác biệt về thứ tự độ lớn được hiển thị ở đó sẽ đáng lo ngại.

Tôi tự hỏi liệu bạn có đang sử dụng các thuật toán tốt nhất mà numpy có thể tận dụng hay không. Từ hướng dẫn biên dịch cho linux:

"Xây dựng FFTW (3.1.2): Các phiên bản SciPy> = 0,7 và Numpy> = 1,2: Do các vấn đề về giấy phép, cấu hình và bảo trì, hỗ trợ cho FFTW đã bị xóa trong các phiên bản của SciPy> = 0,7 và NumPy> = 1,2. Thay vào đó bây giờ sử dụng phiên bản fftpack tích hợp sẵn. Có một số cách để tận dụng tốc độ của FFTW nếu cần thiết cho phân tích của bạn. Hạ cấp xuống phiên bản Numpy / Scipy có hỗ trợ. Cài đặt hoặc tạo trình bao bọc FFTW của riêng bạn. Xem http: //developer.berlios.de/projects/pyfftw/ làm ví dụ chưa được chứng thực. "

Bạn đã biên dịch numpy với mkl? ( http://software.intel.com/en-us/articles/intel-mkl/ ). Nếu bạn đang chạy trên linux, hướng dẫn biên dịch numpy với mkl tại đây: http://www.scipy.org/Installing_SciPy/Linux#head-7ce43956a69ec51c6f2cedd894a4715d5bfff974 (mặc dù có url). Phần quan trọng là:

[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 

Nếu bạn đang sử dụng windows, bạn có thể lấy tệp nhị phân đã biên dịch với mkl, (và cũng có được pyfftw và nhiều thuật toán liên quan khác) tại: http://www.lfd.uci.edu/~gohlke/pythonlibs/ , với món nợ của lòng biết ơn đối với Christoph Gohlke tại Phòng thí nghiệm Động lực học huỳnh quang, UC Irvine.

Hãy lưu ý, trong cả hai trường hợp, có nhiều vấn đề cấp phép, v.v. cần lưu ý, nhưng trang intel giải thích những vấn đề đó. Một lần nữa, tôi tưởng tượng bạn đã cân nhắc điều này, nhưng nếu bạn đáp ứng các yêu cầu cấp phép (điều này trên linux rất dễ thực hiện), điều này sẽ tăng tốc phần numpy rất nhiều so với việc sử dụng một bản dựng tự động đơn giản, thậm chí không cần FFTW. Tôi sẽ quan tâm theo dõi chủ đề này và xem những người khác nghĩ gì. Bất chấp, sự chặt chẽ tuyệt vời và câu hỏi xuất sắc. Cảm ơn vì đã đăng nó.


Cảm ơn bạn vì "comment" công phu của bạn ^^. Để làm rõ thiết lập python / numpy / BLAS của tôi: Tôi đã làm theo hướng dẫn cài đặt này . Tôi đang sử dụng hệ điều hành linux và các phiên bản là: Python 2.7, Scipy 0.9 Numpy 1.6. Đáng tiếc là tôi đã không xây dựng FFTW trước mặt, tôi không phải đã sử dụng MKL ...
Woltan

Theo một cách nào đó, đó là điều may mắn. Điều đó có nghĩa là có rất nhiều cơ hội để cải thiện kết quả của python và có vẻ như bạn muốn sử dụng python. Tôi nghĩ nếu bạn sửa đổi bản dựng của mình thành bản được hiển thị trên liên kết, bạn sẽ thấy vui hơn nhiều với tốc độ của numpy, mặc dù tôi vẫn muốn xem nó như thế nào so với việc triển khai C ++ của bạn.
Nhục nhã

Bạn cũng có thể thử xây dựng ATLAS, nhưng điều đó nghe có vẻ quá đau đầu cho nhu cầu hiệu suất của tôi, vì vậy tôi không có bất kỳ kinh nghiệm nào. Tôi tưởng tượng nếu bạn quan tâm đến việc sử dụng python nhưng có thể sử dụng C ++, sẽ có một số thời điểm mà chi phí thiết lập để thực hiện nhiều biên dịch đặc biệt sẽ lớn hơn mức tiết kiệm ngôn ngữ và sẽ dễ dàng hơn khi thực hiện c ++. Nhưng mkl và fftw đều khá đơn giản.
Nhục nhã

1
Hiện tại MKL, Accelerate và OpenBLAS có hiệu suất tương tự nhau. OpenBLAS có khả năng mở rộng hơn MKL.
Sturla Molden
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.