Lựa chọn nào tốt hơn để sử dụng để chia số nguyên cho 2?

Kỹ thuật nào sau đây là lựa chọn tốt nhất để chia số nguyên cho 2 và tại sao?

Kỹ thuật 1:

x = x >> 1;

Kỹ thuật 2:

x = x / 2;

Đây xlà một số nguyên.

Sử dụng các hoạt động mô tả tốt nhất những gì bạn đang cố gắng làm.

• Nếu bạn đang coi số đó là một chuỗi bit, hãy sử dụng bitshift.
• Nếu bạn đang coi nó như một giá trị số, hãy sử dụng phép chia.

Lưu ý rằng chúng không chính xác tương đương. Họ có thể cho kết quả khác nhau cho số nguyên âm. Ví dụ:

-5 / 2  = -2
-5 >> 1 = -3

(nhàn rỗi)

Liệu cái đầu tiên trông giống như chia? Không. Nếu bạn muốn chia, sử dụng x / 2. Trình biên dịch có thể tối ưu hóa nó để sử dụng dịch chuyển bit nếu có thể (được gọi là giảm cường độ), điều này làm cho nó tối ưu hóa vi mô vô dụng nếu bạn tự làm.

Để giải quyết: có rất nhiều lý do để ưu tiên sử dụng x = x / 2; Dưới đây là một số:

• nó thể hiện ý định của bạn rõ ràng hơn (giả sử bạn không xử lý các bit đăng ký vặn bit hoặc một cái gì đó)

• trình biên dịch sẽ giảm điều này thành một hoạt động thay đổi

• ngay cả khi trình biên dịch không giảm nó và chọn thao tác chậm hơn ca, khả năng điều này sẽ ảnh hưởng đến hiệu suất chương trình của bạn theo cách có thể đo lường được là rất nhỏ (và nếu nó ảnh hưởng đến nó thì bạn có thể thực tế lý do để sử dụng ca)

• nếu phép chia sẽ là một phần của biểu thức lớn hơn, bạn có nhiều khả năng có quyền ưu tiên hơn nếu bạn sử dụng toán tử chia:

  x = x / 2 + 5;
  x = x >> 1 + 5;  // not the same as above

• số học đã ký có thể làm phức tạp mọi thứ thậm chí nhiều hơn vấn đề ưu tiên được đề cập ở trên

• để nhắc lại - trình biên dịch sẽ thực hiện điều này cho bạn bằng mọi cách. Trên thực tế, nó sẽ chuyển đổi phép chia theo hằng số thành một loạt các ca, cộng và nhân cho tất cả các loại số, không chỉ là lũy thừa của hai. Xem câu hỏi này để biết các liên kết đến nhiều thông tin hơn về điều này.

Nói tóm lại, bạn không mua gì bằng cách mã hóa một ca khi bạn thực sự có ý định nhân hoặc chia, ngoại trừ có thể tăng khả năng giới thiệu một lỗi. Đã là cả đời kể từ khi trình biên dịch không đủ thông minh để tối ưu hóa loại điều này thành sự thay đổi khi thích hợp.

Cái nào là lựa chọn tốt nhất và tại sao để chia số nguyên cho 2?

Phụ thuộc vào những gì bạn có nghĩa là tốt nhất .

Nếu bạn muốn đồng nghiệp ghét bạn hoặc làm cho mã của bạn khó đọc, tôi chắc chắn sẽ chọn tùy chọn đầu tiên.

Nếu bạn muốn chia một số cho 2, hãy đi với số thứ hai.

Hai cái này không tương đương nhau, chúng không hành xử giống nhau nếu số âm hoặc bên trong các biểu thức lớn hơn - bitshift có mức độ ưu tiên thấp hơn +hoặc -, phép chia có độ ưu tiên cao hơn.

Bạn nên viết mã của bạn để thể hiện ý định của nó là gì. Nếu hiệu suất là mối quan tâm của bạn, đừng lo lắng, trình tối ưu hóa thực hiện tốt công việc tối ưu hóa vi mô này.

Chỉ cần sử dụng split ( /), giả sử nó là rõ ràng hơn. Trình biên dịch sẽ tối ưu hóa cho phù hợp.

