কেন স্কালাকে সি বা সি ++ দিয়ে প্রয়োগ করা হয়নি


28

কেউ কি জানেন যে স্ক্যালাকে জাভা এবং সি নেট বা সি ++ এর পরিবর্তে .NET এ প্রয়োগ করা হয়েছিল কেন? বেশিরভাগ ভাষাগুলি Cor C ++ দিয়ে প্রয়োগ করা হয় [অর্থাত এরলং, পাইথন, পিএইচপি, রুবি, পার্ল]। জাভা এবং .NET লাইব্রেরিতে অ্যাক্সেস দেওয়া ছাড়াও জাভা এবং .NET এ প্রয়োগ করা স্কালার জন্য কী কী সুবিধা রয়েছে?

হালনাগাদ

স্কেল যদি সি তে প্রয়োগ করা হয় তবে এটি আরও বেশি উপকৃত হবে না কারণ এটি জেভিএমের উপর নির্ভর করার চেয়ে আরও ভালভাবে সুর করা যেতে পারে?


18
এছাড়াও, বিদ্যমান জাভা লাইব্রেরিগুলি ব্যবহার করতে সক্ষম হওয়া এবং জাভা কোডের সাথে দৃly়ভাবে আন্তঃচালিত হওয়া একটি বিশাল সুবিধা, কোনও সামান্য জিনিস নয়।
ট্যামস সেজেলি

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

8
@ চি, কেবল এটি স্বীকার করুন, জাভা সি এর চেয়েও ধীর গতির
জোশুয়া পার্টোগি

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

4
স্কালার রানটাইম পরিবেশটি একটি সি ++ প্রোগ্রাম; জেভিএম
মাইকে 30

উত্তর:


59

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

জিজ্ঞাসা করা প্রশ্নের উত্তর:

স্ক্যালাকে সি বা সি ++ তে প্রয়োগ করা হয়নি কারণ স্কেলা, এটি যে ভাষাতে বাস্তবে প্রয়োগ করা হয়, এটি অনেক ভাল ভাষা।

কেন এটা ভাল? ঠিক আছে, স্কেলা ভাষার জন্য ওডারস্কির লক্ষ্যগুলি সম্পর্কে পড়ুন ।

উদ্দেশ্যে করা হতে পারে এমন প্রশ্নের উত্তর:

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

আমাকে সেই শেষ জিনিসটি পুনরাবৃত্তি করতে দিন: JVM যে কোডটি চলছে তাতে মেশিন কোড হট স্পটগুলিতে সংকলন করবে । এটি সি এবং সি ++ সংকলকগুলির মতোই সংকলন করে।

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

যে প্রশ্নটি / জিজ্ঞাসা করা উচিত ছিল তার উত্তর:

মেশিন কোডে সংকলন জেভিএম বাইকোডে সংকলনের চেয়ে পর্যাপ্ত সুবিধা সরবরাহ করে না।

সিভি বা সি ++ এ জাইভিএম-সমতুলকে পরাজিত করে অবশ্যই মাইক্রোব্যাঙ্কমার্কগুলি তৈরি করা সম্ভব। এটিও সত্য যে সি বা সি ++ এর মধ্যে অত্যন্ত অপ্টিমাইজড কোড জাভা বা স্কালায় অত্যন্ত অনুকূলিত কোডকে পরাজিত করবে। পার্থক্যটি এত দীর্ঘ নয়, দীর্ঘকালীন প্রোগ্রামের জন্য।

নোট করুন যে স্কালাল স্পষ্টভাবে একটি ভাল স্ক্রিপ্টিং ভাষা নয় কারণ স্বল্প-চলমান প্রোগ্রামগুলির জন্য ওভারহেড খুব বড়।

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

সুতরাং, প্রশ্নটি স্কেলার সংকলকটি একটি মেশিন কোড এক্সিকিউটেবল হওয়া বা স্কালার প্রোগ্রামগুলি মেশিন কোড হওয়ার বিষয়ে কিনা , সম্ভাব্য গতি লাভগুলি অগত্যা সত্যিকারের গতি লাভে অনুবাদ করে না ।

