Of course running an emulator to run an interpreter is going to be awful slow. It's kind of a clunky way to go anyway.
Isn't anything that's not PASM really an emulator? For example the Spin VM or gcc"s CMM are emulators for a 32 bit machine written in PASM. The source is then compiled to target this emulator and runs out of hub ram. So if an interpreter was written in C it should in theory be as fast as one that targeted ZiCog but was written in Z80 assembly.
Isn't anything that's not PASM really an emulator? For example the Spin VM or gcc"s CMM are emulators for a 32 bit machine written in PASM. The source is then compiled to target this emulator and runs out of hub ram. So if an interpreter was written in C it should in theory be as fast as one that targeted ZiCog but was written in Z80 assembly.
I guess someone needs to fire up ZiCOG and try it. Also, PropGCC can compile to native PASM code running in a COG or LMM code which is still fetched one long at a time but isn't interpreted.
The recursive algorithm that we're using here does about 2^(n-1) calls. For n equal to 26 that would be about 2^25, which is about 33 million. It seems like you must be using a different recursive algorithm to only run 25 times slower. Does your recursive version call fibo twice per recursion, or only once?
I don't think Mince is bad. It seems to be about the same speed as Spin. I could speed it up a bit by simplifying its memory access to use direct inline rdlong/wrlong instead of calling a function to fetch each long. I did that because it is the VM from xbasic and xbasic can execute code from external memory through a cache. I also do some validity checking like making sure a bytecode is in range and checking for stack overflows and divide by zero which I could eliminate to gain some speed. It seems unlikely though that I'd be able to achieve Tachyon's or even pfth's performance.
One thing I thought of doing with Mince either in its Basic or C syntax version is to use it to make a Propeller BasicStamp or CStamp by writing it to the EEPROM on the new Prop Mini module that has a 64k EEPROM. I could use the second 32k as a small filesystem to store programs and would end up with a stamp-like module that is self-hosted. Of course, you could do the same thing with any of the Forths and have a faster system. Some people might like the infix syntax though, especially people coming from the BasicStamp/pbasic world.
Hi David, first off I must apologize for bombing your thread with my benchmark results, I admire the work you do and after reading your thread I was compelled to try out some benchmarks myself. When I first wrote Tachyon the only real speed tests I did were mainly I/O and VGA as I figured if it did that well then I'm off to a good start.
Although I don't have any problem with coding in Forth I am still interested to see if there is something that could combine the best of both worlds, be target resident and interactive, and suit the majority, even COLs (C Only Language they know people). So I guess you are the guy who could make that work, or else we might end up with a PLisp, and that wouldn't be a bad thing either. Good work.
Wow! 2.5ms for recursive fib(26)? That's great! Can you post a link to your site where we can find out more about this?
Oops, my bad!
I misread the number of microseconds - it's 2.5s for the recursive fib(26). I should have picked that up before pressing send!
The Iterative fib(26) number given previously is correct.
My spin calculation of fib(26) is 10.9s - which is about right as I generally see about a 4x speedup for code translated direct from spin to forth before adding in any pasm optimisations.
A "pasm" version in JDForth of fib(26) completes in 329ms.
Hi David, first off I must apologize for bombing your thread with my benchmark results, I admire the work you do and after reading your thread I was compelled to try out some benchmarks myself. When I first wrote Tachyon the only real speed tests I did were mainly I/O and VGA as I figured if it did that well then I'm off to a good start.
Although I don't have any problem with coding in Forth I am still interested to see if there is something that could combine the best of both worlds, be target resident and interactive, and suit the majority, even COLs (C Only Language they know people). So I guess you are the guy who could make that work, or else we might end up with a PLisp, and that wouldn't be a bad thing either. Good work.
Your benchmark results were welcome. Someone early on asked me how Mince compared with other languages so it is perfectly reasonable that you posted your results. The only thing I was confused about is that you used an iterative algorithm but someone else pointed out that you use a stack in COG memory that is probably too small to do a recursive version. Then Steve was nice enough to post an iterative C version so we now have numbers for that as well.
One thing that crossed my mind is that I could make my Mince compiler generate Tachyon Forth code. After all, my VM is stack-based just like Forth. Of course, that might not make much of a difference. My impression is that Forth programmers optimize stack use while they write code but my compiler isn't doing any optimization at all and I'm sure its translation from infix to postfix is suboptimal. This may be one big hidden advantage of Forth. Because you have to handle the stack manually, you end up doing the thinking required to reduce stack manipulation to a minimum and hence end up with more efficient code.
... to see if there is something that could combine the best of both worlds, ...
This would be an interesting goal indeed. I am not sure if I understand Forth correctly, but I do like the concept of defining a WORD that would make up a statement of something that the statement would do, does my interpretation make any sense? But I also like the structured aspect of Mince, what ever syntax it decides to mimic. Does the Propeller need another programming language? Probably yes, if it is going to be an interactive type, and is for the Propeller with a possibility of being ported to other embedded devices, which could lead to some interesting new language.
Comments
Recursive Fib(26) in 2.5ms
Iterative Fib(26) in 106us
But, Integrates into Spin (and the Propeller Tool) just like any other Spin object.
I make no apologies for it being a commercial product!
Isn't anything that's not PASM really an emulator? For example the Spin VM or gcc"s CMM are emulators for a 32 bit machine written in PASM. The source is then compiled to target this emulator and runs out of hub ram. So if an interpreter was written in C it should in theory be as fast as one that targeted ZiCog but was written in Z80 assembly.
Hi David, first off I must apologize for bombing your thread with my benchmark results, I admire the work you do and after reading your thread I was compelled to try out some benchmarks myself. When I first wrote Tachyon the only real speed tests I did were mainly I/O and VGA as I figured if it did that well then I'm off to a good start.
Although I don't have any problem with coding in Forth I am still interested to see if there is something that could combine the best of both worlds, be target resident and interactive, and suit the majority, even COLs (C Only Language they know people). So I guess you are the guy who could make that work, or else we might end up with a PLisp, and that wouldn't be a bad thing either. Good work.
Oops, my bad!
I misread the number of microseconds - it's 2.5s for the recursive fib(26). I should have picked that up before pressing send!
The Iterative fib(26) number given previously is correct.
My spin calculation of fib(26) is 10.9s - which is about right as I generally see about a 4x speedup for code translated direct from spin to forth before adding in any pasm optimisations.
A "pasm" version in JDForth of fib(26) completes in 329ms.
One thing that crossed my mind is that I could make my Mince compiler generate Tachyon Forth code. After all, my VM is stack-based just like Forth. Of course, that might not make much of a difference. My impression is that Forth programmers optimize stack use while they write code but my compiler isn't doing any optimization at all and I'm sure its translation from infix to postfix is suboptimal. This may be one big hidden advantage of Forth. Because you have to handle the stack manually, you end up doing the thinking required to reduce stack manipulation to a minimum and hence end up with more efficient code.
Ray