স্ট্যাটিক লিঙ্কিং বনাম গতিশীল লিঙ্কিং

Question

কিছু পরিস্থিতিতে গতিশীল লিঙ্কিং বা এর বিপরীতে স্ট্যাটিক লিঙ্কিং চয়ন করার কোন বাধ্যতামূলক কার্য সম্পাদনের কারণ রয়েছে? আমি নিম্নলিখিতটি শুনেছি বা পড়েছি, তবে এর সত্যতার জন্য আমি এই বিষয়ে যথেষ্ট প্রমাণ করতে পারি না।

1) স্ট্যাটিক লিঙ্কিং এবং ডায়নামিক লিঙ্কিংয়ের মধ্যে রানটাইম পারফরম্যান্সের পার্থক্যটি সাধারণত নগণ্য।

2) (1) প্রোগ্রাম হটপাথগুলিকে অনুকূল করতে প্রোফাইল ডেটা ব্যবহার করে এমন প্রোফাইলিং সংকলক ব্যবহার করা সত্য নয় কারণ স্ট্যাটিক লিঙ্কিংয়ের সাথে সংকলকটি আপনার কোড এবং লাইব্রেরি কোড উভয়কেই অনুকূল করতে পারে। ডায়নামিক লিঙ্কিংয়ের সাথে কেবল আপনার কোডটি অনুকূলিত করা যায়। যদি বেশিরভাগ সময় লাইব্রেরি কোড চালাতে ব্যয় করা হয় তবে এটি একটি বড় পার্থক্য আনতে পারে। অন্যথায়, (1) এখনও প্রযোজ্য।

Comments

"স্ট্যাটিক লিঙ্কিংয়ের সাথে, সংকলকটি লাইব্রেরি কোডটি অনুকূলিত করতে পারে" তবে এটি খুব সংকলন করলেই! আপনি যদি কেবল প্রাক-সংকলিত অবজেক্ট ফাইলগুলির সাথে লিঙ্ক করেন তবে আপনার সংকলক সেগুলি অনুকূল করার সুযোগ পাবে না।

যদি এটি সত্য হয় তবে আপনি ঠিক বলেছেন তবে আধুনিক সংকলকগুলির সাথে এটি কতটা সত্য তা নিয়ে কিছু প্রশ্ন রয়েছে, যদি কেউ এই উপায় বা অন্য কোনওটি যাচাই করতে পারে তবে তা দুর্দান্ত।

— এলফ

দেশীয় কোডে সংকলক সংকলক সহ (বেশিরভাগ সি / সি ++ সংকলকগুলির মতো) কোড অপ্টিমাইজেশনের জন্য আর কোনও সুযোগ নেই। কোডটি যদি কিছু মধ্যবর্তী ভাষায় সংকলিত হয় (যেমন নেট আইএল) লাইব্রেরিটি স্থানীয় কোডে সংকলনের জন্য লোড হচ্ছে তখন জেআইটি সংকলককে অনুরোধ করা হবে। জেআইটি সংকলকটি বিকশিত হওয়ার সাথে সাথে চূড়ান্ত সংকলন সময়ের সাথে আরও উন্নত হতে পারে।

— ট্যারিডন

@ এলফ: ভিএস ২০০৮ এলটিসিজি সক্ষম করে ঠিক তেমনটি করে। (লিবিব ফাইলগুলি বিশাল আকারে পরিণত হয়, যদিও ..) আমি এটির সাথে এবং "আমার সংকলক আমার জন্য কী করতে পারে" আগ্রহী এমন কারও সাথে কথা বলেছি, এটি আশ্চর্যের কিছু নয়।

— পিটারচেন

Answer 1

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

---

মন্তব্যগুলিতে এবং অন্যান্য উত্তরে খুব প্রাসঙ্গিক পরামর্শ অন্তর্ভুক্ত করার জন্য কিছু সম্পাদনা। আমি লক্ষ করতে চাই যে আপনি এটির উপর যেভাবে ব্রেক করছেন তা আপনি কোন পরিবেশটি চালানোর পরিকল্পনা করছেন তার উপর অনেক বেশি নির্ভর করে Min ন্যূনতম এম্বেড থাকা সিস্টেমগুলিতে গতিশীল সংযোগকে সমর্থন করার জন্য পর্যাপ্ত সংস্থান থাকতে পারে না। সামান্য বড় আকারের ছোট সিস্টেমগুলি ডায়নামিক লিঙ্কিংকে ভালভাবে সমর্থন করতে পারে, কারণ গতিশীল লিঙ্কিং থেকে র‌্যাম সঞ্চয়কে খুব আকর্ষণীয় করে তুলতে তাদের স্মৃতিশক্তি যথেষ্ট ছোট। মার্ক নোটস, প্রচুর সংস্থান হিসাবে সম্পূর্ণ প্রস্ফুটিত গ্রাহক পিসিগুলির রয়েছে এবং আপনি সম্ভবত সুবিধার বিষয়গুলি এই বিষয়ে আপনার চিন্তাভাবনা চালিয়ে যেতে দিতে পারেন।

