Đầu tiên, (IMO) so sánh với Python gần như vô nghĩa. Chỉ so sánh với Objective-C là có ý nghĩa.
- Làm thế nào một ngôn ngữ lập trình mới có thể nhanh hơn rất nhiều?
Mục tiêu-C là một ngôn ngữ chậm. (Chỉ có phần C là nhanh, nhưng đó là vì C) Nó chưa bao giờ cực kỳ nhanh. Nó chỉ đủ nhanh cho mục đích (của Apple) và nhanh hơn các phiên bản cũ hơn của họ. Và nó chậm vì ...
- Do Objective-C có kết quả từ một trình biên dịch tồi hay có một cái gì đó kém hiệu quả hơn trong Objective-C so với Swift?
Mục tiêu-C đảm bảo mọi phương thức được gửi động. Không có công văn tĩnh nào cả. Điều đó khiến không thể tối ưu hóa chương trình Objective-C hơn nữa. Chà, có lẽ công nghệ JIT có thể là một số trợ giúp, nhưng AFAIK, Apple thực sự ghét đặc điểm hiệu suất không thể đoán trước và tuổi thọ đối tượng. Tôi không nghĩ rằng họ đã áp dụng bất kỳ công cụ JIT nào. Swift không có đảm bảo công văn động như vậy trừ khi bạn đặt một số thuộc tính đặc biệt để tương thích Objective-C.
- Làm thế nào bạn sẽ giải thích tăng hiệu suất 40%? Tôi hiểu rằng việc thu gom rác / kiểm soát tham chiếu tự động có thể tạo ra một số chi phí bổ sung, nhưng điều này nhiều không?
GC hoặc RC không quan trọng ở đây. Swift cũng đang sử dụng RC là chủ yếu. Không có GC ở đó, và cũng sẽ không trừ khi có một bước nhảy lớn về kiến trúc trên công nghệ GC. (IMO, nó là mãi mãi) Tôi tin rằng Swift có nhiều chỗ hơn để tối ưu hóa tĩnh. Đặc biệt là các thuật toán mã hóa ở mức độ thấp, vì chúng thường dựa vào các phép tính số lượng lớn và đây là một chiến thắng lớn cho các ngôn ngữ gửi tĩnh.
Thật ra tôi rất ngạc nhiên vì 40% dường như quá nhỏ. Tôi mong đợi nhiều hơn nữa. Dù sao, đây là bản phát hành ban đầu và tôi nghĩ tối ưu hóa không phải là mối quan tâm chính. Swift thậm chí không đầy đủ tính năng! Họ sẽ làm cho nó tốt hơn.
Cập nhật
Một số người tiếp tục làm phiền tôi để tranh luận rằng công nghệ GC là vượt trội. Mặc dù những điều dưới đây có thể tranh cãi, và chỉ là ý kiến rất thiên vị của tôi, nhưng tôi nghĩ rằng tôi phải nói để tránh tranh luận không cần thiết này.
Tôi biết các GC bảo thủ / theo dõi / thế hệ / gia tăng / song song / thời gian thực là gì và chúng khác nhau như thế nào. Tôi nghĩ rằng hầu hết các độc giả cũng đã biết điều đó. Tôi cũng đồng ý rằng GC rất tốt trong một số lĩnh vực và cũng cho thấy thông lượng cao trong một số trường hợp.
Dù sao, tôi nghi ngờ tuyên bố về thông lượng của GC luôn tốt hơn RC. Hầu hết chi phí hoạt động của RC đến từ hoạt động đếm số lần khóa và khóa để bảo vệ biến số đếm số lần đếm. Và thực hiện RC thường cung cấp một cách để tránh các hoạt động đếm. Trong Objective-C, có __unsafe_unretainedvà trong Swift, (mặc dù nó vẫn không rõ ràng đối với tôi) unowned. Nếu chi phí vận hành đếm lại không được chấp nhận, bạn có thể thử từ chối chúng một cách có chọn lọc bằng cách sử dụng các cơ chế. Về mặt lý thuyết, chúng ta có thể mô phỏng kịch bản sở hữu gần như duy nhất bằng cách sử dụng các tham chiếu không giữ lại rất mạnh mẽ để tránh chi phí RC. Ngoài ra tôi hy vọng trình biên dịch có thể tự động loại bỏ một số hoạt động RC không cần thiết rõ ràng.
Không giống như hệ thống RC, AFAIK, từ chối một phần các loại tham chiếu không phải là một tùy chọn trên hệ thống GC.
Tôi biết có nhiều đồ họa và trò chơi được phát hành đang sử dụng hệ thống dựa trên GC và cũng biết hầu hết trong số chúng đang phải chịu đựng vì thiếu tính quyết đoán. Không chỉ cho đặc tính hiệu suất, mà còn đối tượng quản lý trọn đời. Unity chủ yếu được viết bằng C ++, nhưng phần C # nhỏ bé gây ra tất cả các vấn đề hiệu suất kỳ lạ. Các ứng dụng lai HTML và vẫn bị ảnh hưởng bởi các đột biến không thể đoán trước trên bất kỳ hệ thống nào. Được sử dụng rộng rãi không có nghĩa là vượt trội. Nó chỉ có nghĩa là dễ dàng và phổ biến đối với những người không có nhiều lựa chọn.
Cập nhật 2
Một lần nữa để tránh tranh luận hoặc thảo luận không cần thiết, tôi thêm một số chi tiết.
@Asik cung cấp một ý kiến thú vị về gai nhọn của GC. Đó là cách chúng ta có thể coi cách tiếp cận ở mọi nơi kiểu giá trị như một cách để từ chối công cụ GC. Điều này khá hấp dẫn và thậm chí có thể thực hiện được trên một số hệ thống (ví dụ phương pháp hoàn toàn chức năng). Tôi đồng ý rằng điều này là tốt đẹp trong lý thuyết. Nhưng trong thực tế nó có một số vấn đề. Vấn đề lớn nhất là ứng dụng một phần của thủ thuật này không cung cấp các đặc điểm không có đột biến thực sự.
Bởi vì vấn đề độ trễ luôn là tất cả hoặc không có vấn đề gì . Nếu bạn có một khung hình tăng đột biến trong 10 giây (= 600 khung hình), thì toàn bộ hệ thống rõ ràng là không thành công. Đây không phải là về cách tốt hơn hoặc tồi tệ hơn. Nó chỉ là vượt qua hoặc thất bại. (hoặc ít hơn 0,0001%) Vậy nguồn gốc của GC tăng đột biến ở đâu? Đó là sự phân phối tải trọng kém. Và đó là vì GC về cơ bản là không xác định. Nếu bạn tạo bất kỳ rác nào, thì nó sẽ kích hoạt GC và tăng đột biến sẽ xảy ra. Tất nhiên, trong thế giới lý tưởng nơi tải GC sẽ luôn lý tưởng, điều này sẽ không xảy ra, nhưng tôi đang sống trong thế giới thực chứ không phải thế giới lý tưởng tưởng tượng.
Sau đó, nếu bạn muốn tránh tăng đột biến, bạn phải loại bỏ tất cả các loại ref khỏi toàn bộ hệ thống. Nhưng nó khó, điên rồ và thậm chí là không thể do phần không thể điều khiển được như hệ thống và thư viện lõi .NET. Chỉ cần sử dụng hệ thống không phải là dễ dàng hơn nhiều .
Không giống như GC, RC về cơ bản mang tính quyết định và bạn không phải sử dụng tối ưu hóa điên rồ này (chỉ hoàn toàn là loại giá trị) chỉ để tránh tăng đột biến. Những gì bạn phải làm là theo dõi và tối ưu hóa phần gây ra đột biến. Trong các hệ thống RC, spike là vấn đề thuật toán cục bộ, nhưng trong các hệ thống GC, gai luôn là vấn đề hệ thống toàn cầu.
Tôi nghĩ rằng câu trả lời của tôi đã đi quá nhiều chủ đề, và chủ yếu chỉ là sự lặp lại của các cuộc thảo luận hiện có. Nếu bạn thực sự muốn yêu cầu một số ưu thế / kém hơn / thay thế hoặc bất cứ điều gì khác về nội dung của GC / RC, có rất nhiều cuộc thảo luận hiện có trong trang web này và StackOverflow, và bạn có thể tiếp tục chiến đấu ở đó.
