JIT (javascript / canvas) so với AOT (Flash) có ý nghĩa gì về hiệu suất trò chơi dựa trên trình duyệt?

Theo kinh nghiệm của tôi, cho đến tận ngày nay, tôi vẫn thấy nhiều sự chậm trễ về hình ảnh trong chuyển động / hoạt hình thực thể trong các trò chơi dựa trên JavaScript (Canvas) so với các trò chơi dựa trên Flash.

Tại sao lại thế này - chính xác thì mức độ giảm dần ở mức cơ bản nhất giữa trình biên dịch JIT vs AOT trong kịch bản cụ thể của JavaScript so với Flash.

Đây không phải là phương pháp biên dịch khiến các trò chơi bị lag, đó là trình thu gom rác và trình thu gom rác Flash tách biệt với các trình duyệt.

Tôi nghĩ rằng tôi hoàn toàn có thể tự tin lý do rằng bạn chạy Firefox, bởi vì trình thu gom rác Firefox là thứ tồi tệ nhất bạn có thể nhận được, từ quan điểm chơi game. Nếu bạn chỉ mở một tab và chạy một trò chơi JavaScript nhẹ trong đó, nó thường có thể chấp nhận được, thậm chí có thể không được chú ý. Nhưng nếu bạn mở một loạt các tab, hãy chạy một cái gì đó đòi hỏi khắt khe hơn một chút hoặc sử dụng Fireorms, bạn sẽ dễ dàng nhận được các độ trễ thông thường vượt quá 100 ms.

Tôi đã không thực hiện bất kỳ thử nghiệm mở rộng nào trong một thời gian, nhưng Chrome luôn thực hiện rất tốt trong vấn đề này và cả IE9 và Safari dường như cũng làm một công việc chấp nhận được.

Tôi đã tạo một công cụ để kiểm tra độ trễ JavaScript, bạn có thể chơi với nó nếu bạn thích: http://ebusiness.hopto.org/lagtest/

Thật khó để nói mà không nhìn vào mã thực tế nhưng một vài điểm:

• Flash đã được khoảng lâu hơn. Những người tạo ra các công cụ và thư viện cho nó có nhiều kinh nghiệm xử lý hoạt hình. Tôi không phải là một fan hâm mộ lớn của các công cụ và công nghệ độc quyền nhưng tôi sẽ không bao giờ đánh bại một nhà phát triển ActionScript, người biết anh ấy đang làm gì.

• Các trình duyệt JIT cũng tương đối mới đối với các nhà phát triển JS. Các lựa chọn tốt nhất cho các chuyên gia hoàn hảo thực sự tốt vẫn là thứ chúng tôi sắp xếp như một cộng đồng. Chức năng nội tuyến defs từng là một điều ngu ngốc biên giới phải làm trong rất nhiều trường hợp. Bây giờ, đó là một cách tuyệt vời để tăng sự hoàn hảo trong nhiều tình huống JIT.

• Bình thường hóa cho nhiều trình duyệt không cần nhưng thường không dẫn đến việc không tận dụng hết khả năng của một trình duyệt nhất định.

• (chỉnh sửa: không hoàn toàn đúng về vấn đề này nhưng vẫn có thể có một điểm ở đây - Erik) Trình cắm Flash thân thiện với vectơ và được hiểu rộng rãi về cách tận dụng tối đa lợi thế đó. Liệu các kế hoạch thừa kế sẽ giúp chúng ta có rất nhiều điều tốt với các đối tượng bối cảnh canvas vẫn được nhìn thấy nhưng tôi nghi ngờ nó sẽ ở cùng một mức độ chiến thắng mà bạn có được từ vector.

