Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorKoval
   • CommentTime12 Jun 2009

    
   Jakiś czas temu mieliśmy nowinki związane z hybrydą Forth/Logo i Action. Ciekaw jestem porównania języków Forth i Action. Tzn.: który elastyczniejszy, szybszy, bardziej przemyślany. Wiadomo, że Forth jest dość starym językiem, więc teoretycznie powinien "przegrywać" pod wieloma względami z nowszym, dedykowanym specjalnie dla Atari Actionem (przegrywać w porównaniach przeprowadzonych na Atari). Czy wogóle jest sens takiego porównania? Jak myślicie?
   Następne pytanie, które przyszło mi do głowy: Forth a C++? (to już na PC). Który wymaga mniejszych nakładów pracy, który wydajniejszy itd... Ciekawi mnie to, bo mam do czynienia z C++ w różnych odmianach, a Fortha znam tylko ze słyszenia...
2. • 2:
      
     CommentAuthorCosi
   • CommentTime12 Jun 2009

    
   Forth jest bardzo specyficznym językiem. Trudno go porównywać, choćby ze względu na filozofię pracy - tutaj program "buduje się z klocków" bezpośrednio w systemie, zamiast redagować go w edytorze, a potem przepuszczać przez parser. Programy skompilowane Forthem (tak, da się) mają rozmiar jądra Fortha + całego dodatkowego kodu, więc już masz częściową odpowiedź: do pisania malutkich skrypcików się Forth nie nadawa :)
   Na pewno jest trudniejszy w sprawnym opanowaniu niż Action! Co do C++, to może będę mało obiektywny (obiektowy ;-)), ale kaligrafowanie Kanji to przy programowaniu w C++ łatwizna. Z kolei - jeżeli mówimy o piecach - to w Forth'cie nie wszystko się oprogramuje. C oraz C++ wypełniają niszę, w którą inne języki nie próbują się nawet zagłębiać, i sądzę że jeszcze długo tak zostanie. Natomiast jeżeli porównujemy wydajność Fortha i C++ (czy jakiegokolwiek narzecza obiektowego), to bez żartów, mości Panowie. Programowanie obiektowe NIGDY nie będzie wydajniejsze od strukturalnego.
   No ale wracając do Fortha i Action! - jeżeli ktoś zna (i pamięta) Pascala, to polecałbym Action! (a mówi to miłośnik Fortha! ;-)). Jeżeli nie ma "naleciałości" z Pascala czy C, gorąco polecam naukę Fortha. Chętnie pomogę w miarę moich skromnych możliwości, a i kursów jest trochę. Dopiero z tym językiem można "zobaczyć Matrix" - jak Neo w ostatnich scenach :-D
3. • 3:
      
     CommentAuthorimmolator
   • CommentTime12 Jun 2009

    
   Nie wiem czy dobrze pamiętam, ale po kursie Rolanda Pantoły, Forth zaczął mi się jawić jako swoisty framework (wtedy jeszcze tego słowa nie znałem) do programowania w asemblerze. Oczywiście posiada swoistą egzotyką, co jest jego niezaprzeczalną zaletą. Niektórzy dla takich właśnie doznań uczą się podobno nawet Lispa ;-)
4. • 4:
      
     CommentAuthorCosi
   • CommentTime12 Jun 2009

    
   Niekoniecznie w asemblerze :) Framework to po angielsku "rusztowanie", co dobrze oddaje specyfikę Fortha. Pisałem ostatnio, że nawet Basica można "wbudować" do środka i na tym opierać swoje programy (oczywiście będzie to taki "Basic"). Szkoda, że Forth nie umożliwia dodawania bloków kodu maszynowego do swojego słownika. Wtedy można by go połączyć z dowolnym językiem, dającym taki kod.
   
   No a egzotyka swoją drogą :-))
5. • 5:
      
     CommentAuthorKaz
   • CommentTime16 Jun 2009

    
   No to moze nastal czas, zeby dodac dodawanie kodu maszynowego? Taka "mala" modyfikacja. Pewnie Carsten Strotmann bylby chetny przy tym wspoldzialac (o ile juz nad czyms takim nie pracowal/pracuje).
