। / কনফিগার করা কি গতি বাড়ানো সম্ভব?


29

অনেক সিপিইউ কোর (12 বলে) সহ ওয়ার্কস্টেশনে একটি সফ্টওয়্যার প্যাকেজ সংকলন করার জন্য, কনফিগারেশন পর্যায়ে প্রায়শই প্রকৃত সংকলন পর্যায়ের তুলনায় অনেক বেশি সময় লাগে কারণ ./configureএকের পর এক পরীক্ষা করে make -jচালানো gccহয়, পাশাপাশি সমান্তরালে অন্যান্য কমান্ডও চালায় ।

আমি মনে করি যে বাকি ১১ টি কোর বেশিরভাগ সময় অলস অবস্থায় বসে থাকা ধীর ./configureসম্পন্ন হওয়ার অপেক্ষায় থাকায় এটি সম্পদের এক বিশাল অপচয় । কেন এটি ধারাবাহিকভাবে পরীক্ষাগুলি করা দরকার? প্রতিটি পরীক্ষা কি একে অপরের উপর নির্ভর করে? আমার ভুল হতে পারে তবে এগুলির বেশিরভাগই স্বতন্ত্র বলে মনে হচ্ছে।

আরও গুরুত্বপূর্ণ, গতি বাড়ানোর কোনও উপায় আছে ./configureকি?


সম্পাদনা করুন: পরিস্থিতিটি চিত্রিত করার জন্য, এখানে জিএনইউ করিউটিলসের সাথে একটি উদাহরণ রয়েছে

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

ফলাফল:

# For `time ./configure`
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For `time make -j24`
real    0m42.085s
user    2m35.113s
sys     6m15.050s

কোর্টিলস -৮.৯ সহ , এর ./configureচেয়ে times গুণ বেশি সময় লাগে make। যদিও ./configureকম সিপিইউ সময় ব্যবহার করে ("ব্যবহারকারী" এবং "সিজ" বার দেখুন) এটি অনেক বেশি সময় নেয় ("বাস্তব") কারণ এটি সমান্তরাল নয়। আমি কয়েকবার পরীক্ষার পুনরাবৃত্তি করেছি (প্রাসঙ্গিক ফাইলগুলি সম্ভবত মেমরির ক্যাশে থাকে) এবং সময়গুলি 10% এর মধ্যে থাকে।


4
এটি হাস্যকর এবং লজ্জাজনক যে, এখানে কোনও ভাল বিল্ড সরঞ্জাম নেই। যেগুলি বিদ্যমান রয়েছে সেগুলি নিখুঁত জড়তার কারণে। বাইনারিগুলি তৈরি করা এমন একটি মজাদার, অবিশ্বাস্য বিষয়।
ম্যাট জয়েনার

এটি ধারাবাহিকভাবে পরীক্ষাগুলি সম্পাদন করে কারণ নির্দিষ্ট সিস্টেমে কীভাবে সমান্তরালতা চলছে তা সন্ধান করা দুঃস্বপ্ন হবে।
সাইমন রিখটার

উত্তর:


13

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

আপনার নির্দিষ্ট দৃশ্যের উপর নির্ভর করে যেভাবেই কনফিগারটি চালানোর গতি বাড়ানোর কয়েকটি উপায় থাকতে পারে। উদাহরণ স্বরূপ:

  • একটি দ্রুত শেল ব্যবহার করুন। উদাহরণস্বরূপ, হিসাবে dashপরিবর্তে ব্যবহার বিবেচনা করুন । (দ্রষ্টব্য: দেবিয়ানের অধীনে, এটি প্যাচ করা হয়েছে যাতে এটি ব্যবহার না করে, কারণ এটি ব্যবহার করে প্রচুর স্ক্রিপ্টগুলি ভেঙে যায় ))bash/bin/shdashconfigureconfigure
  • যদি আপনি দূরবর্তীভাবে বিল্ডস চালান (উদাহরণস্বরূপ, ssh এর মাধ্যমে), তবে আমি খুঁজে পেয়েছি যে কনসোল আউটপুট বেশ ধীর হতে পারে। কলিং বিবেচনা করুন configure -q
  • যদি আপনি একই প্রকল্পটি বারবার তৈরি করেন তবে ক্যাশে ফাইলটি ব্যবহার করে বিবেচনা করুন। কল করুন configure -C। বিশদের জন্য অটোকনফ ডকুমেন্টেশন দেখুন।
  • যদি আপনি প্রচুর বিভিন্ন প্রকল্প তৈরি করেন তবে কোনও সাইট ফাইল ( config.site) ব্যবহার করে বিবেচনা করুন । আবার, ডকুমেন্টেশন দেখুন।
  • সমান্তরালে বেশ কয়েকটি প্রকল্প তৈরি করুন।

