সিআইটি + টি জেআইএমের সাথে জেভিএম বা সিএলআর এর চেয়ে দ্রুততর হতে পারে এমন দাবিটি সমর্থন করে কি? [বন্ধ]


119

এসই-তে একটি পুনর্বিবেচনাযুক্ত থিম আমি বহু প্রশ্নের মধ্যে লক্ষ্য করেছি যে চলমান যুক্তি হ'ল জাভা-র মতো উচ্চ স্তরের ভাষার চেয়ে সি ++ দ্রুত এবং / বা আরও দক্ষ। পাল্টা যুক্তিটি হ'ল যে আধুনিক জেভিএম বা সিএলআর জেআইটি এবং ঠিক তেমন ক্রমবর্ধমান সংখ্যক কাজের জন্য ধন্যবাদ হিসাবে দক্ষ হতে পারে এবং আপনি কী করছেন এবং কেন কিছু নির্দিষ্ট উপায়ে করছেন তা যদি আপনি জানেন তবে সি ++ কেবল আরও কার্যকর is মেধা কর্মক্ষমতা বৃদ্ধি হবে। এটি সুস্পষ্ট এবং নিখুঁত জ্ঞান করে।

আমি একটি বেসিক ব্যাখ্যা জানতে চাই (যদি এমন কোনও বিষয় থাকে ...) তবে কেন এবং কীভাবে সিভিএসে জেভিএম বা সিএলআর এর চেয়ে নির্দিষ্ট কাজ দ্রুত হয়? এটি কি কেবল কারণ সি ++ মেশিন কোডে সংকলিত হয়েছে যখন জেভিএম বা সিএলআর এখনও চালনার সময় JIT সংকলনের প্রসেসিং ওভারহেড আছে?

আমি যখন বিষয়টি গবেষণা করার চেষ্টা করি, তখন আমি যে সমস্ত যুক্তি খুঁজে পাই তা হ'ল উচ্চতর পারফরম্যান্স কম্পিউটিংয়ের জন্য সি ++ কীভাবে ব্যবহার করা যেতে পারে তা সঠিকভাবে না বোঝার জন্য কোনও বিশদ তথ্য ছাড়াই উপরে বর্ণিত ments


কর্মক্ষমতা এছাড়াও প্রোগ্রাম জটিলতার উপর নির্ভর করে।
পান্ডু

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

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

3
একটি জেআইটি দ্বারা উত্পাদিত হতে পারে এমন কোনও সংকলন আউটপুট সি ++ দ্বারা উত্পাদিত হতে পারে, তবে সি ++ যে কোড তৈরি করতে পারে তা প্রয়োজনে জেআইটি দ্বারা উত্পাদিত হতে পারে না। সুতরাং সি ++ এর দক্ষতা এবং কর্মক্ষমতা বৈশিষ্ট্যগুলি কোনও উচ্চ-স্তরের ভাষার supers Qed
tylerl

1
@ ডাবল প্রযুক্তিগতভাবে সত্য, তবে একটি নিয়ম হিসাবে আপনি একদিকে প্রোগ্রামের কার্যকারিতা প্রভাবিত সম্ভাব্য রানটাইম কারণগুলি গণনা করতে পারেন। সাধারণত দুটি আঙুলের বেশি ব্যবহার না করেই। সবচেয়ে খারাপ ক্ষেত্রে আপনি একাধিক বাইনারি চালনা করেন ... এটি বাদ দিয়ে যে আপনার এমনকি এটি করার দরকার নেই কারণ সম্ভাব্য গতিপথ नगणনীয়, যার কারণে কেউ কেউ বিরক্তও করে না।
টাইলার

উত্তর:


200

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

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

  • প্রতিটি বস্তুর জন্য কমপক্ষে 8 বাইটের মেমরির ওভারহেড রয়েছে এবং আদিমগুলির পরিবর্তে অবজেক্টগুলির ব্যবহার অনেক জায়গায় প্রয়োজনীয় বা পছন্দ করা হয় (যথা মানক সংগ্রহ)।
  • স্ট্রিং দুটি জিনিস নিয়ে গঠিত এবং 38 বাইটের ওভারহেড রয়েছে
  • ইউটিএফ -16 অভ্যন্তরীণভাবে ব্যবহৃত হয়, যার অর্থ প্রতিটি ASCII চরিত্রের জন্য একের পরিবর্তে দুটি বাইট প্রয়োজন (ওরাকল জেভিএম সম্প্রতি খাঁটি ASCII স্ট্রিংয়ের জন্য এড়াতে একটি অপ্টিমাইজাইন প্রবর্তন করেছে)।
  • এখানে কোনও সামগ্রিক রেফারেন্স টাইপ নেই (যেমন স্ট্র্টস), এবং পরিবর্তে, সামগ্রিক রেফারেন্স ধরণের কোনও অ্যারে নেই। একটি জাভা অবজেক্ট, বা জাভা অবজেক্টের অ্যারে, সি-স্ট্রাক্ট এবং অ্যারেগুলির তুলনায় খুব খারাপ এল 1 / এল 2 ক্যাশে লোকেশন রয়েছে।
  • জাভা জেনেরিকগুলি টাইপ-মুছে ফেলা ব্যবহার করে, এতে টাইপ-ইনস্ট্যান্টেশনের তুলনায় কচির স্থানীয় অবস্থান নেই।
  • অবজেক্ট বরাদ্দ অস্বচ্ছ এবং প্রতিটি বস্তুর জন্য পৃথকভাবে করতে হবে, সুতরাং কোনও অ্যাপ্লিকেশনের পক্ষে ইচ্ছাকৃতভাবে এর ডেটা ক্যাশে-বান্ধব উপায়ে রাখা এবং এখনও এটি কাঠামোগত ডেটা হিসাবে বিবেচনা করা অসম্ভব।

কিছু অন্যান্য স্মৃতি- তবে ক্যাশে-সম্পর্কিত কারণগুলি নয়:

  • কোনও স্ট্যাক বরাদ্দ নেই, সুতরাং আপনার সাথে কাজ করা সমস্ত অ-আদিম ডেটা হ'ল garbage
  • কোনও সমষ্টিগত রেফারেন্স প্রকার নেই বলে, সমষ্টিগত রেফারেন্স ধরণের কোনও স্ট্যাক পাসিং নেই। (ভেক্টর আর্গুমেন্টগুলি কার্যকরভাবে ভাবেন)
  • আবর্জনা সংগ্রহের ফলে L1 / L2 ক্যাশের সামগ্রীগুলি ক্ষতিগ্রস্থ হতে পারে এবং জিসি স্টপ দ্য ওয়ার্ল্ড বিরতিতে আন্তঃসংযোগকে বিরতি দেয়।
  • ডেটা ধরণের মধ্যে রূপান্তরকরণের জন্য সর্বদা অনুলিপি প্রয়োজন; আপনি কোনও সকেট থেকে পেয়েছেন এমন একগুচ্ছ বাইটগুলিতে পয়েন্টার নিতে পারবেন না এবং এটিকে একটি ফ্লোট হিসাবে ব্যাখ্যা করতে পারবেন না।

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

এটি লক্ষণীয় যে, এই ট্রেড অফগুলির অনেকগুলি জাভা / জেভিএম-এর চেয়ে সি # / সিআইএল-এর চেয়ে খুব আলাদা। .NET CIL- এ রেফারেন্স-টাইপ স্ট্রাক্টস, স্ট্যাক বরাদ্দ / পাসিং, স্ট্রকের প্যাক অ্যারে এবং টাইপ-ইনস্ট্যান্টিয়েটেড জেনেরিক রয়েছে।


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

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

18
+1 টি। আরও একটি জিনিস আমি যুক্ত করব (তবে এর জন্য নতুন উত্তর জমা দিতে রাজি নই): জাভাতে অ্যারে সূচীকরণে সর্বদা সীমাবদ্ধতা পরীক্ষা করা জড়িত। সি এবং সি ++ সহ, এটি কেস নয়।
রিওয়ালক

7
উল্লেখ্য যে জাভার গাদা বরাদ্দ ++, (অভ্যন্তরীণ পুলিং এবং কিছু কারণে) সি সঙ্গে একটি সরল সংস্করণের তুলনায় উল্লেখযোগ্যভাবে দ্রুততর মূল্য, কিন্তু C ++ মেমরি অ্যালোকেশন করতে উল্লেখযোগ্যভাবে ভালো হতে যদি আপনি জানেন আপনি কি করছেন।
ব্রেন্ডন লং

10
@ ব্রেন্ডনলং, সত্য .. তবে কেবল মেমরিটি পরিষ্কার থাকলেই - একবার কোনও অ্যাপ্লিকেশন কিছুক্ষণ চলতে থাকলে, জিসির প্রয়োজনীয়তার কারণে মেমরির বরাদ্দটি ধীর হবে যা মেমরি মুক্ত করতে, চূড়ান্তকরণকারীদের চালাতে হবে এবং তারপরে জিনিসগুলি নাটকীয়ভাবে ধীর করে দেয় then কম্প্যাক্ট। এটি এমন বাণিজ্য যা বেঞ্চমার্কগুলিকে সুবিধা দেয় তবে (আইএমএইচও) সামগ্রিকভাবে অ্যাপ্লিকেশনগুলিকে ধীর করে দেয়।
gbjbaanb

67

এটি কি কেবল কারণ সি ++ টি অ্যাসেম্বলি / মেশিন কোডে সংকলিত হয়েছে যখন জাভা / সি # তে এখনও রানটাইমের সময় জেআইটি সংকলনের প্রসেসিং ওভারহেড আছে?

আংশিকভাবে, তবে সাধারণভাবে, একটি একেবারে চমত্কার রাষ্ট্রীয় অত্যাধুনিক JIT কম্পাইলার অভিমানী সঠিক সি ++ কোড এখনও দুটি প্রধান কারণে জাভা কোড চেয়ে ভাল সঞ্চালন থাকে:

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

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

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

একটি অঞ্চল যেখানে সি ++ জাভা থেকে পিছনে থাকতে পারে এমন কোনও পরিস্থিতি যেখানে অনেকগুলি ছোট ছোট অবজেক্টকে স্তূপে বরাদ্দ করা দরকার। এই ক্ষেত্রে, জাভার জঞ্জাল সংগ্রহের সিস্টেমটি সম্ভবত মানের চেয়ে ভাল পারফরম্যান্সের ফলস্বরূপ newএবং deleteসি ++ এ ফল পাবে কারণ জাভা জিসি বাল্ক বিলোপকে সক্ষম করে। তবে আবারও, একটি সি ++ প্রোগ্রামার মেমোরি পুল বা স্ল্যাব বরাদ্দকারী ব্যবহার করে এর জন্য ক্ষতিপূরণ দিতে পারে, যখন জাভা রানটাইম অনুকূলিত হয় না এমন একটি মেমরি-বরাদ্দ প্যাটার্নের মুখোমুখি হলে জাভা প্রোগ্রামারটির কোনও সংস্থান নেই।

এছাড়াও, এই বিষয় সম্পর্কে আরও তথ্যের জন্য এই দুর্দান্ত উত্তরটি দেখুন।


6
উত্তরের উত্তর তবে একটি ছোট বিষয়: "সি ++ টেমপ্লেটগুলি আপনাকে উভয়ই দেয় (আরও দীর্ঘ সময়ের জন্য কমপাইলের সময় ব্যয় করে))" আমি আরও বড় আকারের প্রোগ্রাম আকারে যুক্ত করতে চাই। সর্বদা সমস্যা নাও হতে পারে, তবে যদি মোবাইল ডিভাইসগুলির জন্য বিকাশ করা হয় তবে এটি অবশ্যই হতে পারে।
লিও

9
@ লুইসুবাল: না, এই ক্ষেত্রে, সি # জেনেরিকগুলি খুব জাভা-জাতীয় (যে একই ধরণের "জেনেরিক" কোডের পথটি কোন প্রকারের মধ্য দিয়ে যায় তা বিবেচনা করা হয় না)) সি ++ টেম্পলেটগুলির কৌশলটি হ'ল কোডটি একবারে ইনস্ট্যান্ট করা হয়েছে প্রতিটি ধরণের এটি প্রয়োগ করা হয়। তাই std::vector<int>পরিকল্পিত একটি গতিশীল অ্যারে শুধু ints জন্য, এবং কম্পাইলার এটা সেই অনুযায়ী নিখুত করতে সক্ষম হয়। এসি # List<int>এখনও ঠিক একটি List
জাল্ফ

12
@ জাল্ফ সি # জাভা ব্যবহার করে না এমনটি List<int>ব্যবহার করে। দেখুন stackoverflow.com/questions/116988/...int[]Object[]
luiscubal

5
@ লুইসুবল: আপনার পরিভাষা অস্পষ্ট। আমি যেটি "সংকলন-সময়" বলে বিবেচনা করব তাতে জেআইটি কাজ করে না। আপনি ঠিক বলেছেন, অবশ্যই যথেষ্ট চৌকস এবং আক্রমণাত্মক জেআইটি সংকলক দেওয়া হয়েছে, কার্যকরভাবে এটি কী করতে পারে তার সীমাবদ্ধতা নেই। তবে সি ++ এর জন্য এই আচরণ প্রয়োজন । আরও, সি ++ টেম্পলেটগুলি প্রোগ্রামারকে স্পষ্টত বিশেষত্ব নির্দিষ্ট করার অনুমতি দেয়, যেখানে প্রযোজ্য অতিরিক্ত স্পষ্টত অনুকূলকরণ সক্ষম করে। সি # এর জন্য কোনও সমতুল্য নেই। উদাহরণস্বরূপ, সি ++ এ, আমি এমন কোনও সংজ্ঞা দিতে পারি vector<N>যেখানে নির্দিষ্ট ক্ষেত্রে vector<4>, আমার হাত-কোডেড
সিমডি

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

46

অন্যান্য উত্তরগুলি (এখনও অবধি mention) উল্লেখ করতে ভুলে গেছে বলে মনে হয়, তবে এর উত্তর দেওয়ার জন্য আমি যা অত্যন্ত গুরুত্বপূর্ণ বলে মনে করি তা হল সি ++ 'র এক অত্যন্ত বুনিয়াদী নকশার দর্শন, যা প্রথম দিন # 1 থেকে স্ট্রস্ট্রপ দ্বারা তৈরি এবং নিযুক্ত করা হয়েছিল:

আপনি যা ব্যবহার করেন না তার জন্য আপনি অর্থ প্রদান করবেন না।

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


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

এর পরে, তিনি এমন একটি ভাষা চেয়েছিলেন যা বাস্তব-বিশ্বের সমস্যাগুলি যথাসম্ভব সরাসরি কোডে অনুবাদ করার অনুমতি দেয়, তবে কোডটি খুব দক্ষ হতে দেয়।
তার অনুসরণে, তিনি তৈরি করেছিলেন যা পরবর্তী সময়ে সি ++ হয়ে উঠবে।


সুতরাং উপরোক্ত উদ্ধৃত লক্ষ্যটি কেবলমাত্র কয়েকটি মৌলিক অন্তর্নিহিত নকশার নীতিগুলির মধ্যে একটি নয়, এটি সি ++ এর জন্য রেসন ডি'ট্রে খুব কাছে । এবং এটি ভাষার প্রায় সব জায়গাতেই পাওয়া যাবে: virtualআপনি যখন চান তখনই ফাংশনগুলি হয় (কারণ ভার্চুয়াল ফাংশনগুলিকে কল করা কিছুটা ওভারহেড নিয়ে আসে) আপনি স্পষ্টভাবে এটির জন্য অনুরোধ করলে পডগুলি কেবল স্বয়ংক্রিয়ভাবে আরম্ভ হয়, ব্যতিক্রমগুলি কেবল যখন আপনি প্রকৃতপক্ষে সম্পাদন করতে ব্যয় করেন এগুলি নিক্ষেপ করুন (যেখানে স্ট্যাকফ্রেমগুলির সেটআপ / ক্লিনআপটি খুব সস্তা হওয়ার অনুমতি দেওয়ার জন্য এটি একটি সুস্পষ্ট ডিজাইনের লক্ষ্য ছিল), কোনও জিসি যখনই এটির মতো মনে না করে ইত্যাদি চালায় না etc.

সি ++ পারফরম্যান্সের বিনিময়ে আপনাকে কিছু সুবিধা না দেওয়ার ("আমাকে কি এই পদ্ধতিটি এখানে ভার্চুয়াল করতে হবে?") স্পষ্টভাবে বেছে নেওয়া হয়েছে ("না, আমি না, এবং এখন সংকলক inlineএটি করতে পারে এবং হ্যাকটি আউটকে অনুকূলিত করতে পারে) পুরো জিনিস! "), এবং আশ্চর্যের বিষয় নয় যে এর ফলে আরও সুবিধাজনক ভাষার তুলনায় কার্যকারিতা লাভ হয়েছিল।


4
আপনি যা ব্যবহার করেন না তার জন্য আপনি অর্থ প্রদান করবেন না। => এবং তারপরে তারা আরটিটিআই যুক্ত করেছে :(
ম্যাথিউ এম।

11
@ ম্যাথিউ: আমি যখন আপনার অনুভূতি বুঝতে পেরেছি তখনও আমি সাহায্য করতে পারি না তবে লক্ষ্য করতে পারি যে এটি পারফরম্যান্সের বিষয়ে যত্ন সহকারে যুক্ত করা হয়েছে। আরটিটিআই নির্দিষ্ট করা হয়েছে যাতে এটি ভার্চুয়াল টেবিলগুলি ব্যবহার করে প্রয়োগ করা যায় এবং আপনি যদি এটি ব্যবহার না করেন তবে খুব কম ওভারহেড যুক্ত করে। আপনি যদি পলিমারফিজম ব্যবহার না করেন তবে কোনও মূল্য নেই। আমি কিছু অনুপস্থিত করছি?
এসবিআই

9
@ ম্যাথিউ: অবশ্যই কারণ আছে। তবে এ কারণ কি যৌক্তিক? আমি যা দেখতে পাচ্ছি তা থেকে, "আরটিটিআই-এর ব্যয়", যদি ব্যবহার না করা হয় তবে প্রতিটি পলিমারফিক ক্লাসের ভার্চুয়াল টেবিলের অতিরিক্ত পয়েন্টার, এটি কোনও আরটিটিআই অবজেক্টকে স্থিরভাবে কোথাও বরাদ্দ করা হয়েছে। আপনি যদি আমার টোস্টের চিপটি প্রোগ্রাম না করতে চান তবে এটি কীভাবে প্রাসঙ্গিক হতে পারে?
এসবিআই

4
@ অ্যারোনট: এর জবাব কী দিতে হবে তা নিয়ে আমি ক্ষতি করছি। আপনি কি সত্যই আমার উত্তর খারিজ করেছেন কারণ এটি পৃথকভাবে এই উপায়গুলি এবং বৈশিষ্ট্যগুলি তালিকাভুক্ত করার পরিবর্তে স্ট্রস্ট্রপ এট আলকে এমনভাবে বৈশিষ্ট্যগুলি যুক্ত করেছে যা স্ট্রস্ট্রপ এট আলকে বৈশিষ্ট্যগুলি যুক্ত করেছিল?
এসবিআই

9
@ অ্যারোনট: আপনার প্রতি আমার সহানুভূতি রয়েছে।
sbi

29

আপনি কি সেই বিষয় সম্পর্কে গুগল গবেষণা কাগজটি জানেন ?

উপসংহার থেকে:

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

এটি "অন্তর্গতভাবে আংশিক ব্যাখ্যা," কারণ সত্যিকারের বিশ্ব সি ++ সংকলকগণ অনুশীলনমূলক ব্যবস্থা দ্বারা জাভা সংকলকগুলির চেয়ে দ্রুত কোড উত্পাদন করে "।


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

2
@ গ্রেটিয়ানলুপ: আমি অবাক হয়েছি যে এটি এলটিও-তে সত্য (এখনও) সত্য কিনা।
Deduplicator

2
@GratianLup: আসুন সি জন্য ভুলবেন না প্রফাইল-নির্দেশিত অপ্টিমাইজেশান ++, ...
Deduplicator

23

এটি আপনার প্রশ্নের সদৃশ নয়, তবে গৃহীত উত্তরগুলি আপনার বেশিরভাগ প্রশ্নের উত্তর দেয়: জাভার একটি আধুনিক পর্যালোচনা

যোগফল হিসাবে:

মূলত, জাভা এর শব্দার্থবিজ্ঞান নির্দেশ করে যে এটি সি ++ এর চেয়ে ধীর ভাষা।

সুতরাং, আপনি অন্য কোন ভাষার সাথে সি ++ এর তুলনা করছেন তার উপর নির্ভর করে আপনি একই উত্তর পেতে পারেন বা না পেয়ে পারেন।

সি ++ এ আপনার রয়েছে:

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

এগুলি ভাষার সংজ্ঞাটির বৈশিষ্ট্য বা পার্শ্ব-প্রতিক্রিয়া যা এটিকে যেকোন ভাষার চেয়ে স্মৃতি এবং গতিতে তাত্ত্বিকভাবে আরও দক্ষ করে তোলে:

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

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

স্পষ্টতই, অন্যান্য ভাষাও একই কাজ করতে পারে তবে সেগুলি কেবলমাত্র কম জনপ্রিয় কারণ তারা সি ++ এর মতো বিমূর্ত সরঞ্জাম সরবরাহ করে না, তাই তারা প্রচুর ক্ষেত্রে কম ব্যবহার করে।


7

এটি মূলত স্মৃতি সম্পর্কে (যেমন মাইকেল বর্গওয়ার্ড বলেছিলেন) কিছুটা জেআইটি অদক্ষতা যুক্ত করেছে।

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

আপনি স্ট্রিংয়ের সাথে কোনও স্ট্রিংবিল্ডার অবজেক্টকে প্রতিস্থাপন করে এটিকে অপারেশনটিতে দেখতে পাচ্ছেন ... স্ট্রিংবিল্ডারগণ মেমরির প্রাক-বরাদ্দ করে এবং এটি পূরণ করে কাজ করে এবং এটি জাভা / .NET সিস্টেমগুলির জন্য একটি পরিচিত পারফরম্যান্স ট্রিক।

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

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

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

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


2
আপনার লেখা অনেক কিছুই আধুনিক প্রজন্মের আবর্জনা সংগ্রহকারীদের পক্ষে সত্য নয়।
মাইকেল বার্গওয়ার্ট

3
@ মিশেলবার্গওয়ার্ড যেমন? আমি বলি "জিসি নিয়মিত চালায়" এবং "এটি হিপকে সংক্রামিত করে"। আমার উত্তরটির বাকি অংশগুলি কীভাবে অ্যাপ্লিকেশন ডেটা স্ট্রাকচারগুলি মেমরি ব্যবহার করে তা নিয়ে উদ্বেগ প্রকাশ করে।
gbjbaanb

6

"এটি কি কেবল কারণ সি ++ টি এসেম্বলি / মেশিন কোডে সংকলিত হয়েছে যখন জাভা / সি # তে এখনও রানটাইমের সময় জেআইটি সংকলনের প্রসেসিং ওভারহেড রয়েছে?" মূলত, হ্যাঁ!

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

এখানে একটি সুন্দর বিস্তারিত তুলনা আছে


2

মনে রাখবেন যে নিম্নলিখিতটি কেবল নেটিভ এবং জেআইটি সংকলনের মধ্যে পার্থক্য তুলনা করে এবং কোনও নির্দিষ্ট ভাষা বা ফ্রেমওয়ার্কের বিশদটি আবরণ করে না। এর বাইরে কোনও নির্দিষ্ট প্ল্যাটফর্ম বেছে নেওয়ার বৈধ কারণ থাকতে পারে।

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

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

দাবিটি যে এ-বি চেয়ে দ্রুততর হয় প্রোগ্রামটি চালানোর জন্য নেওয়া সময়ের কথা উল্লেখ করে যা ব্যবহারকারী দেখেছে । যদি আমরা ধরে নিই যে উভয় কোডের টুকরোগুলি এক্সিকিউশন পর্যায়ে একইরূপে সঞ্চালিত হয়, আমাদের অবশ্যই ধরে নিতে হবে যে JIT এর কাজ প্রবাহটি ব্যবহারকারীটির চেয়ে ধীর গতিতে রয়েছে, কারণ তাকে অবশ্যই মেশিন কোডে সংকলনের সময় T দেখতে হবে, যেখানে T> ০. সুতরাং , ব্যবহারকারীর কাছে দেশীয় কাজের প্রবাহের মতো কাজ করার জন্য জেআইটি কাজের প্রবাহের যে কোনও সম্ভাবনার জন্য, আমাদের অবশ্যই কোডটির নির্বাহের সময় হ্রাস করতে হবে, যেমন মেশিন কোডে এক্সিকিউশন + সংকলন কেবল এক্সিকিউশন পর্যায়ে কম হয় নেটিভ কাজ প্রবাহ। এর অর্থ আমাদের দেশীয় সংকলনের চেয়ে JIT সংকলনে কোডটি আরও ভাল করতে হবে optim

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

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

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

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

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

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

একজন সি ++ প্রোগ্রামার যুক্তিযুক্ত হতে পারে যে তাকে গেট-গো থেকে অপ্টিমাইজেশন প্রয়োজন, এবং কোনও ভিএম-র জন্য কীভাবে কীভাবে করা যায় তা নির্ধারণ করার জন্য অপেক্ষা করা উচিত নয় if যদিও এটি সম্ভবত আমাদের বর্তমান প্রযুক্তির একটি বৈধ পয়েন্ট, কারণ আমাদের ভিএমগুলিতে অপ্টিমাইজেশনের বর্তমান স্তরটি দেশীয় কম্পাইলাররা যা দিতে পারে তার চেয়ে নিকৃষ্ট - তবে আমাদের ভিএমগুলিতে এওটি সমাধানগুলি উন্নত করা ইত্যাদি যদি সর্বদা এটি না হয় etc.


0

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


0

আমি মনে করি যে এখানে আসল প্রশ্নটি "কোনটি দ্রুত?" তবে "যা উচ্চতর পারফরম্যান্সের সর্বোত্তম সম্ভাবনা আছে?" এই পদগুলিতে দেখা যায়, সি ++ স্পষ্টভাবে জিততে পারে - এটি নেটিভ কোডে সংকলিত হয়, কোনও জিটিং থাকে না, এটি বিমূর্ততার নিম্ন স্তরের ইত্যাদি etc.

এটি পুরো গল্প থেকে অনেক দূরে।

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

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

উভয় ক্ষেত্রেই অ্যালগরিদমের একটি বুদ্ধিমান বাস্তবায়ন এবং প্রোগ্রামার বোকা না হওয়ার অন্যান্য উদাহরণগুলি সম্ভবত আরও বেশি গুরুত্বপূর্ণ কারণ হতে পারে - উদাহরণস্বরূপ, সি ++ তে সম্পূর্ণ মস্তিষ্ক-মৃত স্ট্রিং কোড লিখতে পারার পক্ষে পুরোপুরি সম্ভব যেটি এমনকি দেয়ালের সাথে যুক্ত হবে will একটি ব্যাখ্যা স্ক্রিপ্টিং ভাষা।


3
"একটি মেশিনের জন্য উপযুক্ত সংকলক অপ্টিমাইজেশানগুলি অন্যটির জন্য পুরোপুরি ভুল হতে পারে" ভাল, ভাষাটির জন্য এটি দোষ দেওয়ার মতো নয়। সত্যিই পারফরম্যান্স-সমালোচনামূলক কোডটি প্রতিটি মেশিনের জন্য পৃথকভাবে সংকলন করা যেতে পারে যা এটি চালু থাকবে, যা আপনি উত্স ( -march=native) থেকে স্থানীয়ভাবে সংকলন করেন তবে এটি কোনও মস্তিষ্কের নয় । - "এটি বিমূর্তির নিম্ন স্তরের" সত্যিই সত্য নয়। সি ++ জাভা হিসাবে উচ্চ স্তরের বিমূর্ত ব্যবহার করে (বা আসলে উচ্চতরগুলি: ফাংশনাল প্রোগ্রামিং? টেমপ্লেট মেটাপোগ্র্যামিং?), এটি জাভা যেমন "পরিষ্কারভাবে" বিমূর্ততা প্রয়োগ করে।
বাম দিকের বাইরে

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

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

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

-1

জেআইটি সংকলন আসলে পারফরম্যান্সে নেতিবাচক প্রভাব ফেলে। আপনি যদি একটি "নিখুঁত" সংকলক এবং একটি "নিখুঁত" জেআইটি সংকলক ডিজাইন করেন তবে প্রথম বিকল্পটি সর্বদা পারফরম্যান্সে জিতবে।

জাভা এবং সি # উভয়ই মধ্যবর্তী ভাষায় ব্যাখ্যা করা হয় এবং তারপরে রানটাইম নেটিভ কোডে সংকলিত হয়, যা কার্য সম্পাদনকে হ্রাস করে।

তবে এখন পার্থক্যটি সি # এর পক্ষে সুস্পষ্ট নয়: মাইক্রোসফ্ট সিএলআর বিভিন্ন সিপিইউগুলির জন্য বিভিন্ন নেটিভ কোড তৈরি করে, এইভাবে মেশিনটি চালিত হওয়ার জন্য কোডটিকে আরও কার্যকর করে তোলে, যা সর্বদা সি ++ কম্পাইলার দ্বারা হয় না।

PS সি # খুব দক্ষতার সাথে রচিত এবং এতে অনেকগুলি বিমূর্ত স্তর নেই। এটি জাভার ক্ষেত্রে সত্য নয়, যা ততটা কার্যকর নয়। সুতরাং, এক্ষেত্রে, এর গ্রেট সিএলআর দিয়ে, সি # প্রোগ্রামগুলি প্রায়শই সি ++ প্রোগ্রামের চেয়ে ভাল পারফরম্যান্স দেখায়। নেট এবং সিএলআর সম্পর্কে আরও তথ্যের জন্য জেফ্রি রিখটারের "সিএলআর মাধ্যমে সি #" দেখুন


8
যদি জেআইটি প্রকৃতপক্ষে পারফরম্যান্সে নেতিবাচক প্রভাব ফেলে, অবশ্যই এটি ব্যবহার করা হত না?
জাভিয়র

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

3
জেআইটির পারফরম্যান্সে ইতিবাচক প্রভাব রয়েছে, নেতিবাচক নয়, আপনি যদি এটিকে প্রসঙ্গে রাখেন - এটি বাইট কোডটি চালানোর আগে মেশিন কোডে সংকলন করে। ফলাফলগুলি ক্যাশে করা যায়, এটি ব্যাখ্যা করা সমমানের বাইট-কোডের চেয়ে দ্রুত চালাতে দেয়।
কেসি কুবাল

3
জেআইটি (বা বরং, বাইটকোড পদ্ধতির) পারফরম্যান্সের জন্য ব্যবহার করা হয়নি, তবে সুবিধার জন্য। প্রতিটি প্ল্যাটফর্মের জন্য প্রাক-বিল্ডিং বাইনারিগুলির পরিবর্তে (বা একটি সাধারণ সাবসেট, যা তাদের প্রত্যেকের জন্য উপ-অনুকূল) আপনি কেবলমাত্র অর্ধেকটিই সংকলন করুন এবং বাকিটি জেআইটি সংকলককে করতে দিন। 'একবার লিখুন, যে কোনও জায়গায় মোতায়েন করুন' 'কেন এইভাবে করা হয়েছে। সুবিধা মাত্র একটি বাইটকোড ব্যাখ্যাকারী সঙ্গে ছিল দিতে পারে, তবে জে আই টি JIT কাঁচা অনুবাদক তুলনায় দ্রুততর এটা করতে না (যদিও অগত্যা যথেষ্ট দ্রুত না একটি প্রি-কম্পাইল সমাধান বীট; জে আই টি JIT সংকলন করে সময় লাগবে, এবং ফলাফল সবসময় আপ দেখা যায় না এর জন্য).
tdammers

4
@ থাডামার্স, আসলে এখানে পারফরম্যান্সের উপাদানও রয়েছে। Java.sun.com/products/hotspot/ whitepaper.html দেখুন । অপ্টিমাইজেশানগুলিতে শাখার পূর্বাভাস এবং ক্যাশে হিটগুলি উন্নত করতে গতিশীল সামঞ্জস্য, ডায়নামিক ইনলাইনিং, ডি-ভার্চুয়ালাইজেশন, সীমা পরীক্ষা করা অক্ষম করা এবং লুপ আনরোলিংয়ের মতো জিনিস অন্তর্ভুক্ত থাকতে পারে। দাবিটি হ'ল অনেক ক্ষেত্রে এগুলি জেআইটির ব্যয়ের চেয়ে বেশি দিতে পারে।
চার্লস ই। গ্রান্ট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.