OpenAI

2 நவம்பர், 2026

என்ஜினியரிங்

OpenAI-இல் Git விரிவாக்கம்

Git சூழலமைப்பில் முதலீடு செய்தபடியே, ஏஜென்ட்டுகளின் பணியளவுக்கு ஏற்ற மூலநிரல் கட்டுப்பாட்டை உருவாக்குதல்.

எழுதியவர்கள்: தொழில்நுட்பக் குழு உறுப்பினர்கள் ஆரன் ஃப்ரீல், டெய்லர் ப்ளாவ், டெட் நைமன்

ஏற்றுகிறது…

கடந்த ஆண்டில், எங்கள் ஒற்றை ரிபாசிட்டரியின் அளவும் அதன் மீதான தேவைகளும் வியக்கத்தக்க வேகத்தில் அதிகரித்துள்ளன. Codex சாத்தியமாக்கும் ஒரேநேரப் பணிகளின் அளவுக்கு ஈடுகொடுக்க, எங்கள் மூலநிரல் கட்டுப்பாட்டு அமைப்பைப் புதுப்பிக்க வேண்டும் என்பது தெளிவானது.

பொறியியல் பணிகளை இடைநிறுத்தாமலும், எங்கள் குழு Git பயன்படுத்தும் முறையை மாற்றாமலும், Git ரிபாசிட்டரிகளுக்கான புதிய பின்தளமான Pando-வை உருவாக்கினோம். இப்போது OpenAI-இன் ஒற்றை ரிபாசிட்டரியில் நடைபெறும் அனைத்து உருவாக்கப் பணிகளையும் Pando இயக்குகிறது. இரு உயரிய இலக்குகளுக்காக Pando வடிவமைக்கப்பட்டது. முதலாவது, பல கிளைகளுக்கு ஒரே நேரத்தில் அனுப்புவதற்கேற்ற, கூடுதல் சேவையகங்கள் மூலம் விரிவாக்கக்கூடிய எழுதுதல். இரண்டாவது, வாசிப்பு த்ரூபுட்டை அதிகபட்சமாக்குவது. இதனால் கிளையன்ட்டுகள் தங்களுக்குக் கிடைக்கும் வலை அலைவரிசை முழுவதையும் பயன்படுத்தும் வேகத்தில் தரவைப் பதிவிறக்க முடியும்.

Git நெறிமுறையுடனும் கிளையன்ட்டுடனும் இணக்கத்தைத் தக்கவைத்தே இந்த இலக்குகளை எட்டினோம். இதனால் எங்கள் பொறியாளர்களும் ஏஜென்ட்டுகளும் தற்போதைய பணிப்பாய்வுகளில் Pando-வைத் தடையின்றி ஏற்க முடிந்தது. நேரடிப் பயன்பாட்டில், அனுப்புதலின் இடைநிலைத் தாமதத்தை ஏறக்குறைய ஐந்தில் ஒரு பங்காக Pando குறைத்தது. இப்போது அது நாளொன்றுக்கு ஏறக்குறைய ஒரு பெட்டாபைட் Git தரவை வழங்குகிறது.

புதிய மூலநிரல் கட்டுப்பாட்டு அமைப்பை உருவாக்கியதற்கான காரணங்களையும், Git இணக்கத்தைத் தக்கவைக்க முடிவுசெய்ததன் காரணத்தையும் இங்கே விளக்குகிறோம். Git விரிவாக்கத்திற்கான வழக்கமான அணுகுமுறைகளுடன் எங்கள் அமைப்பை ஒப்பிட்டு, OpenAI-இன் விரிவாக்கத் தேவைகளை நிறைவேற்ற Pando ஏன் தனித்துவமாகத் தகுதிபெற்றுள்ளது என்பதை விவரிக்கிறோம். அடுத்த கட்டங்களையும், ஏஜென்ட் அளவிலான பணிகளை ஆதரிக்க Git-க்குத் தொடர்ந்து பங்களிக்கும் விதத்தையும் விவாதிக்கிறோம்.

புதிய மூலநிரல் கட்டுப்பாட்டு அமைப்பு ஏன் தேவைப்பட்டது

OpenAI-இல் உருவாக்கப் பணிகளின் அளவையும் வேகத்தையும் Codex மாற்றியுள்ளது. பொறியாளர்கள் மிக அதிகமான பணிகளை ஒரே நேரத்தில் செய்ய இது உதவுகிறது. இதனால் அதிகக் கிளைகள், அனுப்புதல்கள், இணைப்புகள் மட்டுமன்றி, உருவாக்கச் சூழல்கள், ஆராய்ச்சிப் பணிகள், தொடர்ச்சியான ஒருங்கிணைப்பு ஆகியவற்றிலிருந்து அதிகப் பெறுதல்களும் நகலாக்கங்களும் நிகழ்கின்றன.

இந்தத் தேவைகள் ஒன்றோடொன்று சேர்ந்து பெருகுகின்றன. இப்போது ஒரு பொறியாளரிடம் ஒரே நேரத்தில் பல மாற்றங்கள் தொடர்ச்சியான ஒருங்கிணைப்புக்குத் தயாராக உள்ளன. ஒவ்வொரு அனுப்புதலும் பல பணிகளை ஒரே மாற்றப்பதிவைப் பெறச் செய்யலாம்.

கடந்த ஆண்டின் இறுதியிலிருந்து, எங்கள் ஒற்றை ரிபாசிட்டரியை ஆதரிக்கும் அமைப்புகள் தேவைகளுக்கு ஈடுகொடுக்கத் திணறின. மெதுவான பெறுதல்கள், அனுப்புதல்கள், தோல்வியடைந்த இணைப்புகளைச் சந்தித்தோம். சில நேரங்களில் நம்பகத்தன்மை 90%-க்கும் கீழே சரிந்தது. Git-இன் வரம்பை எட்டிவிட்டோமா, அல்லது எங்கள் ஒற்றை ரிபாசிட்டரியை வழங்கிய முறையின் வரம்பையா? இயக்கமுறைமைக் கருவிற்கான திருத்தங்களை மின்னஞ்சல் வழியாகப் பரிமாறிய சமூகத்திலிருந்து Git உருவானது. இருபது ஆண்டுகளுக்கும் மேலாக, மென்பொருள் உருவாக்கும் முறை மாறியபோதெல்லாம் உருவாக்குநர்கள் தங்கள் கருவிகளை Git-க்கு ஏற்ப மாற்றியுள்ளனர். எங்கள் ஒற்றை ரிபாசிட்டரியில் சிக்கல்கள் தோன்றியபோது, அந்தப் பணியை அடித்தளமாகக் கொண்டு தொடர்ந்து உருவாக்குவது எங்களுக்கு முக்கியமாக இருந்தது.

பழக்கமான பணிப்பாய்வைத் தக்கவைத்தபடியே பின்தளத்தை மறுகட்டமைக்க வழி கண்டோம். வெவ்வேறு கிளைகளுக்கான அனுப்புதல்களை இணையாகக் கையாளவும், ஒரே வரலாற்றைப் பல வாசிப்பவர்களுக்கு ஒரே நேரத்தில் வழங்கவும் முடியும். எங்கள் மூலநிரல் கட்டுப்பாட்டுப் பணிப்பாய்வுக்கு Git-ஐ அடித்தளமாக வைத்ததால், கிளையன்ட் மேம்பாடுகள் OpenAI-க்கு வெளியேயும் பயன்படும். எங்கள் Git நகலிலுள்ள⁠(புதிய சாளரத்தில் திறக்கும்) மேம்பாடுகளை மூலத் திட்டத்திற்குப் பங்களித்து, விரிவான சமூகத்துடன் பகிர விரும்பினோம்.

பெருமளவிலான Git பயன்பாட்டிற்கான பொறியியல்

மூலநிரல் கட்டுப்பாட்டு விரிவாக்கத்தில் இரு முக்கியப் பரிமாணங்கள் உள்ளன: பலர் வெவ்வேறு கிளைகளுக்கு எழுதுவது, பலர் ஒரே வரலாற்றைப் பெறுவது. இரண்டிற்கும் ஏற்ப Pando மேம்படுத்தப்பட்டுள்ளது.

முதலில், ஒவ்வொரு கிளையின் புதுப்பிப்புகளையும் Pando தனித்தனியாக ஒருங்கிணைக்கிறது. தொடர்பற்ற கிளைகளின் புதுப்பிப்புகள் இணையாக நடைபெறலாம். ஒரு கிளையைப் பெறுபவருக்கு அந்தத் திருத்தத்திற்குத் தேவையான வரலாறு கிடைக்கும். இதற்கான சமரசம்: பல கிளைகளைப் பார்ப்பவருக்கு அவை வெவ்வேறு நேர நிலைகளில் தெரியலாம்.

இரண்டாவதாக, ஒவ்வொரு கிளையன்ட்டுக்கும் தனிப் பொதிக்கோப்பை உருவாக்காமல், பெறுதல்களில் பொதிக்கோப்புகளை Pando மீண்டும் பயன்படுத்துகிறது. பொதிக்கோப்பு என்பது பல பொருட்களை ஒன்றாகச் சுருக்கும் Git வடிவம். கிளையன்ட் தன்னிடம் ஏற்கெனவே உள்ள சில பொருட்களைப் பதிவிறக்க நேரலாம். ஆனால் குறைந்த கணக்கீட்டுடன் அதே பைட்டுகளைப் பல கிளையன்ட்டுகளுக்குச் சேவையகம் வழங்க முடியும்.

இந்தத் தேர்வுகள், கிளைகள் முழுவதும் எழுதுதலை விரிவாக்கவும் தற்காலிகச் சேமிப்புகளிலிருந்து வாசிப்பை வழங்கவும் உதவுகின்றன. இவை எவ்வாறு இணைந்து செயல்படுகின்றன என்பதைப் புரிந்துகொள்ள, Git வரலாற்றைச் சேமித்துப் பரிமாறும் முறையிலிருந்து தொடங்குவோம்.

Git பொருள் சேமிப்பின் அடிப்படைகள்

ஒரு ரிபாசிட்டரியின் இரு பகுதிகளை Git ஒத்திசைவில் வைத்திருக்க வேண்டும்: பொருட்கள், சுட்டுகள்.

