System.nanoTime () কি সম্পূর্ণ অকেজো?

Question

হিসাবে ব্লগ পোস্টে নথিভুক্ত জাভা System.nanoTime () থেকে সাবধান , x86- র সিস্টেমে, জাভার System.nanoTime () একটি ব্যবহার করে সময় মান CPU- র নির্দিষ্ট কাউন্টার। কলটির সময় পরিমাপ করতে আমি নিম্নলিখিত কেসটি বিবেচনা করি:

long time1= System.nanoTime();
foo();
long time2 = System.nanoTime();
long timeSpent = time2-time1;

এখন একটি মাল্টি-কোর সিস্টেমে এটি হতে পারে যে টাইম 1 পরিমাপ করার পরে, থ্রেডটি একটি পৃথক প্রসেসরের সাথে নির্ধারিত হয়েছে যার কাউন্টারের পূর্ববর্তী সিপিইউর তুলনায় কম। সুতরাং আমরা সময় 2 এর চেয়ে একটি মান পেতে পারি যা সময় 1 এর চেয়ে কম হয় । সুতরাং আমরা টাইমস্পেন্ট একটি নেতিবাচক মান পেতে হবে।

এই কেসটি বিবেচনা করে, এখনই কি সিস্টেম.নোটোটাইমটি বেশ অযথা?

আমি জানি যে সিস্টেমের সময় পরিবর্তন ন্যানোটাইমকে প্রভাবিত করে না। আমি উপরে বর্ণিত সমস্যাটি নয়। সমস্যাটি হ'ল এটি চালু হওয়ার পর থেকে প্রতিটি সিপিইউ একটি আলাদা কাউন্টার রাখবে। এই কাউন্টারটি প্রথম সিপিইউয়ের তুলনায় দ্বিতীয় সিপিইউতে কম হতে পারে। যেহেতু টাইম 1 পাওয়ার পরে থ্রেডটি ওএস দ্বারা দ্বিতীয় সিপিইউতে নির্ধারিত করা যেতে পারে তাই টাইমস্পেন্টের মানটি ভুল এবং এমনকি নেতিবাচকও হতে পারে।

Comments

আমার কোন উত্তর নেই তবে আমি আপনার সাথে একমত। সম্ভবত এটি JVM- এ একটি বাগ হিসাবে বিবেচনা করা উচিত।

— অ্যারন দিগুল্লা

পোস্টটিটি ভুল এবং টিএসসি ব্যবহার না করা ধীর হলেও আপনার সাথে থাকতে হবে: বাগসসুন / বুগড্যাটবেস / ভিউ_বাগ.ডো? বুগ_আইডি=6440250 এছাড়াও টিএসসিকে হাইপারভাইজারের মাধ্যমে দরকারী করা যেতে পারে তবে এটি আবার ধীর হয় slow

— বেটসেস

এবং অবশ্যই, আপনি একটি ভার্চুয়াল মেশিনে চালাতে পারেন যেখানে একটি সিপিইউ একটি সেশনের মধ্য দিয়ে মাঝ পথে দেখাতে পারে: ডি

— সীমিত প্রায়শ্চিত্ত

Answer 1

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

পোস্টটি ভুল, এবং nanoTimeনিরাপদ। এই পোস্টে একটি মন্তব্য আছে যা সান-এর একজন রিয়েলটাইম এবং সম্মতিযুক্ত ডেভিড হোমসের ব্লগ পোস্টের সাথে লিঙ্ক করেছে which এটা বলে:

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

সুতরাং, উইন্ডোজ এ ছিল উইনএক্সপি এসপি 2 অবধি সমস্যাটি , তবে এখন তা নয়।

আমি এমন একটি অংশ II (বা আরও) খুঁজে পাচ্ছি না যা অন্যান্য প্ল্যাটফর্মের বিষয়ে কথা বলে, তবে এই নিবন্ধটিতে এমন একটি মন্তব্য অন্তর্ভুক্ত রয়েছে যা লিনাক্স একই সমস্যার সাথে একই সমস্যার সমাধান করেছে, এর লিঙ্ক সহ with ক্লক_জেটটাইম (CLOCK_REALTIME) এর জন্য FAQ- এর করেছে CL , যা বলে:

1. ক্লক_জেটটাইম (CLOCK_REALTIME) সমস্ত প্রসেসর / কোর জুড়ে সামঞ্জস্যপূর্ণ? (খিলানটি কী ব্যাপার? যেমন পিপিসি, আর্ম, x86, এএমডি 64, স্পার্ক)

এটা বা এটি বগী হিসাবে বিবেচনা করা উচিত ।

যাইহোক, x86 / x86_64 এ, অযৌক্তিক বা ভেরিয়েবল ফ্রিক টিএসসিগুলি সময়ের অসঙ্গতিগুলির কারণ দেখা সম্ভব। ২.৪ কার্নেলগুলির প্রকৃত পক্ষে এর বিরুদ্ধে কোনও সুরক্ষা ছিল না এবং প্রথমদিকে ২. ker কার্নেলগুলি এখানে খুব ভাল ব্যবহার করতে পারেনি। ২.6.১৮ এর হিসাবে এবং এটি সনাক্ত করার জন্য যুক্তিটি ভাল এবং আমরা সাধারণত কোনও নিরাপদ ক্লকসোর্সে ফিরে যেতে পারি।

পিপিসি সর্বদা একটি সিঙ্কড টাইমবেস থাকে, যাতে এটি কোনও সমস্যা না হয়।

সুতরাং, যদি হোমসের লিঙ্কটি সেই nanoTimeকলগুলি বোঝানো হিসাবে পড়তে পারে clock_gettime(CLOCK_REALTIME)তবে এটি x86 এর কার্নেল ২.6.১৮ হিসাবে নিরাপদ-ইশ এবং সর্বদা পাওয়ারপিসিতে থাকে (কারণ আইবিএম এবং মটোরোলা, ইন্টেলের বিপরীতে, আসলে মাইক্রোপ্রসেসারগুলি কীভাবে ডিজাইন করা যায় তা জানে)।

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

সম্পাদনা: এই উত্তরটি উত্স হিসাবে উত্সিত উপর ভিত্তি করে। তবে আমি এখনও চিন্তিত যে এটি আসলে সম্পূর্ণ ভুল হতে পারে। আরও কিছু আধুনিক তথ্য সত্যই মূল্যবান হবে really আমি লিনাক্সের ঘড়িগুলি সম্পর্কে চার বছরের নতুন নিবন্ধের লিঙ্কে পৌঁছেছি যা দরকারী হতে পারে।

Comments

এমনকি উইনএক্সপি এসপি 2 ক্ষতিগ্রস্থ বলে মনে হচ্ছে। আসল কোডের নমুনাটি চালানো সহ, void foo() { Thread.sleep(40); }আমি একটি একক Athlon 64 X2 4200+প্রসেসর ব্যবহার করে নেতিবাচক সময় পেয়েছি (-380 এমএস!)

— লু্ক উশরউড

আমি মনে করি না এই সম্পর্কে আপডেট হয়েছে, কব্জি। লিনাক্স, বিএসডি বা অন্যান্য প্ল্যাটফর্মে আচরণ?

— টোমর গ্যাবেল

উত্তম উত্তর, এই বিষয়টির আরও সাম্প্রতিক অন্বেষণের জন্য একটি লিঙ্ক যুক্ত করা উচিত: শিপিলিভ.নেট

— নিতসান ওয়াকার্ট

@ সাফ: ওহ, এটি লজ্জাজনক। ভাগ্যক্রমে এটি ওয়েব সংরক্ষণাগারে রয়েছে । আমি দেখতে পাচ্ছি যে আমি কোনও বর্তমান সংস্করণ ট্র্যাক করতে পারি কিনা।

— টম অ্যান্ডারসন

