Cái nào nhanh hơn: while (1) hay while (2)?

Đây là một câu hỏi phỏng vấn được hỏi bởi một người quản lý cao cấp.

Cái nào nhanh hơn?

while(1) {
    // Some code
}

hoặc là

while(2) {
    //Some code
}

Tôi đã nói rằng cả hai đều có cùng tốc độ thực hiện, vì biểu thức bên trong whilecuối cùng sẽ đánh giá đến truehoặc false. Trong trường hợp này, cả hai đánh giá truevà không có hướng dẫn điều kiện bổ sung bên trong whileđiều kiện. Vì vậy, cả hai sẽ có cùng tốc độ thực hiện và tôi thích trong khi (1).

Nhưng người phỏng vấn tự tin nói: "Hãy kiểm tra những điều cơ bản của bạn. while(1)Nhanh hơn while(2)." (Anh ấy đã không kiểm tra sự tự tin của tôi)

Điều này có đúng không?

Xem thêm: "for (;;)" có nhanh hơn "while (TRUE)" không? Nếu không, tại sao mọi người sử dụng nó?

Cả hai vòng lặp là vô hạn, nhưng chúng ta có thể thấy cái nào cần nhiều hướng dẫn / tài nguyên hơn cho mỗi lần lặp.

Sử dụng gcc, tôi đã biên dịch hai chương trình sau để lắp ráp ở các mức độ tối ưu hóa khác nhau:

int main(void) {
    while(1) {}
    return 0;
}

int main(void) {
    while(2) {}
    return 0;
}

Ngay cả khi không có tối ưu hóa ( -O0), lắp ráp được tạo là giống hệt nhau cho cả hai chương trình . Do đó, không có sự khác biệt về tốc độ giữa hai vòng.

Để tham khảo, đây là hội đồng được tạo (sử dụng gcc main.c -S -masm=intelvới cờ tối ưu hóa):

Với -O0:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    push    rbp
    .seh_pushreg    rbp
    mov rbp, rsp
    .seh_setframe   rbp, 0
    sub rsp, 32
    .seh_stackalloc 32
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Với -O1:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Với -O2và -O3(cùng đầu ra):

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .section    .text.startup,"x"
    .p2align 4,,15
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Trong thực tế, lắp ráp được tạo cho vòng lặp là giống hệt nhau cho mọi cấp độ tối ưu hóa:

 .L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Các bit quan trọng là:

.L2:
    jmp .L2

Tôi không thể đọc lắp ráp rất tốt, nhưng đây rõ ràng là một vòng lặp vô điều kiện. Các jmphướng dẫn cách vô điều kiện reset chương trình trở lại .L2nhãn mà không cần so sánh một giá trị so với sự thật, và tất nhiên ngay lập tức làm như vậy một lần nữa cho đến khi chương trình được bằng cách nào đó đã kết thúc. Điều này tương ứng trực tiếp với mã C / C ++:

L2:
    goto L2;

Biên tập:

Thật thú vị, ngay cả khi không có tối ưu hóa , tất cả các vòng lặp sau đây đều tạo ra cùng một đầu ra (vô điều kiện jmp) trong lắp ráp:

while(42) {}

while(1==1) {}

while(2==2) {}

while(4<7) {}

while(3==3 && 4==4) {}

while(8-9 < 0) {}

while(4.3 * 3e4 >= 2 << 6) {}

while(-0.1 + 02) {}

Và thậm chí làm tôi ngạc nhiên:

#include<math.h>

while(sqrt(7)) {}

while(hypot(3,4)) {}

Mọi thứ trở nên thú vị hơn với các hàm do người dùng định nghĩa:

int x(void) {
    return 1;
}

while(x()) {}

#include<math.h>

double x(void) {
    return sqrt(7);
}

while(x()) {}

Tại -O0, hai ví dụ này thực sự gọi xvà thực hiện so sánh cho mỗi lần lặp.

Ví dụ đầu tiên (trả về 1):

.L4:
    call    x
    testl   %eax, %eax
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Ví dụ thứ hai (trở về sqrt(7)):

.L4:
    call    x
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jp  .L4
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Tuy nhiên, tại -O1và trên, cả hai đều tạo ra một hội đồng giống như các ví dụ trước (một điều kiện vô điều kiện jmptrở lại nhãn trước).

