Hi Paul,
I go another speedup as follows.
1) Make pop-fails inline
2) Put hints on step:
HINTS: step { peg-vm }
3) (This optimization is unsafe and probably not worth it, but it does
give a further speedup) Use dispatch instead, of case, so change
>alist '[ _ case ]
to
>alist sort-keys values '[ _ dispatch ]
Also, add an unsafe declaration prior to the 'dup type>>' call:
'[ { insn } declare dup type>> _ dispatch ]
Then, make exec inline with 'define-inline' instead of 'define-declared'.
Now I get the following timings:
{
142537
142757
142609
142655
142657
142327
142315
142596
142491
142381
}
Whereas with your original version I got
{
1071314
1069261
1066015
1066367
1067772
1068318
1067183
1067465
1068955
1070898
}
That's a pretty decent speedup.
Slava
On Wed, Jan 28, 2009 at 12:43 PM, Slava Pestov <[email protected]> wrote:
> Hi Paul,
>
> I got a 2x speedup by making two changes.
>
> 1) adding some type declarations to the vm and insn tuples:
>
> TUPLE: peg-vm { str string } { insns vector } { pc fixnum } { pos
> fixnum } { stack vector } { cap vector } ;
>
> TUPLE: insn { type fixnum } { off fixnum } aux ;
>
> To get the latter to work I had to change some f's to 0 in the insn
> constructors. This didn't seem to break anything.
>
> 2) changing the two nth calls to nth-unsafe.
>
> Slava
>
> On Sun, Jan 25, 2009 at 9:18 AM, Paul Moore <[email protected]> wrote:
>> 2009/1/25 Slava Pestov <[email protected]>:
>>> Perhaps you can share your code and I might be able to give additional
>>> hints. I'm really keen on closing this 10x performance gap with C.
>>
>> No problem. I'd not done so before purely because I didn't want to
>> just dump a "please fix my code" posting on the list :-)
>>
>> I've uploaded my code to Bitbucket (I use Mercurial rather than git -
>> hope that's OK). You can get the current version from
>> http://bitbucket.org/pmoore/factor-peg/raw/ca3cd70af2a0/lpeg.factor or
>> look at the whole repository at
>> http://bitbucket.org/pmoore/factor-peg/
>>
>> I think the key areas for improvement now are the any and char opcodes
>> - those are the ones used in the inner loop in my current tests (if I
>> do 3000000 test-vm 10 do-test-run print-timings, those opcodes run 30m
>> times each). The jmp opcode is also used that many times, but that
>> looks faily tight to me...
>>
>> Thanks for the interest!
>>
>> Paul.
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Factor-talk mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk
