On Mon, 2007-07-09 at 16:27 -0400, Sandro Magi wrote:
> > I hope to convince you this isn't necessary.
> >
> > Many people in the games world think dynamic allocation
> > and garbage collection are evil.. in fact this is rot.
>
> Well, I don't think it's "evil"; I quite like it actually. I'm just
> hoping to keep the VM kernel so simple that the greater abstraction
> provided by HOF isn't actually useful.
HOF aren't necessarily slow. Try this program with
bin/flx --test wh.flx
//////// wh.flx //////////////////////
#import <flx.flxh>
var i = 10;
while { i > 0 } { println i; --i; };
/////////////////////////////////////
'while' is a higher order library procedure.
{ i > 0 } and { println i; --1; } are both
function values.
Now, here is the generated code:
/////////// wh.cpp .. EXTRACT ///////////////////
//PROC _init_<4553>: Resume method
con_t *_init_::resume(){
PTF i = 10;
/*Lazy inline call to while'2*/
_5476:;
/*Lazy inline call to gt*/
if(!(0 < PTF i ) ) goto _end_call_lift_5475;
/*Lazy inline call to println*/
{
_a2019t_5791 _tmp5824 = flx::rtl::strutil::str<int>((PTF i));
*(&std::cout)<<_tmp5824;
}
*(&std::cout)<<std::endl;
--(PTF i);
goto _5476;
FLX_RETURN
_end_call_lift_5475:;
FLX_RETURN
}
///////////////////////////////////////////
Notice how the inlining has eliminated all the closures.
There's no allocation here.
This is the whole point of Felix. It does HIGH level optimisations.
It doesn't bother with low level optimisation as much: it lets
the native C++ compiler do that.
This is why you need to:
* build Felix
* write some silly little scripts
* examine the generated code
We both may be surprised at the result :)
http://felix.sourceforge.net/speed/en_flx_perf_0005.html
Felix __can__ be twice as fast as C .. :)
> The problem is that without precise information, you can't make the
> "kill process" judgment with any accuracy; you're left with heuristics
> as in Linux/Unix of killing processes off randomly (although you might
> have more information in this case).
Estimation is the art of limits .. you don't need precise information,
just 'good enough' estimates.
Precise information is too expensive .. and will itself
open up the possibility of a DoS attack! Just flog the system
with a bytecode that makes lots of allocations.. :)
> > Yep. Actually, one idea I've been toying with is to merge Felix
> > and Erlang .. Felix is much better at shared memory multi-processing
> > but Erlang is better at distributed parallelism with message passing.
>
> Hm, interesting; merge in what sense?
Merge as in first make it possible to build Erlang device drivers
with Felix .. later think about merging the language implementations
directly at the source level to get Erlix .. :)
> > There's some support for async disk file I/O, but really
> > Linux can't do this so it's fairly pointless.
>
> Well, some web servers seem to do fairly well with epoll (see lighttpd, et
> al).
We're using epoll on Linux, but it only works for sockets
because when you do I/O on notification .. that I/O isn't
asynchronous. Sendfile (disk to socket) is supposed to be,
but I have my doubts.
> I agree. The resource use properties seem no worse than C++, and Felix
> is considerably better in all other areas.
Well it does just generate ISO C++ files as output, so it
can't be worse than C++ because it IS C++ :)
--
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
