यहां एक आवंटनकर्ता का एक उदाहरण है जो सभी प्लेटफार्मों पर काम करना चाहिए। यह बेशर्मी से इस पर आधारित है:

https://sites.google.com/site/ruslancray/lab/bookshelf/interview/ci/low-level/write-an-aligned-malloc-free-function

ऐसा करने के लिए कई तरीके नहीं हैं और समान कोड नेट पर चारों ओर तैर रहा है, इसलिए इसे इस तरह से विस्तारित करना संभावित ठीक है। (और इसके अलावा यह realloc को लागू नहीं करता है।)

इस कोड को numpy/core/include/numpy/ndarraytypes.h गिराना सुनिश्चित करना चाहिए कि हौसले से आवंटित ndarrays सभी प्लेटफार्मों पर ठीक से संरेखित हैं।

यह मंच स्वतंत्र कोड संभवतः के साथ प्रतिस्थापित किया जा सकता posix_memalign() POSIX पर और _aligned_malloc() विंडोज पर। हालांकि, posix_memalign() realloc() साथ संयोजन संभव नहीं है, इसलिए इसे स्वयं लागू करना शायद बेहतर है।

#define NPY_MEMALIGN 32   /* 16 for SSE2, 32 for AVX, 64 for Xeon Phi */ 

static NPY_INLINE
void *PyArray_realloc(void *p, size_t n)
{
    void *p1, **p2, *base;
    size_t old_offs, offs = NPY_MEMALIGN - 1 + sizeof(void*);    
    if (NPY_UNLIKELY(p != NULL)) {
        base = *(((void**)p)-1);
        if (NPY_UNLIKELY((p1 = PyMem_Realloc(base,n+offs)) == NULL)) return NULL;
        if (NPY_LIKELY(p1 == base)) return p;
        p2 = (void**)(((Py_uintptr_t)(p1)+offs) & ~(NPY_MEMALIGN-1));
        old_offs = (size_t)((Py_uintptr_t)p - (Py_uintptr_t)base);
        memmove(p2,(char*)p1+old_offs,n);    
    } else {
        if (NPY_UNLIKELY((p1 = PyMem_Malloc(n + offs)) == NULL)) return NULL;
        p2 = (void**)(((Py_uintptr_t)(p1)+offs) & ~(NPY_MEMALIGN-1));   
    }
    *(p2-1) = p1;
    return (void*)p2;
}    

static NPY_INLINE
void *PyArray_malloc(size_t n)
{
    return PyArray_realloc(NULL, n);
}

static NPY_INLINE
void *PyArray_calloc(size_t n, size_t s)
{
    void *p;
    if (NPY_UNLIKELY((p = PyArray_realloc(NULL,n*s)) == NULL)) return NULL;
    memset(p, 0, n*s);
    return p;
}

static NPY_INLINE        
void PyArray_free(void *p)
{
    void *base = *(((void**)p)-1);
    PyMem_Free(base);
} 

मेरे पास पहले से ही एक शाखा है जो एक गठबंधन आवंटितकर्ता को जोड़ता है, मैं इसे खोदूंगा।

इस तरह से कुछ का उपयोग करके हम अजगर ट्रेसमैलोक फ्रेमवर्क और विरल मेमोरी का उपयोग करने के लिए विकल्प को फेंक देते हैं (कोई align_calloc नहीं है)।
@njsmith क्या आप अजगर आवंटनकर्ता जोड़ सकते हैं? वे पहले से ही हमारे लिए calloc जोड़ा, अगर हम अब इसे इस्तेमाल नहीं कर सकता एक schame होगा।

संभवतः PyMemAllocatorEx के संदर्भ डेटा में संरेखण में कोई भी पारित हो सकता है? लेकिन NumPy को 2.6 और ऊपर के पायथन संस्करणों का समर्थन करना है, इसलिए Python 3.5 में ऐसा करने से समस्या हल नहीं हो सकती है।

