ข้อดีของการคำนวณจุดคงที่เทียบกับการคำนวณจุดลอยตัว?


9

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

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

แน่นอนคำตอบขึ้นอยู่กับจำนวนบิตที่มีสำหรับการคำนวณจุดคงที่ ระบบจุดคงที่ทั่วไปใช้ความแม่นยำกี่บิต เป็นไปได้หรือไม่ที่จะทำการคำนวณจุดคงที่อย่างมีประสิทธิภาพด้วยการพูด 64 บิต ( ส่วนจำนวนเต็ม 16 บิต, เศษส่วน 48 บิต ) บน x86-64?

ฉันเคยคิดเสมอว่าการคำนวณจุดคงที่จะใช้เฉพาะในสถานการณ์ที่พลังงาน CPU มี จำกัด - มันสมเหตุสมผลไหมที่จะใช้การคำนวณแบบจุดคงที่เมื่อพลังงาน CPU ไม่ต้องกังวล?


คุณต้องการมากกว่าตัวเลขสำคัญ ~ 15 ที่ค่าทศนิยมความแม่นยำสองเท่าให้หรือไม่ ในขณะที่ภาพรวมทั่วไปไม่ดีฉันจะบอกว่าถ้าคุณดูที่การรวมกันของระบบ DSP คงที่ทั้งหมดจำนวนเต็ม 16 บิตน่าจะเป็นรูปแบบที่พบได้บ่อยที่สุด
Jason R

คำตอบ:


7

ความแม่นยำเชิงตัวเลขของจำนวนเต็มจะดีกว่าความแม่นยำเชิงตัวเลขของการลอยหากความละเอียดของจำนวนเต็มที่ดีกว่า คู่มี 52 บิตเศษดังนั้นความแม่นยำสองเท่าจึงมีความละเอียดที่ต่ำกว่าจำนวนเต็มที่ประมาณ252ซึ่งมีขนาดใหญ่กว่า 32768 (215) ดังนั้นไม่แม่นยำของตัวเลขจะไม่ดีกว่าถ้าคุณไปที่จำนวนเต็ม

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

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

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


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

Float Precision ที่มีความแม่นยำเดี่ยวมี 23 mantissae 23 เท่าและ 52 เท่า
Paul R

ฉันขอแนะนำจำนวนเต็ม 16 บิตและเศษส่วน 48 บิตเป็นทางเลือกสำหรับทศนิยมความแม่นยำสองเท่า ฉันพูดถึง 32768 เพื่อระบุว่าค่าของฉันจะพอดีกับช่วงนี้ได้อย่างง่ายดาย จากข้อ จำกัด ของค่าเหล่านี้ฉันคิดว่า Q16.48 จะให้ความแม่นยำเชิงตัวเลขมากกว่าจุดลอยตัวที่มีความแม่นยำสองเท่า
nibot

1
@nibot โอเค คู่จะมีความแม่นยำที่ดีขึ้นจาก -16 ถึง +16 และจำนวนเต็มเศษส่วนจะมีความแม่นยำดีกว่าที่อื่นที่ -32769 และ +32768 แน่นอนว่าพวกเขาไม่สามารถเป็นตัวแทนของอะไรได้มากกว่านั้น พวกเขาก็จะช้ากว่าคู่ สำหรับฉันช่วง จำกัด และความเร็วช้าจะเป็นตัวแบ่งเบรกเกอร์ แต่ YMMV
Jim Clay

6

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

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

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


2
+1 สำหรับการกล่าวถึงความสำคัญของปัญหาแคชที่เกี่ยวข้องกับประสิทธิภาพ ในโปรเซสเซอร์ x86 ที่ทันสมัยการออกแบบอัลกอริทึมของคุณโดยคำนึงถึงแคชสามารถมีผลกระทบอย่างมากต่อประสิทธิภาพ
Jason R

5

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

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


ฉันสนใจที่จะเพิ่มความแม่นยำของตัวเลขไม่ใช่ลดลง
nibot

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

ฉันสามารถใช้รูปแบบจุดคงที่ที่มีมากกว่า 52 บิต
nibot

เนื่องจากคุณต้องการอย่างน้อย 16 บิตสำหรับส่วนจำนวนเต็มของการกำหนดจุดแบบคงที่คุณจะได้รับมากกว่า 64 บิตดังนั้นคุณอาจดูรูปแบบที่ CPU ของคุณไม่มีแม้แต่คำสั่งจำนวนเต็มพื้นฐาน ในกรณีนี้คุณอาจใช้ไลบรารี่ขนาดใหญ่ที่มีอยู่หรือคล้ายกัน คำถามที่สำคัญที่สุดในการตอบคือ: คุณต้องการความแม่นยำมากแค่ไหน?
Paul R