TL; DR

Theo GCC, các vòng lặp khác nhau được biên dịch để lắp ráp giống hệt nhau. Trình biên dịch đánh giá các giá trị không đổi và không bận tâm thực hiện bất kỳ so sánh thực tế nào.

Đạo đức của câu chuyện là:

• Tồn tại một lớp dịch giữa mã nguồn C ++ và các hướng dẫn CPU và lớp này có ý nghĩa quan trọng đối với hiệu năng.
• Do đó, hiệu suất không thể được đánh giá bằng cách chỉ nhìn vào mã nguồn.
• Trình biên dịch phải đủ thông minh để tối ưu hóa các trường hợp tầm thường như vậy. Các lập trình viên không nên lãng phí thời gian suy nghĩ về họ trong phần lớn các trường hợp.

Vâng, while(1)nhanh hơn nhiều so với while(2), cho một con người để đọc! Nếu tôi nhìn thấy while(1)trong một cơ sở mã lạ, tôi biết ngay tác giả dự định và nhãn cầu của tôi có thể tiếp tục dòng tiếp theo.

Nếu tôi thấy while(2), có lẽ tôi sẽ dừng các bài hát của mình và cố gắng tìm hiểu tại sao tác giả không viết while(1). Có phải ngón tay của tác giả trượt trên bàn phím? Các nhà bảo trì của cơ sở mã này sử dụng while(n)như một cơ chế bình luận tối nghĩa để làm cho các vòng lặp trông khác nhau? Đây có phải là một cách giải quyết thô thiển cho một cảnh báo giả trong một số công cụ phân tích tĩnh bị hỏng không? Hay đây là một đầu mối mà tôi đang đọc mã được tạo ra? Đây có phải là một lỗi xuất phát từ việc tìm và thay thế tất cả, hoặc hợp nhất xấu, hoặc tia vũ trụ không? Có lẽ dòng mã này được cho là sẽ làm một cái gì đó khác biệt đáng kể. Có lẽ nó được cho là để đọc while(w)hoặc while(x2). Tôi tốt hơn nên tìm tác giả trong lịch sử của tập tin và gửi cho họ email "WTF" ... và bây giờ tôi đã phá vỡ bối cảnh tinh thần của mình.while(2)while(1) sẽ mất một phần của giây!

Tôi đang phóng đại, nhưng chỉ một chút thôi. Mã dễ đọc là thực sự quan trọng. Và đó là điều đáng nói trong một cuộc phỏng vấn!

Các câu trả lời hiện có hiển thị mã được tạo bởi một trình biên dịch cụ thể cho một mục tiêu cụ thể với một bộ tùy chọn cụ thể không trả lời đầy đủ câu hỏi - trừ khi câu hỏi được hỏi trong ngữ cảnh cụ thể đó ("Sử dụng gcc 4.7.2 nhanh hơn cho x86_64 với các tùy chọn mặc định? ", ví dụ).

Theo như định nghĩa ngôn ngữ, trong máy trừu tượng sẽ while (1) đánh giá hằng số nguyên 1và while (2)đánh giá hằng số nguyên 2; trong cả hai trường hợp, kết quả được so sánh bằng nhau bằng không. Tiêu chuẩn ngôn ngữ hoàn toàn không nói gì về hiệu suất tương đối của hai cấu trúc.

Tôi có thể tưởng tượng rằng một trình biên dịch cực kỳ ngây thơ có thể tạo mã máy khác nhau cho hai biểu mẫu, ít nhất là khi được biên dịch mà không yêu cầu tối ưu hóa.

Mặt khác, trình biên dịch C hoàn toàn phải đánh giá một số biểu thức không đổi tại thời gian biên dịch, khi chúng xuất hiện trong bối cảnh yêu cầu biểu thức không đổi. Ví dụ: cái này:

int n = 4;
switch (n) {
    case 2+2: break;
    case 4:   break;
}

yêu cầu chẩn đoán; một trình biên dịch lười biếng không có tùy chọn trì hoãn việc đánh giá 2+2cho đến khi thời gian thực hiện. Vì trình biên dịch phải có khả năng đánh giá các biểu thức không đổi trong thời gian biên dịch, không có lý do chính đáng nào để nó không tận dụng khả năng đó ngay cả khi không cần thiết.

Tiêu chuẩn C ( N1570 6.8.5p4) nói rằng

Một câu lệnh lặp làm cho một câu lệnh được gọi là thân vòng lặp được thực thi lặp đi lặp lại cho đến khi biểu thức điều khiển so sánh bằng 0.

Vì vậy, các biểu thức hằng có liên quan là 1 == 0và 2 == 0, cả hai đều đánh giá giá inttrị 0. (Những so sánh này được ẩn trong ngữ nghĩa của whilevòng lặp; chúng không tồn tại như các biểu thức C thực tế.)

Một trình biên dịch ngây thơ có thể tạo mã khác nhau cho hai cấu trúc. Ví dụ, lần đầu tiên, nó có thể tạo ra một vòng lặp vô hạn vô điều kiện (coi 1như một trường hợp đặc biệt) và trong lần thứ hai, nó có thể tạo ra một so sánh thời gian chạy rõ ràng tương đương với 2 != 0. Nhưng tôi chưa bao giờ gặp phải một trình biên dịch C thực sự sẽ hoạt động theo cách đó và tôi thực sự nghi ngờ rằng trình biên dịch đó tồn tại.

Hầu hết các trình biên dịch (tôi muốn nói rằng tất cả các trình biên dịch chất lượng sản xuất) đều có các tùy chọn để yêu cầu tối ưu hóa bổ sung. Trong một tùy chọn như vậy, ít có khả năng bất kỳ trình biên dịch nào sẽ tạo mã khác nhau cho hai biểu mẫu.

Nếu trình biên dịch của bạn tạo mã khác nhau cho hai cấu trúc, trước tiên hãy kiểm tra xem các chuỗi mã khác nhau có thực sự có hiệu suất khác nhau không. Nếu có, hãy thử biên dịch lại với tùy chọn tối ưu hóa (nếu có). Nếu chúng vẫn khác nhau, hãy gửi báo cáo lỗi cho nhà cung cấp trình biên dịch. Đó không phải là (nhất thiết) một lỗi theo nghĩa là không tuân thủ tiêu chuẩn C, nhưng gần như chắc chắn đó là một vấn đề cần được sửa chữa.

Điểm mấu chốt: while (1)và while(2) gần như chắc chắn có hiệu suất tương tự. Chúng có chính xác cùng một ngữ nghĩa và không có lý do chính đáng nào cho bất kỳ trình biên dịch nào không tạo mã giống hệt nhau.

Và mặc dù nó hoàn toàn hợp pháp cho một trình biên dịch để tạo ra nhanh hơn mã cho while(1)hơn cho while(2), đó là bình đẳng pháp lý cho một trình biên dịch để tạo ra nhanh hơn mã cho while(1)hơn cho người khác xảy ra while(1)trong cùng một chương trình.

(Có một câu hỏi khác tiềm ẩn trong câu hỏi mà bạn đã hỏi: Làm thế nào để bạn đối phó với một người phỏng vấn khăng khăng về một điểm kỹ thuật không chính xác. Đó có thể là một câu hỏi hay cho trang web Workplace ).

Đợi tí. Người phỏng vấn, anh ta có giống anh chàng này không?

Thật tệ khi bản thân người phỏng vấn đã thất bại trong cuộc phỏng vấn này, điều gì sẽ xảy ra nếu các lập trình viên khác tại công ty này đã "vượt qua" bài kiểm tra này?

Không. Đánh giá các báo cáo 1 == 0và 2 == 0 phải nhanh như nhau. Chúng ta có thể tưởng tượng việc triển khai trình biên dịch kém trong đó cái này có thể nhanh hơn cái kia. Nhưng không có lý do chính đáng tại sao người này nên nhanh hơn người kia.

Ngay cả khi có một số trường hợp mơ hồ khi tuyên bố là đúng, các lập trình viên không nên được đánh giá dựa trên kiến ​​thức về những điều tối nghĩa (và trong trường hợp này là đáng sợ). Đừng lo lắng về cuộc phỏng vấn này, cách tốt nhất ở đây là bỏ đi.

Disclaimer: Đây KHÔNG phải là phim hoạt hình Dilbert gốc. Đây chỉ đơn thuần là một bản mashup .

