อะไรคือข้อเสียของการใช้งาน JavaScript รันไทม์แบบมัลติเธรด? [ปิด]

51

ฉันทำงานเกี่ยวกับการใช้งาน JavaScript แบบหลายเธรดสำหรับสัปดาห์ที่ผ่านมา ฉันมีหลักฐานของแนวคิดที่ทำใน C ++ โดยใช้ JavaScriptCore และเพิ่ม

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

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

ตอนแรกฉันมีการนำ coroutine มาใช้ (โดยใช้บริบทเพิ่ม) ในสถานที่เช่นกัน แต่ฉันต้องทิ้ง (JavaScriptCore มีความรู้เกี่ยวกับสแต็ค) และฉันไม่ต้องการเสี่ยงต่อความโกรธของพวกเขาดังนั้นฉันจึงตัดสินใจไม่พูดถึงมัน

คุณคิดอย่างไร? JavaScript หมายถึงเป็นเธรดเดี่ยวหรือไม่และควรปล่อยไว้ตามลำพังหรือไม่ เหตุใดทุกคนจึงไม่เห็นด้วยกับการรันไทม์ JavaScript ที่ทำงานพร้อมกัน

แก้ไข: ขณะนี้โครงการอยู่ในGitHubทดลองด้วยตัวเองและแจ้งให้เราทราบว่าคุณคิดอย่างไร

ต่อไปนี้เป็นรูปภาพของสัญญาที่รันบนคอร์ CPU ทั้งหมดพร้อมกันโดยไม่มีการช่วงชิง:

javascript multithreading node.js

— voodooattack
แหล่งที่มา

7

ดูเหมือนว่าเป็นคำถามที่มีความเห็นสูง คุณถามคนที่เห็นได้ชัดว่าไม่ชอบความคิดของคุณทำไมพวกเขาคิดว่ามันจะลำบาก?

— 5gon12eder

26

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

— mgw854

2

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

— jfriend00

17

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

— jfriend00

3

โปรดทำงานต่อไป ฉันพิจารณาภาษาโดยไม่ต้องใช้มัลติเธรดเป็นภาษาของเล่น ฉันคิดว่านักพัฒนา JavaScript ส่วนใหญ่ทำงานกับเบราว์เซอร์ซึ่งมีรูปแบบเธรดเดียว

— Chloe

70

1) การมัลติเธรดนั้นยากมากและน่าเสียดายที่วิธีที่คุณนำเสนอความคิดนี้จนถึงตอนนี้บ่งบอกว่าคุณประเมินว่ามันยากเพียงใด

ในขณะนี้ดูเหมือนว่าคุณเพียงแค่ "เพิ่มหัวข้อ" ในภาษาและกังวลเกี่ยวกับวิธีการแก้ไขให้ถูกต้องและมีประสิทธิภาพในภายหลัง โดยเฉพาะอย่างยิ่ง:

หากสองภารกิจพยายามเข้าถึงตัวแปรพร้อมกันมันจะถูกทำเครื่องหมายอะตอมมิกและพวกมันจะต่อสู้เพื่อการเข้าถึง
...
ฉันยอมรับว่าตัวแปรอะตอมมิกจะไม่แก้ปัญหาทุกอย่าง แต่การแก้ปัญหาการซิงโครไนซ์เป็นเป้าหมายต่อไปของฉัน

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

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

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

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

นั่นอาจเป็นเหตุผลว่าทำไมคนถึงไม่พาคุณจริงจัง

2) ความเรียบง่ายและความทนทานของเหตุการณ์ลูปเดียวเป็นข้อได้เปรียบอย่างมาก

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

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

3) Javascript รองรับ "background threads" (WebWorkers) และการเขียนโปรแกรมแบบอะซิงโครนัสอยู่แล้วโดยไม่เปิดเผยการจัดการเธรดโดยตรงกับโปรแกรมเมอร์

ฟีเจอร์เหล่านั้นแก้ปัญหากรณีการใช้งานทั่วไปที่มีผลต่อโปรแกรมเมอร์ของ Javascript ในโลกแห่งความเป็นจริงโดยไม่ละทิ้งความปลอดภัยของเหตุการณ์ลูปเดียว

