12/08/2018, 16:57

Where is WebAssembly now and what’s next?

Ngay cả trong những bản phát hành ban đầu, WebAssembly đã có tốc độ khá nhanh. Nhưng nó sẽ thậm chí còn nhanh hơn trong thời gian tới, thông qua một sự kết hợp của các bản sửa lỗi và các tính năng mới. Improving WebAssembly performance in browsers Một số cải tiến tốc độ sẽ được thực hiện, các ...

Ngay cả trong những bản phát hành ban đầu, WebAssembly đã có tốc độ khá nhanh. Nhưng nó sẽ thậm chí còn nhanh hơn trong thời gian tới, thông qua một sự kết hợp của các bản sửa lỗi và các tính năng mới.

Improving WebAssembly performance in browsers

Một số cải tiến tốc độ sẽ được thực hiện, các trình duyệt hỗ trợ WebAssembly sẽ cải thiện tốc độ trong engine của chúng. Các nhà cung cấp trình duyệt đang làm việc với những vấn đề này một cách độc lập.

Faster function calls between JS and WebAssembly

Hiện nay, thời gian gọi một function WebAssembly trong mã JS là chậm hơn so với mong muốn. Đó là bởi vì nó đã làm một cái gì đó gọi là “trampolining”. Các JIT không biết làm thế nào để xử lý trực tiếp với WebAssembly, vì vậy nó định tuyến WebAssembly sang một cái gì đó để thực hiện. Đây là một bộ phận trong engine, thứ đã được thiết lập để chạy mã WebAssembly đã tối ưu. Điều này có thể chậm hơn lên đến 100x so với việc nếu JIT biết làm thế nào để xử lý WebAssembly một cách trực tiếp. Bạn sẽ không nhận thấy chi phí này nếu bạn đang ném một task lớn duy nhất vào module WebAssembly. Nhưng nếu bạn có rất nhiều lời gọi giữa WebAssembly và JS (ví dụ như bạn thực hiện nhiều task nhỏ hơn), khi đó thì chi phí này sẽ là đáng để chú ý.

Faster load time

JITs phải quản lý sự cân bằng giữa thời gian tải và thời gian thực hiện code. Nếu bạn dành nhiều thời gian biên dịch và tối ưu hóa ban đầu, khi đó tốc độ thực hiện sẽ tăng lên, nhưng nó cũng làm việc khởi động bị chậm đi. Kể từ WebAssembly không cần phải suy đoán những type sẽ được sử dụng, các công cụ không cần phải lo lắng về việc giám sát các type trong thời gian chạy. Điều này cho phép chúng có thêm nhiều lựa chọn, ví dụ parallelizing việc biên dịch với thực thi. Thêm vào đó, bổ sung mới nhất của API JavaScript sẽ cho phép streaming việc biên dịch WebAssembly. Điều này có nghĩa rằng engine có thể bắt đầu biên dịch trong khi các byte dữ liệu vẫn đang được liên tục tải về. Trong Firefox, họ đang làm việc trên một hệ thống hai trình biên dịch. Một trình biên dịch sẽ chạy ban đầu và thực hiện việc tối ưu hóa code một cách không đầy đủ. Trong khi nó đang thực hiện việc đó, một trình biên dịch khác sẽ thực hiện việc tối ưu hóa đầy đủ ở background. Phiên bản được tối ưu hóa đầy đủ của mã này sẽ được trao đổi khi nó đã sẵn sàng.

Adding post-MVP features to the spec

Một trong những mục tiêu của WebAssembly là chỉ định trong khối nhỏ và thử nghiệm trong suốt quá trình, chứ không phải là thiết kế tất cả mọi thứ từ ban đầu. Điều này có nghĩa có rất nhiều tính năng được mong đợi, nhưng không phải 100% suy nghĩ đã được nêu ra. Những tính năng này được gọi là tính năng trong tương lai. Đây chỉ là một vài trong số đó.

Working directly with the DOM

