ยินดีครับ ดีใจที่ได้ทราบว่า ข้อเขียนของผมยังมีผู้เห็นประโยชน์อยู่

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

และยังมีเหตุผลทางด้านเวลา ที่ผมไม่สามารถแบ่งเวลาให้ได้พอที่จะดูแลถึงขั้นทำ Blog ของตัวเองได้

ถึงกระทั่งหนังสือ สมัยก่อนพิมพ์ด้วย RW แล้วส่งไฟล์ให้ Edtior ก็พอแล้ว ทางนั้นจะเกลาให้ เรียบเรียงใหม่ ตรวจแก้ไข จัดเรียงพิมพ์ให้เอง ไอ้ผมมันก็คนนิสัยชอบพิมพ์สดๆ รวดเดียว ในลักษณะของการเล่าประสบการณ์ มาสมัยนี้มันกลายเป็นภาระของผู้เขียนไปตลอดจนถึงการวาง Layout ของ Content ไปเสียแล้ว

การเล่าของผม ผมจะไม่เล่า "ความรู้" เพราะเป็นสิ่งที่หาได้ง่ายเรียนรู้อยู่แล้ว ผมยึดลำดับการเกิดความเป็นจริงที่ว่า

• ข้อเท็จจริง (Fact) คือสิ่งที่มีอยู่แล้ว ตั้งอยู่แล้ว รอบตัวเรา เป็นเงื่อนไขธรรมชาติ

• ประสบการณ์ (Experience) คือวิธีการค้นพบข้อเท็จจริงใดๆ ด้วยสติปัญญาของมนุษย์

• ความรู้ (Knowledge) คือบันทึกผลของประสบการณ์ ซึ่งเป็นแบบสรุป คัดย่อ ตัดทอน เพราะถูกจำกัดด้วยความจุของสื่อบันทึกและข้อจำกัดของการสื่อสารระหว่างมนุษย์ด้วยกันเอง

ในการร่ำเรียนของมนุษย์ ก็ไม่ต่างจากหลักการทาง Programming language นั่นคือ เริ่มเรียนจาก Knowledge เพื่อไม่ต้องเสียเวลาเริ่มกันจาก "การค้นหาข้อเท็จจริง" เพื่อให้มนุษย์นำไป Apply ต่อยอดต่อไปได้เลย เพราะข้อจำกัดที่สำคัญของเราคือ ช่วงชีวิต

เมื่อมีการค้นพบข้อเท็จจริงมากขึ้นเท่าไหร่ เวลาใน 1 ชีวิตของมนุษย์ก็ยิ่งไม่มีมากพอที่จะเรียนรู้จาก Base ขึ้นไปได้มากเท่านั้น จึงต้องตัดทอนเป็น Layer ออกไป ในขณะเดียวกันยิ่งมนุษย์เอาไป Apply ต่อยอดมากเท่าไหร่ ในอีกด้านของการเรียนรู้ ก็ยิ่งมีนวตกรรม/เทคโนโลยีให้เรียนรู้มากขึ้นเท่านั้น

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

อธิบายเท่านี้ คงจะพอเข้าใจได้ว่า Concept ผมคืออะไร จุดยืนผมอยู่ตรงไหน

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

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

จบเรื่องปรัชญาดีกว่า มาเข้าเรื่อง Technic ที่ผมถนัดต่อดีกว่าครับ

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

Reply ที่แล้ว มีคนบอกผมว่า ผมพิมพ์ผิดอยู่สองแห่ง (Serious mis-typing) นะครับ ตรง Assembly code ใน Step ที่ 5) และ 8) ที่ผมพิมพ์เป็น cx และ dx ต้องเป็น bx และ cx นะครับ ที่ผิดตรงนี้มันถึงขั้นทำให้คนที่พยายามทำความเข้าใจตาม อาจทำยังไงก็ไม่อาจเข้าใจได้ เลยต้องแก้ครับ

จาก Reply ที่แล้ว เป็น Overhead แรกที่มีมากที่สุด ถ้าเอาประสบการณ์มาเล่าเป็น Case ก็จะเยอะมากมาย ขาดเขียนตำราหากินไปได้ตลอดชีวิตเลยทีเดียว นี่เป็นเหตุผลที่ผมได้เคยพูดว่า "Case ผมเยอะ" เพราะจะเอาตรงไหน Appliationใด โปรแกรมอะไร Platform ใด ที่เป็น High Level มาเป็นโจทย์ ก็ใช้ได้หมดโลก ตั้งแต่อดีตจนถึงปัจจุบัน และยังคงมีต่อไปในอนาคตครับ