मुझे लगता है कि 3.5 से पहले इस पर अजगर देवों से उलझना एक अच्छा विचार है,
लेकिन मैं अभी भी आश्वस्त नहीं हूं कि हमारे पास एक संरेखित उपयोग करने का एक अच्छा कारण है
निकट अवधि में आवंटितकर्ता। यह संभवतः ऐसा नहीं हो सकता है कि संरचना {
डबल, डबल} वास्तव में win32 या पर बेहतर-से-मालोक संरेखण की आवश्यकता है
स्पार्क, क्योंकि अगर यह सच होता तो कुछ भी काम नहीं करता।
26 नवंबर 2014 09:10 को, "जूलियन टेलर" नोटिफिकेशन @github.com ने लिखा:

मेरे पास पहले से ही एक शाखा है जो एक गठबंधन आवंटितकर्ता को जोड़ता है, मैं इसे खोदूंगा।

इस तरह से कुछ का उपयोग करके हम अजगर का उपयोग करने के लिए विकल्प को फेंक देते हैं
ट्रेसमैलोक फ्रेमवर्क और विरल मेमोरी (कोई एलाइन_कॉलोक नहीं है)।
@njsmith https://github.com/njsmith आप साथ जुड़ने के लिए तैयार होंगे
अजगर फिर से अपने स्लॉट में 3.5 से पहले एक और आवंटनकर्ता जोड़ने के लिए फिर से देवता है
जारी किया गया? उन्होंने पहले से ही हमारे लिए कॉलोक जोड़ दिया है, अगर हम एक schame होगा
अब इसका उपयोग नहीं कर सकता।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5312#issuecomment -64534021

F2py के संबंध में प्रश्न यह था कि फोर्टन को संरेखण की आवश्यकता होगी, सी। स्पीड की न्यूनतम आवश्यकता भी एक मुद्दा नहीं है। यदि डेटा ठीक से संरेखित है, तो अनुक्रमण और SIMD दोनों बेहतर काम करते हैं।

संरेखित आवंटनकर्ता का उपयोग करने का एक कारण वास्तव में गति हो सकता है, और SSE / AVX को सुनिश्चित करना है
संगतता अलग-अलग लेने से आने वाले संख्यात्मक घबराहट को दूर करेगी
अलग-अलग संरेखित डेटा के लिए कोड पथ।
।
f2py फोरट्रान में आईएसओ सी बाइंडिंग मानक से पुराना है, और जिस तरह से
काम अनिवार्य रूप से फोरट्रान की जगह पर वास्तविक मानक तरीका है
C के साथ, सभी द्वारा बड़े पैमाने पर उपयोग किया जाता है। इस अनुभव के प्रकाश में, यह है
स्पष्ट है कि सिस्टम मॉलोक द्वारा प्रदान की गई संरेखण पर्याप्त है
फोरट्रान हमारे लिए व्यवहार में मायने रखता है।

ध्यान दें कि AVX के लिए इंटेल द्वारा 32-बाइट संरेखण की सिफारिश की गई है: https://software.intel.com/en-us/articles/practical-intel-avx-optimization-on-2nd-generation-intel-core-processors

Xpon Phi के लिए NPY_MEMALIGN की परिभाषा के पीछे की टिप्पणी पर एक नज़र डालें।

संरेखित आवंटन प्रदान करने पर मुख्य जटिलता यह है कि एटीएम हम कर सकते हैं
ट्रेसमैलोक इंफ्रास्ट्रक्चर में हुक या तो एलाउंस करें, आवंटन आवंटित करें,
और इसे ठीक करने के लिए CPython अपस्ट्रीम के साथ कुछ समन्वय की आवश्यकता होगी (देखें)

4663)।

5 दिसंबर 2014 को 16:44 पर, "स्टर्ला मोल्डन" सूचनाएं @github.com ने लिखा:

@pitrou https://github.com/pitrou और Xeon के लिए 64 बिट अनुशंसित है
फी। NPY_MEMALIGN की परिभाषा के पीछे की टिप्पणी पर एक नज़र डालें
मेरा कोड उदाहरण।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5312#issuecomment -65816753

तो सीपीथॉन मुद्दा http://bugs.python.org/issue18835 पर है।

