ฉันควรใช้การคูณหรือการหาร?

นี่เป็นคำถามสนุก ๆ โง่ ๆ :

สมมติว่าเราต้องดำเนินการง่ายๆโดยที่เราต้องการครึ่งหนึ่งของค่าของตัวแปร โดยทั่วไปมีสองวิธีในการดำเนินการนี้:

y = x / 2.0;
// or...
y = x * 0.5;

สมมติว่าเราใช้โอเปอเรเตอร์มาตรฐานที่ให้มาพร้อมกับภาษาอันไหนมีประสิทธิภาพดีกว่ากัน?

ฉันเดาว่าการคูณมักจะดีกว่าดังนั้นฉันจึงพยายามยึดติดกับสิ่งนั้นเมื่อฉันเขียนโค้ด แต่ฉันต้องการยืนยันสิ่งนี้

แม้ว่าโดยส่วนตัวแล้วฉันสนใจคำตอบสำหรับPython 2.4-2.5 แต่อย่าลังเลที่จะโพสต์คำตอบสำหรับภาษาอื่น ๆ ! และหากคุณต้องการอย่าลังเลที่จะโพสต์วิธีที่น่าสนใจอื่น ๆ (เช่นการใช้ตัวดำเนินการกะบิต) เช่นกัน

งูหลาม:

time python -c 'for i in xrange(int(1e8)): t=12341234234.234 / 2.0'
real    0m26.676s
user    0m25.154s
sys     0m0.076s

time python -c 'for i in xrange(int(1e8)): t=12341234234.234 * 0.5'
real    0m17.932s
user    0m16.481s
sys     0m0.048s

การคูณเร็วขึ้น 33%

Lua:

time lua -e 'for i=1,1e8 do t=12341234234.234 / 2.0 end'
real    0m7.956s
user    0m7.332s
sys     0m0.032s

time lua -e 'for i=1,1e8 do t=12341234234.234 * 0.5 end'
real    0m7.997s
user    0m7.516s
sys     0m0.036s

=> ไม่มีความแตกต่างอย่างแท้จริง

LuaJIT:

time luajit -O -e 'for i=1,1e8 do t=12341234234.234 / 2.0 end'
real    0m1.921s
user    0m1.668s
sys     0m0.004s

time luajit -O -e 'for i=1,1e8 do t=12341234234.234 * 0.5 end'
real    0m1.843s
user    0m1.676s
sys     0m0.000s

=> เร็วขึ้นเพียง 5%

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

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

การเพิ่มประสิทธิภาพก่อนวัยเป็นรากเหง้าของความชั่วร้ายทั้งหมด จำกฎสามข้อของการเพิ่มประสิทธิภาพไว้เสมอ!

1. อย่าเพิ่มประสิทธิภาพ
2. หากคุณเป็นผู้เชี่ยวชาญโปรดดูกฎ # 1

3. หากคุณเป็นผู้เชี่ยวชาญและสามารถพิสูจน์ความต้องการได้ให้ใช้ขั้นตอนต่อไปนี้:

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

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

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

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

การคูณเร็วขึ้นการหารแม่นยำยิ่งขึ้น คุณจะสูญเสียความแม่นยำหากตัวเลขของคุณไม่ใช่เลข 2:

y = x / 3.0;
y = x * 0.333333;  // how many 3's should there be, and how will the compiler round?

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

x = 100.0;
x / 3.0 == x * (1.0/3.0)  // is false in the test I just performed

ปัญหาความเร็วมีแนวโน้มที่จะมีความสำคัญในภาษา C / C ++ หรือ JIT เท่านั้นและแม้ว่าการดำเนินการจะวนซ้ำที่คอขวดเท่านั้น

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

y = x * (1.0 / 2.0);

คอมไพเลอร์ควรจะทำการหารได้ในเวลาคอมไพล์ดังนั้นคุณจะได้รับการคูณ ณ รันไทม์ ฉันคาดหวังว่าความแม่นยำจะเหมือนกับในy = x / 2.0เคส

ในกรณีที่สิ่งนี้อาจมีความสำคัญ LOT อยู่ในโปรเซสเซอร์แบบฝังซึ่งจำเป็นต้องมีการจำลองจุดลอยตัวเพื่อคำนวณเลขคณิตทศนิยม

แค่จะเพิ่มบางอย่างสำหรับตัวเลือก "ภาษาอื่น ๆ "
C: เนื่องจากนี่เป็นเพียงแบบฝึกหัดทางวิชาการที่ไม่สร้างความแตกต่างฉันจึงคิดว่าจะมีส่วนร่วมในสิ่งที่แตกต่าง

