Apart from lots of small improvements to the code, libraries,
tutorial, etc etc, and especially the typeclass based support
in the library, these are major enhancements to be found
in the next version.

1. Major refactoring of the build system to use a more or
   less entirely Felix independent build code, and to 
   split lots of files, particularly C++ code, out
   of interscript so more programmers can feel comfortable
   working on the repository (even though the interscript
   format was actually better technically).

2. The garbage collector can now run automatically at any allocation,
   and supports functional code. This is done by a adding a conservative
   scan of the machine stacks of all threads.

   The gc is still world_stop naive mark/sweep non-copying 
   style collector similar to Boehm collector except it is precise
   for non-stack memory, and doesn't need all the hacks and kludges
   for arbitrary C++ code. OTOH arbitrary mixing of C++ and Felix
   data types isn't possible (eg you cannot have an STL vector
   of Felix function closures, which Boehm would support).

   The stack scan will only work on machines with a single stack per
   thread. In particular, it will not work on IA64, which has two
   stacks (this can be fixed but I don't have an IA64).

   Felix collector should be considerably faster than Boehm
   because it scans much less memory, in particular it knows
   an array of float doesn't need scanning. It also supports
   variant length fixed size arrays much more efficiently
   (unused memory at the end of the array is never scanned).

   On small objects the 'precise' feature is unlikely to be
   a gain. Felix uses a Judy array to identify pointers into
   its heap. Boehm uses a hybrid with the front end using
   page tables. The Judy method is more general (it works
   with ANY allocator). It may also be much faster (since
   Judy is the result of years of tuning), however it does
   require 8 lookups on a 64 bit machine, so maybe not.

   The Boehm world-stop is much faster than Felix, since it
   uses signals where it can to stop threads, eg on Linux.
   Felix just hangs about waiting until all the threads 
   do their next service call or allocation.

   The Ocaml collector allocates memory MUCH faster than Felix,
   since in many native code versions it just bumps a dedicated
   thread-local machine register. Felix uses malloc,
   which is thread safe, but wraps the higher level allocation
   calls in mutex too (doubling the mutices used).

   However the Ocaml collector does not support parallel
   programming (genuine multi-processing) whereas both
   Felix and Boehm do.

   Boehm also has the option of a parallelised mark
   (that is, the bit that scans for non-garbage by 
   following roots).

3. A small improvement but Felix now builds with OpenMP support
   if available, for both gcc and MSVC++ based systems.
   Felix itself doesn't provide any support for openMP yet,
   and there may be considerable difficulty doing so because
   it primarily requires parallelising loops written in C style,
   and Felix NEVER generates any such loops and can't easily
   do so because they create stack scopes which prevent
   service calls by yields (particularly schannel I/O).
   Felix always uses gotos.

   However, the effect should be to support the experimental
   parallelised valarray and STL algorithms provided with
   the latest gcc installations. Note OpenMp schedules its
   own threads which is not compatible with Felix threading.
   HOWEVER Felix may support parallelisation by OpenMP for
   specific kinds of constructions such as matrix operations.
   (i.e. functional calculations should be easy to parallelise
   provided they don't allocate, or, the allocations disable
   world-stop checks, since the openMP thread aren't registered
   Felix threads).
 
   It may be possible work around that one in later versions
   of OpenMP or with hacks, where OpenMP is provide a pre-registered
   pool of Felix threads (however the current version of OpenMP
   doesn't allow for that AFAIK)

  

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to