দ্রষ্টব্য: ওপেনজেডকে ওপেনজেডকে 8u192 অবধি এই বৈশিষ্ট্যটিকে ধরে রাখতে পারে না, দেখুন bugs.openjdk.java.net/browse/JDK-8184271 । ওপেনজেডকে 8, বা ওপেনজেডিকে 11+ এর কমপক্ষে নতুন সংস্করণ হিসাবে ব্যবহার নিশ্চিত করুন।

— লেভেন্টভ

Answer 2

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

পরীক্ষা করে দেখুন এই উদ্ধৃতি জাভা সূর্যের সাইট থেকে:

রিয়েল-টাইম ক্লক এবং System.nanoTime () উভয় একই সিস্টেম কল এবং এইভাবে একই ঘড়ির উপর ভিত্তি করে।

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

জাভাতেও ন্যানোটাইম () পদ্ধতির জন্য একটি সতর্কতা রয়েছে :

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

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

সুতরাং আপনার প্রশ্নের উত্তর দেওয়ার জন্য ... কোনও ন্যানোটাইম () অকেজো নয় .... এটি প্রতিটি পরিস্থিতিতে ব্যবহার করার জন্য সবচেয়ে বিচক্ষণ পদ্ধতি নয়।

Comments

> ফলাফল প্রাপ্ত ফেরতের মানটি নেতিবাচক হলেও এই পদ্ধতিটি যথেষ্ট ভাল। আমি এটি পাচ্ছি না, যদি টাইমস্প্যান্টের মানটি নেতিবাচক হয়, তবে foo () এ নেওয়া সময় মাপার ক্ষেত্রে এটি কীভাবে কার্যকর?

— pdeva

ঠিক আছে কারণ আপনি যে সমস্ত বিষয়ে উদ্বিগ্ন তা হ'ল পার্থক্যটির পরম মান। যেমন যদি আপনার পরিমাপটি টাইম টি যেখানে t = t2 - t1 থাকে তবে আপনি জানতে চান | t | .... তাই যদি মানটি নেতিবাচক হয় ... তবে মাল্টি কোর সমস্যার সাথেও প্রভাব খুব কমই ঘটতে চলেছে যাইহোক ন্যানোসেকেন্ডস।

— মেজয়েড

@ অ্যারনকে ব্যাকআপ দেওয়ার জন্য: টি 2 এবং টি 1 উভয়ই নেতিবাচক হতে পারে তবে (টি 2-টি 1) অবশ্যই নেতিবাচক হবে না।

— jfs

অ্যারন: আমার বক্তব্যটি ঠিক এটাই। t2-t1 কখনও নেতিবাচক হওয়া উচিত নয় অন্যথায় আমাদের একটি ত্রুটি রয়েছে।

— pdeva

@ পিদেবা - তবে ডক কী বলছেন তা আপনি ভুল বুঝে চলেছেন। আপনি একটি অ-ইস্যু উত্থাপন করছেন। কিছু সময় আছে যা "0" হিসাবে বিবেচিত হয়। ন্যানোটাইম () দ্বারা প্রত্যাবর্তিত মানগুলি সেই সময়ের সাথে সঠিক। এটি একঘেয়েভাবে বাড়ছে টাইমলাইন। আপনি সম্ভবত এই টাইমলাইনের নেতিবাচক অংশ থেকে একটি সিরিজ সংখ্যা পেয়ে যাচ্ছেন। -100, -99, -98(বাস্তবে স্পষ্টত অনেক বড় মান)। তারা সঠিক দিকে যাচ্ছে (বাড়ছে), সুতরাং এখানে কোনও সমস্যা নেই।

— টুলমেকারস্টেভ

Answer 3

বিতর্ক করার দরকার নেই, কেবল উত্সটি ব্যবহার করুন। এখানে, লিনাক্সের জন্য এসই 6, আপনার নিজের সিদ্ধান্তে নিন:

