ฉันควรใช้กระแสข้อมูลแบบขนานเสมอเมื่อทำได้

ด้วย Java 8 และ lambdas ทำให้ง่ายต่อการวนซ้ำคอลเลกชันเป็นสตรีมและใช้สตรีมแบบขนานได้อย่างง่ายดาย ตัวอย่างสองตัวอย่างจากเอกสารตัวอย่างที่สองใช้ parallelStream:

myShapesCollection.stream()
    .filter(e -> e.getColor() == Color.RED)
    .forEach(e -> System.out.println(e.getName()));

myShapesCollection.parallelStream() // <-- This one uses parallel
    .filter(e -> e.getColor() == Color.RED)
    .forEach(e -> System.out.println(e.getName()));

ตราบใดที่ฉันไม่สนใจคำสั่งมันจะเป็นประโยชน์กับการใช้ขนานหรือไม่? ใครจะคิดว่ามันเร็วกว่าการแบ่งงานบนแกนเพิ่มเติม

มีข้อควรพิจารณาอื่น ๆ อีกไหม? ควรใช้สตรีมแบบขนานเมื่อใดและควรใช้สตรีมแบบไม่ขนานเมื่อใด

^{(คำถามนี้ขอให้กระตุ้นการสนทนาเกี่ยวกับวิธีการและเวลาในการใช้สตรีมแบบขนานไม่ใช่เพราะฉันคิดว่าการใช้พวกเขาเป็นความคิดที่ดีเสมอ)}

กระแสขนานมีค่าใช้จ่ายที่สูงกว่ามากเมื่อเทียบกับลำดับ การประสานงานเธรดใช้เวลานานพอสมควร ฉันจะใช้ลำธารเรียงตามค่าเริ่มต้นและพิจารณาเพียงลำพังขนานถ้า

• ฉันมีรายการจำนวนมากที่ต้องดำเนินการ (หรือการประมวลผลของแต่ละรายการต้องใช้เวลาและสามารถขนานกันได้)

• ฉันมีปัญหาเรื่องประสิทธิภาพในตอนแรก

• ฉันไม่ได้เรียกใช้กระบวนการในสภาพแวดล้อมแบบมัลติเธรด (ตัวอย่างเช่น: ในเว็บคอนเทนเนอร์ถ้าฉันมีคำร้องขอให้ดำเนินการแบบขนานจำนวนมากแล้วการเพิ่มเลเยอร์คู่ขนานในแต่ละคำร้องขออาจมีผลลบมากกว่าผลบวก )

ในตัวอย่างของคุณประสิทธิภาพจะถูกผลักดันโดยการเข้าถึงที่มีการซิงโครไนซ์System.out.println()และการทำให้กระบวนการนี้ขนานกันจะไม่มีผลกระทบใด ๆ หรือแม้แต่การลบ

นอกจากนี้โปรดทราบว่าสตรีมขนานไม่ได้แก้ปัญหาการซิงโครไนซ์ทั้งหมดอย่างน่าอัศจรรย์ หากมีการใช้ทรัพยากรที่ใช้ร่วมกันโดยเพรดิเคตและฟังก์ชันที่ใช้ในกระบวนการคุณจะต้องตรวจสอบให้แน่ใจว่าทุกอย่างปลอดภัยต่อเธรด โดยเฉพาะอย่างยิ่งผลข้างเคียงเป็นสิ่งที่คุณต้องกังวลถ้าคุณไปขนานกัน

ไม่ว่าในกรณีใด ๆ วัดอย่าเดา! เฉพาะการวัดเท่านั้นที่จะบอกคุณได้ว่าการขนานนั้นมีค่าหรือไม่

Stream API ได้รับการออกแบบมาเพื่อให้ง่ายต่อการเขียนการคำนวณด้วยวิธีที่แยกออกจากวิธีที่พวกเขาจะถูกดำเนินการทำให้การสลับระหว่างลำดับและขนานง่าย

อย่างไรก็ตามเนื่องจากง่ายไม่ได้หมายความว่ามันเป็นความคิดที่ดีเสมอและในความเป็นจริงมันเป็นความคิดที่ดีที่จะทิ้ง.parallel()ทุกที่ไว้เพียงเพราะคุณทำได้

ก่อนอื่นให้สังเกตว่าการขนานกันนั้นไม่ได้มีประโยชน์อะไรนอกจากความเป็นไปได้ของการดำเนินการที่รวดเร็วกว่าเมื่อมีแกนประมวลผลเพิ่มเติม การดำเนินการแบบขนานจะเกี่ยวข้องกับการทำงานมากกว่าลำดับต่อเนื่องเสมอเนื่องจากนอกเหนือจากการแก้ปัญหาแล้วยังต้องทำการจัดส่งและประสานงานของงานย่อยอีกด้วย ความหวังคือคุณจะได้รับคำตอบเร็วขึ้นโดยการแบ่งงานระหว่างโปรเซสเซอร์หลายตัว ไม่ว่าจะเกิดขึ้นจริงขึ้นอยู่กับหลายสิ่งรวมถึงขนาดของชุดข้อมูลของคุณการคำนวณที่คุณทำกับแต่ละองค์ประกอบธรรมชาติของการคำนวณ (โดยเฉพาะการประมวลผลขององค์ประกอบหนึ่งโต้ตอบกับการประมวลผลของผู้อื่นหรือไม่) จำนวนตัวประมวลผลที่มีอยู่และจำนวนของงานอื่นที่แข่งขันกันสำหรับตัวประมวลผลเหล่านั้น