Giải thích của bạn là chính xác. Đây dường như là một câu hỏi kiểm tra sự tự tin của bạn bên cạnh kiến ​​thức kỹ thuật.

Nhân tiện, nếu bạn trả lời

Cả hai đoạn mã đều nhanh như nhau, vì cả hai đều mất thời gian vô hạn để hoàn thành

người phỏng vấn sẽ nói

Nhưng while (1) có thể làm nhiều lần lặp lại mỗi giây; bạn có thể giải thích lý do tại sao? (điều này là vô nghĩa; kiểm tra lại sự tự tin của bạn)

Vì vậy, bằng cách trả lời như bạn đã làm, bạn đã tiết kiệm được một chút thời gian mà nếu không bạn sẽ lãng phí khi thảo luận về câu hỏi tồi tệ này.

Dưới đây là mã ví dụ được tạo bởi trình biên dịch trên hệ thống của tôi (MS Visual Studio 2012), với tối ưu hóa bị tắt:

yyy:
    xor eax, eax
    cmp eax, 1     (or 2, depending on your code)
    je xxx
    jmp yyy
xxx:
    ...

Với tối ưu hóa được bật:

xxx:
    jmp xxx

Vì vậy, mã được tạo ra là hoàn toàn giống nhau, ít nhất là với một trình biên dịch tối ưu hóa.

Giải thích có khả năng nhất cho câu hỏi là người phỏng vấn nghĩ rằng bộ xử lý kiểm tra từng bit của các số, từng cái một, cho đến khi nó đạt giá trị khác không:

1 = 00000001
2 = 00000010

Nếu "bằng không?" thuật toán bắt đầu từ phía bên phải của số và phải kiểm tra từng bit cho đến khi đạt đến một bit khác không, while(1) { }vòng lặp sẽ phải kiểm tra gấp đôi số bit trên mỗi lần lặp so với while(2) { }vòng lặp.

Điều này đòi hỏi một mô hình tinh thần rất sai về cách thức máy tính hoạt động, nhưng nó có logic bên trong riêng. Một cách để kiểm tra sẽ được hỏi nếu while(-1) { }hay while(3) { }sẽ là như nhau nhanh chóng, hoặc nếu while(32) { }sẽ thậm chí chậm hơn .

Tất nhiên tôi không biết ý định thực sự của người quản lý này, nhưng tôi đề xuất một quan điểm hoàn toàn khác: Khi thuê một thành viên mới vào một nhóm, thật hữu ích khi biết cách anh ấy phản ứng với các tình huống xung đột.

Họ đẩy bạn vào cuộc xung đột. Nếu điều này là đúng, họ thông minh và câu hỏi rất hay. Đối với một số ngành, như ngân hàng, việc đăng vấn đề của bạn lên Stack Overflow có thể là một lý do để từ chối.

Nhưng tất nhiên tôi không biết, tôi chỉ đề xuất một lựa chọn.

Tôi nghĩ rằng manh mối sẽ được tìm thấy trong "yêu cầu của người quản lý cấp cao". Người này rõ ràng đã ngừng lập trình khi anh ta trở thành người quản lý và sau đó anh ta / cô ta phải mất vài năm để trở thành người quản lý cấp cao. Không bao giờ mất hứng thú với lập trình, nhưng không bao giờ viết một dòng kể từ những ngày đó. Vì vậy, tài liệu tham khảo của ông không phải là "bất kỳ trình biên dịch tử tế nào ngoài kia" như một số câu trả lời đề cập, mà là "trình biên dịch mà người này đã làm việc với 20-30 năm trước".

Vào thời điểm đó, các lập trình viên đã dành một tỷ lệ đáng kể thời gian của họ để thử các phương pháp khác nhau để làm cho mã của họ nhanh hơn và hiệu quả hơn vì thời gian CPU của 'máy tính trung tâm' rất có giá trị. Như mọi người đã viết trình biên dịch. Tôi đoán rằng trình biên dịch một và duy nhất mà công ty của anh ta đã có sẵn tại thời điểm đó được tối ưu hóa trên cơ sở 'các câu lệnh thường gặp có thể được tối ưu hóa' và mất một chút phím tắt khi gặp một lúc (1) và đánh giá mọi thứ khác, bao gồm một thời gian (2). Có một kinh nghiệm như vậy có thể giải thích vị trí của anh ấy và sự tự tin của anh ấy trong đó.

