Bitcode, vũ khí giúp Apple thoải mái triển khai kiến trúc CPU mới mà không lo vấn đề tương thích app
Duy Luân
5 nămBình luận: 95
Apple_bitcode_thay_doi_lon_CPU_app_HEADER.png
Hội nghị WWDC 2015 có nhiều điểm mới, ví dụ như OS X 10.11, iOS 9 và watchOS 2.0 cùng rất nhiều những thay đổi giúp lập trình viên viết app dễ dàng hơn. Tuy nhiên, có một thứ mà Apple không nói nhiều đến, ngay cả trong tài liệu của WWDC cũng không đề cập tới, nhưng lại có ý nghĩa vô cùng quan trọng: Bitcode. Về cơ bản thì đây là một thứ "cho phép App Store tối ưu hóa ứng dụng cho từng loại thiết bị trước khi chúng được người dùng tải về", Andreas Wendker - phó giám đốc mảng trải nghiệm OS X cho hay. Ngoài ra, nó còn giúp các ứng dụng "tự động tận dụng các khả năng mới của CPU do Apple bổ sung trong tương lai trong khi lập trình viên không cần đăng tải lại app lên cửa hàng". Vậy thật sự bitcode là gì và nó có ý nghĩa như thế nào với chúng ta?

Bitcode là gì?


Trước khi tìm hiểu về bitcode, bạn cần biết qua một chút về Low Level Virtual Machine (LLVM). Đây là một thư viện lập trình dùng để biên dịch (compile) các mã nguồn cấp cao thành mã máy để thiết bị có thể hiểu về thực thi được. LLVM đã được sử dụng để xây dựng nên nhiều bộ chuyển đổi (compiler) của nhiều ngôn ngữ lập trình cấp cao phổ biến hiện nay, ví dụ như C, C++, Python, Java, Ruby, tất nhiên có cả Objective-C và Swift (vốn là hai ngôn ngữ được xài để viết app cho OS X và iOS)

Trong LLVM có 3 phần. Một phần gọi là "front-end", tạm dịch là phần "mặt tiền", nó chính là thứ dùng để đọc các ngôn ngữ lập trình nói trên. Phần thứ hai gọi là "back-end", nó biết cách đưa ra các dòng mã máy có thể được chạy bởi CPU ARM, x86_64, SPARC, PowerPC và rất nhiều kiến trúc khác.

Nhưng làm sao back-end có thể hiểu được mã nguồn của front-end để thực hiện chức năng chuyển đổi này? Đó là nhiệm vụ của một lớp trung gian nằm giữa "back-end" và "front-end". Lớp trung gian này được biết đến với cái tên "LLVM Optimizer", nó sử dụng một ngôn ngữ lập trình cấp thấp gọi là intermediate representation (IR). IR trong LLVM có thể tồn tại ở ba dạng khác nhau tùy vào lập trình viên, và một trong ba dạng đó có "bitcode" (hai dạng còn lại là assembly và đối tượng kiểu C++).

LLVM_bitcode.png
Nhờ thiết kế độc lập của 3 thành phần, người ta rất dễ hỗ trợ thêm ngôn ngữ front-end mới, cũng như hỗ trợ cho các kiến trúc CPU mới ở phía back-end, ngay cả những kiến trúc không tồn tại ở thời điểm ứng dụng ra đời.

Cũng chính nhờ lợi điểm này mà Apple mới nói rằng Bitcode giúp "ứng dụng tự động tận dụng các khả năng mới của CPU do Apple bổ sung trong tương lai mà lập trình viên không cần sửa lại app". Vì sao? Bởi phần front-end và bitcode vẫn giữ nguyên, chỉ có phần back-end là thay đổi mà thôi, mà phần biên dịch back-end này lại giờ đây sẽ do App Store đảm nhiệm, tức là thuộc trách nhiệm của Apple chứ không còn của lập trình viên nữa.

Bitcode_dich.png

Hiện tại công ty đang dùng kiến trúc ARM cho iOS và watchOS, còn OS X thì dựa trên x86_64. Với bitcode, sau này nếu Apple đổi sang dùng một kiến trúc XYZ mới nào đó thì các app có chứa bitcode vẫn có thể hoạt động được bình thường trên nền tảng mới này mà lập trình viên không cần phải thay đổi gì mã nguồn cả, tất cả đã được App Store đảm đương.