Tôi đồng ý với các câu trả lời khác mà bạn nên ủng hộ x / 2vì mục đích của nó rõ ràng hơn và trình biên dịch sẽ tối ưu hóa nó cho bạn.

Tuy nhiên, một lý do khác để thích x / 2hơn x >> 1là hành vi của >>phụ thuộc vào việc thực hiện nếu xlà một chữ ký intvà là tiêu cực.

Từ mục 6.5.7, gạch đầu dòng 5 của tiêu chuẩn ISO C99:

Kết quả E1 >> E2là vị trí bit E1dịch chuyển phải E2. Nếu E1có loại không dấu hoặc nếu E1có loại đã ký và giá trị không âm, giá trị của kết quả là phần không thể thiếu của thương số E1/ 2 ^E2. Nếu E1có loại đã ký và giá trị âm, giá trị kết quả được xác định theo thực hiện.

x / 2rõ ràng hơn và x >> 1không nhanh hơn nhiều (theo điểm chuẩn vi mô, nhanh hơn khoảng 30% đối với JVM Java). Như những người khác đã lưu ý, đối với các số âm, làm tròn số hơi khác nhau, vì vậy bạn phải xem xét điều này khi bạn muốn xử lý các số âm. Một số trình biên dịch có thể tự động chuyển đổi x / 2thành x >> 1nếu họ biết số này không thể âm (thậm chí tôi nghĩ rằng tôi không thể xác minh điều này).

Thậm chí x / 2có thể không sử dụng lệnh CPU phân chia (chậm), bởi vì một số phím tắt là có thể , nhưng nó vẫn chậm hơn x >> 1.

