Hangisi daha hızlı: (1) veya iken (2)?

Bu üst düzey bir yönetici tarafından sorulan bir röportaj sorusuydu.

Hangisi daha hızlı?

while(1) {
    // Some code
}

veya

while(2) {
    //Some code
}

I sentezleme içi gibi, her ikisi de aynı uygulama hızına sahip söz konusu whilenihayet değerlendirmelidir trueveya false. Bu durumda, hem değerlendirme yapar hem de truekoşul içinde ekstra koşullu talimat yoktur while. Yani, her ikisi de aynı hızda olacak ve ben (1) 'i tercih ederim.

Ancak görüşmeci güvenle dedi: "Temel bilgilerinizi kontrol edin. while(1)Daha hızlıdır while(2)." (Güvenimi test etmiyordu)

Bu doğru mu?

Ayrıca bkz: "için (;;)", (TRUE) "dan" daha hızlı mı? Değilse, insanlar neden kullanıyor?

Her iki döngü de sonsuzdur, ancak hangisinin yineleme başına daha fazla talimat / kaynak aldığını görebiliriz.

Gcc'yi kullanarak, aşağıdaki iki programı çeşitli optimizasyon düzeylerinde birleştirmek için derledim:

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

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

Hiçbir optimizasyon ( -O0) yapılmasa bile , oluşturulan montaj her iki program için de aynıydı . Bu nedenle, iki döngü arasında hız farkı yoktur.

Başvuru için, burada oluşturulan derleme ( gcc main.c -S -masm=intelbir optimizasyon bayrağıyla kullanarak ):

İle -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"

İle -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"

İle -O2ve -O3(aynı çıkış):

    .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"

Aslında, döngü için oluşturulan montaj her optimizasyon seviyesi için aynıdır:

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

Önemli bitler:

.L2:
    jmp .L2

Montajı çok iyi okuyamıyorum, ama bu açıkça koşulsuz bir döngü. jmpTalimat koşulsuz program geri sıfırlar .L2bile doğru karşı bir değeri karşılaştırarak olmadan etiket ve program nasılsa sona kadar tabii hemen bu nedenle yeniden yapar. Bu doğrudan C / C ++ koduna karşılık gelir:

L2:
    goto L2;

Düzenle:

İlginçtir ki, hiçbir optimizasyon olmasa bile , aşağıdaki döngülerin hepsi jmpmontajda aynı çıktıyı (koşulsuz ) üretti :

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) {}

Ve hayretlerime bile:

#include<math.h>

while(sqrt(7)) {}

while(hypot(3,4)) {}

Kullanıcı tanımlı işlevlerle işler biraz daha ilginçleşir:

int x(void) {
    return 1;
}

while(x()) {}

#include<math.h>

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

while(x()) {}

At -O0, bu iki örnek aslında xher yineleme için bir karşılaştırma çağırır ve gerçekleştirir.

İlk örnek (1 döndürme):

.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"

