On Fri, 2007-05-25 at 16:37 +0000, Martin Percossi wrote:
> skaller wrote:
> You are of course completely right. Come to think of it, I remember a
> discussion about this on haskell list. Must be getting senile in my old
> age ;-)
Cool .. I was senile in my youth .. :)
> >Note also, Felix uses tuples rather than curried form,
> >they're more efficient (in Felix) because they're easier to
> >analyse than closure chains.
> More efficient? Closures should be very quick. I've certainly never
> heard of them having an impact on OCaml, which, among FP languages,
> felix is probably closest to.
It just happens that way. Ocaml is optimised for curry form
functions. Felix represent curried functions literally with
nested functions:
fun f(x:int) (y:int)=> x + y;
is literally transformed to
fun f(x:int) {
fun g(y:int)=>x+y;
return the g;
}
In this form, it's a bit harder to optimise, unless both
f and g are inlined. In particular, the 'general' form
of a Felix function is a C++ class:
struct g : int_to_int_function {
f *parent;
g(environment, f *p) : parent(p) { .. }
int apply(int y) { return p->x + y; }
};
struct f {
f(environment) { .. }
int_to_int_function apply(int x) {
return new(gc ..) g(environment, this);
}
};
Clearly, in this general form a single object with a tuple
argument is more efficient than using an extra closure.
> Of course, I guess the thing is you can
> translate functions whose arguments are tuples directly into C function,
> whereas curried functions would get translated to functions that accept
> an environment so that the C compiler couldn't inline those args,
> correct?
See above. Basically, yes, using tuples may help eliminate closures.
However Felix inlines everything very aggressively, so usually
the curried form will still be reduced to application of
primitives, just like the tuple form. In fact, unpacking and
packing tuples can also interfere with optimisation.
> Have you actually done benchmarks on the overhead?
No, I wouldn't know what to compare without careful thought.
> If it's
> small, use curried functions! Because curried functions are just so, so
> much better IMHO. But alas I suspect you're right - that's the price you
> pay for not going to IL and then machine code, I guess... although I
> think the gain, essentially FFI, more than pays it back.
Felix does go to an IL, but then it goes to C++, not machine code.
This results in less than maximally optimal code, but, it
results in portable code, and generally it allows gcc or
other C++ compiler to do all the hard low level optimisations,
which I dare say it can do better than I could.
Felix focuses on high level optimisations.
The combination can be very very fast.. basically Felix is the
fastest programming language available .. pretty cool for
a scripting language, to trash all the compiled languages :)
Yes, it does some things very badly at the moment, such
as lists .. but that can be fixed with a better gc algorithm.
> Cool. I agree about the $$ symbol (speaking of aesthetics: was "whilst"
> rather than "while" really necessary?
while is a library function. Whilst is a low level procedural
sugar for a conditional goto. while is preferred:
while { expr } { body; };
'Whilst' is provided in case while doesn't optimise properly,
that can happen .. :)
> -- see
> http://en.wikipedia.org/wiki/Whilst, in particular the part about style
> guides ;-). F#'s approach, though not inlinable, is to have a directive,
> if memory serves well:
> #syntax light
> which I thought was pretty sensible. But again, you can't inline. Maybe
> have both?
What do you mean I can't inline? Felix inlines almost everything,
inlining is its primary optimisation technique.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
