Shop OBEX P1 Docs P2 Docs Learn Events
re: ULTIMATE List of Propeller Languages & speed — Parallax Forums

re: ULTIMATE List of Propeller Languages & speed

koehlerkoehler Posts: 598
edited 2011-02-18 20:34 in Propeller 1
I did a search through the ULTIMATE list, however didn't see anything related right off. I was wondering if anyone has done any testing on the currently available languages similar to The Computer Language Benchmarks Game http://shootout.alioth.debian.org/
Wondering if anyone has done any sort of benchmarking across the range.

While I'm guessing Assembler is going to be the topper, I'm wondering if one of the Forth or C versions is better/faster than the other. I wouldn't mind picking up another language, however would prefer to pick one that is one of the faster ones.

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2011-02-16 18:03
    "better" and "faster" depend too much on the particular application and the experience of the program author to be useful terms by themselves. That's why you won't see much in terms of benchmarking. It's usually not useful.

    For many applications, assembly is going to be the way to write the fastest programs, but that's not useful for complex programs with lots of data structures requiring subscripting and pointer use. For that, assembly results in much more complex programs that would probably be more error-prone. Assembly also takes a lot more storage than something like Spin.

    Your duplicate thread has been deleted.
  • $WMc%$WMc% Posts: 1,884
    edited 2011-02-16 18:46
    If you want speed,Try this
    '
    PropBasic
    '
    http://forums.parallax.com/showthread.php?118611-Download-PropBASIC-here...-00.01.04
  • koehlerkoehler Posts: 598
    edited 2011-02-16 19:01
    OK, I agree better/faster is somewhat amibiguous. I would think that many people avoid Assembler for exactly the reason you stated.
    But then, how useful is it to have 101 dalmat... languages available if there is no general metric to compare against? The average User is going to have either Assembler (fast), or Spin (not so much). It would seem that for the time and effort being spent by folks in creating these ports, having a benchmark would quite possibly incentivize people to use their work, win-win.

    One can usually get a hint at speed simply by name, Assembler<C<Basic<Spin. But then I thought I read a post about someone using a Basic to create another
    Basic? I don't know, maybe I got the wrong impression and no one is really using any of them outside of PASM, Spin, and Catlina or Femto?

    At this point, if I need more speed than Spin can give me, and I'm disinterestd in going the Assembler route, I can only pick one of the available offerings at random.
  • Mike GreenMike Green Posts: 23,101
    edited 2011-02-16 19:17
    PropBasic compiles into assembly, but tends to use a semi-interpreted assembly form known as LMM (Large Memory Model) which has a 3:1 to 4:1 speed penalty over straight assembly but gains the ability to have the code reside in main (hub) memory like with Spin. The C compilers also use LMM, but Catalina C also has modes that can use external SRAM (at an additional speed penalty) for more storage. There's an embeddedBasic that's written using PropBasic and also compiles into LMM form.
  • RossHRossH Posts: 5,519
    edited 2011-02-16 19:39
    Hi koehler,

    There was some benchmarking done here, but not much has been added recently.

    Tha main problem seems to be finding a benchmark suitable for the Propeller - for example did you look at the memory sizes of the benchmarks in the link you included? In the whole list I only found a single instance of a program that required less than 200kb to run - in any language! Some of them appear to require gigabytes!

    To be suitable for the Propeller, the benchmark has to fulfill all the following criteria:
    • It must be readily implemented in all languages to be compared (Spin, Basic, Forth, PASM, C, etc).
    • It must compile to less than 32k in all languages (since some compilers cannot use XMM).
    • It should not use floating point (since some compilers do not have floating point support).
    • It shoud not use a file system (since some compilers do not have file system support).
    • It should not be too recursive (since some compilers have severely limited stack sizes).
    • It should be representative enough to be useful in comparing real-world programs.
    Can anyone add to this list of requirements? Or propose a suitable benchmark program that meets them? Then the benchamrking itself becomes fairly trivial.

    Ross.
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-02-16 19:43
    There was a thread a while back about benchmarking code on the Propeller and as I recall there were as many disparate points and opinions on how to accomplish it as the number of craters on the Moon. The discussion went into the virtues of FP over INT and visa versa and numerous other points that varied from language to language, some of which favored one language over another. This is just one reason no one has come forth to do a benchmark across the board for every language.

    What is recommended is select a few of the languages that you're interested in and run some benchmarks that hold some value and consideration points for your project and interests. Each language is highly unique and specific and trying to apply a general across the board formula is challenging at best.

    Additionally for most languages there is a link to the author's original thread. Many of the authors have some sample programs and their own benchmark tests. You could look these up for the languages that interest you and start from there.
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-02-16 19:47
    RossH wrote: »
    Hi koehler,

    There was some benchmarking done here, but not much has been added recently.

    Tha main problem seems to be finding a benchmark suitable for the Propeller - for example did you look at the memory sizes of the benchmarks in the link you included? In the whole list I only found a single instance of a program that required less than 200kb to run - in any language! Some of them appear to require gigabytes!

    To be suitable for the Propeller, the benchmark has to fulfill all the following criteria:

    • It must be readily implemented in all languages to be compared (Spin, Basic, Forth, PASM, C, etc).
    • It must compile to less than 32k in all languages (since some compilers cannot use XMM).
    • It should not use floating point (since some compilers do not have floating point support).
    • It shoud not use a file system (since some compilers do not have file system support).
    • It should not be too recursive (since some compilers have severely limited stack sizes).
    • It should be representative enough to be useful in comparing real-world programs.

    Can anyone add to this list of requirements? Or propose a suitable benchmark program that meets them? Then the benchamrking itself becomes fairly trivial.

    Ross.
    I would be in favor of three simple tests. One, add some integers 1+2+3=X and do it several thousand times. Two, time a loop for several thousand iterations. Three, ..
  • RossHRossH Posts: 5,519
    edited 2011-02-16 20:51
    Humanoido wrote: »
    I would be in favor of three simple tests. One, add some integers 1+2+3=X and do it several thousand times. Two, time a loop for several thousand iterations. Three, ..

    The problem with these benchmark is that they are not representative of the performance of real-world programs. They are also extremely easy for a compiler writer to subvert by "optimizing" its performance in such specific cases - subverting the whole point of the benchmark. There is no harm in including these as a small part of a broader benchmark which does many different operations, but alone each one would tell you very little.

    Ross.
  • Heater.Heater. Posts: 21,230
    edited 2011-02-17 00:25
    Rossh,
    Elsewhere I have suggested using my Fast Fourier Transform as a bench mark. I think it meets your criteria. I have
    implementations in PASM, Spin and C that have a very similar form. I'll clean up and post the C vertion soon.
  • RossHRossH Posts: 5,519
    edited 2011-02-17 00:41
    Heater. wrote: »
    Rossh,
    Elsewhere I have suggested using my Fast Fourier Transform as a bench mark. I think it meets your criteria. I have
    implementations in PASM, Spin and C that have a very similar form. I'll clean up and post the C vertion soon.
    Hi Heater,

    That may be a good choice - but does it use floating point? If so, that might rule out a Forth version - I don't think PropForth does floating point (I may be wrong about this).

    Ross.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-02-17 01:40
    A FFT sounds a very good benchmark program.

    Re
    It would seem that for the time and effort being spent by folks in creating these ports, having a benchmark would quite possibly incentivize people to use their work, win-win.

    Speed is important but it may not be the only criteria. For example, I'm working on BCX because 1) I want to use strings, 2) I know Basic string handling better than C string handling, and 3) I want to write huge programs, more than 100k.

    AFAIK no other Propeller language can do all this. Others will almost certainly have different criteria.

    Humanoido has a very useful thread with all the languages listed. I think that is a huge selling point for the Propeller for someone coming from another micro - they can look through that list and hopefully there is at least one language they have seen before. It is more flexible than the Arduino, where you have to program in C, or the Picaxe, where you have to program in Basic.

    Re
    At this point, if I need more speed than Spin can give me, and I'm disinterestd in going the Assembler route, I can only pick one of the available offerings at random.

    I'd probably suggest starting with Spin. And one nice thing you can do with the propeller is run parts of the spin program in parallel using the cogs, and get a speed increase that way.
  • Heater.Heater. Posts: 21,230
    edited 2011-02-17 03:32
    Rossh, the FFT uses fixed point arithmetic.

    And this highlights a theme here. Choice of language is not all about speed. If you really wanted to work with floating point you might have an easier time using C than Spin. If you want to do a lot of work with strings BASIC might be your choice as Dr_A says. And so on.
  • BeanBean Posts: 8,129
    edited 2011-02-17 04:40
    Mike Green wrote: »
    PropBasic compiles into assembly, but tends to use a semi-interpreted assembly form known as LMM (Large Memory Model) which has a 3:1 to 4:1 speed penalty over straight assembly but gains the ability to have the code reside in main (hub) memory like with Spin. There's an embeddedBasic that's written using PropBasic and also compiles into LMM form.

    Mike, I know you are somewhat of a fan of PropBasic, but I just want to clairify...

    PropBasic can compile to native PASM or LMM. By default it generates native code, by adding a LMM option to the PROGRAM command it will generate LMM code. You decide, not the compiler.

    Embedded BASIC is a complete BASIC language all in the propeller (kinda like the OLD days). It is interpreted BASIC.

    I think Parallax should provide a benchmark program because any program provided by a language developer is surely going to show off the strength of their language. It can be provided in a generic high level flowchart that should be fairly easy to convert to most any language. Benchmarks for speed and size should be provided (as one often trades one off for the other).

    Maybe we could submit two version of the benchmark program. One optimized for speed, and one for size.

    The would be a great benefit to propeller users since there are SO many languages available with no clear way to judge one against the other.

    Bean
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-02-17 06:33
    Bean wrote: »
    Embedded BASIC is a complete BASIC language all in the propeller (kinda like the OLD days). It is interpreted BASIC. Bean
    FemtoBasic resides inside the Propeller chip. What is the difference with Embedded BASIC?
  • SapiehaSapieha Posts: 2,964
    edited 2011-02-17 07:10
    Hi Humanoido.

    One writen in Spin (Slow) --- Other compiles directly as PASM --- (Fast)

    Humanoido wrote: »
    FemtoBasic resides inside the Propeller chip. What is the difference with Embedded BASIC?
  • BeanBean Posts: 8,129
    edited 2011-02-17 07:42
    Embedded Basic is pretty much the same as FemtoBasic only faster and with different features. It can run stand-alone with a PS/2 keyboard and TV, or using PST or using Telnet (it requires a recompile for the different configurations).

    PropBasic compiles to assembly.
    Embedded Basic is an interpreter like FemtoBasic.

    Embedded Basic is written using PropBasic...It's a little confusing. But Embedded Basic is a Basic interpreter that is written in a Basic compiler (PropBasic).

    Bean
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-02-17 08:52
    Thanks Sapieha and Bean. So how complete is Embedded BASIC, i.e. is there a current manual for it with commands and details? I do know it has commands that can be read by by looking at the pbas code version. How would you characterize it compared to FemtoBASIC in terms of function capabilities? Thank you.

    Just curious. The one thing I miss in all of these prop basic languages is good comprehensive string handling capability. I suppose we will never reach the level that Extended BASIC had for the TRS-80 Model 1? It seems that every program I want to convert over is heavy on strings, for example, mid, left, right$ etc..
  • BeanBean Posts: 8,129
    edited 2011-02-17 10:05
    I have attached a file that describes Embedded Basic.

    The problem is that it was started as a lark and has had features bolted-on as I went. What is REALLY needed is for someone to make an actual concrete spec for it. I know it could be much smaller (giving more space for BASIC code) but it would need a complete makeover.

    I don't use femtoBasic much so I can't really compare it.

    As for speed, Embedded Basic can do 1000 FOR...NEXT loops in 28 milliseconds (or 28 microseconds per loop).

    Bean
    txt
    txt
    embeddedbasic.txt
    6K
  • koehlerkoehler Posts: 598
    edited 2011-02-17 19:09
    Mike, RossH, et al,

    Thanks, it looks like PropBasic is the way to go most likely, having not really compared feature sets, if Basic is desired.

    I realize the Language Shootout examples would not be amenable to the Prop, it was really just to give an idea of what could be done if there was any interest. While no program is going to be perfect in giving a definitive answer as to which is 'better', the Shootout does the next best thing by using an array of programs which target different sub-systems, and then does some averaging across the results. This seems like a pretty reasonable approach, and on a much smaller scale, say 2-3 programs, could be implemented on the Prop, if the authors or others were interested.
    One program might be a bit-banging serial port, another might do the prop graphics demo, another might be the 8 Talking Cogs, etc.
    Most of us are here are out of school I would think, and free time is a luxury.
    For all of these 'languages' to be of real use to many, there needs to be some way of comparing them to PASM or Spin, IMHO.
    If Catalina, PropBasic, Forth, or whatever had scores for each of these three demo's it would be much easier for one to make a decision based upon how a prospective language scored in one of the the three areas that was congruent to ones potential application.

    I am not calling for Parallax to do anything, just hoping a few of the authors might find this worth considering as it should help show their works strength, and yes weaknesses as well. It might encourage some healthy competition too, who knows.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-02-17 20:34
    Humanoido said
    The one thing I miss in all of these prop basic languages is good comprehensive string handling capability. I suppose we will never reach the level that Extended BASIC had for the TRS-80 Model 1? It seems that every program I want to convert over is heavy on strings, for example, mid, left, right$ etc..

    These are the string functions for BCX.
    BCX String Procedures 