jlong os::javaTimeMillis() {
  timeval time;
  int status = gettimeofday(&time, NULL);
  assert(status != -1, "linux error");
  return jlong(time.tv_sec) * 1000  +  jlong(time.tv_usec / 1000);
}


jlong os::javaTimeNanos() {
  if (Linux::supports_monotonic_clock()) {
    struct timespec tp;
    int status = Linux::clock_gettime(CLOCK_MONOTONIC, &tp);
    assert(status == 0, "gettime error");
    jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec);
    return result;
  } else {
    timeval time;
    int status = gettimeofday(&time, NULL);
    assert(status != -1, "linux error");
    jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec);
    return 1000 * usecs;
  }
}

Comments

এটি কেবলমাত্র সহায়ক যদি আপনি জানেন যে ব্যবহৃত API কী করে does ব্যবহৃত এপিআই অপারেটিং সিস্টেম দ্বারা প্রয়োগ করা হয়; এই কোডটি সঠিক কব্জি ব্যবহৃত এপিআই'র স্পষ্টতা (ক্লক_জেটটাইম / গেটটাইম ডে), তবে অন্যরা যেমন উল্লেখ করেছে, কিছু অ-টু-ডেট অপারেটিং সিস্টেমে বগি বাস্তবায়ন রয়েছে।

— ব্লেজারব্ল্যাড

Answer 4

যেহেতু জাভা 7, System.nanoTime()জেডিকে স্পেসিফিকেশন দ্বারা নিরাপদ থাকার গ্যারান্টিযুক্ত। System.nanoTime()জাভাডোক এটি পরিষ্কার করে দিয়েছে যে একটি জেভিএম-এর মধ্যে সমস্ত পর্যবেক্ষণের আহবানগুলি (এটি, সমস্ত থ্রেড জুড়ে) একঘেয়ে রয়েছে:

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

জেভিএম / জেডিকে বাস্তবায়ন অন্তর্নিহিত ওএস ইউটিলিটিগুলি যখন ডাকা হয় তখন লক্ষ্য করা যায় যে অসঙ্গতিগুলি পর্যবেক্ষণের জন্য দায়ী (যেমন টম অ্যান্ডারসনের উত্তরে উল্লিখিত ) ।

এই প্রশ্নের অন্যান্য পুরানো উত্তরগুলির বেশিরভাগই (২০০৯-২০১২ সালে লিখিত) FUD প্রকাশ করে যা সম্ভবত জাভা 5 বা জাভা 6 এর জন্য প্রাসঙ্গিক ছিল তবে জাভার আধুনিক সংস্করণগুলির জন্য আর প্রাসঙ্গিক নয়।

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

এই কথাটি মাথায় রেখে, সময়যুক্ত ব্লকিং, ব্যবধান ওয়েটিং, টাইমআউট ইত্যাদির জন্য যে কোড ব্যবহার করে সেগুলি nanoTime()ব্যতিক্রম ছোঁড়ার পরিবর্তে negativeণাত্মক সময়ের পার্থক্য (টাইমআউটস )কে জিরো হিসাবে পছন্দ করবে। এই অনুশীলন এছাড়াও বাঞ্ছনীয়, কারণ এটি সব শ্রেণীর সব সুবিধানুযায়ী অপেক্ষার পদ্ধতির আচরণ সঙ্গে সামঞ্জস্যপূর্ণ java.util.concurrent.*, উদাহরণস্বরূপ Semaphore.tryAcquire(), Lock.tryLock(), BlockingQueue.poll(), ইত্যাদি

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

এর পরিবর্তে ব্যবহার করার nanoTime()সরাসরি কোড সঞ্চালনের সময় পরিমাপ জন্য, বিশেষ মাপকাঠিতে অবকাঠামো ও profilers বাঞ্ছনীয়, উদাহরণস্বরূপ ব্যবহার করা উচিত JMH এবং ASYNC-প্রোফাইলার মধ্যে দেওয়াল-ঘড়ি প্রোফাইলিং মোড ।

Answer 5

দাবি অস্বীকার: আমি এই লাইব্রেরির বিকাশকারী

