กูเกิลประกาศในงาน Google I/O 2014 ว่า Android รุ่นหน้ารหัส L จะเปลี่ยนมาใช้รันไทม์ ART แทน Dalvik อย่างเป็นทางการแล้ว
- รองรับ 3 สถาปัตยกรรมซีพียูที่แตกต่างกันคือ ARM, x86, MIPS
- รองรับการประมวลผล 3 วิธีคือ AOT (ahead of time), JIT (just in time), interpreter
- ประสิทธิภาพของ ART ดีกว่า Dalvik อย่างเห็นได้ชัด อัตราการหยุดพักของ garbage collector น้อยลง
- รองรับ 64 บิตมาตั้งแต่ต้น รองรับหน่วยความจำขนาดใหญ่ขึ้น และไม่ต้องแก้โค้ดใดๆ เพราะตัวรันไทม์จัดการให้ทั้งหมด
Comments
พรุ่งนี้ Nexus 5 กับ Nexus 7 มี factory image ส่วน Nexus4 ก็รอกันต่อไป
nexus 4 น่าจะไม่ได้ไปต่อ
ไม่เอาไม่พูดสิครับ T_T
ผมก็ใช้ nexus 4 ยังใหม่อยู่เลยกะใช้ยาวให้ nexus 6 ออก แต่..............................
image ที่จะออกเป็น developer preview หน่ะครับ ผมคิดว่า Google คงไม่ลอยแพ Nexus 4 ง่ายๆ เพราะมันเหมือน Nexus 7 ซะขนาดนั้น
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
เกิน 18 เดือนสำหรับ Nexus 4 แล้วนะครับ T..T
Snapdragon S4 Pro เหมือน nexus 7 2013 นะครับ การอัพเดตไม่น่าจะเป็นปัญหา แต่ developer preview น่าจะแค่ 2 รุ่นก่อน
A smooth sea never made a skillful sailor.
WTF It's Joke ?
ไม่เข้าใจว่าทำไมยังสนับสนุน JIT กับ interpreter อยู่ ถ้าจะใช้ ART
หรือว่าจะยังใช้ได้ทั้งสองอย่างทั้ง dalvik กับ ART เลยยังคง JIT กับ interpreter ไว้อยู่
คิดว่าน่าจะเป็นเรื่อง memory ครับ คือถึงแม้ JIT จะมี memory footprint ที่เยอะกว่า AOT ในโปรแกรมใหญ่ๆ แต่กับโปรแกรมเล็กๆที่ไม่ได้ทำงานตลอดเวลาและไม่ต้องการ performance มากนัก(เช่นเปิดแล้วปิด, ไม่ได้ทำงาน background) ขนาดของ heap เริ่มต้นที่เล็กกว่าของ JIT น่าจะช่วยลดการบริโภค memory ลงได้ครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
เดี๋ยวก่อนนะครับ ที่ผมเข้าใจคือว่า ART เนี่ยมันเป็นแค่ runtime environment ไม่ใช่ virtual machine อย่าง dalvik แล้ว dex ก็ถูกคอมไพล์เป็น native machine code ตั้งแต่ตอนติดตั้งแอปนั้นๆแล้ว
ดังนั้นตอนที่แอปรัน มันจึงรันบนโปรเซสเซอร์และฮาร์ดแวร์โดยตรง ไม๋เหมือนกับการรันบน dalvik ที่คอย interpret dex bytecode เป็น machine code แล้วใช้ JIT ในการเพิ่มประสิทธิภาพการ interpret fragment ของ ้bytecode ที่เป็น hotspot
ที่ผมไม่เข้าใจคือในเมื่อต่อไปแอปจะรันบนโปรเซสเซอร์ตรงๆ แล้วจะมี interpreter กับ JIT ไว้ทำไมเพราะทั้งสองตัวไว้สำหรับการแปลง bytecode on the fly
ผมเดาเอาเองว่า การที่ Google บอกมาแบบนี้คือ ณ ตอนสร้าง App เราอาจสามารถใส่ flag ให้ apk นั้นๆว่าควรทำตัวในโหมดไหน (AOT - compile เป็น machine code, JIT/interpreter อยู่ในสถานะกึ่ง compile) หน่ะครับ เพราะอย่างที่คุณ takwing บอก AOT กับ JIT มันทำงานร่วมกันไม่ได้อยู่แล้ว
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
งานเล็กๆ loop น้อยๆ รันซ้ำน้อย แล้วไม่ต้องการ cache ไฟล์ที่คอมไพล์แล้ว การ interpret ได้ผลดีกว่าเยอะครับ
เป็นเหตุผลที่ Python รันสคริปต์เล็กๆ ได้เร็วมาก ขณะที่ bechmark (ซึ่งมักลูปจำนวนมาก) ทำได้แย่เสมอ
lewcpe.com, @wasonliw
ตามที่ผมเข้าใจคือจุดประสงค์ที่ Python ถูกออกแบบมาพร้อมกับ interpreter น่าจะเป็นเพราะ 2 เหตุผลหลักๆ คือ
1) portability เพราะ Python มันใช้ในการประมวลสคริปต์สำหรับเว็บเบราซ์เซอร์ที่อยู่บนหลายแพล็ตฟอร์ม
2) dynamically typed language
มากกว่าเหตุผลที่ว่า การ interpret เร็วกว่าเพราะว่าการ interpret มันช้ากว่าการรัน native code ที่่ผ่านการคอมไพล์มาเรียบร้อยแล้วบนฮาร์ดแวร์จริงๆอยู่แล้วมากๆ
หลักฐานคือ ตอนแรกที่ dalvik ออกมามีแต่ interpreter เพียวๆ ตอนหลัง Google เลยตัดสินใจเพิ่ม JIT เข้าไปใน dalvik เพื่อลดขั้นตอนการ interpret เซ็คชันของโค้ดที่ถูก interpret บ่อยๆ และข้อดีอีกอย่างของ JIT คือมันสามารถ emit โค้ดตามสถาการณ์โดยการโปรไฟล์โค้ดขณะรันไปในตัว
ผมว่าการ benchmark กับ สคริปต์เล็กๆมันไม่ได้บอกผลอะไรมากเพราะเวลาที่ใช้มันสั้นเกินไปจนบอกประสิทธิภาพอะไรไม่ได้ แต่ Python เป็นที่นิยมน่าจะเป็นเพราะ ตัวภาษา Python เองตอบโจทย์ในเรื่องการเขียนโปรแกรมเพื่อประมวลผล regular expression มากกว่า
N4 ผมพังพอดี ไม่เปิด N6 มาซักหน่อยหรอครับคุณพิชัย
แล้วอย่างนี้ App จะใหญ่เป็นสองเท่าเหมือนตอนนี้มั้ยครับ เพราะผมใช้ CM11 พอเปลี่ยนเป็น ART แล้วพวก App มันกินเนื้อที่เพิ่มเป็นสองเท่ากว่าเลยครับ
ทดลองติดตั้ง 3 OS | Windows Ubuntu Android
นี่อาจจะเป็นรีลีสแรกที่ Android สวยกว่า iOS :)