Windows'un C ++ derlemek için Linux kadar hızlı gitmesini nasıl sağlayabilirim?

Bunun çok fazla bir programlama sorusu olmadığını biliyorum ama alakalı.

Oldukça büyük bir çapraz platform projesi üzerinde çalışıyorum . Windows'ta VC ++ 2008 kullanıyorum. Linux'ta gcc kullanıyorum. Projede yaklaşık 40 bin dosya var. Windows, aynı projeyi derlerken ve bağlarken Linux'tan 10x ila 40x daha yavaştır. Bunu nasıl düzeltebilirim?

Tek bir değişiklik, Linux'ta 20 saniye ve Windows'ta> 3 dakika artımlı bir derleme oluşturur. Neden? Linux'a 'altın' bağlayıcı bile kurabilir ve o zamanı 7 saniyeye indirebilirim.

Benzer şekilde git Linux'ta Windows'tan 10x ila 40x daha hızlıdır.

Git durumunda git git Windows'u en uygun şekilde kullanmıyor ama VC ++? Microsoft'un kendi geliştiricilerini olabildiğince verimli hale getirmek isteyeceğini ve daha hızlı derlemenin buna çok yol açacağını düşünürdünüz. Belki de geliştiricileri C # 'a teşvik etmeye çalışıyorlar?

Basit bir test olarak, çok sayıda alt klasör içeren bir klasör bulun ve

dir /s > c:\list.txt

Windows üzerinde. Bunu iki kez yapın ve ikinci çalışmanın önbellekten çalışmasını sağlayın. Dosyaları Linux'a kopyalayın ve eşdeğer 2 çalıştırmayı yapın ve ikinci çalıştırmayı yapın.

ls -R > /tmp/list.txt

Aynı özelliklere sahip 2 iş istasyonum var. 12g koçlu HP Z600s, 3.0ghz'de 8 çekirdek. ~ 400k dosyaları olan bir klasörde Windows 40 saniye alır, Linux <1 saniye sürer.

Windows'u hızlandırmak için ayarlayabileceğim bir kayıt defteri ayarı var mı? Ne oluyor?

Derleme süreleriyle ilgili olan biraz ilintili bağlantılar, ille de i / o değildir.

• Görünüşe göre Windows 10'da (Windows 7'de değil) bir işlemi kapatmanın genel bir kilit tutması sorunu var . Birden çok çekirdek ve dolayısıyla birden çok işlemle derlenirken bu sorun ortaya çıkar.

• /analyseBir web tarayıcısını yüklemesidir seçenek olumsuz perf etkileyebilir . (Burada alakalı değil, bilmek iyi)

Hardcore bir Windows sistemleri korsanı gelmedikçe, partizan yorumlarından (yapmayacağım) ve spekülasyondan (deneyeceğim şey) daha fazlasını elde edemezsiniz.

1. Dosya sistemi - dirAynı dosya sisteminde aynı işlemleri (dahil ) denemelisiniz . Ben rastladım bu değişik parametreler için birkaç dosya sistemlerini kriterler hangi.

2. Önbelleğe almak. Bir keresinde Linux'ta bir RAM diskinde bir derleme çalıştırmayı denedim ve çekirdeğin önbelleğe alma şekli sayesinde diskte çalıştırmaktan daha yavaş olduğunu gördüm. Bu Linux için sağlam bir satış noktasıdır ve performansın bu kadar farklı olmasının nedeni olabilir.

3. Windows'ta kötü bağımlılık özellikleri. Belki de Windows için krom bağımlılığı spesifikasyonları Linux için olduğu kadar doğru değildir. Bu, küçük bir değişiklik yaptığınızda gereksiz derlemelerle sonuçlanabilir. Windows'ta aynı derleyici araç zincirini kullanarak bunu doğrulayabilirsiniz.

Birkaç fikir:

1. 8.3 adları devre dışı bırakın. Bu, çok sayıda dosyaya ve nispeten az sayıda klasöre sahip sürücülerde büyük bir faktör olabilir:fsutil behavior set disable8dot3 1
2. Daha fazla klasör kullanın. Deneyimlerime göre, NTFS klasör başına yaklaşık 1000'den fazla dosyayla yavaşlamaya başlar.
3. MSBuild ile paralel derlemeleri etkinleştirin; "/ m" anahtarını eklemeniz yeterlidir ve CPU çekirdeği başına MSBuild'in bir kopyasını otomatik olarak başlatır.
4. Dosyalarınızı bir SSD'ye koyun - rastgele G / Ç için büyük yardımcı olur.
5. Ortalama dosya boyutunuz 4KB'den daha büyükse, dosya sistemini kabaca ortalama dosya boyutunuza karşılık gelen daha büyük bir küme boyutuyla yeniden oluşturmayı düşünün.
6. Dosyaların birleştirildiğinden emin olun. Parçalanmış dosyalar çok fazla disk aramasına neden olur, bu da size verimde 40+ faktöre mal olabilir. Sysinternals veya yerleşik Windows birleştiricisinin "contig" yardımcı programını kullanın.
7. Ortalama dosya boyutunuz küçükse ve bulunduğunuz bölüm nispeten doluysa, performans açısından kötü olan parçalı bir MFT ile çalışıyor olabilirsiniz. Ayrıca, 1K'dan küçük dosyalar doğrudan MFT'de saklanır. Yukarıda belirtilen "contig" yardımcı programı yardımcı olabilir veya MFT boyutunu artırmanız gerekebilir. Aşağıdaki komut, ses düzeyinin% 25'ine iki katına çıkarır: fsutil behavior set mftzone 2Boyutu% 12,5'lik artışlarla artırmak için son sayıyı 3 veya 4 olarak değiştirin. Komutu çalıştırdıktan sonra, yeniden başlatın ve sonra dosya sistemini oluşturun.
8. Son erişim süresini devre dışı bırak: fsutil behavior set disablelastaccess 1
9. Dizin oluşturma hizmetini devre dışı bırakma
10. Virüsten koruma ve casus yazılım önleme yazılımınızı devre dışı bırakın veya en azından göz ardı edilecek ilgili klasörleri ayarlayın.
11. Dosyalarınızı işletim sisteminden ve disk belleği dosyasından farklı bir fiziksel sürücüye yerleştirin. Ayrı bir fiziksel sürücü kullanmak, Windows'un her iki sürücüye de paralel G / Ç kullanmasına olanak tanır.
12. Derleyici bayraklarınıza bir göz atın. Windows C ++ derleyicisinin birçok seçeneği vardır; yalnızca gerçekten ihtiyacınız olanları kullandığınızdan emin olun.
13. İşletim sisteminin disk belleği havuzu tamponları için kullandığı bellek miktarını artırmayı deneyin (önce yeterli RAM'e sahip olduğunuzdan emin olun): fsutil behavior set memoryusage 2
14. Ara sıra disk hataları yaşamadığınızdan emin olmak için Windows hata günlüğünü kontrol edin.
15. Disklerinizin ne kadar meşgul olduğunu görmek için Fiziksel Disk ile ilgili performans sayaçlarına göz atın. Yüksek kuyruk uzunlukları veya aktarım başına uzun süreler kötü işaretlerdir.
16. Disk bölümlerinin ilk% 30'u ham aktarım süresi açısından diskin geri kalanından çok daha hızlıdır. Daha dar bölümler ayrıca arama sürelerini en aza indirmeye yardımcı olur.
17. RAID mi kullanıyorsunuz? Öyleyse, RAID türü seçiminizi optimize etmeniz gerekebilir (RAID-5, derleme gibi ağır yazma işlemleri için kötüdür)
18. İhtiyacınız olmayan hizmetleri devre dışı bırakın
19. Klasörleri birleştir: tüm dosyaları başka bir sürücüye kopyalayın (sadece dosyaları), orijinal dosyaları silin, tüm klasörleri başka bir sürücüye kopyalayın (sadece boş klasörler), ardından orijinal klasörleri silin, orijinal sürücüyü birleştirin, önce klasör yapısını kopyalayın ardından dosyaları kopyalayın. Windows büyük klasörleri tek tek oluşturduğunda, klasörler parçalanır ve yavaşlar. ("contig" burada da yardımcı olmalı)
20. G / Ç bağlıysanız ve yedek CPU döngüleriniz varsa, disk sıkıştırmayı AÇIK konuma getirmeyi deneyin. CPU'da bir miktar maliyetle, oldukça sıkıştırılabilir dosyalar (kaynak kodu gibi) için bazı önemli hızlandırmalar sağlayabilir.

NTFS her zaman dosya erişim zamanından tasarruf sağlar. Devre dışı bırakmayı deneyebilirsiniz: "fsutil behavior setctivlastaccess 1" (yeniden başlatma)

Visual c ++ ile ilgili sorun, söyleyebildiğim kadarıyla, derleyici ekibinin bu senaryoyu optimize etmesinin bir öncelik olmadığını söyleyebiliriz. Onların çözümü, önceden derlenmiş başlık özelliklerini kullanmanızdır. Windows'a özgü projelerin yaptığı budur. Taşınabilir değil, ama çalışıyor.

Ayrıca, pencerelerde genellikle virüs tarayıcıların yanı sıra, buid klasörünüzü sizin için izlerse oluşturma sürelerinizi tamamen mahvedebilecek sistem geri yükleme ve arama araçları vardır. windows 7 resouce monitörü bulmanıza yardımcı olabilir. Ben burada bir cevap gerçekten ilgilenen eğer vc ++ inşa sürelerini optimize etmek için bazı ilave ipuçları ile.

Ben şahsen linux üzerinde bir windows sanal makine çalışan bulundu, çünkü linux vm Windows'un kendisi değildi önbellek çok yapıyor çünkü Windows IO yavaşlığı büyük bir kısmını başardı.

Bunu yaptığım 15 dakikadan 6 dakikaya kadar olan büyük (250Kloc) C ++ projelerinin derleme sürelerini hızlandırabildim.

Bunu yapmanın zorluğu, C ++ 'nın kendini ve derleme sürecini birçok küçük, bireysel dosyaya yayma eğiliminden kaynaklanmaktadır. Bu Linux'un iyi olduğu ve Windows'ın iyi olmadığı bir şey. Windows için gerçekten hızlı bir C ++ derleyicisi yapmak istiyorsanız, her şeyi RAM'de tutmaya çalışın ve dosya sistemine mümkün olduğunca az dokunun.

Bu şekilde daha hızlı bir Linux C ++ derleme zinciri oluşturacaksınız, ancak dosya sistemi zaten sizin için bu ayarın çoğunu yapıyor çünkü Linux'ta daha az önemli.

Bunun nedeni Unix kültüründen kaynaklanmaktadır: Tarihsel olarak dosya sistemi performansı, Unix dünyasında Windows'a göre çok daha yüksek bir önceliğe sahiptir. Bunun Windows'da bir öncelik olmadığını söylemek değil, sadece Unix'te daha yüksek bir öncelik olduğunu söylemek.

1. Kaynak koduna erişim.

   Kontrol edemediğiniz şeyi değiştiremezsiniz. Windows NTFS kaynak koduna erişimin olmaması, performansı artırma çabalarının çoğunun donanım geliştirmelerine rağmen olduğu anlamına gelir. Yani, performans yavaşsa, donanımı geliştirerek sorunu çözersiniz: veri yolu, depolama ortamı, vb. Sorunu çözmek için değil, sadece sorunu çözmek için çok şey yapabilirsiniz.

   Unix kaynak koduna erişim (açık kaynaktan önce bile) daha yaygındı. Bu nedenle, performansı artırmak istiyorsanız, önce yazılımda (daha ucuz ve daha kolay) ve ikinci olarak donanımda ele alırsınız.

   Sonuç olarak, dünyada Unix dosya sistemini inceleyerek ve performansı iyileştirmek için yeni yollar bularak doktoralarını alan birçok insan var.

2. Unix birçok küçük dosyaya yönelir; Windows birkaç (veya tek) büyük dosyaya yönelir.

   Unix uygulamaları birçok küçük dosyayla ilgilenme eğilimindedir. Bir yazılım geliştirme ortamı düşünün: her birinin kendi amacı olan birçok küçük kaynak dosyası. Son aşama (bağlama) büyük bir dosya oluşturur, ancak bu küçük bir yüzdedir.

   Sonuç olarak, Unix, dosyaları açmak ve kapatmak, dizinleri taramak vb. İçin son derece optimize edilmiş sistem çağrılarına sahiptir. Unix araştırma makalelerinin geçmişi, dizin erişimini (aramalar ve tam dizin taramaları), ilk dosya açma vb.

   Windows uygulamaları büyük bir dosyayı açma, uzun süre açık tutma, bittiğinde kapatma eğilimindedir. MS-Word'ü düşünün. msword.exe (ya da her neyse) dosyayı bir kez açar ve saatlerce ekler, dahili blokları günceller vb. Dosyanın açılışını optimize etme değeri zaman kaybı olacaktır.

   Windows kıyaslama ve optimizasyonunun geçmişi, uzun dosyaları ne kadar hızlı okuyabileceği veya yazabileceğidir. Optimize edilen budur.

   Ne yazık ki yazılım geliştirme ilk duruma doğru yöneldi. Hix, Unix (TeX / LaTeX) için en iyi kelime işlemci sistemi, her bölümü farklı bir dosyaya koymanızı ve # hepsini bir araya getirmenizi önerir.

3. Unix yüksek performansa odaklanmıştır; Windows kullanıcı deneyimine odaklanmıştır

   Unix sunucu odasında başladı: kullanıcı arayüzü yok. Kullanıcıların gördüğü tek şey hızdır. Bu nedenle hız bir önceliktir.

   Windows masaüstünde başladı: Kullanıcılar yalnızca gördüklerini önemsiyor ve kullanıcı arayüzünü görüyorlar. Bu nedenle, kullanıcı arayüzünü geliştirmek için performanstan daha fazla enerji harcanır.

4. Windows ekosistemi planlanan eskime durumuna bağlıdır. Yeni donanım sadece bir veya iki yıl uzaktayken yazılımı neden optimize etmelisiniz?

   Komplo teorilerine inanmıyorum, ancak yapsaydım, Windows kültüründe performansı arttırmak için daha az teşvik olduğunu belirtelim. Windows iş modelleri, saat gibi yeni makineler satın alan kişilere bağlıdır. (Bu nedenle, MS bir işletim sistemini geç gönderirse veya Intel bir yonga çıkış tarihini kaçırırsa binlerce şirketin hisse senedi fiyatı etkilenir.). Bu, insanlara yeni donanım satın almalarını söyleyerek performans sorunlarını çözmeye yönelik bir teşvik olduğu anlamına gelir; asıl sorunu geliştirerek değil: yavaş işletim sistemleri. Unix, bütçenin sıkı olduğu akademiden geliyor ve dosya sistemlerini daha hızlı hale getirmenin yeni bir yolunu kullanarak doktora derecenizi alabiliyorsunuz; Akademi'de bir kişi nadiren satın alma emri vererek bir problemi çözmek için puan alır.

   Ayrıca, Unix açık kaynak olduğundan (olmasa bile, herkes kaynağa erişime sahipti) herhangi bir sıkılmış doktora öğrencisi kodu okuyabilir ve daha iyi hale getirerek ünlü olabilir. Bu Windows'ta olmaz (MS, akademisyenlerin Windows kaynak koduna erişmesini sağlayan bir programa sahiptir, nadiren yararlanır). Unix ile ilgili performans kağıtlarının şu seçimine bakın: http://www.eecs.harvard.edu/margo/papers/ veya Osterhaus, Henry Spencer veya başkalarının makalelerinin geçmişine bakın. Unix tarihindeki en büyük (ve izlemesi en zevkli) tartışmalardan biri olan Heck, Osterhaus ve Selzer arasında ileri ve geri http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal oldu. html Windows dünyasında böyle bir şey görmüyorsunuz. Satıcıların birbirlerini bir araya getirdiğini görebilirsiniz, ancak son zamanlarda yeniliğin standartların vücut düzeyinde olduğu göründüğünden çok daha nadir görünüyor.

Ben böyle görüyorum.

Güncelleme: Microsoft'tan çıkan yeni derleyici zincirlerine bakarsanız, çok iyimser olacaksınız çünkü yaptıkları şeylerin çoğu, tüm takım zincirini RAM'de tutmayı ve daha az işi tekrarlamayı kolaylaştırıyor. Çok etkileyici şeyler.

Artımlı bağlama

VC 2008 çözümü .lib çıktılarına sahip birden çok proje olarak ayarlandıysa, "Kütüphane Bağımlılık Girişlerini Kullan"; bu, linker bağlantısını .lib yerine doğrudan .obj dosyalarına yapar. (Ve aslında onu kademeli olarak bağlar.)

Dizin geçiş performansı

Orijinal makinedeki dizin taramayı başka bir makinedeki aynı dosyalarla yeni oluşturulan bir dizini taramakla karşılaştırmak biraz haksızlık olur. Eşdeğer bir test istiyorsanız, muhtemelen kaynak makinede dizinin başka bir kopyasını almalısınız. Ben perf sorunları düşünmek rağmen: (disk parçalanması, kısa dosya adları, arka plan hizmetleri, vb Hala yavaş olabilir, ancak bunun nedeni şeylerin herhangi bir sayı için olabilir) dir /sgerçek dosyayı ölçme daha çıktı yazma yapmak için daha fazla var çapraz performans. dir /s /b > nulBüyük bir dizine sahip makinemde bile yavaş.

Dosya sistemiyle ilgili olduğundan eminim. Linux ve Windows için platforma bağlı kodun kesinlikle gerekli olduğu durumlar dışında tüm kodların ortak olduğu bir çapraz platform projesi üzerinde çalışıyorum. Git yerine Mercurial kullanıyoruz, bu yüzden git "Linuxness" geçerli değil. Merkezi depodaki değişiklikleri çekmek, Linux'a kıyasla Windows'ta sonsuza kadar sürer, ancak Windows 7 makinelerimizin Windows XP olanlardan çok daha iyi olduğunu söylemeliyim. Bundan sonra kodu derlemek VS 2008'de daha da kötüdür. Sadece hg değil; CMake, Windows'da da çok daha yavaş çalışır ve bu araçların her ikisi de dosya sistemini her şeyden daha fazla kullanır.

Sorun o kadar kötü ki, bir Windows ortamında çalışan geliştiricilerimizin çoğu artık artımlı yapılar yapmakla bile uğraşmıyor - bunun yerine birlik kurmanın daha hızlı olduğunu buluyorlar .

Bu arada, Windows'ta derleme hızını önemli ölçüde azaltmak istiyorsanız, yukarıda belirtilen birlik derlemesini öneririm. Derleme sisteminde doğru bir şekilde uygulamak acı vericidir (CMake'teki ekibimiz için yaptım), ancak bir kez otomatik olarak yapıldığında sürekli entegrasyon sunucularımız için işleri hızlandırır. Yapı sisteminizin tükettiği ikililere bağlı olarak, 1 ila 2 büyüklük iyileştirmesi siparişi alabilirsiniz. Kilometreniz değişebilir. Bizim durumumuzda, Linux'un üç katlı ve Windows'u yaklaşık 10 kat artırdığını düşünüyorum, ancak çok sayıda paylaşılan kitaplık ve yürütülebilir dosya var (bir birlik derlemesinin avantajlarını azaltıyor).