(Đây là câu hỏi C / C ++, các ngôn ngữ lập trình khác có nhiều toán tử hơn. Đối với Java cũng có dịch chuyển phải không dấu x >>> 1, lại khác nhau. Nó cho phép tính chính xác giá trị trung bình (trung bình) của hai giá trị, do đó (a + b) >>> 1sẽ trả về giá trị trung bình ngay cả đối với các giá trị rất lớn của avà b. Điều này được yêu cầu ví dụ cho tìm kiếm nhị phân nếu các chỉ số mảng có thể rất lớn. Có một lỗi trong nhiều phiên bản tìm kiếm nhị phân , vì chúng được sử dụng (a + b) / 2để tính trung bình. 't hoạt động chính xác. Giải pháp chính xác là sử dụng (a + b) >>> 1thay thế.)

Knuth nói:

Tối ưu hóa sớm là gốc rễ của mọi tội lỗi.

Vì vậy, tôi đề nghị sử dụng x /= 2;

Theo cách này, mã rất dễ hiểu và tôi cũng nghĩ rằng việc tối ưu hóa thao tác này ở dạng đó, không có nghĩa là một sự khác biệt lớn cho bộ xử lý.

Hãy xem đầu ra của trình biên dịch để giúp bạn quyết định. Tôi đã chạy thử nghiệm này trên x86-64 với
gcc (GCC) 4.2.1 20070719 [FreeBSD]

Cũng xem đầu ra trình biên dịch trực tuyến tại godbolt .

Những gì bạn thấy là trình biên dịch sử dụng một lệnh sarl(số học phải dịch chuyển) trong cả hai trường hợp, vì vậy nó nhận ra sự giống nhau giữa hai biểu thức. Nếu bạn sử dụng phép chia, trình biên dịch cũng cần điều chỉnh cho các số âm. Để làm điều đó, nó dịch chuyển bit dấu xuống bit thứ tự thấp nhất và thêm nó vào kết quả. Điều này khắc phục sự cố ngoài luồng khi dịch chuyển các số âm, so với những gì một phép chia sẽ làm.
Vì trường hợp chia làm 2 ca, trong khi trường hợp dịch chuyển rõ ràng chỉ làm một ca, giờ đây chúng ta có thể giải thích một số khác biệt về hiệu suất được đo bằng các câu trả lời khác ở đây.

Mã C với đầu ra lắp ráp:

Để phân chia, đầu vào của bạn sẽ là

int div2signed(int a) {
  return a / 2;
}

và điều này biên dịch thành

    movl    %edi, %eax
    shrl    $31, %eax
    addl    %edi, %eax
    sarl    %eax
    ret

tương tự cho ca

int shr2signed(int a) {
  return a >> 1;
}

với đầu ra:

    sarl    %edi
    movl    %edi, %eax
    ret

Chỉ cần một ghi chú thêm -

x * = 0,5 thường sẽ nhanh hơn trong một số ngôn ngữ dựa trên VM - đáng chú ý là mô tả hành động, vì biến sẽ không phải được kiểm tra để chia cho 0.

Sử dụng x = x / 2; HOẶC x /= 2;Vì có thể một lập trình viên mới sẽ làm việc với nó trong tương lai. Vì vậy, nó sẽ dễ dàng hơn cho anh ta để tìm hiểu những gì đang xảy ra trong dòng mã. Mọi người có thể không nhận thức được tối ưu hóa như vậy.

Tôi đang nói cho mục đích của các cuộc thi lập trình. Nói chung, họ có đầu vào rất lớn trong đó việc chia cho 2 diễn ra nhiều lần và được biết rằng đầu vào là dương hoặc âm.

x >> 1 sẽ tốt hơn x / 2. Tôi đã kiểm tra trên ideone.com bằng cách chạy một chương trình nơi diễn ra hơn 10 ^ 10 phân chia cho 2 thao tác. x / 2 mất gần 5,5 giây trong khi x >> 1 mất gần 2,6 giây cho cùng một chương trình.

Tôi sẽ nói có một số điều cần xem xét.

1. Bitshift nên nhanh hơn, vì không có tính toán đặc biệt nào thực sự cần thiết để dịch chuyển các bit, tuy nhiên như đã chỉ ra, có những vấn đề tiềm ẩn với số âm. Nếu bạn được đảm bảo có số dương, và đang tìm kiếm tốc độ thì tôi khuyên bạn nên dùng bithift.

2. Toán tử phân chia rất dễ dàng cho con người đọc. Vì vậy, nếu bạn đang tìm kiếm khả năng đọc mã, bạn có thể sử dụng điều này. Lưu ý rằng lĩnh vực tối ưu hóa trình biên dịch đã đi một chặng đường dài, vì vậy làm cho mã dễ đọc và dễ hiểu là thực hành tốt.

3. Tùy thuộc vào phần cứng cơ bản, hoạt động có thể có tốc độ khác nhau. Luật của Amdal là làm cho trường hợp phổ biến nhanh chóng. Vì vậy, bạn có thể có phần cứng có thể thực hiện các hoạt động khác nhau nhanh hơn những người khác. Ví dụ: nhân với 0,5 có thể nhanh hơn chia cho 2. (Cấp cho bạn có thể cần lấy sàn của phép nhân nếu bạn muốn thực thi phép chia số nguyên).

Nếu bạn theo đuổi hiệu suất thuần túy, tôi khuyên bạn nên tạo một số thử nghiệm có thể thực hiện các hoạt động hàng triệu lần. Lấy mẫu thực thi nhiều lần (cỡ mẫu của bạn) để xác định cái nào là tốt nhất về mặt thống kê với HĐH / Phần cứng / Trình biên dịch / Mã của bạn.

Đối với CPU, các hoạt động dịch chuyển bit nhanh hơn các hoạt động phân chia. Tuy nhiên, trình biên dịch biết điều này và sẽ tối ưu hóa phù hợp đến mức có thể, vì vậy bạn có thể viết mã theo cách có ý nghĩa nhất và yên tâm khi biết rằng mã của bạn đang chạy hiệu quả. Nhưng hãy nhớ rằng một unsigned inthộp (trong một số trường hợp) có thể được tối ưu hóa tốt hơn một intlý do đã được chỉ ra trước đây. Nếu bạn không cần ký hiệu, thì không bao gồm bit dấu.

x = x / 2; là mã phù hợp để sử dụng .. nhưng một thao tác phụ thuộc vào chương trình của riêng bạn về cách sản lượng bạn muốn sản xuất.

Làm cho ý định của bạn rõ ràng hơn ... ví dụ, nếu bạn muốn chia, sử dụng x / 2 và để trình biên dịch tối ưu hóa nó để thay đổi toán tử (hoặc bất cứ điều gì khác).

Các bộ xử lý ngày nay sẽ không để những tối ưu hóa này ảnh hưởng đến hiệu suất của các chương trình của bạn.

Câu trả lời cho điều này sẽ phụ thuộc vào môi trường bạn đang làm việc.

• Nếu bạn đang làm việc trên một vi điều khiển 8 bit hoặc bất cứ thứ gì không có phần cứng hỗ trợ cho phép nhân, việc dịch chuyển bit được mong đợi và phổ biến, và trong khi trình biên dịch gần như chắc chắn sẽ biến x /= 2thànhx >>= 1 , sự hiện diện của biểu tượng phân chia sẽ làm tăng thêm lông mày trong môi trường đó sử dụng một sự thay đổi để thực hiện một bộ phận.
• Nếu bạn đang làm việc trong môi trường hoặc phần mã quan trọng về hiệu năng, hoặc mã của bạn có thể được biên dịch với tối ưu hóa trình biên dịch, x >>= 1 với một bình luận giải thích lý do của nó có lẽ là tốt nhất cho mục đích rõ ràng.
• Nếu bạn không thuộc một trong các điều kiện trên, hãy làm cho mã của bạn dễ đọc hơn bằng cách sử dụng đơn giản x /= 2. Tốt hơn để lưu lập trình viên tiếp theo tình cờ xem mã của bạn trong 10 giây thực hiện thao tác thay đổi của bạn hơn là không cần thiết phải chứng minh rằng bạn biết sự thay đổi là tối ưu hóa trình biên dịch sans hiệu quả hơn.

Tất cả những giả định số nguyên không dấu. Sự thay đổi đơn giản có lẽ không phải là những gì bạn muốn ký. Ngoài ra, DanielH đưa ra một điểm tốt về việc sử dụng x *= 0.5cho một số ngôn ngữ nhất định như ActionScript.

mod 2, kiểm tra = 1. dunno cú pháp trong c. nhưng điều này có thể là nhanh nhất.

tạo ra sự thay đổi bên phải:

q = i >> n; is the same as: q = i / 2**n;

điều này đôi khi được sử dụng để tăng tốc các chương trình với chi phí rõ ràng. Tôi không nghĩ bạn nên làm điều đó. Trình biên dịch đủ thông minh để thực hiện tăng tốc tự động. Điều này có nghĩa là việc thay đổi sẽ giúp bạn không phải trả giá bằng sự rõ ràng .

Hãy xem trang này từ Lập trình C ++ thực tế.

Rõ ràng, nếu bạn đang viết mã cho người tiếp theo đọc nó, hãy tìm hiểu rõ ràng về "x / 2".

Tuy nhiên, nếu tốc độ là mục tiêu của bạn, hãy thử cả hai cách và thời gian kết quả.Vài tháng trước tôi đã làm việc với thói quen tích chập bitmap liên quan đến việc bước qua một mảng các số nguyên và chia mỗi phần tử cho 2. Tôi đã làm tất cả các cách để tối ưu hóa nó bao gồm cả thủ thuật cũ thay thế "x >> 1" cho "x / 2 ".

Khi tôi thực sự hẹn giờ cả hai cách tôi đã phát hiện ra điều ngạc nhiên là x / 2 nhanh hơn x >> 1

Điều này đã sử dụng Microsoft VS2008 C ++ với bật tối ưu hóa mặc định.

Về mặt hiệu suất. Hoạt động thay đổi của CPU nhanh hơn đáng kể so với phân chia mã op. Vì vậy, chia cho hai hoặc nhân với 2 vv tất cả đều được hưởng lợi từ các hoạt động thay đổi.

Như nhìn và cảm nhận. Là kỹ sư khi chúng ta trở nên gắn bó với mỹ phẩm mà ngay cả những quý cô xinh đẹp cũng không sử dụng! :)

X / Y là một toán tử dịch chuyển đúng ... và ">> "..nếu chúng ta muốn chia hai số nguyên, chúng ta có thể sử dụng toán tử cổ tức (/). toán tử shift được sử dụng để dịch chuyển các bit ..

x = x / 2; x / = 2; chúng ta có thể sử dụng như thế này ..

Trong khi x >> 1 nhanh hơn x / 2, việc sử dụng >> khi xử lý các giá trị âm sẽ phức tạp hơn một chút. Nó đòi hỏi một cái gì đó tương tự như sau:

// Extension Method
public static class Global {
    public static int ShiftDivBy2(this int x) {
        return (x < 0 ? x + 1 : x) >> 1;
    }
}