[Ecls-list] ECL gaining Unicode support [CC from News]

[Juan Jose Garcia-Ripoll]

On Sun, Oct 26, 2008 at 10:48 PM, Teunis Peters <teunis at wintersgift.com> wrote:
> (aside: I'm using 'or' in the binary inclusive sense here)
> The thing - as I understand it about threading - is this:   a
> single-threaded application on a single processor will always run faster
> than a multi-threaded application or a single-threaded application on a
> multiple-processor system.   The strength from multi-threaded code is seen
> when multiple discrete threads are in play or multiple processors are
> handling it.

This is not really the case. The multithreaded code should run as fast
as the single-threaded code except for two things:
- The storage of special variables requires a hash table in the
multithreaded case.
- The lisp environment is stored in thread-local storage, forcing some
additional code.
This adds about 10% of time. The rest 15% comes from the Unicode stuff.

> and re: wide characters and space: optimizations of this are possible and
> probably should be explored once the system is working, I'd guess.    I
> wouldn't mind looking into this myself once I understand why long long
> integers aren't present...   (something in the type system?)

No. Simply somebody has to code it in a way that it becomes a
configurable option -- not all platforms have long long.

> I've been caught up in life issues for the last wee while but the
> possibilities of a mingw32 build of ecl got me paying attention again.
> (last time I tried, it didn't - not as cross-compiled under linux anyway)

I am again in a wrong position to do things about the windows port,
since I am migrating again to a different computer, but I get from
time to time reports about this port and fixes, so I presume it must
not be 100% dead.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)
http://juanjose.garciaripoll.googlepages.com