Büyük çapraz platform projenizi nasıl oluşturuyorsunuz? Linux ve Windows için ortak makefiles kullanıyorsanız, makefiles Windows'da hızlı olacak şekilde tasarlanmamışsa, windows performansını 10 faktör kadar kolayca düşürebilirsiniz.

Linux ve Windows için ortak (GNU) makefiles kullanarak çapraz platform projesinin bazı markalarını düzelttim. Make başlıyorsh.exe bir reçetenin her satırı için Windows ve Linux arasındaki performans farkına neden olan süreç başlatıyor!

GNU'ya göre dokümantasyon yapın

.ONESHELL:

sorunu çözmelidir, ancak bu özellik (şu anda) Windows make için desteklenmemektedir. Bu nedenle, tarifleri tek bir mantıksal satırda olacak şekilde yeniden yazmak (örneğin, mevcut editör satırlarının sonuna; \ veya \ ekleyerek) çok iyi çalıştı!

IMHO tamamen disk G / Ç performansı ile ilgilidir. Büyüklük sırası, birçok işlemin Windows altında diske gittiğini gösterirken, Linux altında bellekte işlenir, yani Linux daha iyi önbelleğe alır. Pencerelerin altındaki en iyi seçeneğiniz, dosyalarınızı hızlı bir diske, sunucuya veya dosya sistemine taşımak olacaktır. Katı Hal Sürücüsü satın almayı veya dosyalarınızı bir ramdiske veya hızlı NFS sunucusuna taşımayı düşünün.