এবং উপায় দ্বারা,

আমি আপনাকে একটি পাল্টা উদাহরণ দেব: হাস্কেল। হাস্কেল মেশিন কোড উত্পন্ন করে এবং তবুও, হাস্কেল প্রোগ্রামগুলি স্কালার চেয়ে ডেবিয়ানের শ্যুটআউটে আরও খারাপ। এটি দেওয়া, যে কেউ নিশ্চিত হতে পারে যে সরাসরি মেশিন কোডে সংকলন করা হলে স্কালার প্রোগ্রামগুলি আরও দ্রুত হবে?


3
@ মাইকে 30 স্কেলা যে কোনও জেভিএম-তে চালিত হবে, এমনকি এটি সি ++ তে না লেখা থাকলেও সেই যুক্তিটি ধরে রাখে না। এবং চলমান সময়ে, কোনও সি ++ কোড নেই, কেবল মেশিন কোড। যদিও এই মন্তব্যটি সম্পর্কে আমি নিশ্চিত না।
ড্যানিয়েল সি সোব্রাল

3
আসল কথাটি হ'ল: মেশিন কোড তৈরি করা বাইট-কোড উত্পন্ন করার চেয়ে জটিল and ...)। সুতরাং এইভাবে এই দিকটি জেভিএমের প্রতিনিধি।
রাফায়েলো

2
আপনি যদি মৃত্যুদন্ড কার্যকর করার বিষয়ে এত কথা বলেন, তবে কেন আপনি মেমরির পারফরম্যান্স সম্পর্কে কথা বলেন না? আপনি কী ভেবে দেখেছেন যে জিনিসগুলি যেমন কল্পনা করা যায় না তেমন বেরিয়ে আসে?
luke1985

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

3
@ lukasz1985 আপনার একমাত্র প্রমাণ যা আমি বুঝতে পারি না তা হ'ল আমি আপনার সাথে একমত নই। তার বিকল্প ব্যাখ্যা হ'ল আপনি ভুল are এবং, জীবিত এবং "তত্কালে" প্রোগ্রামিং হিসাবে, আমার সমসাময়িক বিকল্পগুলির তুলনায় সি এবং সি ++ বাছাইয়ের সাথে জড়িত সিদ্ধান্ত গ্রহণের বিষয়ে আমার প্রথম দৃষ্টিভঙ্গি রয়েছে, যা আমি আমার বক্তব্য প্রমাণ করার জন্য নয়, বরং আপনার প্রতিরূপ হিসাবে প্রস্তাব করার জন্য উল্লেখ করেছি: মিল কথ্য ভাষার সাথে কোনওভাবেই প্রাসঙ্গিক ছিল না, যেখানে মেশিন কোডের সাথে সাদৃশ্য ছিল।
ড্যানিয়েল সি সোব্রাল

31

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

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

এটি সি ++ এর সাথে আরও খারাপ হয়। সি ++ একই প্ল্যাটফর্মের (!) সংকলক থেকে অন্য ভাষার সাথে উল্লেখ না করে সি ++ (বাইনারি স্তরে, মানে) এর সাথে সামঞ্জস্যপূর্ণও নয়।

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

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

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