Git ரிபாசிட்டரி, கோப்புகளின் நிலைப் பிரதிகளையும் அவற்றை இணைக்கும் வரலாற்றையும் பொருட்களின் வரைபடமாகப் பதிவுசெய்கிறது. ஒரு பொருள் தரவுத்தொகுதி, மரம், மாற்றப்பதிவு அல்லது குறிச்சொல்லாக இருக்கலாம். தரவுத்தொகுதிகள் தனிக் கோப்பின் உள்ளடக்கத்தைக் கொண்டுள்ளன. மரங்கள், பெயர்களைத் தரவுத்தொகுதிகள் அல்லது பிற மரங்களுடன் இணைத்து அடைவுக் கட்டமைப்பை உருவாக்குகின்றன. மாற்றப்பதிவுகள் ஒரு வேர் மரத்தையும், பூஜ்ஜியம் அல்லது அதற்கு மேற்பட்ட பெற்றோர் மாற்றப்பதிவுகளையும் சுட்டி, உங்கள் ரிபாசிட்டரியின் வரலாற்றை உருவாக்குகின்றன.

பொருட்கள் அவற்றின் வகை மற்றும் உள்ளடக்கத்தின் ஹாஷ் மதிப்பால் அடையாளப்படுத்தப்படுகின்றன. பொருட்களை மாற்ற முடியாது. மாறிய கோப்பைப் பதிவுசெய்யும்போது புதிய தரவுத்தொகுதி உருவாகும்; மாறாத கோப்புகளும் அடைவுகளும் ஏற்கெனவே உள்ள பொருட்களைப் பயன்படுத்தலாம்.

கிளைகளும் குறிச்சொற்களும் மாற்றப்பதிவுகளைச் சுட்டும் குறிப்புகள் அல்லது “சுட்டுகள்” ஆகும். ஒரு கிளையில் மாற்றத்தைப் பதிவுசெய்யும்போது புதிய மாற்றப்பதிவு உருவாகிறது; அதைச் சுட்டும்படி கிளையின் சுட்டு புதுப்பிக்கப்படுகிறது.

refs/heads/main கிளை C2 மாற்றப்பதிவைச் சுட்டுகிறது; அதன் பெற்றோர் C1. C1, வேர் மரம் T1-ஐச் சுட்டுகிறது. அதில் parser.py, தரவுத்தொகுதி B1-ஐக் குறிக்கிறது. C2, வேர் மரம் T2-ஐச் சுட்டுகிறது. அதில் parser.py, தரவுத்தொகுதி B2-ஐக் குறிக்கிறது. இரு வேர் மரங்களிலும் docs/, ஒரே மரமான T3-ஐக் குறிக்கிறது. அதன் README.md பதிவு தரவுத்தொகுதி B3-ஐயும், usage.md தரவுத்தொகுதி B4-ஐயும் சுட்டுகின்றன.

Git பொருட்கள் அவற்றின் அடையாளங்களால் ஒன்றையொன்று சுட்டுகின்றன: மாற்றப்பதிவுகள் மரங்களையும், மரங்கள் பிற மரங்களையும் தரவுத்தொகுதிகளையும் சுட்டுகின்றன. refs/heads/main கிளை C2 மாற்றப்பதிவைச் சுட்டுகிறது; அதன் பெற்றோர் C1. C1, வேர் மரம் T1-ஐச் சுட்டுகிறது. அதில் parser.py, தரவுத்தொகுதி B1-ஐக் குறிக்கிறது. C2, வேர் மரம் T2-ஐச் சுட்டுகிறது. அதில் parser.py, தரவுத்தொகுதி B2-ஐக் குறிக்கிறது. இரு வேர் மரங்களிலும் docs/, ஒரே மரமான T3-ஐக் குறிக்கிறது. அதன் README.md பதிவு தரவுத்தொகுதி B3-ஐயும், usage.md தரவுத்தொகுதி B4-ஐயும் சுட்டுகின்றன.

Git பொருட்களை “தனித்தனி” அல்லது “பொதியாக்கப்பட்ட” நிலையில் சேமிக்கிறது. தனித்தனிப் பொருட்கள் அவற்றின் பொருள் அடையாளத்தால் குறிக்கப்படும் தனிக் கோப்புகளில் சேமிக்கப்படுகின்றன. பொதியாக்கப்பட்ட பொருட்கள் ஒரே பொதிக்கோப்பில் சேர்த்துச் சேமிக்கப்படுகின்றன. இதனால் ஒத்த பொருட்களை ஒன்றுக்கொன்றான வேறுபாடுகளாகச் சேமிக்க முடிகிறது.

$GIT_DIR/objects கீழ் parser.py-இன் இரு பதிப்புகள் தோன்றுகின்றன. தனித்தனிப் பொருட்களாக, தரவுத்தொகுதி A-இல் parse() உள்ளது; தரவுத்தொகுதி B-இல் parse(), parse_file() இரண்டும் உள்ளன. A-ஐ முழுமையாகப் பொதிக்கோப்பு சேமிக்கிறது. A முழுவதையும் நகலெடுத்து parse_file()-ஐச் சேர்க்கும் அறிவுறுத்தல்களாக B-ஐக் குறிக்கிறது. உடனுள்ள *.idx கோப்பு, பொருள் அடையாளத்தின் மூலம் பொதிக்கோப்பில் இரு தரவுத்தொகுதிகளின் இருப்பிடங்களையும் கண்டறிகிறது.

தரவுத்தொகுதிகளைத் தனிக் கோப்புகளாக Git சேமிக்கலாம் அல்லது ஒரு தரவுத்தொகுதியை மற்றொன்றிலிருந்து வேறுபாடாகக் குறியாக்கி, அவற்றை ஒன்றாகப் பொதியாக்கலாம்.

Git-இல், ஒரு மாற்றப்பதிவிலிருந்து அதன் பெற்றோர்கள், மரங்கள், தரவுத்தொகுதிகள் வழியாக இணைப்புகளைப் பின்தொடர்ந்து ஒரு பொருளைக் கண்டறிய முடிந்தால், அது அந்த மாற்றப்பதிவிலிருந்து அடையக்கூடியது. பெறுதலின்போது, தனக்குத் தேவையான மாற்றப்பதிவுகளையும் ஏற்கெனவே உள்ளவற்றையும் சேவையகத்துக்குக் கிளையன்ட் தெரிவிக்கிறது. தேவையான மாற்றப்பதிவுகளிலிருந்து அடையக்கூடிய பொருட்களைச் சேவையகம் கண்டறிந்து, கிளையன்ட்டிடம் ஏற்கெனவே இருப்பதாகத் தெரிந்தவற்றை விலக்குகிறது. மீதியை வட்டில் Git பயன்படுத்தும் அதே வடிவத்தில் பொதிக்கோப்பாக அனுப்புகிறது. முழு நகலாக்கம் எந்தப் பொருளும் இல்லாமல் தொடங்குவதால், நகலாக்கப்படும் வரலாற்றிலிருந்து அடையக்கூடிய அனைத்துப் பொருட்களும் தேவை.

ஒன்று அல்லது அதற்கு மேற்பட்ட சுட்டுகளைப் புதுப்பிக்கச் சேவையகத்தைக் கோருவதன் மூலம், அனுப்புதல் எதிர்த்திசையில் பொருட்களைப் பரிமாறுகிறது. சேவையகத்திடம் ஏற்கெனவே உள்ள பொருட்களை அனுப்பாமல் இருக்க, அது அறிவித்த சுட்டுகளின் தொகுப்பைக் கிளையன்ட் பயன்படுத்துகிறது. எனவே அனுப்பப்படும் பொதி ஏற்கெனவே உள்ள பொருட்களைச் சார்ந்திருக்கலாம். பொதியை மட்டும் பெறுவது புதிய வரலாற்றை மீட்டமைக்கப் போதாது.

Git ரிபாசிட்டரியைப் பிரதியெடுப்பது என்பது, பல சேவையகங்களில் பொருட்களையும் சுட்டுகளையும் கிடைக்கச் செய்வதாகும். சுட்டின் புதிய மதிப்பை ஒரு பிரதி வழங்குவதற்கு முன், அந்த மதிப்பிலிருந்து அடையக்கூடிய பொருட்களை வழங்கக்கூடியதாக இருக்க வேண்டும். போட்டியிடும் சுட்டுப் புதுப்பிப்புகளையும் சேவை ஒருங்கிணைக்க வேண்டும். அதாவது, ஒரே கிளையை ஒரே பழைய முனையிலிருந்து வெவ்வேறு புதிய மாற்றப்பதிவுகளுக்கு நகர்த்த முயலும் அனுப்புதல்கள். ரிபாசிட்டரியின் அனைத்து எழுதுதல்களுக்கும் ஒரே வரிசையை விதிக்கும் முறைமைகள், தொடர்பற்ற கிளைகளுக்கான அனுப்புதல்களைக்கூட ஒன்றுக்கொன்று காத்திருக்கச் செய்யலாம்.

தற்போதைய பகிர்ந்தமைந்த Git சேவை முறைகள்

Pando-ஐ வடிவமைக்கும்போது, Git மூலநிரல் கட்டுப்பாட்டை விரிவாக்கும் வழக்கமான அணுகுமுறைகளை மதிப்பிட்டோம். ஒன்று, மூன்றுகட்ட உறுதிப்படுத்தல் மூலம் ரிபாசிட்டரிப் பிரதிகளின் சுட்டுப் புதுப்பிப்புகளை ஒருங்கிணைப்பது (3PC: பல முனைகளில் உறுதிப்படுத்தலை ஒருங்கிணைக்கும் நெறிமுறை). மற்றொன்று, தரவுத்தொகுதிச் சேமிப்பகத்தில் பகிரப்பட்ட முன்கூட்டியே எழுதும் பதிவேட்டால் புதுப்பிப்புகளை வரிசைப்படுத்துவது (WAL: மாற்றங்களைப் பயன்படுத்துவதற்கு முன் எழுதப்படும் பதிவு).

மூன்றுகட்ட உறுதிப்படுத்தல் (3PC)