6. • 6:
      
     CommentAuthorCosi
   • CommentTime17 Jun 2009 zmieniony

    
   Carsten mógłby spłodzić jakąś choćby krótką dokumentację do volksFortha*, wtedy zająłbym się intensywnie promocją tego narzecza :) Mógłbym nawet zrobić tłumaczenie tej dokumentacji, choćby z języka dojcz.
   Wtedy można by pomyśleć o rozwijaniu samego Fortha - zwłaszcza że VF ma otwarte źródła...
   
   *) Taką stricte atarowską, opisującą implementację na małe Atari
7. • 7:
      
     CommentAuthorKaz
   • CommentTime1 Jul 2009

    
   Skoro implementacja powstala juz na wiele platform, to moze gdzies jest juz instrukcja po angielsku albo niemiecku?
8. • 8:
      
     CommentAuthorCosi
   • CommentTime2 Jul 2009

    
   Gdzieś coś jest. Pamiętam, że gdzieś udało mi się znaleźć informacje, jak kompilować do .COM'ów. Ale na pewno to nie jest pełna dokumentacja, raczej małe FAQ.
   Na stronie projektu na Sourceforge jest niemiecka dokumentacja do jakiegoś kompatybilnego narzecza - bodajże Fortha-83. Ale dla C64 :(
   
   Btw.: coś mi się przypomniało. Znakomita dokumentacja do figFortha jest dla spectrumowej wersji (w załączniku). Polecam!

   • AbersoftForth.txt
9. • 9:
      
     CommentAuthorKaz
   • CommentTime5 Jul 2009

    
   A masz Cosi ksiazke Ruszczyca "Forth"?
10. • 10:
       
      CommentAuthorCosi
    • CommentTime6 Jul 2009

     
    Nie, a chętnie bym ją dorwał. Na Allegro jest tylko Bielecki ("Hello, I'm Jan B.") ;)
11. • 11:
       
      CommentAuthorKaz
    • CommentTime6 Jul 2009

     
    No to z braku laku polecam wersje elektroniczna, o ktorej w dzisiejszej nowince :).
12. • 12:
       
      CommentAuthorCosi
    • CommentTime6 Jul 2009 zmieniony

     
    Dzięki :) Będzie co czytać do poduchy ;)
    
    PS. Książka jest bardzo fajnie napisana, już w pierwszym rozdziale znalazłem fragment:
    "W warunkach współczesnego burzliwego rozwoju informatyki i przenikania jej do wszystkich dziedzin życia, w tym również do naszych ognisk domowych, poznawanie języków programowania staje się ważnym składnikiem podnoszenia ogólnego poziomu wiedzy każdego Polaka, w tym zwłaszcza wchodzących w życie pokoleń. Poznawanie języków programowania rozszerza horyzonty i pozwala lepiej rozumieć świat, zwiększa podobnie jak poznawanie języków obcych - możliwości udziału w postępie cywilizacyjnym dokonującym się wokół nas. Człowiek ograniczający się do znajomości jednego języka programowania ( a spotykamy takich, niestety, choć coraz rzadziej, również wśród zawodowych programistów ), ogranicza tym samym własne szanse i pozostaje w tyle."
    Czytając książki i gazety z lat 80-tych można zauważyć ciekawe zjawisko: niektórzy autorzy byli przekonani, że za 5-10 lat *każdy* będzie posiadał umiejętność programowania, tak samo jak umiejętność czytania czy liczenia :-) Nie przewidzieli tego, że obsługa komputera będzie tak prosta, jak telewizora czy mikrofalówki ;)
13. • 13:
       
      CommentAuthorsikor
    • CommentTime7 Jul 2009

     
    Ja się na Forth-u nie znam, ale dla niektórych może byyć ciekawe - artykuł na 42 stronie 9-go numeru ANALOG-u (jest w bibliotece), może też ten na 55 stronie też...
14. • 14:
       
      CommentAuthorCosi
    • CommentTime8 Jul 2009

     
    A rocznik jakiś ten numer posiada? ;-) Bo przejrzałem wszystkie i nie znalazłem niczego na temat Fortha...
15. • 15:
       
      CommentAuthorKaz
    • CommentTime8 Jul 2009 zmieniony

     
    Szukaj po numeracji na okladce (numeracja ciagla), nie wedlug nazw plikow, bo te sa numerowane w ramach jednego roku.
    
    PS. Numer 1983_01
