Pytorch: [आरएफसी] मेमोरी प्रारूप (उर्फ लेआउट उर्फ ​​एनएचडब्ल्यूसी) समर्थन

empty_like साथ एक समस्या है; वर्तमान में परिभाषित अर्थशास्त्र यह है कि आप सभी विस्तृत जानकारी छोड़ देते हैं, इसलिए लेआउट को संरक्षित करना और बीसी होना संभव नहीं है।

@VitalyFedyunin को .contiguous() और torch.memory_layout बिट्स को लागू करने के लिए साइन अप किया गया है

एक प्रश्न - एक 4D टेंसर के लिए x आकार के साथ (n, c, h, w)

x = torch.randn(n,c,h,w)
# x.size(): (n, c, h, w)
# x.stride(): (c*h*w, h*w, w, 1)

हमारे पास एक अजीब क्रमपरिवर्तन है

y = x.permute(0, 3, 1, 2)
# y.size(): (n, w, c, h)
# y.stride(): (c*h*w, 1, h*w, w)

अब हम जाँचते हैं कि क्या यह NHWC प्रारूप के लिए सन्निहित है। नीचे के रूप में अपने तर्क का पालन करें

def is_nhwc_contiguous(x):
    return x.permute(0,2,3,1).is_contiguous()

# or alternatively
def is_nhwc_contiguous(x):
    n,c,h,w = x.size() # in any case the sizes remain in NCHW order
    return x.stride() == (c*h*w, 1, c*w, c)

दोनों ही मामलों के लिए is_nhwc_contiguous(y) सच हो जाएगा?

यह सही है। हालांकि हम केवल प्रगति पर रिले नहीं कर सकते क्योंकि हम कॉपी, टू और इसी तरह के संचालन के दौरान किसी भी रूपांतरण को आगे और पीछे से बचाना चाहते हैं।

क्या होगा यदि स्ट्राइड्स का क्रम स्मृति प्रारूप के समान हो? आइए उदाहरण के तौर पर 4D टेंसर का उपयोग करें। एक टेंसर का वर्णन करने के लिए, हमारे पास sizes , strides और stride_indexes :

आकार में (एन, सी, एच, डब्ल्यू)
भौतिक क्रम में कदम , अर्थात्

• (n, c, h, w) के स्ट्राइड्स यदि प्रारूप nchw . है
• (n, h, w, c) के स्ट्राइड्स यदि प्रारूप nhwc है।

stride_indexes नक्शे nchw आकार की ओर बढ़ते हैं:

• (0, 1, 2, 3) यदि प्रारूप nchw है,
• (0, 2, 3, 1) यदि प्रारूप nhwc है।

एनसीएचडब्ल्यू प्रारूप के लिए यह पहले जैसा ही है। एनएचडब्ल्यूसी के लिए यह समान होगा।

def is_nhwc_contiguous(x):
     n,c,h,w = x.size()
     return x.stride() == (h*w*c, w*c, c, 1)

def is_nchw_contiguous(x):
    n,c,h,w = x.size()
    return x.stride() == (c*h*w, h*w, w, 1)

def is_nchw_format(x):
    return x.stride_index() == (0, 1, 2, 3) 

def is_nhwc_format(x):
    return x.stride_index == (0, 2, 3, 1)

def is_contiguous(x):
    if (is_nchw_format(x)):
        return is_nchw_contiguous(x)
    else if (is_nhwc_format(x)):
        return  is_nhwc_contiguous(x)
    else:
        warning_not_support()

# or, to use stride_index
def is_contiguous(x):
    return x.stride() == (x.size[x.stride_index[1]]*x.size[x.stride_index[2]]*x.size[x.stride_index[3]], x.size[x.stride_index[2]] * x.size[x.stride_index[3]], x.size[x.stride_index[3]], 1)

इसे अवरुद्ध प्रारूप का समर्थन करने के लिए भी बढ़ाया जा सकता है। उदाहरण के तौर पर nChw16c का प्रयोग करें,

sizes: (n, c, h, w)
block_sizes: (n, c/16, h, w, 16)
strides: strides of (n, c/16, h, w, 16)
stride_indexes: (0, 1, 2, 3, 1)  # assume blocked dimension is always in dense (i.e. on the right side of major dimension)

अधिक विवरण बाद में और खोजे जा सकते हैं।

ओपी के लिए जो केवल ncw सन्निहित टेंसर को स्वीकार करता है, वह यहाँ कुछ काम होगा।

वैकल्पिक रूप से हम प्रोटोटाइप को थोड़ा बदल भी सकते हैं, मान लीजिए

def is_contiguous(format=nchw):
    ...
def contiguous(format=nchw)
    ...

इस प्रकार डिफ़ॉल्ट रूप से, यह मानता है कि केवल nchw सन्निहित है। इस तरह आपको उन ओपी को फिर से लिखने की आवश्यकता नहीं है, इसे स्वचालित रूप से nchw करने के लिए पुन: व्यवस्थित किया जाएगा।

हम प्रतिनिधित्व करने में सक्षम एपीआई बनाने का प्रयास करते हैं:

• विभिन्न मेमोरी प्रारूप के साथ टेंसर (शुरुआत में, बस आयाम क्रम) PyTorch में Eager और JIT में मौजूद है। अवरुद्ध लेआउट कम प्राथमिकता वाले हैं लेकिन फिर भी अच्छे हैं।
• मेमोरी फॉर्मेट को क्वेरी करने और बदलने के लिए यूजर-एक्सपोज्ड एपीआई
• कोर सीएनएन ऑपरेशंस विभिन्न मेमोरी प्रारूप के साथ इनपुट टेंसर को संभालने में सक्षम हैं और तेजी से कार्यान्वयन के लिए रूटिंग कर रहे हैं
• JIT पास में मेमोरी फॉर्मेट के बारे में अनुमान लगाने और ऑप्टिमाइज़ करने की क्षमता

बढ़िया प्रस्ताव! क्या मैं अपनी समझ को स्पष्ट कर सकता हूं कि क्या यह सही है (एमकेएल-डीएनएन प्रारूपों को संभालने के प्रस्तावों सहित):

मुझे यह सोचने की अनुमति दें कि इस प्रस्ताव को "प्रारूप" वर्ग के रूप में लागू किया गया था। जब तक यह क्वेरी प्रदान करता है और एपीआई को वर्चुअल के रूप में बदलता है, हम एमकेएल-डीएनएन जटिल प्रारूपों में फिट होने वाले विरासत/एक्सटेंशन कर सकते हैं। या अन्य तरीके जब तक यह प्रारूपों को संभालने के लिए एक ढांचा प्रदान करता है, उन सूक्ष्म विवरणों को हमें ऑफलोड करता है।

ओपी कार्यान्वयन के बारे में, प्रत्येक ओपी में एक पसंदीदा प्रारूप हो सकता है जो इसके प्रदर्शन को अधिकतम करता है और एक संगत प्रारूप जो कार्यात्मक हो। तत्व-वार ऑपरेटर (या अधिक आम तौर पर बोलते हुए, मेमोरी बाध्य ओपी) मान लीजिए कि कोई वरीयता नहीं है। ओपी अपने परिणाम टेंसर को "प्रारूप" ऑब्जेक्ट के साथ उत्पन्न करता है, यह प्रारूप ऑब्जेक्ट डिफ़ॉल्ट पाइटोरच अपेक्षा के अनुकूल क्वेरी/बदलते शब्दार्थ की गारंटी देता है, साथ ही यह विशिष्ट स्वरूपों को संभाल सकता है यदि अनुकूलित कार्यों के धारावाहिक कहा जाता है (जैसे conv2d (ReLU (conv2d)) मामला)

@uyongw मैं आपके पहले उदाहरण के बारे में कुछ और स्पष्ट करना चाहता हूं। आप इस उदाहरण को सेट करते हैं, "मेरे पास एक NCHW टेंसर है, जिसे मैंने तब एक अजीब तरीके से ट्रांसपोज़ किया था (इसलिए अब यह NWCH जैसा दिखता है); अब मैं जानना चाहता हूं कि क्या यह NHWC सन्निहित है।" लेकिन इसे देखने का यह गलत तरीका है। एक बेहतर सूत्रीकरण है, "मेरे पास एक NHWC टेंसर है, जिसे मैंने बाद में NCHW टेंसर में बदल दिया।"

इसे अलग तरीके से रखने के लिए, टेंसर के भौतिक आयामों का कोई आंतरिक अर्थ नहीं है (जब हम प्रगति को अनदेखा करते हैं)। हम उन्हें केवल तभी अर्थ देते हैं जब हम विचार करते हैं कि हम उन्हें प्रगति के संबंध में कैसे संदर्भित करते हैं।