Realloc () के साथ जटिलताओं को देखते हुए, 3.5 समय सीमा में CPython को इसे हल करने की अपेक्षा करना यथार्थवादी नहीं हो सकता है। Numpy को संभवतः इसके बजाय अपने स्वयं के संरेखित आबंटित रैपर का उपयोग करना चाहिए (जो PyMem API को स्थगित करने में सक्षम होना चाहिए, और ट्रेसअल्मॉक का लाभ लेना चाहिए, वैसे भी)।

ऐसे आवंटनकर्ता के लिए कोड ऊपर शामिल है। मुझे @juliantaylor का तर्क समझ में नहीं आता, लेकिन वह शायद इसे मुझसे बेहतर समझता है।

मैं समझ सकता हूँ कि वह calloc के बारे में क्या मतलब था। एक calloc बस एक malloc और शून्य करने के लिए एक memset नहीं है। इससे पहले कि वे आवश्यक हों, पन्नों को लाने के लिए एक OS को OS की आवश्यकता होगी। AFAIK कोई PyMem_Calloc नहीं है।

वास्तव में CPython 3.5 में PyMem_Calloc और मित्र हैं।
मुझे लगता है कि @juliantaylor OS फ़ंक्शन (posix_memalign, आदि) का उपयोग करने के कार्यान्वयन के मामले पर विचार कर रहा था। लेकिन यह जरूरी नहीं है।

वैसे @sturlamolden , आपका स्निपेट PyArray_Malloc और दोस्तों को फिर से परिभाषित करता है, लेकिन सरणी आवंटन PyDataMem_NEW का उपयोग करता है। क्या मैं कुछ गलत समझ रहा हूँ?

एक अन्य विचार यह है कि छोटे सरणियों के लिए संरेखित आवंटन बेकार हो सकता है। शायद नीचे एक दहलीज होना चाहिए जो मानक आवंटन का उपयोग किया जाता है?
इसके अलावा, संरेखण विन्यास योग्य होना चाहिए?

आवंटनकर्ताओं को NumPy 1.9 में PyArray_malloc और PyArray_free कहा जाता है। NumPy 1.10 में बहुत कुछ बदल गया है।

क्या आपको यकीन है? PyArray_NewFromDescr_int () कॉल npy_alloc_cache () और npy_alloc_cache () कॉल PyDataMem_NEW ()।

Numpy में कई आवंटन इंटरफेस हैं, और उनके पास बहुत स्पष्ट नहीं है
names. PyArray_malloc / free का उपयोग "नियमित" आवंटन (जैसे ऑब्जेक्ट) के लिए किया जाता है
structs)। डेटा बफ़र्स (ndarray -> डेटा पॉइंटर्स, अस्थायी बफ़र अंदर
ufuncs, आदि), हालांकि, PyDataMem_NEW के माध्यम से आवंटित किए जाते हैं।

Thu पर, 15 जनवरी, 2015 को 7:48 PM, Sturla Molden सूचनाएं @github.com
लिखा था:

आवंटन करने वालों को Numpy 1.9 में PyArray_malloc और PyArray_free कहा जाता है।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5312#issuecomment -70149126।

नाथनियल जे। स्मिथ
पोस्टडॉक्टरल शोधकर्ता - सूचना विज्ञान - एडिनबर्ग विश्वविद्यालय
http://vorpus.org

ऐसा लगता है कि PyDataMem_NEW नंबर malloc NumPy 1.9 में है।
https://github.com/numpy/numpy/blob/3975e095013119cfdbb9405ca95e6c723eb862d3/numpy/core/src/multiarray/alloc.c

@njsmith हाँ, हमें किसी दिन आवंटन मैक्रो को तर्कसंगत बनाना चाहिए ... मैं ndarray (IIRC) के लिए आयाम आवंटित करने के लिए उपयोग किए जाने वाले के साथ शुरू करूँगा।

मैंने एक पैच के साथ PR # 5457 बनाया। दृष्टिकोण पर प्रतिक्रिया अच्छी होगी।

जहाँ तक मुझे पता है कि वर्तमान में एक संरेखित उपयोग करने का कोई लाभ नहीं है
खसरा में आवंटितकर्ता

