Porównanie języków programowania

[SP5FCS]

Robi się coraz ciekawiej, Bascom wypada lepiej niż WinAVR

Pawle aby było sprawiedliwie dla wszystkich kompilatorów f_vfo i f_clk należy zadeklarować nie jako stałe a jako zmienne ( kod Bascom ). W normalnym programie najczęściej są one zmieniane dynamicznie w trakcie programu. Przy stałych odpadają funkcje konwersji formatów.
Tradycyjnie poproszę o pliki wynikowe wygenerowane z Bascom aby popatrzeć dlaczego wypada tak dobrze.

Zmieniłem lekko kod zadania testowego aby wyeliminować obliczenia wykonywane przez kompilator w czasie kompilacji.
Wyniki dla kompilatora WinAVR nadal są bardzo złe, może należy coś poustawiać w optymalizacji kodu ???
Nie mam pojęcia dlaczego najpopularniejszy kompilator dla procków AVR wypada najsłabiej w tych testach.

Kod:

////////////////////////////////////////////////////////////////////////
// Test_1 - obliczanie nastawy dla AD9951
////////////////////////////////////////////////////////////////////////

unsigned long int f_clk=400000000;
unsigned long int FTW;

void Oblicz_FTW (unsigned long int f_vfo)
{
FTW= (unsigned long int) ( (float) 0x100000000 * f_vfo/f_clk );
}

void main(void)
{
Oblicz_FTW(20000000);        //oblicz FTW dla f_vfo=20MHz
}

WinAVR: kod: 3920 bajt, RAM: 272, cykle: 7532
CodeVision: kod: 802 bajt, RAM: 8, cykle 1372

[SQ6OXK]

Ok,

Według życzenia poprawione BASCOM-y.

Wersja z float (single):

Kod:

$noinit
$noramclear

$regfile "m32def.dat"
$crystal = 16000000

Dim Fclk As Dword
Dim Fvfo As Dword
Dim Pom As Single
Dim Pom2 As Single
Dim Ftw As Dword

Fclk = 400000000
Fvfo = 20000000

Pom = &H100000000
Pom2 = Fvfo
Pom = Pom * Pom2
Pom2 = Fclk
Pom = Pom / Pom2
Ftw = Pom

End

  test_1a_ba.zip (Rozmiar: 4.3 KB / Pobrań: 1038)

Wynik:

Kod: 888 (40+848)
Cykle: 1 609 (20+1 589) - ~101ns
Wynik: 0x0CCCCCD0

---

Wersja z Double:

Kod:

$noinit
$noramclear

$regfile "m32def.dat"
$crystal = 16000000

Dim Fclk As Dword
Dim Fvfo As Dword
Dim Pom As Double
Dim Pom2 As Double
Dim Pom3 As Single
Dim Ftw As Dword

Fclk = 400000000
Fvfo = 20000000

Pom = &H100000000
Pom3 = Fvfo
Pom2 = Pom3
Pom = Pom * Pom2
Pom3 = Fclk
Pom2 = Pom3
Pom = Pom / Pom2
Ftw = Pom

End

  test_1b_ba.zip (Rozmiar: 7.13 KB / Pobrań: 1048)

Wynik:

Kod: 1 590 (40+1 550)
Cykle: 3 439 (20+3 419) - ~215ns
Wynik: 0x0CCCCCCD

---

Okazało się że w BASCOM-ie nie można bezpośrednio przypisać zmiennej DWORD do Double.

Najpierw wykonałem próby z mnożenie i dzielenie Double i Single (Float) okazało się jednak, że wyniki są nieprawidłowe.
Nie wiem czy to błąd symulatora czy samego kompilatora, trzeba będzie sprawdzić to na procesorze.
Stąd własnie najpierw konwersja danych z DWORD do Single, a następnie dopiero z Single do Double.

Wyniki oczywiście przez takie podwójne konwersję, są znacznie słabsze.

[SP5FCS]

Pawle, dziękuję za szybką odpowiedź i udział w testach. Widać wyraźnie, że wyniki na zmiennych typu float są porównywalne dla C CodeVision oraz Bascoma. Drobne różnice wynikają z innej składni języka, sposobu przekazywania parametrów czy organizację stosu danych.

Być może problem ze zmiennymi typu float w Bascomie jest związany z normalizację i denormalizacją danych. Tak mam napisaną bibliotekę na zmienny przecinek na procesory 8051. Aby zainicjować zmienną float dowolną wartością stałą muszą ją najpierw doprowadzić do formatu zapisu liczby zmiennoprzecinkowej (normalizacja). Aby po obliczeniach mieć ponownie format dwójkowy musimy ponownie dokonać konwesji formatu zmiennoprzecinkowego na jawną postać bajtową. Wykonywanie obliczeń na danych bez normalizacji daje oczywiście błędny wynik. Celowo normalizacja, denormalizacja to oddzielne funkcje aby nie robić ich za każdym razem a tylko wtedy gdy jest to potrzebne. Przy wielokrotnych obliczeniach robimy to tylko na wejściu na nowych danych oraz na końcowym wyniku obliczeń. Stałe mogą być znormalizowane na etapie kompilacji i tak przechowywane w kodzie co oszczędza czas procesora. Być może tak samo jest w Bascomie.

