Neden montajda program yapıyorsun? [kapalı]

Dışarıdaki tüm düşük seviyeli hackerlara bir sorum var. Bu cümleyle bir blogda karşılaştım. Kaynağın gerçekten önemli olduğunu sanmıyorum (gerçekten umursuyorsan bu Haack) çünkü ortak bir ifade gibi görünüyor.

Örneğin, birçok modern 3-D Oyunun yüksek performanslı çekirdek motoru C ++ ve Assembly'de yazılmıştır.

Derleme gittiği sürece - derleyicide yazılan koddur çünkü bir derleyicinin fazladan talimatlar vermesini veya aşırı bayt kullanmasını istemezsiniz veya C ile ifade edemeyeceğiniz (veya olmadan ifade edemeyeceğiniz daha iyi algoritmalar mı kullanıyorsunuz? derleyici onları karıştırıyor)?

Düşük seviyeli şeyleri anlamanın önemli olduğunu tamamen anlıyorum. Siz onu anladıktan sonra, montajda programın nedenini anlamak istiyorum .

Sanırım bu ifadeyi yanlış yorumluyorsunuz:

Örneğin, birçok modern 3-D Oyunun yüksek performanslı çekirdek motoru C ++ ve Assembly'de yazılmıştır.

Oyunlar (ve bugünlerde çoğu program), "C ++ ile yazıldıkları" gibi "derlemede yazılmıyor". Bu blog, oyunun önemli bir kısmının montajda tasarlandığını veya bir programcı ekibinin oturup ana dili olarak montajda geliştiğini söylemiyor.

Bunun gerçekten anlamı, geliştiricilerin önce oyunu yazması ve C ++ ile çalıştırmasıdır. Ardından profilin profilini çıkarırlar, darboğazların ne olduğunu anlarlar ve eğer zahmete değerse bunları montajda optimize ederler. Ya da zaten deneyimli iseler, hangi parçaların darboğaz olacağını bilirler ve inşa ettikleri diğer oyunların etrafında oturan optimize edilmiş parçalar vardır.

Nokta her zaman olduğu gibi montaj içinde programlama aynıdır: hız . Assembler'da çok fazla kod yazmak saçma olurdu , ancak derleyicinin farkında olmadığı bazı optimizasyonlar var ve yeterince küçük bir kod penceresi için bir insan daha iyisini yapacaktır.

Örneğin, kayan nokta için, derleyiciler oldukça muhafazakar olma eğilimindedir ve mimarinizin daha gelişmiş özelliklerinden bazılarının farkında olmayabilirler. Bir hatayı kabul etmeye istekliysen, genellikle derleyiciden daha iyisini yapabilirsin ve üzerinde çok zaman harcandığını fark edersen, montajda bu küçük kodu yazmaya değer.

İşte daha alakalı bazı örnekler:

Oyunlardan Örnekler

• Intel’den SSE intrinsics kullanarak bir oyun motorunu optimize etme hakkındaki makale . Son kod içsel bilgileri kullanır (satır içi assembler değil), bu yüzden saf montaj miktarı çok azdır. Ancak neyin optimize edileceğini tam olarak bulmak için derleyicinin montajcı çıktısına bakarlar.

• Quake'in hızlı ters karekökü . Yine, rutinin içinde assembler yoktur, ancak bu tür bir optimizasyonu yapmak için mimari hakkında bir şeyler bilmeniz gerekir. Yazarlar, hangi işlemlerin hızlı (çarpma, kaydırma) ve hangilerinin yavaş (bölme, sqrt) olduğunu bilirler. Bu nedenle, yavaş işlemlerden tamamen kaçınan çok zor bir karekök uygulaması ile ortaya çıkıyorlar.

Yüksek Performanslı Bilgi İşlem