शुक्र पर, 16 जनवरी, 2015 को 7:15 बजे, एंटोनी पिट्रू नोटिफिकेशन @github.com
लिखा था:

मैंने एक के साथ PR # 5457 https://github.com/numpy/numpy/pull/5457 बनाया
पैच। दृष्टिकोण पर प्रतिक्रिया अच्छी होगी।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5312#issuecomment -70305997

नाथनियल जे। स्मिथ
पोस्टडॉक्टरल शोधकर्ता - सूचना विज्ञान - एडिनबर्ग विश्वविद्यालय
http://vorpus.org

Numba के साथ हमने निर्धारित किया कि AVX वेक्टर निर्देशों को इष्टतम प्रदर्शन के लिए 32-बाइट संरेखण की आवश्यकता है। यदि आप एवीएक्स सक्षम के साथ नेम्पी को संकलित करते हैं (विशिष्ट संकलक विकल्पों की आवश्यकता है, तो मुझे लगता है), संरेखण में भी अंतर होना चाहिए।

जिज्ञासा से बाहर, क्या आपके पास कोई वास्तविक दुनिया माप है? मैं वहां b / c पूछता हूं
बहुत सारे कारक हैं जो इन चीजों में खेलते हैं (विभिन्न उपरि / गति
अलग-अलग सरणी आकार में ट्रेड-ऑफ़, मेमोरी एलोकेटर का विवरण - जो
अलग-अलग सरणी आकारों में अलग-अलग कार्य भी करते हैं - आदि) जो मुझे कठिन लगता है
यह अनुमान लगाने के लिए कि कोई 0.5% एंड-टू-एंड स्पीडअप या 50% की तरह समाप्त होता है या नहीं
एंड-टू-एंड स्पीडअप या क्या।

शुक्र पर, 16 जनवरी, 2015 को रात 8:16 बजे, एंटोनी पिट्रू नोटिफिकेशन @github.com
लिखा था:

Numba के साथ हमने निर्धारित किया कि AVX वेक्टर निर्देशों के लिए 32-बाइट की आवश्यकता थी
इष्टतम प्रदर्शन के लिए संरेखण। यदि आप AVX सक्षम के साथ Numpy संकलित करते हैं
(विशिष्ट संकलक विकल्पों की आवश्यकता है, मुझे लगता है), संरेखण को एक बनाना चाहिए
अंतर भी।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5312#issuecomment -70315434।

नाथनियल जे। स्मिथ
पोस्टडॉक्टरल शोधकर्ता - सूचना विज्ञान - एडिनबर्ग विश्वविद्यालय
http://vorpus.org

मेरे i5-4210u पर fwiw मुझे 16 और 32 बाइट के बीच कोई महत्वपूर्ण अंतर नहीं दिखता है एक साधारण लोड ऐड स्टोर टेस्ट में, न्यूनतम चक्र गणना 5% से कम लगती है लेकिन माध्यिका और 10 वीं प्रतिशत 1% के समान है

AVX के साथ है?

@seibert ने Numba सरणियों का उपयोग करते हुए Numba (यानी LLVM के साथ बस-इन-टाइम कोड जेनरेशन) के साथ कुछ AVX माप किए, मुझे लगता है कि वह सटीक संख्या पाने के लिए उन्हें फिर से चलाने की कोशिश करेंगे :-)

यहाँ नवीनतम Numba मास्टर के साथ बेंचमार्क है:

http://nbviewer.ipython.org/gist/seibert/6957baddc067140e55fe

Float32 सरणियों (आकार = 10000) के लिए, a + b * fabs(a) संचालन को निष्पादित करते हुए, हम एक Intel Core i7-4820K CPU @ 3.70GHz (Ivy Bridge) पर 40% अंतर देखते हैं।

(हम थोड़ा हैरान हैं कि एलएलवीएम 3.5 ऑटोवैक्टराइज़र संरेखण समस्याओं को ठीक करने के लिए कोई लूप छीलने वाला कोड नहीं बना रहा है। मुझे आश्चर्य नहीं होगा कि क्या इसके लिए जीसीसी या क्लैंग सही है।)

