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

[Teunis Peters]

Juan Jose Garcia-Ripoll wrote:
> 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.
>   
ok most of that is OS-level issues.   I studied this a while back before 
Linux took off and these were issues that came up.   Most of the speed 
issues - on a multitasking system (any modern OS, basically) won't show 
as they're accounted out in testing.
if ecl is to be used in a complex environment with discrete sections 
performing different actions, threads are really ideal.   (otherwise - 
as per erlang - a really good IPC system would be needed.   It probably 
is anyway, though)

>> 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.
>   
Aha!   Thank you.   That helps.   I haven't worked with a platform that 
lacks "long-long" in some form - I only deal with linux, gcc-compiling 
for ARM embedded, windows and MacOSX.   All of them have it and some 
require it for OS interaction - it's mandatory for dealing with large 
files and for dealing with some types of network I/O.    It's been a 
block for some of my ideas because of this...  but there's always ways 
to work around some of it.
>   
>> 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.
>   
I'll look into it further - but there's others, too.

This is a wonderful language project.  Thank you
    - Teunis