İkinci örnek (geri dönüyor 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"

Bununla birlikte, -O1her ikisinde de ve her ikisi de önceki örneklerle aynı montajı üretir ( jmpönceki etikete koşulsuz bir geri dönüş).

TL; DR

GCC altında, farklı döngüler özdeş montaj için derlenir. Derleyici sabit değerleri değerlendirir ve gerçek bir karşılaştırma yapmakla uğraşmaz.

Hikayenin ahlakı:

• C ++ kaynak kodu ve CPU talimatları arasında bir çeviri katmanı vardır ve bu katmanın performans için önemli etkileri vardır.
• Bu nedenle, performans yalnızca kaynak koduna bakarak değerlendirilemez.
• Derleyici bu tür önemsiz durumları optimize edecek kadar akıllı olmalıdır . Programcılar olmamalıdır vakaların büyük çoğunluğunda onlar hakkında onların zaman düşünme israf.

Evet, while(1)çok daha hızlı daha while(2), bir insan okumak için! while(1)Bilmediğiniz bir kod tabanında görürsem , yazarın neyi amaçladığını hemen bilirim ve göz kürelerim bir sonraki satıra devam edebilir.

Eğer görürsem while(2), muhtemelen izlerimi durduracağım ve yazarın neden yazmadığını anlamaya çalışacağım while(1). Yazarın parmağı klavyede kaydı mı? Bu kod tabanının koruyucular while(n)döngülerin farklı görünmesini sağlamak için belirsiz bir yorumlama mekanizması olarak mı kullanılıyor? Bazı kırık statik analiz aracında sahte bir uyarı için kaba bir çözüm mü? Yoksa bu oluşturulan kodu okuduğum bir ipucu mu? Kötü bir şekilde tavsiye edilen bul ve değiştir hepsini ya da kötü bir birleşme ya da kozmik bir ışından kaynaklanan bir hata mıdır? Belki de bu kod satırının çok farklı bir şey yapması gerekiyordu. Belki de okuması gerekiyordu while(w)ya while(x2). Dosya geçmişinde yazarı bulsam iyi olur ve onlara bir "WTF" e-postası gönderirim ... ve şimdi zihinsel bağlamımı kırdım.while(2)while(1) saniyenin bir kısmını alır!

Abartıyorum, ama sadece biraz. Kod okunabilirliği gerçekten önemlidir. Ve bu bir röportajda bahsetmeye değer!

Belirli bir derleyici tarafından belirli bir seçenek kümesi ile belirli bir hedef için oluşturulan kodu gösteren mevcut yanıtlar soruyu tam olarak yanıtlamaz - bu belirli bağlamda soru sorulmadıkça ("x86_64 için gcc 4.7.2 kullanarak daha hızlıdır varsayılan seçeneklerle? "

Dil tanımına gelince, soyut makinede while (1) tamsayı sabitini 1ve while (2)tamsayı sabitini değerlendirir 2; her iki durumda da sonuç sıfıra eşitlik için karşılaştırılır. Dil standardı, iki yapının göreceli performansı hakkında kesinlikle hiçbir şey söylemez.

Son derece saf bir derleyicinin, en azından optimizasyon talep etmeden derlendiğinde, iki form için farklı makine kodu üretebileceğini hayal edebiliyorum.

Öte yandan, C derleyicileri, sabit bir ifade gerektiren bağlamlarda göründüklerinde, derleme zamanında bazı sabit ifadeleri mutlaka değerlendirmelidir . Örneğin, bu:

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

bir teşhis gerektirir; tembel bir derleyicinin değerlendirmesini 2+2yürütme süresine kadar erteleme seçeneği yoktur . Bir derleyicinin derleme zamanında sabit ifadeleri değerlendirme yeteneğine sahip olması gerektiğinden, gerekli olmadığında bile bu özellikten yararlanmaması için iyi bir neden yoktur.

C standardı ( N1570 6.8.5p4) diyor ki

Bir yineleme ifadesi, döngü ifadesi adı verilen bir ifadenin , kontrol ifadesi 0'a eşit olana kadar tekrar tekrar yürütülmesine neden olur .

Dolayısıyla, ilgili sabit ifadeler 1 == 0ve 2 == 0her ikisi de intdeğeri değerlendirir 0. (Bu karşılaştırma, whiledöngünün anlambiliminde örtüktür; gerçek C ifadeleri olarak mevcut değildir.)

Bir perversely naif derleyici olabilir iki yapı için farklı bir kod üretir. Örneğin, birincisi için koşulsuz bir sonsuz döngü oluşturabilir ( 1özel bir durum gibi davranır) ve ikincisi için açık bir çalışma zamanı karşılaştırması oluşturabilir 2 != 0. Ama bu şekilde davranacak bir C derleyicisiyle hiç karşılaşmadım ve böyle bir derleyicinin varlığından ciddi olarak şüpheliyim.

Çoğu derleyici (tüm üretim kalitesi derleyicilerinin söylemeye hazırım) ek optimizasyon isteme seçenekleri var. Böyle bir seçenek altında, herhangi bir derleyicinin iki form için farklı kod üretmesi daha az olasıdır.

Derleyiciniz iki yapı için farklı kod üretirse, öncelikle farklı kod dizilerinin gerçekten farklı performansa sahip olup olmadığını kontrol edin. Varsa, bir optimizasyon seçeneğiyle tekrar derlemeyi deneyin (varsa). Hala farklıysa, derleyici satıcısına bir hata raporu gönderin. C standardına uymama anlamında (mutlaka) bir hata değildir, ancak neredeyse kesinlikle düzeltilmesi gereken bir sorundur.

Alt satır: while (1)ve while(2) neredeyse kesinlikle aynı performansa sahip. Tam olarak aynı semantiğe sahiptirler ve herhangi bir derleyicinin aynı kodu üretmemesinin iyi bir nedeni yoktur.

Ve bir derleyicinin için while(1)olduğundan daha hızlı kod üretmesi tamamen yasal olsa da, bir derleyicinin aynı programdaki başka bir oluşumdan daha while(2)hızlı kod üretmesi de aynı derecede yasaldır .while(1)while(1)

(Sorduğunuz soruda başka bir soru daha var: Yanlış bir teknik noktada ısrar eden bir görüşmeci ile nasıl başa çıkıyorsunuz. Bu muhtemelen İşyeri sitesi için iyi bir soru olacaktır ).

Bir dakika bekle. Görüşmeci, bu adama benziyor muydu?

Görüşmecinin bu röportajda başarısız olması yeterince kötü , ya bu şirketteki diğer programcılar bu testi "geçtiyse"?

Hayır. İfadelerin değerlendirilmesi 1 == 0ve aynı derecede hızlı 2 == 0 olmalıdır . Biz hayal biri diğerinden daha hızlı olabilir zayıf derleyici uygulamaları. Ancak birinin diğerinden daha hızlı olması için iyi bir neden yoktur .

İddiaların doğru olacağı bazı belirsiz durumlar olsa bile, programcılar belirsiz (ve bu durumda ürpertici) bilgilerden hareketle değerlendirilmemelidir. Bu röportaj için endişelenmeyin, buradaki en iyi adım uzaklaşmaktır.

Feragatname: Bu orijinal bir Dilbert karikatürü DEĞİLDİR. Bu sadece bir karışım .

Açıklamanız doğru. Bu, teknik bilgiye ek olarak özgüveninizi test eden bir soru gibi görünüyor.

Bu arada, eğer cevapladıysan

Her iki kod parçası da eşit derecede hızlıdır, çünkü her ikisinin de tamamlanması sonsuz zaman alır

görüşmeci söylerdi

Ancak while (1)saniyede daha fazla yineleme yapabilir; bana nedenini açıklayabilir misin? (bu saçmalık; güveninizi tekrar test etmek)

Yani sizin gibi cevap vererek, aksi takdirde bu kötü soruyu tartışmak için harcayacağınız zamandan tasarruf ettiniz.

İşte benim sistemimde derleyici tarafından oluşturulan örnek kod (MS Visual Studio 2012), optimizasyonlar kapalı:

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

Optimizasyonlar açıkken:

xxx:
    jmp xxx

Böylece üretilen kod, en azından bir optimizasyon derleyicisiyle tamamen aynıdır.

Soru için en olası açıklama, görüşmecinin, işlemcinin sıfır olmayan bir değere ulaşana kadar sayıların ayrı ayrı bitlerini tek tek kontrol ettiğini düşünmesidir:

1 = 00000001
2 = 00000010

"Sıfır mı?" Algoritma, sayının sağ tarafından başlar ve sıfır olmayan bir bite ulaşana kadar her biti kontrol etmek zorundadır, while(1) { }döngü yineleme başına while(2) { }döngüden iki kat daha fazla biti kontrol etmelidir.

Bu, bilgisayarların nasıl çalıştığına dair çok yanlış bir zihinsel model gerektirir, ancak kendi iç mantığı vardır. Çek bir yolu sormak olurdu while(-1) { }ya while(3) { }eğer eşit hızlı olacaktır veya while(32) { }olacağını bile yavaş .

Tabii ki bu menajerin gerçek niyetlerini bilmiyorum, ama tamamen farklı bir görüş öneriyorum: Bir takıma yeni bir üye alırken, çatışma durumlarına nasıl tepki verdiğini bilmek faydalıdır.

Sizi çatışmaya sürüklediler. Eğer bu doğruysa, zekiler ve soru iyiydi. Bankacılık gibi bazı endüstriler için sorununuzu Stack Overflow'a göndermek reddetme için bir neden olabilir.

Ama elbette bilmiyorum, sadece bir seçenek öneriyorum.

Bence ipucu "üst düzey bir yönetici tarafından sorulan" bölümünde bulunacak. Bu kişi yönetici olduğu zaman programlamayı durdurdu ve üst düzey yönetici olması birkaç yılını aldı. Programlamaya olan ilginizi hiçbir zaman kaybetmedim, ama o günden beri hiç bir satır yazmadı. Bu yüzden referansı, bazı cevapların belirttiği gibi "orada iyi bir derleyici" değil, "bu kişinin 20-30 yıl önce çalıştığı derleyici" dir.

O zamanlar, programcılar zamanlarının önemli bir yüzdesini kodlarını daha hızlı ve daha verimli hale getirmek için çeşitli yöntemleri denemek için harcadılar çünkü 'merkezi minibilgisayar'ın CPU zamanı çok değerli. İnsanlar derleyiciler yazıyor. Şirketinin o sırada kullanıma sunulan tek ve tek derleyicisinin 'optimize edilebilen sık karşılaşılan ifadeler' temelinde optimize edildiğini ve bir süre karşılaştığında bir kısayol aldığını tahmin ediyorum (1) ve her şeyi değerlendirdi bir süre dahil olmak üzere (2). Böyle bir deneyime sahip olmak, konumunu ve ona olan güvenini açıklayabilir.

Sizi işe almak için en iyi yaklaşım muhtemelen üst düzey yöneticinin taşınmasını ve sizden önce "programlama eski güzel günlerinde" 2-3 dakika ders vermek sağlayan bir yaklaşımdır sonraki görüşme konusuna sorunsuz bir şekilde yönlendirmeden sağlayan yöntemdir. (Burada iyi zamanlama önemlidir - çok hızlı ve hikayeyi kesiyorsunuz - çok yavaş ve yetersiz odaklanmış biri olarak etiketlenmişsiniz). Röportajın sonunda bu konu hakkında daha fazla bilgi edinmek isteyeceğinizi söyleyin.

Ona bu sonuca nasıl ulaştığını sormalıydın. Orada iyi bir derleyici altında, iki aynı asm talimatları derlemek. Yani, derleyiciye de yola çıkmasını söylemeliydi. Ve buna rağmen, teorik eğitimli bir tahmin yapmak için derleyiciyi ve platformu çok iyi bilmeniz gerekir. Ve sonunda, pratikte önemli değil, çünkü döngüyü bu ayrıntıdan daha fazla etkileyecek bellek parçalanması veya sistem yükü gibi başka dış faktörler var.

Bu soru uğruna, C Komitesinden Doug Gwyn'i optimize edici geçişi olmayan bazı erken C derleyicilerinin montaj için bir test oluşturacağını yazdığını hatırlamalıyım while(1)(buna kıyasla for(;;)).

Bu tarihsel notu vererek görüşmeciye cevap verirdim ve daha sonra herhangi bir derleyicinin bunu yapmasına şaşırmış olsam bile, bir derleyicinin şunları yapabileceğini söyleyebilirim:

• optimizer geçmek olmadan derleyici hem bir test oluşturmak while(1)vewhile(2)
• optimizer pass ile derleyiciye tümünün (koşulsuz atlama ile) while(1)deyimsel olduğu düşünülür. Bu while(2)bir test ile bırakılır ve bu nedenle ikisi arasında bir performans farkı yaratır.

Ben tabii düşünmediğini o görüşmeci eklersiniz while(1)ve while(2)bu eşdeğer yapılar gibi aynı yapı, düşük kaliteli optimizasyonu bir işaretidir.

Böyle bir soru üzerine başka bir şey, yöneticinize yanlış olduğunu söylemek için cesaretin olup olmadığını görmek olacaktır! Ve ne kadar yumuşak bir şekilde iletişim kurabileceğiniz.

İlk içgüdüm, yöneticiye iyi bir derleyicinin ilgilenmesi gerektiğini göstermek için montaj çıktısı oluşturmak olurdu ve eğer bunu yapmazsa, bunun için bir sonraki yamayı göndereceksiniz :)

Bu kadar çok insanın bu sorunu araştırdığını görmek için bunun ne kadar hızlı bir şekilde mikro optimizasyon yapmak istediğinizi görmek için neden bir test olabileceğini tam olarak gösterir. şeyleri .

Cevabım; o kadar önemli değil, çözdüğümüz iş sorununa odaklanmayı tercih ediyorum. Sonuçta, bunun için bana ödeme yapılacak.

Dahası, while(1) {} çünkü daha yaygın ve diğer takım arkadaşlarının birisinin neden 1'den daha yüksek bir sayıya gideceğini anlamak için zaman harcamaları gerekmeyecekti.

Şimdi git ve biraz kod yaz. ;-)