16. • 16:
       
      CommentAuthorKaz
    • CommentTime8 Jul 2009

     
    A w ogole to facet zapowiadal cykl artkow o Forth i szukal wspolpracownikow. Cosi, moze bys do niego napisal? :)
17. • 17:
       
      CommentAuthorCosi
    • CommentTime8 Jul 2009

     
    Sądzisz, że on jeszcze żyje? ;D
18. • 18:
       
      CommentAuthorKaz
    • CommentTime8 Jul 2009 zmieniony

     
    Zyje i ma sie dobrze:
    
    ->link<-
    
    ->link<-
19. • 19:
       
      CommentAuthorsikor
    • CommentTime8 Jul 2009

     
    Dotarłem do 13-go numeru i tam się cykl artków zaczyna, także dobrze szukać. Ja się w temat nie zagłębiam, bo na Fortha się póki co nie piszę. W pierwszym odcinku w każdym razie jest jakieś porównanie Basica, Fortha i ML (machine language ;) ) - tak więc w całości może być bardzo dobry i ciekawy cykl dla zainteresowanych.
20. • 20:
       
      CommentAuthorCosi
    • CommentTime9 Jul 2009

     
    Zyje i ma sie dobrze

    
    Fajny profil na LinkedIn. Facet pisze o sobie w trzeciej osobie - Mr.Volk. Prawie jak Juliusz Cezar ;-) A może ktoś mu ten życiorys napisał?
21. • 21:
       
      CommentAuthorKaz
    • CommentTime9 Jul 2009

     
    Pisanie o sobie w trzeciej osobie to czesty zwyczaj przedstawiania swoich osiagniec. Szczegolnie Ci, ktorzy maja do czynienia z mediami stosuja taka stylistyke swoich CV/profili, etc.
    
    Sikor - ja dotarlem na razie do 4 numeru. Pewnie dlatego, ze sobie wydrukowalem do czytania i papier mi sie skonczyl :D.
22. • 22:
       
      CommentAuthorCosi
    • CommentTime9 Jul 2009

     

    Kaz:

    Pisanie o sobie w trzeciej osobie to czesty zwyczaj przedstawiania swoich osiagniec. Szczegolnie Ci, ktorzy maja do czynienia z mediami stosuja taka stylistyke swoich CV/profili, etc.

    
    Co nie zmienia faktu, że wygląda to potwornie pretensjonalnie ;)
23. • 23:
       
      CommentAuthorKaz
    • CommentTime9 Jul 2009

     
    Wydaje mi sie, ze to ma cos wspolnego z tradycja/zwyczajem. U nich to raczej nie jest pretensjonalne, nie odnioslem takiego wrazenia (czesto na uniwerku spotykalem sie z taka autoprezentacja wykladowcow w pismach, folderach, pracach, etc), a u nas raczej tak.
    
    Wracajac do tematu - czy ktos ma pliki tych Forth-ow opisywanych przez Mr. Volka?
24. • 24: CommentAuthorzbyti
    • CommentTime18 Feb 2020 zmieniony

     

    Tajemnice Atari 92/2:

    Widać wielką zaletę Odwrotnej Notacji Polskiej, a mianowicie brak nawiasów wymuszających pierwszeństwo dla danego działania. Wszystkie działania w języku FORTH są wykonywane zawsze w kolejności zapisu. Czytelnikom proponowałbym spróbować swych sił w następującym przykładzie:
    
    
    (1+2*3)+(1+2)*(2+3)
    
    
    Proszę zapisać to wyrażenie w ję- zyku FORTH i wyświetlić wynik. Czytelnik, który pierwszy prześle poprawny zapis na adres redakcji otrzyma bezpłatnie grę: "A.D.2044".
    

    
    ->link<-
    
    Także może jestem pierwszy i wygrałem grę?! Gdzie się zgłosić po odbiór? :D
    
    A tak na poważnie dopiero za 4x wpisałem poprawnie, tłumacząc sobie w duchu co jest na stacku :D
    
    Jak opanuję te pokręcone cudo na tyle by zrobić Bench by Yosh Plus to tutaj wrzucę.

    • Screenshot_2020-02-18_23-15-53.png
      
      
      
      
