OpenXLA-তে সকলেই অবদান রাখতে পারেন, এবং আমরা সকলের অবদানকে মূল্য দিই। অবদান রাখার বিভিন্ন উপায় রয়েছে, যার মধ্যে রয়েছে:
OpenXLA-এর আলোচনা ফোরামে প্রশ্নের উত্তর দেওয়া (openxla-discuss)
OpenXLA এর ডকুমেন্টেশন উন্নত বা সম্প্রসারণ করা
OpenXLA এর কোড-বেসে অবদান রাখা
OpenXLA-তে নির্মিত লাইব্রেরির বৃহত্তর ইকোসিস্টেমে উপরের যেকোনো উপায়ে অবদান রাখা
OpenXLA প্রকল্পটি Google এর ওপেন সোর্স কমিউনিটি নির্দেশিকা অনুসরণ করে।
শুরু করার আগে
অবদানকারী লাইসেন্স চুক্তিতে স্বাক্ষর করুন
এই প্রকল্পে অবদানের সাথে একটি অবদানকারী লাইসেন্স চুক্তি (CLA) অবশ্যই থাকতে হবে। আপনার (অথবা আপনার নিয়োগকর্তার) কাছে আপনার অবদানের কপিরাইট থাকবে; এটি কেবল আমাদের প্রকল্পের অংশ হিসাবে আপনার অবদান ব্যবহার এবং পুনর্বণ্টন করার অনুমতি দেয়।
যদি আপনি অথবা আপনার বর্তমান নিয়োগকর্তা ইতিমধ্যেই Google CLA-তে স্বাক্ষর করে থাকেন (যদিও এটি অন্য কোনও প্রকল্পের জন্য ছিল), তাহলে সম্ভবত আপনার এটি আবার করার প্রয়োজন নেই।
আপনার বর্তমান চুক্তিগুলি দেখতে অথবা নতুন চুক্তিতে স্বাক্ষর করতে < https://cla.developers.google.com/ > দেখুন।
আচরণবিধি পর্যালোচনা করুন
এই প্রকল্পটি টেনসরফ্লো-এর আচরণবিধি অনুসরণ করে।
অবদান প্রক্রিয়া
ডেভেলপার গাইড
OpenXLA-এর জন্য একটি ডেভেলপমেন্ট এনভায়রনমেন্ট কীভাবে সেটআপ করবেন, যার মধ্যে কোড পাওয়া, এটি তৈরি করা, পরীক্ষা চালানো এবং পরিবর্তন জমা দেওয়া অন্তর্ভুক্ত, সে সম্পর্কে একটি নির্দেশিকা জানতে, অনুগ্রহ করে ডেভেলপার গাইডটি পড়ুন।
অবদান নির্দেশিকা
কম্পাইলারের আর্কিটেকচার নিম্নলিখিত উপাদানগুলি নিয়ে গঠিত।
অপ্টিমাইজেশন পাস
অপ্টিমাইজেশন HLO-তে এক্সিকিউট ট্রান্সফর্মেশন পাস করে কম্পিউটেশনাল দক্ষতা বাড়াতে। এই রূপান্তরগুলি আর্কিটেকচার-অ্যাগনস্টিক, উচ্চ-স্তরের উন্নতি থেকে শুরু করে হার্ডওয়্যার-নির্দিষ্ট সমন্বয় (যেমন, NVIDIA GPU-এর জন্য) পর্যন্ত বিস্তৃত।
আমরা সাধারণত যা গ্রহণ করি:
- এমন পাস যা একাধিক কাজের চাপ জুড়ে সাধারণীকরণ করে এবং কর্মক্ষমতা মানদণ্ডের উপর একটি স্পষ্ট এবং উল্লেখযোগ্য ইতিবাচক প্রভাব প্রদর্শন করে।
আমরা সাধারণত যা প্রত্যাখ্যান করি:
- নির্দিষ্ট মডেলগুলিকে লক্ষ্য করে অনন্য অপ্টিমাইজেশন সম্পাদন করে এমন পাস।
ফিউশন পাস
ফিউশন হল একটি গুরুত্বপূর্ণ অপ্টিমাইজেশন যা একাধিক HLO অপারেশনকে একটি একক কার্নেলে একত্রিত করে মেমরি I/O এবং কার্নেল লঞ্চ ওভারহেড কমাতে সাহায্য করে।
সমস্ত ফিউশন পাস শুধুমাত্র ফিউশন পাইপলাইনে যোগ করা উচিত, আগে বা পরে নয়। এর অর্থ হল প্রি-অপ্টিমাইজড এইচএলও মডিউলে ফিউশন নির্দেশাবলী থাকা উচিত নয়। যদি পাইপলাইনের শুরুতে ফিউশন তৈরি হয়, তবে এটি অপ্টিমাইজেশন পাসের জন্য একটি বাধা হয়ে দাঁড়ায়। যদি ফিউশন দেরিতে তৈরি হয়, তাহলে আমরা জেনারেটেড ফিউশনের জন্য ব্যাকএন্ড নির্বাচন এবং টিউন করার ক্ষমতা হারাতে পারি।
কাস্টম কলগুলিতে ফিউশন, অর্থাৎ প্যাটার্ন-ম্যাচিং কাস্টম কলগুলিকে প্রযোজক/ভোক্তাদের সাথে এবং নতুন কাস্টম কলগুলিতে পুনর্লিখন অনুমোদিত নয়। সেক্ষেত্রে, এটি একটি সঠিক ফিউশন পাস দিয়ে প্রতিস্থাপন করা উচিত।
অনুভূমিক স্কেলিং
অনুভূমিক স্কেলিংয়ে অবদানের মধ্যে রয়েছে HLO অপ্টিমাইজেশন, খরচ মডেলের উন্নতি, লাইব্রেরি আপডেট এবং বিভিন্ন অবকাঠামোগত পরিবর্তন। কর্মক্ষমতা লাভ পুনরুৎপাদন করতে অসুবিধা এবং অভ্যন্তরীণভাবে মাল্টি-হোস্ট কনফিগারেশনের সীমিত প্রয়োজনীয়তার কারণে, আমরা কঠোর গ্রহণযোগ্যতার মানদণ্ড মেনে চলি:
আমরা কম ঝুঁকি বহনকারী ন্যূনতম আক্রমণাত্মক পরিবর্তনগুলিকে অগ্রাধিকার দিই।
আমরা সাধারণত যা গ্রহণ করি:
আন্তঃ-GPU বা আন্তঃহোস্ট যোগাযোগ পরিচালনাকারী লাইব্রেরির আপডেট।
নতুন প্ল্যাটফর্মের জন্য পারফর্মেন্স টেবিল আপডেট।
আমরা সাধারণত যা প্রত্যাখ্যান করি:
HLO একটি নির্দিষ্ট মডেলের সাথে মানানসই পুনর্লিখন বা রানটাইম পরিবর্তন করে।
অবকাঠামোগত পরিবর্তন যা নতুন পতাকা, প্রযুক্তিগত ঋণ বা রিগ্রেশন প্রবর্তন করে।
ব্যাকএন্ড এবং অটোটিউনিং
অপ্রচলিত অপশনের ব্যাকএন্ড, যেমন কাস্টম কল এবং ফিউশন, কোডজেনব্যাকেন্ড ইন্টারফেস বাস্তবায়ন করবে।
এই ইন্টারফেসটি সর্বোত্তম ব্যাকএন্ড নির্বাচন সক্ষম করার জন্য প্রয়োজনীয়, কারণ এটি অটোটিউনারের অনুসন্ধান স্থানে প্রদত্ত HLO নির্দেশাবলীর জন্য পরামিতিগুলি অন্তর্ভুক্ত করার পদ্ধতিগুলি সরবরাহ করে।
// Returns all supported configs for the given HLO instruction.
virtual absl::StatusOr<std::vector<std::unique_ptr<BackendConfig>>>
GetSupportedConfigs(const HloInstruction& instr);
// Returns a default config for the given HLO instruction.
virtual absl::StatusOr<std::unique_ptr<BackendConfig>> GetDefaultConfig(
const HloInstruction& instr);
রানটাইম
XLA কম্পাইলেশন পাইপলাইনের শেষ ফলাফল হল একটি থাঙ্ক সিকোয়েন্স যা সিরিয়ালাইজ করা যেতে পারে।
নতুন সকল thunk টাইপ সিরিয়ালাইজেবল হওয়া উচিত, অর্থাৎ GpuCompiler অথবা CpuCompiler প্রোগ্রামটি কম্পাইল করতে, সিরিয়ালাইজ করতে সক্ষম হওয়া উচিত, যাতে পরবর্তীতে XLA রানার প্রোগ্রামটি লোড এবং এক্সিকিউট করতে পারে। এর মানে হল HloInstruction বা কম্পাইলারের অন্যান্য অংশ বা StreamExecutor এর দিকে কোন নির্দেশিকা থাকা উচিত নয়।
কোড স্ট্যান্ডার্ড
কোডিং স্টাইল : আমরা গুগলের কোড স্টাইল গাইড অনুসরণ করি। বিশেষ করে C/C++ এবং পাইথন গাইডগুলি দেখুন। জমা দেওয়া সমস্ত কোড অবশ্যই এই স্টাইল গাইডগুলির সাথে কঠোরভাবে সঙ্গতিপূর্ণ হতে হবে।
কম্প্যাক্ট পরিবর্তন : আমরা গুগলের ইঞ্জিনিয়ারিং পদ্ধতি অনুসরণ করি। বিশেষ করে, কম্প্যাক্ট পরিবর্তন লেখার নির্দেশিকাটি অনুসরণ করুন। এটি করার ফলে পর্যালোচনাযোগ্যতা উন্নত হওয়ার কারণে আপনার কোড একত্রিত করার গতি অনেক বেড়ে যাবে এবং পরিবর্তনের অনিচ্ছাকৃত পার্শ্বপ্রতিক্রিয়ার সম্ভাবনা হ্রাস পাবে। এমনকি যদি আপনার একটি বড় পরিবর্তন থাকে, তবুও এটিকে আরও ক্রমবর্ধমান পরিবর্তনে বিভক্ত করার জন্য অনেক কৌশল রয়েছে।
পরীক্ষার কভারেজ : সমস্ত পরিবর্তনের মধ্যে উপযুক্ত ইউনিট পরীক্ষা অন্তর্ভুক্ত করা উচিত। ইউনিট পরীক্ষাগুলি নির্দিষ্ট হার্ডওয়্যার (CPU, GPU, ইত্যাদি) সময়ের উপর নির্ভরশীল হওয়া উচিত নয় এবং নির্ধারক এবং কেন্দ্রীভূত পরীক্ষা করার জন্য মক এবং নকলের উদার ব্যবহার করা উচিত। বর্তমানে পরীক্ষা করা কঠিন এমন বিদ্যমান কোড প্রসারিত করার জন্য পরিবর্তনগুলি পরীক্ষাযোগ্যতার ক্ষেত্রে যথাযথ উন্নতি করা উচিত।
সমস্ত পরিবর্তনের ক্ষেত্রে পরিবর্তনের শিরোনামে উপযুক্ত বেঞ্চমার্ক ফলাফলও অন্তর্ভুক্ত করা উচিত যাতে সুবিধাগুলি স্পষ্টভাবে বোঝা যায়।
কোডের মধ্যে প্রচলিত নিয়মাবলী সম্পর্কে সন্দেহ থাকলে, পূর্ব-বিদ্যমান কোড পরীক্ষা করা এবং OpenXLA-তে ইতিমধ্যেই বিদ্যমান প্যাটার্নগুলি অনুসরণ করার চেষ্টা করা সর্বদা একটি ভাল ধারণা।
পর্যালোচনা প্রক্রিয়া
প্রকল্পের সদস্যদের জমা সহ সকল জমা পর্যালোচনা প্রয়োজন। আমরা এই উদ্দেশ্যে GitHub পুল রিকোয়েস্ট ব্যবহার করি। পুল রিকোয়েস্ট ব্যবহার সম্পর্কে আরও তথ্যের জন্য GitHub সহায়তা দেখুন।
পর্যালোচনার আগে কোডটি উপরে তালিকাভুক্ত সমস্ত মান অনুসরণ করতে হবে। এগুলি ঐচ্ছিক নয় এবং পরিবর্তনগুলি সময়মত গ্রহণযোগ্যতা নিশ্চিত করার জন্য পর্যালোচনার অনুরোধ করার আগে জমাদাতার জন্য তাদের কোডটি মেনে চলা নিশ্চিত করা অত্যন্ত গুরুত্বপূর্ণ।
সকল পরীক্ষা অবশ্যই পাস করতে হবে । যদি আপনি দেখেন যে একটি পরীক্ষা ব্যর্থ হয়েছে এবং সমস্যাটি আপনার বিল্ড পরিবেশ বা অন্যথায় আপনার পরিবর্তনগুলির সাথে সম্পর্কিত নয়, তাহলে অনুগ্রহ করে রক্ষণাবেক্ষণকারীদের সাথে যোগাযোগ করুন।
পর্যালোচনা প্রক্রিয়ার সময় সুযোগের ঘাটতি এড়াতে চেষ্টা করুন। এটি জমাদাতা এবং পর্যালোচক উভয়েরই দায়িত্ব। যদি কোনও পরিবর্তন খুব বেশি হতে শুরু করে, তাহলে এটিকে একাধিক পরিবর্তনে ভাগ করার কথা বিবেচনা করুন।
কোনও পরিবর্তন মার্জ করার আগে, এটি অভ্যন্তরীণ পরীক্ষার মধ্য দিয়ে যাবে যা Google এবং অন্যান্য হার্ডওয়্যার বিক্রেতাদের জন্য অভ্যন্তরীণ কোড ব্যবহার করে। যদি অভ্যন্তরীণ পরীক্ষায় কোনও ব্যর্থতা থাকে যা আমাদের পাবলিক CI ধরতে না পারে তবে এটি পর্যালোচনা প্রক্রিয়ায় অতিরিক্ত পদক্ষেপ যুক্ত করতে পারে। আপনার পরিবর্তন পর্যালোচনাকারী Googler কোনও অভ্যন্তরীণ পরীক্ষার ব্যর্থতা সম্পর্কে অবহিত করবেন এবং কী কী সংশোধন করা দরকার তা বর্ণনা করবেন।
প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী (FAQ)
"এই অবকাঠামোগত পরিবর্তন আমার জনসংযোগের সাথে সম্পর্কিত নয়। আমি কেন এটা করব?"
XLA টিমের কোনও নিবেদিতপ্রাণ অবকাঠামো দল নেই, তাই সহায়ক লাইব্রেরি তৈরি করা এবং প্রযুক্তিগত ঋণ এড়ানো আমাদের সকলের দায়িত্ব। আমরা এটিকে XLA-তে পরিবর্তন আনার একটি নিয়মিত অংশ হিসাবে বিবেচনা করি এবং সকলের অংশগ্রহণ আশা করা হয়। কোড লেখার সময় আমরা সাধারণত প্রয়োজন অনুসারে অবকাঠামো তৈরি করি।
XLA পর্যালোচকরা আপনার লেখা PR-এর সাথে কিছু অবকাঠামো তৈরি করতে (অথবা অন্যথায় PR-তে একটি বড় পরিবর্তন করতে) বলতে পারেন। আপনি যে পরিবর্তনটি করার চেষ্টা করছেন তার সাথে এই অনুরোধটি অপ্রয়োজনীয় বা অপ্রয়োজনীয় বলে মনে হতে পারে। এটি সম্ভবত আপনার কতটা অবকাঠামো তৈরি করতে হবে সে সম্পর্কে আপনার প্রত্যাশা এবং আপনার পর্যালোচকের প্রত্যাশার মধ্যে অমিলের কারণে।
প্রত্যাশার মধ্যে অমিল থাকা ঠিক আছে! যখন আপনি কোনও প্রকল্পে নতুন হন (এবং কখনও কখনও আমাদের পুরনোদের ক্ষেত্রেও এটি ঘটে) তখন এটি প্রত্যাশিত। আপনি অতীতে যে প্রকল্পগুলিতে কাজ করেছেন সেগুলির প্রত্যাশা ভিন্ন হতে পারে। এটিও ঠিক এবং প্রত্যাশিত! এর অর্থ এই নয় যে এই প্রকল্পগুলির কোনওটিরই ভুল পদ্ধতি রয়েছে; তারা কেবল আলাদা। এই প্রকল্পে আমরা কী আশা করি তা জানার সুযোগ হিসেবে আমরা আপনাকে অন্যান্য সমস্ত পর্যালোচনা মন্তব্যের সাথে ইনফ্রাস্ট্রাকচার অনুরোধ গ্রহণ করার জন্য আমন্ত্রণ জানাচ্ছি।
"আমি কি ভবিষ্যতের জনসংযোগে আপনার মন্তব্যের উত্তর দিতে পারি?"
পিআর-এ অবকাঠামোগত অনুরোধের (অথবা অন্যান্য বৃহৎ অনুরোধের) ক্ষেত্রে একটি ঘন ঘন প্রশ্ন হল, মূল পিআর-এ পরিবর্তনটি করা উচিত কিনা, নাকি ভবিষ্যতের পিআর-এ এটি ফলো-আপ হিসাবে করা যেতে পারে।
সাধারণভাবে, XLA জনসংযোগ লেখকদের পর্যালোচনা মন্তব্যের ক্ষেত্রে পরবর্তী জনসংযোগের অনুমতি দেয় না। যখন একজন পর্যালোচক সিদ্ধান্ত নেন যে কোনও একটি নির্দিষ্ট জনসংযোগে কিছু সমাধান করা প্রয়োজন, তখন আমরা সাধারণত আশা করি লেখকরা সেই জনসংযোগে এটি সমাধান করবেন, এমনকি যদি অনুরোধ করা হয় তবে তা একটি বড় পরিবর্তন। এই মানটি বাহ্যিকভাবে এবং Google-এর অভ্যন্তরেও প্রযোজ্য।
XLA এই পদ্ধতি গ্রহণের কয়েকটি কারণ রয়েছে।
আস্থা: পর্যালোচকের আস্থা অর্জন করা একটি গুরুত্বপূর্ণ উপাদান। একটি ওপেন-সোর্স প্রকল্পে, অবদানকারীরা ইচ্ছামত উপস্থিত হতে বা অদৃশ্য হয়ে যেতে পারেন। আমরা একটি পিআর অনুমোদন করার পরে, পর্যালোচকদের কাছে নিশ্চিত করার কোনও উপায় থাকে না যে কোনও প্রতিশ্রুত ফলো-আপ আসলে সম্পন্ন হয়েছে।
অন্যান্য ডেভেলপারদের উপর প্রভাব: যদি আপনি XLA-এর কোনও নির্দিষ্ট অংশের সাথে সম্পর্কিত কোনও PR পাঠিয়ে থাকেন, তাহলে অন্যরা একই অংশটি দেখছে এমন সম্ভাবনা বেশি। যদি আমরা আপনার PR-তে টেকনিক্যাল ঋণ গ্রহণ করি, তাহলে যারা এই ফাইলটি দেখছেন তারা ফলো-আপ জমা না দেওয়া পর্যন্ত এই ঋণের দ্বারা প্রভাবিত হবেন।
পর্যালোচক ব্যান্ডউইথ: ফলো-আপে পরিবর্তন স্থগিত করলে আমাদের ইতিমধ্যেই অতিরিক্ত চাপে থাকা পর্যালোচকদের উপর একাধিক খরচ চাপতে হয়। পর্যালোচকরা ফলো-আপের জন্য অপেক্ষা করার সময় সম্ভবত প্রথম পিআর কী ছিল তা ভুলে যাবেন, যার ফলে পরবর্তী পর্যালোচনা আরও কঠিন হয়ে পড়বে। এছাড়াও, পর্যালোচকদের প্রত্যাশিত ফলো-আপগুলির ট্র্যাক রাখতে হবে, নিশ্চিত করতে হবে যে সেগুলি আসলেই ঘটছে। যদি পরিবর্তনটি এমনভাবে করা যায় যাতে এটি আসল পিআরের সাথে সত্যিই অরথোগোনাল হয় যাতে অন্য কোনও পর্যালোচক এটি পর্যালোচনা করতে পারেন, তাহলে ব্যান্ডউইথের সমস্যা কম হবে। আমাদের অভিজ্ঞতায়, এটি খুব কমই ঘটে।