अन्य आर्किटेक्चर के लिए हम लक्षित करने की योजना बना रहे हैं (जैसे कि एएमडी एपीयू जो एचएसए मानक का समर्थन करते हैं), संरेखण की आवश्यकताएं अधिक सख्त हैं, ओपनसीएल डेवलपर्स का सुझाव है कि हमारे पास सर्वश्रेष्ठ प्रदर्शन के लिए सरणियों के लिए 256 बाइट संरेखण है।

मुझे नहीं पता कि 40% एक अत्यधिक दंड की तरह लगता है, मैं एक i5 हैसवेल पर शून्य देखता हूं (जो वास्तव में खराब एवीएक्स प्रदर्शन है)
क्या ऐसा हो सकता है कि जेट कंपाइलर लूप के दो अलग-अलग संस्करण बना रहा हो?
क्या आपके पास इसका असेंबली लेवल प्रोफ़ाइल है (जैसे कि रिकॉर्ड के माध्यम से)?

यह भी हो सकता है कि टर्बो बूस्ट दूसरे लूप पर किक कर रहा हो, इसे निष्क्रिय करना या निगरानी करना वह शामू को दिलचस्प बना सकता है

चूंकि हम बेंचमार्किंग के लिए इस प्रणाली का उपयोग करते हैं, इसलिए हमने BIOS में TurboBoost को निष्क्रिय कर दिया है।

JIT केवल एक बार चल रही है (एक बार जब Numba दिए गए इनपुट प्रकारों के लिए फ़ंक्शन संकलित करता है, तो यह इसे कैश करता है), और JIT को लिंक किए गए नोटबुक में सेल 6 द्वारा बेंचमार्किंग से पहले ट्रिगर किया जाता है।

मैंने पहले सही रिकॉर्ड का उपयोग नहीं किया है, लेकिन मैं इसे देखूंगा। आपने अपने बेंचमार्क कैसे निभाए? (मैं वास्तव में उम्मीद करूंगा कि अगर ई-ब्रिज उपलब्ध एल 2 कैश बैंडविड्थ के कुछ प्रकार के अक्षम्य उपयोग को ट्रिगर कर रहा है तो आइवी ब्रिज से बेहतर करने के लिए हसवेल की आवश्यकता होगी।)

इंटेल का यह श्वेतपत्र पृष्ठ 6 के तल पर संरेखण मुद्दे पर थोड़ी अधिक जानकारी देता है:

https://software.intel.com/sites/default/files/m/d/4/1/d/8/Practical_Optimization_with_AVX.pdf

Unalign 32-byte vectors पर Intel AVX निर्देशों का उपयोग करने का अर्थ है कि हर दूसरा लोड कैशलाइन विभाजन पर होगा, क्योंकि कैश लाइन 64 बाइट्स है। यह 16-बाइट वैक्टर का उपयोग करने वाले Intel SSE कोड की तुलना में कैश लाइन विभाजन दर को दोगुना करता है। मेमोरी-इंटेंसिव कोड में एक उच्च कैश-लाइन स्प्लिट दर प्रदर्शन में गिरावट का कारण है। उस कारण से, इंटेल AVX के साथ उपयोग के लिए डेटा को 32 बाइट्स के साथ संरेखित करने की अत्यधिक अनुशंसा की जाती है।

हैवेल के पास सैंडी / आइवी ब्रिज के L2 कैश बैंडविड्थ का दोगुना है, इसलिए यह संभव है कि मिसल पर दिए गए गलत तरीके से किए गए सरणियों का प्रभाव महत्वपूर्ण न हो ...

मेरा सरल बेंचमार्क यह है:
https://gist.github.com/juliantaylor/68e578d140f427ed80bb
उस i7 पर देखना दिलचस्प होगा

एक कोर i5-2500K (सैंडी ब्रिज) पर परिणाम:
4644 6656 7704 10100

कृपया ध्यान दें कि मुझे बेंचमार्क की शुरुआत में एक लंबा वार्मअप चरण जोड़ना था:

    for (i=0; i<10; i++)
        add(a, 1);