25. • 25: CommentAuthormono
    • CommentTime19 Feb 2020

     
    Raczej
    

    2 3 + 1 2 * + 2 3 * 1 + + ok
26. • 26: CommentAuthorzbyti
    • CommentTime19 Feb 2020 zmieniony

     

    (1+2*3)+(1+2)*(2+3) = (1+6) + 3*5 = 7 + 15 = 22
    

    
    Nie ufam swojej matmie ;)
    
    

    Jeżeli w wyrażeniu nie ma nawiasów, to kolejność wykonywania działań jest następująca: potęgowanie i pierwiastkowanie, dalej mnożenie i dzielenie w kolejności ich występowania, a następnie dodawanie i odejmowanie również w kolejności występowania.
    

    
    @mono Twój wynik na obrazku w załączniku. Ale pewnie trollowałeś ;) Ale to wątek edukacyjny więc sprostowałem :]

    • Screenshot_2020-02-19_00-40-45.png
      
      
      
      
27. • 27: CommentAuthormono
    • CommentTime19 Feb 2020 zmieniony

     
    Nieee, walnąłem się z * + :) Powinno być
    

    2 3 + 1 2 + * 2 3 * 1 + +

    
    
    Edit: Chodziło mi o to, że w Twoim przykładzie końcówka nie powinna być "+ 1 +" bo poprawny wynik uzyskujesz przez przypadek. U Ciebie realizowane jest działanie
    

    (2+3)*(1+2)+(2*3)+1 = 5*3+6+1 = 15+6+1 = 22
28. • 28: CommentAuthorzbyti
    • CommentTime19 Feb 2020 zmieniony

     
    Skorzystałem z przemienności dodawania ;) Mój zapis sprowadza się do:
    
    

    2 3 + 1 2 + * 2 3 * + 1 + => (5 * 3) + (6 + 1) 
    

    
    Na stos idą w kolejności (po działaniach): 5 i 3 zmienione mnożeniem na 15 i dalej 6 po dodaniu 1 zmienione na 7 i dodaję pozostające na stosie 15 = 22.
    
    

    mono:

    poprawny wynik uzyskujesz przez przypadek
    

    
    "Nie ma przypadków, są tylko znaki" ASCII :D
29. • 29: CommentAuthorzbyti
    • CommentTime19 Feb 2020 zmieniony

     
    @mono przecież to jest kurka wodna to samo! :D Nie rozumiem, dlaczego to jest dowód na niepoprawność mojego zapisu. To co rozpisałeś (że niby jest niepoprawne) wygląda tak:
    
    

    (1+2*3)+(1+2)*(2+3) <=> (2+3)*(1+2)+(2*3)+1
    
    (2+3)*(1+2) = (1+2)*(2+3) = 15
    (1+2*3) = (2*3)+1 = 7
    
30. • 30: CommentAuthormono
    • CommentTime19 Feb 2020

     
    Ok, ok. Jeśli zlikwidujemy niepotrzebne nawiasy to masz rację. Chodziło mi o dokładne odtworzenie kolejności działań jaka była we wzorze.
31. • 31: CommentAuthorzbyti
    • CommentTime19 Feb 2020

     
    A! No to oddawaj swoją cyfrową wersję "A.D.2044" ;D
32. • 32: CommentAuthormono
    • CommentTime19 Feb 2020

     
    Jest w archiwum atarionline :P
33. • 33: CommentAuthorzbyti
    • CommentTime19 Feb 2020 zmieniony

     
    Już niedługo ;)
    
    A tak na poważnie to cenię sobie, że zechciało Ci sie skomentować w tym wątku, warto by ożyły takie sprawy :]
34. • 34: CommentAuthorzbyti
    • CommentTime19 Feb 2020

     
    Forth Benchmarks ->link<-
    
    Kto ciekaw może przepisać na Action! i porównać. Ja może się o coś tam pokuszę ale dopiero jak zrozumiem co robię :]
