জেআইটি বনাম স্ট্যাটিক সংকলক
পূর্ববর্তী পোস্টগুলিতে ইতিমধ্যে বলা হয়েছে, জেআইটি রানটাইম সময়ে আইএল / বাইটকোডকে দেশীয় কোডে সংকলন করতে পারে। এর ব্যয়টি উল্লেখ করা হয়েছিল, তবে এটির উপসংহারে নয়:
জেআইটির একটি বড় সমস্যা হ'ল এটি সবকিছু সংকলন করতে পারে না: জেআইটি সংকলন করতে সময় লাগে, তাই জেআইটি কোডের কিছু অংশ সংকলন করবে, যেখানে একটি স্ট্যাটিক সংকলক একটি সম্পূর্ণ নেটিভ বাইনারি তৈরি করবে: কিছু ধরণের প্রোগ্রামের জন্য, স্থির সংকলক সহজেই JIT কে ছাড়িয়ে যাবে।
অবশ্যই সি # (বা জাভা, বা ভিবি) সি ++ এর তুলনায় সাধারণত কার্যকর এবং শক্ত সমাধান তৈরি করতে দ্রুত হয় (কেবল যদি সি ++ এর জটিল শব্দার্থক থাকে, এবং সি ++ স্ট্যান্ডার্ড লাইব্রেরিটি আকর্ষণীয় এবং শক্তিশালী থাকে তবে পুরোটির সাথে তুলনা করলে বেশ দুর্বল হয়) .NET বা জাভা থেকে স্ট্যান্ডার্ড লাইব্রেরির স্কোপ), তাই সাধারণত, সি ++ এবং। নেট বা জাভা জেআইটির মধ্যে পার্থক্য বেশিরভাগ ব্যবহারকারীর কাছে দৃশ্যমান হবে না, এবং যে বাইনারিগুলি সমালোচনামূলক, ভাল, আপনি এখনও সি ++ প্রসেসিং কল করতে পারেন সি # বা জাভা থেকে (এমনকি এই জাতীয় নেটিভ কলগুলি নিজের মধ্যে বেশ ব্যয়বহুলও হতে পারে) ...
সি ++ রূপান্তরকাজ
নোট করুন যে সাধারণত, আপনি সি + বা জাভা এর সমতুল্য সাথে সি ++ রানটাইম কোডটি তুলনা করছেন। তবে সি ++ এর একটি বৈশিষ্ট্য রয়েছে যা বাক্সের বাইরে জাভা / সি #কে ছাড়িয়ে যেতে পারে, এটি হ'ল টেমপ্লেট রূপক: কোড প্রসেসিং সংকলন সময়ে করা হবে (এইভাবে, সংকলনের সময় বৃদ্ধি পাবে) যার ফলে শূন্য (বা প্রায় শূন্য) রানটাইম তৈরি হবে।
আমি এখনও এটিতে একটি বাস্তব জীবনের প্রভাব দেখতে পেয়েছি (আমি কেবল ধারণাগুলি দিয়ে খেলি, তবে ততক্ষণে পার্থক্যটি ছিল জেআইটি-র জন্য মৃত্যুদন্ডের কয়েক সেকেন্ড, এবং সি ++ এর জন্য শূন্য ) তবে এটি উল্লেখযোগ্য, সত্যের টেমপ্লেট রূপক পাশাপাশি নয় নগণ্য...
২০১১-০6-১০ সম্পাদনা করুন: সি ++ তে, সংকলনের সময় প্রকারের সাথে খেলানো সম্পন্ন হয়, যার অর্থ জেনেরিক কোড তৈরি করা হয় যা নন-জেনেরিক কোডকে কল করে (যেমন স্ট্রিং থেকে টাইপ টি-তে জেনেরিক পার্সার, টি টাইপের জন্য স্ট্যান্ডার্ড লাইব্রেরি এপিআই কল করে, এবং তার ব্যবহারকারীর দ্বারা পার্সারটিকে সহজেই অবিস্তারযোগ্য করা) খুব সহজ এবং খুব দক্ষ, যেখানে জাভা বা সি # এর সমতুল্য লেখার পক্ষে সবচেয়ে বেদনাদায়ক, এবং টাইপগুলি সংকলনের সময় জানা থাকলেও সর্বদা ধীর এবং সমাধানের সময়ে চালিত হবে, মানে আপনার একমাত্র আশা জেআইটির পুরো বিষয়টি ইনলাইন করা।
...
২০১১-০৯-২০১০ সম্পাদনা করুন: ব্লিটজ ++ ( হোমপেজ , উইকিপিডিয়া ) এর পিছনে দলটি সে পথে এগিয়ে গেছে এবং স্পষ্টতই, তাদের লক্ষ্য C ++ টেমপ্লেট রূপক মাধ্যমে রানটাইম এক্সিকিউশন থেকে সংকলনের সময় যতটা সম্ভব সরিয়ে বৈজ্ঞানিক গণনাগুলিতে ফরটারের সম্পাদনা পৌঁছানো is । সুতরাং " আমি এখনো তাই একটি বাস্তব জীবনে প্রভাব এই দেখতে আছে অংশ আমি উপরের লিখেছিলেন," আপাতদৃষ্টিতে করে বাস্তব জীবনে বিদ্যমান।
নেটিভ সি ++ মেমরি ইউজ
সি ++ এর জাভা / সি # থেকে মেমরির ব্যবহার আলাদা এবং এর ফলে বিভিন্ন সুবিধা / ত্রুটি রয়েছে।
জেআইটি অপ্টিমাইজেশনের বিষয়টি বিবেচনাধীন, মেমরিতে সরাসরি পয়েন্টার অ্যাক্সেস হিসাবে দ্রুত কিছুই হবে না (আসুন একটি মুহুর্তের প্রসেসরের ক্যাশে ইত্যাদির জন্য উপেক্ষা করুন)। সুতরাং, আপনার যদি মেমরির সংলগ্ন ডেটা থাকে, C ++ পয়েন্টারগুলির মাধ্যমে এটি অ্যাক্সেস করা (যেমন সি পয়েন্টার ... আসুন সিজারকে এর যথাযথ উপহার দিন) জাভা / সি # এর চেয়ে বহুগুণ দ্রুত চলে যাবে। এবং সি ++ এর আরএআইআই রয়েছে যা সি # বা এমনকি জাভা থেকে অনেকগুলি প্রসেসিংয়ে অনেক সহজ করে তোলে। সি ++ usingএর বস্তুর অস্তিত্বের সুযোগ করার দরকার নেই । এবং সি ++ এর একটি নেইfinally ধারা নেই। এটি একটি ত্রুটি নয়।
:-)
এবং সি # আদিম-মত স্ট্রাক্ট সত্ত্বেও, সি ++ "স্ট্যাকের" অবজেক্টগুলির জন্য বরাদ্দ এবং ধ্বংসের জন্য কোনও মূল্য ব্যয় করা হবে না এবং পরিষ্কার করার জন্য কোনও স্বাধীন থ্রেডে কাজ করার জন্য কোনও জিসির প্রয়োজন হবে না।
মেমরি বিভাজন হিসাবে, ২০০৮ সালে মেমরি বরাদ্দকারীরা 1980 এর পুরানো মেমরি বরাদ্দকারী নয় যা সাধারণত একটি জিসির সাথে তুলনা করা হয়: সি ++ বরাদ্দ মেমরিতে সরানো যায় না, তবে লিনাক্স ফাইল সিস্টেমে যেমন: হার্ড ডিস্কের প্রয়োজন ফ্র্যাগমেন্টেশন কখন হয় না? সঠিক কাজের জন্য সঠিক বরাদ্দকারী ব্যবহার করা C ++ বিকাশকারী সরঞ্জামদণ্ডের অংশ হওয়া উচিত। এখন, বরাদ্দকারীদের লেখা সহজ নয় এবং তারপরে, আমাদের বেশিরভাগের কাছে আরও ভাল কাজ করা উচিত এবং বেশিরভাগ ব্যবহারের জন্য, আরআইআইআই বা জিসি যথেষ্ট ভাল করার চেয়ে বেশি।
2011-10-04 সম্পাদনা করুন: দক্ষ বরাদ্দকারীদের উদাহরণগুলির জন্য: উইন্ডো প্ল্যাটফর্মগুলিতে, ভিস্টা থেকে, লো ফ্রেগমেন্টেশন হিপ ডিফল্টরূপে সক্ষম হয়। পূর্ববর্তী সংস্করণগুলির জন্য, উইনাপআই ফাংশন হিপসেটইনফর্মেশন কল করে এলএফএইচ সক্রিয় করা যেতে পারে । অন্যান্য ওএসে বিকল্প বরাদ্দকারী সরবরাহ করা হয় (দেখুন seehttps://secure.wikimedia.org/wikedia/en/wiki/Malloc একটি তালিকার জন্য)
এখন, মাল্টিকোর এবং মাল্টিথ্রেডিং প্রযুক্তির উত্থানের সাথে স্মৃতি মডেলটি কিছুটা জটিল হয়ে উঠছে। এই ক্ষেত্রে, আমি অনুমান করি .NET এর সুবিধা আছে, এবং জাভা, আমাকে বলা হয়েছিল, উপরের মাঠটি ধরেছিল। কিছু "বেয়ার মেটাল" হ্যাকারের পক্ষে তার "মেশিনের কাছে" কোডটির প্রশংসা করা সহজ। তবে এখন, সংকলকটিকে তার কাজটিতে না দিয়ে হাত দিয়ে আরও ভাল সমাবেশ তৈরি করা আরও বেশি কঠিন। সি ++ এর জন্য, এক দশক থেকে সংকলক সাধারণত হ্যাকারের চেয়ে ভাল হয়ে ওঠে। সি # এবং জাভার পক্ষে এটি আরও সহজ।
তবুও, নতুন স্ট্যান্ডার্ড সি ++ 0x সি ++ সংকলকগুলিকে একটি সাধারণ মেমোরি মডেল চাপিয়ে দেবে, যা সি ++ এ কার্যকর মাল্টিপ্রসেসিং / সমান্তরাল / থ্রেডিং কোডকে মানীকরণ করবে (এবং সহজতর করবে) এবং সংযোজকগুলির জন্য অপ্টিমাইজেশনকে আরও সহজ এবং নিরাপদ করে তুলবে। তবে এরপরে, আমরা প্রতি বছর কয়েক বছরে দেখব যদি এর প্রতিশ্রুতি সত্য হয়।
সি ++ / সিএলআই বনাম সি # / ভিবি.এনইটি
দ্রষ্টব্য: এই বিভাগে, আমি সি ++ / সিএলআই, অর্থাৎ সি ++ হোস্ট করে। নেট, নেটিভ সি ++ নয় about
গত সপ্তাহে, .NET অপ্টিমাইজেশান সম্পর্কে আমি একটি প্রশিক্ষণ পেয়েছি এবং আবিষ্কার করেছি যে স্থির সংকলক যাই হোক না কেন খুব গুরুত্বপূর্ণ। জেআইটির চেয়ে গুরুত্বপূর্ণ।
সি ++ / সি এল এলিতে সংকলিত খুব একই কোডটি (বা এর পূর্বপুরুষ, পরিচালিত সি ++) সি # (বা ভিবি.এনইটি, যার সংকলক সি # এর চেয়ে একই আইএল উত্পাদন করে) উত্পাদিত একই কোডের চেয়ে বহুগুণ দ্রুত হতে পারে।
কারণ সি ++ এর চেয়ে ইতিমধ্যে অনুকূলিত কোড তৈরি করতে সি ++ স্ট্যাটিক সংকলকটি অনেক ভাল ছিল।
উদাহরণস্বরূপ, .NET- এ অন্তর্নিহিত ফাংশন এমন ফাংশনগুলির মধ্যে সীমাবদ্ধ যাঁর বাইকোড দৈর্ঘ্য 32 বাইটের চেয়ে কম বা সমান। সুতরাং, সি # তে কিছু কোড একটি 40 বাইট অ্যাকসেসর তৈরি করবে, যা জেআইটি কখনই ইনলাইন করবে না। সি ++ / সিএলআই-তে একই কোডটি একটি 20 বাইট অ্যাকসেসর তৈরি করবে, যা জেআইটি অন্তর্ভুক্ত করবে।
আর একটি উদাহরণ হ'ল অস্থায়ী ভেরিয়েবলগুলি, যা কেবল সি ++ সংকলক দ্বারা সঙ্কলিত যখন এখনও সি # সংকলক দ্বারা উত্পাদিত আইএল-তে উল্লেখ করা হচ্ছে। সি ++ স্ট্যাটিক সংকলন অপ্টিমাইজেশনের ফলে কম কোডের ফলাফল হবে, এভাবে আরও আক্রমণাত্মক জেআইটি অপ্টিমাইজেশানকে আবার অনুমোদন দেওয়া হয়।
এর কারণটি অনুমান করা হয়েছিল যে সি ++ / সিএলআই সংকলক সি ++ নেটিভ সংকলক থেকে সুবিশাল অপ্টিমাইজেশন কৌশলগুলি থেকে লাভ হয়েছিল।
উপসংহার
আমি সি ++ পছন্দ করি।
তবে যতদূর আমি এটি দেখছি, সি # বা জাভা সবই আরও ভাল বাজে। তারা সি ++ এর চেয়ে দ্রুততর নয়, তবে আপনি যখন তাদের গুণাবলী যুক্ত করেন, তখন তারা আরও উত্পাদনশীল হয়ে ওঠে, কম প্রশিক্ষণের প্রয়োজন হয় এবং সি ++ এর চেয়ে আরও সম্পূর্ণ স্ট্যান্ডার্ড লাইব্রেরি থাকে। এবং বেশিরভাগ প্রোগ্রাম হিসাবে, তাদের গতির পার্থক্য (একরকম বা অন্যভাবে) উপেক্ষিত হবে ...
সম্পাদনা করুন (2011-06-06)
সি # /। নেট সম্পর্কে আমার অভিজ্ঞতা
আমার কাছে প্রায় একচেটিয়া পেশাদার সি # কোডিংয়ের 5 মাস রয়েছে (যা আমার সিভিতে ইতিমধ্যে সি ++ এবং জাভা এবং সি ++ / সিএলআইয়ের একটি স্পর্শ যোগ করে)।
আমি উইনফোর্ডস (আহেম ...) এবং ডাব্লুসিএফ (শীতল!), এবং ডাব্লুপিএফ (দুর্দান্ত !!!! এক্সএএমএল এবং কাঁচা সি উভয়ের মাধ্যমেই খেলেছি। ডাব্লুপিএফ এত সহজ যে আমি বিশ্বাস করি সুইং কেবল এটির সাথে তুলনা করতে পারে না), এবং সি # 4.0।
উপসংহারটি হ'ল সি ++ এর চেয়ে সি # / জাভাতে কাজ করে এমন একটি কোড তৈরি করা সহজ / দ্রুততর, যদিও সি #+ এর চেয়ে শক্তিশালী, নিরাপদ এবং শক্তসমর্থ কোড তৈরি করা অনেক কঠিন C কারণগুলি প্রচুর, তবে এটি সংক্ষিপ্ত করে দেওয়া যেতে পারে:
- জেনেরিক্স টেমপ্লেটগুলির মতো শক্তিশালী নয় ( সমস্যাটি বোঝার জন্য একটি দক্ষ জেনেরিক পার্স পদ্ধতি (স্ট্রিং থেকে টি তে লেখার চেষ্টা করুন)) বা বুস্টের কার্যকর সমতুল্য :: লেক্সিক্যাল_কাস্ট সমস্যা বোঝার জন্য )
- RAII তুলনাহীন থেকে যায় ( জিসি এখনও ফাঁস করতে পারে (হ্যাঁ, আমি সেই সমস্যাটি পরিচালনা করতে পেরেছিলাম)) এবং কেবল স্মৃতি পরিচালনা করবে Even এমনকি সি # এর
usingমতো সহজ এবং শক্তিশালী নয় কারণ একটি সঠিক ডিসপোজ বাস্তবায়ন লিখতে অসুবিধা হয় )
- সি #
readonlyএবং জাভা finalসি ++ এর মতো কোথাও কার্যকর নয়const ( অসাধারণ কাজ ছাড়াই আপনি সি # তে পঠনযোগ্য জটিল ডেটা (উদাহরণস্বরূপ নোডের একটি ট্রি) প্রকাশের কোনও উপায় নেই, যদিও এটি সি ++ এর অন্তর্নির্মিত বৈশিষ্ট্য m অপরিবর্তনীয় তথ্য একটি আকর্ষণীয় সমাধান , তবে সব কিছুই অপরিবর্তনীয় করে তোলা যায় না, সুতরাং এটি এতদূর পর্যন্ত পর্যাপ্তও নয় )।
সুতরাং, সি # যতক্ষণ না আপনি কার্যকর কিছু করতে চান ততক্ষণ একটি মনোরম ভাষা হয়ে থাকে তবে আপনি হতাশার ভাষা যে মুহুর্তে আপনি এমন কিছু চান যা সর্বদা এবং নিরাপদে থাকে কাজ করে।
জাভা আরও হতাশাজনক, কারণ এতে সি # এর চেয়ে একই সমস্যা রয়েছে এবং আরও অনেক কিছু: সি # এর usingকীওয়ার্ডের সমতুল্য না থাকা , আমার এক অত্যন্ত দক্ষ সহকর্মী তার রিসোর্সগুলি যেখানে সঠিকভাবে মুক্তি পেয়েছে তা নিশ্চিত করতে খুব বেশি সময় ব্যয় করেছেন, যেখানে সি ++ এর সমতুল্য হবে সহজ হয়েছে (ডেস্ট্রাক্টর এবং স্মার্ট পয়েন্টার ব্যবহার করে)।
সুতরাং আমি অনুমান করি যে সি # / জাভার উত্পাদনশীলতা লাভ সর্বাধিক কোডের জন্য দৃশ্যমান ... যতক্ষণ না আপনার কোডটি যতটা সম্ভব নিখুঁত হতে হবে until সেদিন, আপনি ব্যথা জানবেন। (আপনি আমাদের সার্ভার এবং জিইউআই অ্যাপ্লিকেশনগুলি যা চেয়েছেন তা বিশ্বাস করবেন না ...)।
সার্ভার-সাইড জাভা এবং সি ++ সম্পর্কে
আমি ভবনের অন্য দিকে সার্ভার দলগুলির সাথে যোগাযোগ রেখেছিলাম (আমি তাদের মধ্যে 2 বছর কাজ করেছি, জিইউআই দলে ফিরে যাওয়ার আগে) এবং আমি আকর্ষণীয় কিছু শিখলাম।
গত বছরগুলিতে, প্রবণতাটি ছিল জাভা সার্ভার অ্যাপ্লিকেশনগুলির পুরানো সি ++ সার্ভার অ্যাপ্লিকেশনগুলি প্রতিস্থাপন করার পরিকল্পনা করা হয়েছিল, কারণ জাভাতে প্রচুর ফ্রেমওয়ার্ক / সরঞ্জাম রয়েছে এবং এটি বজায় রাখা, মোতায়েন করা ইত্যাদি সহজ etc
... নিম্ন-বিলম্বিত হওয়ার সমস্যাটি গত মাসগুলিতে তার কুরুচিপূর্ণ মাথা লালন করেছে। তারপরে, জাভা সার্ভার অ্যাপ্লিকেশনগুলি, আমাদের দক্ষ জাভা টিমের দ্বারা অপ্টিমাইজেশনের চেষ্টা করা যাই হোক না কেন, সহজ এবং পরিষ্কারভাবে পুরানোগুলির বিরুদ্ধে প্রতিযোগিতাটি হারাতে পেরেছিল, সত্যিকারের অপ্টিমাইজড সি ++ সার্ভার নয়।
বর্তমানে, জাভা সার্ভারগুলিকে সাধারণ ব্যবহারের জন্য রাখার সিদ্ধান্ত নেওয়া হয়েছে যেখানে কর্মক্ষমতা এখনও গুরুত্বপূর্ণ, নিম্ন-বিন্দু লক্ষ্য দ্বারা উদ্বিগ্ন নয় এবং কম-লেটেন্সি এবং অতি-কম-ল্যাটেন্সি প্রয়োজনীয়তার জন্য ইতিমধ্যে দ্রুত সি ++ সার্ভার অ্যাপ্লিকেশনগুলিকে অনুকূল করে তোলা হয়েছে।
উপসংহার
কিছুই প্রত্যাশার মতো সহজ নয়।
জাভা এবং আরও বেশি সি #, দুর্দান্ত স্ট্যান্ডার্ড লাইব্রেরি এবং ফ্রেমওয়ার্ক সহ দুর্দান্ত ভাষা, যেখানে আপনি দ্রুত কোড দিতে পারেন এবং খুব শীঘ্রই এর ফলাফল হতে পারে।
তবে যখন আপনার কাঁচা শক্তি, শক্তিশালী এবং নিয়মতান্ত্রিক অপ্টিমাইজেশন, শক্তিশালী সংকলক সমর্থন, শক্তিশালী ভাষা বৈশিষ্ট্য এবং নিখুঁত সুরক্ষা প্রয়োজন তখন জাভা এবং সি # আপনার প্রতিযোগিতার remainর্ধ্বে থাকতে হবে এমন গুণগত মানের সর্বশেষ অনুপস্থিত তবে সমালোচনামূলক পার্সেন্ট জেতা কঠিন করে তোলে।
এটি মনে হয় যেন গড় মানের কোড তৈরি করতে আপনার সি + / জাভা এর তুলনায় সি # / জাভাতে কম সময় এবং কম অভিজ্ঞ বিকাশকারী প্রয়োজন, তবে অন্যদিকে, নিখুঁত মানের কোডের জন্য আপনার দুর্দান্ত প্রয়োজন হওয়ার মুহুর্তটি, ফলাফলগুলি পাওয়া হঠাৎ সহজ এবং দ্রুত ছিল was ঠিক সি ++ এ।
অবশ্যই এটি আমার নিজস্ব উপলব্ধি, সম্ভবত আমাদের নির্দিষ্ট প্রয়োজনের মধ্যে সীমাবদ্ধ।
তবে এখনও, জিইউআই দল এবং সার্ভার-সাইড দল দুটিতেই এটি ঘটে।
অবশ্যই, নতুন কিছু ঘটলে আমি এই পোস্টটি আপডেট করব।
সম্পাদনা করুন (2011-06-22)
"আমরা দেখতে পেলাম যে পারফরম্যান্সের ক্ষেত্রে, সি ++ একটি বড় ব্যবধানের সাথে জিতেছে it তবে, এটির পক্ষেও সর্বাধিক বিস্তৃত প্রচেষ্টা দরকার ছিল, যার মধ্যে বেশিরভাগই পরিশীলনের স্তরে করা হয়েছিল যা গড় প্রোগ্রামারকে উপলভ্য হবে না।
[...] জাভা সংস্করণটি সম্ভবত প্রয়োগ করা সবচেয়ে সহজ ছিল, তবে পারফরম্যান্সের জন্য বিশ্লেষণ করা সবচেয়ে কঠিন। বিশেষত আবর্জনা সংগ্রহের চারপাশের প্রভাবগুলি জটিল এবং টিউন করা খুব কঠিন ""
সূত্র:
সম্পাদনা করুন (2011-09-20)
"ফেসবুক এ যাচ্ছে শব্দ 'যে , যুক্তিসঙ্গতভাবে লিখিত সি ++ কোড শুধু দ্রুত চলে ' যা বিরাট পিএইচপি এবং জাভা কোড নিখুঁত এ অতিবাহিত প্রচেষ্টা ওপর জোর দেয়। অপরপক্ষে, সি ++ কোড অন্যান্য ভাষায় চেয়ে লিখতে আরো কঠিন, কিন্তু দক্ষ কোড একটি হল " অন্যান্য ভাষার চেয়ে সি ++ তে লিখতে অনেক সহজ] "।
- অ্যান্ড্রে আলেকজান্দ্রেস্কুর উদ্ধৃতি দিয়ে // বিল্ড / এ হার্ব সটার
সূত্র: