जावा में लिखा निम्नलिखित कार्यक्रम का निरीक्षण करें (runnable संस्करण इस प्रकार पूरा, लेकिन कार्यक्रम के महत्वपूर्ण हिस्सा आगे नीचे एक छोटा सा टुकड़ा में है):क्यों एक अस्थिर पढ़ने और फ़ील्ड सदस्य को लिखना जावा में स्केलेबल नहीं है?
import java.util.ArrayList;
/** A not easy to explain benchmark.
*/
class MultiVolatileJavaExperiment {
public static void main(String[] args) {
(new MultiVolatileJavaExperiment()).mainMethod(args);
}
int size = Integer.parseInt(System.getProperty("size"));
int par = Integer.parseInt(System.getProperty("par"));
public void mainMethod(String[] args) {
int times = 0;
if (args.length == 0) times = 1;
else times = Integer.parseInt(args[0]);
ArrayList <Long> measurements = new ArrayList <Long>();
for (int i = 0; i < times; i++) {
long start = System.currentTimeMillis();
run();
long end = System.currentTimeMillis();
long time = (end - start);
System.out.println(i + ") Running time: " + time + " ms");
measurements.add(time);
}
System.out.println(">>>");
System.out.println(">>> All running times: " + measurements);
System.out.println(">>>");
}
public void run() {
int sz = size/par;
ArrayList <Thread> threads = new ArrayList <Thread>();
for (int i = 0; i < par; i++) {
threads.add(new Reader(sz));
threads.get(i).start();
}
for (int i = 0; i < par; i++) {
try {
threads.get(i).join();
} catch (Exception e) {}
}
}
final class Foo {
int x = 0;
}
final class Reader extends Thread {
volatile Foo vfoo = new Foo();
Foo bar = null;
int sz;
public Reader(int _sz) {
sz = _sz;
}
public void run() {
int i = 0;
while (i < sz) {
vfoo.x = 1;
// with the following line commented
// the scalability is almost linear
bar = vfoo; // <- makes benchmark 2x slower for 2 processors - why?
i++;
}
}
}
}
स्पष्टीकरण: कार्यक्रम वास्तव में बहुत सरल है । यह सिस्टम गुणों से size और par पूर्णांक लोड करता है (-D ध्वज के साथ जेवीएम पास किया गया) - ये इनपुट लंबाई और बाद में उपयोग करने के लिए धागे की संख्या हैं। इसके बाद यह पहली कमांड लाइन तर्क का विश्लेषण करता है जो कहता है कि कार्यक्रम को दोहराने के लिए कितना समय है (हम यह सुनिश्चित करना चाहते हैं कि जेआईटी ने अपना काम किया है और अधिक विश्वसनीय माप हैं)।
प्रत्येक पुनरावृत्ति में run विधि को बुलाया जाता है। यह विधि बस par धागे शुरू करती है, जिनमें से प्रत्येक size/par पुनरावृत्तियों के साथ एक लूप करेगा। थ्रेड बॉडी को Reader कक्षा में परिभाषित किया गया है। लूप की प्रत्येक पुनरावृत्ति एक अस्थिर सदस्य vfoo पढ़ती है और 1 को अपने सार्वजनिक क्षेत्र में असाइन करती है। उसके बाद, vfoo एक बार फिर पढ़ा जाता है और गैर-अस्थिर फ़ील्ड bar को असाइन किया जाता है।
सूचना कैसे समय कार्यक्रम पाश शरीर को क्रियान्वित कर रहा है, तो सूत्र में run के सबसे इस बेंचमार्क का ध्यान केंद्रित है:
final class Reader extends Thread {
volatile Foo vfoo = new Foo();
Foo bar = null;
int sz;
public Reader(int _sz) {
sz = _sz;
}
public void run() {
int i = 0;
while (i < sz) {
vfoo.x = 1;
// with the following line commented
// the scalability is almost linear
bar = vfoo; // <- makes benchmark 2x slower for 2 processors - why?
i++;
}
}
}
टिप्पणियों: एक
Ubuntu Server 10.04.3 LTS
8 core Intel(R) Xeon(R) CPU X5355 @2.66GHz
~20GB ram
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
java -Xmx512m -Xms512m -server -Dsize=500000000 -Dpar=1 MultiVolatileJavaExperiment 10 चल रहा है
मुझे निम्नलिखित बार मिलते हैं:
>>> All running times: [821, 750, 1011, 750, 758, 755, 1219, 751, 751, 1012]
अब, -Dpar=2 की स्थापना, मैं:
>>> All running times: [1618, 380, 1476, 1245, 1390, 1391, 1445, 1393, 1511, 1508]
जाहिर है, यह किसी कारण से स्केल नहीं करता है - मैं हालांकि यह एक में होना प्रतीत होता है दूसरा उत्पादन दोगुनी गति से होने के लिए (उम्मीद है | प्रारंभिक पुनरावृत्तियों के - 380ms)।
दिलचस्प है, लाइन bar = vfoo (जो भी एक अस्थिर लिखने होना चाहिए नहीं है) बाहर टिप्पणी करते हुए निम्नलिखित समय 1,2,4,8 को -Dpar सेट के लिए अर्जित करता है।
>>> All running times: [762, 563, 563, 563, 563, 563, 570, 566, 563, 563]
>>> All running times: [387, 287, 285, 284, 283, 281, 282, 282, 281, 282]
>>> All running times: [204, 146, 143, 142, 141, 141, 141, 141, 141, 141]
>>> All running times: [120, 78, 74, 74, 81, 75, 73, 73, 72, 71]
यह पूरी तरह से स्केल करता है।
विश्लेषण: सबसे पहले, यहां कोई कचरा संग्रहण चक्र नहीं है (मैंने -verbose:gc भी इसे जांचने के लिए जोड़ा है)।
मुझे अपने आईमैक पर समान परिणाम मिलते हैं।
प्रत्येक धागा अपने स्वयं के क्षेत्र के लिए लिख रहा है, और अलग अलग Foo वस्तु अलग धागे से संबंधित उदाहरणों में एक ही cachelines में समाप्त हो प्रतीत नहीं होते हैं - Foo में और अधिक सदस्यों को जोड़ने इसके आकार को बढ़ाने के लिए माप नहीं बदलता है । एल 1 कैश लाइन को भरने के लिए प्रत्येक थ्रेड ऑब्जेक्ट इंस्टेंस में पर्याप्त फ़ील्ड से अधिक है। तो यह शायद एक स्मृति मुद्दा नहीं है।
मेरा अगला सोचा कि JIT, कुछ अजीब कर हो सकती है क्योंकि जल्दी पुनरावृत्तियों आमतौर पर uncommented संस्करण में अपेक्षा के अनुरूप पैमाने करना था, इसलिए मैं विधानसभा (this post on how to do that देखें) मुद्रण द्वारा इस की जाँच की।
java -Xmx512m -Xms512m -server -XX:CompileCommand=print,*Reader.run MultiVolatileJavaExperiment -Dsize=500000000 -Dpar=1 10
और मैं Reader में Jitted विधि run के लिए 2 संस्करणों के लिए इन 2 आउटपुट मिलता है। टिप्पणी की (ठीक से स्केलेबल) संस्करण:
[Verified Entry Point]
0xf36c9fac: mov %eax,-0x3000(%esp)
0xf36c9fb3: push %ebp
0xf36c9fb4: sub $0x8,%esp
0xf36c9fba: mov 0x68(%ecx),%ebx
0xf36c9fbd: test %ebx,%ebx
0xf36c9fbf: jle 0xf36c9fec
0xf36c9fc1: xor %ebx,%ebx
0xf36c9fc3: nopw 0x0(%eax,%eax,1)
0xf36c9fcc: xchg %ax,%ax
0xf36c9fd0: mov 0x6c(%ecx),%ebp
0xf36c9fd3: test %ebp,%ebp
0xf36c9fd5: je 0xf36c9ff7
0xf36c9fd7: movl $0x1,0x8(%ebp)
---------------------------------------------
0xf36c9fde: mov 0x68(%ecx),%ebp
0xf36c9fe1: inc %ebx ; OopMap{ecx=Oop off=66}
;*goto
; - org.scalapool.bench.MultiVolatileJavaExperiment$Reader::[email protected] (line 83)
---------------------------------------------
0xf36c9fe2: test %edi,0xf7725000 ; {poll}
0xf36c9fe8: cmp %ebp,%ebx
0xf36c9fea: jl 0xf36c9fd0
0xf36c9fec: add $0x8,%esp
0xf36c9fef: pop %ebp
0xf36c9ff0: test %eax,0xf7725000 ; {poll_return}
0xf36c9ff6: ret
0xf36c9ff7: mov $0xfffffff6,%ecx
0xf36c9ffc: xchg %ax,%ax
0xf36c9fff: call 0xf36a56a0 ; OopMap{off=100}
;*putfield x
; - org.scalapool.bench.MultiVolatileJavaExperiment$Reader::[email protected] (line 79)
; {runtime_call}
0xf36ca004: call 0xf6f877a0 ; {runtime_call}
uncommented bar = vfoo (गैर स्केलेबल, धीमी) संस्करण:
[Verified Entry Point]
0xf3771aac: mov %eax,-0x3000(%esp)
0xf3771ab3: push %ebp
0xf3771ab4: sub $0x8,%esp
0xf3771aba: mov 0x68(%ecx),%ebx
0xf3771abd: test %ebx,%ebx
0xf3771abf: jle 0xf3771afe
0xf3771ac1: xor %ebx,%ebx
0xf3771ac3: nopw 0x0(%eax,%eax,1)
0xf3771acc: xchg %ax,%ax
0xf3771ad0: mov 0x6c(%ecx),%ebp
0xf3771ad3: test %ebp,%ebp
0xf3771ad5: je 0xf3771b09
0xf3771ad7: movl $0x1,0x8(%ebp)
-------------------------------------------------
0xf3771ade: mov 0x6c(%ecx),%ebp
0xf3771ae1: mov %ebp,0x70(%ecx)
0xf3771ae4: mov 0x68(%ecx),%edi
0xf3771ae7: inc %ebx
0xf3771ae8: mov %ecx,%eax
0xf3771aea: shr $0x9,%eax
0xf3771aed: movb $0x0,-0x3113c300(%eax) ; OopMap{ecx=Oop off=84}
;*goto
; - org.scalapool.bench.MultiVolatileJavaExperiment$Reader::[email protected] (line 83)
-----------------------------------------------
0xf3771af4: test %edi,0xf77ce000 ; {poll}
0xf3771afa: cmp %edi,%ebx
0xf3771afc: jl 0xf3771ad0
0xf3771afe: add $0x8,%esp
0xf3771b01: pop %ebp
0xf3771b02: test %eax,0xf77ce000 ; {poll_return}
0xf3771b08: ret
0xf3771b09: mov $0xfffffff6,%ecx
0xf3771b0e: nop
0xf3771b0f: call 0xf374e6a0 ; OopMap{off=116}
;*putfield x
; - org.scalapool.bench.MultiVolatileJavaExperiment$Reader::[email protected] (line 79)
; {runtime_call}
0xf3771b14: call 0xf70307a0 ; {runtime_call}
दो संस्करणों में मतभेद --------- के भीतर हैं। मुझे असेंबली में सिंक्रनाइज़ेशन निर्देश मिलने की उम्मीद है जो प्रदर्शन के मुद्दे के लिए हो सकता है - जबकि कुछ अतिरिक्त shift, mov और inc निर्देश पूर्ण प्रदर्शन संख्याओं को प्रभावित कर सकते हैं, मुझे नहीं लगता कि वे स्केलेबिलिटी को कैसे प्रभावित कर सकते हैं।
तो, मुझे संदेह है कि यह वर्ग में किसी फ़ील्ड को संग्रहीत करने से संबंधित स्मृति प्रकार का कुछ प्रकार है। दूसरी तरफ, मैं यह भी मानने के इच्छुक हूं कि जेआईटी कुछ मजाकिया करता है, क्योंकि एक पुनरावृत्ति में मापा गया समय जितना तेज़ होगा, उतना ही होना चाहिए।
क्या कोई यहां समझा सकता है कि क्या हो रहा है? कृपया सटीक रहें और उन संदर्भों को शामिल करें जो आपके दावों का समर्थन करते हैं।
धन्यवाद!
संपादित करें:
यहाँ तेजी से (स्केलेबल) संस्करण के लिए बाईटकोड है:
public void run();
LineNumberTable:
line 77: 0
line 78: 2
line 79: 10
line 83: 18
line 85: 24
Code:
Stack=2, Locals=2, Args_size=1
0: iconst_0
1: istore_1
2: iload_1
3: aload_0
4: getfield #7; //Field sz:I
7: if_icmpge 24
10: aload_0
11: getfield #5; //Field vfoo:Lorg/scalapool/bench/MultiVolatileJavaExperiment$Foo;
14: iconst_1
15: putfield #8; //Field org/scalapool/bench/MultiVolatileJavaExperiment$Foo.x:I
18: iinc 1, 1
21: goto 2
24: return
LineNumberTable:
line 77: 0
line 78: 2
line 79: 10
line 83: 18
line 85: 24
StackMapTable: number_of_entries = 2
frame_type = 252 /* append */
offset_delta = 2
locals = [ int ]
frame_type = 21 /* same */
bar = vfoo साथ धीमी गति से (गैर स्केलेबल) संस्करण:
public void run();
LineNumberTable:
line 77: 0
line 78: 2
line 79: 10
line 82: 18
line 83: 26
line 85: 32
Code:
Stack=2, Locals=2, Args_size=1
0: iconst_0
1: istore_1
2: iload_1
3: aload_0
4: getfield #7; //Field sz:I
7: if_icmpge 32
10: aload_0
11: getfield #5; //Field vfoo:Lorg/scalapool/bench/MultiVolatileJavaExperiment$Foo;
14: iconst_1
15: putfield #8; //Field org/scalapool/bench/MultiVolatileJavaExperiment$Foo.x:I
18: aload_0
19: aload_0
20: getfield #5; //Field vfoo:Lorg/scalapool/bench/MultiVolatileJavaExperiment$Foo;
23: putfield #6; //Field bar:Lorg/scalapool/bench/MultiVolatileJavaExperiment$Foo;
26: iinc 1, 1
29: goto 2
32: return
LineNumberTable:
line 77: 0
line 78: 2
line 79: 10
line 82: 18
line 83: 26
line 85: 32
StackMapTable: number_of_entries = 2
frame_type = 252 /* append */
offset_delta = 2
locals = [ int ]
frame_type = 29 /* same */
अधिक मैं कर रहा हूँ इसके साथ प्रयोग करते हुए, मुझे ऐसा लगता है कि इसका वाष्पशीलता से कोई लेना-देना नहीं है - इसमें फ़ील्ड ऑब्जेक्ट करने के लिए लेखन के साथ कुछ करना है। मेरा झुकाव यह है कि यह किसी भी तरह एक स्मृति विवाद मुद्दा है - कैश और झूठी साझाकरण के साथ कुछ, हालांकि बिल्कुल स्पष्ट सिंक्रनाइज़ेशन नहीं है।
संपादित करें 2:
दिलचस्प है, इस तरह कार्यक्रम को बदलने:
final class Holder {
public Foo bar = null;
}
final class Reader extends Thread {
volatile Foo vfoo = new Foo();
Holder holder = null;
int sz;
public Reader(int _sz) {
sz = _sz;
}
public void run() {
int i = 0;
holder = new Holder();
while (i < sz) {
vfoo.x = 1;
holder.bar = vfoo;
i++;
}
}
}
स्केलिंग समस्या का समाधान। जाहिर है, Holder उपरोक्त ऑब्जेक्ट थ्रेड शुरू होने के बाद बनाया जाता है, और शायद स्मृति के एक अलग सेगमेंट में आवंटित किया जाता है, जिसे बाद में संशोधित किया जा रहा है, क्योंकि थ्रेड ऑब्जेक्ट में क्षेत्र bar को संशोधित करने के विपरीत, जो कि किसी भी तरह "बंद" है विभिन्न थ्रेड उदाहरणों के बीच स्मृति में।
'बार = vfoo' धीमी है, क्योंकि यह एक अस्थिर पढ़ा है। गैर-अस्थिर vfoo (असाइनमेंट को असामान्य करने के विरोध में) के साथ आपको कितनी बार मिलता है? – Viruzzo
1) 'vfoo.x = 1' भी अस्थिर पढ़ा जाता है, लेकिन यह धीमा नहीं है और यह अच्छी तरह से स्केल करता है। 2) जब 'vfoo' nonvolatile है, तो JIT लूप को दूर करता है, जब तक कि आप इसके प्रभावों का मुकाबला करने के लिए 'vfoo.x = 1' से पहले लूप के अंदर' if (bar! = Null) 'चेक जोड़ते हैं। यदि आप ऐसा करते हैं - 'vfoo' nonvolatile बनाएं और यह चेक जोड़ें, वही स्केलेबिलिटी समस्या बनी हुई है। – axel22
@ axel22: मुझे नहीं लगता कि कैसे vfoo.x = 1' एक अस्थिर पढ़ा जाता है, आप केवल एक अस्थिर क्षेत्र में लिख रहे हैं। 'bar = vfoo' इसके बजाए एक अस्थिर संदर्भ पढ़ता है। – ninjalj