Tương tự, ở quy mô hẹp hơn, giả sử Apple vẫn tiếp tục dùng ARM cho iOS và watchOS nhưng các CPU mới của hãng có thêm một số chức năng đặc biệt nào đó thì nhờ có bitcode, các ứng dụng vẫn tận dụng được các chức năng này mà không yêu cầu lập trình viên phải viết lại app.

Lấy một ví dụ đơn giản thế này. Với chiếc iPad Pro sắp ra mắt, giả sử Apple không còn xài chip ARM nữa mà chuyển sang chip Intel thì những app iOS nào có tích hợp bitcode sẽ vẫn chạy được trên nền tảng mới mà lập trình viên chẳng cần phải sửa chữa gì. Tương tự, con chip S1 trong Apple Watch hiện là ARM, nhưng lỡ như Apple muốn xài kiến trúc Intel cho chip S2 thì cũng chấp luôn, ứng dụng sẽ luôn chạy được, Apple không cần phải chờ lập trình viên đăng tải lại các app của họ.

Ảnh hưởng đến sự thay đổi kiến trúc CPU


Lịch sử của Apple cho thấy rằng hãng không ngại thay đổi kiến trúc CPU dùng trong các sản phẩm của mình. Lần thứ nhất là khi Apple chuyển từ việc sử dụng kiến trúc Motorola 68k sang PowerPC trong những năm 1990, lần thứ hai vào năm 2005 khi hãng quyết định từ bỏ PowerPC và chuyển sang dùng x86 (CPU Intel). Ngoài Apple thì có hai đối thủ cạnh tranh khác là Commodore và Atari cũng từng thay đổi kiến trúc vi xử lý cho các máy tính của họ, tuy nhiên khác với Apple, hai công ty này đã không bao giờ lấy lại được thị phần của mình và sau này ngừng hẳn việc sản xuất PC.

[​IMG]

Nói riêng về mảng di động, Apple cũng đã mạnh dạn chuyển đổi từ kiến trúc CPU ARM 32-bit lên thành 64-bit trong lúc thị trường smartphone, tablet vẫn còn đang chìm đắm trong hàng tá các vi xử lý 32-bit vào năm 2013 với chiếc iPhone 5s.

Ở đợt chuyển sang xài x86, Apple thông báo trước cho giới lập trình viên về việc này tận 2 năm để họ có thời gian chỉnh sửa lại app của mình. Tương tự, với đợt nâng cấp lên CPU 64-bit cho di động, Apple cũng yêu cầu lập trình viên phải thay đổi mã nguồn và "nộp" ứng dụng lại lên App Store.

Nhưng trong thời gian tới, với bitcode, các nhà phát triển sẽ không còn phải lo lắng về những đợt chuyển đổi kiến trúc CPU, dù cho sự thay đổi đó có lớn đến mức nào đi chăng nữa. Ngay cả khi Apple chuyển sang dùng một kiến trúc hoàn toàn mới thì app của họ vẫn đảm bảo là sẽ chạy được. Và lúc đó, việc duy nhất Apple cần suy nghĩ đó là làm thế nào để CPU của họ chạy tốt hơn, mạnh hơn, ít hao pin hơn, không còn phải lo lắng về vấn đề tương thích app nữa.

Phản ứng của lập trình viên ra sao?


Caleb Davenport, một kĩ sư chuyên về iOS, nói rằng ông vừa thích vừa lo lắng với việc Apple bắt đầu sử dụng bitcode. Thích bởi vì ông không phải viết lại app của mình khi Apple đổi kiến trúc CPU, nhưng "thứ làm tôi lo lắng đó là ứng dụng của tôi có thể được dịch ra để chạy với những cấu hình mà có thể tôi đã không kiểm tra, từ đó dẫn đến lỗi mà bản thân tôi không thể tự tái hiện để sửa".