Cách tiếp cận tốt nhất để giúp bạn được thuê có lẽ là một cách cho phép người quản lý cấp cao được mang đi và giảng cho bạn 2-3 phút về "những ngày tốt đẹp của lập trình" trước BẠN trơn tru dẫn anh ấy về phía đối tượng phỏng vấn tiếp theo. (Thời điểm tốt rất quan trọng ở đây - quá nhanh và bạn đang làm gián đoạn câu chuyện - quá chậm và bạn bị gắn mác là một người không đủ tập trung). Hãy nói với anh ấy vào cuối cuộc phỏng vấn rằng bạn sẽ rất thích tìm hiểu thêm về chủ đề này.

Bạn nên hỏi anh ấy làm thế nào anh ấy đi đến kết luận đó. Dưới bất kỳ trình biên dịch tử tế nào ngoài đó, hai trình biên dịch theo cùng một hướng dẫn asm. Vì vậy, anh ấy nên nói với bạn trình biên dịch là bắt đầu. Và ngay cả như vậy, bạn sẽ phải biết rất rõ về trình biên dịch và nền tảng để thậm chí đưa ra một phỏng đoán có lý thuyết. Và cuối cùng, nó không thực sự quan trọng trong thực tế, vì có các yếu tố bên ngoài khác như phân mảnh bộ nhớ hoặc tải hệ thống sẽ ảnh hưởng đến vòng lặp nhiều hơn chi tiết này.

Vì câu hỏi này, tôi nên thêm rằng tôi nhớ Doug Gwyn từ Ủy ban C viết rằng một số trình biên dịch C ban đầu không có trình tối ưu hóa sẽ tạo ra một bài kiểm tra lắp ráp cho while(1)(so sánh vớifor(;;) không có nó).

Tôi sẽ trả lời người phỏng vấn bằng cách đưa ra ghi chú lịch sử này và sau đó nói rằng ngay cả khi tôi sẽ rất ngạc nhiên bất kỳ trình biên dịch nào đã làm điều này, một trình biên dịch có thể có:

• không có trình tối ưu hóa, trình biên dịch sẽ tạo một bài kiểm tra cho cả hai while(1)vàwhile(2)
• với trình tối ưu hóa, trình biên dịch được hướng dẫn để tối ưu hóa (với bước nhảy vô điều kiện) tất cả while(1)vì chúng được coi là thành ngữ. Điều này sẽ để lại while(2)một bài kiểm tra và do đó làm cho sự khác biệt hiệu suất giữa hai.

Tất nhiên tôi sẽ thêm vào người phỏng vấn rằng không xem xét while(1)và while(2)cấu trúc tương tự là dấu hiệu của tối ưu hóa chất lượng thấp vì đây là các cấu trúc tương đương.

Một câu hỏi khác sẽ là xem bạn có đủ can đảm để nói với người quản lý của mình rằng anh ấy / cô ấy sai không! Và làm thế nào nhẹ nhàng bạn có thể giao tiếp nó.

Bản năng đầu tiên của tôi sẽ là tạo đầu ra lắp ráp để cho người quản lý thấy rằng bất kỳ trình biên dịch tử tế nào cũng sẽ chăm sóc nó và nếu nó không làm như vậy, bạn sẽ gửi bản vá tiếp theo cho nó :)

Để thấy rất nhiều người đi sâu vào vấn đề này, hãy chỉ ra chính xác lý do tại sao điều này rất có thể là một thử nghiệm để xem bạn muốn tối ưu hóa mọi thứ nhanh như thế nào .

Câu trả lời của tôi sẽ là; nó không quan trọng lắm, tôi tập trung vào vấn đề kinh doanh mà chúng tôi đang giải quyết. Rốt cuộc, đó là những gì tôi sẽ được trả tiền cho.

Hơn nữa, tôi sẽ chọn while(1) {}vì nó phổ biến hơn và các đồng đội khác sẽ không cần dành thời gian để tìm hiểu lý do tại sao một người nào đó lại đi với số lượng cao hơn 1.

Bây giờ đi viết một số mã. ;-)

