Tags:

งานวิจัยจาก Sandia National Laboratories พบว่าการเพิ่มจำนวนคอร์ของซีพียูอย่างรวดเร็ว จนไม่ทันกับแบนด์วิธของหน่วยความจำ กลับทำให้ประสิทธิภาพโดยรวมของระบบช้าลง

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

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

ในโลกยุคมัลติคอร์แบบปัจจุบัน ที่จำนวนคอร์ของซีพียูเพิ่มขึ้นอย่างรวดเร็ว การวิจัยของ Sandia National Laboratories พบว่าจุดสมดุลที่ดีที่สุดในขณะนี้อยู่ที่ 8 คอร์เท่านั้น ถ้าเพิ่มจำนวนคอร์เป็น 16 คอร์ (โดยใช้สถาปัตยกรรมหน่วยความจำแบบในปัจจุบัน) ประสิทธิภาพรวมจะลดลงเหลือเท่ากับระบบที่ใช้ 2 คอร์ แต่ถ้าเพิ่มคอร์มากขึ้นไปอีกเป็น 32 หรือ 64 คอร์ ประสิทธิภาพรวมจะลดลงไปอีกมาก (ดูกราฟง่ายกว่า อยู่ด้านใน)

ทางแก้ก็ต้องปรับปรุงวิธีการเชื่อมต่อหน่วยความจำให้ดีกว่านี้ ซึ่งทาง Sandia เสนอให้วางทับไปบนซีพียูเลย เพื่อลดปัญหา interconnect

ที่มา - IEEE Spectrum ผ่าน Ars Technica

No Description

Get latest news from Blognone

Comments

By: Thaina
Windows
on 8 December 2008 - 14:58 #74829

เห็น Intel ทำเป็นว่า ทุก Core มีหน่วยความจำในตัว ตั้งแต่แรกแล้วนี่ครับ??

ที่มาโชว์ 128 คอร์เมื่อช่วงก่อนๆน่ะ

By: jirayu
ContributorWindows PhoneBlackberrySymbian
on 8 December 2008 - 15:14 #74832

ที่บ้านยังใช้ P4 อยู่เลยครับ เหอๆ

MyBlog !!!


By: wklk
ContributorAndroid
on 8 December 2008 - 15:21 #74833

เป็นงั้นไป...

By: 7ingN0ngN0i on 8 December 2008 - 15:24 #74834

ดูจากกราฟ 4 คอร์ กับ 8 คอร์ ก็แทบจะไม่แตกต่าง

By: javaboom
WriteriPhone
on 8 December 2008 - 15:40 #74835
javaboom's picture

ผมเคยเจอ paper ที่กล่าวประมาณนี้แล้ว และเขาก็สรุปว่าซีพียูไม่ควรมีเกิน 16 คอร์ แต่ถ้าเรามองไปที่ HPC บน cluster แบบดั่้งเดิมก็ประสบปัญหาเช่นนี้เหมือนกัน เขาเลยต้องเพิ่มแบนด์วิธของเครือข่าย แต่วิธีแก้อีกอย่างคือการออกแบบซอฟต์แวร์ด้วยครับ เพราะซอฟต์แวร์จะต้องจูนให้พอเหมาะกับจำนวนคอร์ อีกวิธีคือลดการเกิด page fault โดยการจัดการ cache ให้มีประสิทธิภาพ

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

JavaBoom (Boom is not Java, but Java was boom)
http://javaboom.wordpress.com


My Blog

By: mk
FounderAndroid
on 8 December 2008 - 19:13 #74872 Reply to:74835
mk's picture

ถูกต้องนะครับ ในกราฟจะเห็นชัดว่า มีตัวหนังสือระบุชัดเป็น conventional architecture

By: pawinpawin
Writer
on 8 December 2008 - 16:00 #74837

อืม อาจมีอะไรดีๆ อยู่ในแล็บอินเทลที่แก้ปัญหานี้แล้วก็ได้

___________pawinpawin

By: baggio on 8 December 2008 - 16:01 #74838

core i7 architect ?