Ông nói rằng khi chiếc iPhone 5s ra đời lần đầu tiên năm 2013, ông đã phải đợi chiếc điện thoại này về đến tay mình thì mới dám kích hoạt những thành phần 64-bit trong app của ông. Còn với việc LLVM tự động biên dịch các app, người dùng cuối có thể sẽ trải nghiệm app trước cả lập trình viên và có thể gặp những vấn đề không thể dự báo trước. Đặc biệt, những app nào có sử dụng thêm các thư viện lập trình bên ngoài thì chắc chắn sẽ tiêu tùng nếu như thư viện đó không được cập nhật với bitcode.

Một lập trình viên khác, Sjoerd Janssen, thì lại rất hứng thú bởi anh có thể giảm đi rất nhiều việc khi Apple ra mắt một chiếc điện thoại mới. Trong khi đó, trang iMore thì nói rằng họ rất thích bitcode nhưng cũng tỏ ra quan ngại với lý do giống như Davenport đã nói. Nhiều lập trình viên được trang The Next Web hỏi thăm cũng chia sẻ rằng họ lo đến chuyện Apple có thể sẽ không làm tốt và khiến app của họ bị lỗi.

Tương lai: ứng dụng độc lập với CPU, kiến trúc vi xử lý mới cho Mac


Một bài viết trên trang Medium tin rằng việc Apple bắt đầu áp dụng bitcode chính là tín hiệu cho một thứ lớn hơn, quan trọng hơn. Trong tài liệu của mình, Apple có ghi như sau: "với ứng dụng iOS, việc sử dụng bitcode là không bắt buộc nhưng là mặc định. Nếu bạn đưa bitcode vào app của mình, tất cả mọi bộ khung mà app sử dụng cũng cần phải có bitcode. Còn với ứng dụng cho Apple Watch, bitcode là bắt buộc phải có".

Như vậy chúng ta có thể thấy rằng Apple đang dần dần "ép" lập trình viên phải dùng bitcode, bắt đầu với các app cho chiếc đồng hồ của mình. Trên iOS, từ "mặc định" có thể chuyển thành "bắt buộc" trong tương lai bất kì lúc nào.

Nhưng ảnh hưởng lớn nhất có lẽ là với các ứng dụng Mac. Hiện tại Apple có Bob Mansfield, người từng giữ chức phó chủ tịch cấp cao chịu trách nhiệm về mảng công nghệ nhưng đã chuyển sang làm cho một số "dự án bí mật". Biết đâu thứ mà Mansfield đang làm chính là một dòng CPU ARM mới dành cho các máy tính mang logo quả táo thì sao. Chúng ta cũng đã nghe rất nhiều tin đồn về chuyện Apple đang muốn tìm giải pháp thay thế cho chip Intel x86 rồi, và với sự xuất hiện của bitcode thì tin đồn đó càng được củng cố hơn nữa.

macbookairarm.jpg

Theo những gì chúng ta đã biết thì bitcode hiện chưa hỗ trợ app OS X, nhưng chỉ là ở thời điểm hiện tại mà thôi. Trong tương lai, dù sớm hay muộn thì Apple cũng sẽ kích hoạt tính năng này. Một bằng chứng khá rõ ràng đó là người giới thiệu bitcode trên sân khấu WWDC 2015, Andreas Wendker, chính là phó giám đốc mảng trải nghiệm của OS X. Trong dài hạn, mọi app đều không còn phụ thuộc vào kiến trúc CPU nữa.

Với vũ khí bitcode và con chip ARM riêng trong tay, Apple có thể thoát khỏi sự phục thuộc vào Intel, không còn phải lo về những đợt hoãn giao chip của công ty này nữa. Họ cũng hoàn toàn tự chủ về mặt hiệu năng và mức độ tiêu thụ điện của CPU, từ đó tối ưu tốt hơn cho các phần cứng của mình. Ngoài ra, Apple cũng không cần thông báo trước cho lập trình viên khi họ muốn đổi kiến trúc vi xử lý, từ đó giúp giữ bí mật tốt hơn về kế hoạch kinh doanh của mình.

Kết