Optimizasyon konusunda endişeleniyorsanız,

for (;;)

çünkü bunun hiç testi yok. (alaycı mod)

Bana öyle geliyor ki, bu teknik bir soru olarak maskelenen davranışsal röportaj sorularından biri. Bazı şirketler bunu yapar - herhangi bir yetkili programcının cevaplaması oldukça kolay olan teknik bir soru soracaklar, ancak görüşmeci doğru cevabı verdiğinde, görüşmeci onlara yanlış olduklarını söyleyecektir.

Şirket bu durumda nasıl tepki vereceğinizi görmek istiyor. Sessizce oturup sessizce mi oturuyorsunuz ya da kendinizden şüphe duyuyorsanız ya da görüşmeciyi üzme korkusu nedeniyle cevabınızın doğru olduğunu zorlamıyor musunuz? Yoksa yanıldığını bildiğiniz bir otoriteye meydan okumaya istekli misiniz? Mahkumiyetlerinizi desteklemeye istekli olup olmadığınızı ve bunu dokunsal ve saygılı bir şekilde yapıp yapamayacağınızı görmek istiyorlar.

Bu saçmalık fark yarattığında C ve Assembly kodunu tekrar programlardım. Bir fark yarattığında bunu Mecliste yazdık.

Bu soru bana sorulursa, Donald Knuth'un 1974'teki ünlü optimizasyonunu erken optimizasyon hakkında tekrar ederdim ve görüşmeci gülmez ve devam etmezse yürürüm.