By: polaromonas
ContributorWindows PhoneWindows
on 8 December 2008 - 19:11 #74870 Reply to:74838

คงไม่ได้ช่วยหรอกครับ

ในเมื่อ Core i7 microarchitecture ก็คือ K10 ของ intel ดีๆนี่เอง -*-

By: azx
iPhoneWindows
on 8 December 2008 - 16:08 #74839
azx's picture

น่าจะรวมทั้งหมดอยู่ทุกอย่างอยู่ใน chip เดียวเลย(cpu gpu ram hdd)

By: zyenite on 8 December 2008 - 16:24 #74841 Reply to:74839

ระวังชิบหายนะครับ :P (ชิบ + หาย)

By: khajochi
WriteriPhoneIn Love
on 8 December 2008 - 16:25 #74842
khajochi's picture

อื้ม .. คงต้องเพิ่มหน่วยความจำตามจำนวนของคอร์สิเนี่ย

---
Khajochi Blog : It's not a Bug ... It's a Feature


แฟนพันธุ์แท้สตีฟจ็อบส์ | MacThai.com

By: winggundamth
ContributorAndroidUbuntuIn Love
on 8 December 2008 - 16:54 #74845 Reply to:74842
winggundamth's picture

เค้าหมายถึงแบนด์วิธของหน่วยความจำ ไม่ใช่ขนาดของหน่วยความจำไม่ใช่เหรอครับ หรือว่าผมเข้าใจผิด??

I will change the world, to the better day.


I will change the world, to the better day.

By: lew
FounderJusci's WriterMEconomicsAndroid
on 8 December 2008 - 17:45 #74855 Reply to:74842
lew's picture

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

ปัญหาสำคัญคือ ไอ้สถาปัตยกรรมแบบนี้จะมาถึงซีพียูในตลาดเมื่อใหร่กัน

LewCPE


lewcpe.com, @wasonliw

By: rattananen
AndroidWindows
on 8 December 2008 - 17:06 #74846

มันก็เหมือนโรงปะปาที่มีเครื่องกรองน้ำอยู่ 2-3เครื่อง แล้วอยู่ดีๆเพิ่มเป็น 16เครื่อง
คุณจะเอาท่อน้ำที่ไหนจ่ายน้ำให้มันทั้ง 16เครื่องล่ะ?

แล้วอีกอย่างผมว่าคิดว่า CPU ไม่จำเป็นต่อเครื่องที่ใช้ในชีวิตประจำวันเท่าไร
RAM, bus, VGA card จำเป็นกว่าอีกครับไม่เชื่อลองดูได้
เครื่องไหนที่เล่นเกมส์แล้วกระตุกลองเพิ่ม RAM, UP VGA card ดู
ส่วนมากหายกระตุก

ดูจากกราฟ 4 core ก็พอแฮะสำหรับตอนนี้และอนาคตอันใกล้

By: lnwbleach on 8 December 2008 - 17:47 #74856

celeron ต่อไป อิอิ

By: AdmOd
iPhoneWindows
on 8 December 2008 - 18:03 #74857

อาจจะแก้เป็นเสมือนมีเมนบอร์ด 2 ตัวในตัวเดียว เป็น Dual Chipsets, Dual Memory Controllers, Dual บลาๆๆๆ

เป็น Home Cloud ไป

By: DoraeMew
AndroidSymbianUbuntuWindows
on 8 December 2008 - 18:26 #74861

แก้โดยให้แต่ละคอร์มี memory controller และ memory ของตัวเองไม่ได้เหรอ - -?

By: 7
Android
on 8 December 2008 - 21:34 #74882
7's picture

เจอปัญหาแล้ว ก็หาทางแก้กันไป อย่างเราๆทั่นๆ ก็คอยฟังข่าวแล้วซื้อมาใช้ให้เหมาะกับงาน เหมาะกับกระเป๋าสตางค์ ก็พอใจแระ

7blogger.com

By: somsak_sr
ContributorAndroidUbuntu
on 8 December 2008 - 21:39 #74884
somsak_sr's picture