Tóm lại, với bitcode, cả Apple và lập trình viên đều được lợi. Apple trở nên linh hoạt hơn trong việc thay đổi kiến trúc CPU cho các sản phẩm máy tính lẫn di động, còn lập trình viên thì không phải bỏ công sức, tiền bạc và thời gian để viết lại app trong những dịp như thế. Tất nhiên, bitcode sẽ cần thời gian để phổ biến và được tích hợp vào bên trong nhiều app, khi đó thì những lợi ích nói trên mới phát huy tác dụng, chứ chỉ có vài chục app dùng bitcode thì mọi chuyện cũng không thay đổi mấy.

Tham khảo: Apple, LLVM, The Next Web, Wikipedia
no0b4v3r
ĐẠI BÀNG
5 năm
Hướng đi thông minh và trọn vẹn thật 😁
Mặc dù là anti ifan nhưng cũng phải nói là các sản phẩm của apple rất tốt, đặc biệt là về phần mềm 😃 vậy là các app trong tương lại của apple càng tốt hơn nữa, tạo nên áp lực cạnh tranh giúp tất cả đều phải tốt hơn, mình đc lợi hơn 😁
@boybl1990 chuẩn, mặc dù e ko thik iphone ipad nhưg e thik con xcode của apple =))
Mr Link
ĐẠI BÀNG
5 năm
Kinh khủng!!!
Nghề lập trình viên rồi sẽ hấp dẫn vì các nhà sản xuất cứ thay đổi liên tục thế này.
ủng hộ apple chơi chip riêng tự phát triển cho mac trên nền ARM 😁 lúc đó mac là mac chạy osx, hết cài win được nhé :D
@kool_boyjuly Win 8 RT trước cũng là ARM đó. Nếu MS muốn lấn sân sang phần cứng Mac thì cũng chấp luôn Mac ARM. :D
@steve_jobs hy vọng vậy ;))
bango123
TÍCH CỰC
5 năm
@steve_jobs Có điều ms hồi đó không tính chuyện chạy phần mềm win32 trên Windows RT nên RT chết yểu
brits
TÍCH CỰC
5 năm
là một lập trình viên, tôi rất thích điều này 😃
kingsonic
ĐẠI BÀNG
5 năm
Đó là lý do tại sao Apple dùng chip 2 nhân ram 1Gb mà vẫn ăn đứt mấy "quái vật" Android khác về độ mượt.
Tony Diệp
ĐẠI BÀNG
5 năm
@kingsonic 1 comment chứng tỏ bác không hiểu hay có thể là không thèm đọc kỹ bài viết rồi phán theo ý kiến chủ quan
@kingsonic Bài này hổng có liên quan gì tới độ mượt hay chip 2 nhân với RAM 1GB bạn ơi 😆
Vậy thì có thể về sau máy mac sẽ không cài đc win ah.
Có sự khác biệt quá lớn tuong thích app giữa iso va phần còn lại, Apple vẫn là đấng tối cao trong 1 tg dài nữa, buồn thay
ngoctb08
ĐẠI BÀNG
5 năm
thích những sp của apple 😃
Tưởng tiền 😃
ngocultra
ĐẠI BÀNG
5 năm
Dạo này tinh tế toàn apple nhỉ
vinhanboy
TÍCH CỰC
5 năm
@ngocultra Kiểu như bây giờ ra đường toàn thấy xài iPhone á bác 😁
Khác biệt chỉ có thể là Apple, phần còn lại chỉ là tồn tại cho có:oops:
kiểu như vầy thì hi vọng iPhone 7 với iPad Air 3/ Air Pro 1 sử dụng chip A10 với kiến trúc mới chăng...
Apple lúc nào cũng đi tiên phong. Thành công bắt đầu từ đây.
Bảo sao lúc nào nó cũng là sản phẩm đại diện cho sự sang trọng, đẳng cấp, hoàn hảo (hoản hảo của Apple tức là còn có thể hoàn hảo thêm được nữa nhé ^^ không mấy con ra sau thì lấy cái gì mà loè người mua) và sự đơn giản những thứ phức tạp trong sử dụng hàng ngày cho người dùng. Nói câu này mấy bạn dùng Android đừng giận nhé, có đến mùa quýt mới ăn được Iphone. Hồi nó màn hình bé như con kiến chip đơn lõi ram thì vừa đủ còn chả ăn được, giờ nó phình to màn hình rồi tăng thời lượng pin và sắp tới ứng dụng của nó tự động tương thik vs tất cả các loại CPU thì coi như android del bao giờ có cửa ngồi cùng mâm rồi. Thôi thì hy vọng vào cái windowphone thôi, dù sao microsoft nó cũng có kinh nghiệm làm HĐH và đánh nhau vs apple suốt rồi (thấy bảo ngày xưa đập Táo suýt chết xong còn giơ tay ra cưu mang mà, mấy con windowphone nếu có lỡ bo tròn 4 cạnh hay gì gì đó na ná giống iphone thì cũng chả giám kiện đâu ^^)
Dr. Ho
ĐẠI BÀNG
5 năm
@tethien Chú còn non lắm về nhà đọc lại ngôn ngữ C++, Objective-C, Java và tìm hiểu các nó chạy runtime rồi hãy phát biểu linh tinh nhé. Công nghệ bitcode nó tương tự như CPU ảo về nguyên tắc nó có thể compile tất cả ngôn ngữ phía trên Assembly ra mã bitcode. Còn ART chỉ dùng để giả lập JVM trên Android, nó tối ưu hơn Dalvik vì compile sẵn (caching). Còn độ tối ưu phần cứng thì còn khuya mới đú nổi với bitcode.
@anh_hung_vo_le Máy android đua phần cứng thông số to, cái cần nhất là app ngon như iOS chứ mua đt về quẹt tin nhắn lướt web nhanh vèo vèo cũng chả ích lợi gì =))
Cái này có vẻ giống khái niệm JVM của Java, mặc kệ back-end có là platform nào đi nữa, chỉ cần JVM hỗ trợ thì đều chạy Java apps được. Tuy nhiên back-end của Apple không phải là platform mà là chip 😃
@gauto988 kiểu như java phần mềm làm sao chạy nhanh bằng bằng cách biên dịch thẳng ra mã máy. LLVM có lẽ gần mã máy hơn nhưng so với mã máy vẫn thua về tốc độ. Nếu dùng cái này apple chẳng qua muốn làm bước đệm trước khi chuyển sang mã máy. dịch thẳng mã máy vẫn số 1.
LocDT
TÍCH CỰC
5 năm
@hieupy89 Khác nhau đó bạn. Java dịch ByteCode ra mã máy tại thời điểm chạy (JIT) nghĩa là vẫn mất thời gian mỗi lần chạy. BitCode theo như mô tả là dịch ra mã máy trước khi lên Store nghĩa là sẽ có nhiều phiên bản dịch sẵn trên store tương ứng với các dòng máy (chip) khác nhau và khi chạy thì là chạy thẳng mã máy, mọi thứ vẫn nhanh như thường (Nếu bitcode làm tốt nhiệm vụ compile).

