HIVE-Project

josto hat geschrieben:GCC ist beim Fibonacci Programm ca. 3-mal schneller als SmallC.
(((...)))
Ingesamt also sehr ernüchternd....

Nö!

Ganz im Gegentum!

In GCC stecken mittlerweile sicher nicht mehr in Mannjahren sondern eher in Mannjahrtausenden zu messender Aufwand. Der Vergleich mit GCC ist einfach nicht fair!
Und Propeller-Opcode-LMM ist mit einem Interpreter für einen komplett andersartigen Befehlssatz auch nicht wirklich fair vergleichgbar.
Wenn Du einen faireren Vergleich suchst, dann vergleich lieber SmallC mit Spin... beide werden in nichtnativen Code kompiliert, das ist vergleichbarer...

Ok, du hast recht. Spin ist noch schlechter

Wieder ein Faktor 3.

Hervorragende Erfolg! Gratuliere!

Ich hab keine Daten fur fbcc, aber das wird wohl etwa gleich sein (oder ein wenig langsamer: fbcc Bytecodes sind nicht so optimiert wie im ZPU, wie schon am Anfang bemerkt). Sehe aus nach eine Benchmark mit XMM: limitierte Speicherbandbreidte bringt small-c vielleicht nog dichter an gcc dran.

Hatte nicht gedacht das Spin nur auf 1/3 der Geschwindigkeit geht: auch Spin ist eine VM im LMM modus.

Code: Alles auswählen

PUB strcpy(a, b)
  repeat while (byte[a++] := byte[b++])

wird durch BST uebersetzt nach:

Code: Alles auswählen

Addr : 0018: Label0002
Addr : 0018:          6A AE  : Variable Operation Local Offset - 2 Assign VAR++ post inc Long Push
Addr : 001A:             80  : Memory Op Byte POP Address READ 
Addr : 001B:          66 AE  : Variable Operation Local Offset - 1 Assign VAR++ post inc Long Push
Addr : 001D:          82 80  : Memory Op Byte POP Address ASSIGN Write Push
Addr : 001F: JZ Label0004
Addr : 001F:          0A 02  : jz Address = 0023 2
Addr : 0021: Label0003
Addr : 0021: JMP Label0002
Addr : 0021:          04 75  : Jmp 0018 -11  
Addr : 0023: Label0004
Addr : 0023:             32  : Return

Vielleicht wueste eine alte Spin Hase in dieses Forum wieso Spin so Traege ist ??

Ich glaub es last sich was basteln aus die BMA und SPUD debuggers, fur beide gibt es Quelle. Beiden benutzen ein bstc List Datei um von Adressen zum Quelle zu gehen. Ich hab noch kein funktionierendes Spin compiler in C gefunden, und bstc is nicht offene Quelle glaub Ich. Vielleicht ist Sphinx brauchbar fur dieses Zweck. Vielleicht können wir Brad mal Bitten um bstc Quelle frei zu geben.

Hab mal Sphinx genauer angesehen. Compilation von Spin seht sich nicht sehr Schwierig aus -- aber die Probleme sind vielleicht in generation von optimierte Bytecode Sequenzen. Sphinx macht keine Optimierungen.

Also an die Arbeit, eine offene Quelle Hive Spin Compiler in C. Anbei das erste Teil, eine Spin Lexer. Wer Zeit hat, bitte mahl testen (einfach mahl einige spin Quellen anbieten und sehen ob das ohne Crashes oder Fehlermeldungen durch geht).

Paul

paulruiz hat geschrieben:Vielleicht wueste eine alte Spin Hase in dieses Forum wieso Spin so Traege ist ??

Die Funktion fibo() sieht durch BST übersetzt auch nicht so übersichtlich aus:

Code: Alles auswählen

