রুবি / পাইথনের মতো গতিময় ভাষা কি সি / সি ++ পারফরম্যান্সের মতো পৌঁছতে পারে?


64

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

সি / সি ++ এর সাথে খুব ঘনিষ্ঠভাবে সম্পাদনকারী একটি বাইনারিতে রুবি বা অন্য কোনও গতিশীল ভাষাগুলি সংকলন করতে পারে এমন একটি সংকলক তৈরি করা কি সম্ভব? পিআইপি / রুবিনিয়াসের মতো জেআইটি সংকলকরা শেষ পর্যন্ত বা পারফরম্যান্সে সি / সি ++ এর সাথে মিলবে না এমন কোনও মৌলিক কারণ আছে কি?

দ্রষ্টব্য: আমি বুঝতে পারি যে "পারফরম্যান্স" অস্পষ্ট হতে পারে, তাই এটি পরিষ্কার করার জন্য, আমি বলতে চাইছিলাম, আপনি যদি পারফরম্যান্স ওয়াইয়ের সাথে সি / সি ++ এ এক্স করতে পারেন, আপনি কি রুবির / পাইথনের এক্স পারফরম্যান্সের সাথে এক্স এর কাজটি করতে পারবেন? যেখানে এক্স ডিভাইস ড্রাইভার এবং ওএস কোড থেকে শুরু করে ওয়েব অ্যাপ্লিকেশন পর্যন্ত সমস্ত কিছু।


1
আপনি কি পুনরায় প্রশ্নটি পুনঃস্থাপন করতে পারেন যাতে এটি অন্যদের উপর যথাযথ প্রমাণ দ্বারা সমর্থিত উত্তরগুলিকে উত্সাহ দেয়?
রাফেল

@ রাফেল আমি এগিয়ে গিয়ে সম্পাদনা করেছি। আমি মনে করি আমার সম্পাদনা মূলত প্রশ্নের অর্থ পরিবর্তন করে না, তবে এটিকে মতামতের অংশগুলিকে কম আমন্ত্রণ জানায়।
গিলস

1
বিশেষ করে, আমি আপনি কি মনে করেন প্রয়োজন এক (বা কয়েক) কংক্রিট কর্মক্ষমতা ব্যবস্থা ঠিক করতে। রানটাইম? স্থান ব্যবহার? শক্তি ব্যবহার? বিকাশকারী সময়? বিনিয়োগ ফেরত? আমাদের মেটাতে এই প্রশ্নটিও নোট করুন যা এই প্রশ্নটি (বা এর উত্তরগুলি) সম্পর্কিত।
রাফেল

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

Dynচ্ছিক প্রকারের টীকাগুলি (যেমন: ক্লোজার) মঞ্জুরিপ্রাপ্ত গতিশীল ভাষা রয়েছে। আমি যা জানি টাইপ-এনোটেটেড ফাংশনগুলির সাথে সম্পর্কিত পারফরম্যান্স কখন কোনও ভাষা স্ট্যাটিকালি টাইপ করা হত তার সমতুল্য।
পেড্রো মুর্তে রোলো

উত্তর:


68

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

কোস (খুব কার্যকর) পয়েন্টটি দিয়েছিলেন যে ডায়নামিক ভাষাগুলি রানটাইমের সময় সিস্টেম সম্পর্কে আরও তথ্য রয়েছে যা কোডটি অনুকূলিত করতে ব্যবহার করা যেতে পারে।

তবে মুদ্রার আরেকটি দিক রয়েছে: এই অতিরিক্ত তথ্যের উপর নজর রাখা দরকার। আধুনিক স্থাপত্যগুলিতে এটি একটি পারফরম্যান্স কিলার।

উইলিয়াম এডওয়ার্ডস যুক্তিটির একটি সুন্দর ওভারভিউ দেয়

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

উইলিয়াম কয়েকটি আকর্ষণীয় আইবিএম স্লাইড উদ্ধৃত করেছেন :

  • প্রতিটি পরিবর্তনশীল গতিশীল টাইপ করা যেতে পারে: টাইপ চেক প্রয়োজন
  • প্রতিটি বিবৃতিটি অমিল টাইপ এবং এই জাতীয় কারণে ব্যতিক্রমগুলি ছুঁড়ে ফেলতে পারে: ব্যতিক্রম চেকগুলির প্রয়োজন
  • প্রতিটি ক্ষেত্র এবং প্রতীক যোগ সময়, মুছে ফেলা এবং রানটাইম সময়ে পরিবর্তন করা যেতে পারে: অ্যাক্সেস চেক প্রয়োজন
  • প্রতিটি বস্তুর ধরণ এবং শ্রেণীর শ্রেণিবিন্যাস রানটাইমের সময় পরিবর্তিত হতে পারে: শ্রেণি শ্রেণিবিন্যাসের চেকগুলির প্রয়োজন