एक टेंसर का वर्णन करने के लिए, हमारे पास आकार, स्ट्राइड और स्ट्राइड_इंडेक्स हैं

मुझे लगता है कि stride_indexes समस्या के बारे में सोचने का एक सुविधाजनक तरीका है, लेकिन यह स्ट्राइड्स के साथ सख्ती से बेमानी है, क्योंकि आप जो कह रहे हैं वह है "इसे लागू करें (रिवर्स?) क्रमपरिवर्तन को स्ट्राइड्स पर लागू करें, और फिर इसे सच्ची प्रगति।) @VitalyFedyunin और मैं इस बारे में बात कर रहे थे कि इस जानकारी को किसी तरह से कैश करना अभी भी एक अच्छा विचार कैसे हो सकता है, क्योंकि जानकारी को खुद से फिर से बनाना एक दर्द है। लेकिन यह इस प्रस्ताव के दायरे से बाहर है।

इस प्रकार डिफ़ॉल्ट रूप से, यह मानता है कि केवल nchw सन्निहित है।

हां, यह मेरी योजना के बारे में पढ़ रहा है।

@CaoZhongZ

मुझे यह सोचने की अनुमति दें कि इस प्रस्ताव को "प्रारूप" वर्ग के रूप में लागू किया गया था। जब तक यह क्वेरी प्रदान करता है और एपीआई को वर्चुअल के रूप में बदलता है, हम एमकेएल-डीएनएन जटिल प्रारूपों में फिट होने वाले विरासत/एक्सटेंशन कर सकते हैं। या अन्य तरीके जब तक यह प्रारूपों को संभालने के लिए एक ढांचा प्रदान करता है, उन सूक्ष्म विवरणों को हमें ऑफलोड करता है।

मैं वास्तव में नहीं सोचता कि यह प्रस्ताव का सटीक विवरण है। मेमोरी लेआउट समर्थन जो यहां प्रस्ताव का समर्थन करता है, केवल लेआउट हैं जिन्हें स्ट्राइड्स के माध्यम से व्यक्त किया जा सकता है। कुछ भी जो इस तरह से व्यक्त नहीं किया जा सकता है (उदाहरण के लिए, ब्लॉक लेआउट) इस तरह से काम नहीं करेगा, और हमारे अधिक भारी वजन वाले "लेआउट" तंत्र द्वारा समर्थित होना चाहिए।

इसे अलग तरीके से रखने के लिए, टेंसर के भौतिक आयामों का कोई आंतरिक अर्थ नहीं है (जब हम प्रगति को अनदेखा करते हैं)। हम उन्हें केवल तभी अर्थ देते हैं जब हम विचार करते हैं कि हम उन्हें प्रगति के संबंध में कैसे संदर्भित करते हैं।

आंशिक रूप से सहमत :-) लेकिन इस विशिष्ट समस्या पर नहीं। मान लें कि मेरे पास पहले से ही एक nhwc टेंसर है। फिर मैं इसे nwhc करने की अनुमति देता हूं। मैं आगे nhwc को अनुमति देना चाहता हूं, फिर एक सन्निहित () करें। लेकिन मुझे यह पहले से ही nhwc सन्निहित है। क्या यह भ्रमित नहीं है?

मुझे लगता है कि stride_indexes समस्या के बारे में सोचने का एक सुविधाजनक तरीका है, लेकिन यह स्ट्राइड्स के साथ सख्ती से बेमानी है, क्योंकि आप जो कह रहे हैं वह है "इसे लागू करें (रिवर्स?) क्रमपरिवर्तन को स्ट्राइड्स पर लागू करें, और फिर इसे सही स्ट्राइड्स के रूप में मानें।)

आईएमएचओ, यदि आपके पास एनएचडब्ल्यूसी (भौतिक) में कदम हैं, तो यह प्रगति के साथ अनावश्यक नहीं होगा। क्योंकि आपको आकार (तर्क) के साथ सही मैपिंग की आवश्यकता है। अन्यथा वास्तविक आदेश बताने का कोई उपाय नहीं है।

बीटीडब्ल्यू रिवर्स मैपिंग का उपयोग करके एक और सरल दृष्टिकोण है। मान लीजिए, nchw के लिए, यह (0, 1, 2, 3) है, nhwc के लिए, यह (0, 2, 3, 1) के बजाय (0, 3, 1, 2) है। यह कहता है कि stride_index ही हमेशा NCHW भी होता है। लेकिन समस्या यह है कि इसे nChw16c या OIhw16i16o जैसे अवरुद्ध स्वरूपों तक विस्तारित नहीं किया जा सकता है।

अवरुद्ध प्रारूपों के लिए ऑपरेटरों के कार्यान्वयन के एक पूरी तरह से अलग सेट की आवश्यकता होती है; इस कारण से, हम उन्हें 'मेमोरी फॉर्मेट' के साथ नहीं मिलाना पसंद करते हैं, जो कि परिभाषा के अनुसार सभी मौजूदा ऑपरेटरों के अनुकूल होना चाहिए और समान या बेहतर प्रदर्शन के साथ काम करना चाहिए।

आंशिक रूप से सहमत :-) लेकिन इस विशिष्ट समस्या पर नहीं। मान लें कि मेरे पास पहले से ही एक nhwc टेंसर है। फिर मैं इसे nwhc करने की अनुमति देता हूं। मैं आगे nhwc को अनुमति देना चाहता हूं, फिर एक सन्निहित () करें। लेकिन मुझे यह पहले से ही nhwc सन्निहित है। क्या यह भ्रमित नहीं है?

आपके उदाहरण को समझना कठिन है क्योंकि आप बोलचाल की भाषा में कुछ शब्दों का प्रयोग कर रहे हैं और सटीकता की आवश्यकता है। आपने जो कहा है उसकी मैं व्याख्या इस प्रकार कर रहा हूं:

• इस प्रस्ताव के अनुसार एक "nhwc" टेंसर होना चाहिए, "टेन्सर जिसका भौतिक लेआउट NHWC है, लेकिन स्ट्राइड किया गया है ताकि तार्किक लेआउट NCHW हो।"
• "एक (टेन्सर जिसका लॉजिकल लेआउट एनसीएचडब्ल्यू है) टेंसर टू (लॉजिकल लेआउट) एनडब्ल्यूएचसी" को चलाने के लिए y = x.permute(0, 2, 3, 1) चलाना है, क्योंकि आप लॉजिकल लेआउट को अनुमति दे रहे हैं, भौतिक लेआउट नहीं। (मुझे संदेह है कि यह आपका मतलब नहीं था, क्योंकि आपकी मूल पोस्ट में आपने क्रमपरिवर्तन x.permute(0, 3, 1, 2) उल्लेख किया था
• इसके बाद (तार्किक लेआउट) NWHC टेंसर को (तार्किक लेआउट) में बदलने के लिए NHWC क्रमपरिवर्तन z = y.permute(0, 2, 3, 1) । तो अब आपके पास एक टेंसर है जिसका तार्किक लेआउट भौतिक लेआउट के साथ मेल खाता है। इसका मतलब यह है कि अगर हम z.contiguous() पूछें तो हमें सच मिलेगा (और, भ्रामक रूप से, z.contiguous(memory_layout=NCHW) भी सच होगा।) लेकिन यह NHWC सन्निहित नहीं होगा।

मुझे नहीं लगता कि यह वह उदाहरण है जो आपके दिमाग में था, इस मामले में आपको "परम्यूट" से आपका क्या मतलब है, इसके बारे में अधिक सटीक होना होगा।

आईएमएचओ, यदि आपके पास एनएचडब्ल्यूसी (भौतिक) में कदम हैं, तो यह प्रगति के साथ अनावश्यक नहीं होगा। क्योंकि आपको आकार (तर्क) के साथ सही मैपिंग की आवश्यकता है। अन्यथा वास्तविक आदेश बताने का कोई उपाय नहीं है।

यह प्रस्ताव का सार है: हम एनसीएचडब्ल्यू को तार्किक लेआउट के रूप में हमेशा विशेषाधिकार देते लगता है कि इसका तार्किक लेआउट NCHW है। इससे अस्पष्टता दूर होती है। यदि आप उन टेंसरों से निपटना चाहते हैं जिनका तार्किक लेआउट NCHW नहीं है, तो मुझे लगता है कि एपीआई जैसा कि कहा गया है, आपके लिए जीवन को थोड़ा कठिन बना देता है।

@dzhulgakov

संचालन स्मृति प्रारूप व्यवहार को संरक्षित करता है

यदि भौतिक NHWC टेंसर पूरी तरह से स्ट्राइड्स के माध्यम से हो सकते हैं, तो यह तकनीकी रूप से BC-ब्रेकिंग है, जब तक कि आप उन्हें मेमोरी फॉर्मेट टैग के मौजूद होने पर केवल मेमोरी फॉर्मेट को संरक्षित नहीं करते हैं (लेकिन ऐसा लगता है कि आप नहीं चाहते कि इसका अर्थ अर्थ हो, इसलिए मैं मुझे यकीन नहीं है कि प्रस्ताव वर्तमान में क्या सुझाव दे रहा है।) मुझे यकीन नहीं है कि यह वास्तव में व्यवहार में किसी के कोड को तोड़ता है।

यदि भौतिक NHWC टेंसर पूरी तरह से स्ट्राइड्स के माध्यम से हो सकते हैं, तो यह तकनीकी रूप से BC-ब्रेकिंग है, जब तक कि आप उन्हें मेमोरी फॉर्मेट टैग के मौजूद होने पर केवल मेमोरी फॉर्मेट को संरक्षित नहीं करते हैं (लेकिन ऐसा लगता है कि आप नहीं चाहते कि इसका अर्थ अर्थ हो, इसलिए मैं मुझे यकीन नहीं है कि प्रस्ताव वर्तमान में क्या सुझाव दे रहा है।) मुझे यकीन नहीं है कि यह वास्तव में व्यवहार में किसी के कोड को तोड़ता है।

मान लें कि हम मेमोरी फॉर्मेट को 'स्टिकी' बना सकते हैं। ऑप ओवर मेमोरी फॉरमेटेड टेंसर मेमोरी फॉर्मेट किए गए टेंसर का उत्पादन करेगा। इससे बीसी की समस्या का समाधान हो जाएगा।

हालाँकि, हमें बाइनरी (या अधिक सदस्य) संचालन के व्यवहार को परिभाषित करने की आवश्यकता होती है, जब टेंसर के अलग-अलग मेमोरी प्रारूप होते हैं।

@ezyang ओह मैंने अभी पाया कि मेरे उपरोक्त उत्तर में एक टाइपो है। (मुझे इसके लिए खेद है। हालांकि मूल उदाहरण अभी भी सही है।) मुझे इसे नीचे के रूप में पुन: स्थापित करने दें:

1. मेरे पास एक NCHW टेंसर (शारीरिक रूप से, सन्निहित) है।
2. फिर मैं इसे NWHC (तार्किक रूप से) की अनुमति देता हूं।
3. मैं इसे एनएचडब्ल्यूसी को एक सन्निहित() कॉल के साथ आगे बढ़ाना चाहता हूं।
4. इसे NHWC (शारीरिक रूप से) के रूप में उपयोग करें।

लेकिन मैंने इसे चरण 2 के बाद पहले से ही NHWC सन्निहित पाया। फिर मैं चरण 3 को छोड़ सकता हूं और इसे सीधे चरण 4 में NHWC के रूप में उपयोग कर सकता हूं। लेकिन यह निश्चित रूप से सही नहीं है क्योंकि टेंसर का भौतिक क्रम बिल्कुल नहीं बदलता है।

अवरुद्ध प्रारूपों के लिए ऑपरेटरों के कार्यान्वयन के एक पूरी तरह से अलग सेट की आवश्यकता होती है; इस कारण से, हम उन्हें 'मेमोरी फॉर्मेट' के साथ नहीं मिलाना पसंद करते हैं, जो कि परिभाषा के अनुसार सभी मौजूदा ऑपरेटरों के अनुकूल होना चाहिए और समान या बेहतर प्रदर्शन के साथ काम करना चाहिए।

हाँ, हम पहले कदम के रूप में NHWC को सक्षम कर सकते हैं। हालांकि मुझे नहीं लगता कि वास्तव में अवरुद्ध प्रारूप वास्तव में कुछ अलग है। इसे स्वाभाविक रूप से व्यक्त किया जा सकता है (कुछ अच्छे अमूर्त के साथ)। यदि कोई सामान्य प्रारूप विवरण है, तो अन्य केवल नए प्रारूपों को मनमाने ढंग से अवरुद्ध/प्रगति के साथ पंजीकृत कर सकते हैं।

अधिक अगर हमने पहले से ही समर्थन को अवरुद्ध कर दिया है, तो हम अंतर्निहित सब कुछ चलाने के लिए कुछ छिपी हुई संरचनाएं बनाने की जहमत नहीं उठाते हैं, जो अंदर एक अंतर्निहित दुनिया बनाता है और दोनों दुनियाओं के बीच/के बीच एक मुद्दा बन सकता है।

वैसे भी अवरुद्ध प्रारूप के बारे में सोचना बहुत दूर हो सकता है। लेकिन मुझे लगता है कि यदि संभव हो तो डिजाइन को एक्स्टेंसिबल बनाने के लिए बेहतर होगा।

लेकिन मैंने इसे चरण 2 के बाद पहले से ही NHWC सन्निहित पाया। फिर मैं चरण 3 को छोड़ सकता हूं और इसे सीधे चरण 4 में NHWC के रूप में उपयोग कर सकता हूं। लेकिन यह निश्चित रूप से सही नहीं है क्योंकि टेंसर का भौतिक क्रम बिल्कुल नहीं बदलता है।

ठीक है, मैं अब आपका उदाहरण समझता हूं। आप वास्तव में चरण 2 पर रुक सकते हैं और इसका उपयोग इस तरह कर सकते हैं जैसे कि यह एक NCHW टेंसर हो; इस मामले में, आप गलत तरीके से W को C, आदि के रूप में व्याख्यायित करेंगे। यह निश्चित रूप से स्ट्राइड-आधारित कार्यान्वयन के साथ एक नकारात्मक पहलू है ( @dzhulgakov , हमें शायद इसे प्रस्ताव में जोड़ना चाहिए)। इस मामले के लिए प्रस्ताव में कुछ प्रावधान हैं:

उपरोक्त समस्या को हल करने के लिए, प्रारंभिक प्रस्ताव टेंसर पर "सॉफ्ट" मेमोरी फॉर्मेट टैग पेश करना है जो टेंसर पर किए गए अंतिम टू (मेमोरी_फॉर्मैट) कॉल को रिकॉर्ड करता है। ऑपरेटरों को इस एनोटेशन को आउटपुट में प्रचारित करने की आवश्यकता होगी। एनोटेशन "सॉफ्ट" है, इसलिए हम बेमेल एनोटेशन पर हार्ड-एरर नहीं करेंगे, बल्कि प्रोफाइलिंग मोड में चेतावनियां देंगे।

सॉफ्ट मेमोरी फ़ॉर्मेट टैग आपको एक NCHW टेंसर से अलग करने देगा जिसे आपने अनुमति दी थी, बनाम एक टेंसर जो वास्तव में, भौतिक रूप से, NHWC है। लेकिन सॉफ्ट टैग अपने वर्तमान स्वरूप में गैर-बाध्यकारी है, इसलिए मुझे यकीन नहीं है कि यह वास्तव में इस मामले के लिए कितना उपयोगी होगा।

समस्या को हल करने का दूसरा तरीका नामित टेंसर है। नामित टेंसर के साथ, हम (तार्किक) आयामों पर नामों का उपयोग यह पता लगाने के लिए कर सकते हैं कि क्या हम एक टेंसर को NCHW (मान लिया गया डिफ़ॉल्ट) या कुछ और के रूप में देख रहे हैं।

हालांकि मुझे नहीं लगता कि वास्तव में अवरुद्ध प्रारूप वास्तव में कुछ अलग है। इसे स्वाभाविक रूप से व्यक्त किया जा सकता है (कुछ अच्छे अमूर्त के साथ)। यदि कोई सामान्य प्रारूप विवरण है, तो अन्य केवल नए प्रारूपों को मनमाने ढंग से अवरुद्ध/प्रगति के साथ पंजीकृत कर सकते हैं।

यहाँ इस विषय पर और भी कमेंट्री हैं: https://github.com/pytorch/pytorch/issues/16038#issuecomment -454490374

@ezyang उत्तर के लिए धन्यवाद। हाँ नरम प्रारूप टैग मदद कर सकता है। चिंता की बात यह है कि यह पर्याप्त लचीला नहीं हो सकता है क्योंकि आयाम क्रम मनमाना हो सकता है। साथ ही यह स्वयं गणना योग्य नहीं है। नामांकित टेंसर का प्रत्येक आयाम के लिए अर्थपूर्ण अर्थ है, लेकिन मुझे संदेह है कि समर्थन के लिए कुछ और सुविधाओं की आवश्यकता हो सकती है।

व्यक्तिगत रूप से मुझे लगता है कि इसे स्ट्राइड ऑर्डर (भौतिक) से एनसीएचडब्ल्यू आकार ऑर्डर (तार्किक) तक एक नक्शा पेश करके हल किया जा सकता है। जैसा कि मैंने ऊपर प्रस्तावित किया था, एनसीएचडब्ल्यू के लिए यह लगभग वर्तमान डिजाइन के समान है; NHWC के लिए, sizes अभी भी NCHW है, strides (N, H, W, C) क्रम में होगा। और हम कदमों के आयाम सूचकांक को निर्दिष्ट करने के लिए stride_index = (0, 2, 3, 1) का उपयोग करते हैं।

अधिक, strides और stride_index के संयोजन का उपयोग किसी भी टेंसर प्रारूप का प्रतिनिधित्व करने के लिए किया जा सकता है। यह दूसरों को नए डेटा प्रारूप को पंजीकृत करने के लिए लचीलापन दे सकता है।

@ezyang

संचालन स्मृति प्रारूप व्यवहार को संरक्षित करता है

यदि भौतिक NHWC टेंसर पूरी तरह से स्ट्राइड्स के माध्यम से हो सकते हैं, तो यह तकनीकी रूप से BC-ब्रेकिंग है, जब तक कि आप उन्हें मेमोरी फॉर्मेट टैग के मौजूद होने पर केवल मेमोरी फॉर्मेट को संरक्षित नहीं करते हैं (लेकिन ऐसा लगता है कि आप नहीं चाहते कि इसका अर्थ अर्थ हो, इसलिए मैं मुझे यकीन नहीं है कि प्रस्ताव वर्तमान में क्या सुझाव दे रहा है।) मुझे यकीन नहीं है कि यह वास्तव में व्यवहार में किसी के कोड को तोड़ता है।

जब अंकगणितीय संचालन और थ्रेशोल्ड को TensorIterator में ले जाया गया, जो तकनीकी रूप से BC-ब्रेकिंग था (क्योंकि ऑपरेंड के मेमोरी प्रारूप को संरक्षित नहीं किया जाता था, और TensorIterator इसे संरक्षित करता है)। यथास्थिति अब बहुत असंगत है - थ्रेशोल्ड लेआउट को संरक्षित करता है, अन्य सभी यूनरी ऑपरेशंस नहीं करते हैं, टॉर्च। जहां नहीं, अंकगणितीय ऑपरेशन लेआउट को संरक्षित करते हैं यदि दोनों ऑपरेंड का लेआउट समान है, लेकिन "एनसीएचडब्ल्यू" या टेंसर के लिए डिफ़ॉल्ट होगा जो कि contiguous वर्तमान समझ में यदि कोई बेमेल है, तो मुझे यकीन नहीं है कि प्रसारण के लिए क्या होता है।
आप empty_like बारे में भी अच्छी बात कर रहे हैं और लेआउट को संरक्षित करने की तरह बीसी नहीं है। शायद इसे एक लेआउट तर्क की भी आवश्यकता होगी, जैसे प्रस्ताव में is_contiguous

x.is_contiguous(torch.memory_format.channels_first)

@ezyang @ngimel

खाली_समान के साथ एक समस्या है; वर्तमान में परिभाषित अर्थशास्त्र यह है कि आप सभी विस्तृत जानकारी छोड़ देते हैं, इसलिए लेआउट को संरक्षित करना और बीसी होना संभव नहीं है।

आप खाली_समान के बारे में भी एक अच्छा मुद्दा बना रहे हैं और लेआउट को संरक्षित करने की तरह बीसी नहीं है।

यदि हम भौतिक आदेश को व्यक्त करने के लिए कदमों पर भरोसा नहीं करते हैं, तो empty_like BC को तोड़ना आवश्यक नहीं है। टेंसर में 3 प्रकार की आयाम जानकारी होती है:

• आकार: आकार
• लॉजिक ऑर्डर: स्ट्राइड्स में रिकॉर्ड की गई ऑर्डर की जानकारी (आमतौर पर ट्रांसपोज़ या परमिट का समर्थन करने के लिए उपयोग की जाती है)
• भौतिक क्रम: एनसीएचडब्ल्यू या एनएचडब्ल्यूसी (जैसा कि मैंने प्रस्तावित किया है, इसे स्ट्राइड_इंडेक्स के रूप में संबोधित किया जा सकता है)।

वर्तमान में भौतिक क्रम आकार/आकार के समान है। इसलिए हम लॉजिक ऑर्डर को स्ट्राइड्स में छोड़ देते हैं। विचार करें कि हम आकार और भौतिक क्रम को अलग कर रहे हैं, हम केवल तर्क क्रम को छोड़ सकते हैं लेकिन आकार और भौतिक क्रम को संरक्षित कर सकते हैं empty_like । इसका मतलब है कि size() और stride_index() को संरक्षित किया जाएगा, लेकिन stride() को रीसेट कर दिया जाएगा। विशेष रूप से, NHWC टेंसर का empty_like निर्दिष्ट आकार की जानकारी के साथ NHWC सन्निहित टेंसर लौटाएगा।

@uyongw मुझे यकीन नहीं है कि empty_like को बदलना एक अच्छा विचार होगा; अभी इसका शब्दार्थ numpy के empty_like मेल खाता है।

यथास्थिति अब बहुत असंगत है - थ्रेशोल्ड लेआउट को संरक्षित करता है, अन्य सभी यूनरी ऑपरेशंस नहीं करते हैं, टॉर्च। जहां नहीं, अंकगणितीय ऑपरेशन लेआउट को संरक्षित करते हैं यदि दोनों ऑपरेंड का लेआउट समान है, लेकिन "एनसीएचडब्ल्यू" या टेंसर के लिए डिफ़ॉल्ट होगा जो सन्निहित है वर्तमान समझ अगर कोई बेमेल है, तो मुझे यकीन नहीं है कि प्रसारण के लिए क्या होता है।

@ngimel , हाँ, ये अभी बहुत सुसंगत नहीं हैं। मुझे लगता है कि हमारे ऑपरेटरों को एक सुसंगत स्थिति में लाने के लिए स्मृति प्रारूप का प्रतिनिधित्व करने का तरीका काम करने का एक हिस्सा है

@ zou3519 numpy's empty_like जिसे आपने लिंक किया है, में order तर्क है जो डिफ़ॉल्ट रूप से "प्रोटोटाइप के लेआउट से यथासंभव निकटता से मेल खाता है।"। यह वह नहीं है जो empty_like pytorch में वर्तमान में करता है (यह "nchw" - सन्निहित टेंसर देता है, भले ही प्रोटोटाइप असंगत हो)

ओह, मैं देख रहा था, मैं वह बहुत जल्दी पढ़ रहा था। उस स्थिति में यह अच्छा होगा कि हमारा खाली_समान मैच numpy भी हो और यह (शायद?) मेमोरी लेआउट के लिए भी अच्छा होगा।

@ zou3519 हाँ, मैं जो कहना चाह रहा हूँ, वह है वर्तमान शब्दार्थ को बनाए रखना (उल्लेखित @ezyang और @ngimel के रूप में तार्किक क्रम

दो सवाल:

• यदि NHWC टेंसर को NCHW टेंसर में जोड़ा जाए तो क्या होगा?
• एक टेंसर पर t.channel_dim () जैसी विधियों को बनाकर (बी) के नुकसान को संबोधित करने के बारे में क्या है जो पूर्णांक मान को इंगित करता है कि आयाम भौतिक रूप से कहां है? नेटवर्क परिवर्तन के बिना ब्लॉक प्रारूपों जैसे अन्य प्रारूपों को चुनने की अनुमति देने के लिए भी इस दृष्टिकोण की आवश्यकता हो सकती है।

यदि हम अंतिम बुलेट बिंदु के साथ (बी) के कॉन को संबोधित करते हैं, तो (बी) मुझे बेहतर लगता है। यह सहज रूप से स्पष्ट है और तार्किक त्रुटियों का पता लगाना आसान होना चाहिए। सभी मौजूदा ऑप्स टेंसर पर भी काम कर सकते हैं, क्योंकि यह किसी अन्य सन्निहित टेंसर की तरह दिखता है। ऑप्स जो शब्दार्थ को समझ सकता है (नामित टेंसर प्रस्ताव के अनुरूप) अपेक्षित रूप से भी प्रदर्शन करेगा।

@ zou3519 numpy's empty_like जिसे आपने लिंक किया है, में order तर्क है जो डिफ़ॉल्ट रूप से "प्रोटोटाइप के लेआउट से यथासंभव निकटता से मेल खाता है।"। यह वह नहीं है जो empty_like pytorch में वर्तमान में करता है (यह "nchw" - सन्निहित टेंसर देता है, भले ही प्रोटोटाइप असंगत हो)

हम ऐसे मामलों में प्रारूप रखने की योजना बना रहे हैं (स्मृति स्वरूपित टेंसर के लिए)

यदि NHWC टेंसर को NCHW टेंसर में जोड़ा जाए तो क्या होगा?
स्मृति स्वरूपित टेंसर के साथ संचालन स्मृति स्वरूपित टेंसर लौटाएगा। यदि दोनों टेंसर मेमोरी स्वरूपित हैं, तो आउटपुट स्वरूप पहले टेंसर द्वारा निर्धारित किया जाएगा।

मैं दो चीजें जोड़ूंगा:

हम ऐसे मामलों में प्रारूप रखने की योजना बना रहे हैं (स्मृति स्वरूपित टेंसर के लिए)

हमें मौजूदा उपयोगों का ऑडिट करने की आवश्यकता होगी, क्योंकि अक्सर ऑपरेटर empty_like कॉल करेंगे और फिर मान लेंगे कि वे NCHW सन्निहित हैं। और मुझे नहीं पता कि हम तीसरे पक्ष के कोड से कैसे निपटेंगे। ऐसा लगता है कि अगर हम बीसी को संरक्षित करना चाहते हैं तो हमें numpy से अलग डिफ़ॉल्ट की आवश्यकता होगी।

स्मृति स्वरूपित टेंसर के साथ संचालन स्मृति स्वरूपित टेंसर लौटाएगा। यदि दोनों टेंसर मेमोरी स्वरूपित हैं, तो आउटपुट स्वरूप पहले टेंसर द्वारा निर्धारित किया जाएगा।

मैं यह भी जोड़ूंगा, यदि आप वास्तव में परवाह करते हैं कि आपका आउटपुट किस प्रारूप में आता है - आउटपुट टेंसर में पास करें।

खाली_समान पर सहमत हैं, ऐसे कुछ मामले हैं जहां खाली_लाइक/शून्य_ जैसा आदि का परिणाम एनसीएच-सन्निहित माना जाता है (शारीरिक रूप से सन्निहित मुझे कहना चाहिए, कई मामलों में यह छवि संचालन नहीं है)।
आउटपुट टेंसर पास करना ज्यादातर मामलों में एक विकल्प नहीं है, क्योंकि out kwarg वाले फ़ंक्शन अलग-अलग नहीं होते हैं।

हमारी कई समस्याएं अपेक्षित आउटपुट लेआउट की असंगति से आती हैं। हम उन सभी को एक साथ हल नहीं कर सकते हैं, लेकिन हम वर्तमान स्थिति को लॉक करने का प्रयास कर सकते हैं (कम से कम प्रगति के लिए) और एक-एक करके उन्हें खत्म कर सकते हैं। तो यहाँ प्रस्ताव है।

पायथन एपीआई

नई मशाल का परिचय दें। मेमोरी_फॉर्मेट

torch_memory_format.any # default value
torch_memory_format.preserve
torch.memory_format.contiguous # what most of the functions now behave as default
torch.memory_format.nchw # requires 4D tensor, contiguous memory
torch.memory_format.nhwc # requires 4D tensor, restrided/permuted memory

टेंसर को स्पष्ट मेमोरी प्रारूप रूपांतरण की आवश्यकता होगी

x = torch.zeros((10,3,32,32)) # NCHW
x.permute(0,2,3,1).is_contiguous(memory_format=torch.memory_format.nhwc) == False # because memory still layed out as NCHW

उन्हें विशिष्ट प्रारूप के साथ 'टैग' करने के लिए:

y = x.to(memory_format=torch.memory_format.nhwc)
y.is_contiguous(memory_format=torch.memory_format.nhwc) == True # We got new tensor with proper memory layout
y.is_contiguous() == False # Required for back compatibility
y.stride() == (3072, 3, 1, 96)

अब खाली_समान और समान के बारे में:

z = torch.empty_like(y) 
z.is_contiguous() == True # For BC

क्योंकि यह वास्तव में है:

z = torch.empty_like(y, memory_format=torch.memory_format.any ) 

अगर हम प्रारूप रखना चाहते हैं:

z = torch.empty_like(y, memory_format=torch_memory_format.preserve) 
z.is_contiguous() == False 
z.is_contiguous(memory_format=torch.memory_format.nhwc) == True

इसी तरह:

z = torch.empty_like(y, memory_format=memory_format=torch.memory_format.nhwc) 
z.is_contiguous() == False 
z.is_contiguous(memory_format=torch.memory_format.nhwc) == True

इसका मतलब है कि हम धीरे-धीरे प्रत्येक फ़ंक्शन मेमोरी_फॉर्मेट डिफॉल्ट को दुनिया की वर्तमान स्थिति में परिभाषित कर सकते हैं, उन्हें वर्गीकृत कर सकते हैं और ध्यान रख सकते हैं कि हम उन्हें भविष्य में कैसे बदलते हैं।

यदि आप निर्दिष्ट करते हैं कि टेंसर टेंसरऑप्शन को वर्तमान में अनदेखा कर दिया गया है (सबसे अच्छे मामले में वे अपवाद फेंकते हैं उदाहरण के लिए पारित डिवाइस विकल्प out टेंसर डिवाइस के साथ मेल नहीं खाता)।

मेमोरी प्रारूप को हल्का माना जाता है, इसलिए कोई भी क्रमपरिवर्तन इसे खो देगा।

x.zeros((10,3,32,32), memory_format=torch.memory_format.nhwc)
x = x.permute(0,1,3,2).permute(0,1,3,2)
x.is_contiguous(memory_format=torch.memory_format.nhwc) == False (even if strides are similar)

पैडिंग के बारे में निश्चित नहीं है, यहां मदद की सराहना करेंगे।

हालाँकि हम x.to(memory_format=torch.memory_format.nhwc) 'टैग' टेंसर को उचित प्रारूप के साथ बना सकते हैं और स्वयं को वापस कर सकते हैं

बहु

स्मृति प्रारूप 'टैग' को संरक्षित करेगा

मेमोरी फॉर्मेट को ब्लॉक करें

एपीआई ऊपर आयामों/कदमों/आकारों पर निर्भर नहीं है, जिसका अर्थ है कि हम भविष्य में उसी एपीआई को रखते हुए कार्यक्षमता बढ़ा सकते हैं।

आंतरिक एपीआई

ऑपरेटर मेमोरी फॉर्मेट के आधार पर ब्रांच कर सकेंगे

if (self.memory_format(nhwc)) {
 // fast path
} else
{
 // classic implementation
}

यदि हम TensorOptions के रूप में memory_format करते हैं, तो हम प्रेषण स्तर पर शाखा लगाने के बारे में सोच सकते हैं (इसी तरह डिवाइस, लेआउट के लिए)

प्रतिक्रिया का छोटा टुकड़ा @VitalyFedyunin का प्रस्ताव - मुझे लगता है कि यहां 4D टेंसर की आवश्यकता है

torch.memory_format.nchw # requires 4D tensor, contiguous memory
torch.memory_format.nhwc # requires 4D tensor, restrided/permuted memory

रास्ता बहुत अधिक प्रतिबंधात्मक है (क्योंकि हम 2D के अलावा 1D और 3D को भी संभालना चाहते हैं), और मूल प्रस्ताव से channels_first/channels_last इस उद्देश्य के लिए अधिक अनुकूल थे।

सहमत हूं, हमें बेहतर नामकरण की जरूरत है। channels_first बैच पहले जाने को छोड़कर लगभग सही लगता है =)

मुझे आपका नवीनतम प्रस्ताव पसंद है। क्या .contiguous() की हैंडलिंग बदल जाएगी? क्या आपको .contiguous(memory_format=<...>) की आवश्यकता होगी? यदि ऐसा है, और बहुत सारे ऑप्स बस .contiguous() कहते हैं, तो भी वे मेमोरी को गलत तरीके से फॉर्मेट कर सकते हैं। कई ऑपरेशन आज भी आउटपुट को खाली_लाइक () के रूप में आवंटित करते हैं, जिसका प्रभाव समान होगा। क्या इनपुट के मेमोरी फॉर्मेट का पता लगाने और सही सन्निहित और खाली_समान कॉल करने के लिए इन्हें अपडेट करने की योजना होगी?

अभी के लिए हमारे उपयोगकर्ता (और सभी पुस्तकालय) .contiguous() को अवरोही क्रम में प्रगति के साथ स्मृति सन्निहित टेंसर वापस करने की उम्मीद करते हैं।

हम इस अनुबंध को नहीं तोड़ सकते। हालांकि, अच्छी खबर यह है: जैसे ही हम मेमोरी_फॉर्मेट विकल्प का समर्थन करते हैं, जेआईटी यह समझने में सक्षम होगा कि क्लासिक प्रारूप के बजाय .contiguous(memory_format=...) पर कॉल करना कब अधिक कुशल है।

@VitalyFedyunin क्या हम मानते हैं कि नीचे दिए गए संचालन की अनुमति नहीं है?

x.zeros(10,3,32,32)
# x is in nchw (default)
# x.size() is [10,3,32,32]
# x.stride() is [3*32*32, 32*32, 32,1]
x = x.permute(0,2,3,1)
# At this point 
# x.size() is [10,32,32,3], size is not in nchw order
# x.stride() is [3*32*32, 32,1,32*32]

# How can this be supported?
y = x.to(memory_format=torch.memory_format.nhwc)

एक और प्रकार होगा:

x.zeros(10,3,32,32)
# `x` is in nchw (default)
# x.size() is [10,3,32,32]
# x.stride() is [3*32*32, 32*32, 32,1]
x = x.permute(0,2,3,1)
x=x.contiguous()
# At this point 
# x.size() is [10,32,32,3], size is not in nchw order
# x.stride() is [32*32*3, 32*3,3,1]

# How can this be supported?
y = x.to(memory_format=torch.memory_format.nhwc)

@ raghuramank100 - उपयोगकर्ता पहले स्थान पर .permute(0,2,3,1) क्यों कॉल करेगा? इस प्रस्ताव में सभी टेंसरों का सिमेंटिक आकार (एन, सी, एच, डब्ल्यू) है, जिसका अर्थ है कि आकार (1) आपको चैनल देता है। आज पीटी का मानक पुस्तकालय यही मानता है और इस प्रस्ताव में भी वह क्या मानेगा। तो कोई भी .permute को कभी भी कॉल नहीं करेगा

क्या एक संदर्भ प्रबंधक उपयोगी हो सकता है जो उपयोगकर्ता को आवंटित टेंसर के मेमोरी प्रारूप को प्रबंधक के दायरे में विशिष्ट प्रारूप में ओवरराइड करने की अनुमति देता है?

with torch.memory_format(torch.memory_format.nhwc):
    # a will be allocated with the context managed memory format   
    a = torch.randn(...)

# b will be allocated matching some assumed default format
b = torch.randn(...)

मुझे संदर्भ प्रबंधक का विचार पसंद नहीं है, क्योंकि यह मेमोरी_फॉर्मैट के नियंत्रण को ढीला कर देगा।

उदाहरण के लिए:

with torch.memory_format(torch.channels_last):
  x = torch.randn(10,3,32,32) # this one is NHWC
  y = torch.randn(10,10) @ this one is not

जब स्पष्ट memory_format यह स्पष्ट करता है:

x = torch.randn(10,3,32,32).to(memory_format=torch.channels_last) # this one is NHWC
y = torch.randn(10,10).to(memory_format=torch.channels_last) # This is errors out as dim == 2

यदि आवश्यक हो तो हम अनुमति देने के लिए सिंटैक्स जोड़ सकते हैं:

x = torch.randn(10,3,32,32, memory_format=torch.channels_last)

@raghuramank100 अनुमति देने की कोई आवश्यकता नहीं है।

y = x.to(memory_format=torch.channels_last)

आपके लिए सभी गंदे काम करेंगे, डिम्स ऑर्डर को x जैसा ही रखते हुए।

इसलिए:

x = torch.randn(10, 3, 32, 32)
nhwc = x.to(memory_format=torch.channels_last)
self.assertFalse(nhwc.is_contiguous())
self.assertTrue(nhwc.is_contiguous(memory_format=torch.channels_last))
self.assertEqual(nhwc, x)

और आप इस प्रारूप में nhwc को संबोधित करते रह सकते हैं

nhwc[N][C][H][W]

@VitalyFedyunin यह समझ में आता है।

उपयोगकर्ता के दृष्टिकोण से, विधि का नामकरण (यदि यह इस तरह रहता है) मुझे भ्रामक लगता है क्योंकि "to" पहले से ही विभिन्न उपकरणों के लिए Tensor को स्थानांतरित करने का अनुशंसित तरीका है।

साथ ही, C_ORDER और F_ORDER सरणियों को परिवर्तित करने के लिए Numpy's one जैसी किसी चीज़ के बारे में क्या?

numpy.asfortranarray()
numpy.ascontiguousarray()

कोई आसानी से कुछ इस तरह की कल्पना कर सकता है:

torch.randn(32, 3, 64, 64).to(device).as_nhwc()

@VitalyFedyunin : मैं समझता हूं कि एक अलग मेमोरी_फॉर्मैट में रूपांतरण उपयोगकर्ताओं को मैन्युअल रूप से अनुमति देने की आवश्यकता को समाप्त करता है। हालाँकि, एक बार जब यह कार्यक्षमता टॉर्च में उपलब्ध हो जाती है, तो क्या होगा यदि उपयोगकर्ता उपरोक्त उल्लिखित अनुक्रम में फ़ंक्शन को कॉल करते हैं? हमारे पास कम से कम एक चेतावनी/त्रुटि संदेश होना चाहिए जिसमें कहा गया हो कि लेआउट परिवर्तन विफल हो गया है।

@VitalyFedyunin : मैं समझता हूं कि एक अलग मेमोरी_फॉर्मैट में रूपांतरण उपयोगकर्ताओं को मैन्युअल रूप से अनुमति देने की आवश्यकता को समाप्त करता है। हालाँकि, एक बार जब यह कार्यक्षमता टॉर्च में उपलब्ध हो जाती है, तो क्या होगा यदि उपयोगकर्ता उपरोक्त उल्लिखित अनुक्रम में फ़ंक्शन को कॉल करते हैं? हमारे पास कम से कम एक चेतावनी/त्रुटि संदेश होना चाहिए जिसमें कहा गया हो कि लेआउट परिवर्तन विफल हो गया है।

यह तभी संभव होगा जब हम नामांकित टेंसर लागू करेंगे। क्योंकि अभी:

x.zeros(10,10,10,10)
x = x.permute(0,2,3,1)

कोई मुझे नहीं बता सकता कि मैंने अभी-अभी nchw बनाया है या nhwc।

शायद मैंने मूल प्रस्ताव को गलत समझा, लेकिन क्या इस स्थिति को स्पष्ट करने के लिए रिकॉर्ड किया गया स्मृति प्रारूप टैग नहीं है?

@VitalyFedyunin समझ में आता है, हमें यह सुनिश्चित करने की ज़रूरत है कि जब यह एपीआई स्थिर हो जाए तो यह अंतिम उपयोगकर्ताओं को सूचित किया जाए।

@dzhulgakov @VitalyFedyunin # x[0] ; यदि x पहले NHWC टेंसर था, तो मुझे ऐसा करने के बाद HWC टेंसर निकालना चाहिए। मुझे पूरा यकीन है कि विटाली का पैच इसे सही तरीके से नहीं संभालता है, और मुझे यकीन है कि यह उपयोगकर्ताओं के लिए बहुत भ्रमित करने वाला होगा। शायद केवल वही ऑपरेटर प्रभावित होते हैं जो प्रगति के साथ गड़बड़ करते हैं (इस मामले में, उनमें से बहुत अधिक नहीं हैं और हम उन्हें मैन्युअल रूप से ऑडिट कर सकते हैं), लेकिन ऐसा लगता है कि हमें ऐसा करना चाहिए। तुम क्या सोचते हो?

रुको, टेंसर अभी भी इस क्रम में अनुक्रमित हैं: 0-मंद एन; पहला-मंद सी; 2-मंद एच; 3-मंद W. तो x[0] 0-मंद C के साथ टेंसर लौटाता है; पहला-मंद एच; दूसरा-मंद W. भले ही x channel_first या channel_last मेमोरी लेआउट हो।

अन्यथा memory_format का कोई मतलब नहीं है और हमें केवल टेंसर को अनुमति देने की आवश्यकता है।

मेरा कहना है कि स्मृति प्रारूप टैग संरक्षित नहीं है। यदि इनपुट टेंसर को channels_last टैग किया गया था, तो नए टेंसर को any

cc @zou3519 , यहाँ लेआउट प्रसार तर्क मुझे नामित टेंसर कार्य में बहुत सारे नामित आयाम प्रसार की याद दिलाता है।

मैं अभी भी इस प्रस्ताव पर पकड़ बना रहा हूं। लेकिन @ezyang हम प्रति-आयाम ध्वज (या नाम) का प्रचार करके लेआउट प्रचार तर्क का ट्रैक रख सकते हैं और फिर यह नाम सम्मेलनों के साथ नामित टेंसर के बराबर होगा

यह साफ-सुथरा होगा यदि हम मेमोरी टैग लॉजिक और नामित टेंसर लॉजिक को बिल्कुल ठीक कर सकते हैं, भले ही हमारे पास शुरुआत में दो अलग-अलग कार्यान्वयन पथ हों।

चरण एक

दो टेंसर फ़ंक्शंस .is_contiguous और .contiguous (पायथन और सी ++ एपीआई दोनों) की कार्यक्षमता का विस्तार करता है।

नोट: हमारे पास .to(memory_format) फ़ंक्शन के बारे में कई शिकायतें थीं, और हमने इसका समर्थन नहीं करने का निर्णय लिया।

1. .contiguous अब वैकल्पिक कीवर्ड-केवल तर्क का समर्थन करता है - memory_format , जो या तो torch.contiguous_format या torch.channels_last ।

   • torch.contiguous_format का उपयोग करने से मौजूदा .contiguous() व्यवहार सुरक्षित रहेगा।

   • कॉल करना x.contiguous(memory_format=torch.channels_last) नया टेंसर लौटाता है जो समान अर्थपूर्ण लेआउट (NCHW) बनाए रखता है, लेकिन अलग मेमोरी आवंटन पैटर्न है।

     x.contiguous(memory_format=torch.channels_last) इनपुट टेंसर के 3d, 4d या 5d होने की उम्मीद है; और अन्यथा विफल रहता है।

2. .is_contiguous अब केवल वैकल्पिक कीवर्ड तर्क का समर्थन करता है - memory_format , जो या तो torch.contiguous_format या torch.channels_last ।

   • x.is_contiguous(memory_format=torch.contiguous_format) x.is_contiguous() समान कार्यक्षमता को बरकरार रखता है और अपरिवर्तित रहता है।

   • x.is_contiguous(memory_format=torch.channels_last) अगर ए) इनपुट टेंसर मेमोरी में सन्निहित है और बी) एनडब्ल्यूएचसी (या 3 डी, 5 डी के लिए समान) में मेमोरी में आवंटित किया गया है, तो सच हो जाता है।