35. • 35: CommentAuthorzbyti
    • CommentTime19 Feb 2020 zmieniony

     
    No to mam wynik podstawowego benchmarka Yosha ->link<- czyli wykonywanie pętelki przez 2 sekundy.
    
    Bardzo słaby wynik.
    
    Do testów posłużyła mi wersja Extended fig-FORTH - APX w bazie AOL jako Extended fig-FORTH 1.1.atr.
    
    O ile sam język mi się mega (!) podoba to jego prędkość na A8 jest tylko niecałe 2x większa od BASIC'a.
    
    A gdzieś czytałem, że to jest tak blisko maszynowego i w ogóle...
    
    Sprawdzacie sami, może gdzie zrobiłem błąd? Licznik się nie przekręca jakby co.
    
    W porównani do Action! który w tym samym czasie taką pustą pętelkę wyobracał ponad 50 000 razy to marne 1090 iteracji FORTH'a nie zachęca mnie do dalszych badań.
    
    EDIT: volksFORTH w ostatniej wersji 3.8 jest nawet wolniejszy...
    
    CLSN Pascal w tym teście na A8 miał 1322 iteracje.

    • forth-yosh.png
      
      
      
      
    • volksFORTH-yosh.png
      
      
      
      
36. • 36:
       
      CommentAuthorlaoo
    • CommentTime19 Feb 2020

     
    Akurat kolejność działań we wzorze zachowuje się przy zapisie
    
    1 2 3 * + 1 2 + 2 3 + * +
    
    I to jest "koszerna" konwersja bo nie zmieniamy kolejności liczb tylko operatory.
37. • 37: CommentAuthorzbyti
    • CommentTime19 Feb 2020 zmieniony

     
    @laoo faktycznie, dobra uwaga, dzięki!
    
    To jeszcze Yosh Plus z wątku ->link<- i tyle w temacie :]
    
    

    Mad Pascal         YoshPlus: 35572 iterations in 100 ticks
    Action!            YoshPlus: 33239 iterations in 100 ticks
    Quick 1.6          YoshPlus: 16242 iterations in 100 ticks
    DurexForth C64     YoshPLus:  1526 iterations in 100 ticks
    Fast Basic 4.0 Int YoshPlus:  1458 iterations in 100 ticks
    fig-Forth 1.1      YoshPlus:   715 iterations in 100 ticks
    CLSN Pascal        YoshPlus:   487 iterations in 100 ticks
    

    • forth-yoshPlus.png
      
      
      
      
    • FastBasic-YoshPlus.png
      
      
      
      
    • FastBasic-YoshPlus-res.png
      
      
      
      
38. • 38: CommentAuthorzbyti
    • CommentTime20 Feb 2020 zmieniony

     
    fig-Forth 1.1 i 10 iteracji SIEVE
    
    

    \ Sieve Benchmark
     8192 CONSTANT SIZE   
     0 VARIABLE FLAGS  
     0 FLAGS !  
     SIZE ALLOT                         
                                                                                        
     : DO-PRIME                                                                         
       FLAGS SIZE 1 FILL  ( set array )                                                 
       0 ( 0 COUNT ) SIZE 0                                                             
       DO FLAGS I + C@                                                                  
         IF I DUP + 3 + DUP I +                                                         
            BEGIN DUP SIZE <                                                            
            WHILE 0   OVER FLAGS +  C!  OVER +  REPEAT                                  
            DROP DROP 1+                                                                
         THEN                                                                           
     LOOP                                                                               
    

    • forth-sieve.png
      
      
      
      
