Sự cố với mã ARM NEON lõi kép của Qualcomm Scorpion?

Question

Tôi đang phát triển một thư viện gốc cho Android, nơi tôi sử dụng tối ưu hóa lắp ráp ARM và đa luồng để có được hiệu suất tối đa trên chipset ARM lõi kép MSM8660. Trong khi thực hiện một số phép đo tôi nhận thấy như sau:

1. Các đơn luồng thư viện với NEON tối ưu hóa là nhanh hơn đơn luồng thư viện với ARMv6 tối ưu hóa (như mong đợi).
2. Các đa luồng thư viện với ARMv6 tối ưu hóa là nhanh hơn đơn luồng thư viện với ARMv6 tối ưu hóa (như mong đợi).
3. Các đa luồng thư viện với NEON tối ưu hóa là chậm hơn thư viện với NEON tối ưu hóa đơn luồng (chắc chắn không mong đợi!).

Tôi đã thử tìm kiếm trên mạng để giải thích lý do tại sao điều này là nhưng cho đến nay không tìm thấy bất kỳ. Nó gần như có vẻ như tất cả các lõi chia sẻ cùng một đường ống NEON hoặc một cái gì đó như thế, nhưng tất cả các sơ đồ dường như chỉ ra rằng mỗi lõi nên có đơn vị NEON riêng của nó. Có ai biết tại sao điều này xảy ra?

Answer 1

Có thể do bộ nhớ cache bị mất. Thật khó để nói mà không có thêm thông tin.

Answer 2

Dự đoán của tôi là vì hình phạt chu kỳ bổ sung liên quan đến việc xả đường ống NEON. Đường ống NEON nằm phía sau phần còn lại của lõi và do đó bạn sẽ thấy thêm một hình phạt chu kỳ cho các nhánh bị nhỡ và vân vân.

Nếu chủ đề phải đồng bộ hóa khá thường xuyên, hoặc nếu bạn có nhiều khóa, tôi nghĩ bạn sẽ thấy những hình phạt lớn với NEON.

Cách duy nhất bạn sẽ tận dụng NEON để đạt được hiệu suất tổng thể với mã đa luồng là nếu mã này là song song một cách lúng túng và có rất ít và không liên lạc giữa các luồng.

Answer 3

Trước hết, bạn đang sử dụng thư viện nào? Bạn đang chính xác, mỗi lõi có đơn vị NEON riêng của nó, Tuy nhiên, thiết bị độc quyền của riêng họ là VeNum và không cung cấp nhiều thông tin về nó, Nó được thiết kế cho Scorpion Cortex-A8 dựa trên 8x50 và là khá tốt hơn so với việc thực hiện riêng của NEON SIMD, Tuy nhiên, một điều tốt là họ (qcom) thiết kế phần cứng của họ theo cách tương thích với thiết kế cơ sở refrence vì vậy hầu hết mã cho một cortex-A8 sẽ hoạt động tốt với Scorpion mặc dù một số hiệu suất hit do thời gian hướng dẫn khác nhau có thể.

Nếu bạn đang sử dụng "softfp" để biên dịch chương trình, bạn sẽ có phí trên 20 chu kỳ cho mọi chức năng bạn gọi sử dụng đối số dấu chấm động hoặc sử dụng đơn vị NEON như chuyển dữ liệu đăng ký từ lõi ARM để đơn vị Neon và ngược lại là khá chậm và đôi khi có thể gian hàng cốt lõi cho nhiều chu kỳ chờ đợi cho các đường ống để tuôn ra.

Cũng cho chương trình luồng sử dụng đơn vị dấu chấm động, hạt nhân phải lưu sổ đăng ký FP trong khi chuyển ngữ cảnh để phát sinh thêm hình phạt cho chủ đề vì chúng tôi đã biết thanh ghi di chuyển từ neon sang cánh tay chậm và được biết là gian hàng Đường ống dẫn. Ngoài ra nhiều yếu tố khác có thể dẫn đến điều này như tối ưu hóa xấu từ trình biên dịch, bộ nhớ cache bỏ lỡ, không sử dụng tính năng phát hành kép của bọ cạp, lập lịch trình chỉ dẫn xấu và chuyển đổi luồng của bạn từ lõi này sang lõi khác liên tục.