This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bad news from the module/environment front


>>>>> "Telford" == Telford Tendys <telford@eng.uts.edu.au> writes:

Telford> if you are saying that we should have a long term objective
Telford> to unseat C and become the only language anyone will ever
Telford> need

No, this was not what I meant. Apparently we have an architectural
problem in the current evaluator. The way environments are handled
generates a lot of garbage. This is not just sloppy coding in the
righthand corner of scm_deval(), but something that looks to require a
bona fide redesign of the single most important function in the entire
system.

Telford> I often write a first draft in scheme and a third or fourth
Telford> draft in C -- no big deal, usually the C rewrite is very fast
Telford> because by then I know WHAT it is I'm supposed to be writing.

Which is good for smallscale scripting type of applications. But what
if you want to write a large application that uses full CLOS and
call/cc power? Then a rewrite in C is not a simple thing.

Telford> I think the pragmatists amongst us will admit that C
Telford> compilers will beat scheme compilers for the foreseeable
Telford> future.

The problem is more that current scheme compilers seems to beat the
life out of guile (I am working on getting some numbers to support
this claim, but haven't gotten so far yet).

>> If we box ourselves in by coding only for the target audience, Guile
>> will die a slow but certain death.

Telford> I guess that perl must be doomed to a slow but certain death.

No, because Perl5 has retargetted itself for a wider variety of
applications. Perl5 is a general purpose object oriented programming
language, though I do not know about speed/compilation.

But then again, perl is competing against sed and awk which are
completely terrible programming languages. Guile is competing also
against other scheme implementations such as stk, scm, rscheme and
bigloo. Guile has known problems in release cycle, startup time, code
size and library structure; if we also has poor performance, why
should people use guile then?

Telford> rewriting a few critical crunching routines in C is no
Telford> trouble when you can bolt-in C code and call it from your
Telford> scripting language.

Again, this only works if you are spending all your time in a very
small section of the code. If your application uses scheme features
throughout

Telford> I can't say that I have much experience with Tcl but I know
Telford> that there are still people using it. 

Which is why a complete restructuring of the internals was
necessary. I am no expert on tcl either, but as I understand it, tcl7
basically represented everything in strings. Tcl8, in order to get
reasonable performance, uses differentiated native representations,
such that a number really is a (machine) number. There is also a
bytecode compiler.

Telford> GC ... is such an unsolved issue and ... it might be better
Telford> to admit defeat
>> 
>> But still others are doing rather well in this respect. Mark/sweep is
>> not exactly rocket science anymore, and since (any) GC does take time,
>> it makes it all the more important not to create more garbage than
>> necessary.

Telford> Actually, C ...

I was not thinking about C, I was thinking about other schemes and
lisps out there. The problem with mark/sweep is that its performance
is proportional to the size of the heap. A copying collector is
proportional only to the amount of the live data, a generational
collector can do even better.

Telford> In short, an interpretive language has a ``performance roof''
Telford> -- you might as well deal with it.

Agreed, we definitely need to deal with it. Apparently, the current
interpreter can do better, but all in all (still need to get those
numbers) my conclusion is that for larger applications with real
demands on performance, we need a compiler. The hobbit compiler goes
some of the way, but still needs to embrace all of guile.


---------------------------+--------------------------------------------------
Christian Lynbech          | Telebit Communications A/S                       
Fax:   +45 8628 8186       | Fabrikvej 11, DK-8260 Viby J
Phone: +45 8628 8177 + 28  | email: chl@tbit.dk --- URL: http://www.tbit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]