Belki görüşmeci böylesine aptalca bir soru sordu ve 3 puan vermenizi istedi:

1. Temel akıl yürütme.Her iki döngü de sonsuzdur, performans hakkında konuşmak zordur.
2. Optimizasyon seviyeleri hakkında bilgi.Derleyicinin sizin için herhangi bir optimizasyon yapmasına izin verirseniz, özellikle blok boş değilse durumu optimize eder.
3. Mikroişlemci mimarisi hakkında bilgi. Çoğu mimarinin 0 ile karşılaştırmak için özel bir CPU talimatı vardır (her zaman daha hızlı olmasa da).

Sorun şu: Eğer gerçekten bir program yazıp hızını ölçerseniz, her iki devrenin hızı da farklı olabilir! Makul bir karşılaştırma için:

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

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

zamanı yazdıran bazı kodlar eklendiğinde, döngünün bir veya iki önbellek satırına nasıl yerleştirildiği gibi bazı rastgele efektler fark yaratabilir. Bir döngü saf bir şekilde tamamen bir önbellek satırında veya bir önbellek satırının başında olabilir veya iki önbellek satırının üstünde olabilir. Sonuç olarak, görüşmecinin en hızlı iddia ettiği şey aslında tesadüfen en hızlı olabilir.

En kötü durum senaryosu: Optimize edici bir derleyici, döngünün ne yaptığını anlamaz, ancak ikinci döngü yürütüldüğünde üretilen değerlerin birincisi tarafından üretilenlerle aynı olduğunu anlar. Ve ilk döngü için tam kod üretin, ancak ikinci döngü için değil.