Reply นี้จะขอเล่ากรณีที่สอง ซึ่งเป็น Overhead รอง เพราะบาง Compiler สร้าง Compiler directive และ/หรือ Macro ให้พอจะแก้ไขข้อจำกัดทางภาษาในกรณีนี้ได้ แต่ไม่มีความสามารถนี้ใน Compiler ทั้งหมดบน PC นะครับ มีในระดับ ARM และพวก Microcontroller ลงไป

นั่นคือการ กำหนด Instruction Algorithm ได้

ผมจะสมมติตัวอย่าง C Code แบบง่ายๆ หยาบๆ นะครับ

do

i += j;

{

if (condition) j--;

i++;

}

} while (another_condition);

ด้วยข้อจำกัดทางภาษา ใน Statement ที่ว่า i += j; จะแตกออกเป็น Native ที่ต้อง Load ค่า i และ j มาบวกกัน และค่าจะคาอยู่ที่ ax (ผมไม่ได้พูดถึง Overhead จากการ Load ไป/มาระหว่าง Register และ Memory ซึ่งมีอยู่แล้วแน่นอนนะครับ ขอให้ทำความเข้าใจตามดีๆ)

หลังจากตรวจสอบ condition แล้ว ถ้าเป็นเท็จ ก็จะต่อไป i++ ซึ่ง Native ที่ได้จะทำการ Load ค่าจาก Memory มาสู่ ax Register ใหม่อีกครั้งเสมอ เพราะภาษาต้องป้องกันกรณีที่ condition เป็นจริง ซึ่งค่าใน ax จะกลายเป็นค่าของ j ไปแล้ว

นี่คือข้อจำกัดทางภาษา ที่ไม่สามารถกำหนด Algorithm ลงไปขนาดนั้นได้ครับ ในเมื่อเราทราบว่า ค่า i คือสิ่งที่เราสนใจอยู่ แต่เพราะตัวภาษาไม่อาจทราบได้ว่า เจตนาของ Algorithm เป็นเช่นนั้น ไม่ว่า Compiler จะ AI ขนาดไหนในปัจจุบันนี้ ก็ไม่มีตัวไหนมีปัญญาทำความเข้าใจเจตนาของผู้ Coding จนผลิต Native ให้ออกมา Optimize ได้แบบดังต่อไปนี้ครับ... (Assembly หยาบๆ เช่นเคยนะครับ)

1).... 9) ขอข้าม i += j; ไปเลยนะครับ เพราะส่วนนี้ได้ Code ที่ Optimize กว่าอยู่แล้วตามกรณีแรก แต่นี่ผมกำลังอธิบาย OVerhead กรณีที่สองนะครับ

ตรง if (condition) j--; จะได้ Native ประมาณว่า

test condition // หรือ Flag อะไรก็ได้จากการเช็ค condition - ไม่ใช่จุดสนใจเลยขอหยาบๆ

jz NEXT

move ax,[Address ของ j]

dec ax

move [Address ของ j],ax

NEXT:

ตรง i++; จะได้ Native ประมาณว่า

move ax,[Address ของ i]

inc ax

move [Address ของ i], ax

Instruction สุดท้าย เป็น Overhead ของกรณีแรกนะครับ ไม่ใช่สิ่งที่ผมสนใจในขณะที่อธิบายกรณีที่สองอยู่นี้

Instruction ที่สองจากท้าย ได้ผลเหมือน Assembly เท่ากันอยู่แล้ว แต่... ดูที่ Instruction ที่สามจากท้ายครับ กับสังเกตุหลังตรวจสอบ condition ร่วมนะครับ

เพราะภาษาต้องปิดงานในทุก Statement ของภาษาเอง อีกทั้งไม่มี Compiler ใดเข้าใจเจตนาของผู้เขียนได้ ในขณะที่เมื่อเขียนเป็น Assembly แล้ว เราสามารถวาง Code ใหม่ ให้ทำงานเร็วขึ้นอีกเป็นร้อยเท่าตัวได้ง่ายๆ เช่นตัวอย่างหยาบๆ ต่อไปนี้ครับ

test condition // หรือ Flag อะไรก็ได้จากการเช็ค condition - ไม่ใช่จุดสนใจเลยขอหยาบๆ

jz NEXT

move ax,[Address ของ j]

dec ax

move [Address ของ j],ax

move ax,[Address ของ i]

NEXT:

inc ax

move [Address ของ i], ax