คุณมีกรณีการใช้งานเฉพาะจำไว้ว่าคุณสมบัติเหล่านี้ไม่สามารถแก้ไขได้และโปรแกรมเมอร์ Javascript นั้นต้องการวิธีแก้ปัญหาหรือไม่? ถ้าเป็นเช่นนั้นคุณควรแสดง node.js แบบมัลติเธรดของคุณในบริบทของกรณีการใช้งานเฉพาะนั้น

PS อะไรที่ทำให้ฉันลองเปลี่ยนไปใช้การใช้งานแบบมัลติเธรด node.js

เขียนโปรแกรมที่ไม่น่าสนใจใน Javascript / node.js ที่คุณคิดว่าจะได้รับประโยชน์จากมัลติเธรดแท้ ทำการทดสอบประสิทธิภาพของโปรแกรมตัวอย่างนี้ในโหนดปกติและโหนดแบบมัลติเธรดของคุณ แสดงให้ฉันเห็นว่ารุ่นของคุณปรับปรุงประสิทธิภาพรันไทม์การตอบสนองและการใช้งานหลายคอร์ในระดับที่สำคัญโดยไม่ต้องแนะนำข้อบกพร่องหรือความไม่แน่นอน

เมื่อคุณทำเช่นนั้นแล้วฉันคิดว่าคุณจะเห็นผู้คนให้ความสนใจแนวคิดนี้มากขึ้น

— Ixrec
แหล่งที่มา

1

1) โอเคฉันจะยอมรับว่าฉันได้ทำการยกเลิกการซิงโครไนซ์มาระยะหนึ่งแล้ว เมื่อฉันพูดว่า 'สองงานจะต่อกร' นั่นไม่ใช่การออกแบบของฉันมันเป็นข้อสังเกตหลัก: dl.dropboxusercontent.com/u/27714141/ … - ฉันไม่แน่ใจว่าคาถา JavaScriptCore กำลังทำงานอยู่ที่นี่ แต่ควรจะ ' สตริงนี้จะเสียหายหากไม่ได้เป็นอะตอมโดยเนื้อแท้ 2) ฉันไม่เห็นด้วยอย่างยิ่ง นี่คือเหตุผลที่ JS ถูกมองว่าเป็นภาษาของเล่น 3) สัญญา ES6 จะมีประสิทธิภาพมากขึ้นหากใช้งานโดยใช้ตัวกำหนดตารางเวลาเธรดพูล

— voodooattack

13

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

— Chris Hayes

@ChrisHayes คำถามคือทำไมทนกับข้อบกพร่องของมันเมื่อฉันสามารถแก้ไขได้หรือไม่ การทำงานพร้อมกันในฐานะที่เป็นคุณลักษณะปรับปรุง JavaScript หรือไม่

— voodooattack

1

@voodooattack นั่นเป็นคำถาม การทำงานพร้อมกันในฐานะที่เป็นคุณลักษณะปรับปรุง Javascript หรือไม่ หากคุณสามารถรับคำตอบจากชุมชนที่ไม่ใช่ "ไม่" อาจเป็นเพราะคุณทำอะไรซักอย่าง อย่างไรก็ตามดูเหมือนว่าการวนรอบเหตุการณ์และการมอบหมายท้องถิ่นของโหนดไปยังเธรดผู้ปฏิบัติงานสำหรับการบล็อกเหตุการณ์เพียงพอสำหรับสิ่งที่คนส่วนใหญ่ต้องทำ ฉันคิดว่าถ้าคนต้องการจาวาสคริปต์แบบเธรดจริงๆพวกเขาจะใช้จาวาสคริปต์คนงาน หากคุณสามารถหาวิธีที่จะทำให้คนงานที่ทำงานร่วมกับฟังก์ชั่นชั้นแรกแทนไฟล์ JS แต่ .... แล้วคุณอาจจริงๆจะเข้าสู่บางสิ่งบางอย่าง

— lunchmeat317

7

@voodooattack คนที่โทรหา JavaScript เป็นภาษาของเล่นไม่รู้ว่าพวกเขากำลังพูดถึงอะไร มันเป็นภาษาที่ไปสู่ทุกสิ่งหรือเปล่า? ไม่แน่นอน แต่การไล่ออกเช่นนั้นเป็นความผิดพลาดอย่างแน่นอน หากคุณต้องการปัดเป่าความคิดที่ว่า JS เป็นภาษาของเล่นให้สร้างแอปพลิเคชันที่ไม่น่าสนใจผลิตผลหรือชี้ไปที่สิ่งที่มีอยู่ เพียงแค่เพิ่มการเห็นพ้องด้วยจะไม่เปลี่ยนความคิดของคนเหล่านั้น

