एक्सएलए में एलियासिंग

इस दस्तावेज़ में XLA एलियासिंग एपीआई के बारे में बताया गया है, जिससे आपको यह तय करने में मदद मिलती है कि XLA प्रोग्राम बनाते समय, इनपुट और आउटपुट बफ़र को अलग-अलग ग्रुप में बांटना.

कंपाइलेशन के समय एलियासिंग तय करना

उदाहरण के लिए, एक छोटा-सा HLO मॉड्यूल देखें, जो 1 को बस अपने इनपुट में जोड़ देता है:

HloModule increment

ENTRY entry {
  %p = f32[] parameter(0)
  %c = f32[] constant(1)
  ROOT %out = f32[] add(%p, %c)
}

इस मॉड्यूल को दो 4-बाइट बफ़र मिलेंगे: एक इनपुट %p के लिए और दूसरा %out आउटपुट के लिए.

हालांकि, अपडेट करने की प्रोसेस हमेशा मौजूदा जगह पर ही की जानी चाहिए (उदाहरण के लिए, अगर फ़्रंटएंड एक्सप्रेशन में, इनपुट वैरिएबल अब मौजूद नहीं है हिसाब लगाने के बाद, जैसा कि p++ में दिखाया गया है).

ऐसा अपडेट कुशलता से करने के लिए, आप इनपुट एलियासिंग तय कर सकते हैं:

HloModule increment, input_output_alias={ {}: 0 }

ENTRY entry {
  %p = f32[] parameter(0)
  %c = f32[] constant(1)
  ROOT %out = f32[] add(%p, %c)
}

फ़ॉर्मैट तय करता है कि पूरा आउटपुट ({} से मार्क किया गया) इनपुट पैरामीटर 0.

प्रोग्रामेटिक रूप से एलियासिंग तय करने के लिए, देखें XlaBuilder::SetUpAlias एपीआई.

रनटाइम पर एलियासिंग के बारे में जानकारी

पिछले चरण में तय किया गया एलियासिंग, कंपाइलेशन के दौरान तय होता है. निष्पादन के दौरान, आप LocalClient::RunAsync एपीआई तय करें कि बफ़र को डालना है या नहीं.

प्रोग्राम के लिए इनपुट बफ़र को रैप किया गया है ExecutionInput, साथ ही, इसमें MaybeOwningDeviceMemory पेड़ भी शामिल होता है. अगर मेमोरी owning के तौर पर बताया गया है (बफ़र का मालिकाना हक, XLA रनटाइम को दिया जाता है), बफ़र को असल में दान किया जाता है और अपडेट को इस तरह से लागू किया जाता है कंपाइल-टाइम एलियासिंग एपीआई से अनुरोध किया जाता है.

हालांकि, अगर कंपाइल समय पर एलियास किया गया बफ़र, not को रनटाइम, copy-protection का इस्तेमाल शुरू करता है: एक अतिरिक्त आउटपुट बफ़र O बांटा जाता है, और एलियास किए जाने वाले इनपुट बफ़र P की सामग्री कॉपी कर दी गई है O में डालें (इस तरह से, प्रोग्राम इस तरह काम कर सकता है जैसे बफ़र O रनटाइम के दौरान दान किया जाता है).