Ĺadny brzuch
Jak w temacie...
Nasłuchałem się ( naczytałem ) o szybkości działania programów pisanych pod różnymi językami,
jednak nie wiem co jest powodem tych różnic - kod i tak jest zamieniany na maszynowy więc
moim zdaniem wybór języka nie ma nic do rzeczy...
Prosze forumowiczów - rozwiejcie moje wątpliwości :)
c / c++ jest najszybsze, po pierwsze dlatego ze pozwala uzywac "sztuczek" ktore w innych jezykach sa niemozliwe, a po drugie dlatego ze wlasnie w c interpretacja kodu na kod maszynowy jest najbardziej wydajna, choc zeby to zobaczyc trzeba poznac sposob zapisywania danych w kompie. z drugiej strony nie sa to roznice klasy, ktore moznaby poczuc w normalnych programach :) (oprocz javy, w ktorej roznica jest bardzo duza)
I imho aplikacje pisane w językach skryptowych (interpretowanych), jak PHP czy Python działają szybciej.
Co do Javy, to są różne narzędzia optymalizacyjne.
Java jest taka wolna, bo jest kompilowana 'na żywca'. Co do C\C++ to nie wiem na czym polegają te sztuczki, ale fakt C\C++ jest szybsze od Delphi
I imho aplikacje pisane w językach skryptowych (interpretowanych), jak PHP czy Python działają szybciej.
jestes pewny?
moim zdaniem jest odwrotnie... kompilacja naturalnie trwa dluzej od interpretacji , ale jak juz program jest skompilowany, to dziala szybciej od takiego, ktorego trzeba jeszcze interpretowac...
jestes pewny?
moim zdaniem jest odwrotnie... kompilacja naturalnie trwa dluzej od interpretacji , ale jak juz program jest skompilowany, to dziala szybciej od takiego, ktorego trzeba jeszcze interpretowac...
no wlasnie, Coldpeer, cos mieszasz :P jezyk interpretowany zawsze bedzie dzialal wolniej, bo musi byc zamieniany na kod maszynowy na biezaco
Blah, moja gafa :P
Niby sie przyjelo ze c/c++ sa najszybsze, ale moim zdaniem to zalezy od kompilatora. Bo trudno mi uwierzyc ze program skompilowany w Borland C++ Builder razem ze wszystkimi bajerami pokroju VCL bedzie dzialal szybciej niz analogiczny zrobiony w delphi.
Zalezy to tez, mysle, w glownej mierze od optymalizacji kodu, bo kompilator kompilatorem, jezyk jezykiem, a to programista jest z tego tridemu najwieksza fujara. ;)
Na pewno doswiadczony programista zrobi szybszy program w delphi niz poczatkujacy w c/c++.
Wszystko zależy od kompilatora. Może Ci kompilator C++ wygenerować kompletnie nieoptymalny kod a może Ci też superszybki wygenerować. Najszybsze programy powstają w assemblerze. Dlaczego? Ponieważ w asmie jedna instrukcja to jedna instrukcja procesora i optymalny kod asma zawsze będzie szybszy od najoptymalniejszego kodu c++.
Niby sie przyjelo ze c/c++ sa najszybsze, ale moim zdaniem to zalezy od kompilatora. Bo trudno mi uwierzyc ze program skompilowany w Borland C++ Builder razem ze wszystkimi bajerami pokroju VCL bedzie dzialal szybciej niz analogiczny zrobiony w delphi.
VCL jest wolne, jak i niemal wszystkie RADy :) ale mowiac "szybki" nie oceniamy konkretnych bibliotek (bo w kazdym jezyku moga byc szybsze i wolniejsze, a przeciez "delphi" to nie tylko VCL) tylko szybkosci kodu wynikowego, i sprawnosci w automatycznej optymilizacji go przez kompilator. niektorzy w ogole nie zdaja sobie sprawy ze jezyk to nie sama skladnia, ale tez implementacja tej skladni w kodzie maszynowym - kazdy jezyk ma dokladnie okreslone (choc oczywiscie sa roznice, szczegolnie w c) jak tlumaczy dana instrukcje , i nie zmienia sie to w roznych kompilatorach tego samego jezyka (choc oczywiscie dochodza optymilizacje, uzycie instrukcji charakterystycznych dla danych prockow itd. - wiec roznice sa, ale na pewno mniejsze w obrebie jednego jezyka niz roznych).
Zalezy to tez, mysle, w glownej mierze od optymalizacji kodu
jasne, optymilizujac mozna uzyskac duzo wieksze przyspieszenie niz przesiadajac sie z jednego jezyka na drugi :)
c / c++ jest najszybsze, po pierwsze dlatego ze pozwala uzywac "sztuczek" ktore w innych jezykach sa niemozliwe Przykład? Podaj kod.
jasne, optymilizujac mozna uzyskac duzo wieksze przyspieszenie niz przesiadajac sie z jednego jezyka na drugi :)
Jednocześnie może Twój kod zadziałać zupełnie inaczej niż byś tego chciał.
w c jest lepszy, szybszy (ale niebezpieczny) dostęp do pamięci.
Mnie ciekawi jak ma się do szybkości napisanie programu strukturalnie vs. objektowo...
Przykład? Podaj kod.
najprostszy - inkrementacja. najbardziej optymalna metoda inkrementacji w delphi jest inc(), ale to jest procedura i nie mozna jej uzyc np. w ifie, wiec trzeba osobno zwiekszyc i porownywac, w c bez problemu mozna if ++i>0 {} i tak bedzie bardziej optymalnie.
Radek - jesli nie uzywac polimorfizmu szybkosc jest porownywalna.
LLP_33- optymilizacja polega na modyfikowaniu kodu nie zmieniajac efektow jego dzialania - jak ktos tego nie umie, to lepiej niech nie robi :P ale rownie dobrze mozna popelnic bledy piszac program niezoptymilizowany ;)
Użytkownik Deadeye edytował ten post 26 styczeń 2007, 00:21
Mnie ciekawi jak ma się do szybkości napisanie programu strukturalnie vs. objektowo...
Poczytaj, jakie były podstawowe założenia projektantów C++.
Czas kompilacji na pewno wzrośnie ponieważ parser i skaner będzie miał dużo więcej do roboty.
LLP_33- optymilizacja polega na modyfikowaniu kodu nie zmieniajac efektow jego dzialania - jak ktos tego nie umie, to lepiej niech nie robi tongue.gif ale rownie dobrze mozna popelnic bledy piszac program niezoptymilizowany wink2.gif
Współczesne optymalizatory bazują na algorytmach heurystycznych bądź na algorytmach bazujących na przykładach. To już powinno Ci coś mówić. Pokaż mi kompilatory zawierające mechanizmy superoptymalizatora i pokaż mi człowieka, który podda swój normalny program pełnej-gwarantowanej optymalizacji.
Zresztą optymalizator to program napisany przez człowieka, który nie myśli tylko posługuje się pewnymi schematami. Ma zapisane pewne mechanizmy optymalizacji, jak zwijanie stałych, indukcja czy niezamienniki pętli. Jednak on popełnia błędy, gdy zbyt mocno chcemy wychudzić program. Podobna jest sytuacja z walidatorami w3c. Teoretycznie działają ok, jednak idzie je zmylić i całkowicie poprawną stronę uznają Ci za błędną.
Użytkownik LLP_33 edytował ten post 26 styczeń 2007, 00:40
najprostszy - inkrementacja. najbardziej optymalna metoda inkrementacji w delphi jest inc(), ale to jest procedura i nie mozna jej uzyc np. w ifie, wiec trzeba osobno zwiekszyc i porownywac, w c bez problemu mozna if ++i>0 {} i tak bedzie bardziej optymalnie.
Uwazasz ze if ++i>0 ... bedzie szybsze od:
inc(i);
if i>0 ...
?
Mnie sie wydaje ze otrzymasz dokladnie to samo... Jedynie zapis jest troche dluzszy, ale kod nie.
Użytkownik Ali240 edytował ten post 26 styczeń 2007, 01:27
najprostszy - inkrementacja. najbardziej optymalna metoda inkrementacji w delphi jest inc(), ale to jest procedura i nie mozna jej uzyc np. w ifie, wiec trzeba osobno zwiekszyc i porownywac, w c bez problemu mozna if ++i>0 {} i tak bedzie bardziej optymalnie. 1. Nie wiem, jak inc() może być "najbardziej optymalną metodą inkrementacji", inc(i) i i:=i+1 daje ten sam kod. Co prawda można sobie taką funkcję napisać, ale Ty mówisz o jak najmniejszej ilości kodu, co nie przecież zawsze skutkuje szybszym jego wykonaniem :)
2. Ciekawostka:DELPHI: var i:integer; begin i:=1; inc(i); if i>0 then messagebox(0,'1','2',64); end; ASM: 0044D944 . B8 01000000 MOV EAX,1 0044D949 . 40 INC EAX 0044D94A . 85C0 TEST EAX,EAX 0044D94C . 7E 13 JLE SHORT Project1.0044D961 0044D94E . 6A 40 PUSH 40 ; /Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL 0044D950 . 68 64D94400 PUSH Project1.0044D964 ; |Title = "2" 0044D955 . 68 68D94400 PUSH Project1.0044D968 ; |Text = "1" 0044D95A . 6A 00 PUSH 0 ; |hOwner = NULL 0044D95C . E8 378BFBFF CALL <JMP.&user32.MessageBoxA> ; \MessageBoxA 29 bajtówCPP (BCB) (full release): int i=1; if (++i>0) MessageBox(0,"1","2",64); 0040198C > . B8 01000000 MOV EAX,1 00401991 . 40 INC EAX 00401992 . 85C0 TEST EAX,EAX 00401994 . 7E 13 JLE SHORT Project1.004019A9 00401996 . 6A 40 PUSH 40 ; /Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL 00401998 . 68 92F14500 PUSH Project1.0045F192 ; |Title = "2" 0040199D . 68 90F14500 PUSH Project1.0045F190 ; |Text = "1" 004019A2 . 6A 00 PUSH 0 ; |hOwner = NULL 004019A4 . E8 31D30500 CALL <JMP.&USER32.MessageBoxA> ; \MessageBoxA 29 bajtówCPP (DEV-CPP): jw. 004013BA |. C745 FC 01000000 MOV DWORD PTR SS:[EBP-4],1 ; | 004013C1 |. 8D45 FC LEA EAX,DWORD PTR SS:[EBP-4] ; | 004013C4 |. FF00 INC DWORD PTR DS:[EAX] ; | 004013C6 |. 837D FC 00 CMP DWORD PTR SS:[EBP-4],0 ; | 004013CA |. 7E 27 JLE SHORT Project1.004013F3 ; | 004013CC |. C74424 0C 40000000 MOV DWORD PTR SS:[ESP+C],40 ; | 004013D4 |. C74424 08 00004400 MOV DWORD PTR SS:[ESP+8],Project1.004400>; | 004013DC |. C74424 04 02004400 MOV DWORD PTR SS:[ESP+4],Project1.004400>; | 004013E4 |. C70424 00000000 MOV DWORD PTR SS:[ESP],0 ; | 004013EB |. E8 F0F40000 CALL <JMP.&USER32.MessageBoxA> ; \MessageBoxA 49 bajtów
podgląd asma w wydaniu borlanda, jest taki jakiś ubogi :D
czy ja dobrze widzę?:
jeśli chodzi o inkrementację to dev robi to na stosie, a borland w rejestrze... ciekawe...
dalej to praktycznie to samo, tylko że dev ładuje stos jakoś tak od tyłu tzn.. z dołu do góry?
ten TEST EAX,EAX nie daje mi spokoju...
sprawdza on czy i==i a potem robi skok jeżeli 'i' jest mniejszy lub równy? Czy mi sie zdaje, czy borland się tu wspina na wyżyny optymalizacji :roll1: równie dobrze można by było wyciąć pierwsze 3 linijki a potem dać tylko JMP...
kurde już 4:30, pewnie coś porąbałem ze zmęczenia...
Ale tak się tego czepiłem, bo mi kiedyś wychodziło w delph, że dzielenie float i zaokrąglenie jes szybsze od zwykłego dzielenia. Tylko jak potem zajżałem do asma to zobaczyłem, że delphi mi połowe kodu wywalił, bo dzieliłem w pętli tą samą liczbe, więc poprostu w optymalizacji delphik wstawił sobie stałą :chair:
Użytkownik Radek edytował ten post 26 styczeń 2007, 04:38
Co do wyższości skryptów nad programami to brechtam. W końcu coś musi przetworzyć skrypt, żeby sie wykonał. Dwa procesy vs. jeden... Lol...
Najszybszy jest rzeczywiście assembler, ale C z tych "lżejszych" jest najszybszy. Dlaczemu? Nie ma dużo funkcji wewnętrznych i jest w miare bliski assemblerowi. W miare bliski, ale nie za bliski. :P
Nie wiem czy to nie będzie odbiegało zbyt od tematu, ale możliwe, że ma jakiś związęk, a więc:
Dlaczego systemy operacyjne piszę się w C i asm(to wiadomo) a nie w C++ i asm? W czym C++ jest gorsze od C? Chodzi o tą piekelną szybkość:P ?
Nie znam się za bardzo, ale napiszę moje wyobrażenie. Raz, to to, że C jest szybsze, dwa to to, że nie ma za bardzo sensu pisać w C++, gdyż jakieś bajery z STL-a, czy strumienie za bardzo Ci się nie przydadzą. Ponadto większość z nich bazuje na mechanizmach z C. C ma także łatwiejsze zarządzanie pamięcią.
Można napisać system w C++
ten TEST EAX,EAX nie daje mi spokoju...
sprawdza on czy i==i a potem robi skok jeżeli 'i' jest mniejszy lub równy? Czy mi sie zdaje, czy borland się tu wspina na wyżyny optymalizacji :roll1: równie dobrze można by było wyciąć pierwsze 3 linijki a potem dać tylko JMP... TEST służy do sprawdzenia (nie porównania) danej, po tym ustawia odpowiednią flagę wykorzystywaną przez jump'a (JLE).
Tak dla niewtajemniczonych - to był OllyDbg :P
Oczywiście najmniej zajmuje ten kod:33C0 XOR EAX,EAX 40 INC EAX 40 INC EAX 85C0 TEST EAX,EAX 7E 13 JLE SHORT Project1.0044DBC6 6A 40 PUSH 40 68 84DB4400 PUSH Project1.0044DB84 68 86DB4400 PUSH Project1.0044DB86 6A 00 PUSH 0 E8 45299277 CALL user32.MessageBoxA27 bajtów ;)
@ Cyrkiel: W Dev'ie posługiwałeś się MinGW? Pamiętasz mój topic o UkrywaczuNeo? DevCpp wygenerował kod z 1,5 raza większy niż VCToolkit.
Jak widzę, że C++ to "bajery z STL", które się nie przydadzą, to nóż się w kieszeni otwiera. W programach typu "Hello, world" się nie przydadzą, ale tam, gdzie trzeba mieć koniecznie obiektową architekturę C++ jest świetne. Coldpeer, zobacz np. silnik Quake'a 3 a jego wersję pod C++ - DXQuake3. Który kod jest bardzie zrozumiały i lepszy w użyciu? A propos STL - w C musisz deklarować rozmiar tablicy jako stałą i przewidywac go z góry, a w C++ masz wygodny i zoptymalizowany kontener Vector z STL. W razie problemów możesz uzywac kontenerów z Boost, nawet nie martwiąc się o to, co jest "w środku" - to właśnie enkapsulacja, wspaniałe narzędzie z C++.
Co do inkrementacji. W Pascalu jest tak:
i:=i+1;
Wygląda na to, że program tworzy pomocniczą zmienną i przypisuje ją dopiero do lewej strony. Nie lepiej po protu
i++;
?
Cyrkiel: ja wiem że TEST ustawia flagi, ale dlaczego porównuje eax z eax'em (czy i > i?)?
W zasadzie i "i:=1" i "0" to są stałe, które powinien wywalić, bo nic z tego nie wynika w przykładzie...
//edit: dobra już wiem co z tym testem: jak eax jest zero to wtedy flaga będzie zero
MZet: to własnie dobry przykład, dlaczego zazwyczaj do pisania systemu operacyjnego używa się c a nie cpp
W razie problemów możesz uzywac kontenerów z Boost, nawet nie martwiąc się o to, co jest "w środku"
i potem przypadkiem nadpisać sobie pamięć jakimś sterownikiem przykładowo. To jest właśnie wtedy problem, że nie wiadomo co jest w środku...
Co do inkrementacji: wcześniej ktoś napisał, że inc() to funkcja (procedura?) czyli powinna wykonywać "w środku"
i:=i+1 z pomocniczą zmienną, ale na kodzie z debugera widać, że i tak w asmie to wygląda tak:
INC EAX więc jest tak samo jak w c czyli i++
Użytkownik Radek edytował ten post 26 styczeń 2007, 17:41
Co do asm, wcale nie musi być najszybsze - to już CAŁKOWICIE zależy od programisty, czasem na tak niskim poziomie można więcej namieszać niż zrobil by to jakiś kompilator np. C++. Dużo zależy od kompilatora i od programisty, język już nie ma chyba tak wielkiego znaczenia (nie uwzgleniajac skryptow - ktore rzeczywiscie sa wolniejsze)
ale tu mówimy o "zoptymalizowanym" asmie
A co powiecie o dotNecie? Szybszy od Java, czy też nie? W sumie dość podobne zasady działania mają...
Można napisać system w C++ Rownie dobrze i w pascalu. ;)
fenekpl - ale zes temat zrobil. :P Â Wojna na jezyki. ;)
hehe tylko zeby nie przyszlo Ci do glowy zalozyc tematu "Delphi czy C++" bo będzie prawdziwy sajgon:P
Tak, a prawda jest taka, że z reguły dobry programista napisze dobry kod bez znaczenia języka.
Rownie dobrze i w pascalu. ;)
W tych językach, które umożliwiają wstawki assemblera i są kompilowane do kodu maszynowego można napisać pseudo-system.
A co powiecie o dotNecie? Szybszy od Java, czy też nie? W sumie dość podobne zasady działania mają...
Hmm... wlasciwie to sie zdziwilem, bo C# jest dość szybki ... bawilem sie nawet irrlichtem .NET i jakoś tak bardzo nie muliło, spokojnie nawet gre 3D mozna na tym zrobic.
Heh, teoretycznie to i kod wynikowy C++ moze byc tak szybki jak zoptymalizowany asm. Ale to kwetsia kompilatora nie jezyka... popieram w 100% wypowiedź p1101.
@dół: dlatego napisalem "teoretycznie" - gdyby istniał kompilator "doskonały". ...
Użytkownik icek edytował ten post 26 styczeń 2007, 22:21
Heh, teoretycznie to i kod wynikowy C++ moze byc tak szybki jak zoptymalizowany asm. Ale to kwetsia kompilatora nie jezyka...
Heh jeżeli poddasz swój kod 100% i gwarantowanej optymalizacji może i otrzymasz identycznie szybkie kody. Jednak uwierz mi, że nie poddasz.
pozwólcie , że zapytam, bo nie miałem jeszcze okazji pracować z C#.. on również jest kompilowany "na bieżąco"?
Użytkownik Ka-lolek edytował ten post 26 styczeń 2007, 22:55
Ka-lolek: nie, programy napisane w C# kompilowane są do kodu pośredniego afaik IL.
BTW: kompilowany na bieżąco? Chyba interpretowany :)
BTW: pisze się "bieżąco"
fakt, rozpedzilem sie;P poprawione:)
i później ten IL jest interpretowany przez wirtualną maszynę "Ce Płot" ?
Jakoś tak to wygląda. :)
PS. "si szarp" ;)
płot też może być
http://pl.wikipedia.org/wiki/C_Sharp
tak swojsko brzmi... ;)
zanotowane.pl doc.pisz.pl pdf.pisz.pl zsf.htw.pl
Nasłuchałem się ( naczytałem ) o szybkości działania programów pisanych pod różnymi językami,
jednak nie wiem co jest powodem tych różnic - kod i tak jest zamieniany na maszynowy więc
moim zdaniem wybór języka nie ma nic do rzeczy...
Prosze forumowiczów - rozwiejcie moje wątpliwości :)
c / c++ jest najszybsze, po pierwsze dlatego ze pozwala uzywac "sztuczek" ktore w innych jezykach sa niemozliwe, a po drugie dlatego ze wlasnie w c interpretacja kodu na kod maszynowy jest najbardziej wydajna, choc zeby to zobaczyc trzeba poznac sposob zapisywania danych w kompie. z drugiej strony nie sa to roznice klasy, ktore moznaby poczuc w normalnych programach :) (oprocz javy, w ktorej roznica jest bardzo duza)
I imho aplikacje pisane w językach skryptowych (interpretowanych), jak PHP czy Python działają szybciej.
Co do Javy, to są różne narzędzia optymalizacyjne.
Java jest taka wolna, bo jest kompilowana 'na żywca'. Co do C\C++ to nie wiem na czym polegają te sztuczki, ale fakt C\C++ jest szybsze od Delphi
I imho aplikacje pisane w językach skryptowych (interpretowanych), jak PHP czy Python działają szybciej.
jestes pewny?
moim zdaniem jest odwrotnie... kompilacja naturalnie trwa dluzej od interpretacji , ale jak juz program jest skompilowany, to dziala szybciej od takiego, ktorego trzeba jeszcze interpretowac...
jestes pewny?
moim zdaniem jest odwrotnie... kompilacja naturalnie trwa dluzej od interpretacji , ale jak juz program jest skompilowany, to dziala szybciej od takiego, ktorego trzeba jeszcze interpretowac...
no wlasnie, Coldpeer, cos mieszasz :P jezyk interpretowany zawsze bedzie dzialal wolniej, bo musi byc zamieniany na kod maszynowy na biezaco
Blah, moja gafa :P
Niby sie przyjelo ze c/c++ sa najszybsze, ale moim zdaniem to zalezy od kompilatora. Bo trudno mi uwierzyc ze program skompilowany w Borland C++ Builder razem ze wszystkimi bajerami pokroju VCL bedzie dzialal szybciej niz analogiczny zrobiony w delphi.
Zalezy to tez, mysle, w glownej mierze od optymalizacji kodu, bo kompilator kompilatorem, jezyk jezykiem, a to programista jest z tego tridemu najwieksza fujara. ;)
Na pewno doswiadczony programista zrobi szybszy program w delphi niz poczatkujacy w c/c++.
Wszystko zależy od kompilatora. Może Ci kompilator C++ wygenerować kompletnie nieoptymalny kod a może Ci też superszybki wygenerować. Najszybsze programy powstają w assemblerze. Dlaczego? Ponieważ w asmie jedna instrukcja to jedna instrukcja procesora i optymalny kod asma zawsze będzie szybszy od najoptymalniejszego kodu c++.
Niby sie przyjelo ze c/c++ sa najszybsze, ale moim zdaniem to zalezy od kompilatora. Bo trudno mi uwierzyc ze program skompilowany w Borland C++ Builder razem ze wszystkimi bajerami pokroju VCL bedzie dzialal szybciej niz analogiczny zrobiony w delphi.
VCL jest wolne, jak i niemal wszystkie RADy :) ale mowiac "szybki" nie oceniamy konkretnych bibliotek (bo w kazdym jezyku moga byc szybsze i wolniejsze, a przeciez "delphi" to nie tylko VCL) tylko szybkosci kodu wynikowego, i sprawnosci w automatycznej optymilizacji go przez kompilator. niektorzy w ogole nie zdaja sobie sprawy ze jezyk to nie sama skladnia, ale tez implementacja tej skladni w kodzie maszynowym - kazdy jezyk ma dokladnie okreslone (choc oczywiscie sa roznice, szczegolnie w c) jak tlumaczy dana instrukcje , i nie zmienia sie to w roznych kompilatorach tego samego jezyka (choc oczywiscie dochodza optymilizacje, uzycie instrukcji charakterystycznych dla danych prockow itd. - wiec roznice sa, ale na pewno mniejsze w obrebie jednego jezyka niz roznych).
Zalezy to tez, mysle, w glownej mierze od optymalizacji kodu
jasne, optymilizujac mozna uzyskac duzo wieksze przyspieszenie niz przesiadajac sie z jednego jezyka na drugi :)
c / c++ jest najszybsze, po pierwsze dlatego ze pozwala uzywac "sztuczek" ktore w innych jezykach sa niemozliwe Przykład? Podaj kod.
jasne, optymilizujac mozna uzyskac duzo wieksze przyspieszenie niz przesiadajac sie z jednego jezyka na drugi :)
Jednocześnie może Twój kod zadziałać zupełnie inaczej niż byś tego chciał.
w c jest lepszy, szybszy (ale niebezpieczny) dostęp do pamięci.
Mnie ciekawi jak ma się do szybkości napisanie programu strukturalnie vs. objektowo...
Przykład? Podaj kod.
najprostszy - inkrementacja. najbardziej optymalna metoda inkrementacji w delphi jest inc(), ale to jest procedura i nie mozna jej uzyc np. w ifie, wiec trzeba osobno zwiekszyc i porownywac, w c bez problemu mozna if ++i>0 {} i tak bedzie bardziej optymalnie.
Radek - jesli nie uzywac polimorfizmu szybkosc jest porownywalna.
LLP_33- optymilizacja polega na modyfikowaniu kodu nie zmieniajac efektow jego dzialania - jak ktos tego nie umie, to lepiej niech nie robi :P ale rownie dobrze mozna popelnic bledy piszac program niezoptymilizowany ;)
Użytkownik Deadeye edytował ten post 26 styczeń 2007, 00:21
Mnie ciekawi jak ma się do szybkości napisanie programu strukturalnie vs. objektowo...
Poczytaj, jakie były podstawowe założenia projektantów C++.
Czas kompilacji na pewno wzrośnie ponieważ parser i skaner będzie miał dużo więcej do roboty.
LLP_33- optymilizacja polega na modyfikowaniu kodu nie zmieniajac efektow jego dzialania - jak ktos tego nie umie, to lepiej niech nie robi tongue.gif ale rownie dobrze mozna popelnic bledy piszac program niezoptymilizowany wink2.gif
Współczesne optymalizatory bazują na algorytmach heurystycznych bądź na algorytmach bazujących na przykładach. To już powinno Ci coś mówić. Pokaż mi kompilatory zawierające mechanizmy superoptymalizatora i pokaż mi człowieka, który podda swój normalny program pełnej-gwarantowanej optymalizacji.
Zresztą optymalizator to program napisany przez człowieka, który nie myśli tylko posługuje się pewnymi schematami. Ma zapisane pewne mechanizmy optymalizacji, jak zwijanie stałych, indukcja czy niezamienniki pętli. Jednak on popełnia błędy, gdy zbyt mocno chcemy wychudzić program. Podobna jest sytuacja z walidatorami w3c. Teoretycznie działają ok, jednak idzie je zmylić i całkowicie poprawną stronę uznają Ci za błędną.
Użytkownik LLP_33 edytował ten post 26 styczeń 2007, 00:40
najprostszy - inkrementacja. najbardziej optymalna metoda inkrementacji w delphi jest inc(), ale to jest procedura i nie mozna jej uzyc np. w ifie, wiec trzeba osobno zwiekszyc i porownywac, w c bez problemu mozna if ++i>0 {} i tak bedzie bardziej optymalnie.
Uwazasz ze if ++i>0 ... bedzie szybsze od:
inc(i);
if i>0 ...
?
Mnie sie wydaje ze otrzymasz dokladnie to samo... Jedynie zapis jest troche dluzszy, ale kod nie.
Użytkownik Ali240 edytował ten post 26 styczeń 2007, 01:27
najprostszy - inkrementacja. najbardziej optymalna metoda inkrementacji w delphi jest inc(), ale to jest procedura i nie mozna jej uzyc np. w ifie, wiec trzeba osobno zwiekszyc i porownywac, w c bez problemu mozna if ++i>0 {} i tak bedzie bardziej optymalnie. 1. Nie wiem, jak inc() może być "najbardziej optymalną metodą inkrementacji", inc(i) i i:=i+1 daje ten sam kod. Co prawda można sobie taką funkcję napisać, ale Ty mówisz o jak najmniejszej ilości kodu, co nie przecież zawsze skutkuje szybszym jego wykonaniem :)
2. Ciekawostka:DELPHI: var i:integer; begin i:=1; inc(i); if i>0 then messagebox(0,'1','2',64); end; ASM: 0044D944 . B8 01000000 MOV EAX,1 0044D949 . 40 INC EAX 0044D94A . 85C0 TEST EAX,EAX 0044D94C . 7E 13 JLE SHORT Project1.0044D961 0044D94E . 6A 40 PUSH 40 ; /Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL 0044D950 . 68 64D94400 PUSH Project1.0044D964 ; |Title = "2" 0044D955 . 68 68D94400 PUSH Project1.0044D968 ; |Text = "1" 0044D95A . 6A 00 PUSH 0 ; |hOwner = NULL 0044D95C . E8 378BFBFF CALL <JMP.&user32.MessageBoxA> ; \MessageBoxA 29 bajtówCPP (BCB) (full release): int i=1; if (++i>0) MessageBox(0,"1","2",64); 0040198C > . B8 01000000 MOV EAX,1 00401991 . 40 INC EAX 00401992 . 85C0 TEST EAX,EAX 00401994 . 7E 13 JLE SHORT Project1.004019A9 00401996 . 6A 40 PUSH 40 ; /Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL 00401998 . 68 92F14500 PUSH Project1.0045F192 ; |Title = "2" 0040199D . 68 90F14500 PUSH Project1.0045F190 ; |Text = "1" 004019A2 . 6A 00 PUSH 0 ; |hOwner = NULL 004019A4 . E8 31D30500 CALL <JMP.&USER32.MessageBoxA> ; \MessageBoxA 29 bajtówCPP (DEV-CPP): jw. 004013BA |. C745 FC 01000000 MOV DWORD PTR SS:[EBP-4],1 ; | 004013C1 |. 8D45 FC LEA EAX,DWORD PTR SS:[EBP-4] ; | 004013C4 |. FF00 INC DWORD PTR DS:[EAX] ; | 004013C6 |. 837D FC 00 CMP DWORD PTR SS:[EBP-4],0 ; | 004013CA |. 7E 27 JLE SHORT Project1.004013F3 ; | 004013CC |. C74424 0C 40000000 MOV DWORD PTR SS:[ESP+C],40 ; | 004013D4 |. C74424 08 00004400 MOV DWORD PTR SS:[ESP+8],Project1.004400>; | 004013DC |. C74424 04 02004400 MOV DWORD PTR SS:[ESP+4],Project1.004400>; | 004013E4 |. C70424 00000000 MOV DWORD PTR SS:[ESP],0 ; | 004013EB |. E8 F0F40000 CALL <JMP.&USER32.MessageBoxA> ; \MessageBoxA 49 bajtów
podgląd asma w wydaniu borlanda, jest taki jakiś ubogi :D
czy ja dobrze widzę?:
jeśli chodzi o inkrementację to dev robi to na stosie, a borland w rejestrze... ciekawe...
dalej to praktycznie to samo, tylko że dev ładuje stos jakoś tak od tyłu tzn.. z dołu do góry?
ten TEST EAX,EAX nie daje mi spokoju...
sprawdza on czy i==i a potem robi skok jeżeli 'i' jest mniejszy lub równy? Czy mi sie zdaje, czy borland się tu wspina na wyżyny optymalizacji :roll1: równie dobrze można by było wyciąć pierwsze 3 linijki a potem dać tylko JMP...
kurde już 4:30, pewnie coś porąbałem ze zmęczenia...
Ale tak się tego czepiłem, bo mi kiedyś wychodziło w delph, że dzielenie float i zaokrąglenie jes szybsze od zwykłego dzielenia. Tylko jak potem zajżałem do asma to zobaczyłem, że delphi mi połowe kodu wywalił, bo dzieliłem w pętli tą samą liczbe, więc poprostu w optymalizacji delphik wstawił sobie stałą :chair:
Użytkownik Radek edytował ten post 26 styczeń 2007, 04:38
Co do wyższości skryptów nad programami to brechtam. W końcu coś musi przetworzyć skrypt, żeby sie wykonał. Dwa procesy vs. jeden... Lol...
Najszybszy jest rzeczywiście assembler, ale C z tych "lżejszych" jest najszybszy. Dlaczemu? Nie ma dużo funkcji wewnętrznych i jest w miare bliski assemblerowi. W miare bliski, ale nie za bliski. :P
Nie wiem czy to nie będzie odbiegało zbyt od tematu, ale możliwe, że ma jakiś związęk, a więc:
Dlaczego systemy operacyjne piszę się w C i asm(to wiadomo) a nie w C++ i asm? W czym C++ jest gorsze od C? Chodzi o tą piekelną szybkość:P ?
Nie znam się za bardzo, ale napiszę moje wyobrażenie. Raz, to to, że C jest szybsze, dwa to to, że nie ma za bardzo sensu pisać w C++, gdyż jakieś bajery z STL-a, czy strumienie za bardzo Ci się nie przydadzą. Ponadto większość z nich bazuje na mechanizmach z C. C ma także łatwiejsze zarządzanie pamięcią.
Można napisać system w C++
ten TEST EAX,EAX nie daje mi spokoju...
sprawdza on czy i==i a potem robi skok jeżeli 'i' jest mniejszy lub równy? Czy mi sie zdaje, czy borland się tu wspina na wyżyny optymalizacji :roll1: równie dobrze można by było wyciąć pierwsze 3 linijki a potem dać tylko JMP... TEST służy do sprawdzenia (nie porównania) danej, po tym ustawia odpowiednią flagę wykorzystywaną przez jump'a (JLE).
Tak dla niewtajemniczonych - to był OllyDbg :P
Oczywiście najmniej zajmuje ten kod:33C0 XOR EAX,EAX 40 INC EAX 40 INC EAX 85C0 TEST EAX,EAX 7E 13 JLE SHORT Project1.0044DBC6 6A 40 PUSH 40 68 84DB4400 PUSH Project1.0044DB84 68 86DB4400 PUSH Project1.0044DB86 6A 00 PUSH 0 E8 45299277 CALL user32.MessageBoxA27 bajtów ;)
@ Cyrkiel: W Dev'ie posługiwałeś się MinGW? Pamiętasz mój topic o UkrywaczuNeo? DevCpp wygenerował kod z 1,5 raza większy niż VCToolkit.
Jak widzę, że C++ to "bajery z STL", które się nie przydadzą, to nóż się w kieszeni otwiera. W programach typu "Hello, world" się nie przydadzą, ale tam, gdzie trzeba mieć koniecznie obiektową architekturę C++ jest świetne. Coldpeer, zobacz np. silnik Quake'a 3 a jego wersję pod C++ - DXQuake3. Który kod jest bardzie zrozumiały i lepszy w użyciu? A propos STL - w C musisz deklarować rozmiar tablicy jako stałą i przewidywac go z góry, a w C++ masz wygodny i zoptymalizowany kontener Vector z STL. W razie problemów możesz uzywac kontenerów z Boost, nawet nie martwiąc się o to, co jest "w środku" - to właśnie enkapsulacja, wspaniałe narzędzie z C++.
Co do inkrementacji. W Pascalu jest tak:
i:=i+1;
Wygląda na to, że program tworzy pomocniczą zmienną i przypisuje ją dopiero do lewej strony. Nie lepiej po protu
i++;
?
Cyrkiel: ja wiem że TEST ustawia flagi, ale dlaczego porównuje eax z eax'em (czy i > i?)?
W zasadzie i "i:=1" i "0" to są stałe, które powinien wywalić, bo nic z tego nie wynika w przykładzie...
//edit: dobra już wiem co z tym testem: jak eax jest zero to wtedy flaga będzie zero
MZet: to własnie dobry przykład, dlaczego zazwyczaj do pisania systemu operacyjnego używa się c a nie cpp
W razie problemów możesz uzywac kontenerów z Boost, nawet nie martwiąc się o to, co jest "w środku"
i potem przypadkiem nadpisać sobie pamięć jakimś sterownikiem przykładowo. To jest właśnie wtedy problem, że nie wiadomo co jest w środku...
Co do inkrementacji: wcześniej ktoś napisał, że inc() to funkcja (procedura?) czyli powinna wykonywać "w środku"
i:=i+1 z pomocniczą zmienną, ale na kodzie z debugera widać, że i tak w asmie to wygląda tak:
INC EAX więc jest tak samo jak w c czyli i++
Użytkownik Radek edytował ten post 26 styczeń 2007, 17:41
Co do asm, wcale nie musi być najszybsze - to już CAŁKOWICIE zależy od programisty, czasem na tak niskim poziomie można więcej namieszać niż zrobil by to jakiś kompilator np. C++. Dużo zależy od kompilatora i od programisty, język już nie ma chyba tak wielkiego znaczenia (nie uwzgleniajac skryptow - ktore rzeczywiscie sa wolniejsze)
ale tu mówimy o "zoptymalizowanym" asmie
A co powiecie o dotNecie? Szybszy od Java, czy też nie? W sumie dość podobne zasady działania mają...
Można napisać system w C++ Rownie dobrze i w pascalu. ;)
fenekpl - ale zes temat zrobil. :P Â Wojna na jezyki. ;)
hehe tylko zeby nie przyszlo Ci do glowy zalozyc tematu "Delphi czy C++" bo będzie prawdziwy sajgon:P
Tak, a prawda jest taka, że z reguły dobry programista napisze dobry kod bez znaczenia języka.
Rownie dobrze i w pascalu. ;)
W tych językach, które umożliwiają wstawki assemblera i są kompilowane do kodu maszynowego można napisać pseudo-system.
A co powiecie o dotNecie? Szybszy od Java, czy też nie? W sumie dość podobne zasady działania mają...
Hmm... wlasciwie to sie zdziwilem, bo C# jest dość szybki ... bawilem sie nawet irrlichtem .NET i jakoś tak bardzo nie muliło, spokojnie nawet gre 3D mozna na tym zrobic.
Heh, teoretycznie to i kod wynikowy C++ moze byc tak szybki jak zoptymalizowany asm. Ale to kwetsia kompilatora nie jezyka... popieram w 100% wypowiedź p1101.
@dół: dlatego napisalem "teoretycznie" - gdyby istniał kompilator "doskonały". ...
Użytkownik icek edytował ten post 26 styczeń 2007, 22:21
Heh, teoretycznie to i kod wynikowy C++ moze byc tak szybki jak zoptymalizowany asm. Ale to kwetsia kompilatora nie jezyka...
Heh jeżeli poddasz swój kod 100% i gwarantowanej optymalizacji może i otrzymasz identycznie szybkie kody. Jednak uwierz mi, że nie poddasz.
pozwólcie , że zapytam, bo nie miałem jeszcze okazji pracować z C#.. on również jest kompilowany "na bieżąco"?
Użytkownik Ka-lolek edytował ten post 26 styczeń 2007, 22:55
Ka-lolek: nie, programy napisane w C# kompilowane są do kodu pośredniego afaik IL.
BTW: kompilowany na bieżąco? Chyba interpretowany :)
BTW: pisze się "bieżąco"
fakt, rozpedzilem sie;P poprawione:)
i później ten IL jest interpretowany przez wirtualną maszynę "Ce Płot" ?
Jakoś tak to wygląda. :)
PS. "si szarp" ;)
płot też może być
http://pl.wikipedia.org/wiki/C_Sharp
tak swojsko brzmi... ;)