30                        if n1 < 2
Addr : 00AC:             64  : Variable Operation Local Offset - 1 Read
Addr : 00AD:          38 02  : Constant 1 Bytes - 02 - $00000002 2
Addr : 00AF:             F9  : Math Op <     
Addr : 00B0: JZ Label0002
Addr : 00B0:          0A 04  : jz Address = 00B6 4
31                          return n1
Addr : 00B2:             64  : Variable Operation Local Offset - 1 Read
Addr : 00B3:             33  : Return value  
Addr : 00B4: JMP Label0003
Addr : 00B4:          04 0F  : Jmp 00C5 15   
Addr : 00B6: Label0002
33                          return fibo(n1 - 1) + fibo(n1 - 2)
Addr : 00B6:             00  : Drop Anchor Push 
Addr : 00B7:             64  : Variable Operation Local Offset - 1 Read
Addr : 00B8:             36  : Constant 2 $00000001
Addr : 00B9:             ED  : Math Op -     
Addr : 00BA:          05 02  : Call Sub 2    
Addr : 00BC:             00  : Drop Anchor Push 
Addr : 00BD:             64  : Variable Operation Local Offset - 1 Read
Addr : 00BE:          38 02  : Constant 1 Bytes - 02 - $00000002 2
Addr : 00C0:             ED  : Math Op -     
Addr : 00C1:          05 02  : Call Sub 2    
Addr : 00C3:             EC  : Math Op +     
Addr : 00C4:             33  : Return value  
Addr : 00C5: Label0004
Addr : 00C5: Label0003
Addr : 00C5:             32  : Return

Wenn der Code jetzt in einer 8 Bit VM ausgeführt wird, bei der jeder Opcode relativ aufwendig interpretiert werden muss, wird die Sache schon klar.
Die SmallC VM mit ihrem 16-Bit Opcode (direct threaded code) dürfte da effizienter sein.

Aber Fibonacci ist nur ein Beispiel, bei anderen Benchmarks könnte die Sache ganz anders aussehen. Es bleibt spannend...

paulruiz hat geschrieben:Hatte nicht gedacht das Spin nur auf 1/3 der Geschwindigkeit geht: auch Spin ist eine VM im LMM modus.
Code: Alles auswählen
PUB strcpy(a, b)
  repeat while (byte[a++] := byte[b++])

Nur mal am Rande, schon allein die Auswahl der falschen Variable kann Dir Dein Timing so ziemlich in den Boden fahren, e.g. Zugriff zu den ersten 8 Variablen ist optimiert, alles was danach kommt leidet unter einer laengeren Kodierung.

Fuer das obige Beispiel, aender es mal ab in

Code: Alles auswählen

PUB strcpy(a, b)
  repeat
  while (byte[a++] := byte[b++])

und schon ist es schneller (und beansprucht weniger Platz). Davon abgesehen, niemand wuerde strcpy in dieser Form nutzen. Viel eher dann schon etwas in der Richtung:

Code: Alles auswählen

PUB strcpy(a, b)
  bytemove(a, b, strsize(b)+1)

Kam letztlich auch wieder im Prop-Forum auf (Spin speed up).