2
আপনি দয়া করে আরও কিছু ব্যাখ্যা makeকরতে পারেন কেন সমান্তরাল হতে পারে তবে configureবা autoconfনা পারলে?
নেটভোপ

দেখে মনে হচ্ছে শেলটি নিয়ে আমার কিছু কার্যকারিতা আছে। চলমান sh -c "echo $i" > /dev/null1000 গুণ এই সিস্টেমে 10s লাগবে, কিন্তু শুধুমাত্র আমার অন্যান্য সিস্টেমে 1-2s।
নেটভোপ

1
জিএনইউ মেক একাধিক প্রক্রিয়া শুরু এবং পরিচালনার জন্য বেশ জটিল সি কোড ব্যবহার করে। কনফিগার স্ক্রিপ্টগুলি পোর্টেবল বোর্ন শেল-এ লেখা হয়। এটি সম্ভব হবে, তবে সম্ভবত খুব কঠিন।
পিটার আইসেন্ট্রাট

4
configureপরীক্ষাগুলির মধ্যে নির্ভরতা বাছাই করা আসলে একটি কম জটিলতা অপারেশন (টপোলজিকাল সাজান) এবং কম্পিউটিংয়ের প্রথম দিনগুলিতে সমাধান করা হয়েছে। আসল সমস্যাটি হ'ল কেউ এটি করার জন্য কোডটি অটোকনফ এ যুক্ত করতে বিরক্ত করেনি এবং অনেক প্রোগ্রামার নিজেই উত্পন্ন ফাইলগুলি সংশোধন করে। পুরো সিস্টেমটি নতুন করে সংশোধন করা উচিত যাতে কনফিগারেশনটি আর শেল স্ক্রিপ্ট দ্বারা না হয়ে থাকে তবে একটি আবাসিক বাইনারি রিডিং মেটা ডেটা ফাইলগুলি দ্বারা।
বিলc.cn

1
মেলিং তালিকায় উল্লিখিত আলোচনার একটি রেফারেন্স যুক্ত করুন (সংরক্ষণাগারের লিঙ্ক))
কার্ল রিখটার

3

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


1
দুর্ভাগ্যক্রমে, দেখে মনে হচ্ছে এসএসডিগুলি খুব বেশি সাহায্য করবে না। আমি ./configureবারবার দৌড়ানোর চেষ্টা করেছি কিন্তু পরবর্তী রানগুলি প্রথম রান হিসাবে প্রায় সময় নেয়। যেহেতু সিস্টেমে প্রচুর ফ্রি মেমরি রয়েছে তাই আমি মনে করি সিস্টেমটি ডিস্কে না গিয়ে মেমরি ক্যাশে থেকে সংকলক এবং গ্রন্থাগারগুলি পরিচালনা করছে running
নেটভোপ

1
যদি আপনি বারবার চালানোর চেষ্টা করেন। / কনফিগার বারবার (এবং এটি যদি স্বতঃসিদ্ধ করা হয়) এর সমস্ত ফলাফল ক্যাশ হওয়া উচিত এবং খুব ভাল করা উচিত। আপনি আরও সহায়তা চান তা দেখতে আমাদের কনফিগার স্ক্রিপ্ট পোস্ট করতে পারেন। আমি এখানে বেশ গুরুর আধিক্য রয়েছে তা নিশ্চিত
বুবু

আমি আসলে রানগুলির মধ্যে এটি পরিষ্কার করেছি ( ./configureসর্বদা একটি সতেজ উত্তোলিত উত্স বৃক্ষের মধ্যে চলছে)। আমি মূল পোস্টে আরও বিশদ যুক্ত করতে যাচ্ছি (স্থান এখানে সীমাবদ্ধ)।
নেটভোপ