---

কর্মক্ষমতা এবং দক্ষতার সমস্যাগুলি সমাধান করার জন্য: এটি নির্ভর করে ।

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

তবে, আপনি যদি একাধিক প্রক্রিয়া চালাচ্ছেন যা সমস্ত একই লাইব্রেরিকে প্রচুর পরিমাণে কল করে তবে স্ট্যাটিক লিঙ্কিংয়ের সাথে সম্পর্কিত ডায়নামিক লিঙ্কিং ব্যবহার করার সময় আপনি ক্যাশে লাইনগুলি সঞ্চয় করতে পারেন (এবং এভাবে চলমান পারফরম্যান্সে জিতে)। (যদি না আধুনিক ওএসগুলি স্ট্যাটিকালি লিঙ্কযুক্ত বাইনারিগুলিতে অভিন্ন বিভাগগুলি লক্ষ্য করার জন্য যথেষ্ট স্মার্ট না হয় তবে কঠিন মনে হয়, কেউ কি জানেন?)

আরেকটি সমস্যা: লোডিং সময়। আপনি কোনও সময়ে লোডিং ব্যয় প্রদান করেন। আপনি যখন এই ব্যয়টি প্রদান করেন তখন ওএস কীভাবে কাজ করে সেই সাথে আপনি কী লিঙ্কিং ব্যবহার করেন তার উপর নির্ভর করে। আপনি এটির প্রয়োজন হয় না হওয়া পর্যন্ত আপনি এটির পরিবর্তে অর্থ প্রদান বন্ধ রাখবেন।

লক্ষ করুন যে স্থির-বনাম-গতিশীল লিঙ্কিং traditionতিহ্যগতভাবে নয় , একটি অপ্টিমাইজেশান ইস্যু কারণ তারা উভয় অবজেক্ট ফাইলগুলি নিচে পৃথক সংকলন জড়িত। তবে এটি প্রয়োজনীয় নয়: একটি সংকলক প্রাথমিকভাবে হজম হওয়া এএসটি ফর্মটিতে "সংশ্লেষ" "স্ট্যাটিক লাইব্রেরিগুলি" তৈরি করতে পারে এবং মূল কোডের জন্য উত্পন্ন এএসটি যুক্ত করে তাদের "লিঙ্ক" করতে পারে, ফলে বিশ্বব্যাপী অপ্টিমাইজেশনকে শক্তিশালী করা যায়। আমি যে সিস্টেমগুলি ব্যবহার করি সেগুলির কোনওই এটি করে না, সুতরাং এটি কতটা ভাল কাজ করে সে সম্পর্কে আমি মন্তব্য করতে পারি না।

পারফরম্যান্স প্রশ্নের উত্তর দেওয়ার উপায় সর্বদা পরীক্ষার মাধ্যমে (এবং যতটা সম্ভব স্থাপনার পরিবেশের মতো একটি পরীক্ষার পরিবেশ ব্যবহার করুন)।

Comments

রিসোর্স খরচ মূলত কোড স্পেস, সময় যত কম যায় ততই উদ্বেগ কম। 500MB লাইব্রেরি যদি 2MB সঞ্চয়যোগ্য 5 টি প্রক্রিয়ার মধ্যে ভাগ করা হয় যা 3 গিগাবাইট র‌্যামের 1% এর চেয়ে কম হয়।

— মার্ক রান্সম

লাইব্রেরি যদি একই ভার্চুয়াল ম্যাপিং (সমস্ত প্রক্রিয়াতে একই শারীরিক এবং ভার্চুয়াল ঠিকানা) ভাগ করে, একটি গতিশীল লিঙ্ক প্রসেসরের এমএমইউতে টিএলবি স্লটগুলিও সংরক্ষণ করে না?

— ঝ্যান লিংস

এছাড়াও একটি গতিশীল লিঙ্ক আরও ভাল সংস্করণ সহ বগি লাইব্রেরি কোড আপডেট করা সহজ করে তোলে।

— ঝ্যান লিংস

@ জ্যান এটি একটি কার্যকরী সংস্করণে বগি কোড যুক্ত করা সহজ করে তোলে।