நாங்கள் மாடலாக்கிய மூன்றுகட்ட உறுதிப்படுத்தல் வடிவமைப்பில், ரிபாசிட்டரியின் முழு நகலைப் பல பிரதிகளில் Git சேவை வைத்திருக்கிறது. எந்தச் சேவையகம் அனுப்புதலைப் பெற்றாலும், வரும் பொதிக்கோப்பு நகலெடுக்கப்பட்டு அனைத்துப் பிரதிகளுக்கும் இணையாக அனுப்பப்படுகிறது. அனுப்புதலை வெளியிட, பெரும்பான்மையான பிரதிகள் சுட்டுப் புதுப்பிப்பை ஏற்க வேண்டும். இதை நிர்வகிக்கும் சேவையகமே ஒருங்கிணைப்பாளர். அதற்கும் மற்ற ஒவ்வொரு பிரதிக்கும் இடையே பல சுற்றுத் தொடர்புகள் தேவை.

சுட்டுப் புதுப்பிப்பை ஏற்க, ஒவ்வொரு பிரதியும் தன்னிடமுள்ள சுட்டைப் பூட்டி, கிளையன்ட் எதிர்பார்க்கும் மாற்றப்பதிவைத்தான் அது இன்னும் சுட்டுகிறதா எனச் சரிபார்க்கிறது. பின்னர் ஏற்றுக்கொண்ட பிரதிகளுக்கு முன்-உறுதிப்படுத்தல் செய்தியை ஒருங்கிணைப்பாளர் அனுப்புகிறார். பெரும்பான்மையான பிரதிகள் அந்தச் செய்தியை ஏற்றுக்கொண்டதும், புதுப்பிப்பைச் செயல்படுத்துமாறு ஒருங்கிணைப்பாளர் கூறுகிறார். பின்னர் புதுப்பித்த நிலையிலுள்ள எந்தப் பிரதியும் தனது உள்ளக ரிபாசிட்டரி நகலிலிருந்து புதிய கிளை முனையை அறிவிக்கலாம்.

முழுப் பிரதிகளை வைத்திருப்பதால் வாசிப்புகளை உள்ளகத்திலேயே வழங்கலாம். எந்தப் பிரதியைத் தேர்ந்தெடுத்தாலும் கிளையன்ட்டுகளுக்கு அனைத்துச் சுட்டுகளின் ஒத்திசைவான நிலை கிடைக்கும். இதனால் சுட்டுகள் ஒவ்வொன்றாகப் புதுப்பிக்கப்படுகின்றன. ஒவ்வொரு அனுப்புதலுக்கும், பிரதிகளிடையே சுட்டுப் புதுப்பிப்பை ஒருங்கிணைக்கப் பல சுற்றுப் பரிமாற்றங்கள் தேவை.

தேவையான பெரும்பான்மைக்காகக் காத்திருப்பதால், பிரதிகளின் வட்டுச் செயல்திறனும் தொடர்புத் தாமதமும் அனுப்புதலின் வேகத்தைப் பாதிக்கின்றன. எழுதுதலின் அளவு அதிகரிக்கும்போது, வரும் பொதிகளுக்கும் வாசிப்புக் கோரிக்கைகளுக்கும் பிரதிகள் ஈடுகொடுக்க வேண்டும்.

முன்கூட்டியே எழுதும் பதிவேடு (WAL)

நாங்கள் மாடலாக்கிய WAL வடிவமைப்பில், ரிபாசிட்டரி முழுவதும் புதுப்பிப்புகளை வரிசைப்படுத்த, தரவுத்தொகுதிச் சேமிப்பகத்திலுள்ள பகிரப்பட்ட மானிஃபெஸ்ட்டை Git சேவை பயன்படுத்துகிறது. அனுப்புதலைச் சேவையகம் பெறும்போது, வரும் பொதிக்கோப்பைத் தரவுத்தொகுதிச் சேமிப்பகத்தில் பதிவேற்றி, தனது உள்ளக ரிபாசிட்டரி நகலில் சுட்டுப் புதுப்பிப்பைத் தயார்செய்கிறது. அனுப்புதலை வெளியிட, தரவுத்தொகுதிச் சேமிப்பகத்திலுள்ள பகிரப்பட்ட மானிஃபெஸ்ட்டில் ஒரு பதிவைச் சேர்க்கிறது. அப்பதிவு சுட்டுப் புதுப்பிப்பைப் பதிவுசெய்து பொதிக்கோப்பைச் சுட்டுகிறது. பின்னர் ஒப்பிட்டு மாற்றும் செயல்பாட்டின் மூலம் மானிஃபெஸ்ட்டை Git சேவையகம் புதுப்பிக்கிறது. இது மானிஃபெஸ்ட்டைப் பிரிக்க முடியாத ஒரே செயலாக மாற்றுகிறது; இல்லையெனில் மாற்றத்தை நிராகரிக்கிறது. இடையில் வேறொருவர் அதைப் புதுப்பித்திருந்தால், இடைப்பட்ட பதிவுகளைச் சேவையகம் வாசித்து, தனது சுட்டுப் புதுப்பிப்பு இன்னும் செல்லுபடியாகிறதா எனச் சரிபார்க்கிறது. பின்னர் ஏற்கெனவே பதிவேற்றிய பொதிக்கோப்புடன் மீண்டும் முயல்கிறது.

எழுதுபவர்கள் தங்கள் பொதிக்கோப்புகளை இணையாகப் பதிவேற்றலாம். ஆனால் தொடர்பற்ற கிளைகளுக்கான அனுப்புதல்களும் ஒரே மானிஃபெஸ்ட்டைப் புதுப்பிக்க வேண்டும். வெற்றிகரமான ஒப்பிட்டு மாற்றுதலின் சுற்றுப்பயண நேரம், ரிபாசிட்டரி புதிய மானிஃபெஸ்ட்டை வெளியிடக்கூடிய அடிக்கடியைக் கட்டுப்படுத்துகிறது. குறைந்த தாமதமுள்ள தரவுத்தொகுதிச் சேமிப்பகம் இந்தப் படியை விரைவாக்குகிறது. தொகுதியாக்குவதால், ஒரே மானிஃபெஸ்ட் பல சுட்டுகளை ஒரே நேரத்தில் புதுப்பிக்கலாம். ஆனால் புதுப்பிப்புகள் வரிசையில் காத்திருப்பதால் தாமதம் அதிகரிக்கிறது.

தரவுத்தொகுதிச் சேமிப்பகம், பொதிக்கோப்புகளை இணையாகப் பெறலாம். ஆனால் பகிரப்பட்ட மானிஃபெஸ்ட்டின் புதுப்பிப்புகள் இன்னும் ஒன்றுக்கொன்று போட்டியிடுகின்றன. தரவுத்தொகுதிச் சேமிப்பகத்தின் திறனை மட்டும் அதிகரிப்பதால் அந்தத் தடையைத் தீர்க்க முடியாது. ஒவ்வொரு பிரதியும் பொதிகளை உள்ளகத்தில் வழங்குவதற்கு முன், தரவுத்தொகுதிச் சேமிப்பகத்திலிருந்து அவற்றை வாசித்துக் குறியீடாக்க வேண்டும். வரும் எழுதுதல்கள் அந்தப் பணியைவிட வேகமாக இருந்தால், பிரதிகள் பின்தங்கும். புதிதாக அனுப்பப்பட்ட மாற்றப்பதிவுகளைப் பெறக் கிளையன்ட்டுகள் அதிக நேரம் காத்திருக்கும்.

Pando கட்டமைப்பு

இங்குதான் Pando வருகிறது. பல கிளையன்ட்டுகள் ஒரே நேரத்தில் அனுப்புவதை ஆதரிக்கும் அளவுக்கு விரிவடையும் நோக்குடன், Git ரிபாசிட்டரிகளை வழங்குவதற்கான புதிய கட்டமைப்பாக Pando உருவாக்கப்பட்டது. அது செயல்படும் விதம்:

கட்டுப்பாடுகளை மறுபரிசீலித்தல்

Pando-ஐ உருவாக்குவதற்கு முன்பே, Git-இல் சமரசம் செய்யாமல் எங்கள் தேவைகளை நிறைவேற்ற முடியும் என நம்பினோம். ஆனால் பெரும்பாலான Git முறைமைகள் அவசியமானவை எனக் கருதும் சில அம்சங்களில் சமரசம் தேவைப்பட்டது:

  • ரிபாசிட்டரி முழுவதுமான ஒத்திசைவு: அனைத்துச் சுட்டுகளின் ஒரே நேர நிலையை ஒத்திசைவுடன் வழங்க, ரிபாசிட்டரி முழுவதும் ஒருங்கிணைப்பு தேவை. அனைத்துச் சுட்டுப் புதுப்பிப்புகளையும் ஒரே வரிசையில் வைக்கும் முறைமையில், தொடர்பற்ற கிளைகளுக்கான அனுப்புதல்களும் ஒரே ஒருங்கிணைப்பு மையத்தில் போட்டியிடுகின்றன.

  • ஒவ்வொரு கிளையன்ட்டுக்கும் தனிப் பொதிக்கோப்புகள்: வெவ்வேறு உள்ளக வரலாறுகளைக் கொண்ட இரு கிளையன்ட்டுகள் ஒரே கிளையைப் பெறும்போது, அவற்றிடம் ஏற்கெனவே உள்ள பொருட்களை மீண்டும் அனுப்பாமல் இருக்க, சேவையகம் ஒவ்வொன்றுக்கும் தனிப் பொதியை உருவாக்க வேண்டியிருக்கலாம். இப்பதில்களை உருவாக்கச் செயலி வளமும் வட்டு உள்ளீடு/வெளியீடும் தேவைப்படுவதால், அதிக எண்ணிக்கையிலான வாசிப்பவர்களுக்கு ஏற்ப விரிவாக்குவது கடினமாகிறது.

இதற்கு மாற்றாக, எழுதுதலை விரிவாக்கத் தளர்வான ஒத்திசைவு முறையையும் (காரணவழி ஒத்திசைவு), வாசிப்பை விரிவாக்கப் பொதிக்கோப்புகளின் மறுபயன்பாட்டையும் Pando வழங்குகிறது.

காரணவழி ஒத்திசைவு (CC)

