điều kiện vs bộ phận

Question

cho các tuyên bố sau đó được thực hiện rất nhiều:

iNormVal = iVal/uRatio; 

sẽ sau có ý nghĩa hơn (hiệu suất khôn ngoan) nếu uRatio == 1 nhất (90%) của thời gian?

if(uRatio > 1) 
iNormVal = iVal/uRatio; 
else 
iNormVal = iVal; 

nhờ ..

Answer 1

Bạn cần phải profile này để có được một phép đo, nó quá khó đoán. Trình biên dịch có thể quyết định bạn đã sai và xóa thử nghiệm, vì vậy hãy kiểm tra và không tối ưu hóa.

Chi phí thực tế của một bộ phận (số nguyên) có thể khá thấp, đặc biệt là trên các bộ vi xử lý hiện đại dành cho máy tính để bàn. Theo số this PDF, chi phí trên cầu hiện đại (Wolfdale/Nehalem/Sandy Bridge) của bộ phận 32/32-bit tương ứng là 14-23/17-28/20-28. Vì vậy, nếu bạn thực sự làm điều này rất nhiều, nó có thể tăng lên. Trong trường hợp đó, hãy xem xét các tùy chọn song song (vectơ hóa) nếu có thể.

Tôi sẽ cố gắng tránh nó nếu có thể, vì nó giới thiệu một chi nhánh. Các nhánh có hai nhược điểm: chúng làm cho mã phức tạp hơn bằng cách giới thiệu nhiều đường dẫn mà lập trình viên đọc mã phải hiểu, và chúng cũng có thể giới thiệu chi phí thực thi.

Answer 2

Điều đó tùy thuộc.

Mã có trong ứng dụng quan trọng về hiệu suất không? Nếu vậy thì nó có thể giúp hoàn thiện khôn ngoan. Nếu không tốt sau đó tôi thường sẽ sai về phía hoặc đọc được và không giới thiệu thêm nếu tuyên bố.

Ngay cả khi nó đang ở trong một ứng dụng quan trọng hiệu suất, nó thường là các tương tác ranh giới bên ngoài chiếm 95% thời gian hoàn thiện như tương tác với cơ sở dữ liệu hoặc dịch vụ bên ngoài. Các trình biên dịch thường thực thi rất nhanh và nếu các câu lệnh rất rẻ. Khi chúng tôi thường cấu hình mã của chúng tôi, hiếm khi chúng tôi thực hiện thay đổi như những gì bạn đã mô tả chỉ vì lý do hoàn hảo. Việc sử dụng sai vòng lặp và các loại tương tự đôi khi có thể chống đỡ nhưng chúng tôi hiếm khi thêm các câu lệnh như được mô tả.

Hope this helps ...

Answer 3

Vì bạn phát hiện điều này như một nút cổ chai tiềm năng, đó là rất khả năng vị trí này là hoàn toàn không liên quan cho tốc độ tổng thể của ứng dụng. Nghiêm túc, con người, ngay cả lập trình viên guru, nổi tiếng là xấu khi phát hiện các tắc nghẽn thực sự. (Sự khác biệt là lập trình viên tốt thừa nhận và rao giảng rằng, trong khi đàn em giữ dành thời gian để tối ưu hóa các điểm không thích hợp.)

Nói chung tôi thấy phương pháp này để tối ưu hóa hữu ích nhất:

1. Nếu tốc độ là một mối quan tâm lớn, lên lịch thời gian đáng kể để tối ưu hóa được thực hiện trước khi phát hành ứng dụng của bạn.
2. Thiết kế mã của bạn để mã không thể bi quan vốn có thể thao.
3. Triển khai cách dễ nhất để hiểu mã. Ngăn chặn sự bi quan rõ ràng (giống như truyền tham số theo giá trị thay vì tham chiếu), nhưng không được quá mức.
4. Kiểm tra nếu quá chậm.Nếu có hồ sơ ứng dụng và xác định các điểm nóng.
5. Đặt tài nguyên thành tối ưu hóa (và do đó có khả năng làm xáo trộn) những điểm nóng đó, định dạng lặp lại để kiểm tra xem những thay đổi nào có thể trợ giúp.
6. Dừng khi ứng dụng đủ nhanh.