আপনি এটি আরও ভাল পছন্দ করতে পারেন:

http://juliusdavies.ca/nanotime/

তবে এটি একটি ডিএলএল বা ইউনিক্স .so (ভাগ করা বস্তু) ফাইলটিকে বর্তমান ব্যবহারকারীর হোম ডিরেক্টরিতে অনুলিপি করে যাতে এটি জেএনআই কল করতে পারে।

কিছু ব্যাকগ্রাউন্ড তথ্য আমার সাইটে রয়েছে:

http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html

Comments

@ জুলিয়াস আপনি কি নিজের সাইট থেকে লাইব্রেরিটি সরিয়েছেন?

— নিতিন দান্দ্রিয়াল

Answer 6

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

Comments

আপনি একটি রেফারেন্স সরবরাহ করতে পারেন (লিনাক্স এবং উইন্ডোজ আচরণ)?

— jfs

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

— ড্যারেল টিগু

@ ড্যারেলটিগ সহ ১০০০ টি ইভেন্টের সংমিশ্রণ এবং এগুলি যুক্ত করা শেষের শেষের সমান।

— পিটার লরে

@ ড্যারেলটাইগ সিস্টেম.নানোটাইম () বেশিরভাগ সিস্টেমে 1 মাইক্রো-সেকেন্ড বা এর চেয়ে ভাল (100,000 মাইক্রোসেকেন্ড নয়) সঠিক। যখন আপনি কয়েকটি মাইক্রো-সেকেন্ডে নামেন, এবং কেবলমাত্র নির্দিষ্ট সিস্টেমে অনেকগুলি অপারেশন গড়ে গড়ে তোলা হয়।

— পিটার লরে

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

— ড্যারেল টিগু

Answer 7

একেবারে অকেজো নয়। আফিকোনাডোস সময়টি সঠিকভাবে মাল্টি-কোর সমস্যাটি নির্দেশ করে, তবে আসল-শব্দ প্রয়োগগুলিতে এটি প্রায়শই কারেন্টটাইমমিলিসের চেয়ে মূলগতভাবে ভাল better

ফ্রেমে গ্রাফিক্সের অবস্থানগুলি গণনা করার সময় ন্যানোটাইম () আমার প্রোগ্রামে খুব মসৃণ গতির দিকে পরিচালিত করে।

এবং আমি কেবল বহু-কোর মেশিনে পরীক্ষা করি।

Answer 8

আমি System.nanoTime () ব্যবহার করে রিপোর্ট করা একটি নেতিবাচক সময় অতিবাহিত দেখতে পেয়েছি। পরিষ্কার হয়ে উঠতে, প্রশ্নের মধ্যে কোডটি হ'ল:

    long startNanos = System.nanoTime();

    Object returnValue = joinPoint.proceed();

    long elapsedNanos = System.nanoTime() - startNanos;

এবং ভেরিয়েবল 'elapsedNanos' এর নেতিবাচক মান ছিল। (আমি ইতিবাচক যে মধ্যবর্তী কলটি 293 বছরেরও কম সময় নিয়েছিল, এটি দীর্ঘস্থায়ীভাবে সঞ্চিত ন্যানোসের ওভারফ্লো পয়েন্ট :)

আইআইবিএম পি 690 (মাল্টি-কোর) হার্ডওয়্যার এআইএক্স-তে একটি আইবিএম ভি 1.5 জেআরই 64 বিট ব্যবহার করে এটি ঘটেছিল। আমি এই ত্রুটিটি কেবল একবারই দেখেছি, তাই এটি অত্যন্ত বিরল বলে মনে হচ্ছে। আমি কারণটি জানি না - এটি কি একটি হার্ডওয়্যার-নির্দিষ্ট সমস্যা, একটি জেভিএম ত্রুটি - আমি জানি না। আমি সাধারণভাবে ন্যানোটাইম () এর নির্ভুলতার জন্য প্রভাবগুলিও জানি না।