கிளைக்கு ஒரு கிளையன்ட் அனுப்பும்போது, வரும் பொதிக்கோப்பை மாற்ற முடியாத தரவுத்தொகுதியாகத் தரவுத்தொகுதிச் சேமிப்பகத்தில் Pando சேமிக்கிறது. கிளை நகரும் ஒவ்வொரு முறையும், புதிய முனை, அதை வழங்கிய பொதி, அப்பொதி சார்ந்துள்ள முந்தைய சுட்டுப் பதிப்புகள் ஆகியவற்றைக் கொண்ட சுட்டுப் பதிப்பை மீத்தரவுச் சேமிப்பகத்தில் Pando பதிவுசெய்கிறது. தரவுத்தொகுதிச் சேமிப்பகத்தையும் மீத்தரவுச் சேமிப்பகத்தையும் கூடுதல் சேவையகங்கள் மூலம் விரிவாக்கலாம்.

Pando-இலிருந்து மாற்றப்பதிவு அல்லது சுட்டைப் பெற, சுட்டுப் பதிப்புகளின் தொகுப்பை (பொதிக்கோப்புகளை) கிளையன்ட்டில் மீண்டும் செயல்படுத்த வேண்டும். இதன் மூலம், பெறப்படும் சுட்டுப் பதிப்பை உருவாக்கிய கிளையன்ட்டின் நிலை மீட்டமைக்கப்படுகிறது. இது ரிபாசிட்டரி முழுவதும் தளர்வான ஒத்திசைவை வழங்கினாலும், தனித்தனிச் சுட்டுகளின் புதுப்பிப்புகளை வரிசையாகச் செயல்படுத்தியதற்கு இணையான விளைவை உறுதிசெய்கிறது. ஒரே சுட்டுக்கு ஒரே நேரத்தில் அனுப்பும்போது மட்டுமே கிளையன்ட்டுகளுக்கிடையே முரண்பாடு ஏற்படுகிறது. பல கிளைகளை வாசிக்கும் கிளையன்ட், அவை அனைத்தும் ரிபாசிட்டரியின் ஒரே நேர நிலையைக் காட்டுவதாகக் கருத முடியாது.

இடப்புறம், முதன்மைக் கிளையின் மூன்று தொடர்ச்சியான பொதிகளில் முறையே A, B, C; D, E; F மாற்றப்பதிவுகள் உள்ளன. வலப்புறம், முதன்மைக் கிளையும் பணிக்கிளையும் C-இல் பிரிகின்றன. முதன்மைக் கிளை G-க்கு நகர்கிறது; பணிக்கிளை D, E, F வழியாக நகர்கிறது. சமீபத்திய பணிக்கிளைப் பொதியில் D, E, F உள்ளன. D, E ஆகியவை முந்தைய பணிக்கிளைப் பொதியிலும் இருப்பதை முறிந்த கோட்டு எல்லை குறிக்கிறது. புதிய பொதி G-இல் உள்ள முதன்மைக் கிளையைச் சார்ந்திருப்பதை நீல அம்பு குறிக்கிறது. F-இன் Git பெற்றோர் E ஆகும்.

முதன்மைக் கிளைக்கு அனுப்பும்போது, ஒன்று அல்லது அதற்கு மேற்பட்ட மாற்றப்பதிவுகளைக் கொண்ட பொதி சேர்க்கப்படுகிறது. பக்கக் கிளைக்கு ஒவ்வொரு முறை அனுப்பும்போதும், அக்கிளையின் முந்தைய மாற்றப்பதிவுகளும் மீண்டும் சேர்க்கப்படுகின்றன. இதனால் அறிவிக்கப்பட்ட முதன்மைக் கிளைப் பதிப்பைக் கொண்ட கிளையன்ட், பக்கக் கிளையை ஒரே பொதியில் பெற முடியும்.

இது காரணவழி ஒத்திசைவின் ஒரு வடிவம் ஆகும். ஒரு சுட்டைப் பெற, வாசிப்பவர் அதை உருவாக்கியவரின் வரலாற்றைக் காண்கிறார். அனுப்புதலின்போது கிளையன்ட்டும் சேவையகமும் ஏற்றுக்கொள்ளும் பகிரப்பட்ட வரலாற்றை Pando கட்டுப்படுத்துகிறது. இதனால் கிளையன்ட்டுகள் எளிதில் பகிரக்கூடிய பொதிக்கோப்புகளை உருவாக்குகின்றன.

இதன் விளைவாக, Git செயல்பாடுகளின்போது அனைத்துச் சுட்டுகளின் ஒரே நேர நிலையையோ, நகலாக்கம் அல்லது பெறுதலுக்குள் சுட்டுப் புதுப்பிப்புகளின் வரிசையையோ Pando வழங்குவதில்லை. எடுத்துக்காட்டாக, முழு நகலாக்கத்திற்கான பரிமாற்ற ஒப்பிணக்கத்தின்போது foo, bar ஆகிய இரு கிளைகளும் புதுப்பிக்கப்படுவதாகக் கொள்வோம். அப்போது ஒரு கிளையன்ட் foo-ஐ பதிப்பு 1-இலும் bar-ஐ பதிப்பு 2-இலும் காணலாம்; மற்றொரு கிளையன்ட் foo-ஐ பதிப்பு 2-இலும் bar-ஐ பதிப்பு 1-இலும் காணலாம். நடைமுறையில், பயனர்களும் ஏஜென்ட்டுகளும் அனைத்துச் சுட்டுப் புதுப்பிப்புகளின் பொது வரிசையைச் சார்ந்திருப்பதில்லை; தனிச் சுட்டின் புதுப்பிப்பு வரிசையையே சார்ந்துள்ளனர்.

அணுகுமுறைகளின் ஒப்பீடு

மூன்று ஒத்திசைவு முறைகளின் இந்த உருவகச் சோதனையில், 1,000 கிளையன்ட்டுகள் ஒவ்வொன்றும் தனித்தனிக் கிளையைத் தேர்ந்தெடுத்து, தனித்துவமான மாற்றப்பதிவுகளைத் தொடர்ந்து அனுப்புமாறு அமைக்கிறோம். மொத்த நேரத்தையும் அனுப்பியதிலிருந்து பெறுவது வரையிலான தாமதத்தையும் அளவிடுகிறோம். பணிச்சுமைகளுக்குப் பிந்தைய அளவீடு முக்கியமானது. பயனர்களும் ஏஜென்ட்டுகளும் இணைந்து பணியாற்ற அல்லது பதிப்புக் கட்டுப்பாட்டைச் சார்ந்த பிற முறைமைகளைப் பயன்படுத்தத் தேவைப்படும் சுற்றுப்பயண நேரத்தை அது அளவிடுகிறது. இந்த உருவகச் சோதனை, சாதாரண வகை முதல் உயர்தர வகை வரையிலான மெய்நிகர் இயந்திரங்களையும் தரவுத்தொகுதிச் சேமிப்பக முறைமைகளையும் பிரதிபலிக்கிறது. இந்த உருவகச் சோதனையில், மூன்றுகட்ட உறுதிப்படுத்தலுக்கான ரிபாசிட்டரி முழுவதுமான ஒத்திசைவுத் தேவையைத் தளர்த்தியுள்ளோம்.

Simulating Git Server Implementations

Follow each writer through repeated pushes, and separately measure when an independent reader can check out each commit.

Three-phase commit

Ready
Simulated time
0 s
Mean push to fetch
—
Writers done
0 / 1,000

Each square represents one writer. All selected architectures run the same workload. Squares lighten as pushes are acknowledged and turn blue when a writer finishes. The chart shows writers finished over simulated time; independent readers can continue fetching afterward. Use arrow keys to select a writer, Home or End to jump, and Escape to clear.

0 / 10,000 pushes acknowledged · 0 fetched

Select a square to inspect that writer.

Object-store WAL

Ready
Simulated time
0 s
Mean push to fetch
—
Writers done
0 / 1,000

Each square represents one writer. All selected architectures run the same workload. Squares lighten as pushes are acknowledged and turn blue when a writer finishes. The chart shows writers finished over simulated time; independent readers can continue fetching afterward. Use arrow keys to select a writer, Home or End to jump, and Escape to clear.

0 / 10,000 pushes acknowledged · 0 fetched

Select a square to inspect that writer.

Pando

Ready
Simulated time
0 s
Mean push to fetch
—
Writers done
0 / 1,000

Each square represents one writer. All selected architectures run the same workload. Squares lighten as pushes are acknowledged and turn blue when a writer finishes. The chart shows writers finished over simulated time; independent readers can continue fetching afterward. Use arrow keys to select a writer, Home or End to jump, and Escape to clear.

0 / 10,000 pushes acknowledged · 0 fetched

Select a square to inspect that writer.

Writer progress through verified fetches

  • Three-phase commit
  • Object-store WAL
  • Pando
05001,00000 s
  • Waiting
  • Pushing
  • All pushes acknowledged
0 sLater

Synthetic teaching models, not production benchmarks. Mean push to fetch covers topic pushes, from the first attempt through retries until an independent reader verifies that commit. It includes waiting for a reader slot and excludes builds and tests. With merges enabled, writer completion includes the required fetches and trunk merge.

Experiment settings

Preparing simulation…

Results

Play the comparison to see the recorded results.

Synthetic teaching models, not production benchmarks. Mean push to fetch covers topic pushes, from the first attempt through retries until an independent reader verifies that commit. It includes waiting for a reader slot and excludes builds and tests. With merges enabled, writer completion includes the required fetches and trunk merge.

Pando-ஐ மற்ற இரு அணுகுமுறைகளுடன் ஒப்பிடும் இந்த உருவகச் சோதனையை இயக்குங்கள். சாதாரண முதல் உயர்தர வன்பொருள் வரையிலான உள்கட்டமைப்பு, கிளையன்ட்டுகளின் எண்ணிக்கை, பிற அமைப்புகளைத் தேர்ந்தெடுத்து அவை எவ்வாறு ஒப்பிடப்படுகின்றன என்பதைப் பாருங்கள்.

