Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v10]

2022-05-10 Thread Ludovic Henry
> Despite the hash value being cached for Strings, computing the hash still > represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to > the autovectorizer, the complexity of doing it by hand is tri

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v9]

2022-04-13 Thread Claes Redestad
On Thu, 7 Apr 2022 07:01:23 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v9]

2022-04-07 Thread Ludovic Henry
> Despite the hash value being cached for Strings, computing the hash still > represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to > the autovectorizer, the complexity of doing it by hand is tri

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v7]

2022-04-06 Thread Ludovic Henry
On Tue, 5 Apr 2022 15:40:29 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v8]

2022-04-06 Thread Ludovic Henry
> Despite the hash value being cached for Strings, computing the hash still > represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to > the autovectorizer, the complexity of doing it by hand is tri

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-28 Thread Ludovic Henry
On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-27 Thread ExE Boss
On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-26 Thread Joe Darcy
On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-08 Thread Richard Startin
On Mon, 7 Mar 2022 21:41:05 GMT, Richard Startin wrote: >> Ludovic Henry has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add UTF-16 benchmarks > > Great to see this taken up. As it’s implemented here, it’s still scalar, but > the unroll

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-08 Thread Patrick Doyle
On Mon, 7 Mar 2022 21:41:05 GMT, Richard Startin wrote: >> Ludovic Henry has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add UTF-16 benchmarks > > Great to see this taken up. As it’s implemented here, it’s still scalar, but > the unroll

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-08 Thread Claes Redestad
On Tue, 8 Mar 2022 17:01:09 GMT, Claes Redestad wrote: >> Can we change the optimizer so that the strength reduction happens only >> after all transformations have settled? Carelessly changing a multiplication >> to a shift as today may hurt a lot of potential optimisations. >> Thanks. > >> Can

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-08 Thread Claes Redestad
On Tue, 8 Mar 2022 15:36:22 GMT, Quan Anh Mai wrote: > Can we change the optimizer so that the strength reduction happens only after > all transformations have settled? Carelessly changing a multiplication to a > shift as today may hurt a lot of potential optimisations. Thanks. Yes, it's troub

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-08 Thread Paul Sandoz
On Tue, 8 Mar 2022 15:13:46 GMT, Claes Redestad wrote: >> Ludovic Henry has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add UTF-16 benchmarks > > An awkward effect of this implementation is that it perturbs results on small > Strings a

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-08 Thread Quan Anh Mai
On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-08 Thread Claes Redestad
On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-07 Thread Richard Startin
On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-07 Thread Paul Sandoz
On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops

2022-03-05 Thread Ludovic Henry
On Fri, 4 Mar 2022 17:14:34 GMT, Claes Redestad wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-04 Thread Quan Anh Mai
On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops

2022-03-04 Thread Ludovic Henry
On Fri, 4 Mar 2022 17:14:34 GMT, Claes Redestad wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2]

2022-03-04 Thread Ludovic Henry
> Despite the hash value being cached for Strings, computing the hash still > represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to > the autovectorizer, the complexity of doing it by hand is tri

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops

2022-03-04 Thread Ludovic Henry
On Fri, 4 Mar 2022 17:01:05 GMT, Roger Riggs wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >> th

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops

2022-03-04 Thread Claes Redestad
On Fri, 4 Mar 2022 15:54:14 GMT, Ludovic Henry wrote: > Despite the hash value being cached for Strings, computing the hash still > represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to > the a

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops

2022-03-04 Thread Roger Riggs
On Fri, 4 Mar 2022 15:54:14 GMT, Ludovic Henry wrote: > Despite the hash value being cached for Strings, computing the hash still > represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to > the a

RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops

2022-03-04 Thread Ludovic Henry
Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and t