65 টি উপাদানের অ্যারে ঘোষণার চেয়ে 1000 গুণ দ্রুত গতিতে 64 টি উপাদান সহ একাধিক অ্যারে ঘোষণা করা


91

সম্প্রতি আমি লক্ষ্য করেছি যে 64৪ টি উপাদান সহ একই ধরণের অ্যারে ঘোষণার চেয়ে elements৪ টি উপাদান সমন্বিত একটি অ্যারে ঘোষণা করা অনেক দ্রুত (> 1000 গুণ) is

এটি পরীক্ষা করার জন্য আমি এখানে কোডটি ব্যবহার করেছি:

public class Tests{
    public static void main(String args[]){
        double start = System.nanoTime();
        int job = 100000000;//100 million
        for(int i = 0; i < job; i++){
            double[] test = new double[64];
        }
        double end = System.nanoTime();
        System.out.println("Total runtime = " + (end-start)/1000000 + " ms");
    }
}

এটি প্রায় 6 এমএসে চলে, আমি যদি এটির new double[64]সাথে প্রতিস্থাপন করি তবে new double[65]এটি প্রায় 7 সেকেন্ড সময় নেয়। কাজটি আরও বেশি করে থ্রেডে ছড়িয়ে পড়লে এই সমস্যাটি তাত্পর্যপূর্ণভাবে আরও তীব্র হয়ে উঠবে, যেখানে আমার সমস্যাটি উত্পন্ন হয়েছে।

এই সমস্যাটি বিভিন্ন ধরণের অ্যারে যেমন int[65]বা এর সাথেও ঘটে String[65]। এই সমস্যাটি বড় স্ট্রিংগুলির সাথে ঘটে না: String test = "many characters";তবে এটি পরিবর্তিত হলেই ঘটতে শুরু করেString test = i + "";

আমি ভাবছিলাম যে কেন এটি হল এবং যদি সম্ভব হয় তবে এই সমস্যাটি থেকে মুক্তি পাওয়া যায়।


4
অফ-নোট: বেঞ্চমার্কিংয়ের জন্য System.nanoTime()বেশি পছন্দ করা উচিত System.currentTimeMillis()
রকেটবয়

4
আমি কি শুধু কৌতূহলী? আপনি লিনাক্স অধীনে? ওএসের সাথে কি আচরণের পরিবর্তন হয়?
বিএসডি

9
কিভাবে পৃথিবীতে এই প্রশ্নটি একটি ডাউনভোট পেল ??
রোহিত জৈন

4
এফডব্লিউআইডাব্লু, আমি যদি এই কোডটি এর byteপরিবর্তে চালিত করি তবে আমি একই রকম পারফরম্যান্সের ত্রুটি দেখতে পাচ্ছি double
অলিভার চার্লসওয়ার্থ

4
@ থমাস জাংব্লুট: তাহলে ওপি'র পরীক্ষায় তফাতটি কী বোঝায়?
অলিভার চার্লসওয়ার্থ

উত্তর:


88

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

বিশদে যাওয়ার আগে, আসুন লুপের বডিটি ঘনিষ্ঠভাবে দেখে নেওয়া যাক:

double[] test = new double[64];

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

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

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

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

কমান্ড লাইন বিকল্পের সাহায্যে অপ্টিমাইজেশন অক্ষম করা যেতে পারে -XX:-DoEscapeAnalysis। স্কেলার অ্যারেগুলির ম্যাজিক মান 64 কমান্ড লাইনেও পরিবর্তন করা যেতে পারে। আপনি যদি আপনার প্রোগ্রামটি নিম্নলিখিতভাবে সম্পাদন করেন তবে 64৪ এবং elements 65 উপাদানগুলির সাথে অ্যারেগুলির মধ্যে কোনও পার্থক্য থাকবে না:

java -XX:EliminateAllocationArraySizeLimit=65 Tests

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


9
তবে কেন অপ্টিমাইজার সনাক্ত করছে যে
size৪

10
@ নোসিড: ওপির কোডটি বাস্তববাদী না হলেও, এটি স্পষ্টতই জেভিএমের মধ্যে একটি আকর্ষণীয় / অপ্রত্যাশিত আচরণের সূত্রপাত করছে, যার অন্যান্য পরিস্থিতিতেও এর প্রভাব থাকতে পারে। আমি কেন এটি ঘটছে তা জিজ্ঞাসা করা বৈধ বলে মনে করি।
অলিভার চার্লসওয়ার্থ

4
@ থমাস জাংব্লুট আমার মনে হয় না যে লুপটি সরানো হয়েছে। আপনি লুপের বাইরে "ইনট টোটাল" যুক্ত করতে এবং "মোট + = পরীক্ষা [0]" যোগ করতে পারেন; উপরের উদাহরণে। তারপরে ফলাফলটি মুদ্রণ করে আপনি দেখতে পাবেন যে মোট = 100 মিলিয়ন এবং এটি স্টল এক সেকেন্ডেরও কম সময়ে চলে।
সিপকো

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

4
@ সিপকো: আপনি লিখছেন যে অ্যাপ্লিকেশনটি থ্রেডের সংখ্যা দিয়ে স্কেল করছে না। এটি একটি ইঙ্গিত, যে সমস্যাটি আপনি যে মাইক্রো অপ্টিমাইজেশন সম্পর্কে জিজ্ঞাসা করছেন তার সাথে সম্পর্কিত নয়। আমি ছোট অংশগুলির পরিবর্তে বড় ছবি দেখার পরামর্শ দিই।
nosid

2

কোনও বস্তুর আকারের উপর ভিত্তি করে কোনও পার্থক্য থাকতে পারে এমন অনেকগুলি উপায় রয়েছে।

নোসিড অনুসারে, জেআইটিসি হয়ত স্ট্যাকের উপর ছোট "স্থানীয়" অবজেক্ট বরাদ্দ করতে পারে এবং "ছোট" অ্যারেগুলির জন্য আকারের কাট অফ off৪ টি উপাদান হতে পারে।

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

তদুপরি, মানটি স্ট্যাক-বরাদ্দের পরে জেআইটিসি "ডেড কোড নির্মূলকরণ" সম্পাদন করতে পারে, এটি নির্ধারণ করে যে এর ফলাফলটি newকোথাও কখনও ব্যবহার করা হবে না, এবং কোনও পার্শ্ব প্রতিক্রিয়া হারাতে হবে না বলে আশ্বাস দেওয়ার পরে, পুরো newঅপারেশনটি সরিয়ে ফেলুন, এবং তারপরে (এখন খালি) লুপ নিজেই।

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


এই সুত্রে দেরীতে। স্তূপে বরাদ্দ দেওয়ার চেয়ে স্ট্যাকের উপর বরাদ্দ কেন দ্রুত হয়? কয়েকটি নিবন্ধ অনুসারে, গাদাতে বরাদ্দ দিতে ~ 12 নির্দেশিকা লাগে। উন্নতির খুব বেশি জায়গা নেই।
ঘূর্ণি

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