• Oyun alanının dışında, bilimsel hesaplamayla uğraşan insanlar, en yeni donanımlarda hızlı bir şekilde çalışmalarını sağlamak için sık sık bir şeyleri optimize ederler. Bunu fiziği aldatamayacağınız oyunlar olarak düşünün.

  Bunun harika bir yeni örneği, Kafes Kuantum Kromodinamiğidir (Kafes QCD) . Bu makale , problemin, IBM Blue Gene / L üzerindeki PowerPC 440'lar için yoğun bir şekilde optimize edilen çok küçük bir hesaplama çekirdeğine nasıl indirgendiğini açıklamaktadır . Her 440'ın iki FPU'su vardır ve derleyicilerin istismar etmesi zor olan bazı özel üçlü işlemleri desteklerler. Bu optimizasyonlar olmasaydı, Lattice QCD çok daha yavaş çalışırdı, bu da probleminiz pahalı makinelerde milyonlarca CPU saati gerektirdiğinde maliyetlidir.

  Bunun neden önemli olduğunu merak ediyorsanız , bu çalışmadan çıkan Science'daki makaleye göz atın . Kafes QCD kullanarak, bu adamlar bir protonun kütlesini ilk prensiplerden hesapladılar ve geçen yıl kütlenin% 90'ının güçlü kuvvet bağlama enerjisinden ve geri kalanının kuarklardan geldiğini gösterdiler. Bu E = mc ² eylemde. İşte bir özet .

Yukarıdakilerin hepsi için, uygulamalar vardır değil tasarlanmış veya montaj% 100 yazılı - Yakın bile değil. Ancak insanlar gerçekten hıza ihtiyaç duyduklarında, belirli donanımlar üzerinde uçmak için kodlarının temel parçalarını yazmaya odaklanırlar.

Yıllardır montaj dilinde kodlamadım, ancak sıkça gördüğüm birkaç nedeni verebilirim:

• Tüm derleyiciler belirli CPU optimizasyonlarından ve komut setlerinden (örn. Intel'in arada bir eklediği yeni komut setlerinden) yararlanamaz. Derleyici yazarlarının yetişmesini beklemek, rekabet avantajını kaybetmek anlamına gelir.

• Gerçek kodu bilinen CPU mimarisi ve optimizasyonuyla eşleştirmek daha kolay. Örneğin, getirme mekanizması, önbelleğe alma vb. Hakkında bildiğiniz şeyler. Bunun geliştirici için şeffaf olması gerekir, ancak gerçek şu ki, bu yüzden derleyici yazarları optimize edebilir.

• Belirli donanım seviyesi erişimleri yalnızca montaj dili aracılığıyla mümkündür / pratiktir (örneğin, aygıt sürücüsü yazarken).

• Biçimsel akıl yürütme, kodun son veya neredeyse son düzeninin ne olduğunu zaten bildiğiniz için, montaj dili için yüksek seviyeli dilden daha kolaydır.

• API'lerin yokluğunda belirli 3D grafik kartlarının programlanması (1990'ların sonlarında), montaj dilinde genellikle daha pratik ve verimliydi ve bazen diğer dillerde mümkün değildi. Ancak yine, bu, verileri belirli bir sırayla manuel olarak içeri ve dışarı taşımak gibi hızlandırıcı mimarisine dayanan gerçekten uzman düzeyinde oyunları içeriyordu.

Pek çok kişinin daha yüksek seviyeli bir dilin yapacağı durumlarda, özellikle bu dil C olduğunda, assembly dilini kullandığından şüpheliyim. Büyük miktarlarda genel amaçlı kodu elle optimize etmek pratik değildir.

Assembler programlamanın başkalarının bahsetmediği bir yönü vardır - bir uygulamadaki her bir baytın derleyicinin değil kendi çabanızın sonucu olduğunu bildiğinizden duyduğunuz memnuniyet duygusu. 80'lerin başında yaptığım gibi assembler'da tüm uygulamaları yazmaya bir an olsun geri dönmek istemezdim, ama bazen bu hissi özlüyorum ...