சோதனையின் மூன்றுகட்ட உறுதிப்படுத்தல் முறைமையில், சுமையின்போது வட்டுகள் திறன் வரம்பை எட்டுவதால் எழுதுதல் தாமதம் கணிசமாக அதிகரிக்கிறது. அதே காரணத்தால், முன்கூட்டியே எழுதும் பதிவேட்டு முறைமைகளில் சேவையகங்கள் பதிவேட்டை வாசிப்பதில் பின்தங்கி, வாசிப்புத் தாமதம் கணிசமாக அதிகரிக்கிறது. எங்கள் ஒற்றை ரிபாசிட்டரியில் நடந்த நடைமுறைச் சோதனையிலும் இந்த உருவகச் சோதனையிலும், சுமையின்போது செயல்திறன் பாதிக்காமல் பல்லாயிரக்கணக்கான கிளையன்ட்டுகள் ஒரே நேரத்தில் அனுப்புவதை Pando ஆதரிக்கிறது.

அனுப்புதலைக் கையாளும்போது, வரும் பொதிக்கோப்பை உள்ளக ரிபாசிட்டரியில் பிரிக்காமல், தரவுத்தொகுதிச் சேமிப்பகத்துக்கு ஓட்டமாக அனுப்பியபடியே Pando சரிபார்க்கிறது. பெறுதலை ஒரு கிளையன்ட் தொடங்கும்போது, அதற்குத் தேவையான சேமிக்கப்பட்ட பொதிகளை Pando தேர்ந்தெடுக்கிறது; கிளையன்ட் அவற்றைப் பதிவிறக்குகிறது. எந்தச் சேவையகமும் பொதிக்கோப்புகளை உள்ளக ரிபாசிட்டரியில் பயன்படுத்தவோ, அதிக வளம் தேவைப்படும் பிரித்தல், பொதியாக்குதல் செயல்களைச் செய்யவோ தேவையில்லை. இந்தச் சேவையகங்கள் முக்கியமாகப் பரிமாற்ற ஒப்பிணக்கத்தையும் பொதிக்கோப்புத் தேர்வையுமே செய்வதால், Pando சேவையகங்களைச் சாதாரண வன்பொருளில் இயக்கலாம்.

இதனால் கிளையன்ட்டுகள், அவற்றுக்கும் Pando-க்கும் இடையிலான வலையமைப்பு, தரவுத்தொகுதிச் சேமிப்பகச் சேவை ஆகியவற்றின் திறன் வரம்புவரை Pando விரிவடைய முடியும். போதுமான திறன் இருந்தால், தனித்தனிக் கிளைகளில் பணியாற்றும் ஒவ்வொரு கிளையன்ட்டும் தனது இணைப்பு அனுமதிக்கும் முழு வேகத்தில் பொதிகளைப் பரிமாறலாம். அதே வேகத்தில் இன்னும் பல கிளையன்ட்டுகளுக்குச் சேவை வழங்க, Pando சேவையகங்களைச் சேர்த்து, மீத்தரவு மற்றும் தரவுத்தொகுதிச் சேமிப்பகங்களையும் அவற்றுடன் விரிவாக்கலாம்.

Pushing and Fetching a Branch in Pando

Pando stores the writer’s packfile in blob storage and records the ref version in metadata service. On fetch, Pando selects the packs the reader needs, and Express serves them.

Stream the push

  • Packfile bytes
  • Metadata
  • Request / acknowledgment
  • Packfile URIs

கோப்புகளை ஓர் ஏஜென்ட்டானது திருத்தி, உள்ளகத்தில் மாற்றப்பதிவை உருவாக்கி, git push கட்டளையை இயக்குகிறது. கிளையைப் புதுப்பிக்க, அந்த மாற்றங்களைக் கொண்ட பொதிக்கோப்பு உருவாகிறது. பொதியைப் பெற்று, தரவுத்தொகுதிச் சேமிப்பகத்துக்கு ஓட்டமாக Pando அனுப்புகிறது. வரும் அனுப்புதலை ஒரே முறை குறிவிலக்கிச் சரிபார்த்தபின், பலவிசைப் பரிவர்த்தனை மூலம் எங்கள் மீத்தரவுச் சேமிப்பகத்தில் சுட்டுப் பதிப்பைப் பதிவுசெய்து, சுட்டுக் குறிப்பானை ஒரே பிரிக்க முடியாத செயலாக Pando புதுப்பிக்கிறது. இதனால் “நீங்கள் எழுதியதை நீங்களே வாசிக்கலாம்” என்ற ஒத்திசைவை Pando வழங்க முடிகிறது. இந்த முழு எழுதுதல் செயல்பாட்டுக்கு O(1)O(1) மீத்தரவு வாசிப்புகளும் எழுதுதல்களும் தேவை.

கிளையை மற்றொரு கிளையன்ட் பெறும்போது, அதனிடம் ஏற்கெனவே உள்ள வரலாற்றின் அடிப்படையில் சேமிக்கப்பட்ட பொதிகளை Pando தேர்ந்தெடுக்கிறது. இதற்கு O(log⁡Δ)O(\log \Delta) மீத்தரவு வாசிப்புகள் தேவை. கிளையன்ட்டிடம் உள்ளதற்கும் அதற்குத் தேவையானதற்கும் இடையிலான மிகக்குறுகிய சுட்டுப் பதிப்பு இடைவெளியே Δ\Delta ஆகும். பொதிக்கோப்புகளின் URIகளைச் சேவையகம் வழங்குகிறது. வட்டாரத் தற்காலிகச் சேமிப்புகளில் பொதிக்கோப்புகளைச் சேமிக்கும் Express சேவை வழியாகக் கிளையன்ட் அவற்றைப் பதிவிறக்குகிறது.

இந்த வடிவமைப்பு Pando கட்டமைப்பின் மூன்று மையச் சேவைகளைச் சார்ந்துள்ளது: அனுப்புதல், பெறுதல், சுருக்குதல்.

அனுப்புதல்களை விரிவாக்குதல்

கிளையன்ட் அனுப்பும்போது, வழக்கமான Git சேவையகம் தன் சீட்டுகள் அனைத்தையும் காட்டும் சீட்டாட்டக்காரரைப் போல, தன்னிடம் உள்ள ஒவ்வொரு கிளையையும் கிளையன்ட்டுக்கு வெளிப்படுத்துகிறது. கிளையன்ட் பின்னர் மாற்றப்பதிவுகள், மரங்கள், தரவுத்தொகுதிகளைத் திரட்டி, சேவையகத்திடம் ஏற்கெனவே இருப்பதாகத் தெரிந்த பொருட்களை விலக்கும் பொதிக்கோப்பை உருவாக்குகிறது.

அதிகச் சுட்டுகளை அறிவிப்பது அனுப்புதலின் அளவைக் குறைக்கலாம். ஆனால் அனுப்பியவர் விலக்கிய பொருட்கள் மற்றொரு கிளையன்ட்டிடம் இல்லாமல் இருக்கலாம் என்பதால், பொதியை மீண்டும் பயன்படுத்துவது கடினமாகலாம்.

Pando வேறொரு அணுகுமுறையைப் பின்பற்றுகிறது. அனைத்துக் கிளைகளையும் காட்டாமல், தேர்ந்தெடுத்த சில கிளைகளை மட்டுமே கிளையன்ட்டுக்கு அறிவிக்கிறது. இதற்கு இரு காரணங்கள் உள்ளன:

  1. ஒவ்வொரு சுட்டின் ஒத்திசைவான நிலையை வழங்க அதிக வளங்கள் தேவை. மில்லியன் கணக்கான கிளைகள் இருந்தால், சுட்டு அறிவிப்பு மட்டுமே 100 MiB-ஐத் தாண்டலாம். இதற்கு ஒவ்வொரு சேவையகமும் தற்போதைய பொருத்தப்பட்டியலை அதிக ஒருங்கிணைப்புச் செலவுடன் பராமரிக்க வேண்டும் அல்லது சுட்டுகளின் எண்ணிக்கைக்கேற்ப வளம் தேவைப்படும் தரவுத்தள வினவலை இயக்க வேண்டும்.

  2. சுட்டுகளில் ஒரு பகுதியை மட்டும் கிளையன்ட்டுக்கு வழங்குவதால், சேவையகம் வெளிப்படையாக விலக்க அனுமதித்தவற்றை மட்டுமே சார்ந்துள்ள பொதியை அது உருவாக்கும். சார்புகளைக் கண்காணிப்பதால், ஓர் அனுப்புதலில் கிளையன்ட் உருவாக்கிய பொதிக்கோப்பைப் பின்னர் வரும் பெறுதலுக்குப் பதிலாக வழங்கி Pando மீண்டும் பயன்படுத்த முடிகிறது.

Git சேவையகம் அதிகச் சுட்டுகளை அறிவிக்கும்போது, அனுப்பும் கிளையன்ட்டுகள் பொருட்களை விலக்குவதற்கு அதிக ஆதாரங்கள் கிடைக்கின்றன. இதனால் சிறிய பொதிகளை உருவாக்கலாம். ஆனால் இப்பொதிக்கோப்புகளை மீண்டும் பயன்படுத்த, பெறும் கிளையன்ட்டுகளிடம் ஒவ்வொரு சார்பும் இருப்பதைச் சேவையகம் உறுதிசெய்ய வேண்டும். இல்லையெனில், கிளையன்ட்டுக்குத் தேவையான பொருட்கள் பொதிக்கோப்பில் விடுபட்டிருக்கலாம்.

மறுபுறம், Git சேவையகம் எந்தச் சுட்டையும் அறிவிக்காவிட்டால், ரிபாசிட்டரியின் முழு வரலாற்றையும் கொண்ட பொதிக்கோப்பைக் கிளையன்ட் உருவாக்கும். அப்பொதிக்கோப்பை எந்தக் கிளையன்ட்டும் பயன்படுத்தலாம். ஆனால் எந்தக் கிளையைப் பெற்றாலும் முழு நகலாக்கத்துக்கு இணையான வளச்செலவு ஏற்படும்.

பொதிக்கோப்பின் அளவை அறிவிக்கப்படும் சுட்டுகள் எவ்வாறு பாதிக்கின்றன என்பதைக் காட்டும் வளைவு. சுட்டுகள் ஏதும் அறிவிக்கப்படாதபோது முழு வரலாறும் சேர்கிறது; முதன்மைக் கிளையை அறிவிக்கும்போது அளவு குறைகிறது; அனைத்துச் சுட்டுகளையும் அறிவிக்கும்போது புதிய பொருட்கள் மட்டுமே சேர்கின்றன.