3

นอกจากคำตอบที่ดีมาก ๆ ที่ให้ไว้ที่นี่แล้วมีบางสิ่งที่ควรค่าเพิ่มเติม:

  • มีสถานการณ์ที่แม้ว่าคุณจะมีความต้องการขั้นพื้นฐานมากในช่วงไดนามิกของข้อมูลที่คุณดำเนินการคุณจะยังคงต้องการความแม่นยำที่ดีมากสำหรับการดำเนินการบางอย่างที่ทำกับมันตัวอย่างเช่นคุณจะต้องการใช้ตัวกรอง IIR ต้องการสัมประสิทธิ์ที่ค่อนข้างเล็ก และการตัดทอนพวกเขาจะทำให้เกิดความไม่แน่นอน ทันทีที่ระบบของคุณมีข้อเสนอแนะมีโอกาสที่ดีที่ปัญหา quantization / truncation จะกัดคุณกลับเมื่อใช้จุดคงที่ - คุณต้องระมัดระวังมากขึ้นเกี่ยวกับสิ่งต่าง ๆ เช่นทอพอโลยีโครงสร้างและแผนการตัด / การตัดเศษส่วน
  • แตกต่างจากสถาปัตยกรรม DSP / DSC หลายตัว x86 ไม่มีการดำเนินการจำนวนเต็มแบบอิ่มตัว (เช่นนั้นจะอยู่ใน SSE ไม่ใช่รหัสสเกลาร์มาตรฐาน) ซึ่งหมายความว่าในกรณีที่มีการล้น, สิ่งเลวร้ายสามารถเกิดขึ้นได้ - ค่าการเปลี่ยนสัญญาณและ "การห่อ" คุณจะต้องระมัดระวังเป็นพิเศษกับโอเวอร์โฟลว์และช่วงไดนามิกหรือการทดสอบการโรยบนช่วงตัวถูกดำเนินการทั่วรหัสของคุณ นี่อาจเป็นอันตรายต่อประสิทธิภาพการทำงาน โดยการเปรียบเทียบจุดลอยตัวมีความยืดหยุ่นมากขึ้นสำหรับปัญหาเหล่านี้เนื่องจากช่วงไดนามิกขนาดใหญ่ให้ "headroom" มากขึ้นและการไหลล้นจะไม่นำไปสู่ความล้มเหลวที่ร้ายแรง รหัสการประมวลผลสัญญาณเสียงส่วนใหญ่ที่รันบนคอมพิวเตอร์เดสก์ท็อปกำลังใช้ช่วง -1.0 .. 1.0, ความแม่นยำเดียวหรือสองครั้ง; ดังนั้นสิ่งนี้จึงให้ความสำคัญมากกว่าร้อยเดซิเบล ฉันได้เขียนรหัสการประมวลผลสัญญาณเสียงด้วยวิธีการทั้งสองและเมื่อใช้จุดลอยมีเพียงไม่กี่สถานที่เมื่อฉันต้องคลิป / อิ่มตัวสัญญาณอย่างชัดเจน - โดยปกติจะอยู่ที่ส่วนท้ายของห่วงโซ่การประมวลผลสัญญาณหรือในสถานที่ที่มีข้อเสนอแนะ

1

บางจุดที่ต้องพิจารณา:

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

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


ฉันไม่ได้ตั้งใจจะบอกว่าฉันจะใช้กางเกงขาสั้น 16 บิตเพื่อบรรจุปริมาณของฉัน แต่ค่อนข้างคล้ายกับรูปแบบจุดคงที่ 64 บิตที่มีจำนวนเต็ม 16 บิตและส่วนที่เป็นเศษส่วน 48 บิต แรงจูงใจคือถ้าฉันไม่ได้ใช้บิตเลขชี้กำลังในรูปแบบจุดลอยตัวส่วนใหญ่แล้วความแม่นยำเชิงตัวเลขของฉันจะดีขึ้นหรือไม่ถ้าฉันใช้บิตเหล่านั้นเพื่อให้เป็นตัวเลขนัยสำคัญเพิ่มเติม
nibot

คุณควรเพิ่มจำนวนเต็ม 16 บิต + เศษส่วน 48 บิตให้กับคำถามเดิม ดูเหมือนว่า215ทำให้เกิดความสับสน
Christopher Felton

อีกสิ่งหนึ่ง: สำหรับฉันแล้ว StackOverflow (แทนที่จะเป็น DSP.SE ที่นี่) จะเป็นสถานที่ที่เหมาะที่สุดที่จะได้รับเหตุผลที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับข้อดีและข้อเสียของรูปแบบหนึ่งมากกว่าอีกรูปแบบหนึ่ง
heltonbiker
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.