[Stackless] Fwd: Falcon - new programming language

OvermindDL1 overminddl1 at gmail.com
Wed Jun 17 05:58:32 CEST 2009


Gull freaking...
I meant to send this to the stackless list, I forget it is my only
list that does not set the header to only respond to the list rather
than the last person who sent a message...


---------- Forwarded message ----------
From: OvermindDL1 <overminddl1 at gmail.com>
Date: Mon, Jun 15, 2009 at 9:47 PM
Subject: Re: [Stackless] Falcon - new programming language


On Mon, Jun 15, 2009 at 7:17 PM, OvermindDL1<overminddl1 at gmail.com> wrote:
> For note, based on the facts sheet saying pythons embeddability is
> low, I find Python very easy to embed, as easy as Lua even, only
> reason I think people find it difficult is the lack of documentation
> on the subject, but once learned, it is really easy.
>
> Looks like a fascinating language though.  Cannot look it it till
> later, so I am curious, is the programming style channel based (like
> Stackless Python), Actor based (like Erlang), or something else?
>
> Also, does it do any form of compilation to machine code?  I have been
> making a static language (think C with Actors, but is quite easy to
> embed as well) recently, and I would dump it if I found something that
> did what I want at the speed that I require.  :)
>
> On Mon, Jun 15, 2009 at 7:42 AM, Guy Hulbert<gwhulbert at eol.ca> wrote:
>> On Mon, 2009-15-06 at 06:30 -0700, Andrew Francis wrote:
>>> I downloaded and glanced at the "Survival Guide." Some quick
>>> take-aways.
>>> 1) I think the Event Marshalling feature is neat: the language I work
>>> on, WS-BPEL has this (I have to implement this in Stackless). 2) The
>>> language has quite a bit of documentation.
>>
>> I looked at all the docs on the page with the survival guide.
>>
>> Very thorough and it all looks useful.
>>
>>>
>> --
>> --gh
>>
>>
>>
>> _______________________________________________
>> Stackless mailing list
>> Stackless at stackless.com
>> http://www.stackless.com/mailman/listinfo/stackless
>>
>

I was wanting to test the speed comparison using your example loop on the page:
  int a = 0;
  for( int i = 0; i < 100000000; i++ )
     a = a + 1;
So I converted that to something my program can use (a rather minimal
change actually), ran it, and there was no real measurable execution
time, I think my optimization passes were optimizing the loop out (I
return the variable a so it could not optimize that away though).
I then disabled the optimization passes and ran again, it actually
took a few hundreds of a second then, including the parsing,
compiling, optimizing, and JIT'ing steps.
I then change the 100000000 to 1000000000 (added 1 zero), ran it
again, and it was just at about 2 seconds (with optimization passes
disabled I *know* the loop still existed in all its uglyness, as well
as a lot of nasty stack access without using any registers, the
optimization passes do a *lot*).

Depending on the input code mine will either JIT it, interpret it, and
usually do both at once (the code can mutate itself, alter the actual
syntax tree after generation, think LISP, but with a C syntax).  I can
force it to *just* use the interpreter though, and doing that then
using 1000000 for the loop takes about 16 seconds, so about 62500
loops per second then I guess, using the slow interpreter (my
interpreter is the thing that *is* correct, not fast, I always make
sure the JIT does the exact same thing as the interpreter, including
with any amount of optimizations enabled, just focusing on speed
instead.

I will by using my language for heavy math work (and a lot of generic
stuff as well that is not as speed sensitive).  It can transparently
bind to standard C functions (the JIT will even take the address of
the C function and integrate it directly in the code so it is not a
function pointer, doing the necessary conversions from my data
structures to the C style data structures in-line).  The main focus of
mine though is heavy concurrency (Actor based language, I love the
Actor style far more then other concurrency styles, like channels)
with C-like speed for the math stuff that matters (I do not like
writing a whole extension module just to get a stupid little speed
boost on something when the language should do it itself), and is very
easy to embed (actually I designed it exclusively to embed, although I
did whip up a quick console app with it embedded that takes a file or
the standard input and has a number of command-line switches to
operate on it for testing).

Mine however is not dynamically typed (although using the type of
'auto' is essentially dynamic as the function it is in will be
compiled differently depending on what the type should be (think
templates for C++)), I have never actually liked dynamically typing
things, even all my Python code I treat a variable as only a certain
type, if it can be multiple types then I treat the var as a variant
type (where-as my language also has a strict highly optimized variant
type designed for fast visitor access that will not cause multiple
function compilations as the auto type does).

So, I am mostly curious on how well the Falcon language can optimize
trivially optimizable code like the given loop above and other pure
math constructs, if it does well then I may just drop mine since I
would prefer to actually get back to my main project rather then
making a new language for it (although I would finish mine someday, I
like a C with Actors style).

As for a better speed comparison, do you have any code that makes a
more heavy use comparison?  I may not be able to test Falcon for a few
weeks unless I shirk away from work for a bit.  Something like the
Dining Philosophers Problem
(http://en.wikipedia.org/wiki/Dining_philosophers_problem) perhaps
would make a great test example for concurrency problems, and some
more heavy math code (recursive fibinocci perhaps?  My app can do the
recursive form of fib(46) in about 11 seconds for example) would be
nice to test raw math computation speed and optimization capabilities.




More information about the Stackless mailing list