W czym napisane programy są szybsze, zużywają mniej RAM-u(etc)?
W C# czy w C++?
Programy w C# używają pośrednio .NET Framework więc zużywają minimalnie więcej RAMu oraz są minimalnie wolniejsze przez to, jednak różnica nie jest odczuwalna
W C++ trzeba uwzględnić czy kompilujemy przez Visual C++ (wtedy będzie podobnie jak w C#) czy też G++ wtedy program będzie natywny i nie traci na szybkości oraz RAMie jednak tu też różnica jest bardzo znikoma
Najszybciej będą działały programy napisane w Asemblerze, potem w C i (podobno) Go. Ale jeżeli piszesz cokolwiek intensywnie działającego z bazą danych albo internetem (w dzisiejszych czasach tworzy się jeszcze inne aplikacje?), to użyty język prawie nie będzie miał znaczenia.
C++ pod Visualem też jest kompilowany do kodu natywnego. (Co innego C++/CLI)
No tak: IDE, kompilatory, systemy operacyjne, bazy danych (w sensie silniki), przeglądarki i wiele innych
To zależy od wielu czynników i umiejętności programistów. W uproszczeniu można powiedzieć, że pojedynczy algorytm zazwyczaj będzie szybszy w C++. Wielowarstwowy system bazodanowy będzie szybszy w C#. (No, i będzie działał.)
Ty wiesz w ogóle co to jest G++?
Kompilatorem używanym przez Visual Studio do C++ jest cl, pozwala on kompilować zarówno kod natywny jak i CLR (przy użyciu przełącznika /clr).
Przed chwilą stworzyłem dwa proste programy w C++ i w C#,
by sprawdzić który ma szybsze obliczanie działań, no i wygrało C#.
To trochę dziwne z tego co piszecie wynika że C++ ma szybsze obliczanie itp. a C# ma zwinniejszą bibliotekę.
Jest na to jakieś wytłumaczenie?
Programy:
Jest. Zapomniałeś o obliczeniach i nie potrafisz używać kompilatora.
Napisz kod, który będzie robił coś sensowniejszego niż wypisywanie do konsoli. Na przykład liczył wartość ciągu fibonacciego rekurencyjnie dla zadanego n, albo robił inne bardziej skomplikowane obliczenia. Jedyne działanie jakie jest w Twoim programie do dodawanie jedynki… Tak nie sprawdza się prędkości 
Nie wiem jak w C#, ale w C++ można przyspieszyć działanie programów przez samą organizację kodu np. w taki sposób aby odpowiednio korzystał z pamięci cache.
I do mierzenia czasu użyj mechanizmów języka, nie stopera 
Nie robi się tego też w w/w sposób. Są języki (głownie funkcyjne), które są wstanie same rozwikłać rekurencję ogonową (tu oczywiście skrót myślowy o kompilatorze). Są też takie, których filozofia głosi, że programista wie co robi.
Masz jakiś dowód, na to że nie potrafię używać kompilatora?
Bo jak na razie wywołujesz zamieszanie.
http://speedy.sh/YN3Tb/test.7z
Przykładowy test z liczeniem liczb Fibonacciego na liczbach 64-bit.
Po uruchomieniu trzeba podać 2 liczby: ile razy ma być liczona liczba Fibonacciego, i do której liczby liczyć.
Na wyjściu wypisuje jedną liczbę (można zignorować) i czas jaki trwały obliczenia.
cs.exe - kompilowany na Visual C# 2010, wymaga .NET 4 (nie programuję w C#, jak macie jakieś zastrzeżenia to piszcie
cpp.exe - kompilowany na Visual C++ 2010, 32-bit (spory rozmiar wynika z tego, że dałem statyczne linkowanie biblioteki standardowej, dałem też mniejszy cpp_.exe ale wymaga Visual 2010 Redistributable Package)
Oba programy w wersji Release.
Mogę zrobić test na którym C++ wychodzi gorzej niż Java i C#. Wystarczy nie włączać optymalizacji, w przypadku GCC: -O2. A ten test co dałeś to żadne porównanie, tylko pętla + wypisanie czegoś, zero obliczeń itd.
Nie wiem jak wygląda sprawa z C# i .NETem, bo bardziej interesuje mnie Java i JVM i sporo o tym czytałem. Platformy klasy JVM po prostu nie mogą być szybsze od kodu natywnego – same są nim ograniczone. Natomiast często JVM wypada szybciej od C++, gdy dochodzi konieczność zarządzania pamięcią: maszyna wirtualna po prostu robi to lepiej, w trakcie działania potrafi tak sobie ustawić kod, żeby jak najmniej skakać w pamięci, ma to oczywiście konsekwencje w postaci wolnego startu (dlatego też testowanie szybkości Javy poprzez zmierzenie czasu pierwszego wykonania algorytmu jest niemiarodajne – będzie do 20 razy wolniejszy niż kolejne wykonania).
W dzisiejszych czasach mamy takie procesory, że przez te kilka warstw abstrakcji nie ma znaczenia, różnice są na poziomie ułamków milisekund, czego nawet nikt nie odczuje, dopóki nie będzie musiał takiej skumulowanej na raz różnicy odczuć (np. renderowanie obrazu 3D).
Jak wspomniano: najszybciej byłoby w Assemblerze, ale nikt normalny nie kodzi w nim non stop, bo rozwój takiego kodu jest zbyt kosztowny i trudny. Są działy w których szybkość jest ważna, ale bez przesady.
A co niby JVM produkuje, jak nie kod natywny?
Kompilacja JIT może dawać wydajniejszy kod niż kompilacja statyczna, np. dlatego, że potrafi lepiej dostosować kod do maszyny na której pracuje w pełni wykorzystując zalety procesora. Poza tym, wie, które metody wirtualne nie są nigdzie przesłaniane, więc mogą zostać zinlinowane. Do tego JVM może dynamicznie profilować pracującą aplikację i rekompilować w celu poprawienia wydajności. I są jeszcze takie techniki jak Escape analysis, które pozwalają optymalizować alokację pamięci.
– Dodane 18.11.2013 (Pn) 20:15 –
Tak to niestety jest ze sztucznymi benchmarkami, że zawierają kod, który nie ma sensu:
for(int i = 0; i < a; ++i)
y += test(x);
I taki kod zostanie skompilowany w C#, metoda “test” faktycznie zostanie wywołana a razy. Natomiast kompilator C++ skompiluje tak naprawdę taki kod:
long long foo = test(x);
for(int i = 0; i < a; ++i)
y += foo;
Dlatego ten test jest niemiarodajny. Jeśli skompilujemy powyższy kod w C#, to różnicy między oboma językami praktycznie nie będzie.