BCOPY statement 
CONCAT statement 
CONTAINEDIN function 
DEL$ function 
ENC$ function 
Extended String Literal statement 
EXTRACT$ function 
FINDINTYPE function 
INS$ function 
INCHR function 
INSTR function 
INSTRREV function 
IREMOVE$ function 
IREPLACE$ function 
JOIN$ function 
LCASE$ function 
LEFT$ function 
LEN function 
LIKE function 
LPAD$ function 
LTRIM$ function 
MCASE$ function 
MID$ function 
MID$ statement 
PEEK$ function 
POKE function 
REDIM statement 
REDIM PRESERVE statement 
REMAIN$ function 
REMOVE$ function 
REPEAT$ function 
REPLACE$ function 
RETAIN$ function 
REVERSE$ function 
RIGHT$ function 
RPAD$ function 
RTRIM$ function 
SPACE$ function 
SPRINT function 
STR$ function 
STRTOKEN$ function 
STRIM$ function 
STRING$ function 
SYSSTR function 
TALLY function 
TRIM$ function 
UCASE$ function 
USING$ function 
VERIFY function

    In terms of scoring languages, many of them are just pasm in disguise. BCX compiles to C. C compiles to LMM, and LMM pasm is simply pasm running a bit slower than real pasm. Prop Basic compiles directly to pasm. And if you want to do things like a bit bang serial port, you would do these directly in pasm anyway.
    It might encourage some healthy competition too, who knows.

    No shortage of competition, and that can only be a good thing!
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-02-18 00:08
    Bean wrote: »
    I have attached a file that describes Embedded Basic. The problem is that it was started as a lark and has had features bolted-on as I went. What is REALLY needed is for someone to make an actual concrete spec for it. I know it could be much smaller (giving more space for BASIC code) but it would need a complete makeover. I don't use femtoBasic much so I can't really compare it. As for speed, Embedded Basic can do 1000 FOR...NEXT loops in 28 milliseconds (or 28 microseconds per loop). Bean
    Bean, wow, this is really a great accomplishment as seen by the statements in this text document, even it could be expanded with more explanations - I see a lot of incorporated statements that can make programming more easy. It's interesting how these things start with a spark of interest and develop into complete things that are highly useful. I agree, it would be great if someone could pick it up and continue to support it. How many statements were in the benchmark for-next loop? If just two, that sounds like 71,428 instructions per second! Very nice!
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-02-18 00:13
    Dr_Acula,

    Indeed BCX is totally powerful in terms of string handling capabilities, and impressive features. BCX converts BASIC to C. What I need is this powerful string handling capability to remain in BASIC.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-02-18 18:23
    Can you explain more? Does it matter that it converts to C on the way through to PASM? I have an IDE with a one touch "compile" button and most of the time never even look at the C.
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-02-18 19:04
    Dr_Acula wrote: »
    Can you explain more? Does it matter that it converts to C on the way through to PASM? I have an IDE with a one touch "compile" button and most of the time never even look at the C.
    What I am looking for is this - I power on the prop and a BASIC cursor appears on the screen. I can type in BASIC statements to make a program, save it to eeprom, or type run. Can it convert it to C? Yes, as long as I don't know about it.

    I can also make my program auto boot when the Prop powers on. Embedded BASIC by Bean works like this. Of all the computers and systems I've tried over many years, I like this type of system the most for pure enjoyment and fun projects. I especially liked computers in the past which had BASIC in ROM. So keeping it in eeprom is the next best thing.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-02-18 20:34
    Ah, I get it. So this is the difference between an "interpreter" and a "compiler"

    Basic tended to have interpreters. C tended more towards compilers. My first Basic was MBASIC and BASCOM, which gave you the best of both worlds - an interpreter and a compiler.

    I took a look at Basic interpreters yesterday - nothing stands out as possible to run on the propeller. Yet. But it would be a matter of searching through looking for one that a) gives you the source code and b) where the source is in a language you can write on the propeller (Basic itself, or more likely, C).

    My propeller has Kyedos permanently on the eeprom now. So - hit the reset button, kyedos comes up about 1 second later, type "CPM" and CPM comes up about 3 seconds later, then type "MBASIC" and I can write Basic programs in the interpreter.
    10 PRINT "Hello World"
    RUN
    Hello World

    What would be cool would be the MBASIC commands in Bean's Basic.
    10 A$="Fuzzy Wuzzy was a bear. Fuzzy Wuzzy had no hair. Fuzzy Wuzzy wasn't very fuzzy, was he?"
    20 B$=LEFT$(A$,11)
    30 PRINT B$
Sign In or Register to comment.