— jpmc26

16

แค่เดาที่นี่เพื่อแสดงให้เห็นปัญหาในแนวทางของคุณ ฉันไม่สามารถทดสอบกับการใช้งานจริงเนื่องจากไม่มีลิงก์ใด ๆ ...

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

function withdraw(v) {
  a -= v;
  b += v;
}
function deposit(v) {
  b -= v;
  a += v;
}

ทีนี้ในโลกที่มีหลายเธรดของคุณจะเกิดอะไรขึ้นเมื่อเธรดสองตัวดำเนินการwithdrawและdepositในเวลาเดียวกัน ขอบคุณเมอร์ฟี ...

(คุณอาจมีรหัสที่ใช้ + = และ - = พิเศษ แต่นั่นไม่ช่วยในบางจุดคุณจะมีสถานะท้องถิ่นในฟังก์ชั่นและไม่มีทางที่จะ 'ล็อค' ตัวแปรสองตัวในเวลาเดียวกันค่าคงที่ของคุณจะไม่เปลี่ยนแปลง ถูกละเมิด)

แก้ไข: หากรหัสของคุณเทียบเท่ากับรหัส Go ที่https://gist.github.com/thriqon/f94c10a45b7e0bf656781b0f4a07292aความคิดเห็นของฉันนั้นถูกต้อง ;-)

— thriqon
แหล่งที่มา

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

— Dietrich Epp

3

@voodooattack "ฉันเพิ่งทดสอบ ... " คุณไม่เคยเจอคำสั่งการดำเนินการที่ไม่สอดคล้องกับการตั้งเวลาเธรดหรือไม่ มันแตกต่างกันไปจากการวิ่งจากเครื่องหนึ่งไปอีกเครื่องหนึ่ง การนั่งและเรียกใช้การทดสอบครั้งเดียว (หรือแม้กระทั่งการทดสอบนับร้อยครั้ง) โดยไม่ระบุกลไกสำหรับการปฏิบัติการตามกำหนดเวลานั้นไร้ประโยชน์

— jpmc26

4

@voodooattack ปัญหาคือการทดสอบพร้อมกันก็ไม่มีประโยชน์ คุณต้องสามารถพิสูจน์ได้ว่าค่าคงที่จะคงอยู่หรือกลไกไม่สามารถเชื่อถือได้ในการผลิต

— sapi

1

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

— Zach Lipton

2

@voodooattack ดังนั้นหากผู้ใช้สามารถใช้เธรดของคุณสำหรับฟังก์ชั่นที่ไม่มีข้อมูลที่ใช้ร่วมกันหรือผลข้างเคียง (และพวกเขาต้องการที่จะไม่ใช้พวกเขาสำหรับสิ่งอื่น ๆ เพราะอย่างที่เราเห็นที่นี่ไม่มีวิธีที่ปลอดภัยสำหรับเธรด) ถ้าอย่างนั้นคุณให้คุณค่าอะไรกับ Web Workers (หรือหนึ่งในหลาย ๆ ไลบรารีที่ให้ API ที่ใช้งานได้มากกว่าใน Web Workers) และ Web Workers นั้นปลอดภัยกว่ามากเพราะทำให้ผู้ใช้ไม่สามารถใช้ระบบได้ "ไร้ความรับผิดชอบ"

— Zach Lipton

15

ทศวรรษที่แล้ว Brendan Eich (ผู้ประดิษฐ์ JavaScript) ได้เขียนเรียงความชื่อThreads Suckซึ่งเป็นหนึ่งในไม่กี่เอกสารที่เป็นที่ยอมรับในตำนานการออกแบบของ JavaScript

ไม่ว่าจะถูกต้องหรือไม่เป็นคำถามอื่น แต่ฉันคิดว่ามันมีอิทธิพลอย่างมากต่อชุมชน JavaScript ที่คิดเกี่ยวกับการเกิดพร้อมกัน

— Erik Pukinskis
แหล่งที่มา

31

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

— Phil Wright

12

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

— Billy Cravens