Nie ukrywam rozczarowania efektami uzyskanymi pod WinAVR, może ktoś z Kolegów posługujący się tym kompilatorem spróbuje "wycisnąć" coś więcej w ramach tego testu. Kończę wersję w ASM, wyniku po powrocie ze spotkania na PW.

Zapraszam do wykonania testu na innych procesorach Bascom51, ASM51, C_51, PIC, ARM.

-------------------------------------------------------------------------------------
Wstępne wyniki dla assebmlera AVR przy obliczeniach na 64 bitach są takie:

Kod: 162 bajt (8+154)
Cykle: 1774 (4+1770)
RAM: 12 bajt

Zapewne Koledzy zastanawiają się czy to możliwe, czy raczej żart "prima aprilis-owy" ?

[SQ6ADE]

(30-03-2012 0:19)SP5FCS napisał(a):  ....
Zapraszam do udziału w teście, mogę napisać funkcje w assemblerze ...

Pojawi się coś takiego ?

[SP4EJT]

Chciałbym dołaczyć do zabawy ale ...... Czy w AVRStudio z WinAVR też mogę sprawdzić ilość cykli ?
Niby znalazłem tabelke "Cycle Counter" ale tam jest tylko "13" to raczej niemożliwe
Zrobiłem nowy projekt, zaznaczyłem że to ma byc pod Atmega32 i wkleiłem kod z postu #10

Kod:

#include <stdint.h>
#include <avr/io.h>


int main(void)
{
  uint64_t Fclk=400000000;
  uint64_t Fvfo=20000000;
  uint32_t FTW;
  FTW=(uint32_t)((uint64_t)0x100000000*Fvfo/Fclk);  
  
  return 0;
};

[SP5FCS]

Marcin, weź kod z postu #11 aby zmusić kompilator do wykonania obliczeń. Teraz kompilator uznaje, że nic nie musi liczyć bo może obliczyć wynik na etapie kompilacji.

[SP4EJT]

Przepraszam za brak polskich znakow w domu mam rozwalona klawiature.

Dobra, do rzeczy ... cos drgnelo
Adam jakbys jeszcze powiedzial dlaczego po nacisnieciu "start debuging" Cycle Counter ma wartosc 2467 ? .... a dopiero jak wcisne "Auto Step" licznik idzie do tych 7 tysiecy. ???
I jeszczee jedno ... rozumiem ze wynik jest w rejestrach od 19 do 22, dobrze przyuwazylem ?

[SP5FCS]

Marcin, po naciśnięciu [start debuging] symulator wykonuje cały kod inicjujący (prolog), omijanie wektorów przerwań, ustawienie stosów, zerowanie pamięci RAM itd. i zatrzymuje się na pierwszej linii kodu w języku C. Czyli jeszcze nic z kodu C nie wykonał a już 2,5 tys cykli poszło w powietrze.
Aby mieć pełny wgląd na to co robi procesor należy uruchomić disassembler i na nim robić symulację krok po kroku (po jednej linni kodu asm).
Wynik końcowy jest zapisywany w pamięci RAM do zmiennej FTW (podgląd Memory). Wynik przekazywany jest pośrednio przez rejestry [R21,R20,R19,R18].

Mimo, że mamy 01 kwietnia to wyniki uzyskane w assemblerze nie są forumowym żartem. Nie ukrywam, że wykonanie mojego zadania wymagało w ASM sporego nakładu pracy, brak gotowych procedur obliczeniowych na tak długich formatach. Tym bardziej cieszy uzyskany efekt końcowy. Wynik do sprawdzenia na podstawie symulacji pod AVR Studio, pliki w załączniku.

Uzyskanie dobrego wyniku wymagało zastosowania kilku sztuczek programowych. Obliczenia są wykonywane na poniższych formatach.
- 2^32*f_vfo jako zmienna integer[64] bity;
- dzielenie integer[64] przez integer[32]
- FTW jako integer[32]
Wynik to poprawna część całkowita bez korekty wartości po przecinku.

Wynik końcowy TEST_1, assebmler AVR dla ATmega32
Kod: 162 bajt (8+154) - inicjowanie, program główny, funkcja obliczania FTW
Cykle: 1774 (4+1770)
RAM: 12 bajt - 3 zmienne w RAM po 4 bajty
Wynik: 0x0CCCCCCC

No cóż, interpretację wyników pozostawiam czytelnikom forum. Trudno o lepszą rekomendację dla możliwości assemblera.