"প্লাগইনগুলি সর্বদা গতিশীল সংযোগের জন্য কল করে" " এটা ভুল। অ্যাপলের অডিও ইউনাইটস এর মতো কিছু প্লাগইন মডেল পৃথক প্রক্রিয়াতে প্লাগইন চালাতে এবং আইপিসি ব্যবহার করতে পারে। এটি প্লাগইনগুলির জন্য ডায়নামিক লিঙ্কিংয়ের একটি নিরাপদ বিকল্প (প্লাগইন হোস্টটিকে ক্র্যাশ করতে পারে না)। উত্তরটি "প্লাগইনগুলিকে গতিশীল সংযোগের প্রয়োজন হতে পারে" বা এর অনুরূপ আপডেট করার পরামর্শ দিন।

— টেলর

Answer 2

1) একটি ডিএলএল ফাংশন কল করা সর্বদা একটি অতিরিক্ত পরোক্ষ লাফ ব্যবহার করে এমনটি ভিত্তিতে তৈরি হয়। আজ, এটি সাধারণত নগণ্য। ডিএলএল এর ভিতরে আই 386 সিপিইউতে আরও কিছু ওভারহেড রয়েছে, কারণ তারা অবস্থানের স্বাধীন কোড তৈরি করতে পারে না। Amd64 এ, জাম্পগুলি প্রোগ্রামের কাউন্টারের সাথে তুলনামূলক হতে পারে, সুতরাং এটি একটি বিশাল উন্নতি।

2) এটি সঠিক। প্রোফাইলিং দ্বারা পরিচালিত অনুকূলিতকরণের সাহায্যে আপনি প্রায় 10-15 শতাংশ পারফরম্যান্স জিততে পারেন। এখন যে সিপিইউ গতি তার সীমাতে পৌঁছেছে এটি করা উপযুক্ত হবে।

আমি যোগ করব: (3) লিঙ্কার আরও ক্যাশে দক্ষ গ্রুপিংয়ে ফাংশনগুলি সজ্জিত করতে পারে, যাতে ব্যয়বহুল ক্যাশে স্তরের মিসগুলি হ্রাস করা যায়। এটি বিশেষত অ্যাপ্লিকেশনগুলির প্রারম্ভকালীন সময়েও প্রভাব ফেলতে পারে (আমি সান সি ++ কম্পাইলারের সাথে প্রাপ্ত ফলাফলের ভিত্তিতে)

এবং ভুলে যাবেন না যে ডিএলএলগুলির সাথে কোনও ডেড কোড নির্মূলকরণ সম্পাদন করা যাবে না। ভাষার উপর নির্ভর করে, ডিএলএল কোডটি সর্বোত্তম নাও হতে পারে। ভার্চুয়াল ফাংশনগুলি সর্বদা ভার্চুয়াল থাকে কারণ সংকলক জানেন না যে কোনও ক্লায়েন্ট এটি ওভাররাইট করছে কিনা।

এই কারণগুলির জন্য, যদি ডিএলএলগুলির প্রকৃত প্রয়োজন না হয় তবে কেবল স্থির সংকলন ব্যবহার করুন।

সম্পাদনা করুন (ব্যবহারকারীকে আন্ডারস্কোর দ্বারা মন্তব্যটির জবাব দিতে)

এখানে অবস্থান স্বাধীন কোড সমস্যাটি সম্পর্কে একটি ভাল সম্পদ http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/

বর্ণিত হিসাবে x86 এগুলি অন্য কোনও কিছুর জন্য আফাইক রাখে না তবে 15 বিট জাম্প রেঞ্জ এবং শর্তহীন জাম্প এবং কলগুলির জন্য নয়। এই কারণেই ফাংশনগুলি (জেনারেটরগুলি থেকে) বেশি থাকলে 32 কে সবসময়ই একটি সমস্যা হয়ে থাকে এবং এমবেডেড ট্রাম্পলাইনগুলির প্রয়োজন হয়।

তবে লিনাক্সের মতো জনপ্রিয় x86 ওএসে আপনার .SO / DLL ফাইলটি gccস্যুইচ দিয়ে উত্পন্ন না করা হলে -fpic(যা পরোক্ষ জাম্প টেবিলগুলির ব্যবহার জোর করে) আপনার যত্নের প্রয়োজন নেই । কারণ আপনি যদি না করেন, কোডটি ঠিক ঠিক ঠিক ঠিক ঠিক করা থাকে যেমন কোনও লিংক এটিকে স্থানান্তরিত করে। তবে এটি করার সময় এটি কোড বিভাগটিকে ভাগ করে না নেওয়ার যোগ্য করে তোলে এবং ডিস্ক থেকে কোডটিকে মেমরির মধ্যে পূর্ণ ম্যাপিংয়ের প্রয়োজন হবে এবং এটি ব্যবহার করার আগে এটির সমস্ত স্পর্শ করা প্রয়োজন (বেশিরভাগ ক্যাশে খালি করা, টিএলবি হিট করা) ইত্যাদি ছিল time যখন এটি ধীর বলে বিবেচিত হত।

সুতরাং আপনার আর কোনও লাভ হবে না।