39. • 39: CommentAuthorzbyti
    • CommentTime20 Feb 2020 zmieniony

     
    Wszystkie programy w tabelce w najnowszych wersjach na 20.02.2020.
    

    CC65           YoshPlus:   41844 iterations in 100 ticks
    Mad Pascal     YoshPlus:   35572 iterations in 100 ticks
    Action!        YoshPlus:   33239 iterations in 100 ticks
    Quick 2.2      YoshPlus:   21320 iterations in 100 ticks
    Quick 1.6      YoshPlus:   16242 iterations in 100 ticks
    PL65           YoshPlus:    4708 iterations in 100 ticks
    FastBasic FBI  YoshPlus:    2427 iterations in 100 ticks
    fig-Forth 1.1  YoshPlus:     715 iterations in 100 ticks
    CLSN Pascal    YoshPlus:     487 iterations in 100 ticks
    
    CC65            Chessboard:   76 iterations in 150 ticks
    Mad Pascal      Chessboard:   40 iterations in 150 ticks
    Action!         Chessboard:   35 iterations in 150 ticks
    Quick 2.2       Chessboard:   27 iterations in 150 ticks
    Quick 1.6       Chessboard:   16 iterations in 150 ticks
    PL65            Chessboard:   12 iterations in 150 ticks
    
    MADS (opt)         SIEVE:    440 ticks in 10 iterations
    CC65 (opt)         SIEVE:    602 ticks in 10 iterations
    Mad Pascal (opt)   SIEVE:    644 ticks in 10 iterations
    Mad Pascal         SIEVE:    739 ticks in 10 iterations
    Action!            SIEVE:   1003 ticks in 10 iterations
    Advan BASIC (opt)  SIEVE:   1050 ticks in 10 iterations
    Quick 1.6          SIEVE:   2022 ticks in 10 iterations
    Quick 2.2          SIEVE:   2199 ticks in 10 iterations
    PL65               SIEVE:   3853 ticks in 10 iterations
    FastBasic FBI      SIEVE:   6312 ticks in 10 iterations
    Advan BASIC        SIEVE:   6800 ticks in 10 iterations
    fig-Forth 1.1      SIEVE:   8482 ticks in 10 iterations
    Turbo-BASIC XL [C] SIEVE:  16880 ticks in 10 iterations
    Turbo-BASIC XL     SIEVE:  46060 ticks in 10 iterations
    BASIC              SIEVE: 133960 ticks in 10 iterations
    

    
    
40. • 40: CommentAuthorbartgo
    • CommentTime10 Jan 2024 zmieniony

     
    Zgłaszam drobną reklamację. Fig-Forth jest powolny, ale nie aż tak, jest nieco lepiej.
    
    Po pierwsze, zamiast zmiennych lokalnych, typowo używa się stosu - więc test który polega głównie na żonglowaniu zmiennymi lokalnymi jest niemiarodajny.
    
    Po drugie, nie ma potrzeby używania C@, mnożenia przez 256 itp - słowo @ już działa na dwóch bajtach.
    
    Oczywiście wyniki "sita" nie napawają optymizmem ale może też uda mi się znaleźć metodę optymalizacji algorytmu "pod Forth", dam wtedy znać.
    
    Mój kod do porównania:
    
    

    ( ** YOSH ** )
    ( loop - 2 seconds, no vars )
    COLD
    : YOSH ( -- n )
      0 20 !
      0
      BEGIN
        100 20 @ > WHILE 1+
      REPEAT ;
    
    YOSH .
    (  2386 on APX Forth   )
    (  2330 on Antic Forth )
    (  4255 on Val Forth   )
    
    
    
    ( ** YOSH PLUS ** )
    ( v2, with variables )
    COLD
    0 VARIABLE VAR-I
    0 VARIABLE VAR-A
    0 VARIABLE VAR-B
    : YOSHP2 ( -- n )
      0 VAR-I ! 0 VAR-A ! 0 VAR-B !
      0 20 ! BEGIN
      20 @ 100 < WHILE
    	  1 VAR-A +! VAR-A @ VAR-B !
    	  1 VAR-B +! VAR-B @ VAR-A !
          1 VAR-I +! 
      REPEAT ;
      
    YOSHP2 VAR-I ?
    (  1261 on APX Forth  )
    (  1289 on Val Forth  )
     
    ( ** YOSH PLUS ** )
    ( v3, stack fun )
    
    : YOSHP3 ( -- )
      0 20 !
      0 0 0
      BEGIN
      20 @ 100 < WHILE
    	1+ >R DROP 1+ DUP 
    	1+ SWAP DROP DUP  
    	R>
      REPEAT ;
      
    YOSHP3 .
    (  1310 on APX Forth   )
    (  1289 on Antic Forth )
    (  2141 on Val Forth   )
    
    

    
    
    Faktycznie ostatni kawałek kodu jeszcze można przyspieszyć, są tam operacje nieco bez sensu (DROP / DUP), żeby tylko naśladować jak to w innych językach działa. Po co przekazywać parametr lub ustawiać zmienną skoro zaraz ją będziemy napisywać. No ale przedstawiłem taki kompromis, przykład.
41. • 41:
       
      CommentAuthorKaz
    • CommentTime10 Jan 2024

     
    Dobra robota, Bartku!