அதிகச் சுட்டுகளை அறிவிப்பதால் சிறிய பொதிக்கோப்புகள் உருவாகின்றன. ஒரே ஒரு சுட்டை அறிவிப்பதிலேயே பெரும்பாலான அளவுக் குறைப்பு கிடைக்கலாம்.

இயல்பாக, கிளையன்ட் புதிய அம்சக் கிளையை அனுப்பும்போது, நியமிக்கப்பட்ட முதன்மைக் கிளையை மட்டுமே அடிப்படையாக Pando அறிவிக்கிறது. இதனால் ரிபாசிட்டரியில் கிளைகள் அதிகரித்தாலும் அறிவிப்பின் அளவு மாறாது. ஆனால் சில சமரசங்கள் தேவை. ஒரு பொறியாளர் ஒரே கிளைக்கு மீண்டும் மீண்டும் அனுப்பினாலோ, ஓர் அம்சக் கிளையின்மேல் மற்றொன்றை அமைத்தாலோ, முதன்மைக் கிளைக்கு வெளியே உள்ள அனைத்தையும் கிளையன்ட் மீண்டும் அனுப்ப வேண்டும்.

இதனால் அடுத்தடுத்த கிளை அனுப்புதல்கள் பெரிதாகி, தேவையில்லாமல் மீளும் பொருட்களைக் கொண்டிருக்கலாம்; கூடுதல் கிளையன்ட் அலைவரிசையும் செலவாகிறது. எங்கள் ஒற்றை ரிபாசிட்டரியில், இவ்வாறு உருவான பொதிக்கோப்புகளின் இடைநிலை அளவு 20 KiB-க்கும் குறைவு; 99-ஆம் சதமான அளவு 3 MiB-க்கும் குறைவு. இது எங்களுக்குப் பொருத்தமான சமரசம் ஆகும். அறிவிக்கப்பட்ட முதன்மைக் கிளை வரலாறு ஏற்கெனவே உள்ள வாசிப்பவர், அந்த ஒரே பொதிக்கோப்பில் கிளையைப் பெற முடியும்.

கிளையன்ட்டுக்கு அறிவிக்க வேண்டிய சுட்டுகளைத் தேர்ந்தெடுத்தபின், அனுப்புதலை ஏற்று மீத்தரவுச் சேமிப்பகத்தை Pando புதுப்பிக்கிறது. மீத்தரவுப் புதுப்பிப்பை உடனடி, பின்னணி பகுதிகளாக Pando பிரிக்கிறது. புதிதாகப் புதுப்பிக்கப்பட்ட மாற்றப்பதிவைக் கிளையன்ட்டுகள் உடனே பெறுவதை உடனடி மீத்தரவுப் புதுப்பிப்பு உறுதிசெய்கிறது. இது புதிய சுட்டுப் பதிப்பை எழுதி, சுட்டுக் குறிப்பானை அதனுடன் பொருத்துகிறது. புதிய முனை, பொதிக்கோப்பின் பரிமாற்ற ஒப்பிணக்கத்தில் பயன்படுத்திய சார்புகள், அனுப்பப்பட்ட பொதிக்கோப்பின் இணைப்பு ஆகியவையும் சேமிக்கப்படுகின்றன.

அதே நேரத்தில், சுருக்குதலைத் திட்டமிடுதல் போன்ற பின்னணிப் பணிகளும் அதே பரிவர்த்தனையில் பதிவுசெய்யப்படுகின்றன. மிகப் பெரிய அனுப்புதல்களில், மாற்றப்பதிவுகளில் ஒரு பகுதி மட்டுமே உடனடியாக எழுதப்படுகிறது. இதனால் அனுப்புதலின் அளவு எதுவாக இருந்தாலும், மீத்தரவுச் சேமிப்பகத்தில் நிலையான எண்ணிக்கையிலான வாசிப்புகளும் எழுதுதல்களுமே தேவைப்படுகின்றன.

முக்கியமாக, தொடர்பற்ற சுட்டுகளுக்கான அனுப்புதல்களை Pando சேவையகங்கள் தனித்தனியாக ஏற்க முடியும். போட்டிக்கு உள்ளாகும் ஒரே விசை சுட்டுக் குறிப்பான்தான். ஒப்பிட்டு மாற்றுதல் போன்ற பிரிக்க முடியாத செயல்பாட்டால் அதைப் பாதுகாக்கிறோம். Pando சேவையகங்கள், மீத்தரவுச் சேமிப்பக விரிவாக்க அலகுகள் அல்லது தரவுத்தொகுதிச் சேமிப்பகங்களைச் சேர்த்து எழுதுதல் த்ரூபுட்டை அதிகரிக்கலாம்.

இணைப்பின் முழு வேகத்தில் பெறுதல் மற்றும் நகலாக்கச் செயல்திறன்

பெறுதலை ஒரு கிளையன்ட் செய்யும்போது, நெறிமுறையில் have, want எனப்படும் இரு தொகுப்பு மாற்றப்பதிவு அடையாளங்களைச் சேவையகத்துக்கு வழங்குகிறது. வழக்கமான Git சேவையகம், ஏற்கெனவே உள்ள மாற்றப்பதிவுகளிலிருந்து அடையக்கூடிய பொருட்களுக்கும் தேவைப்படும் மாற்றப்பதிவுகளிலிருந்து அடையக்கூடிய பொருட்களுக்கும் இடையிலான தொகுப்பு வேறுபாட்டைக் கணக்கிட்டு, அவற்றைச் சுருக்கிக் கிளையன்ட்டுக்கு அனுப்புகிறது. இந்தச் செயல்பாட்டை விரைவாக்கத் திறந்தமூல Git சேவையகத்தில் பல உள்ளகக் குறியீடுகள் இருந்தாலும், பொதிக்கோப்புகளை உருவாக்க அதிகக் கணக்கீடு தேவைப்படலாம்; அவற்றைப் பொதுவாகத் தற்காலிகச் சேமிப்பில் மறுபயன்படுத்துவதும் கடினம்.

மாறாக, அனுப்புதலின்போது பதிவான மாற்றப்பதிவுப் பொருத்தங்களைப் பயன்படுத்தி கிளையன்ட்டின் have, want தொகுப்புகளை Pando தேடுகிறது. அந்த மாற்றப்பதிவுகளைக் கொண்ட சுட்டுப் பதிப்புகளுடன் அவற்றைப் பொருத்துகிறது. அந்த ஒவ்வொரு சுட்டுப் பதிப்பும் Pando முன்பு பெற்ற பொதிக்கோப்புடன் இணைக்கப்பட்டுள்ளது. இதன் மூலம் கிளையன்ட்டுக்குத் தேவையானவற்றைக் கண்டறிந்து, தேவையான பொருட்கள் அனைத்தையும் உள்ளடக்கும் பொதிக்கோப்புகளைச் சேவையகம் தேர்ந்தெடுக்கிறது.

Planning fetches in Pando

Pando compares what a client has with what it wants, then selects the stored packfiles needed—including any missing branch dependencies.

Already heldFetchMissing branch dependency

Fetch 27 trunk packs.

Select a branch to include its trunk dependencies.

Git நெறிமுறையில் ஏற்கெனவே உள்ளவை, தேவைப்படுபவை ஆகியவற்றைச் சுட்டுப் பதிப்புகளின் வரிசையுடன் Pando பொருத்துகிறது. ஒரு பக்கக் கிளை தேவைப்படும்போது, முதன்மைக் கிளையில் அது சார்ந்துள்ள பகுதிகள் வரையும் தேவைப்படுகிறது.

நகலாக்கம் அல்லது பெறுதலின் HTTP பதிலில் ஒரே ஒரு பொதிக்கோப்பை அனுப்ப மட்டுமே Git நெறிமுறை அனுமதிக்கிறது. எனினும், அதிகம் கவனிக்கப்படாத Git அம்சமான packfile-uri, கூடுதல் பொதிகளைத் தனியாகப் பதிவிறக்குவதற்கான இணைப்புகளைச் சேவையகம் வழங்க அனுமதிக்கிறது. Pando இந்த முறையை மட்டுமே பயன்படுத்தி, பதிலுக்குள் காலியான பொதிக்கோப்பை அனுப்புகிறது. இந்த அம்சத்தை ஆதரிக்க, packfile-uri-க்கான பல மேம்பாடுகளை மூலத் திட்டத்திற்கு OpenAI பங்களித்தது.

OpenAI முறைமைகள் பல புவியியல் பகுதிகளில் இயங்குவதால், ஒவ்வொரு பகுதியிலும் உள்ளகத் தற்காலிகச் சேமிப்புகளுடன் Pando சேவையகக் குழுக்களைப் பராமரிக்கிறோம். பொதி வழங்கல் சேவையான Express, எங்கள் தரவுத்தொகுதிச் சேமிப்பகத்தைத் தற்காலிகமாகச் சேமிக்கிறது; மற்றொரு சேவை மீத்தரவுச் சேமிப்பகத்தைத் தற்காலிகமாகச் சேமிக்கிறது. மாற்றப்பதிவு அடையாளத்திற்கான கோரிக்கை அல்லது சுட்டின் சிறப்பு வாசிப்பை, அந்தக் குழுவின் தற்காலிகச் சேமிப்பு நிலையிலிருந்தே முழுமையாக வழங்க இவை Pando-க்கு உதவுகின்றன. பொதிக்கோப்புக் கோரிக்கைகளை Express சேவையகங்களுக்கு அனுப்ப ஒத்திசைவான ஹாஷ் முறையைப் பயன்படுத்துகிறோம். தற்காலிகச் சேமிப்பிலிருந்து தரவு கிடைக்கும் விகிதம் 99%-க்கும் மேல் உள்ளது.

இந்தத் தற்காலிகச் சேமிப்பு முறைமை மிக உயர்ந்த த்ரூபுட்டை வழங்கி, கிளையன்ட்டுகளுக்கும் Pando-க்கும் இடையிலான வலையமைப்பின் முழுத் திறனையும் பயன்படுத்த முடிகிறது. இந்தப் பொதிக்கோப்பு URIகளையும் உள்ளகத் தற்காலிகச் சேமிப்புகளையும் கொண்டு, வழக்கமான மேகக்கணினிச் சேவை மெய்நிகர் இயந்திரங்களை மட்டுமே பயன்படுத்தினாலும், நகலாக்கமும் பெறுதலும் 10 Gbps வலையமைப்பு இணைப்புகளின் முழுத் திறனையும் பயன்படுத்துவதை உறுதிசெய்துள்ளோம்.