สังเกตุนะครับ ผมแค่ย้าย move ax,[Address ของ i] เท่านั้น ความเร็วเพิ่มขึ้นหลายร้อยเท่าตัวทันทีครับ เพราะเราทราบอยู่แล้วว่า ถ้า condition ไม่เป็นจริงแล้ว ค่าใน ax ยังคงเป็นค่าของ i อยู่เช่นเดิม จังไม่จำเป็นต้อง Load ค่ามาจาก Memory ใหม่ ซึ่งใช้เวลานานมาก แม้กระทั่ง Memory ที่เร็วที่สุดในปัจจุบัน ก็ยังใช้เวลานานกว่าการถ่ายเทค่าภายใน Register ที่อยู่ในตัว Processor เองถึงหลายร้อยเท่าตัวขึ้นไป

นี่ผมยังไม่แสดงถึงว่า แค่ Code นี้ เรา Optimize ได้มากกว่านี้อีก ถ้าจัดวางลำดับ Instruction ใหม่เท่านั้นเอง โดยที่ไม่ได้ลดขนาด Native code ลงด้วยนะครับ (อันนั้นมันเข้าสู่ Overhead กรณีแรก) นี่คือ Native ได้เท่าเดิมเลย

อ่านมาถึงตรงนี้... คงสงสัยกันอีกแล้วล่ะสิ ไอ้ "บ้าพลัง" นี่ มันเอาตรงไหนมาพล่ามหว่า ใน PC มีด้วยหรือ? (บ้าพลังหรือไม่ ถึงตอนนี้ผู้อ่านคงทราบแล้วว่า ที่จริง ยักษ์ของผมยังนอนกรนอยู่เลยครับ)

มีครับ เอาตัวอย่างบน Windows เช่นเคย ซึ่งผู้อ่านส่วนใหญ่ถนัด ก็เช่น Codec ทั้งหมดไงครับ ไหนจะ Compression tools ทั้งหลายอีก Spread sheet application ทั้งหลาย ...โอย... เยอะแยะไปหมดครับ

ลักษณะ Code ที่ทำ Loop ซ้ำๆ จะแยกประเด็นออกไปทำอย่างอื่นเป็นครั้งคราวตาม Period condition จะเจอ Overhead นี้ของภาษาทั้งนั้น

บนเครื่องทรัพยากรเยอะๆ อย่าง PC ที่สามารถ Coding แบบขี่ไดโนเสาร์จับอะมีบาได้ ก็ไม่จำเป็นต้องให้ความสำคัญในกรณีนี้ไปเสียทั้งหมดในการ Coding โปรแกรมใดๆ แต่อย่างกรณีเช่น Codec ก็หนีไม่พ้นครับ

PC ออกจะแร้งแรง กว่าจะ Decoding HD ได้ลื่น บริโภค Hardware แค่ไหนครับ?

กับอีกหลาย Embedded ที่มีทรัพยากรด้อยกว่ามากๆ แบบเทียบกันไม่ติด เขาก็ตามมา Decoding HD ได้บ้างเพราะอะไร?

และนี่เอง Compiler สำหรับ Processor เล็กๆ เหล่านี้ เลยต้องมี Compiler directive หรือ Macro พิเศษให้ผู้ Coding สามารถลงไปกำหนดลำดับ Instruction ด้วยตัวเองได้นั่นเอง แต่ PC ยังไม่มีเพราะ... เหลือเฟือเหลือเกินนั่นเอง เวลาจะต้องใช้ที เลยต้อง Inline Assembler ใส่ลงไปเลย

และอย่าง Spread sheet application ก็เช่นกัน นี่เป็นคำตอบที่ทำไม OpenOffice Calc ให้ความเร็วสู้ Excel ไม่ได้ และ ณ ตอนนี้ ไม่มีทางสู้ได้แน่นอน เพราะ OOO เป็น Open Source ที่มี Concept เป็น Single code ไปสู่ Multi architecture/Platform จึงต้องเขียนเป็น Pure C ให้มากที่สุด ดังนั้นการ Update แต่ละ Cell ซึ่งมีลักษณะการ Coding เป็น Loop เข้ากรณีที่สองที่ผมอธิบายนี้จึงมีมาก ในขณะที่ Excel นั้น M$ แยก Platform ในการ Compile และ Inline Assembler ในส่วนเหล่านี้ลงไปเพื่อ Optimize Algorithm ให้ได้ Performance สูง ที่จริงแล้ว M$ เขาถึงขนาดแยก Code ในแต่ละ Architecture เลยด้วยครับ

อธิบายกรณีที่สองแค่นี้นะครับ

มีเวลาแล้วจะมาร่ายกรณีต่อๆ ไปให้ เอาสัก 4-5 กรณีแรกก็พอ กรณีหลังๆ มันจะมี Case น้อยลงเรื่อยๆ