Kam letztlich auch wieder im Prop-Forum auf (http://forums.parallax.com/showthread.p ... n-speed-up).

Das war eine gute Link - hab Ich mit Interesse und Freude gelesen. In 2008-2009 haben drei Leute (skippy, cluso99 und jazzed) ziemlich viel erreicht. Fur Projekte wie ZiCog, CP/M, C auf LCC basis und ein schnelleres Spin Interpreter haben sie sich die Debugging Tools gebaut die auch Ich benotigen wird fur PDP11 und altes Unix. Gleiche Probleme, gleiche Losungen.

Hab wieder einige Sachen gelernt, zum Bleispiel das man im Cog Bereich 0x1f0..0x1f3 vier PASM Instruktionen verstekken kan mit eine Debugger Kerne ... also unsichtbar fur normale PASM Programme. Weiter, Spin ist so Trage weil man da zu viel in 500 Longs hat gesteckt: kompakte Programmen war wichtiger als schnelle. Sie glauben bis zu 50% besser mit heutigen Spin Bytecode und zweifach besser mit ein langeres Bytecode. Stimmt mit josto's Datenpunkt

Aber auch gelernt das Sie eine offene Quelle Spin Compiler entbehrt hatten:

Originally Posted by cluso99 on 01-03-2012, 09:44 PM
Originally Posted by jazzed on 01-03-2012, 07:22 PM Having an LMM-like Spin interpreter would be useful for various reasons. An LMM-like interpreter would allow for using high density Spin and would be faster of course although single threaded (the slow interpreter could still be used for multi-cog spin threads). Having an open source Spin compiler would enable many more interesting things like 32 bit Spin programs, etc....
Yes, an open sourced spin compiler (and pasm compiler) would have opened a lot of things up for developing the prop. Even with the problems with PropTool source, it would have helped the march.

Ich glaub (aber bin da nicht Sicher) das die Drei 'ausgespielt' sind mit Prop I und jetzt auf Prop II warten fur neue Abenteuer.

Paul

paulruiz hat geschrieben:Hab wieder einige Sachen gelernt, zum Bleispiel das man im Cog Bereich 0x1f0..0x1f3 vier PASM Instruktionen verstekken kan mit eine Debugger Kerne ... also unsichtbar fur normale PASM Programme.

Wenn's danach geht kannst Du insgesamt 511 Befehle haben (auch wenn dira nicht gerade guenstig dafuer ist, der Vollstaendigkeit halber zaehl ich es aber mit, Beispiel hier). Einzige Ausnahme ist vscl ($1FF), dort kannst Du i.d.R. nur Daten ablegen.

Nachtrag: Um genau zu sein, man kann dort ($1FF) code ausfuehren aber es bedarf einiger Vorbereitung(en). Im Normalfall, e.g.

Code: Alles auswählen

        org     0
        mov     $1FF, insn
        jmp     #$1FF

insn    hubop   $1FF, #%10000_000           ' reset

funktioniert das nicht. Das Programm ist in dem Fall in einer Endlos-Schleife gefangen.

Seh mal (Danke 'yeti'!)
http://forums.parallax.com/showthread.p ... ler-in-C-C
Ich bin sehr Froh: ein Bauteil das innerhalb 24 Stunden da ist und ohne Arbeit. War nur alles so einfach!

Die grosse ist 10.000 Zeilen, etwa 2-Fach was Ich gedacht hatte, aber immer noch schlank. Vielleicht lasst es sich auch nog abspecken. Am moment wird nog kein Debug info generiert, aber das ist vielleicht nicht so schwer um zu machen.

Hab jetzt auch 'spinsim' gefunden, und das seht sich sehr gut aus. CVM Kompiliert mit offene Quelle Spin Compiler funktioniert mit spinsim, und auch mit SPUD / BMA Debugger. Yippee! Fast alle Bauteile sind da, nur nog alles zusammen basteln.

paulruiz hat geschrieben:Hab jetzt auch 'spinsim' gefunden, und das seht sich sehr gut aus. CVM Kompiliert mit offene Quelle Spin Compiler funktioniert mit spinsim, und auch mit SPUD / BMA Debugger. Yippee! Fast alle Bauteile sind da, nur nog alles zusammen basteln.

--> spinsim ... durchdrehen auch auf dem PC

HIVE-Project

Ich hatte einen Traum...

Re: Ich hatte einen Traum...

Re: Ich hatte einen Traum...

Re: Ich hatte einen Traum...

Re: Ich hatte einen Traum...

Re: Ich hatte einen Traum...

Re: Ich hatte einen Traum...

Re: Ich hatte einen Traum...

Re: Ich hatte einen Traum...

Re: Ich hatte einen Traum...

Re: Ich hatte einen Traum...