นอกจากนี้โปรดทราบว่าการขนานกันนั้นมักจะนำมาซึ่งลัทธิเอนโดเทมินิสม์ในการคำนวณที่มักจะถูกซ่อนไว้โดยการใช้งานแบบต่อเนื่อง บางครั้งสิ่งนี้ไม่สำคัญหรือสามารถบรรเทาได้ด้วยการ จำกัด การดำเนินการที่เกี่ยวข้อง (เช่นตัวดำเนินการลดต้องไร้สัญชาติและเชื่อมโยงกัน)

ในความเป็นจริงบางครั้งการขนานจะทำให้การคำนวณของคุณเร็วขึ้นบางครั้งก็ไม่ได้และบางครั้งมันก็จะทำให้ช้าลง ที่ดีที่สุดคือการพัฒนาครั้งแรกโดยใช้การดำเนินการตามลำดับแล้วใช้ขนานที่

(A) คุณรู้ว่ามีประโยชน์กับการเพิ่มประสิทธิภาพและ

(B) ว่าจะให้ประสิทธิภาพที่เพิ่มขึ้นจริง

(A) เป็นปัญหาทางธุรกิจไม่ใช่ปัญหาด้านเทคนิค หากคุณเป็นผู้เชี่ยวชาญด้านประสิทธิภาพคุณมักจะสามารถดูรหัสและตรวจสอบ (B) แต่เส้นทางสมาร์ทคือการวัด (และอย่ากังวลจนกว่าคุณจะมั่นใจได้ว่า (A) ถ้ารหัสนั้นเร็วพอแนะนำให้ใช้รอบสมองของคุณที่อื่นดีกว่า)

แบบจำลองประสิทธิภาพที่ง่ายที่สุดสำหรับการขนานคือโมเดล "NQ" โดยที่ N คือจำนวนองค์ประกอบและ Q คือการคำนวณต่อองค์ประกอบ โดยทั่วไปคุณต้องมีผลิตภัณฑ์ NQ เกินขีด จำกัด บางอย่างก่อนที่คุณจะเริ่มได้รับประโยชน์ด้านประสิทธิภาพ สำหรับปัญหาต่ำ Q เช่น "เพิ่มตัวเลขตั้งแต่ 1 ถึง N" คุณจะเห็นจุดคุ้มทุนระหว่าง N = 1,000 ถึง N = 10,000 ด้วยปัญหาถาม - ตอบสูงกว่าคุณจะเห็น breakevens ที่ระดับต่ำกว่า

แต่ความจริงแล้วค่อนข้างซับซ้อน ดังนั้นจนกว่าคุณจะประสบความสำเร็จในขั้นแรกให้ระบุก่อนว่าการประมวลผลแบบต่อเนื่องจะทำให้คุณต้องเสียค่าใช้จ่ายจริงหรือไม่

ฉันดูหนึ่งในการนำเสนอผลงานของไบรอันเก๊ (Java Language สถาปนิกและสเปคนำสำหรับแลมบ์ดานิพจน์) เขาอธิบายในรายละเอียดเกี่ยวกับ 4 จุดต่อไปนี้ที่ต้องพิจารณาก่อนทำการขนาน

ค่าใช้จ่ายในการแยก / ย่อยสลาย
- บางครั้งการแยกมีราคาแพงกว่าเพียงแค่ทำงาน
ค่าใช้จ่ายในการจัดส่ง / การจัดการ
- สามารถทำงานได้มากในเวลาที่ใช้ในการส่งงานให้กับเธรดอื่น
ต้นทุนชุดค่าผสมผลลัพธ์
- บางครั้งชุดค่าผสมเกี่ยวข้องกับการคัดลอกข้อมูลจำนวนมาก ตัวอย่างเช่นการเพิ่มตัวเลขมีราคาถูกในขณะที่ชุดการรวมมีราคาแพง
สถานที่
- ช้างในห้อง นี่คือจุดสำคัญที่ทุกคนอาจพลาด คุณควรพิจารณาถึงการพลาดแคชหาก CPU รอข้อมูลเนื่องจากแคชหายไปดังนั้นคุณจะไม่ได้รับอะไรเลยจากการขนาน นั่นเป็นสาเหตุที่แหล่งที่มาของอาเรย์นั้นขนานที่ดีที่สุดเพราะดัชนีถัดไป (ใกล้กับดัชนีปัจจุบัน) ถูกแคชและมีโอกาสน้อยกว่าที่ CPU จะได้รับแคช

นอกจากนี้เขายังกล่าวถึงสูตรที่ค่อนข้างง่ายเพื่อกำหนดโอกาสในการเร่งความเร็วแบบขนาน