আমি প্রত্যাহার না ওএস (সোলারিস বা FreeBSD 'র) কারণ আমি শুধু এই না করছেন আমাকে সমস্যার আমার ইউনিক্স বিল্ড সিস্টেমের সাথে দিয়েছেন কেন এটি ক্র্যাশ পর্যন্ত আমি আবেদন -fPICকরতে gcc।

Comments

আমি এই উত্তরটি পছন্দ করি, কারণ আমি প্রশ্নটিতে উত্থাপিত পয়েন্টগুলিকে সম্বোধন করার একমাত্র এটি ছিল।

— এলফ

এই ডিএলএল প্রযুক্তিগুলির উপর উল্লেখ থাকা এবং বিভিন্ন অপারেটিং সিস্টেমের মধ্যে একটি তুলনা করা আকর্ষণীয় হবে।

— চাচা জাইভ

সূক্ষ্ম বলে মনে হচ্ছে, তবে সিপিইউ গতি অবশ্যই তার সীমাতে পৌঁছে নি।

— এডিয়াকাপি

Answer 3

গতিশীল লিঙ্কিং কিছু লাইসেন্স প্রয়োজনীয়তা যেমন এলজিপিএল পূরণ করার একমাত্র ব্যবহারিক উপায় ।

Comments

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

— জেবেেন্টলি

পাও না। আপনি যা লিখেছেন তার প্রশংসা করতে আপনি আমাকে আরও উত্স (বা আরও বিস্তৃত) দিতে পারেন?

— বাসকায়া

@ তিন বছরের এলজিপিএল লাইসেন্স বিভাগটি ৪ ডি + ই দেখুন । হয় আপনাকে এমন একটি ফর্ম বিতরণ করতে হবে যা ব্যবহারকারীর একটি লিঙ্ক করতে পারে, বা একটি ভাগ করা (গতিশীল) লাইব্রেরি বিতরণ করতে হবে।

— মার্ক র্যানসোম

Answer 4

আমি ডিএনএমকেকে উল্লেখ করা পয়েন্টগুলির সাথে একমত, আরও:

• স্ট্যাটিকালি লিঙ্কযুক্ত অ্যাপ্লিকেশনগুলি মোতায়েন করা সহজ হতে পারে, যেহেতু খুব কম বা কোনও অতিরিক্ত ফাইল নির্ভরতা (.dll / .so) না থাকায় তারা ভুল জায়গায় নিখোঁজ হয়ে বা ইনস্টল করার সময় সমস্যা দেখা দিতে পারে।

Comments

এটি লক্ষণীয় যে গুগল থেকে গো সংকলক মূলত এই কারণে শুধুমাত্র স্থিতিশীলভাবে বাইনারিগুলি সংকলন করবে ।

— Hut8

Answer 5

স্ট্যাটিকালি লিঙ্কযুক্ত বিল্ড করার একটি কারণ হ'ল এক্সিকিউটেবলের জন্য আপনার সম্পূর্ণ বন্ধ রয়েছে তা যাচাই করা, অর্থাত্ সমস্ত প্রতীক উল্লেখগুলি সঠিকভাবে সমাধান করা হয়েছে।

অবিচ্ছিন্ন ইন্টিগ্রেশন ব্যবহার করে তৈরি করা এবং পরীক্ষা করা হচ্ছিল এমন একটি বৃহত সিস্টেমের অংশ হিসাবে, রাতের প্রতিরোধের পরীক্ষাগুলি এক্সিকিউটেবলের একটি স্ট্যাটিকভাবে সংযুক্ত সংস্করণ ব্যবহার করে চালানো হয়েছিল। মাঝে মধ্যে, আমরা দেখতে পাব যে একটি প্রতীক সমাধান হবে না এবং স্থির লিঙ্কটি ব্যর্থ হবে যদিও গতিযুক্তভাবে সংযুক্ত এক্সিকিউটেবল সফলভাবে লিঙ্ক করবে।

এটি সাধারণত তখন ঘটেছিল যখন ভাগ হওয়া লিবগুলির মধ্যে গভীরভাবে বসে থাকা প্রতীকগুলির একটি ভুল নাম ছিল এবং সুতরাং এটি স্থিরভাবে লিঙ্ক করে না। গতিশীল লিংক সমস্ত চিহ্নগুলি সম্পূর্ণরূপে সমাধান করে না, গভীরতা-প্রথম বা প্রস্থ-প্রথম মূল্যায়ন ব্যবহার নির্বিশেষে, আপনি গতিশীলভাবে সংযুক্ত এক্সিকিউটেবলের সাথে শেষ করতে পারেন যার পুরো বন্ধ নেই।

Comments

খুব ভালো কথা, আমি কাজ করার সময় কিছু কোড নিয়ে এটি করার চেষ্টা করছি তবে সমস্ত কিছু

— সংশ্লেষিত

Answer 6

1 / আমি এমন প্রকল্পগুলিতে এসেছি যেখানে ডায়নামিক লিঙ্কিং বনাম স্ট্যাটিক লিঙ্কিং বেঞ্চমার্কযুক্ত ছিল এবং গতিশীল লিঙ্কিংয়ে স্যুইচ করার জন্য পার্থক্যটি যথেষ্ট পরিমাণে নির্ধারিত হয়নি (আমি পরীক্ষার অংশ নই, আমি কেবল উপসংহারটি জানি)

2 / ডায়নামিক লিঙ্কিং প্রায়শই পিকের সাথে যুক্ত থাকে (পজিশন ইন্ডিপেন্ডেন্ট কোড, কোড যা কোডটি বোঝানো হয় তার উপর নির্ভর করে সংশোধন করার প্রয়োজন হয় না)। আর্কিটেকচারের উপর নির্ভর করে পিআইসি আরেকটি ধীরগতি আনতে পারে তবে দুটি এক্সিকিউটেবল (এবং ওএস যদি সুরক্ষা ব্যবস্থা হিসাবে লোড অ্যাড্রেসটিকে এলোমেলোকরণ ব্যবহার করে তবে একই কার্যকর দুটি ক্ষেত্রেও দুটি প্রক্রিয়া) এর মধ্যে গতিশীলভাবে সংযুক্ত লাইব্রেরি ভাগ করে নেওয়ার সুবিধা পেতে প্রয়োজন। আমি নিশ্চিত নই যে সমস্ত ওএস দুটি ধারণা দুটি আলাদা করার মঞ্জুরি দেয়, তবে সোলারিস এবং লিনাক্স এবং আইএসআরটি করে যা এইচপি-ইউএক্সও করে।

3 / আমি অন্যান্য প্রকল্পগুলিতে এসেছি যা "ইজি প্যাচ" বৈশিষ্ট্যের জন্য গতিশীল লিঙ্কিং ব্যবহার করেছিল। তবে এই "ইজি প্যাচ" ছোট ফিক্সের বিতরণকে কিছুটা সহজ এবং জটিলটির একটি রূপান্তর স্বপ্ন দেখায়। আমরা প্রায়শই সবকিছু ধাক্কা দিয়ে প্লাস্টার সাইটে সমস্যাগুলি ট্র্যাক করে শেষ করেছিলাম কারণ ভুল সংস্করণটি টোকেন ছিল।

আমার উপসংহারটি হ'ল আমি ব্যতিক্রম স্ট্যাটিক লিঙ্কিং ব্যবহার করেছি:

• প্লাগইনগুলির মতো জিনিসের জন্য যা গতিশীল সংযোগের উপর নির্ভর করে

• ভাগ করে নেওয়া গুরুত্বপূর্ণ (সি / সি ++ রানটাইম, জিইউআই লাইব্রেরিগুলির মতো একই সময়ে একাধিক প্রক্রিয়া দ্বারা ব্যবহৃত বড় লাইব্রেরিগুলি ... যা প্রায়শই স্বতন্ত্রভাবে পরিচালিত হয় এবং যার জন্য এবিআইকে কঠোরভাবে সংজ্ঞায়িত করা হয়)

যদি কেউ "ইজি প্যাচ" ব্যবহার করতে চান, আমি যুক্তি দিয়ে বলব যে গ্রন্থাগারগুলি উপরের বড় লাইব্রেরির মতোই পরিচালনা করতে হবে: সেগুলি অবশ্যই সংজ্ঞায়িত এবিআইর সাথে প্রায় স্বাধীন হতে হবে যা অবশ্যই সংশোধন করে পরিবর্তন করা উচিত নয়।

Comments

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

— অ্যান্ড্রু ম্যাকগ্রিগোর

ধন্যবাদ অ্যান্ড্রু, আমি জানতাম না যে কিছু লিনাক্স বিতরণ এটি ব্যবহার করেছে। আপনার কাছে কি আমি অনুসরণ করতে পারি এমন একটি রেফারেন্স বা আরও শিখার জন্য আমি কী কী শব্দটি অনুসন্ধান করতে পারি? (এফডাব্লুআইডাব্লু আমি শুনেছি উইন্ডোজ এটির একটি বৈকল্পিক কাজ করছে, তবে উইন্ডোজ এটির উল্লেখ করার জন্য আমার দক্ষতার অঞ্চল থেকে অনেক দূরে)।

— এপ্রোগ্রামার

আমি মনে করি আপনি যে কীওয়ার্ডটি সন্ধান করছেন সেটি হ'ল "প্রিলিংক" - এটি প্রোগ্রামের সূচনাটিকে দ্রুততর করার জন্য একটি নির্দিষ্ট ঠিকানায় দ্রুত লোড করার জন্য একটি গ্রন্থাগার প্রস্তুত করে।

— ব্লেজারব্লেড

Answer 7

এটি লিনাক্স এবং পারফরম্যান্সের প্রভাবগুলিতে ভাগ করে নেওয়া লাইব্রেরিগুলি সম্পর্কে দুর্দান্তভাবে আলোচনা করে।

Comments

ড্রিপারের ডিএসওর সাথে কীভাবে লিঙ্ক করার জন্য +1, লিনাক্সে লাইব্রেরি তৈরি করা প্রত্যেকেরই পড়া উচিত।

— জান্নে

Answer 8

ইউনিক্সের মতো সিস্টেমে, ডায়নামিক লিঙ্কিং 'রুট'-এর পক্ষে জীবন-যাপনকারী স্থানে ইনস্টল করা ভাগ করা লাইব্রেরিগুলির সাথে অ্যাপ্লিকেশনটি ব্যবহার করতে সমস্যা তৈরি করে। কারণ গতিশীল লিঙ্কার সাধারণত LD_LIBRARY_PATH বা রুট সুবিধাগুলি সহ প্রক্রিয়াগুলির জন্য এর সমতুল্য মনোযোগ দেয় না। কখনও কখনও স্ট্যাটিক লিঙ্কিং দিনটি বাঁচায়।

বিকল্পভাবে, ইনস্টলেশন প্রক্রিয়াটি গ্রন্থাগারগুলি সনাক্ত করতে হবে, তবে এটি সফ্টওয়্যারটির একাধিক সংস্করণে মেশিনে সহাবস্থান করতে অসুবিধাজনক হতে পারে।

Comments

মূল বিষয়টি LD_LIBRARY_PATHভাগ করা লাইব্রেরিগুলি ব্যবহার করার ক্ষেত্রে ঠিক কোনও বাধা নয়, কমপক্ষে জিএনইউ / লিনাক্সে নয়। উদাহরণস্বরূপ, যদি আপনি ../lib/প্রোগ্রাম ফাইলের সাথে ভাগ করে নেওয়া লাইব্রেরিগুলি ডিরেক্টরিতে রাখেন , তবে GNU সরঞ্জাম চেইনের সাথে লিঙ্কার বিকল্পটি -rpath $ORIGIN/../libসেই আপেক্ষিক অবস্থান থেকে লাইব্রেরিটি সন্ধান করে। এরপরে আপনি সহজেই সম্পর্কিত সমস্ত ভাগ করা লাইব্রেরির সাথে অ্যাপ্লিকেশনটি সহজেই স্থানান্তর করতে পারেন। এই কৌশলটি ব্যবহার করে, অ্যাপ্লিকেশন এবং গ্রন্থাগারগুলির একাধিক সংস্করণ থাকার কোনও সমস্যা নেই (ধরে নিলে তারা সম্পর্কিত, যদি আপনি প্রতীকী লিঙ্কগুলি ব্যবহার করতে না পারেন) তবে তারা সম্পর্কিত ass

— FooF

> মূল অধিকার সহ প্রক্রিয়াগুলির জন্য। আমি মনে করি আপনি মূলসূত্রবিহীন ব্যবহারকারীদের দ্বারা চালিত সেতুযুক্ত প্রোগ্রামগুলির বিষয়ে কথা বলছেন - অন্যথায় এটি কোনও অর্থ দেয় না। এবং অ-মানক স্থানে লাইব্রেরি সহ একটি নির্ধারিত বাইনারি আশ্চর্যজনক - তবে যেহেতু কেবলমাত্র রুট সেই প্রোগ্রামগুলি ইনস্টল করতে পারে তাই তিনি সে /etc/ld.so.confক্ষেত্রেও সম্পাদনা করতে পারবেন ।

— ব্লেজারব্লেড

Answer 9

এটা সত্যিই খুব সহজ। আপনি যখন আপনার উত্স কোডটিতে পরিবর্তন আনেন, আপনি কি এটি তৈরি করতে 10 মিনিট বা 20 সেকেন্ড অপেক্ষা করতে চান? কুড়ি সেকেন্ড আমি সহ সব করতে পারেন। এর বাইরে, আমি হয় তরবারিটি থেকে বেরিয়ে এসেছি বা কীভাবে পৃথক সংকলন ব্যবহার করতে পারি এবং এটিকে আরাম অঞ্চলে ফিরিয়ে আনতে কীভাবে লিঙ্কিং করতে পারি তা নিয়ে চিন্তাভাবনা শুরু করি।

Comments

আমি সংকলনের গতিতে পার্থক্যটি আসলে চিহ্নিত করিনি, তবে আমি গতিশীল লিঙ্কটি উল্লেখযোগ্যভাবে দ্রুত করতে পারতাম। আমার সংকলনের সময় যেমন হয় তেমন বুস্ট যথেষ্ট খারাপ কাজ করে।

— এলওফ

Answer 10

ডায়নামিক লিঙ্কিংয়ের সর্বোত্তম উদাহরণ হ'ল লাইব্রেরি ব্যবহৃত হার্ডওয়্যারের উপর নির্ভরশীল। প্রাচীন কালে সি গণিতের গ্রন্থাগারটি গতিশীল হওয়ার সিদ্ধান্ত নেওয়া হয়েছিল, যাতে প্রতিটি প্ল্যাটফর্ম এটিকে অনুকূল করতে সমস্ত প্রসেসরের ক্ষমতা ব্যবহার করতে পারে।

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

Answer 11

গতিশীল লিঙ্কিংয়ের জন্য গতিশীল লাইব্রেরিটি খুঁজে পেতে এবং এটি লোড করার জন্য ওএসের জন্য অতিরিক্ত সময় প্রয়োজন। স্ট্যাটিক লিঙ্কিংয়ের সাথে, সবকিছু একসাথে এবং এটি মেমরির মধ্যে এক-শট লোড।

এছাড়াও, ডিএলএল হেল্ক দেখুন । এটি সেই দৃশ্যে যেখানে ডিএলএল যে ওএস লোড করে তা আপনার অ্যাপ্লিকেশনটির সাথে আসে না, বা আপনার অ্যাপ্লিকেশনটি যে সংস্করণটি প্রত্যাশা করে।

Comments

ডিএলএল হেলকে এড়াতে বিভিন্ন ধরণের প্রতিরোধ ব্যবস্থা রয়েছে তা লক্ষ করা গুরুত্বপূর্ণ।

— ocodo

Answer 12

এখনও আলোচিত নয় এমন আরেকটি সমস্যা হ'ল লাইব্রেরিতে বাগ ফিক্স করা।

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

গতিশীল সংযোগের মাধ্যমে, আপনি কেবল গতিশীল লাইব্রেরি পুনর্নির্মাণ এবং পুনরায় বিতরণ করবেন এবং আপনার কাজ শেষ হয়েছে।

Answer 13

স্ট্যাটিক লিঙ্কিং আপনাকে কেবলমাত্র একটি একক উদাহরণ দেয়, একটি পরিবর্তন করতে আপনার পুরো প্রোগ্রামটি পুনরায় সংকলনের প্রয়োজন order ডায়নামিক লিঙ্কে আপনার কেবলমাত্র ডেল পরিবর্তন করতে হবে এবং আপনি যখন আপনার এক্সপি চালাবেন তখন পরিবর্তনগুলি রানটাইম এ নেওয়া হবে dyn ডায়নামিক লিঙ্কিং (যেমন: উইন্ডোজ) দ্বারা আপডেট এবং বাগ ফিক্স সরবরাহ করা সহজ।

Answer 14

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

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

জিএনইউ / লিনাক্স সিস্টেম ব্যবহার করে এমন ডিভাইসগুলির একটি অত্যন্ত সাধারণ উদাহরণ হ'ল ব্যাসবক্স । আমি নেটবিএসডি-র সাথে বুটযোগ্য আই 386 (32-বিট) সিস্টেমের চিত্র তৈরি করে চূড়ান্ত দিকে নিয়ে এসেছি যার মধ্যে কার্নেল এবং এর মূল ফাইল সিস্টেম উভয়ই রয়েছে, যার মধ্যে crunchgenহার্ড-লিঙ্কগুলির সাথে একটি একক স্ট্যাটিক-লিঙ্কযুক্ত (বাই ) বাইনারি রয়েছে সমস্ত প্রোগ্রাম যা নিজেই স্ট্যান্ডার্ড ফুল-ফিচার সিস্টেম প্রোগ্রামগুলির সমস্ত (শেষ গণনা ২ 27৪ তে ভাল) রয়েছে (এটি বেশিরভাগ টুলচেন ব্যতীত), এবং এটি আকারে 20 মেগা বাইটের চেয়ে কম (এবং সম্ভবত কেবলমাত্র 64MB সহ একটি সিস্টেমে খুব স্বাচ্ছন্দ্যে চলে মেমরির (এমনকি মূল ফাইল সিস্টেমটি সঙ্কুচিত এবং সম্পূর্ণ র‍্যামে থাকা সত্ত্বেও) যদিও আমি এটির পরীক্ষা করার জন্য এত ছোট একটিও খুঁজে পাইনি।

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

তবে এটি এখনও পুরো গল্প নয়। আমি সাধারণত আমার সম্পূর্ণ বিকাশ সিস্টেমের জন্য সমস্ত বাইনারি স্থিতিশীলভাবে যুক্ত করে নেটবিএসডি অপারেটিং সিস্টেম ইনস্টলগুলি তৈরি এবং ব্যবহার করি। যদিও এটি একটি বিস্ময়কর পরিমাণে আরও বেশি ডিস্ক স্পেস গ্রহণ করে (টুলচেইন এবং এক্স 11 স্ট্যাটিক-লিঙ্কযুক্ত সবকিছু সহ x86_64 এর জন্য মোট ~ 6.6 গিগাবাইট) (বিশেষত যদি কোনও সমস্ত প্রোগ্রামের জন্য পুরো ডিবাগ প্রতীক টেবিলগুলি অন্য ~ 2.5 জিবি উপলব্ধ রাখে) তবে ফলাফল এখনও সামগ্রিকভাবে দ্রুত সঞ্চালিত হয় এবং কিছু কাজের জন্য এমনকি লাইব্রেরির কোড পৃষ্ঠা ভাগ করার জন্য আদর্শ গতিশীল-সংযুক্ত সিস্টেমের চেয়ে কম মেমরি ব্যবহার করা হয়। ডিস্কটি সস্তা (এমনকি দ্রুতগতির ডিস্ক), এবং প্রায়শই ব্যবহৃত ডিস্ক ফাইলগুলি ক্যাশে করা মেমরিও তুলনামূলক কম সস্তা, তবে সিপিইউ চক্রগুলি আসলে এটি নয় এবং ld.soশুরু হওয়া প্রতিটি প্রক্রিয়ার জন্য প্রারম্ভকৃত মূল্য প্রদান করে paying everyএটি শুরু হওয়ার সময়টি অনেকগুলি প্রক্রিয়া শুরু করার জন্য সিপিইউ চক্রের কয়েক ঘন্টা এবং ঘন্টা সময় নেয়, বিশেষত যখন একই প্রোগ্রামগুলি বারবার ব্যবহার করা হয়, যেমন উন্নয়ন সিস্টেমে সংকলক। স্ট্যাটিক-লিঙ্কযুক্ত সরঞ্জামচেইন প্রোগ্রামগুলি কয়েক ঘন্টা দ্বারা আমার সিস্টেমগুলির জন্য পুরো-ওএস মাল্টি-আর্কিটেকচার বিল্ড সময়কে হ্রাস করতে পারে । আমি এখনও আমার একক crunchgen'এড বাইনারি'তে সরঞ্জামচেইনটি তৈরি করতে পারি না, তবে আমার সন্দেহ হয় যে আমি যখন সিপিইউ ক্যাশে জয়ের কারণে আরও কয়েক ঘন্টা বিল্ড টাইম সাশ্রয় করি।

Answer 15

স্ট্যাটিক লিঙ্কিংটিতে প্রোগ্রামগুলি যে একক এক্সিকিউটেবল ফাইলের জন্য প্রয়োজনীয় ফাইলগুলি অন্তর্ভুক্ত করে।

ডায়নামিক লিঙ্কিং যা আপনি সাধারণ হিসাবে বিবেচনা করবেন, এটি একটি এক্সিকিউটেবল করে তোলে যার জন্য এখনও ডিএলএল প্রয়োজন হয় এবং এগুলি একই ডিরেক্টরিতে থাকতে পারে (বা ডিএলএলগুলি সিস্টেম ফোল্ডারে থাকতে পারে)।

(ডিএলএল = ডায়নামিক লিঙ্ক লাইব্রেরি)

গতিযুক্ত লিঙ্কযুক্ত এক্সিকিউটেবলগুলি দ্রুত সংকলিত হয় এবং এটি সংস্থান-ভারী নয় as

Answer 16

Static linking সংকলনের সময় এমন একটি প্রক্রিয়া যখন কোনও লিঙ্কযুক্ত সামগ্রী প্রাথমিক বাইনারিতে অনুলিপি করা হয় এবং একক বাইনারি হয়ে যায়।

কনস:

• সংকলন সময় দীর্ঘ
• আউটপুট বাইনারি বড়

Dynamic linkingরানটাইমের একটি প্রক্রিয়া যখন কোনও লিঙ্কযুক্ত সামগ্রী লোড হয়। এই টেকনিকটি এগুলিকে অনুমতি দেয়:

• ABIস্থিতিশীলতা বৃদ্ধি করে এমন প্রাথমিকের সংশোধন না করে লিঙ্কযুক্ত বাইনারি আপগ্রেড করুন ^{[সম্পর্কে]}
• একটি একক ভাগ অনুলিপি আছে

কনস:

• শুরুর সময়টি ধীর হয় (লিঙ্কযুক্ত সামগ্রীটি অনুলিপি করা উচিত)
• লিঙ্কারের ত্রুটিগুলি রানটাইমটিতে ফেলে দেওয়া হয়