4

@BillyCravens haha แม้แต่หนังสือบัญญัติของ Javascript: "Javascript the good parts " โดย Crockford ทำให้เกมอยู่ในชื่อ ปฏิบัติต่อทัศนคติของ Eich ด้วยวิธีเดียวกันเพียงแค่ยึดสิ่งที่เขาพูดนั่นคือ :-) ดี

— gbjbaanb

13

@PhilWright: การนำ Javascript มาใช้ครั้งแรกของเขานั้นแตกต่างจาก Lisp ซึ่งสำหรับฉันเขาได้รับความเคารพอย่างมาก การตัดสินใจของเจ้านายของเขาที่จะบังคับให้เขาแทนที่ Lisp syntax ด้วย C-like syntax ไม่ใช่ความผิดของเขา Javascript ที่เป็นแกนหลักยังคงเป็น Lisp runtime

— slebetman

7

@PhilWright: คุณไม่ควรตำหนิ Eich เพราะความบ้าคลั่งของภาษา มันเป็นข้อผิดพลาดในการใช้งานในช่วงต้นและความต้องการความเข้ากันได้ย้อนหลังสำหรับภาษาเว็บที่ป้องกันไม่ให้ JS โตขึ้น แนวคิดหลักยังคงเป็นภาษาที่ยอดเยี่ยม

— Bergi

8

การเข้าถึงของอะตอมไม่ได้แปลเป็นพฤติกรรมที่ปลอดภัยต่อเธรด

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

จาวาสคริปต์ได้รับการเธรดเดียวและแซนด์บ็อกซ์ตั้งแต่ต้นและรหัสทั้งหมดจะถูกเขียนด้วยสมมติฐานเหล่านี้ในใจ

นี่เป็นข้อได้เปรียบที่ยอดเยี่ยมเกี่ยวกับบริบทแยกและให้ 2 บริบทแยกทำงานในหัวข้อที่แตกต่างกัน ฉันยังหมายถึงผู้ที่เขียน javascript ไม่จำเป็นต้องรู้วิธีจัดการกับเงื่อนไขการแข่งขันและอื่น ๆ อีกมากมาย

— วงล้อประหลาด
แหล่งที่มา

นี่คือเหตุผลที่ฉันคิดว่า API ตัวกำหนดตารางเวลาควรมีความทันสมัยมากขึ้นและใช้ภายในสำหรับสัญญาและฟังก์ชั่นที่ไม่มีผลข้างเคียง

— voodooattack

6

แนวทางของคุณจะปรับปรุงประสิทธิภาพอย่างมีนัยสำคัญหรือไม่?

น่าสงสัย คุณต้องพิสูจน์สิ่งนี้จริงๆ

วิธีการของคุณจะทำให้ง่ายขึ้น / เร็วขึ้นในการเขียนรหัสหรือไม่?

แน่นอนว่ารหัสแบบมัลติเธรดนั้นยากกว่าการได้รับรหัสเธรดเดี่ยวหลายเท่า

แนวทางของคุณจะแข็งแกร่งขึ้นหรือไม่?

การหยุดชะงักสภาพการแข่งขัน ฯลฯ เป็นฝันร้ายที่ต้องแก้ไข

— ฟิลไรท์
แหล่งที่มา

2

ลองสร้าง raytracer โดยใช้ node.js ตอนนี้ลองอีกครั้งด้วยเธรด กระบวนการหลายอย่างไม่ใช่ทุกอย่าง

— voodooattack

8

@voodooattack ไม่มีใครในใจที่ถูกต้องจะเขียน ray-tracer โดยใช้ javascript โดยมีหรือไม่มีเธรดเพราะมันเป็นขั้นตอนวิธีที่ค่อนข้างเรียบง่าย แต่ใช้การคำนวณที่เน้นการเขียนที่ดีกว่าในภาษาที่คอมไพล์อย่างสมบูรณ์ . สำหรับประเภทของปัญหาที่ใช้จาวาสคริปต์นั้นการทำงานแบบหลายกระบวนการนั้นมีมากเกินพอ

— Jan Hudec

@JanHudec: เฮ้, JS กำลังจะได้รับการสนับสนุน SIMD เช่นกัน :-) hacks.mozilla.org/2014/10/introducing-simd-js

— Bergi

2