(Nó khác cho mã thư viện, rõ ràng, nhưng những vài bước sẽ mang bạn một chặng đường dài.)

Answer 4

Nếu bạn quyết định đi với phân nhánh sau đó bạn có thể kiểm tra đầu tiên đối với trường hợp chung. Nó có thể đọc được nhiều hơn một chút và nên có hiệu năng tốt hơn một chút.

if(uRatio <= 1) { 
    iNormVal = iVal; 
} 
else { 
    iNormVal = iVal/uRatio; 
} 

Để dễ đọc hơn, bạn có thể thêm biến cục bộ có tên tốt chứa kết quả biểu thức.

unsigned int uSmallRatio = uRatio <= 1; 
if(uSmallRatio) { 
    iNormVal = iVal; 
} 
else { 
    iNormVal = iVal/uRatio; 
} 

Trình biên dịch có thể tối ưu hóa mã này vào cùng một mã máy như cách tiếp cận đầu tiên. Tôi không chắc chắn về điều này mặc dù.

Tương tự như vậy bạn có thể làm điều này không nhưng nó là đẹp:

iNormVal = uRatio <= 1 ? iVal : iVal/uRatio; 

Cuối cùng cách tiếp cận khác sẽ là:

iNormVal = iVal; 
if(uRatio > 1) { /*explain why you do this so it won't be changed by somebody else*/ 
    iNormVal = iVal/uRatio; 
} 

tôi chắc chắn rằng có những cách tiếp cận khác để xem xét.

Kính trọng ...

Answer 5

Điều khoản if thực sự có khả năng sẽ làm cho chương trình chậm hơn. Phân nhánh là thực sự kém hiệu quả vì bộ vi xử lý hiện đại là pipelined và các chi nhánh ngăn không cho đường ống hoàn toàn hiệu quả. Đây là một vấn đề quan trọng như vậy mà nỗ lực đáng kể đi vào branch prediction, nhưng điều đó sẽ không giúp ích gì trong trường hợp này. Ngay cả khi dự đoán là đúng 90% thời gian, điều đó có nghĩa là một đường ống trống 10% thời gian, điều này còn tệ hơn nhiều so với phân chia int (đặc biệt là khi tính đến mệnh đề if sẽ mất thời gian).

Nhưng rất có thể nó không quan trọng chút nào vì mã của bạn dành phần lớn thời gian của nó ở một nơi hoàn toàn khác, khiến cho toàn bộ câu hỏi này lãng phí rất nhiều thời gian.

Answer 6

Hầu hết các vấn đề về hiệu suất đều là hệ tư tưởng (bạn thiết kế sai cách) hoặc triển khai thuật toán chậm hơn đã được chứng minh (các lựa chọn nhất định).

Ngoài ra, hiệu suất đạt được sẽ ở cấp độ lắp ráp và sẽ phụ thuộc vào nền tảng.

Tôi khó có thể đề nghị điều này như là một mối quan tâm thực tế cho hiệu suất, trừ khi bạn thực sự bị ràng buộc về hiệu suất, tại thời điểm đó bạn cần phải kiểm tra ở trên đầu tiên.

Tất cả những gì bạn đã làm là nâng cao lông mày của người sẽ duy trì mã của bạn. Hy vọng bạn có một lập trình viên lười biếng để lại một mình, hoặc bạn sẽ mất mã này.

Vì bạn không có bảo đảm ở cấp độ này, mã sẽ hoạt động như thế nào trên các nền tảng khác nhau cho các trình biên dịch, tùy chọn trình biên dịch và tối ưu hóa khác nhau, thậm chí bạn có thể mất mã để tối ưu hóa trình biên dịch. Tốt nhất là tập trung vào các vấn đề lớn hơn.