சுருக்குதலும் முதல் பைட் வருவதற்கான நேரமும்

பெரும்பாலான Git சேவையகங்களில், வளரும் ரிபாசிட்டரியின் செயல்திறனைப் பராமரிக்க மறுபொதியாக்கமும் தேவையற்ற தரவு நீக்கமும் அவசியம். இரண்டும் சேமிப்பிடத்தை மீட்கின்றன; ஆனால் அதிகக் கணக்கீடும் உள்ளீடு/வெளியீடும் தேவைப்படுகின்றன.

OpenAI-இன் ஒற்றை ரிபாசிட்டரி போன்ற வேகமாக மாறும் ரிபாசிட்டரியில், கடைசிப் பெறுதலுக்குப் பிறகு நிகழ்ந்த ஒவ்வொரு அனுப்புதலுக்கும் தனிப் பொதிக்கோப்பு URI அனுப்புவது நடைமுறைக்கு ஏற்றதல்ல. தனது முதன்மைக் கிளையைப் புதுப்பித்துக்கொள்ள, கிளையன்ட் தினமும் பல்லாயிரக்கணக்கான பொதிக்கோப்புகளைப் பதிவிறக்க வேண்டியிருக்கும்.

இந்தக் கூடுதல் சுமையைக் குறைக்க, பதிவுக் கட்டமைப்புடைய இணைப்பு மரங்களில் நடைபெறும் சுருக்குதலை ஒத்த வடிவமைப்பைப் பயன்படுத்தி, பின்னணியில் பொதிகளை Pando ஒன்றிணைக்கிறது. ஒவ்வொரு அனுப்புதலும் Pando “L0” என அழைக்கும் பொதிக்கோப்பை உருவாக்குகிறது. Pando அனுப்பக்கூடிய மிகச்சிறிய தரவு அலகு இதுவே. காலப்போக்கில், பின்னணிப் பணியாளர்கள் இந்தப் பொதிக்கோப்புகளைச் சுட்டுப் பதிப்பு வரிசைகளை உள்ளடக்கும் தொகுப்புகளாகச் சேர்க்கின்றன. அவற்றின் அளவு L0-இலிருந்து பெருக்கல் விகிதத்தில் அதிகரிக்கிறது. தற்போது எங்கள் ஒற்றை ரிபாசிட்டரி L4 வரையிலான பொதிக்கோப்புத் தொகுப்புகளைப் பயன்படுத்துகிறது.

இந்தத் தொகுப்புகள் இரு நோக்கங்களை நிறைவேற்றுகின்றன. ஒரு தொகுப்பு போதுமான அளவு நிரம்பியதும், சுருக்குதல் பணியாளர் அதைப் பொறுப்பேற்று ஒரே பொதிக்கோப்பை உருவாக்குகிறது. பொதிக்கோப்புக்குள் பொருட்களை மறுசீரமைப்பதால் சுருக்க விகிதம் மேம்படுகிறது. மேலும், சுட்டுப் பதிப்புகளின் தாவல் பட்டியலாகச் செயல்பட்டு, பெறுதலுக்கான பரிமாற்ற ஒப்பிணக்கச் செயல்திறனையும் மேம்படுத்துகிறது. ஒவ்வொரு நிலையிலும் உள்ள குறியீடுகளை ஒரே நேரத்தில் தேடுவதன் மூலம், மடக்கை அளவிலான நேரத்தில் கிளையன்ட்டுக்கு அனுப்ப வேண்டிய பொதிகளை Pando தேர்ந்தெடுக்க முடியும். மறுபொதியாக்கப்பட்டிருந்தாலும் இல்லாவிட்டாலும், இந்தப் பொதிக்கோப்புத் தொகுப்புகள் பெறுதலைத் திறம்படத் திட்டமிட உதவுகின்றன. இதனால் Pando-இன் த்ரூபுட் மற்றும் தாமதம் சார்ந்த தேவைகள் குறைகின்றன.

Compaction in Pando

Small packfiles are grouped into larger covers across levels, improving compression and speeding up fetches.

Compaction in progressPublished cover

சுருக்குதல், பல சுட்டுப் பதிப்புகளின் பொதிக்கோப்புகளைப் பின்னணியில் ஒன்றிணைக்கிறது. இதனால் குறைவான கோப்புகளுடன் மேலும் திறம்படப் பெற முடிகிறது.

பல Git சேவையகங்களைப் போலல்லாமல், ஒவ்வொரு நிலையிலும் பொதிக்கோப்புகள் தக்கவைக்கப்படுகின்றன; அவை கைவிடப்படுவதோ தேவையற்ற தரவாக நீக்கப்படுவதோ இல்லை. பெறுதலில் கிளையன்ட்டுகள் கோரும் have, want தொகுப்புகளின் அடிப்படையில், ஒவ்வொரு நிலையிலுள்ள பொதிகளும் தொடர்ந்து வழங்கப்படுகின்றன. Pando-ஐ API-ஆகப் பயன்படுத்தும் கிளையன்ட்டுகள், பொதிக்கோப்பிலிருந்து ஏதேனும் ஒரு பொருளை வாசிக்கும்போது, L4-ஐ விட L0-இல் குறைந்த தரவை வாசித்தாலே போதும். ஏனெனில் அதில் பொருள் சுருக்கப்பட்டிருக்க வாய்ப்பு குறைவு.

Pando-இல் சுருக்குதல், கிளையன்ட்டுகளுக்கு அனுப்பப்படும் மொத்தத் தரவின் அளவைக் கணிசமாகக் குறைக்கிறது. மேலும், கிளையன்ட் பின்தங்கிய அளவைவிடக் குறைந்த விகிதத்தில் பொதித் திட்டமிடல் பணியை அதிகரிக்க உதவுகிறது. பெரிய, வேகமாக மாறும் ரிபாசிட்டரிகளுக்கு இது குறிப்பாக முக்கியம். இத்தகைய ரிபாசிட்டரிகள் மென்பொருள் உருவாக்கத்தில் புதிய இயல்பாக மாறும் என எதிர்பார்க்கிறோம்.

Pando உருவாக்கம்

Codex உதவியுடன் Pando-ஐ உருவாக்கினோம். தொடக்கம் முதல் நேரடிப் பயன்பாடு வரை வெறும் 10 வாரங்களே ஆனது. Pando-இன் மையத்தை ஒரே பொறியாளர் வடிவமைத்தார்; ஏஜென்ட் குழுக்கள் செயல்படுத்தின; சில பொறியாளர்கள் பயன்பாட்டுக்குக் கொண்டுவந்தனர். இந்த ஆண்டு ஏப்ரலில் Pando நேரடிப் பயன்பாட்டுக் கோரிக்கைகளைக் கையாளத் தொடங்கியது. OpenAI பயன்படுத்தும் விரிவான மூலநிரல் கட்டுப்பாட்டு மேலாண்மைக் கருவி முறைமையின் ஒரு பகுதி இது.

Pando-இன் வடிவமைப்பைச் சரிபார்க்கப் பலவகை அணுகுமுறைகளைப் பயன்படுத்தினோம். மேலும் பாதுகாப்பான மென்பொருள் அடித்தளங்களை உருவாக்குவதற்கான⁠ எங்கள் கொள்கைகளைப் பயன்படுத்தினோம். முற்றிலும் புதிய திட்டப்பணி என்பதால், பழைய சார்புகள் இல்லாமல் Rust-இல் Pando-ஐ உருவாக்கத் தேர்ந்தெடுத்தோம். ஏஜென்ட்டுகள் தங்கள் மாற்றங்களை வழக்கமான Git செயல்பாட்டுடன் ஒப்பிட்டுச் சோதிக்க, இணக்கச் சோதனைத் தொகுப்பை எழுதினோம். ஒரே உள்ளீட்டுக்கு ஒரே விளைவைத் தரும் உருவகச் சோதனைச் சூழல் பணி அமைவுகளையும் உருவாக்கினோம். முறைமையின் மாறாத விதிகளையும் பண்புகளையும் சரிபார்த்து, பரிமாற்ற ஒப்பிணக்கத்திலும் பொதித் திட்டமிடலிலும் நுணுக்கமான போட்டிநிலைப் பிழைகளையும் பின்னடைவுகளையும் கண்டறிந்து குறைக்க இவை உதவின.

பல மாடல்கள் இந்த முறைமைக்குப் பங்களித்தன. புதிய மாடல்கள் கிடைத்தபோது, Pando-இன் செயல்திறனையும் நம்பகத்தன்மையையும் மேம்படுத்த அவற்றைப் பயன்படுத்தினோம். GPT‑6 Astra பயன்படுத்தி, ஏஜென்ட்டுகள் Lean, TLA+ மொழிகளில் “Pando கோட்பாட்டை” முறைப்படுத்தின. செயலாக்கப் பிழைகளைக் கண்டறிந்து திருத்தவும், முறைமையின் பண்புகளை நிரூபிக்கவும் அதைப் பயன்படுத்தினோம். Pando-இல் அரிதான எல்லைநிலைகளைக் கண்டறிந்து சரிசெய்ய, பல தொடர்ச்சியான அமர்வுகள் நூற்றுக்கணக்கான மணிநேரம் இயங்கின. Daybreak திறனுள்ள மாடல்களைப் பயன்படுத்தி, Git மற்றும் Pando-இல் தாக்குதல் நோக்கிலான பாதுகாப்புச் சோதனைகளைச் செய்ய ஏஜென்ட்டுகளை இரவுபகலாக இயக்குகிறோம்.

Pando-ஐ பயன்பாட்டில் கொண்டுவருதல்

முதலில், தற்போதைய மூலநிரல் கட்டுப்பாட்டு முறைமைக்கு வாசிப்பு, எழுதுதல் கோரிக்கைகளை அனுப்பும் இடைநிலையாக Pando-ஐ நிறுவினோம். இதனால் Pando-ஐயும் முந்தைய முறைமையையும் ஒத்திசைவில் வைத்து, சேவைத் தடையின்றிக் கோரிக்கைகளைப் பாதுகாப்பாக Pando-க்கு மாற்ற முடிந்தது.

தற்காலிகச் சேமிப்பு வடிவமைப்பின் ஒரு பகுதியாக, கோரிக்கைகளை அனுப்புவதற்கு முன் நகல்களை நீக்கி ஒன்றிணைக்கவும் Pando முடியும். முறைமைகளை ஒவ்வொன்றாக Pando-க்கு மாற்றும்போது, தற்போதைய கருவிகளைச் சீராக இயங்கவைக்க இது உதவியது. அதிகப் பணிச்சுமைகளை Pando-க்கு மாற்றியபோது, அவற்றின் அனுப்புதல்கள் Pando-இன் தற்காலிகச் சேமிப்பை நிரப்பி, முந்தைய பின்தளத்தின் நம்பகத்தன்மையையும் மேம்படுத்தின.

Pando பயன்படுத்தும்போது செயல்திறனை மேம்படுத்த, எங்கள் பொதுப் பயன்பாட்டு Git பதிப்பை உருவாக்குநர்களின் கணினிகளிலும் ChatGPT கணினிப் பயன்பாட்டிலும் வழங்கத் தொடங்கினோம். கிளையன்ட்டுகளைப் படிப்படியாக Pando-க்கு மாற்ற, Git கட்டளைவரி இடைமுகத்தைச் சுற்றிய ஓர் அகநிலைக் கருவியைப் பயன்படுத்தினோம். மாற்றக் கோரிக்கைகள், நிரல் மதிப்பாய்வு ஆகியவற்றைக் கையாளப் பல கருவிகளையும், தானியக்கங்களுக்கான APIகளையும் உருவாக்கினோம். Git தரவுப் போக்குவரத்துடன், பழைய APIகள், இணைய நிகழ்வு அறிவிப்புகள், ரிபாசிட்டரி பதிவிறக்கங்களைச் சார்ந்த நூற்றுக்கணக்கான ஒருங்கிணைப்புகளையும் மாற்றினோம்.

உருவாக்குநர்களும் குழுக்களும் மாறுவதற்கு Codex தானே உதவியது. ஏற்கெனவே உள்ள பணிநகல்களைத் தயார்படுத்தவும், புதிய முறைமையைப் பயன்படுத்த ஏஜென்ட்டுகளுக்கு வழிகாட்டவும் திறன்களை உருவாக்கினோம். இதனால், தங்கள் உருவாக்கச் சூழல்களையும் சேவைகளையும் மாற்றுமாறு உருவாக்குநர்கள் Codex-இடம் கேட்டாலே போதும்.

Pando-க்கு மாறியது இணைப்பின் நம்பகத்தன்மையை மேம்படுத்தி, அனுப்புதலின் இடைநிலைத் தாமதத்தை ஏறக்குறைய 80% குறைத்தது.

சில செயலிக் கருக்களைக் கொண்டே Pando நாளொன்றுக்கு ஒரு பெட்டாபைட் Git தரவை வழங்க முடியும். ஒரே மணிநேரத்தில் 57 டெராபைட்டுக்கும் அதிகமான Git பொதிகளை Pando வழங்கியுள்ளது. அதில் 99%-க்கும் அதிகமான பைட்டுகள் உள்ளக வட்டுத் தற்காலிகச் சேமிப்பிலிருந்து வழங்கப்பட்டன.

பொதிகளை மீண்டும் பயன்படுத்துவதால், வழங்கும் சேவையகங்களில் மிகக் குறைந்த கணக்கீட்டுடன், பல கிளையன்ட்டுகள் ஒரே ரிபாசிட்டரி வரலாற்றைப் பதிவிறக்க முடிகிறது. இந்த எடுத்துக்காட்டு ஒரு ரிபாசிட்டரியைக் காட்டுகிறது; ஆனால் இன்னும் பலவற்றை ஆதரிக்க Pando வடிவமைக்கப்பட்டுள்ளது. தேவை அதிகரிக்கும்போது, தரவு வழங்கலையும் Git பரிமாற்ற ஒப்பிணக்கத்தையும் தனித்தனியாக விரிவாக்கலாம்.

Git திட்டப்பணிக்குப் பங்களித்தல்

Git நெறிமுறையையும் கிளையன்ட்டையும் அடிப்படையாகக் கொண்டு Pando உருவாக்கியதால், Git-இன் பிழைகளையும் அதன் செயல்திறனை மேம்படுத்தும் வாய்ப்புகளையும் கண்டறிந்தோம்.

எடுத்துக்காட்டாக, மறுபயன்பாட்டுப் பொதிகளை Pando நேரடியாகக் கிளையன்ட்டுகளுக்கு வழங்குகிறது. எனவே அவற்றைப் பதிவிறக்கிக் குறியீடாக்குவது, முறைமையை வேகமாகவும் நம்பகமாகவும் மாற்றுவதில் முக்கியமானது. அந்தப் பணி, ஒரேநேரப் பதிவிறக்கங்கள், தடைப்பட்ட பரிமாற்றத்திற்குப் பிந்தைய சுத்தப்படுத்தல், ஏற்கெனவே முடிந்த பதிவிறக்கங்களை மீண்டும் தொடர்தல் ஆகியவற்றில் அரிதான எல்லைநிலைகளை வெளிக்கொணர்ந்தது. அந்தச் செயல்பாதைகளைச் சரிசெய்து, பெறுதலுக்காக ஏற்கெனவே உள்ள பொதியை ஏற்கும்போது சரிபார்ப்புகளைச் சேர்த்தோம். இந்தப் பணியை மூலத் திட்டத்திற்கும் பங்களித்தோம்.

நேரமும் அலைவரிசையும் எங்கு செலவாகின்றன என்பதைக் காண, packfile-uri பதிவிறக்கங்களுக்குத் தடமறிதலையும் பொதி உருவாக்கத்திற்குப் பைட் எண்ணிக்கைகளையும் சேர்த்தோம். மெதுவான பெறுதலில் நேரம் பொதி உருவாக்கத்திற்கா பரிமாற்றத்திற்கா செலவாகிறது என்பதை இதனால் எளிதில் அறியலாம்.

OpenAI-இன் Git உருவாக்கப் பதிப்பில்⁠(புதிய சாளரத்தில் திறக்கும்), தனித்தனிப் பொதிகளைக் கிளையன்ட் இணையாகப் பதிவிறக்கிக் குறியீடாக்க முடியும். “வெளிப்படையாகக் குறிப்பிடப்பட்ட இருப்புகள்” என்ற கருத்தைச் சேர்த்தோம். இதனால், அனுப்பும் கிளையன்ட் தனது பொதியிலிருந்து விலக்கக்கூடிய வரலாற்றிலிருந்து தனியாக, கிளையின் தற்போதைய முனையைச் சேவையகம் அறிவிக்க முடியும். Pando-இல், அம்சக் கிளை நகரவில்லை என்பதை --force-with-lease மூலம் சரிபார்த்து, முதன்மைக் கிளையை மட்டும் அடிப்படையாகக் கொண்டு பொதியை உருவாக்கக் கிளையன்ட்டுகளுக்கு இது உதவுகிறது. அந்த முதன்மைக் கிளை வரலாறு உள்ள எவரும் அதே பொதியைப் பயன்படுத்திக் கிளையைப் பெறலாம்.

இவற்றில் பல மேம்பாடுகள் ஏற்கெனவே மூல Git திட்டத்திலும், மேலும் பல எங்கள் பொது ரிபாசிட்டரியிலும் உள்ளன. இந்த மேம்பாடுகள் Pando-க்கு அப்பாலும் பயன்பட, Git சமூகத்துடன் தொடர்ந்து பணியாற்றுகிறோம். இந்தப் பணியை எங்கள் பொதுத் திருத்தக் கண்காணிப்பில்⁠(புதிய சாளரத்தில் திறக்கும்) பின்தொடரலாம்.

அடுத்தது என்ன

Git ரிபாசிட்டரிகளை விரிவாக்குவது குறித்த வழக்கமான கருத்துகளை மறுபரிசீலித்ததன் மூலம், எங்கள் பொறியாளர்களும் ஏஜென்ட்டுகளும் ஏற்கெனவே பயன்படுத்தும் Git பணிப்பாய்வுகளை மாற்றாமல் ஒற்றை ரிபாசிட்டரியை விரிவாக்க Pando உதவுகிறது. எங்கள் ஒற்றை ரிபாசிட்டரியில் ஒரே நேரத்தில் அதிகப் பணிகளைச் செய்ய Pando வழிவகுத்துள்ளது. இணைப்பின் நம்பகத்தன்மையை மேம்படுத்தி, நிரல் மாற்றங்களை வெளியிடும் நேரத்தையும் குறைத்துள்ளது. ஒற்றை ரிபாசிட்டரிக்கு அப்பாலும், OpenAI-க்குள் Pando-இன் பிற பயன்பாடுகளை ஆராய்கிறோம். ஏராளமான ஏஜென்ட்டுகள் பகிரப்பட்ட Git ரிபாசிட்டரியில் இணைந்து பணியாற்ற வேண்டிய பணிச்சுமைகளும் இதில் அடங்கும்.

பொறியாளர்களும் ஏஜென்ட்டுகளும் அதிக மென்பொருளை உருவாக்கும்போது, மூலநிரல் கட்டுப்பாட்டில் நாங்கள் சந்தித்த வரம்புகளை OpenAI-க்கு வெளியேயுள்ள பல குழுக்களும் சந்திக்கும். Pando-ஐச் சாத்தியமாக்கும் தொழில்நுட்பத்தை எங்கள் பயனர்களுடன் பகிர்வதற்கான வழிகளை தற்போது ஆராய்கிறோம்.

Git ரிபாசிட்டரிகளின் பயனர்கள் மற்றும் நிர்வாகிகளின் இருபது ஆண்டுகால அனுபவத்தை அடித்தளமாகக் கொண்டது Pando. Pando-ஐத் தொடர்ந்து மேம்படுத்துவோம். அதே நேரத்தில், Git பயனர்களுக்குப் பரவலாக உதவும் மேம்பாடுகளைப் பகிர, திறந்தமூல Git சமூகத்துடன் இணைந்து பணியாற்றுவோம்.

ஆசிரியர்/எழுத்தாளர்

OpenAI