Một điều thú vị mà tôi ngạc nhiên chưa ai nhắc đến là sự khác biệt trong các kiểu biên dịch JIT, bởi vì Flash vẫn là JIT được biên dịch và, trong hầu hết các trình duyệt hiện đại, JavaScript cũng vậy, tuy nhiên Flash là ngôn ngữ được gõ mạnh, có nghĩa là có cả một lĩnh vực tối ưu hóa mà nó có thể thực hiện (chẳng hạn như phát trực tiếp một cuộc gọi đến một phương thức (điều mà JavaScript không thể làm được)), mà JavaScript không thể thực hiện được vì nó được gõ động. Bạn có thể thay thế toàn bộ định nghĩa của hàm trong JavaScript tại bất kỳ điểm nào bạn muốn và định nghĩa mới đó là cái phải được gọi. (JavaScript vẫn có thể thực hiện một cuộc gọi gián tiếp mà sẽ không tốn kém hơn nhiều) Truy cập trường trên một trường thực sự là một ví dụ tốt hơn so với gọi phương thức, bởi vì JavaScript thậm chí có thể thực hiện điều này một cách gián tiếp,

Một sự khác biệt trong hiệu suất là, như đã được đề cập, GC. Tôi nghi ngờ (tôi đã không kiểm tra) rằng hầu hết các trình duyệt sử dụng một GC đếm tham chiếu (bởi vì tất cả bộ nhớ mà GC phân bổ cho một trang có thể được giải phóng khi trang còn lại, đây thực sự là một trong những nơi tốt nhất để sử dụng GC đếm tham chiếu ), hoặc một quét quét bảo thủ (chẳng hạn như Boehm). Cái sau có thể chậm hơn đáng kể so với cái trước nếu nó không được thực hiện đúng. (Boehm là một ví dụ về việc triển khai đúng) Mặt khác, Flash sử dụng một GC chính xác (dễ thực hiện hơn trong một hệ thống được gõ mạnh). Bởi vì Flash sử dụng một GC chính xác, nó không có chi phí thời gian chạy của việc đếm tham chiếu. (không lớn lắm, nhưng vẫn còn đó) Một ví dụ điển hình về một GC chính xác là Mono SGen, cũng thu gọn đống.

Sau đó, có một thực tế là JavaScript không được thiết kế với hình ảnh động. (như đã được đề cập) Theo như tôi biết, sẽ không có trình duyệt nào phát ra các hướng dẫn kiểu SSE cho các vòng lặp hoạt hình, trong đó, vì các chức năng kết xuất lõi trong Flash có thể đã được tối ưu hóa để đạt hiệu suất cao nhất. (ở một số nơi được viết trong lắp ráp thô)

Nói chung, thực tế là một ngôn ngữ động sẽ luôn chậm hơn ngôn ngữ gõ tĩnh nếu nó phải được biên dịch kịp thời để không khiến người dùng phàn nàn về sự chậm chạp của nó.

IMHO khác biệt đến từ thực tế là Flash được xây dựng từ mặt đất để thực hiện chính xác điều đó, hình ảnh động. Flash thực hiện các kỹ thuật (mặc dù kém theo phán đoán chính) để hiển thị mượt mà hơn khi chạy theo mặc định, khi ở JS, bạn sẽ cần thực hiện các triển khai đó theo cách thủ công.

Có những ví dụ về các triển khai tuyệt vời của JS / Canvas chạy tốt hơn hầu hết các trò chơi Flash mà tôi thấy xung quanh. Tất cả đều đến với nhà phát triển làm cho họ.

ngoài khía cạnh GC, JIT của các công nghệ này, còn có khoảng cách giữa việc sử dụng phần cứng.

trong phiên bản mới nhất của flash player, flash đã bắt đầu sử dụng khả năng tăng tốc phần cứng để hiển thị những hình ảnh đó, giúp quá trình kết xuất nhanh hơn và chất lượng tốt hơn. mặt khác, các trò chơi điều khiển JS trên một số trình duyệt (FF, CHROME) đã bắt đầu điều này. Mặc dù có một ngoại lệ, trình duyệt IE9 đã bắt đầu kiến ​​trúc lại từ lớp trừu tượng phần cứng, các trình duyệt từ IE9 đã đạt được tiến bộ to lớn trong việc sử dụng tăng tốc phần cứng, do đó kết xuất đồ họa trên các trình duyệt này chắc chắn tốt hơn và nhanh hơn các trình duyệt khác.