কিছু ঐ চেক বিশ্লেষণ পরে কাটানো যেতে পারে (বিশেষ দ্রষ্টব্য: এই বিশ্লেষণ এছাড়াও সময় লাগে - রানটাইম এ)।

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

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

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

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


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

1
@ রাফেল মূল শব্দটি: সম্ভবত। এটি এটি কোনওভাবে দেখায় না। আমি কেবল এটিই বলতে চেয়েছিলাম। পূর্ববর্তী অনুচ্ছেদে আমার অনুমানের কারণগুলি (তবে কোনও প্রমাণ নেই) দিয়েছি।
কনরাড রুডল্ফ

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

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

3
বিজ্ঞপ্তি: এই মন্তব্য-থ্রেডটি একটি মিনি আড্ডায় পরিণত হচ্ছে। আপনি যদি এই আলোচনা চালিয়ে যেতে চান তবে দয়া করে এটি আড্ডায় আনুন। মন্তব্যগুলি মূল পোস্টটি উন্নত করতে ব্যবহার করা উচিত। দয়া করে এখানে এই কথোপকথনটি বন্ধ করুন। ধন্যবাদ।
রবার্ট Cartaino

20

আপনি যদি পারফরম্যান্স ওয়াইয়ের সাথে সি / সি ++ এক্স করতে পারেন, আপনি কি রুবি / পাইথনে এক্স এর সাথে পারফরম্যান্স করতে পারেন?

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

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

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

অতিরিক্তভাবে, পিআইপি / রুবিনিয়াসের মতো জেআইটি সংকলকগুলি কি সি / সি ++ এর সাথে পারফরম্যান্সে মিলবে?

নাহ।

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

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


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

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

@ বেন: একবার আপনার RPYthon হয়ে গেলে, RPYthon সংকলক ব্যর্থ হয়ে সিপিথন ইন্টারপ্রেটার ব্যবহার করে ফিরে আসে এমন একটি সংকলক / ইন্টারপ্রেটার তৈরি করা তুচ্ছ, সুতরাং "পাইথন কোডের কেবলমাত্র একটি উপসেটই ভাল করতে পারে: ..." সম্পূর্ণ নির্ভুল।
মিথ্যা রায়ান

9
@ রাফেল এটি অনেকবার দেখানো হয়েছে যে ভালভাবে সি ++ কোড জাভা প্রকাশ করে। এটি "ভাল লেখা" অংশ যা সি ++ এ পাওয়া বেশ খানিকটা শক্ত, তাই অনেকগুলি বেঞ্চে আপনি ফলাফলগুলি দেখেন যে জাভা সি ++ ছাড়িয়েছে। সি ++, অতএব, আরও ব্যয়বহুল, তবে যখন টাইট মেম কন্ট্রোল এবং মেটাল গ্রিটের দরকার হয় তখন সি / সি ++ আপনার দিকে ফিরে আসে। বিশেষত সি কেবল এসি / পি এসেইম্বেলার।
টিসি 1

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

18

সংক্ষিপ্ত উত্তরটি: আমরা জানি না , 100 বছরে আবার জিজ্ঞাসা করুন। (আমরা তখনও জানি না; সম্ভবত আমরা কখনই জানতে পারব না))

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

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

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

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

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

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

উচ্চ-স্তরের ভাষার পক্ষে একটি যুক্তি হ'ল আধুনিক সিস্টেমে পারফরম্যান্স কার্যকরভাবে পরিচালিত নির্দেশাবলীর সংখ্যার সাথে এতটা দৃ corre়ভাবে সম্পর্কযুক্ত নয় এবং সময়ের সাথে কম less নিম্ন-স্তরের ভাষাগুলি সহজ ক্রমযুক্ত মেশিনগুলির জন্য ভাল মিল matches উচ্চ স্তরের ভাষা যদি দ্বিগুণ নির্দেশাবলীর দ্বারাই কার্যকর করে তবে ক্যাশে আরও বুদ্ধিমানের সাথে পরিচালনা করতে পরিচালিত করে যাতে এটি যত ক্যাশে মিস করে তার অর্ধেক করে দেয়, এটি বিজয়ীর অবসান ঘটাতে পারে।

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

সব মিলিয়ে উচ্চ-স্তরের ভাষাগুলি একটি জরিমানা দিয়ে শুরু হওয়ার সাথে সাথে তাদের উন্নতির আরও জায়গা রয়েছে। তারা কত কাছাকাছি পেতে পারেন? 100 বছর পরে আবার জিজ্ঞাসা করুন।

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


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

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

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

@ কনরাড রুডল্ফ যদি অনুমান করতে চান তবে আমি সফটওয়্যার ইঞ্জিনিয়ারিংয়ের বিষয়ে জিজ্ঞাসা করব ।
গিলস

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

10

সি ++ বিবৃতি মধ্যে মৌলিক পার্থক্য x = a + bএবং পাইথন বিবৃতি x = a + bযে একটি সি / সি ++ কম্পাইলার এই বিবৃতি থেকে বলতে পারেন (এবং সামান্য অতিরিক্ত তথ্য এটি ধরনের সম্পর্কে সহজলভ্য হয়েছে x, aএবং b) অবিকল কি মেশিন কোড মৃত্যুদন্ড কার্যকর করা প্রয়োজন । পাইথন স্টেটমেন্টটি কী অপারেশনগুলি চালাচ্ছে তা বলার জন্য আপনাকে হ্যালটিং সমস্যাটি সমাধান করতে হবে।

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

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

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

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

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

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


1
এটি এখন কোনও মন্তব্য ছাড়াই দুটি ডাউন-ভোট। আমি কিভাবে এই উত্তর উন্নতি করতে পরামর্শ স্বাগত জানাতে হবে!
বেন

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

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

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

@ মিকেয়া আমি মনে করি আপনি সম্ভবত পয়েন্টটি মিস করছেন। x + yদক্ষ মেশিন সংযোজন ক্রিয়াকলাপগুলিতে সংকলন করার জন্য , আপনাকে এটি সংকলন করার সময় তা জানতে হবে এবং তা নয়। সব সময় , না শুধুমাত্র কিছু সময়। গতিশীল ভাষার জন্য বাস্তববাদী প্রোগ্রামগুলির সাথে এটি প্রায়শই সম্ভব নয়, যদিও যুক্তিসঙ্গত হিউরিস্টিক্স বেশিরভাগ সময় সঠিকভাবে অনুমান করতে পারে। সংকলনের জন্য সংকলন-সময়ের গ্যারান্টি দরকার । সুতরাং "অনেক পরিস্থিতিতে" কথা বলার মাধ্যমে আপনি আসলে আমার উত্তরটি মোটেও সম্বোধন করছেন না।
বেন

9

গতিশীল ভাষাগুলির জন্য সবচেয়ে খারাপ পরিস্থিতিটির রূপরেখার মাত্র একটি দ্রুত পয়েন্টার:

পার্ল পার্সিং গণনাযোগ্য নয়

ফলস্বরূপ, (পূর্ণ) পার্ল কখনও স্থিতিশীলভাবে সংকলিত হতে পারে না


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

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


5

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

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

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

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

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

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

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


এটি পুনরায় পড়ার পরে, আমি এটি সত্য বলে মনে করি না। জেআইটি সংকলন আপনার যুক্তি ভঙ্গ করে। এমনকি সবচেয়ে সহজ কোড, উদাঃ main(args) { for ( i=0; i<1000000; i++ ) { if ( args[0] == "1" ) {...} else {...} }করতে উল্লেখযোগ্যভাবে আপ sped একবার মান argsপরিচিত হয় (এটা অভিমানী পরিবর্তন কখনই, যা আমরা জাহির করতে সক্ষম হতে পারে)। একটি স্থিতিশীল সংকলক এমন কোড তৈরি করতে পারে না যা তুলনাকে কখনও ড্রপ করে। (অবশ্যই, সেই উদাহরণে আপনি কেবল লুপটির ifবাইরে টানুন But তবে জিনিসটি আরও জটিল আকার ধারণ করতে পারে))
রাফেল

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

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

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

তবে আপনি পার্থক্য নির্ধারণ করতে পারেন । একটি বৈকল্পিক প্রসেসরের অপরিবর্তিত (সি) হাতে হাতে কোডটি প্রেরণ করে, অন্যটি রানটাইমের সময়ে (রুবি, জাভা, ...) সংকলন করে। প্রথমটি আমরা "স্থিতিশীল সংকলন" বলতে যা বোঝি, তারপরের অংশটি "ঠিক সময়ের সংকলন" (যা ডেটা নির্ভর নির্ভর অপটিমাইজেশনকে মঞ্জুরি দেয়)।
রাফেল

4

আপনি কি রুবির মতো গতিশীল ভাষার জন্য সি / সি ++ এর সাথে তুলনামূলক পারফরম্যান্স তৈরি করতে কম্পাইলার তৈরি করতে পারেন?

আমি মনে করি যে উত্তরটি "হ্যাঁ" । আমি আরও বিশ্বাস করি যে তারা দক্ষতার দিক থেকে (এমনকি সামান্য হলেও) বর্তমান সি / সি ++ আর্কিটেকচারকেও ছাড়িয়ে যেতে পারে believe

কারণটি সহজ: রান-টাইমে সংকলন-সময়ের চেয়ে বেশি তথ্য রয়েছে।

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

দেখুন ডায়নামিক ভাষাসমূহ স্ট্রাইক পিছনে , Google এর স্টিভ Yegge দ্বারা একটি বক্তৃতা (এছাড়াও আছে একটি ভিডিও সংস্করণ কোথাও আমি বিশ্বাস করি)। তিনি ভি 8 থেকে কংক্রিট জেআইটি অপ্টিমাইজেশান কৌশলগুলির উল্লেখ করেছেন। দীপক!

আমি আগামী 5 বছরের মধ্যে যা যাব তার প্রতীক্ষায় আছি!


2
আমি আশাবাদকে ভালবাসি।
ডেভ ক্লার্ক

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

1
@ ডেভ ক্লার্ক এটাই আমাকে চালিয়ে রেখেছে :)
কোস

2

যে সমস্ত লোক আপাতদৃষ্টিতে এটি তাত্ত্বিকভাবে সম্ভব বলে মনে করেন বা ভবিষ্যতে ভবিষ্যতে, তারা আমার মতে সম্পূর্ণ ভুল। মূল বিষয়টি সত্য যে গতিশীল ভাষাগুলি একটি সম্পূর্ণ ভিন্ন প্রোগ্রামিং শৈলী সরবরাহ করে এবং চাপিয়ে দেয় in প্রকৃতপক্ষে, পার্থক্যটি দ্বিগুণ, এমনকি যদি উভয় দিকই আন্তঃসম্পর্কিত হয়:

  • সিম্বলগুলি (vars, বা বরং id <>> সব ধরণের ডেটাম বাইন্ডিংস) টাইপযুক্ত নয়।
  • কাঠামোগুলি (ডেটা, রানটাইমের সময় যা কিছু থাকে) সমস্ত উপাদানগুলি টাইপ করা হয় না।

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

L

  • ElementLL
  • সমস্ত চিহ্নগুলি সেই ধরণের হয় Element, তারা কোনও উপাদান রাখতে পারেL
  • সমস্ত কাঠামো (আবার, মডেল রুটিন সহ) কেবলমাত্র এলিমেন্টের গ্রহণ করে

এটা আমার পক্ষে পরিষ্কার যে এটি কেবল একটি বিশাল পারফরম্যান্স; এবং আমি এমনকি সমস্ত পোস্ট (প্রোগ্রামের সংবেদনশীলতা নিশ্চিত করার জন্য প্রয়োজনীয় সকল প্রকারের রানটাইম চেকগুলির অগণিত) স্পর্শ করি না other


+1 খুব আকর্ষণীয়। আপনি আমার উত্তর পড়েছেন? আপনার এবং আমার চিন্তাভাবনা একই রকম মনে হচ্ছে যদিও আপনার উত্তরটি আরও বিশদ এবং আকর্ষণীয় দৃষ্টিকোণ সরবরাহ করে।
প্যাট্রিক 87

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

@ প্যাট্রিক ৮87: আপনারা ঠিক বলেছেন, আমাদের চিন্তার রেখাগুলি একই রকম মনে হয় (আগে পড়েনি, দুঃখিত, আমার প্রতিচ্ছবি বর্তমানে সি-তে ডিন ল্যাং বাস্তবায়নের মাধ্যমে এসেছে))
স্পিরিট

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

1

আমার কাছে সমস্ত উত্তর বিস্তারিতভাবে পড়ার সময় নেই ... তবে আমি আনন্দিত হয়েছিলাম।

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

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

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

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

কোনও ভাষার স্থির টাইপিং না থাকার বিষয়টি কখনই বোঝায় না যে সেই ভাষায় লেখা প্রোগ্রামগুলি স্থিরভাবে টাইপ করা হয় না। অন্যদিকে এটি হতে পারে যে কোনও টাইপ সিস্টেম একটি প্রোগ্রাম ব্যবহার করে তা বর্তমানে উপস্থিত টাইপ চেকারের পক্ষে পর্যাপ্ত আনুষ্ঠানিকভাবে না হয়ে যায়।

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

এবং এই বক্তব্যটি সম্পর্কে আরও মন্তব্য করতে যে Perl parsing is not computable, এই বাক্যটি যা বোঝায়, এমএল এর সাথেও একই সমস্যা রয়েছে, যা একটি উল্লেখযোগ্যভাবে সুনির্দিষ্টভাবে আনুষ্ঠানিক ভাষা। Type checking complexity in ML is a double exponential in the lenght of the program.সবচেয়ে খারাপ ক্ষেত্রে জটিলতার জন্য এটি একটি খুব সুনির্দিষ্ট এবং আনুষ্ঠানিক ফলাফল ... যা মোটেই গুরুত্বপূর্ণ নয়। আফাক, এমএল ব্যবহারকারীরা এখনও এমন একটি বাস্তব প্রোগ্রামের জন্য অপেক্ষা করছেন যা ধরণের পরীক্ষকটি বিস্ফোরিত হবে।

অনেক ক্ষেত্রে, আগের মতো, মানব সময় এবং দক্ষতা কম্পিউটিং পাওয়ার চেয়ে কম scar

ভবিষ্যতের আসল সমস্যাটি হ'ল যে সমস্ত লিগ্যাসি সফ্টওয়্যার এখনও ব্যবহৃত হয় তা পুনরায় লিখিত না করেই নতুন জ্ঞান, নতুন প্রোগ্রামিং ফর্মগুলিকে একীভূত করতে আমাদের ভাষাগুলি বিকশিত করা।

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

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


0

কয়েকটি নোট:

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

  • গতিশীল ভাষার জন্য সময়ের-সংকলকগুলির উচ্চতর বিকল্পগুলি বিদ্যমান। ভাল লিস্প বাস্তবায়ন সমতুল্য সি এর অর্ধেক গতিতে পৌঁছে

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

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


এ কেমন উত্তর? ভাল, বুলেট তিনটি হতে পারে, যদি আপনি উল্লেখগুলি যুক্ত করেন।
রাফেল

আমি দাবিটি সম্পর্কে খুব সন্দেহবাদী যে পিজিও সাধারণ কাজের চাপের অধীনে ওয়েব অ্যাপ্লিকেশন কোডের জন্য লুয়াজিআইটির পারফরম্যান্সের সাথে মেলে না।
কনরাড রুডল্ফ

@ কনরাডরুডল্ফ একটি জেআইটির মূল সুবিধাটি হ'ল বিভিন্ন পথগুলি উত্তপ্ত হওয়ার সাথে সাথে জেআইটি কোডটি অ্যাডাপ্ট করে।
ডেমি

@ ডিমেট্রি আমি এটি জানি। তবে এটি কোনও সুবিধা কিনা তা নির্ধারণ করা খুব কঠিন - আমার উত্তর এবং মন্তব্যটির আলোচনাটি এখানে দেখুন। সংক্ষেপে: জেআইটি ব্যবহারের পরিবর্তনের জন্য মানিয়ে নিতে পারে, রানটাইমের সময়ও এটি স্টাফ ট্র্যাক করতে হবে যা একটি ওভারহেড দেয়। বিরতি এমনকি এটি স্বজ্ঞাতভাবে কেবল তখনই আচরণের ক্ষেত্রে ঘন পরিবর্তন ঘটে। ওয়েব অ্যাপ্লিকেশনগুলির জন্য, কেবলমাত্র একটি একক (বা খুব কম) ব্যবহারের প্যাটার্ন রয়েছে যার জন্য অপ্টিমাইজেশন অর্থ প্রদান করে, সুতরাং অভিযোজনযোগ্যতার কারণে ন্যূনতম কর্মক্ষমতা বৃদ্ধি ক্রমাগত প্রোফাইলিংয়ের ওভারহেডকে অফসেট করে না।
কনরাড রুডল্ফ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.