Genellikle, bir meslekten olmayanın montajı C'den daha yavaştır (C'nin optimizasyonu nedeniyle), ancak birçok oyunun ( Doom'u açıkça hatırlıyorum ), normal makinelerde sorunsuz çalışması için Assembly'de oyunun belirli bölümlerine sahip olmak zorundaydı.

İşte bahsettiğim örnek.

İlk işimde (80'ler) montaj dilinde profesyonel programlamaya başladım. Gömülü sistemler için bellek talepleri - RAM ve EPROM - düşüktü. Kaynaklarda kolay olan sıkı kodlar yazabilirsiniz.

80'lerin sonunda C'ye geçtim. Kodun yazılması, hata ayıklaması ve bakımı daha kolaydı. Assembler'da çok küçük kod parçacıkları yazılmıştı - benim için bu, kendi RTOS'unuzda bağlam değiştirmeyi yazarken öyleydi. (Bu bir "bilim projesi" olmadığı sürece artık yapmamanız gereken bir şey.)

Bazı Linux kernel kodlarında assembler parçacıkları göreceksiniz. Son zamanlarda onu spinlock'larda ve diğer senkronizasyon kodlarında inceledim. Bu kod parçalarının atomik test ve set işlemlerine, önbellekleri manipüle etmesine vb. Erişmesi gerekir.

Çoğu genel programlama için modern C derleyicilerini optimize etmekte zorlanacağınızı düşünüyorum.

@AltCognito'ya, zamanınızın muhtemelen sorun hakkında daha fazla düşünmek ve işleri daha iyi yapmak için daha iyi harcandığına katılıyorum. Bazı nedenlerden dolayı programcılar genellikle mikro verimliliklere odaklanırlar ve makro verimlilikleri ihmal ederler. Performansı artırmaya yönelik Assembly dili mikro verimliliktir. Sistemin daha geniş bir görünümü için geri adım atmak, bir sistemdeki makro sorunları ortaya çıkarabilir. Makro sorunları çözmek genellikle daha iyi performans kazanımları sağlayabilir. Makro problemler çözüldükten sonra mikro seviyeye inin.

Sanırım mikro problemler tek bir programcının kontrolünde ve daha küçük bir alanda. Makro düzeyde davranışı değiştirmek, daha fazla insanla iletişim gerektirir - bazı programcıların kaçındığı bir şey. Bütün kovboy vs takım olayı.

"Evet". Ancak, assembler'da kod yazmanın faydalarının çoğunlukla çabaya değmediğini anlayın. Mecliste yazmak için alınan getiri, problem hakkında daha fazla düşünmeye odaklanmaktan ve zamanınızı daha iyi bir yol düşünerek harcamaktan daha küçük olma eğilimindedir.

Quake'i yazmaktan büyük ölçüde sorumlu olan John Carmack ve Michael Abrash ve ID'lerin oyun motorlarına giren tüm yüksek performanslı kodlar, bu kitapta ayrıntılı olarak bu konuya giriyor .

Ayrıca, bugün derleyicilerin oldukça akıllı olduğu ve çoğu zaman gizli mimari desteklerden yararlanan birçok teknik kullandığı konusunda Ólafur Waage ile aynı fikirdeyim.

Bu günlerde, en azından sıralı kodlar için, iyi bir derleyici neredeyse her zaman son derece tecrübeli bir assembly dili programcısını bile yener. Ancak vektör kodları için bu başka bir hikaye. Örneğin, yaygın olarak konuşlandırılan derleyiciler, x86 SSE biriminin vektör-paralel özelliklerinden yararlanarak böyle harika bir iş yapmazlar. Ben bir derleyici yazarıyım ve SSE'yi kullanmak , derleyiciye güvenmek yerine kendi başınıza gitmeniz için nedenler listemin başında geliyor.

SSE kodu, en azından MSVC'de derleyici içsellerinden daha iyi çalışır. (yani fazladan veri kopyaları oluşturmaz)

İşteki kaynaklarımda üç veya dört montaj rutini (yaklaşık 20 MB kaynakta) var. Hepsi SSE (2) ve resimler (oldukça büyük - 2400x2048 ve daha büyük düşünün) üzerindeki işlemlerle ilgilidir.

Hobi için bir derleyici üzerinde çalışıyorum ve orada daha fazla derleyiciniz var. Çalışma zamanı kitaplıkları çoğu zaman bunlarla doludur, çoğu normal yordamsal rejime meydan okuyan şeylerle (istisnalar için yardımcılar vb.) İlgilidir.

Mikrodenetleyicim için herhangi bir birleştiricim yok. Modern mikrodenetleyicilerin çoğu , döngüleri optimize etmek için assembler kullanmaya gerek kalmayacak kadar çok çevresel donanıma (kesinti kontrollü sayaçlar, hatta tüm dört evreli kodlayıcılar ve seri yapı blokları) sahiptir. Mevcut flaş fiyatları ile aynı şey kod belleği için de geçerli. Ayrıca, genellikle pin uyumlu cihazlar vardır, bu nedenle sistematik olarak cpu gücünüz veya flash alanınız biterse, yükseltme genellikle sorun olmaz

Gerçekten 100000 cihaz ve programlama derleyicisi göndermediğiniz sürece, sadece bir kategori daha küçük bir flash çipi yerleştirerek gerçekten büyük tasarruflar elde etmeyi mümkün kılar. Ama ben o kategoride değilim.

Pek çok insan gömülü olmanın montajcı için bir bahane olduğunu düşünüyor, ancak denetleyicileri Unix'in geliştirildiği makinelerden daha fazla CPU gücüne sahip . (Mikroçip, 10 USD'nin altında 40 ve 60 MIPS mikro denetleyicilerle birlikte gelir ).

Bununla birlikte, mikroçip mimarisini değiştirmek kolay olmadığından, pek çok insan miras kalmıştır. Ayrıca HLL kodu mimariye çok bağlıdır (çünkü donanım çevresini, G / Ç'yi kontrol etmek için kayıtları vb. Kullanır). Bu yüzden bazen assembler'da bir projeyi sürdürmek için iyi nedenler olabilir (yeni bir mimaride işleri sıfırdan kurabildiğim için şanslıydım). Ama çoğu zaman insanlar gerçekten montajcıya ihtiyaçları olduğu konusunda kendilerini kandırırlar.

GOTO'yu kullanıp kullanamayacağımızı sorduğumuzda bir profesörün verdiği cevabı hala beğeniyorum (ama bunu ASSEMBLER olarak da okuyabilirsiniz): "özelliğe neden ihtiyacınız olduğuna dair 3 sayfalık bir makale yazmaya değeceğini düşünüyorsanız, onu kullanabilirsiniz . Lütfen sonuçlarınızla birlikte makaleyi gönderin. "

Bunu düşük seviyeli özellikler için yol gösterici bir ilke olarak kullandım. Kullanmak için çok sıkılmayın, ancak doğru şekilde motive ettiğinizden emin olun. Hatta bir gerekçe olarak karmaşık akıl yürütmeden kaçınmak için bir veya iki yapay engel (makale gibi) kaldırın.

Bazı talimatlar / bayraklar / kontroller C seviyesinde yoktur.

Örneğin, x86'da taşma kontrolü basit taşma bayrağıdır. Bu seçenek C'de mevcut değildir.

Hatalar satır başına çalışma eğilimindedir (ifade, kod noktası, vb.); Çoğu problem için, montajın yüksek seviyeli dillerden çok daha fazla satır kullanacağı doğru olsa da, bazen eldeki problemin en iyi (en kısa, en az çizgi) haritası olduğu durumlar vardır. Bu vakaların çoğu, gömülü sistemlerde sürücüler ve bitler gibi olağan şüphelileri içerir.

Diğer bir neden, mevcut derleyicinin bir mimari için yeterince iyi olmaması ve programda ihtiyaç duyulan kod miktarının, programcının içinde kaybolması kadar uzun veya karmaşık olmaması olabilir. Gömülü bir sistem için bir mikro denetleyici programlamayı deneyin, genellikle montaj çok daha kolay olacaktır.

Bahsedilen diğer şeylerin yanı sıra, tüm yüksek dillerin belirli sınırlamaları vardır. Bu nedenle, bazı insanlar kodlarını tam olarak kontrol edebilmek için ASM'de programlama yapmayı seçerler.

Diğerleri, 20-60KB aralığında çok küçük yürütülebilir dosyalara sahiptir, örneğin HiEdit kontrolünün yazarı tarafından uygulanan HiEditor , sözdizimi vurgulama ve yalnızca ~ 50kb'lik sekmelerle Windows için mükemmel güçlü düzenleme kontrolü). Koleksiyonumda, Excell'den ssheets gibi html renderlarına kadar 20'den fazla altın kontrolüm var.

Bence birçok oyun geliştiricisi bu bilgiye şaşıracak.

Bildiğim çoğu oyun mümkün olduğunca az montaj kullanıyor. Bazı durumlarda hiç yok ve en kötü ihtimalle bir veya iki döngü veya işlev.

Bu alıntı aşırı genelleştirilmiştir ve on yıl önceki kadar doğru değildir.

Ancak hey, yalnızca gerçekler, gerçek bir hacker'ın toplanma lehine yaptığı haçlı seferini engellememelidir. ;)

128 bayt RAM ve 4K program belleğine sahip düşük kaliteli bir 8 bit mikro denetleyici programlıyorsanız, derlemeyi kullanma konusunda fazla seçeneğiniz yoktur. Bazen daha güçlü bir mikro denetleyici kullanırken, kesin bir zamanda gerçekleşmesi için belirli bir eyleme ihtiyaç duyarsınız. Montaj dili, talimatları sayabildiğiniz ve böylece kodunuz tarafından kullanılan saat döngülerini ölçebildiğiniz için yararlıdır.

Tüm Y2K iyileştirme çabaları için etrafta olsaydınız, Assembly'i bilseydiniz çok para kazanabilirdiniz. Çevresinde hala çok sayıda eski kod var ve bu kod bazen bakım gerektiriyor.

Çok küçük CPU'lar üzerindeki çok küçük projelerin yanı sıra, montajdaki tüm bir projeyi asla programlamaya kalkışmazdım. Bununla birlikte, bazı iç döngülerin stratejik el kodlamasıyla bir performans darboğazının giderilebileceğini bulmak yaygındır.

Bazı durumlarda, gerçekten gerekli olan tek şey, bazı dil yapılarını, optimize edicinin nasıl kullanılacağını anlamasının beklenemeyeceği bir talimatla değiştirmektir. Tipik bir örnek, vektör işlemlerinin ve çoğaltma-biriktirme işlemlerinin bir optimize edicinin keşfetmesinin zor olduğu, ancak kodu kullanmanın kolay olduğu DSP uygulamalarındadır.

Örneğin, bazı SH4 modelleri 4x4 matris ve 4 vektör komutu içerir. Donanım varsayımına uyması için düzeltme matrisini 4x4'e büyütmenin küçük bir maliyetiyle, 3x3 matris üzerindeki eşdeğer C işlemlerini uygun talimatlarla değiştirerek bir renk düzeltme algoritmasında büyük bir performans artışı gördüm . Bu, bir düzineden fazla montaj satırı yazarak ve ilgili veri türlerine uygun ayarlamaları yaparak ve çevreleyen C kodundaki bir avuç yere depolayarak elde edildi.

Bahsedilmiş gibi görünmüyor, bu yüzden eklemeyi düşündüm: modern oyun geliştirmede, en azından yazılan derlemelerin bir kısmının CPU için olmadığını düşünüyorum. Gölgelendirici programları biçiminde GPU için .

Bu, her türlü nedenden ötürü gerekli olabilir, bazen basitçe, kullanılan daha yüksek seviyeli gölgeleme dili, belirli bir boyut kısıtlamasına, hıza veya herhangi bir kombinasyona uymak için tam işlemin istenen talimat sayısıyla tam olarak ifade edilmesine izin vermediğinden . Tıpkı montaj dili programlamasında her zamanki gibi, sanırım.

Bugüne kadar gördüğüm neredeyse her orta-büyük oyun motoru veya kitaplık, 4x4 matris birleştirme gibi matris işlemleri için bazı elle optimize edilmiş montaj sürümlerine sahiptir. Görünüşe göre derleyiciler büyük matrislerle çalışırken bazı akıllı optimizasyonları (yazmaçları yeniden kullanma, döngüleri maksimum verimli bir şekilde açma, makineye özel talimatlardan yararlanma vb.) Kaçınılmaz olarak gözden kaçırıyor. Bu matris işleme fonksiyonları da neredeyse her zaman profilde "sıcak noktalardır".

Ayrıca, elle kodlanmış derlemenin özel gönderim için çok kullanıldığını gördüm - FastDelegate gibi şeyler, ancak derleyiciye ve makineye özel.

Son olarak, Kesme Servis Rutinleriniz varsa, asm dünyadaki tüm farkı yaratabilir - kesme altında olmasını istemediğiniz belirli işlemler vardır ve kesme işleyicilerinizin "içeri girip hızlıca çıkmasını" istersiniz. .. eğer asmdeyse ISR'nizde ne olacağını neredeyse tam olarak biliyorsunuz ve sizi kanlı şeyleri kısa tutmaya teşvik ediyor (ki bu zaten iyi bir uygulamadır).

Oyunlar performans açısından oldukça açlar ve bu arada optimize ediciler oldukça iyi olmasına rağmen bir "usta programcı" montajda doğru parçaları elle kodlayarak biraz daha fazla performans elde edebilir.

Asla önce profil oluşturmadan programınızı optimize etmeye başlamayın. Profil oluşturduktan sonra darboğazları tanımlayabilmeli ve daha iyi algoritmalar bulmak ve benzerleri artık onu kesmiyorsa, montajdaki bazı şeyleri elle kodlamayı deneyebilirsiniz.

Montaj kullanımı hakkında sadece bir geliştiriciyle kişisel olarak konuştum. Taşınabilir bir mp3 çaların kontrolleriyle ilgilenen aygıt yazılımı üzerinde çalışıyordu. İşi montajda yapmanın 2 amacı vardı:

1. Hız: gecikmelerin minimum düzeyde olması gerekir.
2. Maliyet: Kodun minimum düzeyde olması nedeniyle, onu çalıştırmak için gereken donanım biraz daha az güçlü olabilir. Milyonlarca birim seri üretildiğinde, bu eklenebilir.

Yapmaya devam ettiğim tek derleyici kodlaması, yetersiz kaynaklara sahip gömülü donanım içindir. Leander bahseder gibi, montaj yine de uygundur ISR ler kodu hızlı ve iyi anlaşılması gereken burada.

Benim için ikinci bir neden, montaj bilgimi işlevsel tutmaktır. Teklifimi yerine getirmek için CPU'nun attığı adımları inceleyip anlayabilmek sadece iyi hissettiriyor.

Assemblyler'da en son yazdığımda, derleyiciyi libc içermeyen, konumdan bağımsız kod üretmeye ikna edemediğim zamandı.

Bir dahaki sefere muhtemelen aynı sebepten olacak.

Elbette başka nedenlerim vardı .

Pek çok insan montaj dilini karalamayı sever çünkü onunla kodlamayı asla öğrenmediler ve onunla sadece belli belirsiz bir şekilde karşılaştılar ve bu onları ya korkuttu ya da biraz korkuttu. Gerçek yetenekli programcılar, tamamlayıcı oldukları için C veya Assembly'ye vurmanın anlamsız olduğunu anlayacaklardır. aslında birinin avantajı diğerinin dezavantajıdır. C'nin organize sözdizimsel kuralları netliği geliştirir, ancak aynı zamanda iktidar meclisinin herhangi bir yapısal kuraldan muaf olmasını da bırakır! C kodu talimatı, programlama amacının netliğini zorladığı tartışılabilecek, engellemeyen kod oluşturmak için yapılır, ancak bu bir güç kaybıdır. C'de derleyici if / elseif / else / end içine atlamaya izin vermeyecektir. Veya birbiriyle örtüşen farklı değişkenlere iki for / end döngüsü yazmanıza izin verilmez, kendi kendini değiştiren kod yazamazsınız (veya sorunsuz bir şekilde yapamazsınız), vb. geleneksel programcılar yukarıdakilerden korkar ve bu yaklaşımların gücünü, geleneksel kuralları takip etmek için yetiştirildikleri için nasıl kullanacakları hakkında hiçbir fikirleri olmaz. . İşte gerçek: Bugün, kullandığımız uygulamadan çok daha fazlasını yapacak bilgi işlem gücüne sahip bir makineye sahibiz, ancak insan beyni bunları kuraldan bağımsız bir kodlama ortamında (= montaj) kodlayamayacak kadar yetersiz ve büyük ölçüde kısıtlayıcı kurallara ihtiyaç duyuyor. spektrumu azaltır ve kodlamayı basitleştirir. Yukarıda bahsedilen sınırlamalar nedeniyle çok verimsiz hale gelmeden C koduyla yazılamayacak bir kod yazdım. Ve çoğu insanın montajda yazmanın ana nedeni olduğunu düşündüğü hızdan henüz bahsetmedim. Eğer zihniniz C'de düşünmekle sınırlıysa, o zaman sonsuza kadar derleyicinizin kölesi olursunuz. C programcıları sadece "Dames" oynarken, satranç ustalarının ideal montaj programcıları olacağını hep düşünmüşümdür.

Artık hız değil, Kontrol . Hız bazen kontrolden gelir, ancak montajda kodlamanın tek nedeni budur . Diğer tüm nedenler, kontrole (yani, SSE ve diğer el optimizasyonu, aygıt sürücüleri ve aygıta bağlı kod, vb.)

GCC ve Visual C ++ 2008'den (Visual C ++ 9.0 olarak da bilinir) daha iyi performans gösterebilirsem, insanlar bunun nasıl mümkün olduğu hakkında benimle röportaj yapmakla ilgilenecekler.

Bu yüzden şu an için bir şeyler okudum ve gerektiğinde __asm ​​int 3 yazıyorum.

Umarım bu yardımcı olur ...

Birkaç yıldır mecliste yazmadım, ancak eskiden iki nedenim vardı:

• Bir şeyin meydan okuması! Yıllar önce her şeyi x86 derlemesinde ( DOS ve Windows 3.1 günleri) yazdığım birkaç aylık bir dönemden geçtim . Temelde bana bir yığın düşük seviyeli işlem, donanım G / Ç vb. Öğretti .
• Bazı şeyler için boyutu küçük tuttu (yine TSR yazarken DOS ve Windows 3.1 )

Kodlama derlemesine tekrar bakıyorum ve bu, işin zorluğu ve eğlencesinden başka bir şey değil. Bunu yapmak için başka bir nedenim yok :-)

Bir keresinde, önceki programcının kayan nokta kullanarak (sabit noktalı bir DSP üzerinde!) C'de yazılan ton algılama mantığı dışında, çoğunlukla montaj kodunda yazdığı bir DSP projesini devralmıştım. Ton algılama mantığı gerçek zamanın yaklaşık 1 / 20'sinde çalıştı.

Neredeyse her şeyi sıfırdan yeniden yazdım. Bazı küçük kesme işleyicileri ve kesme işleme ve eski koddan 100 kat daha hızlı çalışan düşük seviyeli frekans algılama ile ilgili birkaç düzine kod satırı dışında hemen hemen her şey C'de idi.

Akılda tutulması gereken önemli bir şey, sanırım, çoğu durumda, küçük rutinlerle hızın artırılması için büyük olanlara göre çok daha büyük fırsatlar olacağıdır, özellikle de elle yazılmış derleyici her şeyi yazmaçlara sığdırabiliyorsa, ancak bir derleyici yapmazsa oldukça yönetin. Bir döngü zaten her şeyi kayıtlarda tutamayacak kadar büyükse, iyileştirme için çok daha az fırsat vardır.

Android telefonlardaki Java uygulamaları için bayt kodunu yorumlayan Dalvik VM, dağıtıcı için assembler kullanır. Bu film (yaklaşık 31 dakika içinde, ancak tüm filmi izlemeye değer!)

"Hala bir insanın derleyiciden daha iyisini yapabileceği durumlar vardır".

Yapmıyorum, ama en azından denemek ve ilerlemenin bir noktasında çok uğraşmak için bir noktaya değindim (yakında umarım). Yüksek seviyeli bir dilde programlama yaparken düşük seviyeli şeyleri ve perde arkasında işlerin nasıl yürüdüğünü öğrenmek kötü bir şey olamaz. Ne yazık ki bir geliştirici / danışman ve bir ebeveyn olarak tam zamanlı bir işte zaman kazanmak zor. Ama zamanında teslim edeceğim, bu kesin.