সিএলআর অনুরূপ শক্তি সরবরাহ করে, তবে আইএমও একটি দুর্বলতা যা যুক্ত করে: এটি একজন বিক্রেতার লক-ইন পরিবেশ। (হ্যাঁ আমি মনো সম্পর্কে জানি I এখনও আমি মনে করি এটি কোনও বিক্রেতা লক-ইন পরিবেশ।


3
আপনি বুঝতে পারেন যে সি # এবং সিএলআর আসলে যে কোনও ব্যবহার করতে পারেন এটি একটি মুক্ত মান।
এরিন

7
আমি যেখানে "মনো সম্পর্কে জানি" এবং তারপরে "এখনও মনে হয় এটি কোনও বিক্রেতা লক-ইন পরিবেশ" সম্পর্কে কিছুটা মনে হয় সেখানে ইরিন আপনাকে কিছুটা ক্লু দেবে।
আমার সঠিক মতামতটি

3
@ এরিট .NET ফ্রেমওয়ার্কের সমস্তই নয়
বিকল্পটি

1
@ বিকল্প: যদি এটি খুব বেশি লোককিন হয় তবে বিবেচনা করুন যে জাভা কনফরমেন্স পরীক্ষাগুলি এখনও নিখরচায় নয় এবং এটি জাভার জন্য অন্যরকম একটির মধ্যে সেরা 6, অন্যর মতো অর্ধ ডজন।
Deduplicator

18

এই সাক্ষাত্কার অনুসারে , বিদ্যমান জাভা অবকাঠামো এবং গ্রন্থাগারগুলিতে অ্যাক্সেসের প্রাথমিক কারণ ছিল।

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

সুতরাং আমি স্থির করেছিলাম যে আমি জাভা থেকে আলাদা একটি ভাষা ডিজাইন করতে চাইলেও এটি জাভা অবকাঠামো - জেভিএম এবং এর লাইব্রেরির সাথে সর্বদা সংযুক্ত হবে । এই ধারণা ছিল ...


10

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

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


2
বর্ণিত সুবিধাগুলি হ'ল কয়েকটি কারণ যা উদাহরণস্বরূপ পাইথনকে জেভিএম (জাইথন) এবং। নেট (আয়রন পাইথন) উভয়ই পুনরায় প্রয়োগ করা হয়েছে।
নৃত্য করুন

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

1
এবং পিএইচপি এমনকি JVM বা। নেট উপর যা করে তা করতে সক্ষম হয় না। @ ডিন হার্ডিং> আমি মনে করি না আয়রন পাইথন বা জাইথন ​​কোনও মূল্যবোধ প্রমাণ করেছিল prove
ক্লাইম

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

2
ছোট সংশোধন: জাভা পিএইচপি এর চেয়ে পুরানো। তবে পিএইচপি সিজিআই প্রোগ্রাম হিসাবে শুরু হয়েছিল, পরে অ্যাপাচি পোস্টডি মডিউল হয়ে যায় এবং এটি বড় হয়ে ওঠে। উভয় জিনিস (সিজি এবং httpd মডিউল) জাভার পক্ষে ভাল কাজ করে না। সুতরাং জিনিসগুলি এত সহজ নয়, একটি জেভিএম প্রতিটি কিছুর জন্য প্ল্যাটফর্ম নয়। ;-)
জোহানেস

6

সি কোডটি স্থিতিশীলভাবে দেশীয় কোডে (মেশিন কোড) সংকলিত হয় ।

স্কালাটি স্থিরভাবে জাভা বাইটকোডে সংকলিত হয় এবং তারপরে প্রয়োজনীয় হিসাবে, গতিশীলভাবে নেটিভ কোডটি অনুকূলিতকরণে সংকলিত হয়। প্রক্রিয়া:

স্কেল কোড --- স্ট্যাটিকালি-সংকলিত টু ---> জেভিএম বাইট কোড --- গতিশীলভাবে সংকলিত-জেভিএম-হটস্পট-থেকে ---> নেটিভ কোড

যে কোনও ভাষা তৈরি / চালানোর জন্য সাধারণ বিকল্পসমূহ:

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

আপনার প্রশ্ন: "জাভা কেন সি ইন্টারমিডিয়েট কোডের সাথে (খ) পরিবর্তে একটি জেভিএম দিয়ে (ডি) ব্যবহার করে?"