İkisi de eşit - aynı.

Spesifikasyonlara göre, 0 olmayan bir şey doğru olarak kabul edilir, bu yüzden herhangi bir optimizasyon olmadan bile ve iyi bir derleyici while (1) veya while (2) için herhangi bir kod üretmez. Derleyici basit bir kontrol oluşturur != 0.

İnsanların bu çok basit soruyu test etmek, kanıtlamak ve cevaplamak için harcadıkları zaman ve çaba miktarına bakarak, her ikisinin de soruyu sorarak çok yavaş yapıldığını söylüyorum.

Ve böylece daha fazla zaman geçirmek için ...

"while (2)" çok saçma, çünkü,

"while (1)" ve "while (true)", tarihsel olarak, kesinlikle gerçekleşecek bir koşula bağlı olarak, döngü içinde bir aşamada "break" denilmesini bekleyen sonsuz bir döngü oluşturmak için kullanılır.

"1" her zaman doğruyu değerlendirmek için oradadır ve bu nedenle "while (2)" demek, doğru olarak değerlendirilecek "while (1 + 1 == 2)" demek kadar saçmadır.

Ve tamamen aptal olmak istiyorsanız sadece kullanın: -

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

Kodlayıcınızın kodun çalışmasını etkilemeyen bir yazım hatası yaptığını düşünmek istiyorum, ama kasıtlı olarak "2" yi sadece garip olmak için kullandıysa, kodunuzu kullanarak garip sh! T'yi zorlaştırmadan önce onu çuvalla okuyun ve çalışın.

