OpenXLA তে অবদান

প্রত্যেকেই OpenXLA-তে অবদান রাখতে পারেন এবং আমরা প্রত্যেকের অবদানকে মূল্য দিই। অবদান রাখার বিভিন্ন উপায় রয়েছে, যার মধ্যে অন্তর্ভুক্ত:

• OpenXLA-এর আলোচনা ফোরামে (openxla-discuss) প্রশ্নের উত্তর দেওয়া

• OpenXLA-এর ডকুমেন্টেশন উন্নত বা প্রসারিত করা

• OpenXLA-এর কোড-বেসে অবদান রাখা

• OpenXLA-এর উপর নির্মিত লাইব্রেরির বৃহত্তর ইকোসিস্টেমে উপরোক্ত যেকোনো উপায়ে অবদান রাখা।

ওপেনএক্সএলএ প্রকল্পটি গুগলের ওপেন সোর্স কমিউনিটি নির্দেশিকা অনুসরণ করে।

শুরু করার আগে

অবদানকারী লাইসেন্স চুক্তিতে স্বাক্ষর করুন

এই প্রকল্পে অবদানের সাথে অবশ্যই একটি অবদানকারী লাইসেন্স চুক্তি (CLA) সংযুক্ত থাকতে হবে। আপনার অবদানের কপিরাইট আপনার (বা আপনার নিয়োগকর্তার) কাছেই থাকবে; এটি কেবল প্রকল্পের অংশ হিসাবে আপনার অবদান ব্যবহার এবং পুনঃবিতরণ করার জন্য আমাদের অনুমতি দেয়।

যদি আপনি বা আপনার বর্তমান নিয়োগকর্তা ইতিমধ্যেই গুগল সিএলএ-তে স্বাক্ষর করে থাকেন (এমনকি যদি তা অন্য কোনো প্রকল্পের জন্যও হয়ে থাকে), তাহলে সম্ভবত আপনাকে এটি আবার করার প্রয়োজন নেই।

আপনার বর্তমান চুক্তিগুলো দেখতে বা নতুন চুক্তি স্বাক্ষর করতে < https://cla.developers.google.com/ > পরিদর্শন করুন।

আচরণবিধি পর্যালোচনা করুন

এই প্রকল্পটি টেনসরফ্লো-এর আচরণবিধি অনুসরণ করে।

অবদান প্রক্রিয়া

ডেভেলপার গাইড

OpenXLA-এর জন্য কীভাবে একটি ডেভেলপমেন্ট এনভায়রনমেন্ট সেটআপ করতে হয়, যার মধ্যে কোড সংগ্রহ করা, বিল্ড করা, টেস্ট চালানো এবং পরিবর্তন জমা দেওয়া অন্তর্ভুক্ত, সে সম্পর্কে বিস্তারিত জানতে অনুগ্রহ করে ডেভেলপার গাইডটি দেখুন।

অবদান নির্দেশিকা

কম্পাইলারের স্থাপত্য নিম্নলিখিত উপাদানগুলো নিয়ে গঠিত।

অপ্টিমাইজেশন পাস

অপ্টিমাইজেশন পাসগুলো কম্পিউটেশনাল দক্ষতা বাড়ানোর জন্য HLO-তে রূপান্তর সম্পাদন করে। এই রূপান্তরগুলো আর্কিটেকচার-নিরপেক্ষ উচ্চ-স্তরের উন্নতি থেকে শুরু করে হার্ডওয়্যার-নির্দিষ্ট সমন্বয় (যেমন, NVIDIA GPU-এর জন্য) পর্যন্ত বিস্তৃত।

আমরা সাধারণত যা মেনে নিই:

• এমন পাস যা একাধিক ওয়ার্কলোড জুড়ে প্রযোজ্য এবং পারফরম্যান্স বেঞ্চমার্কে একটি সুস্পষ্ট ও উল্লেখযোগ্য ইতিবাচক প্রভাব প্রদর্শন করে।

আমরা সাধারণত যা প্রত্যাখ্যান করি:

• এমন পাস যা নির্দিষ্ট মডেলকে লক্ষ্য করে অনন্য অপ্টিমাইজেশন সম্পাদন করে।

ফিউশন পাস

ফিউশন একটি গুরুত্বপূর্ণ অপ্টিমাইজেশন যা মেমরি আই/ও এবং কার্নেল লঞ্চ ওভারহেড কমানোর জন্য একাধিক এইচএলও অপারেশনকে একটি একক কার্নেলে একত্রিত করে।