Cách này thực chất đã được nhiều hãng áp dụng như Microsoft đã tuyên bố các ứng dụng cho Windows Phone (Viết bằng .NET và compile ra dạng mã trung gian IL) sẽ được chuyển qua native code khi lên Store tương ứng với từng dòng máy, nên khi tải về sẽ chạy nhanh như ứng dụng native.

Hay Google với ART cũng complie ByteCode của Java ra native code (AOT) tại thời điểm tải về, việc compile được thực hiện trên thiết bị đầu cuối. Google chọn giải pháp này thay vì compile trên store có lẽ vì có quá nhiều thiết bị Android với các dòng chip khác nhau nên bản thân Google cũng không thể kiểm soát hết được do đó để cho các OEM khi dùng chip nào thì tự tinh chỉnh lại bộ compile ART cho phù hợp.

Về cơ bản cách làm của Apple, Google, Microsoft đều đưa ứng dụng về dạng native như lập trình viên tự compile nên về lý thuyết là ko khác nhau về tốc độ khi chạy. Nhưng thực tế sẽ khác nhau ở chỗ việc chuyển qua code trung gian trước khi ra mã máy sẽ phải tuân theo nhưng tập lệnh và cấu trúc nhất định mà code trung gian đó quy định do đó có thể không tối ưu bằng dùng thẳng mã máy. Nhưng việc ko tối ưu này chỉ xảy ra với những lập trình viên hiểu cực kỳ rõ con chip mình hướng tới, và phải rất giỏi để có thể tận dụng tối đa con chip. Còn với đa số các lập trình viên thì chạy qua trình compile trung gian vẫn là giải pháp tốt nhất vì các trình compile đó đã được thiết kế tối ưu dựa trên những bộ óc từ giỏi trở lên.
nforce
TÍCH CỰC
5 năm
@LocDT Đọc từ đầu toàn thấy mems nâng bi Apple, thấy có mỗi bác viết bài là có nội dung tí. Mình cũng đồng ý với bác là cái này chả khác gì ART trên Android cả. Chỉ khác thời điểm biên dịch thôi. Apple tới giờ mới làm việc này là bởi native code có rất nhiều hạn chế về mặt triển khai trên nhiều cấu hình khác nhau. Mà đồ apple số thiết bị giờ cũng tăng lên nhiều rồi. Ngoài ra hardware giờ cũng mạnh hơn trước nhiều. Còn android thì mục tiêu ban đầu là tương thích, nên nó phát triển dựa trên mô hình giống JVM trước.
Nói chung cái này có thể lạ với đa số, chứ ko lạ với dân kỹ thuật.
Dr. Ho
ĐẠI BÀNG
5 năm
@gauto988 Khác thím à. Java bytecode không được dịch ra mã máy trực tiếp, mỗi khi chạy ứng dụng thì phải load JVM để dịch lúc runtime, thành ra sẽ tạo ra nhiều overhead. Còn ý tưởng của Bitcode là một ngôn ngữ trung gian sẽ được compile ra mã máy trên AppStore rồi mới chuyển xuống cho người dùng.
DJspeed
ĐẠI BÀNG
5 năm
động thái trên cho thấy apple chuẩn bị bỏ Samsung về mảng CPU và chuyển qua Intel hoặc một hãng khác. giảm bớt khả năng phụ thuộc và chi phí chuyển đổi một loại kiến trúc CPU nhất định khi không muốn hợp tác tiếp tục
@DJspeed Apple phụ thuộc vào SS khi nào thế bác, SS chỉ đóng vai trò gia công chip cho Apple thôi (do SS có cơ sở hạ tầng để gia công chip sll), ngoài ra chả có quyền nhúng tay vào thứ gì khác....Mà nói đúng hơn là SS phụ thuộc Apple vì nguồn thu từ hợp đồng gia công cho Apple vốn cực lớn, chả thế mà năm nào mảng gia công SS cũng phải bù lỗ cho mãng di động đấy =))
Dr. Ho
ĐẠI BÀNG
5 năm
@cuong32654 Nhiều bác không phân biệt được thiết kế, gia công, sản xuất. Apple nó thiết kế con chip, xuất phim âm bản để SS làm chip. Nó giống như điện tử, người ta thiết kế rồi xuất gerber để in mạch. Không có file gốc thì nhìn đám gerber như đám bùi nhùi.
CPU ARM của apple làm chủ rồi chứ liên quan gì đến samsung ở đây. Samsung chỉ là nhà máy SX. Bây giờ apple chuyển qua x86 của intel hoá ra lại phụ thuộc vào intel

Cá nhân
Bạn
Hi bạn!
Điểm Reward Store: 
Tuổi Tinh tế: 
Cấp độ thành viên Tinh Tế


Tải app Tinh tế

Tải app Tinhte - Theo dõi thông tin mà bạn yêu thích

Tải app TinhteTải app Tinhte
Tải app Tinh tế cho Android trên Google PlayTải app Tinh tế cho iPhone, iPad trên App Store



Cộng đồng nổi bật




  • Chịu trách nhiệm nội dung: Trần Mạnh Hiệp
  • © 2020 Công ty Cổ phần MXH Tinh Tế
  • Địa chỉ: 209 Đường Nam Kỳ Khởi Nghĩa, Phường 7, Quận 3, TP.HCM
  • Số điện thoại: 02862713156
  • MST: 0313255119
  • Giấy phép thiết lập MXH số 11/GP-BTTTT, Ký ngày: 08/01/2019