รุ่น NQ :

N x Q > 10000

ที่ไหน
N = จำนวนรายการข้อมูล
Q = จำนวนงานต่อรายการ

JB กระแทกเล็บที่หัว สิ่งเดียวที่ฉันสามารถเพิ่มคือ Java 8 ไม่ได้ทำประมวลผลแบบขนานบริสุทธิ์ก็ไม่paraquential ใช่ฉันเขียนบทความและฉันได้ทำ F / J มาสามสิบปีแล้วดังนั้นฉันจึงเข้าใจปัญหา

คำตอบอื่น ๆ ได้รวมถึงการทำโปรไฟล์เพื่อหลีกเลี่ยงการปรับให้เหมาะสมก่อนเวลาอันควรและค่าใช้จ่ายในการประมวลผลแบบขนาน คำตอบนี้อธิบายถึงตัวเลือกที่ดีที่สุดของโครงสร้างข้อมูลสำหรับการสตรีมแบบขนาน

ตามกฎแล้วประสิทธิภาพที่เพิ่มขึ้นจากการขนานจะดีที่สุดในการสตรีม ArrayList , HashMap, HashSetและConcurrentHashMapอินสแตนซ์; อาร์เรย์; intช่วง; และlongช่วง สิ่งที่โครงสร้างข้อมูลเหล่านี้มีเหมือนกันคือพวกมันสามารถแบ่งได้อย่างถูกต้องและถูกเป็น subranges ของขนาดที่ต้องการใด ๆ ซึ่งทำให้ง่ายต่อการแบ่งงานระหว่างเธรดแบบขนาน สิ่งที่เป็นนามธรรมที่ใช้โดยไลบรารีของสตรีมเพื่อทำงานนี้คือตัวแยกซึ่งถูกส่งคืนโดยspliteratorเมธอด on StreamและIterableและ

ปัจจัยสำคัญอีกประการที่โครงสร้างข้อมูลเหล่านี้มีเหมือนกันคือให้การอ้างอิงที่ดีถึงยอดเยี่ยมเมื่อประมวลผลตามลำดับการอ้างอิงองค์ประกอบตามลำดับจะถูกเก็บไว้ในหน่วยความจำ วัตถุที่อ้างถึงโดยการอ้างอิงเหล่านั้นอาจไม่ใกล้เคียงกันในหน่วยความจำซึ่งจะช่วยลดการอ้างอิงท้องถิ่น Local-of-reference กลายเป็นสิ่งสำคัญอย่างยิ่งสำหรับการดำเนินการแบบขนานจำนวนมาก: โดยไม่ต้องเธรดจะใช้เวลาส่วนใหญ่ในการรอข้อมูลที่จะถ่ายโอนจากหน่วยความจำไปยังแคชของโปรเซสเซอร์ โครงสร้างข้อมูลที่มีตำแหน่งอ้างอิงที่ดีที่สุดคืออาร์เรย์ดั้งเดิมเนื่องจากข้อมูลนั้นถูกเก็บไว้ในหน่วยความจำอย่างต่อเนื่อง

ที่มา: ข้อ # 48 ใช้ความระมัดระวังเมื่อทำการสตรีมแบบขนาน, Java 3e ที่มีประสิทธิภาพโดย Joshua Bloch

อย่าขนานกระแสข้อมูลที่ไม่มีที่สิ้นสุดด้วยขีด จำกัด นี่คือสิ่งที่เกิดขึ้น:

    public static void main(String[] args) {
        // let's count to 1 in parallel
        System.out.println(
            IntStream.iterate(0, i -> i + 1)
                .parallel()
                .skip(1)
                .findFirst()
                .getAsInt());
    }

ผลลัพธ์

    Exception in thread "main" java.lang.OutOfMemoryError
        at ...
        at java.base/java.util.stream.IntPipeline.findFirst(IntPipeline.java:528)
        at InfiniteTest.main(InfiniteTest.java:24)
    Caused by: java.lang.OutOfMemoryError: Java heap space
        at java.base/java.util.stream.SpinedBuffer$OfInt.newArray(SpinedBuffer.java:750)
        at ...

เหมือนกันถ้าคุณใช้ .limit(...)

คำอธิบายที่นี่: Java 8 การใช้. Parallel ในสตรีมทำให้เกิดข้อผิดพลาด OOM

ในทำนองเดียวกันอย่าใช้ขนานหากมีการสั่งซื้อสตรีมและมีองค์ประกอบมากกว่าที่คุณต้องการประมวลผลเช่น

public static void main(String[] args) {
    // let's count to 1 in parallel
    System.out.println(
            IntStream.range(1, 1000_000_000)
                    .parallel()
                    .skip(100)
                    .findFirst()
                    .getAsInt());
}

สิ่งนี้อาจทำงานได้นานขึ้นเนื่องจากเธรดแบบขนานอาจทำงานได้ในช่วงจำนวนมากมายแทนที่จะเป็นสิ่งสำคัญ 0-100 ทำให้สิ่งนี้ใช้เวลานานมาก