সমস্ত ফিউশন পাস শুধুমাত্র ফিউশন পাইপলাইনেই যোগ করা উচিত, আগে বা পরে নয়। এর মানে হলো, প্রি-অপ্টিমাইজ করা HLO মডিউলে ফিউশন নির্দেশাবলী থাকা উচিত নয়। যদি পাইপলাইনের শুরুতে ফিউশন তৈরি হয়, তবে এটি অপ্টিমাইজেশন পাসগুলোর জন্য একটি বাধা হয়ে দাঁড়ায়। আর যদি ফিউশন দেরিতে তৈরি হয়, তাহলে আমরা উৎপন্ন ফিউশনের জন্য ব্যাকএন্ড নির্বাচন এবং টিউন করার ক্ষমতা হারাই।

কাস্টম কলগুলোর সাথে ফিউশন, অর্থাৎ প্রডিউসার/কনজিউমারের সাথে কাস্টম কলগুলোর প্যাটার্ন মেলানো এবং সেগুলোকে নতুন কাস্টম কলে পুনর্লিখন করা অনুমোদিত নয়। সেক্ষেত্রে, এটিকে একটি যথাযথ ফিউশন পাস দ্বারা প্রতিস্থাপন করা উচিত।

ব্যাকএন্ড এবং অটোটিউনিং

আননেস্টেড অপস, যেমন কাস্টম কল এবং ফিউশনের ব্যাকএন্ডগুলোকে অবশ্যই CodegenBackend ইন্টারফেসটি ইমপ্লিমেন্ট করতে হবে।

সর্বোত্তম ব্যাকএন্ড নির্বাচন সক্ষম করার জন্য এই ইন্টারফেসটি প্রয়োজনীয়, কারণ এটি প্রদত্ত 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 কম্পাইলেশন পাইপলাইনের চূড়ান্ত ফলাফল হলো একটি থাঙ্ক সিকোয়েন্স, যাকে সিরিয়ালাইজ করা যায়।

সমস্ত নতুন থাঙ্ক টাইপ সিরিয়ালাইজেবল হওয়া উচিত, অর্থাৎ GpuCompiler বা CpuCompiler প্রোগ্রামটি কম্পাইল ও সিরিয়ালাইজ করতে সক্ষম হবে, যাতে পরবর্তীতে XLA রানার প্রোগ্রামটি লোড ও এক্সিকিউট করতে পারে। এর মানে হলো, HloInstruction বা কম্পাইলারের অন্য কোনো অংশ কিংবা StreamExecutor দিকে কোনো পয়েন্টার থাকা উচিত নয়।

কোড মান

• কোডিং শৈলী : আমরা গুগলের কোড স্টাইল গাইড অনুসরণ করি। বিশেষত C/C++ এবং Python গাইডগুলো দেখুন। জমা দেওয়া সমস্ত কোড অবশ্যই এই স্টাইল গাইডগুলো কঠোরভাবে মেনে চলতে হবে।

• সংক্ষিপ্ত পরিবর্তন : আমরা গুগলের ইঞ্জিনিয়ারিং অনুশীলন অনুসরণ করি। বিশেষ করে, অনুগ্রহ করে সংক্ষিপ্ত পরিবর্তন লেখার নির্দেশিকাটি অনুসরণ করুন। এটি করলে আপনার কোড পর্যালোচনার যোগ্যতা বৃদ্ধি পাবে এবং পরিবর্তনের অনিচ্ছাকৃত পার্শ্বপ্রতিক্রিয়ার সম্ভাবনা কমে যাবে, যার ফলে আপনার কোড মার্জ হওয়ার গতি অনেক বেড়ে যাবে। এমনকি যদি আপনার একটি বড় পরিবর্তনও থাকে, সেটিকে আরও ছোট ছোট পরিবর্তনে ভাগ করার অনেক কৌশল রয়েছে। যদি আপনার পিআর (PR) খুব বড় হয়ে যায়, তবে এটিকে ছোট ছোট পিআর-এ ভাগ করার জন্য অনুরোধ জানিয়ে একটি স্বয়ংক্রিয় মন্তব্য পাঠানো হবে।