क्या वह औसत / मंझला / ... है? यह काफी महत्वपूर्ण लग रहा है, लगता है कि इंटेल ने इस पर बहुत काम किया है।

यह लूप में कुछ सैकड़ों रनों के बाद बेंचमार्क से लगभग स्थिर आउटपुट है।

मैंने एक पैक SSE2 कार्यान्वयन जोड़ा, यहां आंकड़े (i5-2500K) हैं:
4660 6492 7468 5108 10096
(32B संरेखित AVX, 16B (संयुक्त राष्ट्र) ने AVX, 8B (संयुक्त राष्ट्र) को AVX, संरेखित SSE2, स्केल को संरेखित किया।

यहाँ अद्यतन स्रोत है: https://gist.github.com/pitrou/892219a7d4c6d37de201

कोर i5-4200U (लैपटॉप हैसवेल सीपीयू) से लगभग स्थिर आउटपुट:
4120 4152 4148 4260 7308

कम से कम यहाँ, मिस एवीएक्स को समान संरेखण के साथ SSE2 से बदतर नहीं है।

यहाँ मेरा MBP (क्वाड-कोर i7-3635QM, 2.4 GHz, Ivy Bridge) है:
5060 4932 5820 5704 5040

मुझे avxintrin.h से immintrin.h बदलना पड़ा और Intel icc से संकलन करना पड़ा क्योंकि gcc 4.8.1 ने कोड को संकलित करने से इनकार कर दिया (और इसलिए क्लैंग किया)।

@sturlamolden , क्या यह संभव हो सकता है कि वेक्टर कर रहा है?

(ध्यान दें कि बेंचमार्क संभवतः कैश सबसिस्टम पर अधिक दबाव डालेगा यदि इसके अलावा दो अलग-अलग इनपुट एरे शामिल हों)

मुझे पता नहीं है।

@sturlamolden यह कोड कुछ SSE2 के साथ इंटरफेस करने के लिए बहुत उपयोगी था।

मेरे पास विंडोज पर एक मुद्दा था (वीसी के सभी संस्करण, जिसमें 2015 भी शामिल है) इस लाइन को पसंद नहीं करते हैं

memmove((void*)p2,p1+old_offs,n);    

चूँकि वे void* पर सूचक अंकगणित का समर्थन नहीं करते हैं। एक अल्पावधि फिक्स के रूप में मैंने इसे गणित करने के लिए char* कास्ट किया। यह शायद सही नहीं है - क्या आपके पास एक बेहतर विचार है कि यह विंडोज पर सही ढंग से क्या संकलन करेगा?

मेरी गलती। शून्य पर सूचक अंकगणित * अवैध है। सी। के लिए कास्टिंग * सही है।
कोड उदाहरण अपडेट किया गया।

मैं 64-बाइट संरेखित सुपीरियर सरणियों को कैसे प्राप्त करूं? Https://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.require.html से 'ALIGNED' पते कुछ अलग लंबाई में संरेखित करने लगते हैं। संरेखण लंबाई के लिए कुछ उपयोगकर्ता-विन्यास योग्य पैरामीटर है?

मैंने अपना (पाइथन) एलायमेंट एलाटेटर बनाया जो नम्पी द्वारा प्रदान की गई (अनलिज्ड) मेमोरी पर काम करता है।

import numpy as np

def empty_aligned(n, align):
    """                                                                                                                                     
    Get n bytes of memory wih alignment align.                                                                                              
    """

    a = np.empty(n + (align - 1), dtype=np.uint8)
    data_align = a.ctypes.data % align
    offset = 0 if data_align == 0 else (align - data_align)
    return a[offset : offset + n]


def test(n):
    for i in xrange(1, 1024):
        b = empty_aligned(n, i)

        try:
            assert b.ctypes.data % i == 0
            assert b.size == n
        except AssertionError:
            print i, b.ctypes.data % i, b.size

शायद इस तरह एक पायथन समाधान एक व्यवहार्य समाधान है?

@eamartin यह NumPy के आंतरिक C कोड और इंटरफ़ेस कोड के बारे में Fortran द्वारा f2py (भी C कोड) द्वारा उत्पन्न है। स्पष्ट कारणों के लिए, NumPy का कार्यान्वयन NumPy पर निर्भर नहीं हो सकता है।

यद्यपि आप अपने पायथन प्रोजेक्ट्स के लिए उस ट्रिक का उपयोग कर सकते हैं।

@sturlamolden : यह @nachiket और दूसरों को एक समान स्थिति में मदद कर सकता है, हालांकि।

@sturlamolden :

हालांकि, पायथन इंटरफेस में बेहतर संरेखण विकल्प की पेशकश करना नम्पी और देशी पुस्तकालयों के बीच पायथन इंटरफेस विकसित करने के लिए मूल्यवान होगा, जिनके पास तर्कों पर संरेखण आवश्यकताएं हैं।

मैं पायथन इंटरफेस am में बेहतर संरेखण विकल्पों की पेशकश करने के खिलाफ नहीं हूं

"पायथन एलायंस एलोकेटर" का हल जो मैंने सुझाया वह हैक है। मुझे लगता है कि पायथन इंटरफेस में संरेखण की पेशकश करना अच्छा होगा, लेकिन ऐसा करने का सही तरीका सी स्तर पर संरेखण को संभालना होगा।

यह सुविधा मेरे लिए बहुत उपयोगी होगी। मैं एक FPGA डिवाइस (Altera A10GX) का उपयोग कर रहा हूँ, जहाँ DMA कंट्रोलर को 64-बाइट के लिए संरेखित डेटा का उपयोग करने की आवश्यकता होती है, यह मेरे कोड को 40x (!!!) तक बढ़ा देता है। मुझे संदेह है कि @nachiket में भी मेरे जैसी ही समस्या है। मैंने कुछ ऐसा ही लिखा है जो @eamartin का उपयोग कर रहा है लेकिन यह थोड़ा हैक है।

मैं निश्चित रूप से 64 बाइट संरेखण को प्रोत्साहित करता हूं:

1. यह कैश लाइन आकार है
2. यह AVX512 तक के किसी भी SIMD संरेखण के लिए उपयुक्त है

यहां हम लगभग 5 साल बाद हैं।

इसे बनाने पर कोई विचार (64-बाइट विशेष रूप से संरेखण) एक मानक विशेषता??

यह साइथन कोड अब NumPy में है। बेशक, यह डिफ़ॉल्ट नहीं बदलता है।

मेरे 2cents: एक आबंटित आवंटनकर्ता को मदद मिलेगी जब हार्डवेयर डिवाइस और कर्नेल स्तर कॉल के साथ इंटरफ़ेस। ये इंटरफेस बफ़र्स को पृष्ठों पर संरेखित करने से लाभान्वित हो सकते हैं।

रैंडमगेन को मर्ज करने में, हमें PyArray_realloc_aligned और दोस्तों का फायदा हुआ। क्या हमें इन रूटीन को numpy/core/include में स्थानांतरित करना चाहिए?

यह निश्चित रूप से उपयोगी होगा, @mattip। क्या पायथन से भी इस कार्यक्षमता को एक्सेस करना संभव होगा?

रैंडमगेन को मर्ज करने में, हमें PyArray_realloc_aligned और दोस्तों का फायदा हुआ। क्या हमें इन रूटीन को numpy/core/include में स्थानांतरित करना चाहिए?

मेरे कोड बंद कर दिया, फिर किया था? 😂

ऐसा लगता है कि मैं NumPy er के लिए लिखे गए कोड के लिए कोई लॉकर योगदानकर्ता नहीं हूं:

https://github.com/numpy/numpy/blob/v1.17.2/numpy/_build_utils/src/apple_sgemv_fix.c
https://github.com/numpy/numpy/blob/v1.17.2/numpy/random/src/aligned_malloc/aligned_malloc.h

शायद यादृच्छिक से सुन्न के लिए इस कदम में कुछ बिंदु पर खो गया। मैं
लगता है कि मेरे पास एक रिकॉर्ड था कि यह तुम्हारा था।

रवि पर, नवंबर 17, 2019, 10:29 स्टर्ला मोल्डन सूचनाएं @github.com ने लिखा:

ऐसा लगता है कि मैंने जिस कोड के लिए लिखा है, उसके लिए मेरा कोई लॉगर योगदानकर्ता नहीं है
NumPy 🧐:

https://github.com/numpy/numpy/blob/v1.17.2/numpy/_build_utils/src/apple_sgemv_fix.c

https://github.com/numpy/numpy/blob/v1.17.2/numpy/random/src/aligned_malloc/aligned_malloc.h

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5312?email_source=notifications&email_token=ABKTSRLWKGXUFE4OK53SJMDQUEMJJAFNNNMM4AYDJQ42Y3NVWWKWFDFDFDFDFFDFFDFXFDFDXFDFDF4FDFDF4FD
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ABKTSRM7IZIKPGKT4D2W4IDQUEMJJANCNFSM4AYDJQ4Q
।

कोड का मूल स्रोत क्या था?

लिंक मर चुका है, लेकिन इसे एक एलायंस मॉलोक से अनुकूलित किया गया था जो इस तरह दिखता था:

https://tianrunhe.wordpress.com/2012/04/23/aligned-malloc-in-c/

यह स्टर्ला की एक गीथब पोस्ट थी। कोई मूल कोड फ़ाइल नहीं थी।

रवि पर, नवंबर 17, 2019, 12:04 मैटी पिकस नोटिफिकेशन @github.com ने लिखा:

कोड का मूल स्रोत क्या था?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5312?email_source=notifications&email_token=ABKTSRKKJJC4K6C4C4LW4FFYULQUENDA5CNFM4JDQJJQ42YY3PNVWKH52HFH52HFHHSHHSHHSH52&hl=hi
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ABKTSRIVMQFEJ5EP227PXL3QUEXNDANCNFSM4AYDJQ4Q
।

https://github.com/numpy/numpy/issues/5312#issuecomment -64529217

यह एलायंस मॉलोक के लिए है।

सूर्य पर, 17 नवंबर 2019, 12:14 केविन शेपर्ड [email protected]
लिखा था:

यह स्टर्ला की एक गीथब पोस्ट थी। कोई मूल कोड फ़ाइल नहीं थी।

रवि पर, नवंबर 17, 2019, 12:04 मैटी पिकस नोटिफिकेशन @github.com ने लिखा:

कोड का मूल स्रोत क्या था?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5312?email_source=notifications&email_token=ABKTSRKKJJC4K6C4C4LW4FFYULQUENDA5CNFM4JDQJJQ42YY3PNVWKH52HFH52HFHHSHHSHHSH52&hl=hi
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ABKTSRIVMQFEJ5EP227PXL3QUEXNDANCNFSM4AYDJQ4Q
।

क्या हर कोई जो नेम्पी को कोड की 50 पंक्तियों में योगदान देता है उसे एक समर्पित कॉपीराइट हेडर मिलता है? मैं अपने योगदान के माध्यम से जा सकता हूं और देख सकता हूं कि क्या कोई लागू होता है :-)

ऐसा लगता है कि मैं उस कोड के लिए योगदानकर्ता नहीं हूं जो मैंने NumPy के लिए लिखा है no:

आप हैं और हमेशा रहेंगे :)

क्या हर कोई जो नेम्पी को कोड की 50 पंक्तियों में योगदान देता है उसे एक समर्पित कॉपीराइट हेडर मिलता है? मैं अपने योगदान के माध्यम से जा सकता हूं और देख सकता हूं कि क्या कोई लागू होता है :-)

नहीं। हम स्रोत कोड के अंदर ऐसी चीजों को कूटने से बचने की कोशिश करते हैं, क्योंकि यह हमेशा बेतहाशा अपूर्ण और बनाए रखने में कठिन होगा। हम लोगों को THANKS.txt में खुद को सूचीबद्ध करने के लिए कहते हैं; मैं उस के लिए एक बेहतर विकल्प देख रहा हूं, क्योंकि वह फ़ाइल अक्सर मर्ज संघर्ष देता है।