Dizin geçiş testlerini çalıştırdım ve sonuçlar rapor edilen derleme sürelerine çok yakın, bunun CPU işlem süreleri veya derleyici / bağlayıcı algoritmaları ile ilgisi olmadığını düşündürüyor.

Krom dizin ağacından geçerken yukarıda önerilen ölçülen süreler:

• NTFS'de Windows Home Premium 7 (8 GB Ram): 32 saniye
• NTFS'de Ubuntu 11.04 Linux (2GB Ram): 10 saniye
• Ext4'te Ubuntu 11.04 Linux (2GB Ram): 0.6 saniye

Testler için krom kaynaklarını (her ikisi de win / linux altında) çektim

git clone http://github.com/chromium/chromium.git 
cd chromium
git checkout remotes/origin/trunk 

Kaçtığım zamanı ölçmek için

ls -lR > ../list.txt ; time ls -lR > ../list.txt # bash
dir -Recurse > ../list.txt ; (measure-command { dir -Recurse > ../list.txt }).TotalSeconds  #Powershell

Erişim zaman damgalarını, virüs tarayıcımı kapattım ve pencereler altındaki önbellek yöneticisi ayarlarını (> 2Gb RAM) artırdım - hepsi belirgin bir iyileştirme olmadan. İşin doğrusu, kutudan çıkar çıkmaz Linux, RAM'in dörtte biri ile Windows'tan 50 kat daha iyi performans gösterdi.