Nếu bạn lo lắng về việc tối ưu hóa, bạn nên sử dụng

for (;;)

bởi vì điều đó không có bài kiểm tra (chế độ yếm thế)

Dường như với tôi đây là một trong những câu hỏi phỏng vấn hành vi được che đậy như một câu hỏi kỹ thuật. Một số công ty làm điều này - họ sẽ hỏi một câu hỏi kỹ thuật khá dễ dàng để bất kỳ lập trình viên có thẩm quyền nào trả lời, nhưng khi người được phỏng vấn trả lời đúng, người phỏng vấn sẽ nói với họ rằng họ đã sai.

Công ty muốn xem bạn sẽ phản ứng thế nào trong tình huống này. Bạn có ngồi im lặng và không thúc đẩy rằng câu trả lời của bạn là chính xác, do nghi ngờ bản thân hoặc sợ làm phiền người phỏng vấn? Hay bạn sẵn sàng thách thức một người có thẩm quyền mà bạn biết là sai? Họ muốn xem liệu bạn có sẵn sàng đứng lên cho niềm tin của mình không, và liệu bạn có thể làm điều đó một cách khéo léo và tôn trọng.

Tôi đã từng lập trình C và mã hội trở lại khi loại vô nghĩa này có thể đã tạo ra sự khác biệt. Khi nó đã làm cho một sự khác biệt, chúng tôi đã viết nó trong hội.

Nếu tôi được hỏi câu hỏi đó, tôi sẽ lặp lại câu nói nổi tiếng năm 1974 của Donald Knuth về tối ưu hóa sớm và đi bộ nếu người phỏng vấn không cười và tiếp tục.

Có thể người phỏng vấn đặt ra câu hỏi ngớ ngẩn như vậy một cách có chủ ý và muốn bạn kiếm được 3 điểm:

1. Lý luận cơ bản. Cả hai vòng lặp là vô hạn, thật khó để nói về hiệu suất.
2. Kiến thức về mức độ tối ưu hóa. Anh ấy muốn nghe từ bạn nếu bạn để trình biên dịch thực hiện bất kỳ tối ưu hóa nào cho bạn, nó sẽ tối ưu hóa điều kiện, đặc biệt là nếu khối không trống.
3. Kiến thức về kiến ​​trúc vi xử lý. Hầu hết các kiến ​​trúc đều có một lệnh CPU đặc biệt để so sánh với 0 (trong khi không nhất thiết phải nhanh hơn).

Đây là một vấn đề: Nếu bạn thực sự viết một chương trình và đo tốc độ của nó, tốc độ của cả hai vòng có thể khác nhau! Đối với một số so sánh hợp lý:

unsigned long i = 0;
while (1) { if (++i == 1000000000) break; }

unsigned long i = 0;
while (2) { if (++i == 1000000000) break; }

với một số mã được thêm vào để in thời gian, một số hiệu ứng ngẫu nhiên như cách vòng lặp được định vị trong một hoặc hai dòng bộ đệm có thể tạo ra sự khác biệt. Một vòng lặp có thể hoàn toàn nằm trong một dòng bộ đệm hoặc khi bắt đầu một dòng bộ đệm, hoặc nó có thể sắp xếp hai dòng bộ đệm. Và kết quả là, bất cứ điều gì người phỏng vấn tuyên bố là nhanh nhất thực sự có thể là nhanh nhất - bởi sự trùng hợp.

Trường hợp xấu nhất: Trình biên dịch tối ưu hóa không tìm ra vòng lặp làm gì, nhưng chỉ ra rằng các giá trị được tạo ra khi vòng lặp thứ hai được thực hiện giống như vòng lặp đầu tiên được tạo ra. Và tạo mã đầy đủ cho vòng lặp đầu tiên, nhưng không phải cho vòng thứ hai.

Cả hai đều bằng nhau - giống nhau.

Theo thông số kỹ thuật, mọi thứ không phải là 0 đều được coi là đúng, vì vậy ngay cả khi không có bất kỳ tối ưu hóa nào, và một trình biên dịch tốt sẽ không tạo ra bất kỳ mã nào trong khi (1) hoặc while (2). Trình biên dịch sẽ tạo ra một kiểm tra đơn giản cho != 0.

