NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Pascal kontra C: Czy naprawdę C przewyższa czytelnością i wygodą w programowaniu?
Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next
J.F
Guest
Guest
Tue Jan 28, 2014 6:10 pm
Użytkownik "Zbych" napisał w wiadomości
W dniu 2014-01-27 23:45, J.F pisze:
Quote:
Ale w C jest de facto standard
pozwalający zrobić sporo niskopoziomowych rzeczy. Np:
/* Diable watchdog timer */
WDTCTL = WDTPW | WDTHOLD;
Akurat tu .. Pascala latwo rozszerzyc o operacje bitowe, zas C nie
gwarantuje jednolitej kompilacji powyzszego.
W obliczu roznych mozliwosci procesora i sprzetowych rejestrow nie
wiadomo jak C to skompiluje.
Akurat w tym przykładzie kompilator nie ma zbyt dużego wyboru i poza
zmianą sposobu adresacji rejestru nie może nic fikuśnego wygenerować.
Gorzej z konstrukcjami typu:
rejestr |= stała
rejestr &= stała
rejestr ^= stała
rejestr.bit = stała
Bo może się okazać że taka modyfikacja rejestru wcale nie jest
atomowa.
pozwalający zrobić sporo niskopoziomowych rzeczy. Np:
/* Diable watchdog timer */
WDTCTL = WDTPW | WDTHOLD;
Akurat tu .. Pascala latwo rozszerzyc o operacje bitowe, zas C nie
gwarantuje jednolitej kompilacji powyzszego.
W obliczu roznych mozliwosci procesora i sprzetowych rejestrow nie
wiadomo jak C to skompiluje.
Akurat w tym przykładzie kompilator nie ma zbyt dużego wyboru i poza
zmianą sposobu adresacji rejestru nie może nic fikuśnego wygenerować.
Gorzej z konstrukcjami typu:
rejestr |= stała
rejestr &= stała
rejestr ^= stała
rejestr.bit = stała
Bo może się okazać że taka modyfikacja rejestru wcale nie jest
atomowa.
Atomowe to jedno, ale to bodajze w '51 bylo ze dwa rejestry byly pod
tym samym adresem,
jeden do odczytu, drugi tylko do zapisu, ale instrukcje typu
OR/AND/XOR stala
odczytywaly ten do do zapisu.
A jak to C skompiluje - nie wiadomo.
Nie wiadomo tez w jakiej kolejnosci bedzie wyrazenie obliczac i
rejestry czytac, a to moze byc istotne.
J.
A.L.
Guest
Guest
Wed Jan 29, 2014 2:22 am
On Tue, 28 Jan 2014 18:01:30 +0100, "J.F"
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Użytkownik "Piotr Gałka" napisał w wiadomości
Użytkownik "A.L." <alewando@aol.com> napisał w wiadomości
Do tego wlasnei sluzy C. C jest strukturalizowanym asemblerem
Czasem brakuje mi w C dostępu do bitu przeniesienia.
A może jest tylko ja nie wiem ?
Nie ma, bo to wbrew pozorom nie assembler.
No, sa wstawki assemblerowe, da sie to zrobic, ale to juz trzeba
wiecej instrukcji napisac, bo inaczej nie wiadomo jak sie wczesniejsze
skompilowalo.
Użytkownik "A.L." <alewando@aol.com> napisał w wiadomości
Do tego wlasnei sluzy C. C jest strukturalizowanym asemblerem
Czasem brakuje mi w C dostępu do bitu przeniesienia.
A może jest tylko ja nie wiem ?
Nie ma, bo to wbrew pozorom nie assembler.
No, sa wstawki assemblerowe, da sie to zrobic, ale to juz trzeba
wiecej instrukcji napisac, bo inaczej nie wiadomo jak sie wczesniejsze
skompilowalo.
Wstawi asemblerowe to sie robilo 30 lat temu. Dzisiaj praktyka mowi
aby napisac procedure w asemblezre i wolac jja z C
A.L.
Marek
Guest
Guest
Wed Jan 29, 2014 9:42 am
On Tue, 28 Jan 2014 19:22:21 -0600, A.L. <alewando@aol.com> wrote:
Quote:
Wstawi asemblerowe to sie robilo 30 lat temu. Dzisiaj praktyka mowi
aby napisac procedure w asemblezre i wolac jja z C
aby napisac procedure w asemblezre i wolac jja z C
Przecież procedura w asm to właśnie wstawka... czy chodzi o gołą
procedurę asm w pliku zew. (.S ) i później linkowaną z funkcjami w
C?
Wstawka asm w funkcji C jest chyba bezpieczniejsza bo kompilator wm
zadba prolog i epilog funkcji...
--
Marek
Sebastian Biały
Guest
Guest
Wed Jan 29, 2014 5:50 pm
On 2014-01-27 00:36, stchebel@gmail.com wrote:
Quote:
A ileż się nasłuchałem, że w C da się zrobić to, czego w Pascalu się nie da.
Na uC w C da się zrobić wszystko a w Pascalu nic. Głównie dlatego że
wybór języka programowania przez rynek dawno został zrobiony i nie ma tu
żadnego sensownego argumentu. Po prostu *NIE* ma kompilatorów Pascala na
uC poza jakimś żałosnym hobbystycznym szumem, więc rozmowa na ten temat
jest czysto akademicka i nie ma praktycznego zastosowania jak również
wykazuje ukryte skłonności samobójcze kierownika potencjalnego projektu.
Guest
Wed Jan 29, 2014 7:39 pm
W dniu poniedziałek, 27 stycznia 2014 17:45:17 UTC-5 użytkownik J.F napisał:
Quote:
Użytkownik napisał w wiadomości grup
dyskusyjnych:3a3cc0cf-7519-4efc-b7a1-c307d18b9f33@googlegroups.com...
Pytasz się dlaczego wymyślono C. Proste, był potrzebny język
z nastepującymi własnościami:
- ma się dać kompilować głupim kompiltorem (pierwsza maszyna na
której
chodziło C mała w porównaniu z innymi uwczesnymi maszynami)
No, C i Pascal to mniej wiecej te same lata, a tych kombinacji w C
tyle, ze kompilator Pascala chyba znacznie prostszy.
dyskusyjnych:3a3cc0cf-7519-4efc-b7a1-c307d18b9f33@googlegroups.com...
Pytasz się dlaczego wymyślono C. Proste, był potrzebny język
z nastepującymi własnościami:
- ma się dać kompilować głupim kompiltorem (pierwsza maszyna na
której
chodziło C mała w porównaniu z innymi uwczesnymi maszynami)
No, C i Pascal to mniej wiecej te same lata, a tych kombinacji w C
tyle, ze kompilator Pascala chyba znacznie prostszy.
C i Pascal to duze uproszczenie w porównaniu z wcześnieszymi
PL/I czy Algolem 68. Ale nawet Pascal Wirtha zawiera parę
"ciekawych" konstrukcji:
- zwracanie wartosci przez przypizanie do nazwy funkcji (trzeba
rozróżniać zwracanie wwartości od wywołania rekursywnego)
- parametry przekazywane przez wartość i przez zmienną,
trzeba je rozróżniać, a przekazywanie przez zmienną wymaga
w praktyce żeby kompilator w środu miał operator adresu
- rekordy z wariantami, mają część stałą i zmienną, przy tym
pozwalają na dowolne zagnieżdżanie (co daje podobny efekt
jak anonimowe unie wprowadzone w latach 90 do niektórych
kompilatorów C)
- rekordy spakowane, użyteczność podobna do pół bitowych, ale
można napisać całą masę bezużytecznych deklaracji które
kompilator ma poprawnie obsłużyć.
- funkcje lokalne (mają dostęp do zmiennych otaczającej je
funkcji)
- skoki nielokalne (trzeba zwinąć stos wywołań)
- tablice konforemne, mają specjalną regułę przekazywania
jako parameter i wymagają wsparcia dla tablic zmiennej
wielkości
Wiele implementacji Pascala pomijało ważne własności
ale pełna implementacja byłaby bar
Quote:
- ma pozwalać na zwięzły i czytelny zapis programu
Juz chyba nie bylo co oszczedzac pojedynczych znakow, a i tak
najwiecej sie na wciecia tracilo
Brak instrukcji "with" w C troche utrudnia zwiezlosc.
Nietrywialne użycia "with" zastępuje operator adresu i wskaźniki.
Tak źe w sumie zysk dla Pascala raczej niewielki. Ja pisałem
sporo w Pascalu, a nie pamiętam czy kiedyś uzyłem "with".
Quote:
- pozwalać na otrzymanie w miarę wydajnego kodu wynikowego
Tego i Pascal nie wyklucza, no moze z wyjatkiem sprawdzania zakresow
tablic.
Pascal pozwala na wydajny kod jak masz optymalizator. Ale bez
optymalizatora kod wynikowy będzie gorszy niż z C,
Luke
Guest
Guest
Wed Jan 29, 2014 9:40 pm
Dnia 2014-01-27 23:45, Użytkownik J.F napisał:
Quote:
Trzeba przyznac ze skladnia C jest "bledogenna" - nawet doswiadczony
programista moze sie latwo pomylic.
programista moze sie latwo pomylic.
95% takich pomyłek wykrywa nawet gcc z włączonym odpowiednią opcją i
wyświetla warning ("upewnij się, czy na pewno tak chciałeś").
L.
Guest
Wed Jan 29, 2014 10:14 pm
W dniu środa, 29 stycznia 2014 11:50:02 UTC-5 użytkownik Sebastian Biały napisał:
Quote:
On 2014-01-27 00:36, stchebel@gmail.com wrote:
A ileż się nasłuchałem, że w C da się zrobić to, czego w Pascalu się nie da.
Na uC w C da się zrobić wszystko a w Pascalu nic. Głównie dlatego że
wybór języka programowania przez rynek dawno został zrobiony i nie ma tu
żadnego sensownego argumentu. Po prostu *NIE* ma kompilatorów Pascala na
uC poza jakimś żałosnym hobbystycznym szumem, więc rozmowa na ten temat
jest czysto akademicka i nie ma praktycznego zastosowania jak również
wykazuje ukryte skłonności samobójcze kierownika potencjalnego projektu.
A ileż się nasłuchałem, że w C da się zrobić to, czego w Pascalu się nie da.
Na uC w C da się zrobić wszystko a w Pascalu nic. Głównie dlatego że
wybór języka programowania przez rynek dawno został zrobiony i nie ma tu
żadnego sensownego argumentu. Po prostu *NIE* ma kompilatorów Pascala na
uC poza jakimś żałosnym hobbystycznym szumem, więc rozmowa na ten temat
jest czysto akademicka i nie ma praktycznego zastosowania jak również
wykazuje ukryte skłonności samobójcze kierownika potencjalnego projektu.
Obrazek nie jest tak zero-jedynkowy jak go przedstawiasz. Jest GNU Pascal
i na procki wspierarane przez odpowiednia wersje GNU C możesz zrobić
to co w C. Od paru lat nie jest rozwijany (zajęłem się czym innym)
ale wersje bazowane na GCC 3.x będą działać przez wiele lat.
Ty pewnie nie bierzesz GNU Pascala pod uwagę, ale ZCW był
(i prawdopodbnie jest) używany przez całkiem poważne projekty.
Jest też Free Pascal, nie wiem jak ze wsparciem mniejszych prockow,
ale większych ARM-ach da się podziałać.
Ja dziś uC programuję w C, ale nie robię jakiś super
poważnych projektów. W poważnym projekcie Pascal może
mieć zalety. Oczywiście trzeba brać pod uwagę wiele
czynników i szanasa że Pascal będzie najlepszy jest
mała. Ale jak ktoś używa Pascal to nie rzucaj epitetów:
jest szansa że wie co robi.
J.F.
Guest
Guest
Wed Jan 29, 2014 11:08 pm
Dnia Mon, 27 Jan 2014 18:36:28 -0600, A.L. napisał(a):
Quote:
On Mon, 27 Jan 2014 13:44:15 -0800 (PST), hebisch@math.uni.wroc.pl
Dziś kompilatory optymalizujące dla C są łatwo dostępne, więc można
nie doceniać możliwici użycia prostego kompilatora. Ale w pierwszych
latach C kompilatory dla mini i mikrokomuterów były badziewiate.
Nie byly badziewne. Pierwsze kompilatory C byly doskonale, na dlugo
zanim pojawily sie pecety.
Dziś kompilatory optymalizujące dla C są łatwo dostępne, więc można
nie doceniać możliwici użycia prostego kompilatora. Ale w pierwszych
latach C kompilatory dla mini i mikrokomuterów były badziewiate.
Nie byly badziewne. Pierwsze kompilatory C byly doskonale, na dlugo
zanim pojawily sie pecety.
No nie, spodziewam sie ze pierwsze byly kiepskie. Ale sie udoskonalily
.... jak piszesz - na dlugo przed pecetami.
Quote:
W C byl i jest pisany UNIX. Gdy Pecety sie
pojawily, kompilatory C bazowaly na technice kompilacji kompilatorow
Unixowych i byly naprawde doskonale. Zas kompilatory Pascala bazowaly
na p-kodzie i maszynie wirtualnej
pojawily, kompilatory C bazowaly na technice kompilacji kompilatorow
Unixowych i byly naprawde doskonale. Zas kompilatory Pascala bazowaly
na p-kodzie i maszynie wirtualnej
No nie - to tylko jedna z mozliwosci, dla tych co chca szybko pascala
posadzic na nowej maszynie. Byly i normalne kompilatory.
Quote:
Jak idzie o optymalizacje, to optymalizacja nei jest specjalnie
krytyczna
krytyczna
Zalezy. Programista mowi ze C jest dwa razy szybsze i Pascal przestaje
byc uzywany.
Quote:
Kompilator Pascala wie kiedy ma do czynienia
z tablią i zwykle (z wyjątkiem niekiedy dodawanyc konstrukcji
w stylu C) zna rozmiar tablicy więc może automatycznie wstawić
instrukcje sprawdzające czy indeks mieści się w granicach.
No i wlasnei dlatego program w Pascalu jest wolniejszy niz w C
z tablią i zwykle (z wyjątkiem niekiedy dodawanyc konstrukcji
w stylu C) zna rozmiar tablicy więc może automatycznie wstawić
instrukcje sprawdzające czy indeks mieści się w granicach.
No i wlasnei dlatego program w Pascalu jest wolniejszy niz w C
Ale niespecjalnie krytycznie :-)
Quote:
W sumie: jak masz dobry kompilator Pascala to może on
mieć zalety w porównaniu z C. Ale jest spora szansa
że C wygra ze względu na większą dostępność narzędzi
i bibliotek.
Nei nalezy porownywac pomarancz z jablkami. Pascal to silnie typowany
jezyk wysokiego poziomu, C to "strukturalizowany asembler" dla
zastosowan gdzie neisbedny jest bliski kontakt z "metalem"
mieć zalety w porównaniu z C. Ale jest spora szansa
że C wygra ze względu na większą dostępność narzędzi
i bibliotek.
Nei nalezy porownywac pomarancz z jablkami. Pascal to silnie typowany
jezyk wysokiego poziomu, C to "strukturalizowany asembler" dla
zastosowan gdzie neisbedny jest bliski kontakt z "metalem"
Spojrz na produkty Borlanda ... i nie masz racji.
Pare rozszerzen do standardu i oba jezyki sa prawie identyczne.
Quote:
NA dodatek, Pascal ma pewne cechy ktore powoduja ze musi wykonywac sie
wolniej niz C. Oprocz indeksow tablic (patzr wyzej) sa "zanurzone
procedury" (nested procedures) ktore wymahaja aby dostep do pewnych
elementow byl okreslany w czasie wykonania programu.
wolniej niz C. Oprocz indeksow tablic (patzr wyzej) sa "zanurzone
procedury" (nested procedures) ktore wymahaja aby dostep do pewnych
elementow byl okreslany w czasie wykonania programu.
A potem zrobili C++
Quote:
Optymalizacja zas nei zawsze jest pozadana. Wiadomo ze a + (b+c) nei
rowna sie czasami (a+b)+c, a optymalizujacy kompilator usunie nawiasy
jako pierwsza czynnosc. No, chyba ze to jest kompilator Fortranu...
rowna sie czasami (a+b)+c, a optymalizujacy kompilator usunie nawiasy
jako pierwsza czynnosc. No, chyba ze to jest kompilator Fortranu...
No ale C tez moze je usunac.
Quote:
P.S> A przyczyna zwiezlosci C jest prosta: gdy uzywa sie {} zamiast
begion/end, krazek tasmy papierowej jest znacznie mniejszy...
begion/end, krazek tasmy papierowej jest znacznie mniejszy...
Mowisz ze tak to bylo ? Czy to juz jednak czasy wciec ?
J.
JarosĹaw SokoĹowski
Guest
Guest
Wed Jan 29, 2014 11:38 pm
Pan J.F. napisał:
Quote:
P.S> A przyczyna zwiezlosci C jest prosta: gdy uzywa sie {} zamiast
begion/end, krazek tasmy papierowej jest znacznie mniejszy...
Mowisz ze tak to bylo ? Czy to juz jednak czasy wciec ?
begion/end, krazek tasmy papierowej jest znacznie mniejszy...
Mowisz ze tak to bylo ? Czy to juz jednak czasy wciec ?
Wcięcia robione tabulatorami nie wydłużają tasiemki dramatycznie.
--
Jarek
A.L.
Guest
Guest
Thu Jan 30, 2014 1:07 am
On Wed, 29 Jan 2014 23:08:58 +0100, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
No nie, spodziewam sie ze pierwsze byly kiepskie. Ale sie udoskonalily
... jak piszesz - na dlugo przed pecetami.
Historia jezyka C
http://cm.bell-labs.com/who/dmr/chist.pdf
Quote:
No nie - to tylko jedna z mozliwosci, dla tych co chca szybko pascala
posadzic na nowej maszynie. Byly i normalne kompilatory.
Byly. Ale te ktore znam (Na Odre na prztklad, czy Turbo Pascal)
benerowaly kod maszynowy "on the fly" zamiast generacji p-codu. Ale
bazujaca na kompilatorze Ammana. Struktura kompilatora byla taka sama
i narzucona pzrez strukture jezyjk poniekad
A.L.
bartekltg
Guest
Guest
Thu Jan 30, 2014 7:13 am
On 2014-01-27 19:31, JDX wrote:
Quote:
On 2014-01-27 18:34, J.F wrote:
[...]
A z drugiej strony - uzyles f2c, wiec ominales problem ... ale C++ juz
sobie dobrze radzi z liczbami zespolonymi ?
Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++ daleki byl
od doskonalosci.
Podejrzewam (bo nie porównywałem), że C++ obecnie radzi sobie z liczbami
zespolonymi tak samo dobrze jak Fortran. W każdym razie w bibliotece
standardowej ma wsparcie dla tych liczb:
http://en.cppreference.com/w/cpp/numeric/complex .
[...]
A z drugiej strony - uzyles f2c, wiec ominales problem ... ale C++ juz
sobie dobrze radzi z liczbami zespolonymi ?
Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++ daleki byl
od doskonalosci.
Podejrzewam (bo nie porównywałem), że C++ obecnie radzi sobie z liczbami
zespolonymi tak samo dobrze jak Fortran. W każdym razie w bibliotece
standardowej ma wsparcie dla tych liczb:
http://en.cppreference.com/w/cpp/numeric/complex .
Radzić sobie radzi. Są/były dwa problemy.
Po pierwsze, fortran przez swoje ograniczenia pozwalał na lepsze
sztuczki optymalizacyjne.
http://stackoverflow.com/questions/1602451/c-valarray-vs-vector
Ale tego prawie nikt nie używa, za to używa się różnych innych
bibliotek.
Po drugie, były jakieś kłopoty z kompatybilnośćią binarną
pomiędzy FORTRAN, C i C++. Wydaje mi się, ze już posprzątali.
Quote:
Takie np odwrocenie tablicy zespolonej rownie elegancko jak w Fortranie
daje sie zapisac i rownie szybko idzie ?
Elegancko macierze to się odwraca w Matlabie (i klonach):
http://www.mathworks.com/help/matlab/ref/inv.html.
daje sie zapisac i rownie szybko idzie ?
Elegancko macierze to się odwraca w Matlabie (i klonach):
http://www.mathworks.com/help/matlab/ref/inv.html.
Pomijając to, że odwracanie macierzy to najczęśćiej zły pomysł, c++:
http://eigen.tuxfamily.org/dox-2.0/TutorialAdvancedLinearAlgebra.html
A.inverse();
[ładna biblioteka, niekoniecznie najszybsza, intem MKL jest niekokonany,
ale dużo nie ustępuje, a od początku napisana w c++]
Quote:
A jak to się robi w
Fortranie?
Fortranie?
sgetri, dgetri
cgetri, zgetri
http://www.physics.orst.edu/~rubin/nacphy/lapack/routines/dgetri.html
:-)
W sumie niby koszmarek, a porządnego _całościowego_ opakowania tego
w c++ (z Expression templates, move) jakoś nie ma.
CUDA też wystawia taki interfejs.
pzdr
bartekltg
Cezary Grądys
Guest
Guest
Thu Jan 30, 2014 2:11 pm
W dniu 27.01.2014 14:47, Jarosław Sokołowski pisze:
Quote:
Pan Cezary Grądys napisał:
Problem może być jesli bedziesz potrzebował większej wydajnosci, jakoś
te kompilatory Pascala które spotkałem nie tworzą wydajnego kodu.
Które konkretnie? Wydaje mi się, że akurat *ten* argument stracił rację
bytu. Znam dwie grubsze rzeczy, które mają źródła w Pascalu: TeX i Mizar.
Problem może być jesli bedziesz potrzebował większej wydajnosci, jakoś
te kompilatory Pascala które spotkałem nie tworzą wydajnego kodu.
Które konkretnie? Wydaje mi się, że akurat *ten* argument stracił rację
bytu. Znam dwie grubsze rzeczy, które mają źródła w Pascalu: TeX i Mizar.
Ostatnio słabo mi się sprawdził fpc pod względem szybkosci. Ale możliwe,
że są szybkie, szczególnie komercyjne. Tu się spierał nie będę.
--
Cezary Grądys
czarekgr@wa.onet.pl
JarosĹaw SokoĹowski
Guest
Guest
Thu Jan 30, 2014 2:45 pm
Pan Cezary Grądys napisał:
Quote:
Problem może być jesli bedziesz potrzebował większej wydajnosci, jakoś
te kompilatory Pascala które spotkałem nie tworzą wydajnego kodu.
Które konkretnie? Wydaje mi się, że akurat *ten* argument stracił rację
bytu. Znam dwie grubsze rzeczy, które mają źródła w Pascalu: TeX i Mizar.
Ostatnio słabo mi się sprawdził fpc pod względem szybkosci. Ale możliwe,
że są szybkie, szczególnie komercyjne. Tu się spierał nie będę.
te kompilatory Pascala które spotkałem nie tworzą wydajnego kodu.
Które konkretnie? Wydaje mi się, że akurat *ten* argument stracił rację
bytu. Znam dwie grubsze rzeczy, które mają źródła w Pascalu: TeX i Mizar.
Ostatnio słabo mi się sprawdził fpc pod względem szybkosci. Ale możliwe,
że są szybkie, szczególnie komercyjne. Tu się spierał nie będę.
Też nie chodzi mi o to, by sie spierać, tylko o ustalenie faktu. Sytuacja
z Mizarem i zmianą kompilatora z Borlanda na FPC miała miejsce na przełomie
wieków (przypomnę, że skutkowało to sporym przyspieszeniem). Ale pamiętam
też, jak ktoś tak z dziesięć lat wcześniej pokazywał mi swoje analizy kodu
wynikowego Borlanda -- był tak dobry, że trudno było coś poprawić. W dodatku
Pascal miewał ten kod lepszy od C w analogicznym programie testowym. Może to
stąd, że te analizowane programy były stosunkowo proste, a Mizar, to kawał
kodu. Możliwe, że ta utrata szybkości następuje przy jakichś konkretnych
rzeczach, które słabo zostały dopracowane w kompilatorze (nie wyrabia się
na zakrętach, czy cóś).
--
Jarek
A.L.
Guest
Guest
Fri Jan 31, 2014 2:02 am
On Thu, 30 Jan 2014 14:45:36 +0100, Jaros?aw Soko?owski
<jaros@lasek.waw.pl> wrote:
Quote:
Też nie chodzi mi o to, by sie spierać, tylko o ustalenie faktu. Sytuacja
z Mizarem i zmianą kompilatora z Borlanda na FPC miała miejsce na przełomie
wieków (przypomnę, że skutkowało to sporym przyspieszeniem). Ale pamiętam
też, jak ktoś tak z dziesięć lat wcześniej pokazywał mi swoje analizy kodu
wynikowego Borlanda -- był tak dobry, że trudno było coś poprawić. W dodatku
Pascal miewał ten kod lepszy od C w analogicznym programie testowym. Może to
stąd, że te analizowane programy były stosunkowo proste, a Mizar, to kawał
kodu. Możliwe, że ta utrata szybkości następuje przy jakichś konkretnych
rzeczach, które słabo zostały dopracowane w kompilatorze (nie wyrabia się
na zakrętach, czy cóś).
z Mizarem i zmianą kompilatora z Borlanda na FPC miała miejsce na przełomie
wieków (przypomnę, że skutkowało to sporym przyspieszeniem). Ale pamiętam
też, jak ktoś tak z dziesięć lat wcześniej pokazywał mi swoje analizy kodu
wynikowego Borlanda -- był tak dobry, że trudno było coś poprawić. W dodatku
Pascal miewał ten kod lepszy od C w analogicznym programie testowym. Może to
stąd, że te analizowane programy były stosunkowo proste, a Mizar, to kawał
kodu. Możliwe, że ta utrata szybkości następuje przy jakichś konkretnych
rzeczach, które słabo zostały dopracowane w kompilatorze (nie wyrabia się
na zakrętach, czy cóś).
Popatrz sobie jak dziala kompilator Pascala. Zagniezdzone procedury
powoduja ze dostep do miennych musi sie odbywac pzrez tworzony na
biegowo, w czasie wykonywanai programu, ciag aktywacji (dynamic
activation link). C czegos takiego nie potzrebuje z definicji. Wiec
dostep do zmiennyc hzajmuje w Pascalu wiecej czasu niz w C
A.L.
J.F.
Guest
Guest
Fri Jan 31, 2014 9:37 am
Dnia Thu, 30 Jan 2014 19:02:43 -0600, A.L. napisał(a):
Quote:
Popatrz sobie jak dziala kompilator Pascala. Zagniezdzone procedury
powoduja ze dostep do miennych musi sie odbywac pzrez tworzony na
biegowo, w czasie wykonywanai programu, ciag aktywacji (dynamic
activation link). C czegos takiego nie potzrebuje z definicji. Wiec
dostep do zmiennyc hzajmuje w Pascalu wiecej czasu niz w C
powoduja ze dostep do miennych musi sie odbywac pzrez tworzony na
biegowo, w czasie wykonywanai programu, ciag aktywacji (dynamic
activation link). C czegos takiego nie potzrebuje z definicji. Wiec
dostep do zmiennyc hzajmuje w Pascalu wiecej czasu niz w C
Hm, musialbym przypomniec sobie ... ale jest to chyba
a) do zrobienia - kompilator wiedzac ze to procedura wywolana z
nadrzednej moze policzyc gdzie na stosie jest zmienna nadrzednej.
gorzej jesli jest rekurencja.
A C przeciez tez ma bloki w funkcji, w ktorych moga byc wlasne
zmienne. A C++ to juz w ogole.
b) do obejscia - jesli procedura dostanie dodatkowe parametry z
uzywanymi zniennymi z nadrzednych.
c) a przeciez wystarczy napisac - kto uzywa zmiennych z nadrzednych
procedur obniza wydajnosc.
J.
elektroda NewsGroups Forum Index - Elektronika Polska - Pascal kontra C: Czy naprawdę C przewyższa czytelnością i wygodą w programowaniu?