On Tue, 2007-04-03 at 11:05 +0400, Artem Gr wrote: > > Felix was in the shootout but got kicked out by Isaac Gouy. > > Ahh. I see.
> http://lists.motion-twin.com/pipermail/neko/2006-May/000931.html Yes, but that's Isaac's biased view of what happened. In fact I worked for months with the original admin, Brent Fulingham who was very supportive. However some issues came up and Isaac completely misunderstood what was going on. Roughly, many of the tests were somewhat arbitrary, in trying to test 'language features' or specify algorithms. [How do you implement a procedural algorithm in a functional programming language?] As an example of how much of a Nazi he was -- Felix can do exception handling by using a non-local goto. This works if the goto is wrapped inside a closure and passed down to the routine which then throws it by executing it. It unwinds the stack and all! Gouy decided this wasn't real exception handling .. and disallowed the Felix implementation. It came to his attention because the test was so stupidly simple .. Felix managed to inline away all the closures and reduce the non-local goto to a local goto .. the test reduced to a loop which incremented a counter .. :) So Felix actually ran this test in NEGATIVE time --- due to the Shootout subtracting 'startup time' from the tests to get rid of the bias against Java. Unfortunately that Felix test started faster than "Hello World" .. hence negative time. Of course Gouy refused to listen to rational argument. In fact C was using jump buffers (setjmp/longjmp) which are precisely the same. Indeed, the functional languages using continuation passing (eg Scheme) also do the same. So Gouy ended up looking like so much of a fool .. he closed down the mailing lists by moving the traffic to a web site he had control over. Gouy just couldn't understand that I had a vested interest in the Shootout making sensible measurements, and actually wanted HARDER tests that Felix didn't perform well at, so I could use the Shootout to judge if I was successful at improving the compiler. Isaac is so insecure and paranoid he just didn't get it that far from cheating at the tests, I was actually arguing in the opposite direction ;( He banned Felix for cheating, when the fault was in the overly simplistic benchmarks. Note that the Shootout was actually invaluable during the development of Felix because it allowed me to target optimisations based on 'real world' code. That's only one example. Felix also trashed the threading test, for the same reason: the test was so stupidly simple, that the Felix implementation used tail calls to spawn the chain of threads .. and the tail calls of course got optimised, so there was actually no threading :) Again .. a negative time solution. Then there was the regexp test. Moron face decided Felix wasn't passing the test because it couldn't do substring extraction. Of course it could extract substrings .. just not using the regexp engine. He didn't want to listen to the arguments that the Felix method, which uses a builtin compiler supported regular definition concept and generates a deterministic automaton which would have creamed all the other engines in a performance test given reasonable data, was actually a superior technique. In fact .. Felix got it right and ALL the other stupid languages using bindings to PCRE got it wrong, because they copied a bug in the Perl RE which had been provided, which tried to be super tricky and use back references .. the result being so unreadable it actually got the WRONG answer. I actually submitted a much simpler and CORRECT Perl solution, no back references required .. of course Felix was clearly correct, you could tell by looking at the code .. which clearly you couldn't for Perl style string regexps (since for perhaps a year no one noticed the tests were actually all giving the wrong answer .. :) Of course my patch to the Perl code was ignored, and the test was never fixed. The fact is .. Felix was close to running ALL the tests faster than ANY other language. Tt was roughly around #5. My personal opinion was that Haskell won the Shootout hands down, because I weighted LOC highly -- simple code is good code, and Haskell waltzed in with the simplest code. > Perhaps it is possible to include some more of (possibly old) Shootout > tests in http://felix.sourceforge.net/speed/en_flx_perf_top.html ? And > improve the output a bit - explain which is which in > "Rankings for ack on rosella > felix 13 5.51 [N= 3 SD= 2%] > gnat 13 9.59 [N= 1 SD= 0%] > gccopt 13 9.84 [N= 2 SD= 0%]" Other tests are actually there in the bagley directory. However putting them into the speed stuff requires also putting the comparators -- Ocaml, gcc, Haskell, etc in .. the problem is it's all work and there are limited resources. I can't get the Haskell version of the code to compile .. not a Haskell programmer ;( You're welcome to contribute -- all you need is willingness and a sourceforge account :) > You don't need to change the GC in order to run under the managed C++. No, but it would probably be a good idea. > I think this is largely independent things. You can > a) have an external garbage collector (like > http://smieciuch.sourceforge.net/) in C++, no docs available on that one .. > but you already have one, and > independently you can > b) compile C++ into CLI and allocate value types on the unmanaged heap, > as in the usual C++. > http://msdn2.microsoft.com/en-us/library/ms384241(VS.71).aspx Problem is I just don't have enough Windows expertise, and I don't have time to learn all of it .. more people needed. > > To unwind the machine stack .. I just throw a C++ exception, > > but of course you can't recover from that. > > Whether the stack is implemented in a separate stack memory or in the > heap is an implementation detail. The question is - can it be unwound it > to provide a stack trace? You can unwind the machine stack with any system debugger: it's the machine stack, the same one always used by C/C++ so any debugger handling C/C++ stacks will handle Felix machine stacks because Felix generates portable ISO C++ code. >From that perspective procedure 'stacks' are just heap data. It's certainly possible to instrument Felix code to show debugging information .. but the instrumented code can't say anything about the machine stack because Felix doesn't manage it: the C/C++ compiler manages it. I personally think exception backtraces are a waste of time, for two reasons: First, Felix doesn't support exception handling: only the run time system (or user C++ libraries) can throw exceptions .. with one caveat -- Felix throws continuations sometimes to unwind the machine stack before continuing on to unwind the spaghetti stack. Other than that .. any error or C++ exception just aborts the thread (which is a problem .. it should abort the program :) Secondly, backtraces are fairly useless in a multi-programming (concurrent/parallel) environment. OTOH Felix can generate instrumentation, and some is already available .. for example you can set an environment variable to trace all heap activity. I am interested in extending this, probably using a TCP/IP based process monitor, where you can dynamically turn various diagnostics on and off whilst a program is actually running. So basically you start a Felix process under control of a a monitor which connects to the driver code via a socket, and then you can send commands to the running program. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