[SP4EJT]

(01-04-2012 23:59)SP5FCS napisał(a):  Marcin, po naciśnięciu [start debuging] symulator wykonuje cały kod inicjujący (prolog), omijanie wektorów przerwań, ustawienie stosów, zerowanie pamięci RAM itd. i zatrzymuje się na pierwszej linii kodu w języku C. Czyli jeszcze nic z kodu C nie wykonał a już 2,5 tys cykli poszło w powietrze.

1. Czyli dzieje sie to w przypadku C lub innego jezyka wysokopoziomowego, a w asemblerze nie ??
2. Jesli program w C mialby w petli obliczac FTW to "prolog" jest tylko na poczatku, a za drugim razem FTW obliczane jest w liczbie cykli 7k - 2,5k(prolog) = 4,5k ??

SP5FCS napisał(a):Mimo, że mamy 01 kwietnia to wyniki uzyskane w assemblerze nie są forumowym żartem. Nie ukrywam, że wykonanie mojego zadania wymagało w ASM sporego nakładu pracy ...... No cóż, interpretację wyników pozostawiam czytelnikom forum. Trudno o lepszą rekomendację dla możliwości assemblera.

3. Adam, zachwalasz i przekonujesz, mnie przekonales. Zlituj sie wreszcie i zrob krotki kurs, a wlasciwie tylko jego poczatek. Wiem ze Ci sie nie chce ale zrobilbys DUZA przysluge dla wielu osob. Ja bede pierwszy na twoich lekcjach. Wystarczy zaczac tak jak ja zrobilem to na forum - zrobilem kilka lekcji, dalem linki do materialow do szkolenia we wlasnym zakresie i Ci przecietnie kumaci dadza sobie rade sami z dalszym szkoleniem jezyka C (oczywiscie powroce do tego kursu).
Najgorzej jest zaczac ! Musi byc ktos kto naprowadzi poczatkujacego aby nie poddal sie na samym poczatku.
Przemysl to chociarz .

[SP5FCS]

Marcin, celem tego wątku nie jest zachwalanie czy przekonywanie czytających do konkretnego języka a pokazanie różnic oraz efektów pracy w poszczególnych środowiskach. Praktyczne testy pokazują realny koszt wykonania algorytmu w postaci kodu i czasu pracy procesora. Wygoda języka wysokopoziomowego jest okupiona większym kodem i czasem wykonania. Pracochłonne i powolne pisanie programu w assemblerze może dać efekt w postaci zwartego i szybkiego kodu. Coś za coś, nie ma idealnego języka. W tych testach nie chodzi o wyłonienie zwycięzcy. Każdy język programowania jest wystarczająco dobry jeśli pozwala programiście osiągnąć zamierzony cel w zakładanym czasie.

Przewaga assemblera pod względem generowanego kodu oraz szybkości wykonania jest oczywista dla większości programistów. Dlatego fragmenty oprogramowania o wysokich wymaganiach czasowych są pisane wyłącznie w assemblerze. Niestety te dwie istotne zalety dla wielu nie są tak ważne jak prostota języka, czas nauki, gotowe funkcje, przykładowe programy, szybkość wykonania aplikacji. Nie sądzę aby nauka assemblera na potrzeby naszego hobby była uzasadniona. Wyjątkiem mogą być wstawki assemblerowe w innych językach.

Jeśli już miałbym przekonywać Kolegów do jakiegoś języka do celów hobbystycznych to byłby to Bascom. Nigdy nie gustowałem w tym języku (czasy ZX-80) ale dla Kolegów nie znających żadnego języka to rozsądny wybór. Prosta składnia, darmowy kompilator do 4kB, masa gotowych funkcji do obsługi zasobów procesora oraz urządzeń peryferyjnych, dużo działających przykładów, duże grono kolegów do wymiany doświadczeń. Testy pokazały, że nawet przy złożonych obliczeniach pod względem generowanego kodu oraz czasu wykonania nie ustępuje kompilatorom języka C. Oczywiście "fani" języka C wymyślą taki test, który rozłoży Bascoma na łopatki ale czy często będziemy tworzyli takie oprogramowanie.

Jeśli ktoś myśli poważniej o programowaniu ( złożone sterowniki, nowe procesory, soft na komputery) to warto od razu uczyć się C. Należy jednak pamiętać, że jest to język wiele trudniejszy niż Bascom. Możliwość pisania w różnych środowiskach, na różnych platformach to jedna z najistotniejszych zalet tego języka.

W sprawie kursu to nie jest kwestia chęci tylko ograniczonego czasu na hobby. Muszę skończyć to zacząłem wcześniej, syntezę na TFT do Husara i to ma najwyższy priorytet.
Moim zdanie w tej chwili ważniejsze jest dokończenie kursu języka C aby stanowił pewną całość. Chętnie pomogę jeśli wiedza i czas pozwoli.