42. • 42:
       
      CommentAuthorjhusak
    • CommentTime10 Jan 2024

     
    Trzeba by dodać llvm na 6502 do testów :)
43. • 43:
       
      CommentAuthorjhusak
    • CommentTime11 Jan 2024 zmieniony

     
    Popchnąłem llvm-mos i po drobnych poprawkach mamy:
    

    CC65           YoshPlus:   41844 iterations in 100 ticks
    llvm-mos -O1   YoshPlus:   41718 iterations in 100 ticks
    Mad Pascal     YoshPlus:   35572 iterations in 100 ticks
    Action!        YoshPlus:   33239 iterations in 100 ticks
    Quick 2.2      YoshPlus:   21320 iterations in 100 ticks
    Quick 1.6      YoshPlus:   16242 iterations in 100 ticks
    PL65           YoshPlus:    4708 iterations in 100 ticks
    FastBasic FBI  YoshPlus:    2427 iterations in 100 ticks
    fig-Forth 1.1  YoshPlus:     715 iterations in 100 ticks
    CLSN Pascal    YoshPlus:     487 iterations in 100 ticks
    
    llvm-mos -O3    Chessboard:   154(!) iterations in 150 ticks
    CC65            Chessboard:   76 iterations in 150 ticks
    Mad Pascal      Chessboard:   40 iterations in 150 ticks
    Action!         Chessboard:   35 iterations in 150 ticks
    Quick 2.2       Chessboard:   27 iterations in 150 ticks
    Quick 1.6       Chessboard:   16 iterations in 150 ticks
    PL65            Chessboard:   12 iterations in 150 ticks
    
    MADS (opt)         SIEVE:    440 ticks in 10 iterations
    CC65 (opt)         SIEVE:    602 ticks in 10 iterations
    Mad Pascal (opt)   SIEVE:    644 ticks in 10 iterations
    Mad Pascal         SIEVE:    739 ticks in 10 iterations
    llvm-mos -O3       SIEVE:    927 ticks in 10 iterations
    Action!            SIEVE:   1003 ticks in 10 iterations
    Advan BASIC (opt)  SIEVE:   1050 ticks in 10 iterations
    Quick 1.6          SIEVE:   2022 ticks in 10 iterations
    Quick 2.2          SIEVE:   2199 ticks in 10 iterations
    PL65               SIEVE:   3853 ticks in 10 iterations
    FastBasic FBI      SIEVE:   6312 ticks in 10 iterations
    Advan BASIC        SIEVE:   6800 ticks in 10 iterations
    fig-Forth 1.1      SIEVE:   8482 ticks in 10 iterations
    Turbo-BASIC XL [C] SIEVE:  16880 ticks in 10 iterations
    Turbo-BASIC XL     SIEVE:  46060 ticks in 10 iterations
    BASIC              SIEVE: 133960 ticks in 10 iterations
    

    
    
    UWAGA.
    Przy 154 iteracjach na 150 ramek dla llvm-mos sprawdziłem dokładnie, czy czegoś nie wyrugował. Dla różnych opcji -O1,-O2,-Oz,-Os jest to ca 50, ca 70, ale akurat dla -O3 jest to prawdziwe 154! CZAD
    
    UWAGA 2.
    Przy YoshPlus inne optymalizacje dawały od ca 8000 (bez optymalizacji), poprzez ca 9000 (optymalizacje -Oz, -Os, -O2, -O3.)
44. • 44: CommentAuthorbartgo
    • CommentTime11 Jan 2024 zmieniony

     
    Ho, ho... gdzie można zobaczyć kod powyższych testów tego llvm-mos? Plus jakieś przykłady typowych programów? Strona ->link<- wydaje się bardzo opisowa, przykłady są porozbijane.
    
    EDIT: są przykłady kodu, pięknie -- ->link<-
    
    Może się zepnę kiedyś i dopiszę testy dla foco65, chyba dam radę... jestem ciekaw, czy będzie bliżej środka czy czołówki. Z jednej strony to xasm ale z drugiej, opakowanie Forth-a.
