Luôn nhanh, yo
Trong trước của tôi các bài viết mà tôi đã nói về cách WebAssembly cho phép bạn đưa hệ sinh thái thư viện C/C++ lên web. Một ứng dụng và tận dụng rộng rãi thư viện C/C++ là squoosh, ứng dụng web cho phép bạn nén hình ảnh bằng nhiều bộ mã hoá và giải mã được biên dịch từ C++ sang WebAssembly.
WebAssembly là một máy ảo cấp thấp chạy mã byte được lưu trữ
trong .wasm tệp. Mã byte này được nhập và cấu trúc rõ ràng theo cách
vì nó có thể được biên dịch và tối ưu hoá cho hệ thống lưu trữ nhanh hơn nhiều so với
JavaScript có thể. WebAssembly cung cấp một môi trường để chạy mã có
hộp cát và nhúng ngay từ đầu.
Theo kinh nghiệm của tôi, hầu hết các vấn đề về hiệu suất trên web đều do bố cục và tô màu quá mức nhưng thỉnh thoảng ứng dụng cần phải tác vụ tính toán tốn nhiều thời gian. WebAssembly có thể giúp bạn vào đây.
Con đường nóng bỏng
Trong squoosh, chúng tôi đã viết một hàm JavaScript xoay vùng đệm hình ảnh theo bội số 90 độ. Trong khi OffscreenCanvas là lựa chọn lý tưởng để thì tính năng này không được hỗ trợ trên các trình duyệt mà chúng tôi đang nhắm đến và lỗi trong Chrome.
Hàm này lặp lại mọi pixel của hình ảnh đầu vào và sao chép hình ảnh đó vào một vị trí khác nhau trong hình ảnh đầu ra để đạt được độ xoay. Dành cho kích thước 4094px x 4096px (16 megapixel) sẽ cần hơn 16 triệu lần lặp lại khối mã bên trong, được chúng tôi gọi là "đường dẫn nóng". Mặc dù khá lớn lặp lại, 2 trong số 3 trình duyệt chúng tôi đã thử nghiệm hoàn thành tác vụ trong 2 giây trở xuống. Thời lượng có thể chấp nhận được cho loại tương tác này.
for (let d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
for (let d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
const in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
outBuffer[i] = inBuffer[in_idx];
i += 1;
}
}
Tuy nhiên, một trình duyệt mất hơn 8 giây. Cách các trình duyệt tối ưu hoá JavaScript thực sự phức tạp và các công cụ khác nhau sẽ tối ưu hoá cho những yếu tố khác nhau. Một số tối ưu hóa cho thực thi thô, một số tối ưu hóa cho tương tác với DOM. Trong trong trường hợp này, chúng tôi đã gặp phải đường dẫn không được tối ưu hoá trong một trình duyệt.
Mặt khác, WebAssembly được xây dựng hoàn toàn dựa trên tốc độ thực thi thô. Loại đối thủ sau lượt đánh bóng nếu chúng ta muốn có hiệu suất nhanh, dự đoán trên các trình duyệt cho mã như thế này, WebAssembly có thể giúp bạn khắc phục vấn đề này.
WebAssembly giúp dự đoán hiệu suất
Nhìn chung, JavaScript và WebAssembly có thể đạt được cùng hiệu suất cao nhất. Tuy nhiên, đối với JavaScript, hiệu suất này chỉ có thể đạt được trên "đường dẫn nhanh", và việc duy trì được "đường dẫn nhanh" đó thường là điều khó khăn. Một lợi ích chính WebAssembly cung cấp hiệu suất có thể dự đoán được, ngay cả trên các trình duyệt. Chính sách nghiêm ngặt nhập và kiến trúc cấp thấp cho phép trình biên dịch mạnh mẽ hơn đảm bảo sao cho mã WebAssembly chỉ phải được tối ưu hoá một lần và sẽ luôn sử dụng "đường dẫn nhanh".
Viết cho WebAssembly
Trước đây, chúng tôi đã lấy thư viện C/C++ và biên dịch chúng vào WebAssembly để sử dụng trên trang web. Chúng tôi không thực sự xử lý mã của thư viện, chỉ viết một số lượng nhỏ mã C/C++ để tạo cầu nối giữa trình duyệt và thư viện. Lần này động lực của chúng tôi khác biệt: Chúng tôi muốn viết điều gì đó từ đầu với WebAssembly để chúng tôi có thể tận dụng những lợi thế mà WebAssembly có được.
Cấu trúc WebAssembly
Khi viết cho WebAssembly, bạn nên tìm hiểu thêm một chút về WebAssembly thực sự là gì.
Cách trích dẫn nội dung của WebAssembly.org:
Khi biên dịch một đoạn mã C hoặc Rust thành WebAssembly, bạn sẽ nhận được một .wasm
chứa nội dung khai báo mô-đun. Nội dung khai báo này bao gồm một danh sách
"nhập" mà mô-đun yêu cầu từ môi trường của mình, một danh sách các nội dung xuất mà mô-đun này
mô-đun này cung cấp cho máy chủ lưu trữ (các hàm, hằng số, các phân đoạn bộ nhớ) và
tất nhiên là các lệnh nhị phân thực tế cho các hàm có trong đó.
Điều gì đó mà tôi không nhận ra cho đến khi xem xét vấn đề này: Hệ thống giúp WebAssembly là một "máy ảo dựa trên ngăn xếp" không được lưu trữ trong đoạn mã mà các mô-đun WebAssembly sử dụng. Ngăn xếp hoàn toàn nằm trong máy ảo nội bộ và các nhà phát triển web không thể truy cập được (ngoại trừ thông qua Công cụ cho nhà phát triển). Như vậy là hoàn toàn có thể để viết các mô-đun WebAssembly mà không cần thêm bộ nhớ nào và chỉ dùng ngăn xếp nội bộ máy ảo.
Trong trường hợp này, chúng ta sẽ cần sử dụng một số bộ nhớ bổ sung để cho phép truy cập tuỳ ý
tới pixel của hình ảnh và tạo ra một phiên bản xoay của hình ảnh đó. Đây là
mục đích của WebAssembly.Memory.
Quản lý bộ nhớ
Thông thường, một khi sử dụng thêm bộ nhớ, bạn sẽ cần phải
quản lý bộ nhớ đó. Những phần nào của bộ nhớ đang được sử dụng? Những ứng dụng nào miễn phí?
Chẳng hạn như trong C, bạn có hàm malloc(n) tìm một dung lượng bộ nhớ
trong số n byte liên tiếp. Các hàm thuộc loại này còn được gọi là "allocators".
Tất nhiên, việc triển khai trình phân bổ đang được sử dụng phải được đưa vào
WebAssembly và sẽ làm tăng kích thước tệp của bạn. Kích thước và hiệu suất này
trong số các chức năng quản lý bộ nhớ này có thể thay đổi khá đáng kể tuỳ thuộc vào
thuật toán được sử dụng, đó là lý do tại sao nhiều ngôn ngữ cung cấp nhiều cách triển khai
để chọn ("dmalloc", "emmalloc", "wee_alloc", v.v.).
Trong trường hợp này, chúng ta biết kích thước của hình ảnh đầu vào (và do đó kích thước kích thước của hình ảnh đầu ra) trước khi chạy mô-đun WebAssembly. Ở đây, chúng ta đã nhìn thấy cơ hội: Thông thường, chúng tôi truyền vùng đệm RGBA của hình ảnh đầu vào dưới dạng tham số vào hàm WebAssembly và trả về hình ảnh được xoay dưới dạng hàm trả về giá trị. Để tạo giá trị trả về đó, chúng ta phải sử dụng trình phân bổ. Nhưng vì chúng ta biết tổng dung lượng bộ nhớ cần thiết (gấp hai lần dung lượng đầu vào một lần cho đầu vào và một lần cho đầu ra), chúng ta có thể đặt hình ảnh đầu vào vào Bộ nhớ WebAssembly sử dụng JavaScript, hãy chạy mô-đun WebAssembly để tạo một Thứ hai, xoay hình ảnh rồi sử dụng JavaScript để đọc lại kết quả. Chúng ta có thể mà không cần quản lý bộ nhớ!
Tha hồ lựa chọn
Nếu bạn đã xem hàm JavaScript gốc mà chúng tôi muốn cho WebAssembly-fy, bạn có thể thấy rằng đây chỉ là một công nghệ tính toán không có API dành riêng cho JavaScript. Do đó, vị trí địa lý phải khá thẳng để chuyển mã này sang bất kỳ ngôn ngữ nào. Chúng tôi đánh giá 3 ngôn ngữ biên dịch thành WebAssembly: C/C++, Rust và CouncilScript. Câu hỏi duy nhất chúng ta cần trả lời cho mỗi ngôn ngữ là: Làm cách nào để truy cập vào bộ nhớ thô mà không sử dụng các chức năng quản lý bộ nhớ?
C và Emscripten
Emscripten là trình biên dịch C cho mục tiêu WebAssembly. Mục tiêu của Emscripten là làm hàm thay thế cho các trình biên dịch C nổi tiếng như GCC hoặc clang và gần như tương thích với cờ. Đây là một phần cốt lõi trong sứ mệnh của Emscripten vì công cụ này muốn biên dịch mã C và C++ hiện có thành WebAssembly dễ dàng như nhất có thể.
Về bản chất, việc truy cập vào bộ nhớ thô của C và các con trỏ cũng tồn tại lý do:
uint8_t* ptr = (uint8_t*)0x124;
ptr[0] = 0xFF;
Ở đây, chúng ta sẽ biến số 0x124 thành con trỏ thành con trỏ 8 bit không dấu
số nguyên (hoặc byte). Thao tác này sẽ chuyển biến ptr thành một mảng một cách hiệu quả
bắt đầu từ địa chỉ bộ nhớ 0x124 mà chúng ta có thể sử dụng như bất kỳ mảng nào khác,
cho phép chúng ta truy cập các byte riêng lẻ để đọc và ghi. Trong trường hợp này, chúng ta
đang xem xét vùng đệm RGBA của hình ảnh mà chúng tôi muốn sắp xếp lại để đạt được
xoay. Để di chuyển một pixel, chúng ta thực sự cần phải di chuyển 4 byte liên tiếp cùng một lúc
(một byte cho mỗi kênh: R, G, B và A). Để làm cho điều này dễ dàng hơn, chúng ta có thể tạo một
mảng số nguyên 32 bit chưa ký. Theo quy ước, hình ảnh đầu vào sẽ bắt đầu
tại địa chỉ 4 và hình ảnh đầu ra của chúng ta sẽ bắt đầu ngay sau hình ảnh đầu vào
kết thúc:
int bpp = 4;
int imageSize = inputWidth * inputHeight * bpp;
uint32_t* inBuffer = (uint32_t*) 4;
uint32_t* outBuffer = (uint32_t*) (inBuffer + imageSize);
for (int d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
for (int d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
int in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
outBuffer[i] = inBuffer[in_idx];
i += 1;
}
}
Sau khi chuyển toàn bộ hàm JavaScript sang C, chúng ta có thể biên dịch tệp C
với emcc:
$ emcc -O3 -s ALLOW_MEMORY_GROWTH=1 -o c.js rotate.c
Như thường lệ, emscripten tạo một tệp mã keo có tên c.js và một mô-đun wasm
có tên là c.wasm. Lưu ý rằng mô-đun wasm gzip chỉ ~260 Byte, trong khi
mã keo là khoảng 3,5KB sau gzip. Sau vài lần khó chịu, chúng tôi đã có thể bỏ qua
mã keo và tạo thực thể cho các mô-đun WebAssembly bằng vanilla API.
Bạn thường có thể thực hiện việc này với Emscripten, miễn là bạn không sử dụng bất cứ thứ gì
trong thư viện chuẩn C.
Rust
Rust là một ngôn ngữ lập trình mới, hiện đại có hệ thống kiểu chữ phong phú, không có thời gian chạy và một mô hình quyền sở hữu đảm bảo an toàn cho bộ nhớ cũng như đảm bảo an toàn cho luồng. Gỉ cũng hỗ trợ WebAssembly dưới dạng một tính năng cốt lõi và nhóm Rust đã đã đóng góp rất nhiều công cụ tuyệt vời cho hệ sinh thái WebAssembly.
Một trong những công cụ đó là wasm-pack, theo
nhóm công tác của rustwasm. wasm-pack
lấy mã của bạn và biến mã đó thành một mô-đun thân thiện với web
có sẵn với các gói như webpack. wasm-pack cực kỳ
nhưng hiện chỉ hoạt động với Rust. Nhóm này là
đang cân nhắc thêm khả năng hỗ trợ cho các ngôn ngữ nhắm mục tiêu WebAssembly khác.
Trong Rust, lát cắt là những mảng nằm trong C. Cũng giống như C, chúng ta cần tạo
lát cắt sử dụng địa chỉ bắt đầu của chúng ta. Điều này đi ngược lại với mô hình an toàn bộ nhớ
mà Rust thực thi, vì vậy, để có được cách thức, chúng ta phải sử dụng từ khoá unsafe,
cho phép chúng tôi viết mã không tuân thủ mô hình đó.
let imageSize = (inputWidth * inputHeight) as usize;
let inBuffer: &mut [u32];
let outBuffer: &mut [u32];
unsafe {
inBuffer = slice::from_raw_parts_mut::<u32>(4 as *mut u32, imageSize);
outBuffer = slice::from_raw_parts_mut::<u32>((imageSize * 4 + 4) as *mut u32, imageSize);
}
for d2 in 0..d2Limit {
for d1 in 0..d1Limit {
let in_idx = (d1Start + d1 * d1Advance) * d1Multiplier + (d2Start + d2 * d2Advance) * d2Multiplier;
outBuffer[i as usize] = inBuffer[in_idx as usize];
i += 1;
}
}
Biên dịch các tệp Rust bằng cách sử dụng
$ wasm-pack build
tạo ra mô-đun wasm 7,6KB với khoảng 100 byte mã keo (cả hai sau gzip).
AssemblyScript
AssemblyScript là một dự án trẻ hướng đến việc trở thành trình biên dịch TypeScript-to-WebAssembly. Bây giờ cần lưu ý rằng nó sẽ không chỉ sử dụng bất kỳ TypeScript nào. MultiplexScript sử dụng cú pháp tương tự như TypeScript nhưng chuyển chuẩn cho riêng họ. Thư viện chuẩn của họ mô hình hoá khả năng của WebAssembly. Điều đó có nghĩa là bạn không thể chỉ biên dịch bất kỳ TypeScript nào bạn đang về WebAssembly, nhưng điều đó không có nghĩa là bạn không phải tìm hiểu để viết WebAssembly!
for (let d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
for (let d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
let in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
store<u32>(offset + i * 4 + 4, load<u32>(in_idx * 4 + 4));
i += 1;
}
}
Khi xem xét bề mặt kiểu dữ liệu nhỏ mà hàm rotate() có,
khá dễ dàng để chuyển mã này sang CouncilScript. Các hàm load<T>(ptr:
usize) và store<T>(ptr: usize, value: T) do hộiScript cung cấp để
truy cập vào bộ nhớ thô. Để biên dịch tệp hộiScript của chúng tôi,
chúng ta chỉ cần cài đặt gói npm AssemblyScript/assemblyscript và chạy
$ asc rotate.ts -b assemblyscript.wasm --validate -O3
hộiScript sẽ cung cấp cho chúng ta một mô-đun wasm ~300 Byte và không có mã keo. Mô-đun này chỉ hoạt động với API WebAssembly vanilla.
Điều tra viên WebAssembly
7,6KB của Rust lớn bất ngờ khi so sánh với 2 ngôn ngữ khác. Có là một số công cụ trong hệ sinh thái WebAssembly có thể giúp bạn phân tích các tệp WebAssembly của bạn (bất kể ngôn ngữ được tạo là gì) và cho bạn biết điều gì đang xảy ra, đồng thời giúp bạn cải thiện tình hình của mình.
Twiggy
Twiggy là một công cụ khác của Rust
Nhóm WebAssembly trích xuất nhiều dữ liệu chi tiết từ WebAssembly
. Công cụ này không dành riêng cho Rust và cho phép bạn kiểm tra những thứ như
biểu đồ cuộc gọi của mô-đun, xác định các phần không dùng đến hoặc thừa và tìm ra
phần nào đang đóng góp vào tổng kích thước tệp của mô-đun của bạn. Chiến lược phát hành đĩa đơn
bạn có thể thực hiện sau bằng lệnh top của Twiggy:
$ twiggy top rotate_bg.wasm
Trong trường hợp này, chúng ta có thể thấy rằng phần lớn kích thước tệp bắt nguồn từ trình phân bổ. Điều đó thật đáng ngạc nhiên vì mã của chúng ta không sử dụng tính năng phân bổ động. Một yếu tố đóng góp quan trọng khác là "tên hàm" tiểu mục.
dải wasm
wasm-strip là một công cụ trong Bộ công cụ nhị phân WebAssembly, hay viết tắt là wabt. Chiến dịch này có
một số công cụ cho phép bạn kiểm tra và thao tác với các mô-đun WebAssembly.
wasm2wat là một trình phân tách có thể biến mô-đun wasm nhị phân thành
ở định dạng mà con người có thể đọc được. Wabt cũng chứa wat2wasm cho phép bạn bật
định dạng mà con người đọc được đó trở lại mô-đun wasm nhị phân. Mặc dù chúng tôi đã sử dụng
hai công cụ bổ sung này để kiểm tra các tệp WebAssembly, chúng tôi nhận thấy rằng
wasm-strip sao cho hữu ích nhất. wasm-strip xoá các phần không cần thiết
và siêu dữ liệu từ mô-đun WebAssembly:
$ wasm-strip rotate_bg.wasm
Điều này làm giảm kích thước tệp của mô-đun gỉ từ 7,5KB xuống còn 6,6KB (sau gzip).
wasm-opt
wasm-opt là một công cụ của Binaryen.
Nó sử dụng một mô-đun WebAssembly và cố gắng tối ưu hoá mô-đun đó cho cả kích thước và
hiệu suất chỉ dựa trên mã byte. Một số công cụ như Emscripten đã chạy
công cụ này, một số công cụ khác thì không. Thông thường, bạn nên thử và tiết kiệm một chút
byte bổ sung bằng cách sử dụng các công cụ này.
wasm-opt -O3 -o rotate_bg_opt.wasm rotate_bg.wasm
Với wasm-opt, chúng ta có thể xoá bớt một số byte khác để còn lại tổng cộng
6,2KB sau gzip.
#![no_std]
Sau một thời gian tham khảo và nghiên cứu, chúng tôi đã viết lại mã Rust mà không sử dụng
Thư viện chuẩn của Rust, sử dụng
#![no_std]
của chúng tôi. Thao tác này cũng sẽ vô hiệu hoá hoàn toàn cơ chế phân bổ bộ nhớ động, xoá
mã phân bổ từ mô-đun của chúng tôi. Biên dịch tệp Rust này
thông qua tính năng
$ rustc --target=wasm32-unknown-unknown -C opt-level=3 -o rust.wasm rotate.rs
tạo ra mô-đun wasm 1,6KB sau wasm-opt, wasm-strip và gzip. Mặc dù
vẫn lớn hơn các mô-đun do C và CouncilScript tạo ra. Tuy nhiên, dung lượng này rất nhỏ
để được coi là ứng dụng có kích thước nhỏ gọn.
Hiệu suất
Trước khi đi đến kết luận chỉ dựa trên kích thước tệp — chúng tôi đã trải qua hành trình này để tối ưu hoá hiệu suất, chứ không phải kích thước tệp. Vậy làm cách nào để đo lường hiệu suất và kết quả ra sao?
Cách đo điểm chuẩn
Mặc dù WebAssembly là định dạng mã byte cấp thấp, nhưng bạn vẫn cần gửi định dạng này thông qua một trình biên dịch để tạo mã máy dành riêng cho máy chủ. Cũng giống như JavaScript, trình biên dịch hoạt động theo nhiều giai đoạn. Nói một cách đơn giản: Giai đoạn đầu tiên có nhiều nhanh hơn khi biên dịch nhưng có xu hướng tạo mã chậm hơn. Sau khi mô-đun bắt đầu đang chạy, trình duyệt sẽ quan sát những phần nào thường được sử dụng và gửi những phần đó thông qua một trình biên dịch tối ưu hoá nhiều hơn nhưng chậm hơn.
Trường hợp sử dụng của chúng ta thú vị ở chỗ mã để xoay hình ảnh sẽ được sử dụng một lần, có thể hai lần. Vì vậy, trong hầu hết các trường hợp, chúng tôi sẽ không bao giờ nhận được những lợi ích khác của trình biên dịch tối ưu hoá. Điều quan trọng cần lưu ý khi đo điểm chuẩn. Chạy các mô-đun WebAssembly của chúng tôi 10.000 lần trong một vòng lặp sẽ mang lại kết quả không thực tế. Để có con số thực tế, chúng ta nên chạy mô-đun một lần và đưa ra quyết định dựa trên các con số trong lần chạy đó.
So sánh hiệu suất
Hai biểu đồ này là các chế độ xem khác nhau về cùng một dữ liệu. Trong biểu đồ đầu tiên, chúng ta so sánh trên mỗi trình duyệt, trong biểu đồ thứ hai, chúng tôi so sánh theo ngôn ngữ được sử dụng. Năn nỉ lưu ý rằng tôi đã chọn thang thời gian logarit. Một điều quan trọng nữa là tất cả các điểm chuẩn này sử dụng cùng một hình ảnh thử nghiệm 16 megapixel và cùng một máy chủ ngoại trừ một trình duyệt không thể chạy trên cùng một máy.
Nếu không phân tích những biểu đồ này quá nhiều, thì rõ ràng chúng tôi đã giải quyết được vấn đề về hiệu suất: Tất cả các mô-đun WebAssembly chạy trong khoảng 500 mili giây trở xuống. Chiến dịch này xác nhận nội dung chúng tôi đã đưa ra ngay từ đầu: WebAssembly cung cấp cho bạn các nội dung dễ đoán hiệu suất. Bất kể chúng tôi chọn ngôn ngữ nào, sự khác biệt giữa các trình duyệt và ngôn ngữ là rất ít. Chính xác: Độ lệch chuẩn của JavaScript trên tất cả các trình duyệt là ~400 mili giây, trong khi độ lệch chuẩn của tất cả Các mô-đun WebAssembly trên tất cả các trình duyệt là khoảng 80 mili giây.
Nỗ lực
Một chỉ số khác là mức độ nỗ lực của chúng tôi để tạo và tích hợp mô-đun WebAssembly của chúng tôi vào squoosh. Khó chỉ định một giá trị số cho nên tôi sẽ không tạo bất kỳ biểu đồ nào nhưng có một vài điều tôi muốn chỉ ra:
hộiScript dễ sử dụng. Công cụ này không chỉ cho phép bạn sử dụng TypeScript để viết WebAssembly, giúp đồng nghiệp của tôi xem xét mã rất dễ dàng, nhưng tạo ra các mô-đun WebAssembly không cần keo, rất nhỏ với kích thước tốt hiệu suất. Công cụ trong hệ sinh thái TypeScript, như đẹp hơn và tslint, nhiều khả năng sẽ mang lại hiệu quả.
Gỉ kết hợp với wasm-pack cũng cực kỳ tiện lợi nhưng lại vượt trội
tại các dự án WebAssembly lớn hơn là các mối liên kết và việc quản lý bộ nhớ
cần thiết. Chúng tôi đã phải chuyển hướng một chút khỏi con đường hạnh phúc để đạt được sự cạnh tranh
kích thước tệp.
C và Emscripten đã tạo một mô-đun WebAssembly rất nhỏ và có hiệu suất cao đột phá, nhưng không can đảm đi vào đoạn mã keo và giảm nó xuống những thứ cần thiết để làm cho tổng kích thước (mô-đun WebAssembly + mã keo) kết thúc khá lớn.
Kết luận
Vậy bạn nên sử dụng ngôn ngữ nào nếu có đường dẫn nóng về JS và muốn tạo đường dẫn đó nhanh hơn hoặc nhất quán hơn với WebAssembly. Như thường lệ với hiệu suất câu hỏi, câu trả lời là: Tuỳ trường hợp. Vậy chúng tôi đã vận chuyển những gì?
So sánh ở kích thước mô-đun / sự đánh đổi hiệu suất của các ngôn ngữ khác nhau mà chúng tôi đã sử dụng, lựa chọn tốt nhất có vẻ là C hoặc CouncilScript. Chúng tôi quyết định gửi Rust. Có có nhiều lý do dẫn đến quyết định này: Tất cả các bộ mã hoá và giải mã đã được chuyển trong Squoosh cho đến nay được biên dịch bằng Emscripten. Chúng tôi muốn mở rộng kiến thức về Hệ sinh thái WebAssembly và sử dụng một ngôn ngữ khác trong phiên bản chính thức. hộiScript là một lựa chọn thay thế mạnh mẽ, nhưng dự án còn tương đối trẻ và trình biên dịch chưa hoàn thiện như trình biên dịch Rust.
Trong khi sự khác biệt về kích thước tệp giữa Rust và các ngôn ngữ khác trông khá quyết liệt trong biểu đồ tán xạ, nhưng thực tế thì điều này không quá lớn: Tải 500B hoặc 1,6KB thậm chí trên 2G chỉ mất chưa đến 1/10 giây. và Rust hy vọng sẽ sớm thu hẹp khoảng cách về kích thước mô-đun.
Xét về hiệu suất trong thời gian chạy, Rust có mức trung bình nhanh hơn trên các trình duyệt so với hộiScript. Đặc biệt là trong các dự án lớn hơn, Rust sẽ có nhiều khả năng tạo mã nhanh hơn mà không cần phải tối ưu hoá mã theo cách thủ công. Nhưng đó không ngăn bạn sử dụng công cụ mình thấy thoải mái nhất.
Tất cả những gì đang nói đến: CouncilScript là một khám phá tuyệt vời. Công cụ này cho phép truy cập web tạo ra các mô-đun WebAssembly mà không cần phải tìm hiểu ngôn ngữ. Nhóm BoardScript phản hồi rất nhanh và tích cực đang nỗ lực cải tiến chuỗi công cụ của mình. Chắc chắn chúng tôi sẽ theo dõi hộiScript trong tương lai.
Cập nhật: Rust
Sau khi xuất bản bài viết này, Nick Fitzgerald
của nhóm Rust đã chỉ cho chúng tôi
cuốn sách Rust Wasm xuất sắc của họ, chứa
một phần về cách tối ưu hoá kích thước tệp. Thực hiện theo
có hướng dẫn ở đó (đáng chú ý nhất là bật tính năng tối ưu hoá thời gian liên kết và
xử lý khi hoảng loạn) cho phép chúng tôi viết mã Rust "bình thường" và quay lại sử dụng
Cargo (npm của Rust) mà không làm tăng kích thước tệp. Mô-đun Rust kết thúc
lên tới 370B sau gzip. Để biết thông tin chi tiết, vui lòng xem tài liệu PR mà tôi mở trên Squoosh.
Xin đặc biệt cảm ơn Ashley Williams, Steve Klabnik, Nick Fitzgerald và Max Graey vì đã luôn giúp đỡ trong hành trình này.