Programming language หลายภาษาเขียนไปแล้วรันช้าเพราะ type checking

ไม่นับเรื่องใช้หรือไม่ใช้ garbage collection ไม่นับเรื่อง data structure พื้นฐานที่ไม่เหมือนกัน และไม่ได้เขียนเรื่อง compile หรือ interpret ผมสมมุติว่า compile ให้หมดเลยแล้วกันเพราะว่า mruby ก็ยัง compile ได้เลย ทำไม compile แล้วโปรแกรมไม่รันเร็วเท่าเขียน Go เป็นต้น

เมื่อเห็นโปรแกรมเท่านี้

a * b

หรือจะเขียนแบบ Lisp ก็ตามเหมือนกัน

(* a b)

แปลไปเป็น assembly สำหรับ 8088 + 8087 ก็แปลงไปเป็นคำสั่ง แน่ IMUL หรือ FMUL แต่ว่าไม่รู้ว่า type อะไร มันอาจจะเป็น string ก็ได้ อาจจะเป็น list ก็ได้ ก็ check type ก่อน แล้วก็กระโดดไปทำสิ่งที่ควรทำกับ type นั้น check type และกระโดดนี่มันช้ากว่า FMUL อีก โดยเฉพาะการกระโดด CPU ต้องเดาว่าจะข้ามไปทำคำสั่งต่อไปดีหรือเปล่า ซึ่งก็อาจจะเดาผิด ถ้า compiler รู้แต่แรกเลยว่าเป็น type อะไร โปรแกรมมันเร็วขึ้นเพราะไม่ต้องมา check type ตอนรัน

การที่จะรู้ type ได้ก็มีอยู่ 2 อย่าง คือโปรแกรมเมอร์เขียนบอกเองเลย เช่น

(declare (integer a b))

แบบข้างบน compiler เห็นก็เลือก IMUL ได้เลย เพราะรู้แล้วว่า a และ b เป็น integer หรือไม่ compiler ไปหาเอาซึ่งเรียกว่า type inference เช่น

บรรทัดก่อนหน้าเขียน

(setq a 10)

(setq b 20)

แบบนี้ก็รู้อยู่แล้วว่า 10 และ 20 มันเป็น integer แต่เวลาทำจริง ๆ มันก็จะซับซ้อนกว่านี้อีก

แต่บางทีโปรแกรมเมอร์ไม่ได้ประกาศ type รวมถึง inference เองก็ได้ แต่ละภาษาใช้วิธีไม่เหมือนกัน เช่น Go ก็จะไม่ compile บอกให้โปรแกรมเมอร์ไปใส่ type มาจน compiler พอใจ; Common Lisp ต่างออกไปคือ ถ้าไม่รู้ว่า type อะไรก็ compile อยู่ดีแล้วเดี๋ยวค่อยไป check type ตอนรันก็ได้

ทั้งหมดที่ว่ามายังไม่เกี่ยวกับ JIT compilation เลย แต่ความรู้เกี่ยว JIT compilation ของผมจำกัดมาก เคยอ่านแค่ของ Ruby ผ่าน ลักษณะการทำงานคือรันทีแรกก็ check type ไปก่อน ก็จะรู้ type แล้วตอนรันนั่นล่ะ พอรันซ้ำที่เดิมไป 10 ค่อย generate code แบบที่ไม่ต้อง check type ออกมา ทีนี้รอบต่อไปก็จะรันไวขึ้น ปัจจุบัน Ruby ใช้เทคนิค Basic Block Versioning ใน YJIT ซึ่งผมยังไม่ได้อ่านละเอียด

สำหรับคนที่เขียน Common Lisp อาจจะช่างหัว JIT compiler ไปเลยก็ได้ เพราะรู้อยู่แล้วว่าอยากให้ code ส่วน ไหนรันเร็ว ก็ให้ใส่ type เข้าไปตรงนั้น มันก็จะรันเร็วขึ้น ส่วนที่ไม่ได้อยาก optimize ก็แล้วแต่เหตุปัจจัยอื่น ๆ

Reply to this note

Please Login to reply.

Discussion

No replies yet.