ฉันรวบรวมเพื่อประกอบโดยไม่มีการปรับให้เหมาะสมและดูที่ผลลัพธ์
รหัส:

int main() {

    volatile int a;
    volatile int b;

    asm("## 5/2\n");
    a = 5;
    a = a / 2;

    asm("## 5*0.5");
    b = 5;
    b = b * 0.5;

    asm("## done");

    return a + b;

}

รวบรวมด้วย gcc tdiv.c -O1 -o tdiv.s -S

หารด้วย 2:

movl    $5, -4(%ebp)
movl    -4(%ebp), %eax
movl    %eax, %edx
shrl    $31, %edx
addl    %edx, %eax
sarl    %eax
movl    %eax, -4(%ebp)

และการคูณด้วย 0.5:

movl    $5, -8(%ebp)
movl    -8(%ebp), %eax
pushl   %eax
fildl   (%esp)
leal    4(%esp), %esp
fmuls   LC0
fnstcw  -10(%ebp)
movzwl  -10(%ebp), %eax
orw $3072, %ax
movw    %ax, -12(%ebp)
fldcw   -12(%ebp)
fistpl  -16(%ebp)
fldcw   -10(%ebp)
movl    -16(%ebp), %eax
movl    %eax, -8(%ebp)

อย่างไรก็ตามเมื่อฉันเปลี่ยนints เป็นdoubles (ซึ่งเป็นสิ่งที่ python น่าจะทำ) ฉันได้รับสิ่งนี้:

แผนก:

flds    LC0
fstl    -8(%ebp)
fldl    -8(%ebp)
flds    LC1
fmul    %st, %st(1)
fxch    %st(1)
fstpl   -8(%ebp)
fxch    %st(1)

คูณ:

fstpl   -16(%ebp)
fldl    -16(%ebp)
fmulp   %st, %st(1)
fstpl   -16(%ebp)

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

ตามบันทึกข้างคุณจะเห็นว่าในโปรแกรมของฉันผลตอบแทนmain() a + bเมื่อฉันนำคีย์เวิร์ดที่ระเหยออกไปคุณจะไม่มีทางเดาได้เลยว่าแอสเซมบลีมีลักษณะอย่างไร (ไม่รวมการตั้งค่าโปรแกรม):

## 5/2

## 5*0.5
## done

movl    $5, %eax
leave
ret

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

ขออภัยสำหรับคำตอบที่ยาวเกินไป

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

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

หากคุณยังอยากรู้อยากเห็นจากมุมมองการเพิ่มประสิทธิภาพระดับต่ำ:

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

ระยะเวลาที่ความแตกต่างของท่อขึ้นอยู่กับฮาร์ดแวร์อย่างสมบูรณ์ ฮาร์ดแวร์ล่าสุดที่ฉันใช้คือ 9 รอบสำหรับการคูณ FPU และ 50 รอบสำหรับการหาร FPU ฟังดูมาก แต่คุณจะสูญเสีย 1,000 รอบสำหรับการพลาดความทรงจำเพื่อที่จะได้มองเห็นสิ่งต่างๆ

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

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

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

เขียนตามที่ระบุเจตนาของคุณชัดเจนกว่า

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

อย่าทำแบบอื่น

ทำทุกอย่างที่คุณต้องการ นึกถึงผู้อ่านของคุณก่อนอย่ากังวลกับประสิทธิภาพจนกว่าคุณจะแน่ใจว่าคุณมีปัญหาด้านประสิทธิภาพ

ให้คอมไพเลอร์ทำประสิทธิภาพให้คุณ

หากคุณกำลังทำงานกับจำนวนเต็มหรือประเภทจุดลอยตัวอย่าลืมตัวดำเนินการบิทชิฟต์ของคุณ: << >>

    int y = 10;
    y = y >> 1;
    Console.WriteLine("value halved: " + y);
    y = y << 1;
    Console.WriteLine("now value doubled: " + y);

