Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #51383

Re: RfD Recognizer, 3rd version

From Bernd Paysan <bernd@net2o.de>
Newsgroups comp.lang.forth
Subject Re: RfD Recognizer, 3rd version
Date 2016-09-27 13:23 +0000
Organization A noiseless patient Spider
Message-ID <nsdrrs$798$1@dont-email.me> (permalink)
References (1 earlier) <a6a3672d-2e36-4085-93bf-fbf4cc3a7d0e@googlegroups.com> <87oa3a6jn2.fsf@jester.gateway.pace.com> <7cf7cab7-4593-48e7-a088-218458d61003@googlegroups.com> <87fuol7ups.fsf@jester.gateway.pace.com> <b9qdnb_VYP2QrXfKnZ2dnUU7-TfNnZ2d@supernews.com>

Show all headers | View raw


Am Tue, 27 Sep 2016 03:38:37 -0500 schrieb Andrew Haley:
> I think the proposal is to allow recognizers to be run before dictionary
> search.  The dictionary search itself can be a recognizer,
> and can appear anywhere in the recognizer stack.

Yes, of course users can change the default recognizer stack to fit any 
of their needs, and if they add slow recognizers on the top of the stack, 
the whole search can become pretty slow.

Comparing gforth-0.7.3 vs. current git Gforth on loading cross.fs however 
shows a measurable difference in favor of gforth-current (32ms vs. 36ms 
user time). Something else became better... and in fact, we have tuned 
our hash function.

If you think that the simple loop through the recognizer stack is too 
expensive, it's certainly possible to compile a tuned search function on 
every SET-RECOGNIZERS (possibly giving it a unique name derived from a 
hash over the xts, and using that name if it is already available), and 
that should eliminate the dynamic overhead. But we have that sort of 
overhead already for the loop through the search order. In fact, treating 
the search order as recognizer stack and using a similar precompilation 
scheme on SET-ORDER could tune that, too.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: RfD Recognizer, 3rd version trans <transfire@gmail.com> - 2016-09-26 20:33 -0700
  Re: RfD Recognizer, 3rd version Paul Rubin <no.email@nospam.invalid> - 2016-09-26 21:39 -0700
    Re: RfD Recognizer, 3rd version tabcomputing@gmail.com - 2016-09-26 22:45 -0700
      Re: RfD Recognizer, 3rd version Paul Rubin <no.email@nospam.invalid> - 2016-09-26 22:55 -0700
        Re: RfD Recognizer, 3rd version Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-27 03:38 -0500
          Re: RfD Recognizer, 3rd version anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-27 12:42 +0000
          Re: RfD Recognizer, 3rd version Bernd Paysan <bernd@net2o.de> - 2016-09-27 13:23 +0000
          Re: RfD Recognizer, 3rd version trans <transfire@gmail.com> - 2016-09-27 19:09 -0700
            Re: RfD Recognizer, 3rd version JennyB <jennybrien@googlemail.com> - 2016-09-28 00:07 -0700
              Re: RfD Recognizer, 3rd version anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-30 12:34 +0000
            Re: RfD Recognizer, 3rd version albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-28 10:03 +0200
              Re: RfD Recognizer, 3rd version ruvim.pinka@gmail.com - 2016-09-28 02:39 -0700
                Re: RfD Recognizer, 3rd version albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-28 13:22 +0200
            Re: RfD Recognizer, 3rd version anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-28 11:41 +0000
      Re: RfD Recognizer, 3rd version albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 15:15 +0200

csiph-web