เรื่องเหล่านี้ไม่มีในตำราครับ ต่อให้หาบน Internet ก็ไม่มีเนื้อหาลงลึกแบบนี้ เพราะนี่คือการเล่า "ความเป็นจริง" ที่เกิดขึ้นจริงจากประสบการณ์ และดันเป็นสิ่งที่ "เซียน" ส่วนใหญ่ของโลก เขาหวงนักหวงหนา เพราะมันเป็นเหมือนเคล็ดวิชาที่เอาไว้สยบคนอื่นเขาไปได้ทั่ว ใช้เรียกค่าตัวแพงๆ หากินไปได้ตลอด เอาไว้ใช้เป็น Consult ก็ได้ เต๊ะจุ๊ยแล้วคอยตบหัวเด็กรุ่นใหม่ด้วยสิ่งเหล่านี้ แล้วยังได้ค่าตัวแพงอีก (ผมจะโดนดักตีหัวไหมเนี่ย?) ไหนจะยังเอาไว้ใช้ใส่ในผลิตภัณฑ์ของตัวเองให้เหนือกว่าคู่แข่งที่ดันมีแต่ทีมลูกจ้าง Software engineer ที่ไม่ลงลึกพอ (ทำให้ผมมีตลาดหากินอยู่ทุกวันนี้ ตลาดนี้โล่งสบาย คู่แข่งน้อยจนแทบไม่มี ที่มีก็ไม่น่าเรียกว่าคู่แข่ง เพราะเกี่ยงงานกันทั้งนั้น มันทำไม่ทันครับ - มาสิครับ มาจับตลาดนี้กัน คนไทยจะได้ผงาด)

เช่นเดียวกับที่ผมจะบอกว่า ที่มีผู้ใช้ C กล่าวกันเกลื่อนว่า "ผลงานจาก C ได้ Performance เกือบระดับเดียวกัน" ลามไปถึงว่า "เผลอๆ จะดีกว่า" นั้น แค่สองกรณีแรกที่ผมยกข้อจำกัดทางภาษามาอธิบาย ก็เห็นได้แล้วว่า "เป็นไปไม่ได้ที่ C จะได้ Native ที่มี Performance ดีกว่า Assembly" ครับ

เมื่อภาษาอื่นนอกจาก Assembly จัดระดับกันเองแล้ว จะให้ C อยู่ล่างสุด ถือได้ว่าใกล้เคียง Assembly ที่สุดแล้ว นั่นกล่าวถูกต้องครับ แต่อย่าเข้าใจผิดในเรื่องหนึ่งคือ....

ในวิธีการเทียบดังกล่าวนั้น ถ้าดูเฉพาะ Gap ระหว่าง C กับ Assembly แล้ว โดยไม่มี Gap ระหว่าง C กับภาษาอื่นข้างบนมาเป็น Scale วัด ผมจะขอใช้คำว่า "ยังห่างไกล" ครับ ชนิดที่ว่าเป็นไปไม่ได้เลยทีเดียว ที่ Pure C จะได้ Code ที่มี Performace ใกล้เคียง Assembly ได้

ขอให้ผู้ที่ถนัด C ทั้งหลาย จงอย่าใส่ไข่ความรู้/ความเชื่อของตัวเองจนล้นหลามไปแบบนั้นครับ

ยกตัวอย่างข่าวเรื่อง Source code ของ POP (Prince Of Persia) แล้วกันครับ ผู้อ่านไปฮือฮากันที่ Code เป็น Assembly ล้วนๆ แต่... มีใครสังเกตุไหมครับ? ว่า Native ของทั้ง Game รวมไปถึง Data ของ Game ไม่ว่าจะเสียง ดนตรี ตลอดไปจน Story board และ Save Game สามารถบรรจุในแผ่น Diskette ขนาด 720KB ได้?

ขอให้เซียน C ทั้งโลก ลองใช้ Pure C เขียน Game ลักษณะเดียวกัน ละเอียดเท่ากัน มีเนื้อหาเท่ากัน แล้ว Compile ด้วย Compiler ใดๆ ที่เซียนผู้นั้นถนัดที่สุด Optimize ได้เป็นที่สุด เขียนออกมาดูสิครับ ว่าจะทำให้อยู่ใน 720KB ได้ไหม? และยังทำงานบน Processor ที่มีหน่วยความจำเพียงแค่ 640KB ด้วยความเร็วแค่ 16MHz ได้หรือไม่?

เอาสิครับ จะ "บ้าพลัง C" สักแค่ไหน ก็ลองพยายามดูกันนะครับ (C, Pascal และ Assembly ทั้งสามคือภาษาอันดับ 1 ของผม แต่เจอโจทย์อย่างนี้ ผมก็ขอบายล่ะครับ เพราะรู้ว่า เป็นไปไม่ได้)