จริงๆแล้วมีเหตุผลที่ดีที่ตามกฎทั่วไปของการคูณด้วยหัวแม่มือจะเร็วกว่าการหาร ลอยส่วนจุดในฮาร์ดแวร์จะทำทั้งที่มีการเปลี่ยนแปลงและขั้นตอนวิธีลบเงื่อนไข ( "หารยาว" กับเลขฐานสอง) หรือ - มีแนวโน้มวันนี้ - ด้วยซ้ำเช่นอูแบรต์ของ อัลกอริทึมการเปลี่ยนและลบต้องการความแม่นยำอย่างน้อยหนึ่งรอบต่อบิต (การทำซ้ำแทบจะเป็นไปไม่ได้ที่จะขนานกันเหมือนกับการเลื่อนและการเพิ่มของการคูณ) และอัลกอริทึมแบบวนซ้ำจะทำการคูณอย่างน้อยหนึ่งครั้งต่อการวนซ้ำไม่ว่าในกรณีใดก็เป็นไปได้สูงที่การแบ่งจะใช้รอบมากขึ้น แน่นอนว่าสิ่งนี้ไม่ได้คำนึงถึงความแปลกประหลาดในคอมไพเลอร์การเคลื่อนย้ายข้อมูลหรือความแม่นยำ แม้ว่าโดยทั่วไปแล้วถ้าคุณกำลังเขียนโค้ดวงในในส่วนที่ไวต่อเวลาของโปรแกรมการเขียน0.5 * xหรือ1.0/2.0 * xมากกว่าx / 2.0เป็นสิ่งที่ควรทำ ความอวดดีของ "รหัสที่ชัดเจนที่สุด" นั้นเป็นเรื่องจริงอย่างแน่นอน แต่ทั้งสามอย่างนี้มีความใกล้เคียงกันมากจนคนอวดรู้ในกรณีนี้เป็นเพียงการอวดรู้

ฉันเรียนรู้มาตลอดว่าการคูณมีประสิทธิภาพมากกว่า

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

การหารจุดลอยตัวนั้น (โดยทั่วไป) ช้าเป็นพิเศษดังนั้นในขณะที่การคูณจุดลอยตัวนั้นค่อนข้างช้า แต่ก็น่าจะเร็วกว่าการหารจุดลอยตัว

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

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

ระวัง "โดยทั่วไปการเดาการคูณจะดีกว่าดังนั้นฉันจึงพยายามยึดติดกับสิ่งนั้นเมื่อฉันเขียนโค้ด"

ในบริบทของคำถามเฉพาะนี้หมายถึง "เร็วกว่า" ในที่นี้ดีกว่า ซึ่งไม่มีประโยชน์มากนัก.

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

ดูเลขคณิต Floating Point ที่มีการวิเคราะห์ข้อผิดพลาด ดูปัญหาพื้นฐานใน Floating Point คณิตศาสตร์และการวิเคราะห์ข้อผิดพลาด

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

ปัญหาใหญ่ที่สุดมาจากการพยายามจัดการตัวเลขสองตัวที่เกือบเท่ากัน บิตขวาสุด (บิตข้อผิดพลาด) เข้ามาครอบงำผลลัพธ์

>>> for i in range(7):
...     a=1/(10.0**i)
...     b=(1/10.0)**i
...     print i, a, b, a-b
... 
0 1.0 1.0 0.0
1 0.1 0.1 0.0
2 0.01 0.01 -1.73472347598e-18
3 0.001 0.001 -2.16840434497e-19
4 0.0001 0.0001 -1.35525271561e-20
5 1e-05 1e-05 -1.69406589451e-21
6 1e-06 1e-06 -4.23516473627e-22

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

ฉันเคยอ่านพบว่าการคูณมีประสิทธิภาพมากกว่าใน C / C ++ ไม่มีความคิดเกี่ยวกับภาษาที่ตีความ - ความแตกต่างอาจเล็กน้อยเนื่องจากค่าใช้จ่ายอื่น ๆ ทั้งหมด

เว้นเสียแต่ว่ามันจะกลายเป็นปัญหาที่ยึดติดกับสิ่งที่บำรุงรักษา / อ่านได้มากกว่า - ฉันเกลียดมันเมื่อมีคนบอกฉัน แต่มันเป็นเรื่องจริง

ผมขอแนะนำให้คูณโดยทั่วไปเพราะคุณไม่ต้องใช้รอบเพื่อให้แน่ใจว่าตัวหารของคุณไม่ใช่ 0 แน่นอนว่าจะใช้ไม่ได้ถ้าตัวหารของคุณเป็นค่าคงที่

Java android มีโปรไฟล์บน Samsung GT-S5830

public void Mutiplication()
{
    float a = 1.0f;

    for(int i=0; i<1000000; i++)
    {
        a *= 0.5f;
    }
}
public void Division()
{
    float a = 1.0f;

    for(int i=0; i<1000000; i++)
    {
        a /= 2.0f;
    }
}