• টেস্ট কভারেজ : সমস্ত পরিবর্তনে যথাযথ ইউনিট টেস্ট অন্তর্ভুক্ত করা উচিত। ইউনিট টেস্টগুলো নির্দিষ্ট হার্ডওয়্যারের (সিপিইউ, জিপিইউ, ইত্যাদি) টাইমিংয়ের উপর নির্ভরশীল হওয়া উচিত নয় এবং সুনির্দিষ্ট ও ফোকাসড টেস্ট করার জন্য এতে মক (mock) ও ফেক (fake)-এর ব্যাপক ব্যবহার করা উচিত। বর্তমানে টেস্ট করা কঠিন এমন বিদ্যমান কোডকে সম্প্রসারণের উদ্দেশ্যে করা পরিবর্তনগুলোতে টেস্টযোগ্যতার যথাযথ উন্নতি করা উচিত।

  সুবিধাগুলো যাতে স্পষ্টভাবে বোঝা যায়, তা নিশ্চিত করার জন্য সমস্ত পরিবর্তনের শিরোনামে উপযুক্ত বেঞ্চমার্ক ফলাফলও অন্তর্ভুক্ত করা উচিত।

• কোডের প্রচলিত রীতি সম্পর্কে সন্দেহ থাকলে, আগে থেকে বিদ্যমান কোড পরীক্ষা করা এবং OpenXLA-তে আগে থেকেই প্রচলিত প্যাটার্নগুলো অনুসরণ করার চেষ্টা করা সর্বদা একটি ভালো উপায়।

পর্যালোচনা প্রক্রিয়া

প্রজেক্ট সদস্যদের জমা দেওয়া লেখা সহ সকল জমা দেওয়া লেখা পর্যালোচনার জন্য প্রয়োজন। এই উদ্দেশ্যে আমরা গিটহাব পুল রিকোয়েস্ট ব্যবহার করি। পুল রিকোয়েস্ট ব্যবহার সম্পর্কে আরও তথ্যের জন্য গিটহাব হেল্প দেখুন।

• পর্যালোচনার পূর্বে কোডকে অবশ্যই উপরে তালিকাভুক্ত সমস্ত মানদণ্ড অনুসরণ করতে হবে। এগুলি ঐচ্ছিক নয় এবং পরিবর্তনগুলির সময়মতো অনুমোদন নিশ্চিত করার জন্য, পর্যালোচনার অনুরোধ করার আগে জমা প্রদানকারীর জন্য এটি নিশ্চিত করা অত্যন্ত গুরুত্বপূর্ণ যে তার কোডটি এই মানদণ্ডগুলি মেনে চলে।

• গিটহাবে সমস্ত পরীক্ষা এবং অতিরিক্ত যাচাই অবশ্যই সফল হতে হবে । যদি আপনি দেখেন যে কোনো পরীক্ষা ত্রুটিপূর্ণ এবং সমস্যাটি আপনার বিল্ড এনভায়রনমেন্ট বা আপনার করা অন্য কোনো পরিবর্তনের সাথে সম্পর্কিত নয়, তাহলে অনুগ্রহ করে রক্ষণাবেক্ষণকারীদের সাথে যোগাযোগ করুন।

• পর্যালোচনা প্রক্রিয়ার সময় কাজের পরিধি বৃদ্ধি (স্কোপ ক্রিপ) পরিহার করুন। এটি প্রস্তাবকারী এবং পর্যালোচনাকারী উভয়েরই দায়িত্ব। যদি কোনো পরিবর্তন খুব বড় হয়ে যেতে শুরু করে, তবে সেটিকে একাধিক পরিবর্তনে বিভক্ত করার কথা বিবেচনা করুন।