45. • 45: CommentAuthortebe
    • CommentTime11 Jan 2024

     
    copy/paste i nie sprawdzam co wklejam, pogratulować
    
    wyniki dla MadPascala są dostępne na stronie projektu, na githubie
    
    ->link<-
    
    oczywiście jeśli ktoś nie potrafi przesunąć strony w dół, to podaję:
    
    

    Mad Pascal     YoshPlus:   41933 iterations in 100 ticks
    
    Mad Pascal      Chessboard:   88 iterations in 150 ticks
    
    Mad Pascal (opt)   SIEVE:    577 ticks in 10 iterations
    Mad Pascal         SIEVE:    658 ticks in 10 iterations
    

    
    
    wynik 154-156 dla Chessboard można otrzymać przy rozpętleniu głównej pętli, w załączniku

    • chessboard_156.zip
46. • 46:
       
      CommentAuthorjhusak
    • CommentTime11 Jan 2024 zmieniony

     
    Ktoś ma dziś gorszy dzień?
    
    Żeś nie sprawdził przedtem, to nie było uwzględnione. Ja nie będę wszystkich wyników sprawdzał, zrobił to Zbyti na ówczesnych wersjach.
    
    Podejrzewam, że coś tu llvm-mos napowywijał w podobnym stylu, typu rozwinął _najgłębszą_ pętlę. Próbowałem wypluć rezultat, bo mnie to ciekawi, ale na razie bez sukcesu, dzieciaki spać się same nie położą, chociaż są już prawie dorosłe :P
47. • 47:
       
      CommentAuthorjhusak
    • CommentTime11 Jan 2024 zmieniony

     
    Tak, po rozwinięciu wewnętrznej pętli mamy w llvm-mos 156 ramek.
    Czyli llvm-mos zrobił sam to, co należało. Brawo. Jako jedyny.
    
    W reszcie przypadków nie jest tak wydajny, jak CC65 czy MadPascal, co jest zastanawiające, przy całej tej maszynerii...
    
    Okazuje się, że dla 6502 te zaawansowane kompilatory potrafią zoptymalizować nieoptymalny kod, ale optymalny to już nie bardzo. Czyli dobrze jest pisać optymalny kod i kompilować prostszym kompilatorem, niż nieoptymalny i mieć naiwną (z reguły) nadzieję, że kompilator zrobi porządek.
    
    Oczywiście - jeśli w grę wchodzą dzisiejsze procesory - to sprawa się zmienia diametralnie - ogrom wiedzy związany z optymalizacją kodu na taki procesor nie pozwala swobodnie kodować w asemblerze i tu takie zaawansowane kompilatory są niezastąpione.
    
    ---------------- edit ----------------
    Sprawdziłem kod niezoptymalizowany dla checkboard.c, bo były 2 różne dla cc65 i llvm, przez co cc65 miał fory. Poprawiłem kod checkboard.pas z repo madpascala, aby był tożsamy z kodem w c.
    Więc taki niezoptymalizowany kod checkboard.c identyczny dla trzech kompilatorów:
    
    llvm-mos -O3, rozwija pętlę, 155 razy, długość 5424.
    llvm-mos -O2 - nie rozwija pętli(?) - 59 razy., długość 5543 bajty
    llvm-mos -O1, -Os, -Oz - po uruchomieniu nie działa dobrze/zawiesza się
    llvm-mos bez optymalizacji - krzaczy grafikę, ale 8 razy narysował, długość 6475.
    cc65 -Osir - 27 razy, długość 3734 bajtów.
    cc65 -O - 22 razy, długość 3695 bajtów.
    cc65 bez optymalizacji 4(!) razy, długość 4006 bajtów.
    
    mp wykonał kod 30 razy, za to długość (z opcją -x): 884 bajty.
    
    --- edit 2b ---
    
    (Stan na styczeń 2024)
    
    po usunięciu printf i graphics ilość kodu w cc65 spada do 841 bajtów, natomiast w llvm-mos -Os do 219! (-O3 237) A w mp do 399.
    CC ma sporo kodu "startup", podczas, gdy llvm nie ma go wcale (przynajmniej nie znalazłem, może parę bajtów).
    
    --- edit 3 ---
    pozwoliłem sobie to tu wkleić lokalnie, bo oficjalnie autorzy llvm-mos proszą, żeby nie upubliczniać benchmarków, bo to się intensywnie zmienia. Jeśli będzie z tym problem - usunę. Jednak, uważam, że wiedzą trzeba się dzielić.