on
ข่าวขำๆ ที่คนโดนคงขำไม่ออก และเป็นประเด็นทางเทคนิคการพัฒนาโปรแกรมที่น่าสนใจครับ
เรื่องมีอยู่ว่าทีมพัฒนา Firefox ประสบปัญหา "โปรแกรมคอมไพล์ไม่ผ่าน" เพราะตัวซอร์สโค้ดมีขนาดใหญ่เกินไป จนหน่วยความจำบนเครื่องที่ใช้คอมไพล์ซึ่งเป็นเครื่องแบบ 32 บิตมีไม่พอ
ขั้นตอนการคอมไพล์ Firefox มาให้พวกเราๆ ใช้ดาวน์โหลดกัน สำหรับเวอร์ชันวินโดวส์จะทำบนเครื่องที่ใช้ระบบปฏิบัติการวินโดวส์แบบ 32 บิต ด้วย Microsoft Visual C++ 2005 ซึ่งใช้มานานแล้ว ส่วนเทคนิคการปรับแต่งประสิทธิภาพจะใช้เทคนิคที่เรียกว่า Profile-Guided Optimisation (PGO) ที่ช่วยรีดประสิทธิภาพได้ประมาณ 10% แต่ก็เปลืองหน่วยความจำระหว่างคอมไพล์มาก
ปัญหาคือซอร์สโค้ดของ Firefox (ไม่ใช่ตัวไฟล์ไบนารี) มีขนาดใหญ่มากขึ้นเรื่อยๆ จนหน่วยความจำที่ต้องใช้ขณะคอมไพล์มีเยอะเกินหน่วยความจำที่อ้างอิงได้แบบ 32 บิตเสียแล้ว ผลคือ Mozilla ต้องหยุดคอมไพล์ Firefox รุ่นที่กำลังพัฒนาชั่วคราว
วิศวกรของ Mozilla เสนอทางแก้ 3 แนวทาง
- ลดขนาดของโค้ดลง โดยอาจตัดโค้ดบางส่วน (เช่น libxul) ออกเป็นไลบรารีแยกต่างหาก
- ย้ายไปใช้ Visual C++ 2010 ที่อาจจะมีประสิทธิภาพดีกว่า Visual C++ 2005
- เปลี่ยนไปคอมไพล์บนเครื่องแบบ 64 บิตที่อ้างอิงหน่วยความจำได้เยอะกว่า (แต่ยังคอมไพล์แบบ 32 บิต)
แนวทางที่เป็นไปได้คงเป็นการผสมกันระหว่างข้อ (1) และ (3) ครับ
ที่มา - mozilla.dev.platform, Softpedia
ขำดีไหมเนี่ย
lingjaidee Tue, 13/12/2011 - 19:43
ขำดีไหมเนี่ย ปัญหาขององค์กรระดับนี้ -_-'
มันเป็นสิ้งที่ไม่ควรเกิดใช่ไห
tg-thaigamer Tue, 13/12/2011 - 19:50
มันเป็นสิ้งที่ไม่ควรเกิดใช่ไหมอ่ะครับ
ทำ 3
darkleonic Tue, 13/12/2011 - 19:56
ทำ 3 อย่างพร้อมกันครับ
แต่ให้เลือก ผมว่าเลือกอัน 3 ตรงประเด็นสุด
ซ้ำ
put4558350 Tue, 13/12/2011 - 23:05
In reply to ทำ 3 by darkleonic
ซ้ำ
1 กับ 2
put4558350 Tue, 13/12/2011 - 22:54
In reply to ทำ 3 by darkleonic
1 กับ 2 ทำแล้วโปรแกรมเร็วขึ้นนะครับ
1 จะเร็วขึ้นมาก แต่งานช้าง
2 จะเร็วขึ้นนิดหน่อย งานก็น้อยตาม
3 เหมือนแก้ปัญหาชั่วคราวแต่ก็ง่ายและเร็วที่สุด
ผมคิดว่ามันก็เป็นปัญหาทางเทคน
Manta Tue, 13/12/2011 - 19:56
ผมคิดว่ามันก็เป็นปัญหาทางเทคนิคที่เกิดขึ้นได้ ไม่ใช่เรื่องบังเอิญหรือแปลกแต่อย่างใด
วิธีทางแก้ด้วยวิธีที่ 3 น่าจะเป็นการแก้ที่สาเหตุมากที่สุดครับ
ปัญหาแปลกๆ
atheist Tue, 13/12/2011 - 20:00
ปัญหาแปลกๆ มันก็เกิดกับทุกองค์กร ต่างกันที่ว่าจะเปิดเผยหรือไม่
ย้ายไปใช้ Visual C++ 2010
azx Tue, 13/12/2011 - 20:43
ย้ายไปใช้ Visual C++ 2010 เถอะ
เรื่องธรรมดานี่ครับ Chrome
sake Tue, 13/12/2011 - 20:48
เรื่องธรรมดานี่ครับ Chrome เองก็แนะนำให้ใช้ OS 64bits ในการ build เหมือนกัน
ตอนใช้ก็บริโภคแรม ตอนคอมไพล์ก
kswisit Tue, 13/12/2011 - 21:03
ตอนใช้ก็บริโภคแรม
ตอนคอมไพล์ก็บริโภคแรม
???
McKay Tue, 13/12/2011 - 22:13
In reply to ตอนใช้ก็บริโภคแรม ตอนคอมไพล์ก by kswisit
???
ผมหมายถึงตอนใช้งาน เปิดแค่
kswisit Tue, 13/12/2011 - 23:10
In reply to ??? by McKay
ผมหมายถึงตอนใช้งาน เปิดแค่ 3แทป ซัดแรมไป 200+ Mb ละครับ
ถ้าใช้เครื่อง 64 บิต
bitworld Tue, 13/12/2011 - 21:10
ถ้าใช้เครื่อง 64 บิต การคอมไพล์แบบ 32 บิตยังสามารถอ้างหน่วยความจำมากกว่า 4GB (โดยอุปมา) ได้ด้วยเหรอครับ ผมนึกว่าตัวคอมไพล์สถาปัตย์ไหนก็อ้างได้แค่นั้นซะอีก (ร้างลาการเขียนโปรแกรมมาชาตินึง ไม่ถนัดอย่างแรง เลยไม่ค่อยเข้าใจ ขอผู้รู้มาอธิบายด้วยครับ จะได้เข้าใจข่าวหน่อย พอดีงงตรงข้อ 3)
คิดว่าเป็นที่ compiler นะครับ
hexavision Tue, 13/12/2011 - 21:39
In reply to ถ้าใช้เครื่อง 64 บิต by bitworld
คิดว่าเป็นที่ compiler นะครับ อาจจะรันบนเครื่อง 32bit แล้ว compiler ใช้แรมเกิน 4GB เลยไม่ยอมทำงาน
ถ้าเปลี่ยนไปใช้ compiler ที่ทำงานบน 64bit แต่กำหนด Target เป็น 32bit ก็น่าจะได้
ได้ 4 GB ต่อ process ครับ
McKay Tue, 13/12/2011 - 22:20
In reply to ถ้าใช้เครื่อง 64 บิต by bitworld
ได้ 4 GB ต่อ process ครับ ซึ่งถ้าเป็น 32bit ทุก process รวมกันจะได้ไม่เกินประมาณ 3.0-3.5 ประมาณนี้(ตามจำนวนแรม ไม่นับ vm) และ process ละไม่เกิน 2GB
คิดไปเองหรือเปล่านะเรานี่ คือ
kichinto Tue, 13/12/2011 - 21:47
คิดไปเองหรือเปล่านะเรานี่
คือโลโก้มันเป็น หมาไฟโดนโลกทับตาย ตายทั้งท้องกลมโต อ้วนนั่นเอง หุหุ
4.เปลี่ยนไปใช้ Google chrome
utehn Tue, 13/12/2011 - 22:06
4.เปลี่ยนไปใช้ Google chrome ให้หมดและยุบทีม :)
นึกไม่ออกเลยทีเดียวว่า source
coolmilk Tue, 13/12/2011 - 22:39
นึกไม่ออกเลยทีเดียวว่า source จะยาวขนาดไหน
ผมว่าที่มันยาว
tekkasit Tue, 13/12/2011 - 23:45
ผมว่าที่มันยาว น่าจะเพราะไม่ได้สักแค่คอมไพล์เฉยๆ แต่เพราะมีการใช้เทคนิค Profile-Guided Optimization ที่อาศัยการบันทึกพฤติกรรมการทำงานจริงๆของโปรแกรมรุ่นตัวอย่าง เพื่อมาปรับแต่งโปรแกรมตัวจริงอีกที ซึ่งไอ้รันสองเด้ง แถมต้องเก็บสถิติตลอดนั่นน่าจะตัวเขมือบแรม ทำให้ใช้แรมเกิน 3G (ขีดจำกัดของระบบ 32-bit) ได้ง่ายๆ
จริงๆก็ไปหาเครื่อง 64-bit มาคอมไพล์ 32-bit ก็น่าจะได้ ถวายแรมไปหกถึงแปดกิ๊กฯ คงจะพอคอมไพล์สบายๆ
ในระยะยาวใช้วิธีแรกน่าจะดีสุด
bow_der_kleine Tue, 13/12/2011 - 23:53
ในระยะยาวใช้วิธีแรกน่าจะดีสุด แถมยังช่วยลดเวลาการคอมไพล์ด้วย เพราะการแก้บางส่วน ไม่จำเป็นต้อง build ใหม่ทั้งก้อน
vc++ 2010
neonicus Wed, 14/12/2011 - 01:20
vc++ 2010 นี่มีประสิทธิภาพดีสุดแล้วหรอ
ไม่ได้อยู่ในแวดวงการ dev app พวกนี้ด้วยสิ แต่เหมือนว่าไม่ได้ยิน c compiler ตัวใหม่ๆหรือเด่นๆมาหลายยยยยยปีแล้ว
ถ้าใช้วิธีสุถดท้าย นี่แปลว่า
tomazzu Wed, 14/12/2011 - 08:15
ถ้าใช้วิธีสุถดท้าย นี่แปลว่า เครื่อง เก่า ๆ ปิดประตูเลยสินะ
วิธีที่ 4. optimize กระบวนการ
prophecyx Wed, 14/12/2011 - 10:52
วิธีที่ 4. optimize กระบวนการ Profile-Guided Optimisation (PGO) ให้ใช้แรมน้อยลง ???
(ขำๆ นะครับ) ^ ^
เปิด /PAE จะได้ผลไหม แล้ว
ultimateohm Wed, 14/12/2011 - 14:44
เปิด /PAE จะได้ผลไหม แล้ว compiler มันรองรับ AWE ไหม
(ขอบ่นหน่อยครับ)ขนาดตอนพัฒนาย
vanilla Wed, 14/12/2011 - 16:16
(ขอบ่นหน่อยครับ)ขนาดตอนพัฒนายังมีปัญหาเรื่องทรัพยากรไม่พอ
แล้วตอนปล่อยออกมา โปรแกรมจะกินทรัพยากรของ user เท่าไหร่ไม่อยากคิดเลย
เวอปัจจุบันแค่เปิดไม่กี่แท๊บก็ใช้แรมมหาศาล แต่ก็ยังช้า บางทีมีค้างด้วย ขนาดใช้แรม 3G
แค่พัฒนาโปรแกรม Browser แล้วต้องใช้ทรัพยากรมากขนาดนนี้
จนผมต้องอัพฮาร์ดแวร์ตามด้วย มันไม่เวริ์คเลยครับทรัพย์ผมจาง ทำยังกับเป็นเกม 3D -*-
ปัจจุบันนี้ถ้าไม่ติด Add-ons ที่ใช้ปัจจุบัน จะย้ายไป opera ถาวรเลย เพราะเร็วมากมาย
มันคนละเรื่องเดียวกันเลยครับ
mk Wed, 14/12/2011 - 17:22
In reply to (ขอบ่นหน่อยครับ)ขนาดตอนพัฒนาย by vanilla
มันคนละเรื่องเดียวกันเลยครับ อย่าเอามาผสมกันสิครับ
ถ้าพูดแบบย่อๆ ...
lancaster Wed, 14/12/2011 - 18:14
In reply to (ขอบ่นหน่อยครับ)ขนาดตอนพัฒนาย by vanilla
ถ้าพูดแบบย่อๆ ... ยิ่งใช้พลังงานในการคอมไพล์มากเท่าไหร่ โปรแกรมที่ได้ยิ่งใช้พลังงานน้อยลงเท่านั้นครับ