नोट: चरण के अंत तक x.is_contiguous(memory_format=torch.channels_last) प्रत्येक कॉल पर टेंसर की स्थिति की गणना करेगा। यह कार्यक्षमता बाद में अपडेट की जाएगी।

2 चरण

विशिष्ट संचालन के लिए स्मृति प्रारूप को संरक्षित करें:

1. यूनरी तत्व-वार ऑपरेटर channel_last मेमोरी फॉर्मेट को सुरक्षित रखते हैं।

   a = torch.randn(N,C,H,W)
   b = a.contiguous(memory_format=torch.channels_last)
   c = b.sin()
   c.is_contiguous(memory_format=torch.channels_last) == True
   

2. बाइनरी तत्व-वार ऑपरेटर ( add , sub , mul , div ) channel_last मेमोरी प्रारूप को संरक्षित करते हैं।

   a = torch.randn(N,C,H,W)
   b = a.contiguous(memory_format=torch.channels_last)
   c = b * torch.randn(H,W)
   c.is_contiguous(memory_format=torch.channels_last) == True
   

3. साइज़, स्ट्राइड्स और डिम्स ऑर्डर पर कोई भी ऑपरेशन मेमोरी फॉर्मेट को रीसेट करता है।

   a = torch.randn(N,C,H,W)
   b = a.contiguous(memory_format=torch.channels_last)
   c = b.permute(0,2,3,1).permute(0,3,1,2)
   c.is_contiguous(memory_format=torch.channels_last) == False
   