Hiện nay, không có cách nào để tương tác với DOM. Điều này có nghĩa bạn không thể làm một cái gì đó giống như element.innerHTML để cập nhật một node từ WebAssembly. Thay vào đó, bạn phải đi qua JS để thiết lập giá trị. Điều này có nghĩa là gọi một function JavaScript từ bên trong WebAssembly-cả function JavaScript và WebAssembly có thể được sử dụng như imports trong một module WebAssembly. Dù bằng cách nào, thì nhiều khả năng là đi qua JavaScript sẽ chậm hơn so với cách truy cập trực tiếp. Nên chức năng làm việc trực tiếp với DOM sẽ giúp cho các tác vụ thao tác nhiều với DOM trở nên nhanh hơn đáng kể.

Shared memory concurrency

Một cách để tăng tốc độ code là làm cho các phần khác nhau của chương trình có thể chạy đồng thời, song song với nhau. Điều này đôi khi có thể phản tác dụng, khi chi phí liên lạc giữa các thread có thể mất nhiều thời gian hơn so với chi phí cho các tác vụ ban đầu. Nhưng nếu bạn có thể chia sẻ bộ nhớ giữa các thread, chi phí này sẽ được giảm đi. Để làm điều này, WebAssembly sử dụng SharedArrayBuffer mới của JavaScript. Khi đã được đặt ra trong các trình duyệt, các nhóm làm việc có thể bắt đầu xác định WebAssembly nên làm việc với chúng như thế nào.

SIMD

Nếu bạn đọc các bài viết khác hoặc theo dõi về WebAssembly, bạn có thể đã nghe về hỗ trợ SIMD. Đó là từ viết tắt của Single Instruction, Multiple Data. Đó là một cách khác để thực hiện các task một cách song song với nhau. SIMD làm cho WebAssembly có thể có một cấu trúc dữ liệu lớn, giống như một vector của các số khác nhau, và áp dụng các lệnh tương tự đến các bộ phận khác nhau cùng một lúc. Bằng cách này, nó có thể đẩy nhanh tiến độ các loại tính toán phức tạp mà bạn cần cho các trò chơi hoặc VR. Điều này không phải là quá quan trọng đối với các nhà phát triển ứng dụng web thông thường. Nhưng nó là rất quan trọng đối với các nhà phát triển làm việc với đa phương tiện, chẳng hạn như các nhà phát triển trò chơi.

Exception handling

Nhiều code dựa trên các ngôn ngữ giống như C++ sử dụng exceptions. Tuy nhiên, exceptions chưa được quy định như một phần của WebAssembly. Nếu bạn đang soạn thảo code của bạn với Emscripten, nó sẽ bắt exception xử lý đối với một số mức tối ưu hóa biên dịch. Điều này là khá chậm, vì vậy bạn có thể sử dụng cờ DISABLE_EXCEPTION_CATCHING để tắt nó đi. Khi một exception được xử lý tự nhiên trong WebAssembly, thì việc này sẽ không cần thiết.

Other improvements—making things easier for developers

Một số tính năng trong tương lai không ảnh hưởng đến hiệu suất, nhưng sẽ làm cho cho các nhà phát triển có thể làm việc dễ dàng hơn với WebAssembly.

  • First-class source-level developer tools. Hiện nay, trình gỡ lỗi WebAssembly trong trình duyệt giống như trình gỡ lỗi assembly thô. Rất ít các nhà phát triển có thể ánh xạ mã nguồn của họ sang assembly. Tuy nhiên các ông cụ hỗ trợ đang được cải thiện để các nhà phát triển có thể gỡ lỗi mã nguồn của họ.
  • Garbage collection. Một vướng mắc hiện nay là WebAssembly không biết làm thế nào để tương tác với garbage collectors hiện có, như một builtin trong JS engine. Ý tưởng về tính năng tương lai này là để cho WebAssembly first-class truy cập vào GC builtin với một tập các loại nguyên thủy GC low-level và operations.
  • ES6 Module integration. Các trình duyệt hiện đang bổ sung hỗ trợ việc loading module JavaScript bằng cách sử dụng thẻ script. Khi tính năng này được bổ sung vào, một thẻ như <script src=url type="module"> có thể làm việc ngay cả khi url trỏ đến một mô-đun WebAssembly.

Conclusion

Hiện tại WebAssembly đã là nhanh. Và với các tính năng mới, cộng với những cải tiến việc thực hiện trong các trình duyệt, nó sẽ còn nhanh hơn nữa.

0