Trudność w tym wynika z faktu, że C ++ ma tendencję do rozprzestrzeniania się i procesu kompilacji na wiele małych, pojedynczych plików. W tym Linux jest dobry, a Windows nie. Jeśli chcesz stworzyć naprawdę szybki kompilator C ++ dla Windows, staraj się trzymać wszystko w pamięci RAM i jak najmniej dotykać systemu plików.
W ten sposób stworzysz szybszy łańcuch kompilacji Linuksa C ++, ale jest to mniej ważne w Linuksie, ponieważ system plików już robi za Ciebie wiele z tego dostrajania.
Przyczyną tego jest kultura uniksowa: w przeszłości wydajność systemu plików była znacznie wyższym priorytetem w świecie Uniksa niż w systemie Windows. Nie znaczy to, że nie był to priorytet w systemie Windows, po prostu w systemie Unix miał wyższy priorytet.
Dostęp do kodu źródłowego.
Nie możesz zmienić tego, czego nie możesz kontrolować. Brak dostępu do kodu źródłowego systemu Windows NTFS oznacza, że większość wysiłków zmierzających do poprawy wydajności dotyczyła ulepszeń sprzętowych. Oznacza to, że jeśli wydajność jest wolna, problem można obejść, ulepszając sprzęt: magistralę, nośnik pamięci itd. Możesz zrobić tylko tyle, jeśli musisz obejść problem, a nie go naprawiać.
Dostęp do kodu źródłowego Uniksa (jeszcze przed otwarciem kodu źródłowego) był bardziej rozpowszechniony. Dlatego jeśli chciałbyś poprawić wydajność, powinieneś zająć się tym najpierw w oprogramowaniu (tańsze i łatwiejsze), a następnie w sprzęcie.
W rezultacie na świecie jest wiele osób, które zdobyły doktoraty, studiując system plików Unix i znajdując nowe sposoby na poprawę wydajności.
Unix ma tendencję do tworzenia wielu małych plików; Windows ma tendencję do tworzenia kilku (lub jednego) dużego pliku.
Aplikacje uniksowe zwykle obsługują wiele małych plików. Pomyśl o środowisku programistycznym: wiele małych plików źródłowych, każdy z innym przeznaczeniem. Ostatni etap (linkowanie) tworzy jeden duży plik, ale jest to niewielki procent.
W rezultacie Unix ma wysoce zoptymalizowane wywołania systemowe do otwierania i zamykania plików, skanowania katalogów i tak dalej. Historia prac badawczych dotyczących Uniksa obejmuje dziesiątki lat optymalizacji systemu plików, które poświęcono dużo uwagi poprawie dostępu do katalogów (wyszukiwanie i skanowanie pełnego katalogu), początkowym otwieraniu plików i tak dalej.
Aplikacje systemu Windows mają tendencję do otwierania jednego dużego pliku, utrzymywania go otwartego przez długi czas i zamykania po zakończeniu. Pomyśl o MS-Word. msword.exe (lub cokolwiek innego) otwiera plik raz i dołącza go godzinami, aktualizuje wewnętrzne bloki i tak dalej. Wartość optymalizacji otwierania pliku byłaby stratą czasu.
Historia testów porównawczych i optymalizacji systemu Windows dotyczy tego, jak szybko można czytać lub zapisywać długie pliki. Właśnie to zostaje zoptymalizowane.
Niestety rozwój oprogramowania zmierzał w kierunku pierwszej sytuacji. Do licha, najlepszy system przetwarzania tekstu dla Uniksa (TeX / LaTeX) zachęca do umieszczania każdego rozdziału w innym pliku i # uwzględniania ich wszystkich razem.
Unix koncentruje się na wysokiej wydajności; Windows koncentruje się na wrażeniach użytkownika
Unix uruchomiony w serwerowni: brak interfejsu użytkownika. Jedyne, co widzą użytkownicy, to szybkość. Dlatego priorytetem jest szybkość.
System Windows został uruchomiony na pulpicie: Użytkownicy dbają tylko o to, co widzą, i widzą interfejs użytkownika. Dlatego więcej energii przeznacza się na poprawę interfejsu użytkownika niż na wydajność.
Ekosystem Windows zależy od planowanej dezaktualizacji. Po co optymalizować oprogramowanie, gdy nowy sprzęt jest już za rok lub dwa?
Nie wierzę w teorie spiskowe, ale gdybym wierzył, wskazałbym, że w kulturze Windows jest mniej bodźców do poprawy wydajności. Modele biznesowe Windows zależą od ludzi kupujących nowe maszyny, takie jak w zegarku. (Dlatego cena akcji tysięcy firm ulega zmianie, jeśli MS spóźni się z dostawą systemu operacyjnego lub jeśli Intel przegapi datę premiery chipa). Oznacza to, że istnieje zachęta do rozwiązywania problemów z wydajnością poprzez nakłanianie ludzi do zakupu nowego sprzętu; nie poprawiając prawdziwego problemu: powolnych systemów operacyjnych. Unix wywodzi się ze środowiska akademickiego, w którym budżet jest napięty, a doktorat można uzyskać, wymyślając nowy sposób na przyspieszenie systemów plików; rzadko ktoś ze środowiska akademickiego otrzymuje punkty za rozwiązanie problemu poprzez wydanie zamówienia.
Ponadto, ponieważ Unix jest oprogramowaniem typu open source (nawet jeśli nie był, każdy miał do niego dostęp), każdy znudzony doktorant może czytać kod i zyskać sławę dzięki ulepszaniu go. To się nie zdarza w systemie Windows (MS ma program, który zapewnia naukowcom dostęp do kodu źródłowego Windows, rzadko jest wykorzystywany). Spójrz na ten wybór artykułów związanych z Uniksem: http://www.eecs.harvard.edu/margo/papers/ lub zapoznaj się z historią artykułów Osterhausa, Henry'ego Spencera lub innych. Heck, jedną z największych (i najprzyjemniejszych do oglądania) debat w historii Uniksa była wymiana zdań między Osterhaus i Selzer http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal. html
Nie widać, żeby coś takiego działo się w świecie Windows. Może się zdarzyć, że dostawcy będą się wzajemnie poprawiać, ale ostatnio wydaje się to znacznie rzadsze, ponieważ wydaje się, że wszystkie innowacje są na poziomie organów normalizacyjnych.
Tak to widzę.