উত্তর:

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

  1. পারফরম্যান্স: উচ্চ স্তরের ভাষার জন্য (d) (ক) - (সি) এর চেয়ে দ্রুত পারফরম্যান্স দেয়।
    সরাসরি লিখিত এবং হ্যান্ড-অপ্টিমাইজড সি কোড দ্রুত। তবে, সি-তে স্ট্যাটিক্যালি সংকলিত উচ্চ-স্তরের ভাষা তুলনামূলকভাবে ধীর। জাভা ডিজাইনাররা এটি ভালভাবে জানতেন। তাদের বর্তমান "হটস্পট" ডিজাইনটি প্রস্থের ক্রম পর্যন্ত কর্মক্ষমতা বাড়িয়ে তোলে। একক কোরতে জাভা হটস্পট কোডটি মানব-অনুকূলিত সি হিসাবে গড়ে '50% তত দ্রুত '(সবচেয়ে ভাল ক্ষেত্রে এটি' 120% দ্রুত ', সবচেয়ে খারাপ ক্ষেত্রে '30% দ্রুত' হিসাবে)। তবে অবশ্যই এটি কমলাগুলির সাথে আপেলের সাথে তুলনা করে - নিম্ন স্তরের কোড ভি উচ্চ-স্তরের কোড। এবং যে অনেক হবেহটস্পট অপ্টিমাইজেশন ব্যবহার না করা হলে আরও খারাপ। নিশ্চিত করতে, কেবল জেভিএম আরগ্সের মাধ্যমে হটস্পট সংকলন অক্ষম করুন! বা জাভা 1 & 2 এর কার্যকারিতা বিবেচনা করুন, যখন হটস্পট উপস্থিত ছিল না বা অপরিণত ছিল। অথবা সি এর মাধ্যমে অন্য কোনও ভাষা সংকলনের চেষ্টা করুন - যেমন পার্লসিসি। সুতরাং উপরেরগুলি একটি শক্তিশালী এবং উত্পাদনশীল ভাষার জন্য দুর্দান্ত ফলাফল। আরও বিকাশের সাথে, এটি সম্ভব (বা এমনকি সম্ভবত) যে খুব শীঘ্রই জেভিএম হ্যান্ড-কোডেড সি-কে গড়ে গড়ে ফেলেছে ace স্ক্যালাল গড় হিসাবে জাভা হিসাবে স্রেফ 70-80% is তবে একাধিক কোর জুড়ে স্কেল দৃ strongly়ভাবে স্কেল করে (আরও উন্নতি অব্যাহত রাখার জন্য), যেখানে জাভা আংশিকভাবে কাজ করে এবং সি হয় না। এই জাতীয় উচ্চ স্তরের ভাষার জন্য একক কোর সম্পাদনা রেট দেওয়া হয়েছে:

    দোহিত <স্থিতিশীলভাবে সংকলিত <গতিশীল সংকলিত

    মাল্টি-কোর পারফরম্যান্স / স্কেলাবিলিটি রেট:

    দোলাযুক্ত গতিশীল কোড <স্ট্যাটিকালি সংকলিত আবশ্যক কোড <স্ট্যাটিকালি সংকলিত কার্যকরী / ঘোষিত কোড <গতিশীলভাবে সংকলিত কার্যকরী / ঘোষিত কোড

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

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

  3. বহনযোগ্যতা: জেভিএম কয়েক ডজন অপারেটিং সিস্টেম প্ল্যাটফর্ম / সংস্করণগুলিতে 'বাক্সের বাইরে' চলছে। এগুলি স্কেল স্বয়ংক্রিয়ভাবে পোর্ট করা হয়। উল্লেখযোগ্য ব্যতিক্রম হ'ল আইওএস (আইপ্যাড / আইফোন / আইপড) - অ্যাপল দ্বারা 'প্রযুক্তিগতভাবে' পরিবর্তে 'বাণিজ্যিকভাবে' অবরুদ্ধ। এটি জেভিএমের প্রাথমিক ডিজাইনের সময়, 12 বছর আগে অনুমান করা যায়নি। জেভিএম আরও কয়েক ডজন অন্যান্য সার্ভার, ডেস্কটপ, মোবাইল এবং এম্বেড থাকা ডিভাইসগুলিতে জরিমানা চালায়, যা সি সমর্থন করে না - গুগল অভিযোজিত ডালভিক ভিএম সহ অ্যান্ড্রয়েড সহ (নতুন ফোন বিক্রি হওয়া ৫০%)। অবশ্যই, সি কোড বহু সংখ্যক প্ল্যাটফর্মের উপর কাজ করে, তাই জাভা (সম্ভবত লক্ষ্য সি-এর উদ্দেশ্য-সি এর একটি উপসেট) এর সাথে 'উপরে বা সম্ভবত এটি ছাড়িয়ে' এখানে রেট দেওয়া যেতে পারে। তবে সি আসবে (1), (2) এবং (3)। অবশ্যই, আইওএসএল-এ এইচটিএমএল 5 / জাভাস্ক্রিপ্ট / ওয়েবকিট (বা উদ্দেশ্য-সি) উপস্থাপনা স্তর একটি রিমোট স্কেল অ্যাপ্লিকেশনটির সাথে আন্তঃক্রিয়া করতে পারে - তাই বিকাশকারীদের এটি করা উচিত। অবশ্যই, তারা কম উত্পাদনশীল হবে।

  4. সরঞ্জাম এবং গ্রন্থাগারগুলি : স্পষ্টতই হাজার হাজার বাণিজ্যিক এবং ওপেন সোর্স জাভা গ্রন্থাগার এবং সরঞ্জাম রয়েছে যা স্কালার মাধ্যমে লাভ / লাভ করতে পারে - সি এর চেয়ে বেশি more

  5. সুরক্ষা: - একটি নিয়ন্ত্রিত অ্যাপ সার্ভার বা জেভিএম পরিবেশে চলমান সুরক্ষা নীতি এবং বিধিনিষেধের জন্য দৃ for় সমর্থন দেয়, যা কর্পোরেট পরিবেশে অত্যন্ত মূল্যবান হতে পারে।


