[Top][All Lists]
[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
- fmatch, stefan, 2010/05/06
- Re: fmatch, Ludovic Courtès, 2010/05/07
- Re: fmatch, stefan, 2010/05/07
- Re: fmatch, Ludovic Courtès, 2010/05/07
- Re: fmatch, stefan, 2010/05/07
- Re: fmatch, Ludovic Courtès, 2010/05/09
- Re: fmatch,
stefan <=
- Re: fmatch, Ludovic Courtès, 2010/05/10
- Re: fmatch, Stefan, 2010/05/11
- Re: fmatch, stefan, 2010/05/17
- Re: fmatch, Ludovic Courtès, 2010/05/22
- Re: fmatch, stefan, 2010/05/22
- Re: fmatch, Ludovic Courtès, 2010/05/23
- Re: fmatch, stefan, 2010/05/23
- Re: fmatch, Ludovic Courtès, 2010/05/24
- Re: fmatch, stefan, 2010/05/24
- Re: fmatch, Ludovic Courtès, 2010/05/25