• গিটহাবে কোনো পরিবর্তন অনুমোদিত হওয়ার পর কিন্তু মার্জ করার আগে, এটি গুগল এবং অন্যান্য হার্ডওয়্যার বিক্রেতাদের নিজস্ব কোড ব্যবহার করে অভ্যন্তরীণ পরীক্ষার মধ্য দিয়ে যাবে। অভ্যন্তরীণ পরীক্ষায় যদি এমন কোনো ব্যর্থতা দেখা দেয় যা আমাদের পাবলিক CI ধরতে পারে না, তাহলে এটি পর্যালোচনা প্রক্রিয়ায় অতিরিক্ত ধাপ যোগ করতে পারে। আপনার পরিবর্তন পর্যালোচনাকারী গুগল কর্মী যেকোনো অভ্যন্তরীণ পরীক্ষার ব্যর্থতার কথা জানাবেন এবং কী সংশোধন করতে হবে তা বর্ণনা করবেন। অভ্যন্তরীণ পরীক্ষাগুলোর সার্বিক অবস্থা গিটহাবের চেক তালিকায় দেখা যাবে।

  • import/copybara — অভ্যন্তরীণ পর্যালোচনা সিস্টেমে পরিবর্তন আমদানি করা হয়েছে : আপনার PR গুগলের অভ্যন্তরীণ সিস্টেমে আমদানি করা হয়েছে এবং যাচাইকরণ চলছে।
  • import/copybara — পরিবর্তনটি স্থানান্তর করার সময় একটি ত্রুটি ঘটেছে : আপনার পিআর (PR) গুগলের অভ্যন্তরীণ সিস্টেমে ইম্পোর্ট করা যায়নি। এমনটা খুব কমই ঘটে। আপনি এই অবস্থাটি দেখলে অনুগ্রহ করে আপনার রিভিউয়ারকে জানান।
  • feedback/copybara — ক্রিয়েট টাইম সহ রানগুলোর জন্য গুগলের অভ্যন্তরীণ যাচাই পাস করেছে... : সমস্ত অভ্যন্তরীণ যাচাই পাস করেছে। আপনার পিআরটি শীঘ্রই মার্জ করা হবে।
  • feedback/copybara — নির্দিষ্ট ক্রিয়েট টাইমের রানগুলোর জন্য গুগলের অভ্যন্তরীণ যাচাই ব্যর্থ হয়েছে ... : কিছু অভ্যন্তরীণ যাচাই ব্যর্থ হয়েছে। গুগলের একজন ইঞ্জিনিয়ার শীঘ্রই আরও বিস্তারিত তথ্যসহ একটি মন্তব্য পোস্ট করবেন। যদি আপনি একদিনের মধ্যে এই ব্যর্থতাগুলো সম্পর্কে কোনো তথ্য না পান, তবে অনুগ্রহ করে আপনার রিভিউয়ারকে জানান।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী (FAQ)

এই অবকাঠামোগত পরিবর্তনটি আমার পিআর-এর সাথে সম্পর্কিত নয়। আমি এটা কেন করব?

XLA টিমের কোনো ডেডিকেটেড ইনফ্রাস্ট্রাকচার টিম নেই, তাই হেল্পার লাইব্রেরি তৈরি করা এবং টেকনিক্যাল ডেট এড়ানোর দায়িত্ব আমাদের সকলের। আমরা এটিকে XLA-তে পরিবর্তন আনার একটি নিয়মিত অংশ হিসেবে বিবেচনা করি এবং সকলের অংশগ্রহণ প্রত্যাশিত। আমরা সাধারণত কোড লেখার সময় প্রয়োজন অনুযায়ী ইনফ্রাস্ট্রাকচার তৈরি করে থাকি।

XLA পর্যালোচকরা আপনার লেখা একটি PR-এর সাথে আপনাকে কিছু পরিকাঠামো তৈরি করতে (অথবা PR-টিতে একটি বড় পরিবর্তন আনতে) বলতে পারেন। এই অনুরোধটি আপনার করা পরিবর্তনের সাথে অপ্রয়োজনীয় বা সম্পর্কহীন বলে মনে হতে পারে। এর কারণ সম্ভবত এই যে, আপনার কতটা পরিকাঠামো তৈরি করতে হবে সে সম্পর্কে আপনার প্রত্যাশা এবং আপনার পর্যালোচকের প্রত্যাশার মধ্যে একটি অমিল রয়েছে।

প্রত্যাশার অমিল থাকাটা স্বাভাবিক! কোনো প্রকল্পে নতুন হলে এমনটা হওয়াই স্বাভাবিক (এমনকি আমাদের মতো অভিজ্ঞদের ক্ষেত্রেও মাঝে মাঝে এমনটা ঘটে)। অতীতে আপনি যে প্রকল্পগুলোতে কাজ করেছেন, সেগুলোর প্রত্যাশা ভিন্ন হওয়ার সম্ভাবনাই বেশি। সেটাও স্বাভাবিক এবং প্রত্যাশিত! এর মানে এই নয় যে এই প্রকল্পগুলোর কোনোটির কর্মপন্থা ভুল; এগুলো কেবল ভিন্ন। এই প্রকল্পে আমাদের প্রত্যাশা কী, তা জানার একটি সুযোগ হিসেবে আমরা আপনাকে অন্যান্য সমস্ত পর্যালোচনার মন্তব্যের পাশাপাশি অবকাঠামোগত অনুরোধগুলোকেও গ্রহণ করার জন্য আমন্ত্রণ জানাচ্ছি।