Đánh giá bằng lượng thời gian và công sức mọi người đã bỏ ra để kiểm tra, chứng minh và trả lời câu hỏi rất thẳng này Id nói rằng cả hai đều được thực hiện rất chậm bằng cách đặt câu hỏi.

Và vì vậy để dành nhiều thời gian hơn cho nó ...

"trong khi (2)" là vô lý, bởi vì,

"while (1)" và "while (true)" trong lịch sử được sử dụng để tạo một vòng lặp vô hạn dự kiến ​​"phá vỡ" sẽ được gọi ở một giai đoạn nào đó bên trong vòng lặp dựa trên một điều kiện chắc chắn sẽ xảy ra.

"1" chỉ đơn giản là ở đó để luôn luôn đánh giá là đúng và do đó, để nói "while (2)" cũng ngớ ngẩn như nói "while (1 + 1 == 2)" cũng sẽ đánh giá là đúng.

Và nếu bạn muốn hoàn toàn ngớ ngẩn, chỉ cần sử dụng: -

while (1 + 5 - 2 - (1 * 3) == 0.5 - 4 + ((9 * 2) / 4)) {
    if (succeed())
        break;
}

Tôi muốn nghĩ rằng lập trình viên của bạn đã tạo ra một lỗi đánh máy không ảnh hưởng đến việc chạy mã, nhưng nếu anh ta cố tình sử dụng "2" để trở nên kỳ lạ thì hãy sa thải anh ta trước khi anh ta đặt mã lạ vào mã của bạn. đọc và làm việc với.

Điều đó phụ thuộc vào trình biên dịch.

Nếu nó tối ưu hóa mã, hoặc nếu nó đánh giá 1 và 2 thành đúng với cùng một số lệnh cho một tập lệnh cụ thể, tốc độ thực thi sẽ như nhau.

Trong trường hợp thực tế, nó sẽ luôn nhanh như nhau, nhưng có thể tưởng tượng một trình biên dịch cụ thể và một hệ thống cụ thể khi điều này sẽ được đánh giá khác nhau.

Ý tôi là: đây không thực sự là một câu hỏi liên quan đến ngôn ngữ (C).

Vì mọi người đang tìm cách trả lời câu hỏi này muốn vòng lặp nhanh nhất, nên tôi đã trả lời rằng cả hai đều được biên dịch như nhau thành cùng một mã lắp ráp, như đã nêu trong các câu trả lời khác. Tuy nhiên, bạn có thể đề xuất với người phỏng vấn bằng cách sử dụng 'unrolling'; a do {} vòng lặp while thay vì vòng lặp while.

Thận trọng: Bạn cần đảm bảo rằng vòng lặp ít nhất sẽ luôn chạy một lần .

Các vòng lặp nên có một điều kiện phá vỡ bên trong.

Ngoài ra, đối với loại vòng lặp đó, cá nhân tôi thích sử dụng do {} while (42) vì bất kỳ số nguyên nào, ngoại trừ 0, sẽ thực hiện công việc.

Câu trả lời rõ ràng là: như đã đăng, cả hai đoạn sẽ chạy một vòng lặp vô hạn bận rộn như nhau, làm cho chương trình chậm vô hạn .

Mặc dù việc xác định lại các từ khóa C là các macro về mặt kỹ thuật sẽ có hành vi không xác định, nhưng đó là cách duy nhất tôi có thể nghĩ để tạo ra đoạn mã nhanh chóng: bạn có thể thêm dòng này lên trên 2 đoạn:

#define while(x) sleep(x);

nó thực sự sẽ làm while(1)nhanh gấp đôi (hoặc một nửa chậm) while(2).

Lý do duy nhất tôi có thể nghĩ tại sao while(2)sẽ chậm hơn là:

1. Mã tối ưu hóa vòng lặp để

   cmp eax, 2

2. Khi phép trừ xảy ra, về cơ bản bạn đang trừ

   a. 00000000 - 00000010 cmp eax, 2

   thay vì

   b. 00000000 - 00000001 cmp eax, 1

cmpchỉ đặt cờ và không đặt kết quả. Vì vậy, trên các bit có ý nghĩa ít nhất chúng ta biết nếu chúng ta cần vay hay không với b . Trong khi đó với một bạn phải thực hiện hai phép trừ trước khi bạn vay tiền.