[Shootout-list] Missing programs and score calculation (Was:

[Isaac Gouy]

The Felix mailing-list can be found at this URL
http://sourceforge.net/mailarchive/forum.php?forum=felix-language

--- skaller <skaller at users.sourceforge.net> wrote:

> On Fri, 2005-09-16 at 09:23 +0200, Marco van de Voort wrote:
> > > Felix outperforms C/C++ even though it actually generates C++!
> > 
> > In selected benchmarks of course. One benchmark that is known to
> favour
> > functional languages is a bit simplistic isn't it ? :-)
> 
> But C/C++ comes second for Ackermann, beating Ocaml, Haskell,
> and other functional languages .. so why do you say this test
> favours functional languages??
> 
> In fact, Felix outperforms the competition on quite a lot
> of the Shootout tests: for exception handling, threading
> by several orders of magnitude, and it equals the leader
> for many other tests (where the leader is C, Felix can
> always equal it simply because it generates C, literally
> if necessary).
> 
> For one test (regexp) Felix gets the right answer because it
> has simple clear syntax and ALL the other languages
> get it wrong -- because the Shootout result data is itself
> wrong and the tests cheated and just copied the wrong
> Perl regexp.
> 
> The thing is, for many features Felix is actually slower,
> but this isn't evident in the Shootout because the tests
> are too trivial: I could easily construct examples where
> Felix would not perform well. For example: C/C++ code
> releases memory at the end of a test .. Felix doesn't,
> and the tests don't use enough memory to ever trigger
> garbage collection: the Felix gc is quite slow compared
> to, for example, Ocaml.
> 
> > gcc is so slow due to the fact that it reparses headers ad
> infinitum (no
> > precompiled headers) and because it starts a zillion different
> processes per
> > compilation unit (at least cpp,gcc and as)
> 
> No. Surely these things don't help, but the real reason is
> that it uses extremely bad data structures. For example
> a linear list is used for lookup: this is an O(n) search.
> Sensible compilers use Hashtables .. which is an O(1) search.
> 
> gcc also has optimisations with quadratic time, however it
> is singularly incapable of handling large functions, even
> with optimisation off.
> 
> I have actually been forced to recode some Felix regression
> tests because gcc was taking 20 minutes to compile a large
> function --- reduced to 10 seconds by simply splitting it
> up into collection of smaller functions -- except that 
> 10% of the time gcc actually crashed with an internal error:
> it was using the WHOLE of my systems 1Gig of RAM to
> compile this code .. argggg ...
> 
> This is disgusting, since basic C can be compiled entirely
> linearly, in one pass with backpatching (for labels and
> forward declarations). Remember this is without optimisation ..
> 
> 
> -- 
> John Skaller <skaller at users dot sourceforge dot net>
> 
> > _______________________________________________
> Shootout-list mailing list
> Shootout-list at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/shootout-list
> 



	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/