আমি কেবলমাত্র ফোল্ডারটি পরিষ্কার না করে পরীক্ষা করেছি (অর্থাত্‍ একের ./configureপরপরই চলমান ./configure) এবং দুটি রান একই সময়ে সময় নেয়। এর অর্থ কি ক্যাশিং সম্ভবত আমার সিস্টেমে কাজ করছে না?
নেটভোপ

আমি কোর্টিলগুলি নিয়ে আসব এবং সময় পেলে কনফিগার করার চেষ্টা করব। সাথে থাকুন.
বুবু

3

যদি আপনি অনডম্যান্ড সিপিইউ গভর্নর ব্যবহার করেন তবে পারফরম্যান্সটি ব্যবহার করে দেখুন। এটি 40-50% দ্বারা i7 এবং a8-3850 এ সহায়তা করে। Q9300 এ খুব বেশি পার্থক্য করে না।

কোয়াড কোর সিপুতে, আপনি হয়ত করতে পারেন

for cpu in `seq 0 3`; do sudo cpufreq-set -g performance -c $cpu; done

(-R বিকল্পটি এটি তৈরি করা উচিত যাতে প্রতিটি কোরের জন্য আপনাকে সিপুফেরিক-সেট করতে না হয়, তবে আমার কম্পিউটারগুলিতে এটি কার্যকর হয় না))

যদিও ক্যাশে বিকল্পটি আরও বেশি সহায়তা করে।


3

বিভিন্ন ধরণের ./configureস্ক্রিপ্ট রয়েছে। কোনও স্ক্রিপ্ট তৈরিতে কোনও বিকাশকারীকে সহায়তা করার জন্য জনপ্রিয় সরঞ্জাম ( অটকনফ তাদের মধ্যে একটি হ'ল ) ./configureরয়েছে, তবে এমন কোনও নিয়ম নেই যা বলে যে প্রতিটি বিকাশকারীকে এই সরঞ্জামগুলি ব্যবহার করতে হবে, এবং তারপরেও এই সরঞ্জামগুলির মধ্যেও, এই স্ক্রিপ্টগুলির পদ্ধতিতে বিস্তৃত ভিন্নতা থাকতে পারে নির্মিত হয়।

./configureসমান্তরালভাবে চালানো যেতে পারে এমন কোনও জনপ্রিয় স্ক্রিপ্ট সম্পর্কে আমি অবগত নই । জনপ্রিয় সরঞ্জামগুলির দ্বারা নির্মিত বেশিরভাগ স্ক্রিপ্টগুলি কমপক্ষে কিছু না কিছু বা তার সমস্ত ফলাফলকে ক্যাশে করে, তাই আপনি যদি আবার চালনা করেন ( make cleanযাইহোক, প্রথমে না করেই ), দ্বিতীয়বার এটি আরও দ্রুত চলে।

এটি করা সম্ভব হয়নি তা বলার অপেক্ষা রাখে না ... তবে আমি সন্দেহ করি যে কাজ করছে এমন লোকদের জন্য কিছুটা অনুপ্রেরণা নেই autoconf, উদাহরণস্বরূপ, যেহেতু বেশিরভাগ প্যাকেজগুলির জন্য, কনফিগার পর্বটি প্রকৃত সংকলন এবং সংযোগের তুলনায় খুব দ্রুত সম্পর্কিত পর্যায়ক্রমে।


2
যদিও এই সরঞ্জামগুলি ব্যবহার করার উপযুক্ত কারণ রয়েছে: সেগুলি পরিপক্ক এবং তারা অনেকগুলি ছোট বিবরণ ট্র্যাক করে। আমার মনে হয় আপনি এমনি এম্বেড ওয়ার্ল্ডে লিনাক্স এত বড় অবস্থানে থাকতে পারতেন না যদি আপনি কেবল আপনার ক্রস সংকলকটিতে কনফিগার স্ক্রিপ্টটি নির্দেশ করতে না পারেন এবং 90% সময়ের বাক্স থেকে এটি কাজ না করতে পারেন।
সাইমন রিখটার

2

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

যাইহোক ... অন্টারে রাম করতে হবে এবং সেখান থেকে তৈরি করতে হবে।

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2

1
ধন্যবাদ, তবে আমি ইতিমধ্যে / dev / shm তে সংকলন করছি যা একটি tmpfs :-)
নেটভপ

0

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

সুতরাং জিনিসটির গতি বাড়ানোর বিষয়ে আমার ইঙ্গিতগুলি পর্যালোচনা করুন / পড়ুন https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.