अनिर्णीत रहता है

1. यदि आउटपुट 'चैनल_लास्ट' सुपाठ्य है, तो रीशेप (और समान) ऑपरेशन का परिणाम

   import torch
   a = torch.randn(N,C,H,W)
   b = a.contiguous(memory_format=torch.channels_last)
   c = b.reshape(N,C,-1)
   c.is_contiguous(memory_format=torch.channels_last) # ?
   

   नोट: वर्तमान में memory_format संरक्षित नहीं है

2. NHWC + NCHW संचालन का परिणाम। क्या यह एनएचडब्ल्यूसी है?

   नोट: वर्तमान में NHWC + NCHW -> NHWC और NCHW + NHWC -> NHWC

बिल्ली/विभाजन जैसे संचालन के बारे में क्या? स्मृति प्रारूप को संरक्षित करना उनके लिए उपयोगी होगा।

@ezyang - अनुक्रमण के संबंध में मुझे लगता है कि हमें कहीं रुक जाना चाहिए। विभिन्न मेमोरी लेआउट पूरी तरह से पारदर्शी नहीं हैं और कुछ ऑप्स को उनकी अवहेलना करने की अनुमति दी जानी चाहिए। मेरा तर्क है कि x[0] को x[0].unsqueeze(0) सहित टैग को मिटाने की अनुमति दी जानी चाहिए