Sayıların yanlış olduğunu iddia etmek isteyen herkes için - herhangi bir nedenle - lütfen bir deneyin ve bulgularınızı gönderin.

Nmake yerine jom kullanmayı deneyin

Buradan edinin: https://github.com/qt-labs/jom

Gerçek şu ki, nmake çekirdeklerinizden sadece birini kullanıyor, jom çok çekirdekli işlemcilerden yararlanan bir nmake klonu.

GNU, -j seçeneği sayesinde bunu hazır yapar, bu da Microsoft nmake'ye karşı hızının bir nedeni olabilir.

jom, farklı işlemciler / çekirdekler üzerinde paralel olarak farklı make komutları yürüterek çalışır. Kendinizi farkı hissedin!

Gnu make'i ve Windows'taki MinGW araçlarından diğer araçları kullanarak sadece bir gözlem eklemek istiyorum: Araçlar IP yoluyla iletişim kuramasalar bile ana bilgisayar adlarını çözüyor gibi görünüyorlar. Bunun MinGW çalışma zamanının bazı başlatma rutinlerinden kaynaklandığını tahmin ediyorum. Yerel bir DNS proxy çalıştırmak, bu araçlarla derleme hızını artırmama yardımcı oldu.

Büyük bir baş ağrımdan önce, paralel olarak bir VPN bağlantısı açtığımda oluşturma hızı 10 kat azaldı. Bu durumda, tüm bu DNS aramaları VPN'den geçti.

Bu gözlem, sadece MinGW tabanlı değil, aynı zamanda en son MinGW sürümünde de değişmiş olabilir.

Son zamanlarda mingw bash.exe'yi win- bash'ın sürümüyle değiştirerek Gnu make'i kullanarak derlemeyi yaklaşık% 10 oranında hızlandırmanın başka bir yolunu arşivleyebilirim

(Kazan-bash etkileşimli düzenleme konusunda çok rahat değildir.)