@voodooattack หากคุณไม่ได้ตระหนักถึงพวกเขาจะดูที่SharedArrayBuffers จาวาสคริปต์กำลังได้รับการสร้างพร้อมกันมากขึ้น แต่พวกเขากำลังถูกเพิ่มอย่างระมัดระวังมากที่อยู่จุดปวดที่เฉพาะเจาะจงพยายามที่จะลดการตัดสินใจออกแบบที่ไม่ดีที่เราจะต้องอยู่กับมันมานานหลายปี

— ติดตั้ง MONICA ใหม่ - ธนาคารเจเรมี

2

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

คุณสามารถดูรุ่นอื่น ๆ ของการทำงานพร้อมกัน (เช่นการส่งข้อความ) เพื่อช่วยให้คุณทราบว่าคุณได้รับประโยชน์จากรุ่นใดบ้าง

— Ankur
แหล่งที่มา

1

ฉันคิดว่าสัญญา ES6 จะได้รับประโยชน์จากรูปแบบการนำไปใช้ของฉันเนื่องจากพวกเขาไม่ได้โต้แย้งการเข้าถึง

— voodooattack

ดูที่ข้อมูลจำเพาะของ WebWorkers มีแพ็กเกจ npm ที่ให้การใช้งานได้ แต่คุณสามารถนำไปใช้เป็นแกนหลักของเครื่องยนต์ของคุณแทนที่จะเป็นแพ็กเกจ

— Ankur

JavaScriptCore (การใช้งานเว็บคิตต์ของ JS ฉันกำลังใช้) ดำเนินการแล้วมันเป็นเพียงการรวบรวมธง

— voodooattack

ตกลง. WebWorkers ทำงานพร้อมกันด้วยการส่งข้อความ คุณสามารถลองตัวอย่าง raytracer ของคุณกับพวกมันและเปรียบเทียบกับแนวทางสถานะที่ไม่แน่นอน

— Ankur

4

การส่งข้อความจะถูกนำไปใช้เสมอบนสถานะที่ไม่แน่นอนซึ่งหมายความว่าจะช้ากว่า ฉันไม่เห็นจุดของคุณที่นี่ : - /

— voodooattack

1

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

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

— dryajov
แหล่งที่มา

4

แต่ "คณิตศาสตร์และชีวสารสนเทศศาสตร์" น่าจะเขียนได้ดีกว่าใน C #, JAVA หรือ C ++

— Ian

จริงๆแล้ว Python และ Perl เป็นภาษาหลักในพื้นที่เหล่านั้น

— dryajov

1

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

— voodooattack

@dryajov ดีใจที่คุณไม่ทราบวิธี FORTRAN ใหญ่อยู่ในบางส่วนของพื้นที่วิทยาศาสตร์คอมพิวเตอร์ ...

— cmaster

@dryajov เพราะพวกเขาสามารถเข้าถึงมนุษย์ได้มากขึ้นซึ่งอาจไม่ใช่นักเขียนโปรแกรมเต็มเวลาไม่ใช่เพราะพวกเขามีลำดับจีโนมที่ดีกว่าโดยเนื้อแท้เรามีภาษาที่สร้างขึ้นเพื่อวัตถุประสงค์เช่น R และรวบรวมภาษาทางวิทยาศาสตร์เช่น Fortran

— แมว

0

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

หากคุณสามารถหาวิธีที่จะทำให้มันกลายเป็นโมดูล npm ปกติซึ่งฟังดูไม่น่าจะเป็นไปได้คุณอาจทำให้บางคนใช้มัน

— Jason Livesay
แหล่งที่มา

คุณหมายความว่าโปรแกรมเมอร์ JS นั้นถูกล็อคผู้ขายถึง npm หรือไม่?

— voodooattack

3

คำถามคือเกี่ยวกับระบบรันไทม์ใหม่และไม่ใช่โมดูล npm และการเห็นพ้องด้วยสถานะที่ใช้ร่วมกันที่ไม่แน่นอนเป็นแนวคิดเก่า ๆ

— Ankur

1

@voodooattack ฉันหมายถึงพวกเขาจะถูกบีบให้เข้าใกล้วิธีที่เป็นที่นิยมอยู่แล้วและมันจะเป็นไปไม่ได้เลยที่จะเอาชนะสถานะเดิม

— Jason Livesay