ผมเข้าใจว่าถ้าไปเพิ่มให้มี memory ในแต่ละ core เอง มันแก้ปัญหาได้ระดับนึง แต่ผมว่ามันเป็นกึ่งๆการ "เลี่ยงปัญหา" คือ ผลักภาระให้ software ไปหาทางจัดการ processor เอาเองให้มีประสิทธิภาพในการจัดการ ram

ตรงนี้ผมเข้าใจว่ามันแก้ไปบ้างแล้ว คือใน kernel มักจะมีการ schedule และมีการ set พวก affinity ทำให้การจอง memory มันมักจะใช้ตัวที่อยู่กับ CPU เองไว้ก่อน ซึ่งวิธีง่ายๆนี้ก็ได้ผลกับ app ทั่วๆไปตอนนี้ที่รันกัน 1 thread แล้วก็ใช้ ram พอประมาณ แต่ถ้าเกิด app หันกันมาเขียนแบบ multi thread กันมากๆ การคุยกันข้าม cpu ก็จะเกิดอยู่ดี

ปัญหาคือ thread model ในปัจจุบันผมเข้าใจว่ายังมีวิธีการทำ communication ง่ายๆคือคุยกันผ่าน global/heap ของโปรแกรม เพราะงั้นถ้าเจอ app ประเภทหลาย thread ที่จำเป็นต้องใช้ cpu หลายๆ core ช่วยให้รันได้เร็วขึ้นจริงๆ มันจะกลายเป็นว่ารันแล้วไม่ค่อยเร็วขึ้นเท่าไหร่เพราะมันก็ต้องคุยกันผ่าน bus ที่เป็นคอขวดอยู่ดี

ผมจำได้เลาๆว่าตอนคลัสเตอร์ ปัญหานี้ถูกแก้ไปพร้อมๆกับการมาของ infiniband โดยระหว่างนั้นก็มีพวก elan, myrinet ขัดตาทัพไปก่อน แล้วพวก app ก็หันมาขยันทำ parallelize กันซะจนปัจจุบันแทบหา HPC app ที่ไม่เป็น parallel ไม่เจอ แต่ถ้ามาเกิดในระดับ multi core ซึ่งไม่มี programming language พิเศษ การแก้ในระดับซอฟต์แวร์น่าจะลำบาก เพราะแม้กระทั่งในปัจจุบัน พวกภาษาหรือคอมไพเลอร์ที่ทำ parallelize อัตโนมัติก็ยังทำได้ไม่ค่อยดี ผมเข้าใจว่าพวกภาษากึ่งๆอย่าง OpenMP ประสิทธิภาพก็ยังด้อยกว่าเขียนเป็น MPI แต่แรก อันนี้ผมสังเกตจากที่ว่า App ส่วนใหญ่หันมาเขียนเป็น MPI กันหมดนะครับ

พอไปอ่าน lew's blog เรื่อง terascale ก็พบว่าดูเหมือนเขาจะคิดแบบนี้เหมือนกัน เลยแก้ปัญหาโดยการเพิ่ม bandwidth แบบมหาศาลและเปลี่ยนรูปแบบการเชื่อมต่อแต่ละ core ไปเลย

By: sugree
FounderWriterAndroidBlackberry
on 9 December 2008 - 00:47 #74906

ปีที่แล้วเห็นว่าเชื่อมโปรเซสเซอร์กับหน่วยความจำด้วยไฟเบอร์ เร็วปรู๊ด

By: zda98
Windows Phone
on 9 December 2008 - 09:03 #74945

วิธีอ่ะผมว่ามีแล้วแต่มันแพงเลยยังไม่สามารถนำมาใช้งานกับเครื่องตามบ้านได้เช่น Switch แบบ Infiniband ที่ใช้ในระบบ Cluster ก็น่าจะแก้ไขได้บ้างนะครับ

By: somsak_sr
ContributorAndroidUbuntu
on 9 December 2008 - 22:59 #75061 Reply to:74945
somsak_sr's picture

infiniband ถ้าเทียบกับ bandwidth ใน CPU ยังช้านะครับ ได้แค่หลัก 20Gbps เอง อย่างใน terascale นี่ซัดไประดับ TB ครับ