Re: Very promising results with libpcre2
Ævar Arnfjörð Bjarmason writes: > I am very tempted though to support them in parallel, if only for ease > of performance testing and to be able to roll out support for > grep.patternType=perl meaning pcre1 for now, but add a > grep.patternType=pcre2 for testing (and make grep.patternType=pcre1 > work, with grep.patternType=pcre being synonymous with > grep.patternType=perl, i.e. whatever the default is). Perhaps. As long as the code doesn't get too ugly, I think we would survive ;-)
Re: Very promising results with libpcre2
Jeffrey Walton writes: >> Just to make sure that we are on the same page. While I do not see >> the need to link with both variants and allow users to choose >> between them at runtime, I do not know if the whole world is ready >> to drop pcre1 and use pcre2 (the latter of which has only been >> around for a bit over two years). >> >> So we'd probably want to do >> >> (1) keep USE_LIBPCRE and enable v1 when set; >> (2) add USE_LIBPCRE2 and enable v2 when set; >> (3) make sure to error out when both are set. >> >> or something like that. It is tempting to allow us to say >> >> make USE_LIBPCRE=2 >> >> but the existing builds are likely to be depending on "is it set to >> anything? then use PCRE1" behaviour, so we unfortunately cannot take >> that route. > > Yeah, that's the question I kinda had. > >> make USE_LIBPCRE=2 > > I'd prefer a configure option for consistency. Maybe: > ... It is way too early to worry about how ./configure support for this will look like to the end user. Because our Makefile is designed to be usable without configure, the order we do things will be to first decide how we are going to use Makefile variables to configure the feature (i.e. what you saw that I said to Ævar). Once we know the decision, then we arrange autoconf to spit out the chosen Makefile variables using --with-pcre or whatever input. This step cannot start before we know the decision of the former. The one who writes --with-pcre support in ./configure would not know if USE_LIBPCRE=YesPlease or something else is the desired output until then.
Re: Very promising results with libpcre2
> Just to make sure that we are on the same page. While I do not see > the need to link with both variants and allow users to choose > between them at runtime, I do not know if the whole world is ready > to drop pcre1 and use pcre2 (the latter of which has only been > around for a bit over two years). > > So we'd probably want to do > > (1) keep USE_LIBPCRE and enable v1 when set; > (2) add USE_LIBPCRE2 and enable v2 when set; > (3) make sure to error out when both are set. > > or something like that. It is tempting to allow us to say > > make USE_LIBPCRE=2 > > but the existing builds are likely to be depending on "is it set to > anything? then use PCRE1" behaviour, so we unfortunately cannot take > that route. Yeah, that's the question I kinda had. > make USE_LIBPCRE=2 I'd prefer a configure option for consistency. Maybe: --with-pcre # Original PCRE --with-pcre1 # Alias --with-pcre2 # PCRE2 I prefer it because I usually do the following to see the interesting things that's going on: ./configure --help Often, I find a `--with-ssl` or similar. If `--with-ssl` fails, then I go to the README and INSTALL to fine tune it. By the way, if you are tweaking Configure, then consider adding a --with-perl=X, too. Its consistent, it side steps the hard coded /usr/bin/perl, and it signals to users its tunable. Jeff
Re: Very promising results with libpcre2
On Sat, Apr 1, 2017 at 8:24 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> On Sat, Apr 1, 2017 at 12:48 AM, Junio C Hamano wrote: >>> Ævar Arnfjörð Bjarmason writes: >>> That enables the new JIT support in pcre v2: s/iterrx fixed prx rx 2.19-- -33% -44% fixed 1.47 49%-- -17% prx 1.22 79% 20%-- >>> >>> The numbers with JIT does look "interesting". >>> >>> I couldn't quite tell if there are major incompatibilities in the >>> regex language itself between two versions from their documentation, >>> but assuming that there isn't (modulo bugfixes and enhancements) and >>> assuming that we are going to use their standard matcher, it may be >>> OK to just use the newer one without linking both. >> >> There's no incompatibilities in the regex language itself (modulo bugs >> etc). So yeah, I'll prepare some patch to use v2. > > Just to make sure that we are on the same page. While I do not see > the need to link with both variants and allow users to choose > between them at runtime, I do not know if the whole world is ready > to drop pcre1 and use pcre2 (the latter of which has only been > around for a bit over two years). > > So we'd probably want to do > > (1) keep USE_LIBPCRE and enable v1 when set; > (2) add USE_LIBPCRE2 and enable v2 when set; > (3) make sure to error out when both are set. > > or something like that. It is tempting to allow us to say > > make USE_LIBPCRE=2 > > but the existing builds are likely to be depending on "is it set to > anything? then use PCRE1" behaviour, so we unfortunately cannot take > that route. We're on the same page, all of this makes sense, there'll be some OS's / environments which for years won't be packaging pcre2 but will have pcre1. I am very tempted though to support them in parallel, if only for ease of performance testing and to be able to roll out support for grep.patternType=perl meaning pcre1 for now, but add a grep.patternType=pcre2 for testing (and make grep.patternType=pcre1 work, with grep.patternType=pcre being synonymous with grep.patternType=perl, i.e. whatever the default is).
Re: Very promising results with libpcre2
Ævar Arnfjörð Bjarmason writes: > On Sat, Apr 1, 2017 at 12:48 AM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason writes: >> >>> That enables the new JIT support in pcre v2: >>> >>> s/iterrx fixed prx >>> rx 2.19-- -33% -44% >>> fixed 1.47 49%-- -17% >>> prx 1.22 79% 20%-- >> >> The numbers with JIT does look "interesting". >> >> I couldn't quite tell if there are major incompatibilities in the >> regex language itself between two versions from their documentation, >> but assuming that there isn't (modulo bugfixes and enhancements) and >> assuming that we are going to use their standard matcher, it may be >> OK to just use the newer one without linking both. > > There's no incompatibilities in the regex language itself (modulo bugs > etc). So yeah, I'll prepare some patch to use v2. Just to make sure that we are on the same page. While I do not see the need to link with both variants and allow users to choose between them at runtime, I do not know if the whole world is ready to drop pcre1 and use pcre2 (the latter of which has only been around for a bit over two years). So we'd probably want to do (1) keep USE_LIBPCRE and enable v1 when set; (2) add USE_LIBPCRE2 and enable v2 when set; (3) make sure to error out when both are set. or something like that. It is tempting to allow us to say make USE_LIBPCRE=2 but the existing builds are likely to be depending on "is it set to anything? then use PCRE1" behaviour, so we unfortunately cannot take that route. Thanks.
Re: Very promising results with libpcre2
On Sat, Apr 1, 2017 at 12:48 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> That enables the new JIT support in pcre v2: >> >> s/iterrx fixed prx >> rx 2.19-- -33% -44% >> fixed 1.47 49%-- -17% >> prx 1.22 79% 20%-- > > The numbers with JIT does look "interesting". > > I couldn't quite tell if there are major incompatibilities in the > regex language itself between two versions from their documentation, > but assuming that there isn't (modulo bugfixes and enhancements) and > assuming that we are going to use their standard matcher, it may be > OK to just use the newer one without linking both. There's no incompatibilities in the regex language itself (modulo bugs etc). So yeah, I'll prepare some patch to use v2.
Re: Very promising results with libpcre2
Ævar Arnfjörð Bjarmason writes: > That enables the new JIT support in pcre v2: > > s/iterrx fixed prx > rx 2.19-- -33% -44% > fixed 1.47 49%-- -17% > prx 1.22 79% 20%-- The numbers with JIT does look "interesting". I couldn't quite tell if there are major incompatibilities in the regex language itself between two versions from their documentation, but assuming that there isn't (modulo bugfixes and enhancements) and assuming that we are going to use their standard matcher, it may be OK to just use the newer one without linking both.
