[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fmatch

From: Ludovic Courtès
Subject: Re: fmatch
Date: Sun, 09 May 2010 22:57:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)


stefan <address@hidden> writes:

>> Hmmmm.  My first reaction is that I’d rather avoid complex VM
>> instructions like this and instead focus on native compilation (AOT or
>> JIT) when we feel like improving performance.
>> What do you think?
> Well, I think that for plain pattern matching, a sane compilation is the way 
> to go in the long run. For unification I'm not sure.

OK.  I was just thinking about (ice-9 match).  Let’s start a separate
thread for unification.  :-)

>> For 2.2 and beyond, I really think the focus should be on allowing hot
>> spots to be written in Scheme, which means compiling Scheme code
>> natively.  This would be beneficial to all Scheme code, not just this
>> specific pattern matching construct.
> This is clearly a good move. Hmm Ok, I see your point here. I could write 
> the whole stuff out in scheme directly. Hmm it would still be nice to have
> an implemenation in C and compare with what you get when introducing this 
> code. Also one should focus on stuff in the right order. So if I spend the 
> next 
> two weeks writing a small prolog implementaion. Should we wait untill after 
> 2.2 to get the suggested speed and live with 15x performance hit? It is 
> tempting to deliver that system and then spend the next years to shoot it 
> down into pure scheme. 

Don’t hold your breath: native compilation won’t show up overnight.  ;-)

You /can/ implement hotspots in C, but you most likely don’t need to
write special VM instructions for that.  Instead, you could probably
implement primitive procedures in C (info "(guile) Primitive


reply via email to

[Prev in Thread] Current Thread [Next in Thread]