মূল প্রশ্নের উত্তর দেওয়ার জন্য, আমি ন্যানোটাইমকে অকেজো বলে মনে করি না - এটি উপ-মিলিসেকেন্ড সময় সরবরাহ করে, তবে এটির সত্যিকারের (কেবল তাত্ত্বিক নয়) ঝুঁকি রয়েছে যা আপনার বিবেচনায় নেওয়া উচিত।

Comments

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

— ড্যারেল টিগু

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

— অবিরাম

Answer 9

এটি উইন্ডোজ এক্সপি এবং জেআরই 1.5.0_06 চলমান কোর 2 জুটির সমস্যা বলে মনে হচ্ছে না।

তিনটি থ্রেড সহ একটি পরীক্ষায় আমি System.nanoTime () পিছনে যেতে দেখছি না। প্রসেসর উভয়ই ব্যস্ত, এবং থ্রেডগুলি মাঝে মাঝে চলমান থ্রেডগুলিকে উস্কে দিতে মাঝে মাঝে ঘুমাতে যায়।

[সম্পাদনা] আমি অনুমান করব যে এটি কেবল শারীরিকভাবে পৃথক প্রসেসরের উপর ঘটে, অর্থাত্ কাউন্টারগুলি একই ডাইতে একাধিক কোরের জন্য সিঙ্ক্রোনাইজ হয়।

Comments

এটি সম্ভবত সর্বদা ঘটবে না, তবে ন্যানোটাইম () বাস্তবায়িত হওয়ার কারণে সম্ভাবনা সর্বদা থাকে।

— pdeva

আমি অনুমান করব যে এটি কেবল শারীরিকভাবে পৃথক প্রসেসরের উপর ঘটে, অর্থাত্ কাউন্টারগুলি একই ডাইতে একাধিক কোরের জন্য সিঙ্ক্রোনাইজ হয়।

— স্টার ব্লু

এমনকি এটি নির্দিষ্ট প্রয়োগের উপর নির্ভর করে, আইআইআরসি। তবে এটি ওএসের যত্ন নেওয়ার কথা take

— ব্লেসরব্ল্যাড

একই x86 প্রসেসরের একাধিক কোরের আরডিটিএসসি কাউন্টারগুলিকে অগত্যা সিঙ্ক্রোনাইজ করা হয় না - কিছু আধুনিক সিস্টেম বিভিন্ন কোরকে বিভিন্ন গতিতে চালিত করতে দেয়।

— জুলাই

Answer 10

না, এটি নয় ... এটি কেবলমাত্র আপনার সিপিইউর উপর নির্ভর করে, উচ্চ যথার্থ ইভেন্ট টাইমারটি পরীক্ষা করুন কীভাবে / কেন সিপিইউ অনুযায়ী জিনিসগুলি পৃথকভাবে আচরণ করা হয় তার জন্য ।

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

আইবিএম এমনকি আপনাকে এটি পারফরম্যান্স বেঞ্চমার্কিংয়ের জন্য ব্যবহার করার পরামর্শ দেয় (একটি ২০০ post পোস্ট, তবে আপডেট হয়েছে)।

Comments

সমস্ত বাস্তবায়ন যেমন বাহাভিউরকে সংজ্ঞায়িত করা হয়েছে, "ক্যাভেট সম্রাট!"

— ডেভিড স্মিট

Answer 11

আমি পিটার লরি একটি ভাল উত্তর প্রদান করছে যেখানে একই আলোচনা মূলত যা সংযোগ করছি। আমি কেন System.nanoTime () ব্যবহার করে একটি নেতিবাচক সময় ব্যয় করব?

অনেকে জাভা System.nanoTime () এ নেতিবাচক সময় ফিরতে পারে বলে উল্লেখ করেছেন। অন্যান্য লোকেরা যা বলেছে তার পুনরাবৃত্তি করার জন্য আমি ক্ষমা চেয়েছি।

1. ন্যানোটাইম () একটি ঘড়ি নয় তবে সিপিইউ চক্রের কাউন্টার।
2. রিটার্ন মান সময়ের মতো দেখতে ফ্রিকোয়েন্সি দ্বারা বিভক্ত হয়।
3. সিপিইউ ফ্রিকোয়েন্সি ওঠানামা করতে পারে।
4. যখন আপনার থ্রেডটি অন্য সিপিইউতে নির্ধারিত হবে তখন ন্যানোটাইম () পাওয়ার সম্ভাবনা রয়েছে যার ফলস্বরূপ নেতিবাচক পার্থক্যের সৃষ্টি হয়। এটা যৌক্তিক। সিপিইউ জুড়ে কাউন্টারগুলি সিঙ্ক্রোনাইজ করা হয় না।
5. অনেক ক্ষেত্রে, আপনি বেশ বিভ্রান্তিকর ফলাফল পেতে পারেন তবে ডেল্টা নেতিবাচক নয় বলে আপনি বলতে সক্ষম হবেন না। চিন্তা করুন.
6. (নিশ্চিত না হওয়া) আমি মনে করি আপনি একই সিপিইউতে নেতিবাচক ফলাফল পেতে পারেন যদি নির্দেশাবলী পুনরায় সাজানো হয়। এটি রোধ করতে, আপনাকে আপনার নির্দেশিকাগুলি সিরিয়াল করে মেমোরি বাধা দিতে হবে।

এটি শীতল হতে চাই যদি System.nanoTime () কার্যকর হয় যেখানে কোরআইডি ফিরে আসে।

Comments

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

— লেভেন্টভ

5 সম্পর্কে। ন্যানোটাইম () পার্থক্য ফলাফলগুলি সত্যই বিভ্রান্তিকর হতে পারে, তবে এই অ্যাসনওয়ারের অন্যান্য পয়েন্টগুলিতে উপস্থাপিত কারণে নয়। তবে এখানে কারণগুলির জন্য উপস্থাপন করা হয়েছে: শিপিলিভ.नेट

— ব্লগ

হাস্যকরভাবে, regarding সম্পর্কিত বিষয়ে ওপেনজেডিকে বিশেষত পুনঃক্রমের কারণে একটি বাগ ছিল: বাগস.ওপেনজডক.জাভা.নেট / ব্রাউজ / জেডিকে-8184271 । ওপেনজেডিকে, ন্যানোটাইম () একটি অভ্যন্তরীণ এবং এটি পুনরায় অর্ডার করার অনুমতি দেওয়া হয়েছিল, এটি একটি বাগ।

— লেভেন্টভ

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

— ঘূর্ণি

আপনার # 4 মান হিসাবে না নেতিবাচক পার্থক্য সম্পর্কে বলেছেন : "ন্যানোটাইম () পাওয়ার সম্ভাবনা রয়েছে যার ফলস্বরূপ নেতিবাচক পার্থক্য হয়।"

— লেভেন্টভ

Answer 12

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

Answer 13

জাভা 5 নথিও একই উদ্দেশ্যে এই পদ্ধতিটি ব্যবহার করার পরামর্শ দেয় recommend

এই পদ্ধতিটি কেবল অতিবাহিত সময় পরিমাপ করতে ব্যবহার করা যেতে পারে এবং এটি সিস্টেম বা প্রাচীর-ঘড়ির সময় সম্পর্কিত কোনও ধারণার সাথে সম্পর্কিত নয়।

জাভা 5 এপিআই ডক

Answer 14

এছাড়াও, System.currentTimeMillies()আপনি যখন আপনার সিস্টেমের ঘড়িটি পরিবর্তন করেন তখন পরিবর্তন হয়, যখন System.nanoTime()না হয়, সুতরাং পরে সময়কালগুলি পরিমাপ করা আরও নিরাপদ।

Answer 15

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

Comments

উত্স বা আরও ভাল ব্যাখ্যা ছাড়াই এই মন্তব্যটি অকেজো

— আইস 3