जैसा कि रघु ने उल्लेख किया है, यदि संभव हो तो बिल्ली/विभाजन को टैग को संरक्षित करना चाहिए, हालांकि यह काफी सामान्य उपयोग है। मुझे लगता है कि अंगूठे का सामान्य नियम यह होना चाहिए कि जब तक ऑपरेटिंग रैंक नहीं बदलता है या धुरी को अजीब तरह से बदल देता है, हमें टैग को संरक्षित करना चाहिए। यदि रैंक बदलता है - सभी बेट्स बंद हैं।

मैं सहमत हूं कि कुछ मामलों में हम टैग खो देंगे। लेकिन मैं x[0] बारे में असहमत हूं। यह मेरे लिए NCHW से CHW तक जाने का एक बहुत ही सामान्य तरीका प्रतीत होता है।

इस बारे में कई बातचीत के बाद कि Tensors को channel_last 'टैग' ले जाने (या नहीं) करने में कितना भ्रमित है, हमने bc-ब्रेकिंग परिवर्तन और चैनल_लास्ट प्रारूप में ऑटो-प्रमोशन टेंसर को पेश करने का जोखिम उठाने का फैसला किया।

एपीआई के लिए इसका क्या अर्थ है:

N,1,H,[W,[D]] जैसे स्ट्राइड वाले किसी भी 3d, 4d, 5d टेंसर को स्वचालित रूप से channel_last मेमोरी फॉर्मेट मिल जाएगा।

