Get Your Moto On

corz writes "Has PHP got you down? Are you tired of writing those Perl CGI scripts? Why not check out The Moto Programming Language. Released under the GPL, Moto allows for two modes of execution: interpreted and compiled. Moto is different from the rest of the field in that you can develop a site using interpreted mode for quick testing, then when the site is ready for production you can compile the it into an Apache DSO and serve it straight from memory. If you are looking to learn a new language, or would like to help with development, consider giving Moto a chance. Go download it now."

Comments

Embedded languages - pah

[Professor Collins]

I'm sad to see the curse of ASP and its copycats continue on like this. Embedding script inside a document file makes it quick and easy for non-programmers to write messy, unmaintainable code:

• They violate Model-View-Controller (MVC) separation. While it is possible to write your controller code as one long block of PHP and call its functions from your view scripts, that totally obviates the purported advantages of an embedded language.
• The embedded languages themselves are generally horrible. Visual Basic needs no run-down of its deficiencies. PHP is an overgrown SSI replacement which has ended up looking like a bad parody of Perl. Moto looks to be little more than a light wrapper around C. None of these languages have a proper object model, consistent database integration, or a good extension mechanism.
• They slow down maintenance of code. While the initial development phase may be expediated by the ability to embed code inside HTML, the web of markup and programme logic quickly becomes entangled in itself, and only gets worse over time. Starting with a proper top-down design phase may slow down development at first, but will be greatly rewarding in the long run.

The idea of Moto as both a compiled and interpreted language is noble (although not original; most Common LISP and Smalltalk implementations have both interpreted and compiled environments), but I urge them to reconsider their misguided language design strategy. They don't even need to come up with their own language; building a native code compiler for an established language like Python or Ruby would be a much greater boon to the open-source community at large.

Perl & mod_perl

[wdr1]

Moto allows for two modes of execution: interpreted and compiled. Moto is different from the rest of the field in that you can develop a site using interpreted mode for quick testing, then when the site is ready for production you can compile the it into an Apache DSO and serve it straight from memory...

This is somewhat analogous to using Perl and mod_perl. If that's the only reason to use Moto, I'd stick with Perl instead.

-Bill

Re:Perl & mod_perl

[Sentry21]

This is somewhat analogous to using Perl and mod_perl. If that's the only reason to use Moto, I'd stick with Perl instead.

I think you misunderstand what's happening here.

In 'fast mode', you're using it like mod_perl or PHP, but the next step is to compile it to native code and run it as a binary server module - not interpreted by, but run as. With mod_perl or php, your site is always interpreted by the DSO, but for Moto, your site IS the DSO. This provides a nice speed boost.

--Dan

Re:Perl & mod_perl

[wdr1]

With mod_perl or php, your site is always interpreted by the DSO, but for Moto, your site IS the DSO.

I get that part, but mod_perl can run at speeds equiv. to writing a DSO in C. My understanding is that it caches the Perl op-code in memory, etc. So it's not really be interprested each request by the ISO, simply executed.

This provides a nice speed boost.

I'd wager it's either not actually there, or hardly noticable. Are there benchmarks anywhere?

-Bill

Re:Perl & mod_perl

[motojoe]

Honestly a thorough performance comparison with other languages hasn't been completed. I've largely been basing performance estimates on the speed at which my own web applications execute (most pages are within the hundreds of transactions per second range) compared with what I've seen elsewhere.

I have started a more thorough performance test by converting the programs on the python vs java page (http://www.twistedmatrix.com/users/glyph/rant/pyt hon-vs-java.html) and the great language shootout page (http://www.bagley.org/~doug/shootout/) . A full suite of performance tests will be posted on the projectmoto site in the next couple days. In the meantime if anyone wants to run a performance test from the shootout page in moto now, follow these steps :

1) grab http://projectmoto.org/perftests.tar.gz . These are conversions of 11 of the tests into moto.
2) fix the value for N for tests in other languages downloaded from the shootout page (shootout tests have the number of iterations passed in)
3) compile and time the moto file with the following script:

set MOTONAME = "$1.moto";
set CNAME = "$1.c";
moto -c $MOTONAME > $CNAME;
gcc -I/usr/local/moto/include -I/usr/local/moto/mx/codex/util -I/usr/local/moto/mx/moto -D__MAIN__=main -DSHARED_MALLOC -O3 -o $1 $CNAME /usr/local/moto/mx/moto/libmx_moto.a /usr/local/moto/mx/codex/util/libmx_codex_util.a /usr/local/moto/lib/libcodex.a;
time ./$1 > out

Anyway, the performance picture for compiled moto pages currently looks like this :

Calls to functions / methods written in moto are made roughly 100 times faster in compiled moto pages than calls to functions or methods in perl, python or ruby and about 20 times faster than methods are called in Java. Part of this may be due to method inlining for small methods by gcc but this is one area where any compiled language is going to smoke an interpreted one. You can see this in the methcall, sieve, and fibo tests from the shootout page. Also, if gcc wants to optomize compiled moto code, more power too it. Its one of the reasons generating C is a good idea. C is virtually guaranteed to have more optimized compilers on more systems than any other language compiler or interpreter.

Array accesses in moto are 10 times faster in moto than they are in python or perl and about 40 times faster than in ruby. They are 2 times faster than in Java. The implementation of arrays in moto is still un-opimized and functions are called behind the scenes on array access leading me to believe I could get another 5-10 time speed boost here when that gets optimized. The biggest reason that arrays are still so much faster in moto than they are in perl, python, or ruby, is that these language don't even try to offer typed, bounded arrays, thus array access is a much more heavy weight operation. The counterpoint to this is that arrays in these languages are much more powerful. Moto, like Java, offers classes, like Vector and Stacks to do these sorts of dynamic operations. Moto may eventually have language level support for more dynamic sorts of arrays but they will be differentiated by type from the simple C/Java style arrays moto supports now. These results can be tested with the ary3 test from the shootout page.

Outputting "hello world" 100,000 times runs about twice as fast in compiled moto as in perl, and 4-5 times as fast as it does in ruby. This is at least partially due to output buffering in moto which happens by default. It runs about 50 times faster than in java but thats because System.out.println sucks

Regular expression matching and substitution in moto today is 10 or more times slower than Perl or languages that use the PCRE package. The implementation is not optimized and incomplete. I hope to one day use the libtre package for regexes giving moto the completeness and the speed of these other languages in this regard. The implementation of regexes in moto is currently a modified version of Ville Laurikari's TNFA algorithms. This does mean that I will never have a regex that takes me an exponential amount of time to match. It also means I will not support back-references in the regex ... but I never liked them anyway.

Inserting integers to and from a hash (IntHashtable in moto) is 30% faster than in Java 50% faster than in python or ruby and 3 times faster than in perl. The difference with Java is likely because my Hashtable accesses aren't synchronized, this test should be redone with a Hashmap.

Inserting objects into a Vector (adding dynamically onto an array in Perl, Python, and Ruby) is about the same as in Java, and 10-50% faster than in perl,python,and ruby . Behind the scenes perl, python, and ruby, are effectively calling the same sort of highly optimized C methods as moto and Java are. I figured native method invocation in moto would take roughly the same amount of time in moto as it does in the interpreted languages. But that wasn't exactly what was going on. Turns out the memory manager in moto isn't nearly as fast as it should be and allocation of all the objects to put into the vector is what eats up all the time. The objinst test from the shootout page (as well as any old profile of a compiled moto app) demonstrates this. Object allocation in moto, java, perl, python, and ruby take roughly the same amount of time. The memory manager in moto is to blame for this. It is completely home grown. It acts on an memory mapped file and uses splay trees for the free list. This is necessary in order to persist objects between page views on the 1.3.x versions of apache. Turns out this implementation is nowhere near as fast as system malloc. So much for long bearded algorithms. The memory manager will be swapped out in the future for apache 2 support where its likely thread safe versions of the system malloc will be used. This should be a great big speed boost to all parts of moto.

matrix multiplication is 10 times faster than in perl, python, or ruby ... but who cares

-Dave

BTW: Don't try these tests in the moto interpreter ... no one ever claimed that was fast :)

Zend Safeguard Suite...

[coene]

A bit off topic of the actual news, but related to many comments....

If you are looking to compile your PHP (to not make source viewable, make it faster, etc etc) check out Zend's SafeGuard Suite...