यहाँ C ++ कोड का एक टुकड़ा है जो कुछ बहुत अजीब व्यवहार दिखाता है। किसी अजीब कारण के लिए, डेटा को चमत्कारिक ढंग से छांटने से कोड लगभग छह गुना तेज हो जाता है:
#include <algorithm>
#include <ctime>
#include <iostream>
int main()
{
// Generate data
const unsigned arraySize = 32768;
int data[arraySize];
for (unsigned c = 0; c < arraySize; ++c)
data[c] = std::rand() % 256;
// !!! With this, the next loop runs faster.
std::sort(data, data + arraySize);
// Test
clock_t start = clock();
long long sum = 0;
for (unsigned i = 0; i < 100000; ++i)
{
// Primary loop
for (unsigned c = 0; c < arraySize; ++c)
{
if (data[c] >= 128)
sum += data[c];
}
}
double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;
std::cout << elapsedTime << std::endl;
std::cout << "sum = " << sum << std::endl;
}- बिना
std::sort(data, data + arraySize);, कोड 11.54 सेकंड में चलता है। - सॉर्ट किए गए डेटा के साथ, कोड 1.93 सेकंड में चलता है।
प्रारंभ में, मुझे लगा कि यह सिर्फ एक भाषा या संकलक विसंगति हो सकती है, इसलिए मैंने जावा की कोशिश की:
import java.util.Arrays;
import java.util.Random;
public class Main
{
public static void main(String[] args)
{
// Generate data
int arraySize = 32768;
int data[] = new int[arraySize];
Random rnd = new Random(0);
for (int c = 0; c < arraySize; ++c)
data[c] = rnd.nextInt() % 256;
// !!! With this, the next loop runs faster
Arrays.sort(data);
// Test
long start = System.nanoTime();
long sum = 0;
for (int i = 0; i < 100000; ++i)
{
// Primary loop
for (int c = 0; c < arraySize; ++c)
{
if (data[c] >= 128)
sum += data[c];
}
}
System.out.println((System.nanoTime() - start) / 1000000000.0);
System.out.println("sum = " + sum);
}
}एक समान लेकिन कम चरम परिणाम के साथ।
मेरा पहला विचार यह था कि सॉर्टिंग डेटा को कैश में लाता है, लेकिन फिर मैंने सोचा कि यह मूर्खतापूर्ण था क्योंकि सरणी अभी उत्पन्न हुई थी।
- क्या हो रहा है?
- क्यों एक सॉर्ट किए गए सरणी को अनसोल्ड सरणी को संसाधित करने की तुलना में तेज़ी से संसाधित कर रहा है?
कोड कुछ स्वतंत्र शब्दों को समेटता है, इसलिए आदेश को कोई फर्क नहीं पड़ता।
168
वाह ... री: मेल्टडाउन एंड स्पेक्टर
—
काइलमिट
@SachinVerma मेरे सिर के ऊपर से: 1) जेवीएम आखिरकार सशर्त चालों का उपयोग करने के लिए पर्याप्त स्मार्ट हो सकता है। 2) कोड मेमोरी-बाउंड है। CPU कैश में फिट होने के लिए 200M बहुत बड़ा है। इसलिए प्रदर्शन ब्रांचिंग के बजाय मेमोरी बैंडविड्थ द्वारा टोंटी जाएगा।
—
रहस्यमयी
@ रहस्यवादी, लगभग 2)। मुझे लगा कि भविष्यवाणी तालिका पैटर्न (उस पैटर्न के लिए जाँच की गई वास्तविक चर के बावजूद) पर नज़र रखती है और इतिहास के आधार पर भविष्यवाणी उत्पादन में बदलाव करती है। क्या आप कृपया मुझे एक कारण दे सकते हैं, क्यों एक बड़े बड़े सरणी शाखा भविष्यवाणी से लाभ नहीं होगा?
—
सचिन वर्मा
@SachinVerma यह करता है, लेकिन जब सरणी यह है कि बड़े, एक भी बड़ा कारक संभावना खेल में आता है - स्मृति बैंडविड्थ। स्मृति समतल नहीं है । मेमोरी तक पहुंच बहुत धीमी है, और सीमित मात्रा में बैंडविड्थ है। चीजों को सरल बनाने के लिए, केवल कुछ बाइट्स हैं जो एक निश्चित समय में सीपीयू और मेमोरी के बीच स्थानांतरित हो सकते हैं। इस प्रश्न में एक जैसा सरल कोड शायद उस सीमा को प्रभावित करेगा भले ही यह गलतफहमी से धीमा हो। यह 32768 (128KB) के सरणी के साथ नहीं होता है क्योंकि यह CPU के L2 कैश में फिट होता है।
—
रहस्यपूर्ण
एक नया सुरक्षा दोष है जिसे BranchScope कहा जाता है: cs.ucr.edu/~nael/pubs/asplos18.pdf
—
Veve