इसे काम करने के लिए, हम इस बात की गारंटी देने के लिए विशेष सावधानी बरतेंगे कि channel_last tensors पर ऑपरेटर जो channel_last tensors को आउटपुट करते हैं, उनका कम से कम सन्निहित टेंसर पर ऑपरेटरों के समान प्रदर्शन होगा।

सबसे खराब स्थिति में:
1) उपयोगकर्ता आउटपुट पर .contiguous() को कॉल कर सकते हैं।
2) हम ऑटो-प्रमोशन कोड इस तरह से लिखेंगे कि इस व्यवहार को बदलना लगभग तुच्छ होगा।

ऐसे ऑटो प्रचार के दुष्प्रभाव हैं:

import torch
x = torch.randn(10,16,16,3).permute(0,3,1,2) 
x.is_contiguous(memory_format=torch.channels_last) == True

दूसरी ओर यह मामले को हल कर सकता है (हल्के संशोधनों के बाद):

import torch
x = torch.randn(10,3,16,16).contiguous(memory_format=torch.channels_last)
x = x[0].unsqueeze(0)
x.is_contiguous(memory_format=torch.channels_last) == True

सुस्त रूपांतरणों से, @ezyang के अनुरोध के अनुसार

नतालिया गिमेलशेन [2:19 अपराह्न]
इसलिए मैं मानता हूं कि टैग की कोई अवधारणा नहीं होगी।

import torch
#batch = 10, channels = 4, spatial dimensions = 16
x = torch.randn(10,16,16,4).permute(0,3,1,2)
x.is_contiguous(memory_format=torch.channels_last) == True
y = torch.randn(10,16,16,2).permute(0,3,1,2)
x1,x2 = x.chunk(2, dim=1) #chunk along channels dimension, no longer contiguous
x1.is_contiguous(memory_format=torch.channels_last) == False #right? So, if a tensor like this comes into e.g. convolution, what am I supposed to do with it? Did it want to be NHWC? Did it want to be nchw?
z=y+x1 #y is channels_last, x1 is something, what is the z layout?```

विटाली फेड्युनिन [8:23 पूर्वाह्न]
z channel_last . होने जा रहा है

विटाली फेड्युनिन [8:25 पूर्वाह्न]
यदि X1 किसी भी प्रस्तावित वेरिएंट में channel_last नहीं है (जब तक कि हम चंक फंक्शन को वापस नहीं करने के लिए बदलते हैं), तो कनवल्शन इसे सन्निहित (चैनल_फर्स्ट) फॉर्मेट में बदल देगा और सन्निहित भी लौटाएगा

