guile-devel
[Top][All Lists]
Advanced

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

Re: fmatch


From: stefan
Subject: Re: fmatch
Date: Sun, 9 May 2010 22:52:01 +0200
User-agent: KMail/1.12.4 (Linux/2.6.31.12-0.2-desktop; KDE/4.3.5; x86_64; ; )

On Sunday 09 May 2010 10:57:21 pm Ludovic Courtès wrote:
> Hi!
> 
> 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.  :-)

In a sense they are close actually But as you say let's push the unification
onto the stack!!

Actually (ice-9 match) has quit a lot of power and I would try keeping it a 
little thinner in the beginning for a speedier version.
 
> >> 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.  ;-)

No problem. But then we might think about supporting some faster version.

> 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
> Procedures").

You then need to translate the action scheme code into a lambda and execute
that. That could work, I'll keep this as an option.

e.g.

(match x ((a b) (+ a b)))

(let ((F (lambda (a b) (+ a b))))
  (c-code-match x pat F))

This has it's elegance. So do you see any performancs 
issues using this?

/Stefan
                




reply via email to

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