Istnieje wiele badań porównawczych i dostępnych online, jeśli chodzi o wydajność środowiska wykonawczego aplikacji zbudowanych w tym lub innym języku. Niektóre napędzane przez korporacje, niektóre akademickie, niektóre tylko osobiste raporty z eksperymentów.

Dostajemy również przyzwoity udział w badaniach porównawczych dotyczących skutków ubocznych języka programowania i jego narzędzi, takich jak:

• czasy budowy
• prawdopodobieństwo wykrycia błędu poprodukcyjnego,
• moc ekspresyjna,
• itp...

Jednak ostatnio coraz bardziej dziwi mnie zużycie pamięci przez moje programy bardziej niż cokolwiek innego. Może to wynikać z faktu, że chociaż prawo Moore'a jest po naszej stronie w kwestii surowej wydajności, zdaliśmy sobie sprawę, że inne wąskie gardła mają większe znaczenie. To, i nie mam tendencji do aktualizacji mojego sprzętu co jakiś czas, i mam trochę „starych” (czytaj Pentium 4 3.6GHz 2005-2006 z 4 GB pamięci RAM), które w dzisiejszych czasach są trudne do użycia w dużych aplikacjach bez wymagając ode mnie wielkiego wysiłku, aby wycisnąć z nich każdy kawałek soku (wybór systemu operacyjnego, interfejsu użytkownika, ulepszenie usług i demonów, wybór aplikacji do wykonania zadania lub innego ...). Szczerze mówiąc, czasami odpalam toplub procexppłaczę na widok pamięci wykorzystywanej przez najbardziej niewinne programy.

Mogę rozwiązać ten problem, pchając się w kierunku podanym powyżej i zasadniczo próbując ograniczyć siebie i programy, z których korzystam (chyba z tego powodu mam wielką miłość do programów cli), ale nie mogę się powstrzymać od myślenia że może robimy to źle.

Nowoczesne narzędzia dla współczesnych potrzeb

Oczywiście języki wyższego poziomu są prawdopodobnie lepsze i uzasadniają ich wartość ciężaru własnego. Pewnych wyborów projektowych dokonano wtedy z dobrych (lub podobno dobrze zaplanowanych) powodów, w wielu łańcuchach narzędzi. Współdzielone biblioteki, modele pamięci, procesory wstępne, systemy typów itp. Ale niektóre mogą być bardziej opłacalne niż inne dzięki naszemu nowoczesnemu sprzętowi i chętnie przeczytam kilka poważnych badań na ten temat.

Moje pytanie brzmi zatem: czy wisi w grze Benchmarks Game i innych, które koncentrują się na porównaniu podstawowego zużycia pamięci przez środowisko wykonawcze języków?

Co więcej, czy istnieją badania porównujące to z innymi parametrami (podobnie jak w tym artykule , na przykład w przypadku innych kryteriów, również opartych na grze Benchmarks )?

^{Znalazłem częściowe informacje, więc zacznę kompilować swoje ustalenia we własnej odpowiedzi. Nie pozwól, aby powstrzymało Cię to od przekazywania własnych odpowiedzi (lub edytowania tej).}

Istniejąca literatura:

• Empiryczne porównanie 7 języków programowania - Prechelt (2000) [ PDF ]

  Trochę przestarzały, ale obejmuje część materiału, który mnie interesuje, i daje pogląd na wykorzystanie pamięci ekspresyjnej i jej ekspresję. Wyniki mogą się znacznie różnić, ale jest to ciekawy początek.

• Szybkość, wielkość i niezawodność języków programowania - Marceau (2009) [ blog ]

• Używany kod, używane kształty czasu z gry Benchmarks [ u32 , u32q , u64 , u64q ]

  Chociaż nie obejmuje zużycia pamięci w czasie wykonywania, praca Marceau jest mniej więcej takim rodzajem referencji lub badań empirycznych, które chętnie znajdę dla tej krytyki pod względem treści i jakości. Dobry przykład tego, czego szukam, tylko dla różnych wskaźników. Drugi artykuł to kontynuacja znaleziona na stronie Benchmarks Game, która została opublikowana wkrótce po (i które zawiera odniesienia) pracy Marceau, z nowszymi ekranami i większą liczbą języków, choć wciąż bez szczegółów pamięci wykonawczej. Każdy wykres na tych stronach prowadzi następnie do języka-to-języka porównaniu która zrobienia zapewnić wysoki poziom informacji w pamięci chociaż.

To nie odpowiada na pytanie na słowo, ale może nieco zmienia perspektywę. Mam na myśli zapis z czatu, aby nadać ton temu komentarzowi, który z pewnością będzie przedmiotem wielu głosów negatywnych.

Są ludzie, dostawcy sprzętu, dostawcy narzędzi i programiści, którzy są zaniepokojeni wydajnością. Na razie będzie to coraz większy problem dla nich i dla nas wszystkich. Obawy te są zakorzenione w urządzeniach mobilnych, zwłaszcza w potworach o dużej mocy i pożeraniu baterii z największymi ekranami i najsilniejszymi radiotelefonami.

Cofnijmy się jeszcze raz, po części dlatego, że znaleźliśmy się w obecnej sytuacji, ze stosunkowo masywnymi ramami i lekkim lekceważeniem ogólnej wydajności, poza ulepszeniami sprzętowymi, jest dziedzictwem. Zgodność ze starszymi systemami utwierdza nas w zgodności oprócz kompatybilności. To nie tyle wina czasów najwyższego poziomu, że zasadniczo są one tym samym środowiskiem wykonawczym, działającym dość wydajnie i wydajnie, gdy są używane w innym środowisku operacyjnym (np. Xbox, Windows Mobile pre 7/8 / Surface, Java Framework itp.).

Porównaj zakres kompatybilności komputera stacjonarnego ze starszym oprogramowaniem z zakresem kompatybilności urządzenia mobilnego.

W przypadku urządzeń mobilnych producenci urządzeń dokładają starań, aby zapewnić pewną kompatybilność, ale nie uczynili kompatybilności podstawową podstawą. Gdy istnieje wybór między dalszym zapewnianiem zgodności a przenoszeniem projektu systemu mobilnego do przodu, system mobilny idzie do przodu.

W przypadku komputerów stacjonarnych wydaje się, że jest odwrotnie. Jeśli znacząca przełomowa zmiana trafi w marketerów lub pierwszych użytkowników w niewłaściwy sposób, wielokrotnie przesuwa potrzebne funkcje i przeprojektowanie na zapleczu. W pewnym momencie pamiętam plotki o tym, że my, użytkownicy systemu Windows, znajdziemy całkowicie i dramatycznie nowy system plików z Windows XP, potem w Vistę, później to samo dla Seven i wreszcie w Eight, ale nie, tylko stopniowo ulepszany od czasu po raz pierwszy widzieliśmy to w Windows2000? Nowy system plików długo siedział, został złomowany, a jakkolwiek pogłoski decydują później, nie mogę powiedzieć. To prawdopodobnie największy znany przypadek, ale jestem przekonany, że nie jest to jedyny duży przypadek.

Nawet w przypadku najnowszych tabletów i mobilnych systemów operacyjnych Microsoft, który niegdyś kształtował rynek, jest teraz spleciony w mecz śmierci nie tylko z konsumentami, ale także z cienia samego siebie z działu komputerów stacjonarnych. Tablet musiał znacznie współpracować z odpowiednikiem na komputery stacjonarne. Nie, nie mógł się z tym doskonale bawić, ze względu na różnice w architekturze, ale także z powodu archaicznego charakteru podstaw pulpitu, dokonał znacznych poświęceń.

Teraz z pewnością Windows jest łatwym celem do jakiejkolwiek krytyki w tej sytuacji, ale inne platformy są dalekie od „bez grzechu”. W ekosystemie Linuksa czai się wiele reliktów, które z pewnością powodują wielką konsternację dla systematycznych ulepszeń.

Ekonomia odgrywa dużą rolę w tym równaniu; sposób, w jaki finansujemy nasze komputery i aplikacje na jednym, oraz sposób, w jaki są one finansowane na drugim, jest zdumiewająco odmienny. Tam, gdzie Wintel silnie wpłynął na przestarzałość, Apple i Google zmieniły go w prawie ścisły harmonogram. To jest nieco poza kursem, niż zamierzałem, więc odejdę, gdy siedzi, i niech czytelnicy zabiorą go stamtąd.

Jeśli i kiedy duzi dostawcy zmienią swoje modele przestarzałości i ceny, mogą zacząć iść do przodu ze zmianami na większą skalę w bardziej wyrównanym tempie. Te frameworki najwyższego poziomu, które są obsługiwane przez języki najwyższego rzędu, będą się w pewien sposób kurczyć, ponieważ będą w stanie osiągnąć swoje zadanie na wysokim poziomie z bardziej niskopoziomową wydajnością, ponieważ nieefektywna pośrednia kompatybilność i warstwy niskiego poziomu będą zostać drastycznie zmniejszone, jeśli nie wyeliminowane.