ผล?

Multiplications():   time/call: 1524.375 ms
Division():          time/call: 1220.003 ms

หารเร็วกว่าการคูณ (!) ประมาณ 20%

เช่นเดียวกับโพสต์ # 24 (การคูณเร็วขึ้น) และ # 30 - แต่บางครั้งก็เข้าใจง่ายเหมือนกัน:

1*1e-6F;

1/1e6F;

~ ฉันพบว่าทั้งคู่อ่านง่ายและต้องอ่านซ้ำหลายพันล้านครั้ง ดังนั้นจึงมีประโยชน์ที่จะรู้ว่าการคูณมักจะเร็วกว่า

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

บน Pentium 4, 2.8 GHz, เทียบกับ 2003:

• การคูณ: 8.09
• หาร: 7.97

สำหรับ Xeon W3530, vs2003:

• การคูณ: 4.68
• กอง: 4.64

สำหรับ Xeon W3530, vs2010:

• การคูณ: 5.33
• กอง: 21.05.2018

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

แก้ไขเมื่อ 18-03-2556: ข้อสังเกตสำหรับ vs2010

นี่คือคำตอบสนุก ๆ โง่ ๆ :

x / 2.0เป็นไม่เทียบเท่ากับx 0.5 *

สมมติว่าคุณเขียนวิธีนี้เมื่อ 22 ต.ค. 2551

double half(double x) => x / 2.0;

ตอนนี้ 10 ปีต่อมาคุณได้เรียนรู้ว่าคุณสามารถเพิ่มประสิทธิภาพโค้ดชิ้นนี้ได้ วิธีนี้อ้างอิงในหลายร้อยสูตรตลอดแอปพลิเคชันของคุณ ดังนั้นคุณจึงเปลี่ยนและพบกับการปรับปรุงประสิทธิภาพที่น่าทึ่ง 5%

double half(double x) => x * 0.5;

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

double quantize(double x)
{
    if (half(x) > threshold))
        return 1;
    else
        return -1;
}

บรรทัดล่างคือ; เมื่อคุณได้ข้อใดข้อหนึ่งจากทั้งสองแล้วก็จงยึดมันไว้!

ถ้าเราสมมติว่าการดำเนินการ add / subtrack มีค่าใช้จ่าย 1 แล้วคูณด้วยต้นทุน 5 และหารต้นทุนประมาณ 20

หลังจากการสนทนาที่ยาวนานและน่าสนใจนี่คือสิ่งที่ฉันทำ: ไม่มีคำตอบสุดท้ายสำหรับคำถามนี้ เป็นบางคนชี้ให้เห็นว่ามันขึ้นอยู่กับทั้งฮาร์ดแวร์ (CF piotrkและgast128 ) และคอมไพเลอร์ (CF @Javierทดสอบ 's) หากความเร็วไม่สำคัญหากแอปพลิเคชันของคุณไม่จำเป็นต้องประมวลผลข้อมูลจำนวนมากแบบเรียลไทม์คุณอาจเลือกใช้ความชัดเจนโดยใช้การแบ่งส่วนหากความเร็วในการประมวลผลหรือภาระของโปรเซสเซอร์เป็นปัญหาการคูณอาจจะปลอดภัยที่สุด สุดท้ายนี้หากคุณไม่ทราบแน่ชัดว่าแอปพลิเคชันของคุณจะนำไปใช้งานบนแพลตฟอร์มใดเกณฑ์มาตรฐานก็ไม่มีความหมาย และเพื่อความชัดเจนของรหัสความคิดเห็นเดียวจะทำงานได้!

ในทางเทคนิคไม่มีสิ่งที่เรียกว่าการหารมีเพียงการคูณด้วยองค์ประกอบผกผัน ตัวอย่างเช่นคุณไม่เคยหารด้วย 2, คุณคูณด้วย 0.5

'ส่วน' - เด็กให้ของตัวเองว่ามันมีอยู่เป็นครั้งที่สอง - อยู่เสมอยากที่คูณเพราะ 'หาร' xโดยyหนึ่งในความต้องการเป็นครั้งแรกในการคำนวณค่าy^{-1}ดังกล่าวว่าแล้วทำคูณy*y^{-1} = 1 x*y^{-1}ถ้าคุณรู้y^{-1}แล้วไม่คำนวณจากyต้องเป็นการเพิ่มประสิทธิภาพ