Bu derleyiciye bağlıdır.

Kodu optimize ederse veya belirli bir komut seti için aynı sayıda talimatla 1 ve 2'yi true olarak değerlendirirse, yürütme hızı aynı olacaktır.

Gerçek durumlarda her zaman eşit derecede hızlı olacaktır, ancak farklı değerlendirildiğinde belirli bir derleyiciyi ve belirli bir sistemi hayal etmek mümkün olacaktır.

Demek istediğim: bu gerçekten dil (C) ile ilgili bir soru değil.

Bu soruyu cevaplamak isteyen insanlar en hızlı döngüyü istediklerinden, diğer cevaplarda belirtildiği gibi, her ikisinin de aynı derleme koduna eşit olarak derlendiğini yanıtlardım. Bununla birlikte, görüşmeciye 'döngü çözme' seçeneğini önerebilirsiniz ; a yerine {} while döngüsü yerine while döngüsü.

Dikkatli: Döngünün en azından her zaman bir kez çalışacağından emin olmanız gerekir .

İlmeğin içinde bir kırılma durumu olmalıdır.

Ayrıca bu tür bir döngü için kişisel olarak do {} kullanırken (42) 0 hariç herhangi bir tamsayı işi yapacağını tercih ederim.

Açık cevap: yayınlandığı gibi, her iki parça da eşit derecede meşgul sonsuz bir döngü çalıştıracak ve bu da programı sonsuz derecede yavaşlatacaktır .

C anahtar kelimelerini makrolar olarak yeniden tanımlamak teknik olarak tanımlanmamış davranışa sahip olsa da, kod parçacıklarından birini hızlı yapmanın tek yolu budur: Bu satırı 2 parçanın üstüne ekleyebilirsiniz:

#define while(x) sleep(x);

gerçekten while(1)iki kat daha hızlı (veya yarı yavaş) yapar while(2).

Neden while(2)daha yavaş olacağını düşünebilmemin tek nedeni :

1. Kod, döngüyü

   cmp eax, 2

2. Çıkarma gerçekleştiğinde esasen

   a. 00000000 - 00000010 cmp eax, 2

   onun yerine

   b. 00000000 - 00000001 cmp eax, 1

cmpyalnızca bayrakları ayarlar ve bir sonuç belirlemez. Yani en az önemli bitlerde b ile ödünç almamız gerekip gerekmediğini biliyoruz . İle Halbuki bir sen bir ödünç almadan önce iki çıkarmalar gerçekleştirmek zorunda.