আমি কি ভবিষ্যতের কোনো জনসংযোগ প্রতিবেদনে আপনার মন্তব্যটির উত্তর দিতে পারি?

পিআর-এ (PR) ইনফ্রাস্ট্রাকচার রিকোয়েস্ট (বা অন্যান্য বড় রিকোয়েস্ট) সংক্রান্ত একটি সাধারণ প্রশ্ন হলো, পরিবর্তনটি কি মূল পিআর-এই করতে হবে, নাকি এটি ভবিষ্যতের কোনো পিআর-এ ফলো-আপ হিসেবে করা যেতে পারে।

সাধারণত, XLA পিআর লেখকদের ফলো-আপ পিআর-এর মাধ্যমে পর্যালোচনার মন্তব্যের সমাধান করার অনুমতি দেয় না। যখন কোনো পর্যালোচক মনে করেন যে একটি নির্দিষ্ট পিআর-এ কোনো কিছুর সমাধান করা প্রয়োজন, তখন আমরা সাধারণত লেখকদের কাছে আশা করি যে তাঁরা সেই পিআর-এই তার সমাধান করবেন, এমনকি যদি অনুরোধ করা পরিবর্তনটি বড় ধরনেরও হয়। এই নিয়মটি বাহ্যিকভাবে এবং গুগলের অভ্যন্তরেও প্রযোজ্য।

XLA যে এই পন্থা অবলম্বন করে, তার কয়েকটি কারণ রয়েছে।

• বিশ্বাস: পর্যালোচকের বিশ্বাস অর্জন করা একটি অত্যন্ত গুরুত্বপূর্ণ বিষয়। একটি ওপেন-সোর্স প্রকল্পে, অবদানকারীরা নিজেদের ইচ্ছামতো যোগ দিতে বা অদৃশ্য হয়ে যেতে পারেন। আমরা একটি পিআর (PR) অনুমোদন করার পর, প্রতিশ্রুত ফলো-আপগুলো আসলেই সম্পন্ন হচ্ছে কিনা, তা নিশ্চিত করার কোনো উপায় পর্যালোচকদের থাকে না।

• অন্যান্য ডেভেলপারদের উপর প্রভাব: আপনি যদি XLA-এর কোনো নির্দিষ্ট অংশ সম্পর্কিত একটি PR পাঠিয়ে থাকেন, তাহলে খুব সম্ভবত অন্যরাও সেই একই অংশটি দেখছেন। আমরা যদি আপনার PR-এ থাকা টেকনিক্যাল ডেট গ্রহণ করি, তাহলে ফলো-আপ জমা না দেওয়া পর্যন্ত যারা এই ফাইলটি দেখছেন, তারা সবাই এই ডেটের দ্বারা প্রভাবিত হবেন।

• পর্যালোচকদের কাজের চাপ: কোনো পরিবর্তনকে পরবর্তী পর্যালোচনার জন্য স্থগিত করলে তা আমাদের ইতিমধ্যেই অতিরিক্ত কাজের চাপে থাকা পর্যালোচকদের উপর একাধিক বোঝা চাপিয়ে দেয়। পরবর্তী পর্যালোচনার জন্য অপেক্ষা করার সময় পর্যালোচকরা সম্ভবত ভুলে যাবেন যে প্রথম পিআরটি কী বিষয়ে ছিল, যা পরবর্তী পর্যালোচনাকে আরও কঠিন করে তুলবে। এছাড়াও, পর্যালোচকদের প্রত্যাশিত পরবর্তী পর্যালোচনাগুলোর উপর নজর রাখতে হবে এবং সেগুলো যেন বাস্তবে সম্পন্ন হয় তা নিশ্চিত করতে হবে। যদি পরিবর্তনটি এমনভাবে করা যায় যা মূল পিআর থেকে সম্পূর্ণ আলাদা, যাতে অন্য কোনো পর্যালোচক এটি পর্যালোচনা করতে পারেন, তাহলে কাজের চাপ ততটা সমস্যা হবে না। আমাদের অভিজ্ঞতায়, এমনটা খুব কমই ঘটে।