[Google I/O] Android L เริ่มใช้ ART แล้ว, รองรับ 64 บิต, ไม่ต้องแก้โค้ดใดๆ

พรุ่งนี้ Nexus 5 กับ Nexus 7

eoror24 Thu, 26/06/2014 - 01:10

พรุ่งนี้ Nexus 5 กับ Nexus 7 มี factory image ส่วน Nexus4 ก็รอกันต่อไป

nexus 4 น่าจะไม่ได้ไปต่อ

mosslam Thu, 26/06/2014 - 01:20

nexus 4 น่าจะไม่ได้ไปต่อ

ไม่เอาไม่พูดสิครับ T_T

eoror24 Thu, 26/06/2014 - 01:21

ไม่เอาไม่พูดสิครับ T_T

ผมก็ใช้ nexus 4

mosslam Thu, 26/06/2014 - 01:22

ผมก็ใช้ nexus 4 ยังใหม่อยู่เลยกะใช้ยาวให้ nexus 6 ออก แต่..............................

image ที่จะออกเป็น developer

McKay Thu, 26/06/2014 - 01:32

image ที่จะออกเป็น developer preview หน่ะครับ ผมคิดว่า Google คงไม่ลอยแพ Nexus 4 ง่ายๆ เพราะมันเหมือน Nexus 7 ซะขนาดนั้น

เกิน 18 เดือนสำหรับ Nexus 4

gooGof Thu, 26/06/2014 - 01:39

เกิน 18 เดือนสำหรับ Nexus 4 แล้วนะครับ T..T

Snapdragon S4 Pro เหมือน

Golflaw Thu, 26/06/2014 - 13:59

Snapdragon S4 Pro เหมือน nexus 7 2013 นะครับ การอัพเดตไม่น่าจะเป็นปัญหา แต่ developer preview น่าจะแค่ 2 รุ่นก่อน

WTF It's Joke ?

skuma Sun, 29/06/2014 - 18:39

WTF It's Joke ?

ไม่เข้าใจว่าทำไมยังสนับสนุน

takwing Thu, 26/06/2014 - 01:23

ไม่เข้าใจว่าทำไมยังสนับสนุน JIT กับ interpreter อยู่ ถ้าจะใช้ ART
หรือว่าจะยังใช้ได้ทั้งสองอย่างทั้ง dalvik กับ ART เลยยังคง JIT กับ interpreter ไว้อยู่

คิดว่าน่าจะเป็นเรื่อง memory ครับ คือถึงแม้ JIT จะมี memory footprint ที่เยอะกว่า AOT ในโปรแกรมใหญ่ๆ แต่กับโปรแกรมเล็กๆที่ไม่ได้ทำงานตลอดเวลาและไม่ต้องการ performance มากนัก(เช่นเปิดแล้วปิด, ไม่ได้ทำงาน background) ขนาดของ heap เริ่มต้นที่เล็กกว่าของ JIT น่าจะช่วยลดการบริโภค memory ลงได้ครับ

เดี๋ยวก่อนนะครับ

takwing Thu, 26/06/2014 - 01:44

เดี๋ยวก่อนนะครับ ที่ผมเข้าใจคือว่า 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

McKay Thu, 26/06/2014 - 01:48

ผมเดาเอาเองว่า การที่ Google บอกมาแบบนี้คือ ณ ตอนสร้าง App เราอาจสามารถใส่ flag ให้ apk นั้นๆว่าควรทำตัวในโหมดไหน (AOT - compile เป็น machine code, JIT/interpreter อยู่ในสถานะกึ่ง compile) หน่ะครับ เพราะอย่างที่คุณ takwing บอก AOT กับ JIT มันทำงานร่วมกันไม่ได้อยู่แล้ว

งานเล็กๆ loop น้อยๆ

lew Thu, 26/06/2014 - 03:43

งานเล็กๆ loop น้อยๆ รันซ้ำน้อย แล้วไม่ต้องการ cache ไฟล์ที่คอมไพล์แล้ว การ interpret ได้ผลดีกว่าเยอะครับ

เป็นเหตุผลที่ Python รันสคริปต์เล็กๆ ได้เร็วมาก ขณะที่ bechmark (ซึ่งมักลูปจำนวนมาก) ทำได้แย่เสมอ

ตามที่ผมเข้าใจคือจุดประสงค์ที

takwing Tue, 01/07/2014 - 21:14

ตามที่ผมเข้าใจคือจุดประสงค์ที่ Python ถูกออกแบบมาพร้อมกับ interpreter น่าจะเป็นเพราะ 2 เหตุผลหลักๆ คือ

portability เพราะ Python มันใช้ในการประมวลสคริปต์สำหรับเว็บเบราซ์เซอร์ที่อยู่บนหลายแพล็ตฟอร์ม
dynamically typed language

มากกว่าเหตุผลที่ว่า การ interpret เร็วกว่าเพราะว่าการ interpret มันช้ากว่าการรัน native code ที่่ผ่านการคอมไพล์มาเรียบร้อยแล้วบนฮาร์ดแวร์จริงๆอยู่แล้วมากๆ

หลักฐานคือ ตอนแรกที่ dalvik ออกมามีแต่ interpreter เพียวๆ ตอนหลัง Google เลยตัดสินใจเพิ่ม JIT เข้าไปใน dalvik เพื่อลดขั้นตอนการ interpret เซ็คชันของโค้ดที่ถูก interpret บ่อยๆ และข้อดีอีกอย่างของ JIT คือมันสามารถ emit โค้ดตามสถาการณ์โดยการโปรไฟล์โค้ดขณะรันไปในตัว

ผมว่าการ benchmark กับ สคริปต์เล็กๆมันไม่ได้บอกผลอะไรมากเพราะเวลาที่ใช้มันสั้นเกินไปจนบอกประสิทธิภาพอะไรไม่ได้ แต่ Python เป็นที่นิยมน่าจะเป็นเพราะ ตัวภาษา Python เองตอบโจทย์ในเรื่องการเขียนโปรแกรมเพื่อประมวลผล regular expression มากกว่า