4

জেভিএম / সিএলআর

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

আমি যতদূর জানি, কেবলমাত্র স্কালার জেভিএম সংস্করণটি বর্তমান রাখা হচ্ছে, নেট সংস্করণটি নেই।


3

দেখে মনে হচ্ছে আপনি দুটি সম্পর্কযুক্ত জিনিস মিশ্রণ করছেন।

প্রথমটি হ'ল, স্কালার প্রয়োগের জন্য কোন প্রোগ্রামিংয়ের ভাষা স্কাল লেখক (গুলি) ব্যবহার করেছেন?

যার উত্তর, স্কেল নিজেই। এবং এটিই একমাত্র গ্রহণযোগ্য উত্তর, কারণ আপনি যদি এই নতুন ভাষাটি আবিষ্কার করেন তবে এটি প্রয়োগের জন্য নিজেই এটি ব্যবহার না করেন - এটি কী ভাল?

দ্বিতীয় বিষয়টি হল, স্কালায় লিখিত প্রোগ্রামগুলি চালানোর জন্য লক্ষ্য প্ল্যাটফর্মটি কী?

এখানে পছন্দটি আরও আকর্ষণীয় হয়ে ওঠে, তবে আপাতত, একমাত্র লক্ষ্য যা 100% কাজ করে তা হল জেভিএম। .NET- র জন্য সমর্থন এখনও চলছে। এছাড়াও কিছু লোক জাভাসক্রিপ্টে সংকলন করার জন্য স্কালার কাজ করার জন্য কাজ করছে। তত্ত্ব অনুসারে, কাউকে সি, সি ++, এলএলভিএম, নেটিভ কোড বা যে কোনও কিছুতে সংকলনের জন্য আরও 'ব্যাকেন্ডস' যুক্ত করতে বাধা দেয় না।

কেন জেভিএমকে প্রাথমিক প্ল্যাটফর্ম হিসাবে বেছে নেওয়া হয়েছিল? আমার অনুমান কারণ

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

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

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

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

0

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

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

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

এ কারণেই আমি ভাবতে পারি, তবে মনে রাখবেন যে অন্যান্য কারণ থাকতে পারে - যেমন লাইসেন্স দেওয়া এবং সেখানে জড়িত রাজনীতি (যা নোংরা জিনিস যা আমি কখনই getুকতে চাই না)।


-2

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


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