Numpy: أوقات تشغيل طويلة للغاية في numpy.fft.fft (تتبع # 1266)

تم إنشاؤها على ١٩ أكتوبر ٢٠١٢ · 19تعليقات · مصدر: numpy/numpy

_Original Ticket http://projects.scipy.org/numpy/ticket/1266 بتاريخ 2009-10-19 بواسطة trac user koehler ، المخصصة لمجهول.

على الرغم من أن توثيق numpy.fft.fft ينص على ما يلي:
"هذا هو الأكثر فاعلية لـ na power من اثنين. هذا أيضًا يخزن ذاكرة تخزين مؤقت للذاكرة العاملة بأحجام مختلفة من fft ، لذلك يمكنك نظريًا مواجهة مشاكل في الذاكرة إذا اتصلت بهذا مرات عديدة مع عدد كبير جدًا من n's." ، أعتقد أنه قد يكون من المهم الإبلاغ عن هذه الغرابة في وقت التشغيل.
اعتمادًا على طول المصفوفة ، يختلف وقت تشغيل fft بشكل كبير جدًا:

[ipython shell, from numpy import *]
In [1]: %time fft.fft(zeros(119516))
CPU times: user 22.83 s, sys: 0.39 s, total: 23.23 s
Wall time: 23.53 s

In [3]: %time fft.fft(zeros(119517))
CPU times: user 36.33 s, sys: 0.08 s, total: 36.40 s
Wall time: 36.51 s

In [5]: %time fft.fft(zeros(119518))
CPU times: user 4.88 s, sys: 0.08 s, total: 4.96 s
Wall time: 5.02 s

In [7]: %time fft.fft(zeros(119519))
CPU times: user 0.45 s, sys: 0.00 s, total: 0.45 s
Wall time: 0.45 s

In [9]: %time fft.fft(zeros(119515))
CPU times: user 0.07 s, sys: 0.00 s, total: 0.08 s
Wall time: 0.08 s

In [11]: %time fft.fft(zeros(119514))
CPU times: user 15.84 s, sys: 0.06 s, total: 15.90 s
Wall time: 15.95 s

In [13]: %time fft.fft(zeros(119513))
CPU times: user 272.75 s, sys: 1.03 s, total: 273.78 s
Wall time: 275.63 s

00 - Bug numpy.fft

مصدر

thouis

التعليق الأكثر فائدة

يجب إصلاح هذا في numpy 1.17.

mreineck في ٥ أبريل ٢٠١٩

👍2

ال 19 كومينتر

_ @ كتب

ذات صلة: # 1177 http://projects.scipy.org/scipy/ticket/949

numpy-gitbot في ٢٣ أكتوبر ٢٠١٢

_ @ rgommers كتب بتاريخ 2011-03-01_

numpy-gitbot في ٢٣ أكتوبر ٢٠١٢

_ @ rgommers كتب بتاريخ 2011-03-01_

قام David C. بتنفيذ تحويل Bluestein إذا كنت بحاجة إليه: https://github.com/cournape/numpy/tree/bluestein

نأمل أن تهبط في جذع نامبي قريبًا.

numpy-gitbot في ٢٣ أكتوبر ٢٠١٢

تم تغيير الإنجاز إلى Unscheduled بواسطة mwiebe في 2011-03-25

numpy-gitbot في ٢٣ أكتوبر ٢٠١٢

في هذا pr يتم اقتراح حشوة للأعداد الأولية الصغيرة
https://github.com/scipy/scipy/pull/3144
قد يكون الحصول على وظيفة للحصول على حجم حشوة أفضل أداة مفيدة في numpys fftpack

juliantaylor في ١٨ يناير ٢٠١٤

نعم ، بدلاً من m = 2 ** nextpow2(2 * n - 1) ، سيكون من الأسرع استخدام شيء مثل الوظيفة next_regular

endolith في ١٩ يناير ٢٠١٤

لقد صادفت أيضًا هذه المشكلة باستخدام وظيفة اكتشاف التوازن في pymbar التي تستدعي مرارًا np.fft و np.ifft من خلال وظيفة الارتباط التلقائي لنماذج statsmodels على العديد من المصفوفات الأقصر بشكل متزايد. اكتشفت تنميط الكود ، الأمر الذي قادني في النهاية إلى هذا الموضوع. الحل الوحيد حتى الآن هو الاتصال صراحة

 np.fft.fftpack._fft_cache.clear()

للتأكد من أن متطلبات الذاكرة لا تنمو بشكل خطير. ومع ذلك ، لا يبدو أن هذا هو الحل المثالي. سيكون من الجيد أن يكون لديك kwarg مثل "memsafe = True" و / أو وظيفة لمسح ذاكرة التخزين المؤقت يدويًا دون الرجوع إلى المتغير العام بشكل صريح.

smcantab في ٢٦ يناير ٢٠١٥

juliantaylor Padding لا ينطبق على FFTs العادي ، أليس كذلك؟ فقط للالتفاف / الارتباط؟

rgommers تعمل خوارزمية Bluestein على تسريع FFT للأحجام الأولية ، كما هو الحال في https://github.com/scipy/scipy/issues/4288 ، ولكنها تتطلب حسابًا مسبقًا لأغنيات معقدة ، وتكون أكثر فعالية عندما تحتفظ بـ زقزقة في الذاكرة وإعادة استخدامها بشكل متكرر على أجزاء من البيانات. لذلك لست متأكدًا مما إذا كان هذا مفيدًا لـ numpy وربما فقط تأجيل scipy.fftpack.czt لهذا التطبيق؟

على أي حال أعتقد أنه يمكن إغلاق هذا كنسخة مكررة من https://github.com/numpy/numpy/issues/1177 ؟ ما لم يكن شيء آخر مثل خوارزمية رايدر أفضل من خوارزمية بلوستين؟

ومسألة @ smcantab مختلفة؟

endolith في ١٦ فبراير ٢٠١٦

endolith كان هذا منذ وقت طويل :) لكن نعم ، الآن بعد أن نظرت إليه مرة أخرى يبدو أنه مشكلة مختلفة. قد تكون المشكلة التي أبلغت عنها لا تزال ذات صلة على الرغم من أنني اضطررت إلى تنفيذ الحل البديل الذي اقترحته في pymbar حتى يعمل.

smcantab في ٢٢ فبراير ٢٠١٦

لمعلوماتك ، قابلت شخصًا ما في مؤتمر صوتي أظهر لي هذا المثال. من السهل التكاثر والمتطرف.

%time np.fft.fft( np.random.randn(100000) )
Wall time: 16 ms
Out[16]: 
array([ 196.58599022  +0.j        ,  -88.38483360 +89.2507627j ,
       -166.72250316+339.27161306j, ...,   12.22959535 -64.01621313j,
       -166.72250316-339.27161306j,  -88.38483360 -89.2507627j ])

%time np.fft.fft( np.random.randn(100003) )
Wall time: 1min 42s
Out[17]: 
array([  13.36160617  +0.j        , -314.86472577-340.44686425j,
       -258.36716707-170.43805382j, ...,  -21.18014704+441.3618185j ,
       -258.36716707+170.43805382j, -314.86472577+340.44686425j])

قدمًا بطول 1e6: 16 مللي ثانية

قدم بطول 1e6 + 3: 1 دقيقة و 42 ثانية

standarddeviant في ١٨ أكتوبر ٢٠١٧

ميزة وليست حشرة. يكون FFTPACK "سريعًا" فقط عندما تكون عوامل الحجم منتجًا للأرقام 2 ، 3 ، 4 ، 5. كانت هناك رغبة طويلة الأمد في استخدام خوارزمية أسرع للأحجام الأولية الكبيرة ، لكن لم يتم تنفيذها. لاحظ أن 100003 عدد أولي.

charris في ١٨ أكتوبر ٢٠١٧

لن أسميها "ميزة" ، لكنها طبيعية وليست خطأ. :)

يحتوي https://github.com/scipy/scipy/issues/4288 على خوارزمية Bluestein ، ولكنها تتطلب حسابًا مسبقًا لغردًا معقدًا ، لذلك ستحتاج إلى إجراء بعض الاختبارات لمعرفة الأحجام الأولية التي تصبح جديرة بالاهتمام.

endolith في ١٩ أكتوبر ٢٠١٧

👍1

مثير للإعجاب. الشيء الرئيسي الذي أعرفه هو أن تطبيق fft الافتراضي لجوليا وماتلاب ليس به هذا السلوك. لدي فضول بشأن ما يفعله تطبيق Julia لتجنب هذا السلوك.

standarddeviant في ١٩ أكتوبر ٢٠١٧

جوليا وماتلاب يتصلان بـ FFTW ، وهو ما لا يمكننا فعله بسبب ترخيصه.

charris في ١٩ أكتوبر ٢٠١٧

لاحظ أن هناك روابط Python لـ FFTW ؛ يبدو pyFFTW الحالية إلى حد ما. إذا كانت سرعة FFT مصدر قلق ، فمن المحتمل أن يكون هذا هو السبيل للذهاب. كان FFTPACK تطبيقًا جيدًا في يومه ، لكن الشفرة والأجهزة قد تطورت.

charris في ١٩ أكتوبر ٢٠١٧

charris أنا أقدر المعلومات بالتأكيد وهذا أمر مؤسف ، لكن من المنطقي فيما يتعلق بالترخيص.

standarddeviant في ٢٠ أكتوبر ٢٠١٧

standarddeviant يمكنك أيضًا وضع القرد pyfftw فوق numpy / scipy لاستخدامه FFTW

endolith في ٢٠ أكتوبر ٢٠١٧

يجب إصلاح هذا في numpy 1.17.

mreineck في ٥ أبريل ٢٠١٩

👍2

شكرا @ mreineck ، الإغلاق