एसटीएम

Question

के साथ खराब प्रदर्शन/लॉकअप मैं एक प्रोग्राम लिख रहा हूं जहां बड़ी संख्या में एजेंट घटनाओं को सुनते हैं और उन पर प्रतिक्रिया करते हैं। Control.Concurrent.Chan.dupChan के बाद से हटा दिया गया है मैं Tchan के रूप में विज्ञापित उपयोग करने का फैसला।

टीसीएचएन का प्रदर्शन मेरी अपेक्षा से भी बदतर है। मैं निम्नलिखित प्रोग्राम है जो मुद्दे को दर्शाता है:

{-# LANGUAGE BangPatterns #-} 

module Main where 

import Control.Concurrent.STM 
import Control.Concurrent 
import System.Random(randomRIO) 
import Control.Monad(forever, when) 

allCoords :: [(Int,Int)] 
allCoords = [(x,y) | x <- [0..99], y <- [0..99]] 

randomCoords :: IO (Int,Int) 
randomCoords = do 
    x <- randomRIO (0,99) 
    y <- randomRIO (0,99) 
    return (x,y) 

main = do 
    chan <- newTChanIO :: IO (TChan ((Int,Int),Int)) 

    let watcher p = do 
     chan' <- atomically $ dupTChan chan 
     forkIO $ forever $ do 
        r@(p',_counter) <- atomically $ readTChan chan' 
        when (p == p') (print r) 
     return() 

    mapM_ watcher allCoords 

    let go !cnt = do 
     xy <- randomCoords 
     atomically $ writeTChan chan (xy,cnt) 
     go (cnt+1) 

    go 1 

जब संकलित (-O) और इस तरह कार्यक्रम पहले इच्छा उत्पादन कुछ चलाएँ:

 
./tchantest 
((0,25),341) 
((0,33),523) 
((0,33),654) 
((0,35),196) 
((0,48),181) 
((0,48),446) 
((1,15),676) 
((1,50),260) 
((1,78),561) 
((2,30),622) 
((2,38),383) 
((2,41),365) 
((2,50),596) 
((2,57),194) 
((3,19),259) 
((3,27),344) 
((3,33),65) 
((3,37),124) 
((3,49),109) 
((3,72),91) 
((3,87),637) 
((3,96),14) 
((4,0),34) 
((4,17),390) 
((4,73),381) 
((4,74),217) 
((4,78),150) 
((5,7),476) 
((5,27),207) 
((5,47),197) 
((5,49),543) 
((5,53),641) 
((5,58),175) 
((5,70),497) 
((5,88),421) 
((5,89),617) 
((6,0),15) 
((6,4),322) 
((6,16),661) 
((6,18),405) 
((6,30),526) 
((6,50),183) 
((6,61),528) 
((7,0),74) 
((7,28),479) 
((7,66),418) 
((7,72),318) 
((7,79),101) 
((7,84),462) 
((7,98),669) 
((8,5),126) 
((8,64),113) 
((8,77),154) 
((8,83),265) 
((9,4),253) 
((9,26),220) 
((9,41),255) 
((9,63),51) 
((9,64),229) 
((9,73),621) 
((9,76),384) 
((9,92),569) 
... 

और फिर, कुछ बिंदु पर, बंद हो जाएगा कुछ भी लिखना, जबकि अभी भी 100% सीपीयू खपत है।

 
((20,56),186) 
((20,58),558) 
((20,68),277) 
((20,76),102) 
((21,5),396) 
((21,7),84) 

लॉकअप के साथ-साथ भी तेज है और केवल कुछ मुट्ठी भर के बाद होता है। यह आरटीएस '-एन ध्वज के माध्यम से जो भी कोर उपलब्ध कराया जाएगा, वह भी उपभोग करेगा।

इसके अतिरिक्त प्रदर्शन खराब दिखता है - केवल प्रति सेकंड लगभग 100 ईवेंट संसाधित होते हैं।

क्या यह एसटीएम में एक बग है या क्या मैं एसटीएम के अर्थशास्त्र के बारे में कुछ गलत समझ रहा हूं?

Answer 1

कार्यक्रम काफी बुरी तरह से प्रदर्शन करने जा रहा है। आप 10,000 धागे जो सभी के लिए लिखा जा के लिए एक एकल Tvar के लिए इंतजार अप कतार होगा बंद को उत्पन्न करने जा रहे हैं। तो एक बार वे सब जा रहे हैं, आप अच्छी तरह से हो रहा प्राप्त कर सकते हैं:

1. 10.000 धागे की प्रत्येक चैनल से पढ़ने के लिए कोशिश करता है, यह खाली पाता है, और अंतर्निहित Tvar के लिए प्रतीक्षा कतार में ही कहते हैं। तो आपके पास टीवी कतार के लिए प्रतीक्षा कतार में 10,000 कतार-अप घटनाएं और 10,000 प्रक्रियाएं होंगी।
2. कुछ चैनल के लिए लिखा है। यह 10,000 धागे से प्रत्येक unqueue और रन-कतार पर इसे वापस डाल देंगे (इस हे हो सकता है (एन) या हे (1), कैसे आरटीएस लिखा है के आधार पर)।
3. 10,000 धागे से प्रत्येक फिर आइटम पर कार्रवाई करता है, तो यह उस में रुचि रखते हैं, जो सबसे अधिक नहीं होगा यह देखने के लिए चाहिए।

इसलिए प्रत्येक आइटम ओ (10,000) प्रसंस्करण का कारण बन जाएगा। आप इसका मतलब है कि प्रत्येक थ्रेड को जगाने के लिए के बारे में 1 माइक्रोसेकंड की आवश्यकता है प्रति सेकंड 100 घटनाओं, देखते हैं, तो, TVars के एक जोड़े को पढ़ने के एक करने के लिए लिख सकते हैं और फिर से कतार। यह इतना अनुचित नहीं लगता है। मुझे समझ में नहीं आता कि कार्यक्रम पूरी तरह से बंद क्यों होगा।

सामान्य तौर पर, मैं इस डिजाइन स्क्रैप और इसे बदलना इस प्रकार हैं:

किसी एकल थ्रेड घटना चैनल है, जो एक मानचित्र का कहना रुचि रिसीवर चैनल को समन्वय से पढ़ लो। एकल धागा ओ (लॉग एन) समय में मानचित्र से रिसीवर (ओं) को चुन सकता है (ओ (एन) से काफी बेहतर है, और इसमें बहुत छोटे स्थिर कारक शामिल हैं), और केवल रुचि प्राप्तकर्ता को ईवेंट भेजें । तो आप रुचि रखने वाले पार्टी को केवल एक या दो संचार करते हैं, बजाय हर किसी के लिए 10,000 संचार। विचार 5 का एक सूची-आधारित रूप सीएचपी में लिखा गया है।इस पत्र के 4: http://chplib.files.wordpress.com/2011/05/chp.pdf

Answer 2

क्या नील ने कहा करने के लिए जोड़ा जा रहा है, अपने कोड भी एक अंतरिक्ष रिसाव (के साथ छोटे n ध्यान देने योग्य है): स्पष्ट टपल का निर्माण हुआ मुद्दा by making tuples strict फिक्सिंग के बाद , मैं निम्नलिखित प्रोफाइल के साथ छोड़ दिया गया था: यहां क्या हो रहा है, मुझे लगता है कि, मुख्य धागा साझा TChan पर डेटा लिख ​​रहा है, कार्यकर्ता थ्रेड इसे पढ़ सकते हैं (TChan, जैसे Chan, असंबद्ध है)। तो कार्यकर्ता धागे spend most of their time अपने संबंधित एसटीएम लेनदेन को दोबारा बेचते हुए, जबकि मुख्य धागा चैनल में और भी डेटा भरने में व्यस्त है; यह बताता है कि आपका प्रोग्राम क्यों लटकता है।

Answer 3

यह एक अच्छा परीक्षण मामला है! मुझे लगता है कि आपने वास्तव में वास्तविक livelock/भुखमरी का एक दुर्लभ उदाहरण बनाया है। हम -eventlog के साथ संकलित करके और -vst के साथ चलकर या -debug के साथ संकलित करके -Ds के साथ चलकर इसका परीक्षण कर सकते हैं। हम देखते हैं कि प्रोग्राम रनटाइम "लटका" के रूप में भी अभी भी पागल की तरह काम कर रहा है, अवरुद्ध धागे के बीच कूद रहा है।

उच्च स्तरीय कारण यह है कि आपके पास एक (तेज़) लेखक और कई (तेज़) पाठक हैं। पाठकों और लेखक दोनों को कतार के अंत का प्रतिनिधित्व करने वाले एक ही टीवीर तक पहुंचने की आवश्यकता है। आइए मान लें कि नोडेटर्मिनिस्टिक रूप से एक धागा सफल होता है और जब ऐसा होता है तो अन्य सभी विफल हो जाते हैं। अब, जब हम 100 * 100 तक विवाद में धागे की संख्या बढ़ाते हैं, तो पाठक की प्रगति की संभावना तेजी से शून्य की ओर जाती है। इस बीच, लेखक वास्तव में लंबे को पाठकों की तुलना में उस टीवीर की पहुंच में लेते हैं, जिससे चीजों को इसके लिए और भी बदतर बना दिया जाता है।

इस उदाहरण में, लेखक के लिए go के प्रत्येक आमंत्रण के बीच एक छोटा थ्रॉटल डालना (कहें, threadDelay 100) समस्या को ठीक करने के लिए पर्याप्त है। यह पाठकों को लगातार लिखने के बीच सभी ब्लॉक के लिए पर्याप्त समय देता है, और इसलिए livelock को समाप्त करता है। हालांकि, मैं सोचता हूं कि इस तरह की स्थितियों से निपटने के लिए रनटाइम शेड्यूलर के व्यवहार को बेहतर बनाने में यह एक दिलचस्प समस्या होगी।