विटाली फेड्युनिन [9:12 AM]
@ngimel प्रतिक्रिया के लिए धन्यवाद, मुझे लगता है कि जब दृश्य-समान संचालन शामिल होते हैं तो अधिकांश मामलों को कवर करने के लिए हम

नतालिया गिमेलशेन [9:36 पूर्वाह्न]
एक धागे का जवाब दिया:
तो ऐसा लगता है कि कोई समस्या है, नहीं? चैनलों के आयामों को विभाजित करना एक अपेक्षाकृत सामान्य बात है, उदाहरण के लिए स्थापना जैसे नेटवर्क में। तो अगर टेंसर चैनल पहले टेंसर को खंडित किया जाता है, तो कनवल्शन आउटपुट चैनल-फर्स्ट होगा (जो सहज ज्ञान युक्त व्यवहार है, और सबसे अधिक संभावना है कि उपयोगकर्ता क्या चाहता है), यदि टेंसर चैनल-आखिरी है तो कन्वेक्शन आउटपुट एक बार फिर चैनल पहले होगा?

नतालिया गिमेलशेन [9:39 पूर्वाह्न]
एक धागे का जवाब दिया:
लेकिन केवल गैर-कम्यूटेटिव जोड़ व्यवहार के कारण और y पहले तर्क और चैनल आखिरी होने के कारण, है ना? x1+y का परिणाम क्या होगा? क्या हमारे पास कहीं बाइनरी ऑपरेशंस के लिए लेआउट प्रचार नियम हैं?

विटाली फेड्युनिन [10:44 पूर्वाह्न]
1) हाँ, यह समस्या है जिसे हम वैकल्पिक प्रस्ताव के साथ हल करने जा रहे हैं। मैं अभी कुछ परीक्षण करने जा रहा हूं और इसे इस सप्ताह (या दो दिनों में) लिखूंगा।
2) x1+y - भी channel_last का निर्माण करना चाहिए अन्यथा यह भ्रमित करने वाला है, और हां, हमारे पास लेआउट प्रचार नियम लिखे होंगे।

मुझे लगता है कि जब हमने इस व्यक्ति के बारे में बात की तो मैंने @VitalyFedyunin को जो अवलोकन किया (लेकिन मुझे नहीं लगता कि मुझे इसे कहीं भी लिखना याद आया), यह है कि

लेकिन ऐसा लगता है कि थ्रैश आउट करने के लिए यहां बहुत सारे विवरण हैं, और मुझे यकीन नहीं है कि यह अंत में काम करता है।

तो कनवल्शन की आलस्य (और अन्य लेआउट-जागरूक ऑपरेटरों, उस मामले के लिए, उदाहरण के लिए अपसैंपलिंग जिसे मैंने हाल ही में इनपुट पर .contiguous() कॉल करके शुरू किया है - तो इसका क्या मतलब है?) प्राथमिक कारण था टैग शुरू करने के लिए, आईआईआरसी।

हाँ, इसलिए मैं टैग डिज़ाइन को फिर से क्रैक करने के साथ ठीक हूँ, लेकिन फिर हम
इन टैगों को कैसे प्रचारित किया जाए, इसकी समस्याओं को गंभीरता से हल करना होगा,
यहां तक ​​​​कि जब आप लेआउट खो देते हैं (जैसा कि चंकिंग के मामले में होता)
चैनलों पर)। मुझे कुछ "वर्तमान लेआउट" बनाने का अधिक शौक है
संदर्भ प्रबंधक की तरह, इसे डेटा पर निर्भर बनाने के बजाय।

नगिमेल के 2019-06-19 12:43:45 -0700 के संदेश के अंश:

तो कनवल्शन की आलस्य (और अन्य लेआउट-जागरूक ऑपरेटरों, उस मामले के लिए, उदाहरण के लिए अपसैंपलिंग जिसे मैंने हाल ही में इनपुट पर .contiguous() कॉल करके शुरू किया है - तो इसका क्या मतलब है?) प्राथमिक कारण था टैग शुरू करने के लिए, आईआईआरसी।

BTW हमें केवल layout चिपके रहने के बजाय एक नई अवधारणा क्यों बनानी है? मुझे नहीं लगता कि विरल प्रतिनिधित्व में "चैनल_लास्ट" जैसे लेआउट की एक अच्छी तरह से परिभाषित अवधारणा है, इसलिए हमें memory_formats * layouts उत्पाद का प्रतिनिधित्व करने की आवश्यकता नहीं है ( layouts वर्तमान उपयोग को संदर्भित करता है ), लेकिन केवल memory_format + layouts अर्थ है कि उसी तर्क का उपयोग करना ठीक होना चाहिए जैसा हम करते थे? मेरे लिए यह दोनों छोटे, अच्छे हैं, और हमें कारखानों के हस्ताक्षर को एक हजार तर्कों तक विस्तारित करने से बचने देंगे।

लेआउट विकल्प पर विचार किया गया था (परिशिष्ट की जाँच करें), लेकिन हमने पाया कि यह बहुत सारे कोड दोहराव को जन्म देगा और साथ ही ऑटो कन्वर्टिंग टेंसर को एक अलग मेमोरी_फॉर्मैट पर अनुमति नहीं देगा।

आखिरकार मेमोरी_फॉर्मैट टेंसर को स्ट्राइड करने और अनुकूलित कर्नेल और आउटपुट को आसानी से लेने का तरीका है जो स्ट्राइडेड टेंसर की संपत्ति है, पूरी तरह से अलग वर्ग नहीं

कुछ अर्थों में स्पैस लेआउट भी सरणी के लिए अनुकूलित कर्नेल को आसानी से चुनने का एक तरीका है जो अधिकतर शून्य है क्या आप "फ्लाई पर एक अलग मेमोरी_फॉर्मैट पर ऑटो कनवर्टिंग टेंसर को अस्वीकार करने के साथ-साथ" भाग के बारे में विस्तार से बता सकते हैं?

यह एक भोला सवाल हो सकता है, लेकिन क्यों PyTorch इस एपीआई पर विचार कर रहा है बनाम सिर्फ ऑप्स में NHWC का उपयोग करने के विकल्प को उजागर कर रहा है, जो सीधे अंतर्निहित CuDNN कर्नेल को कॉल करेगा जहां उपलब्ध है?

यह एक सामान्य उपयोग के मामले की तरह लगता है (एलएम आर्किटेक्चर के साथ छवि ऑप्स जैसे रूपांतरण और पूलिंग को मिलाकर) यह एक आसान समाधान होगा। एक डेवलपर के रूप में, मैं केवल एक Conv2d(..., nhwc=True) चाहता हूं। क्या कोई कारण है कि इसका कोई मतलब नहीं है?

@rewonc हमने समान दृष्टिकोण पर विचार किया है (

• इस दृष्टिकोण के लिए कर्नेल को NHWC कर्नेल को लागू करने के लिए सन्निहित टेंसर के पुनर्विक्रय करने की आवश्यकता होगी।
• अगले ऑपरेटर को इनपुट को फिर से (सन्निहित में) प्रतिबंधित करना होगा जब तक कि उसके पास nhwc=True विकल्प भी न हो।
• पूरे नेटवर्क में NHWC होने के लिए, प्रत्येक एक ऑपरेटर को nhwc=True विकल्प की आवश्यकता होगी।

पुनश्च. यदि आप CudNN Ex फ़ंक्शंस के बारे में चिंतित हैं, तो हम cudnn_batch_norm_nhwc और इसी तरह के ऑपरेटरों को बेनकाब करना चाहते हैं।

हाय @VitalyFedyunin , हमने देखा कि नामित टेंसर को PyTorch 1.3 में समर्थित किया गया था। क्या यह NHWC (या यहां तक ​​कि अवरुद्ध) प्रारूप समर्थन पर चिंताओं को हल (या आंशिक रूप से हल) कर सकता है? क्या नामित टेंसर के आधार पर NHWC राज्य को आगे बढ़ाने की कोई योजना है?

हम चैनलों के अंतिम समर्थन के साथ आगे बढ़ रहे हैं, मैं इस सप्ताह यहां और सुस्त चैनलों में रोडमैप प्रकाशित करूंगा। हम जल्द ही किसी भी समय अवरुद्ध प्रारूपों को जोड़ने पर विचार नहीं कर रहे हैं (क्योंकि इसके लिए सभी ऑपरेटरों को फिर से लिखना होगा)।

धन्यवाद। यह अच्छा होगा!

https://github.com/pytorch/pytorch/issues/28619 . के अंदर कार्यों और प्रगति को संभालना