Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Optimize popcount functions with ARM SVE intrinsics.

  1. Popcount optimization using SVE for ARM

    Devanga.Susmitha@fujitsu.com <devanga.susmitha@fujitsu.com> — 2024-12-06T05:54:15Z

    Hello,   This email is to discuss the contribution of the speed-up popcount and popcount mask feature we have developed for the ARM architecture using SVE intrinsics.
The current method for popcount on ARM relies on compiler intrinsics or C code, which processes data in a scalar fashion, handling one integer at a time. By leveraging SVE intrinsics for popcount, the execution can process multiple integers simultaneously, depending on the vector length, thereby significantly enhancing the performance of the functionality.
We have designed this feature to ensure compatibility and robustness. It includes compile-time and runtime checks for SVE compatibility with both the compiler and hardware. If either check fails, the code falls back to the existing scalar implementation, ensuring fail-safe operation. Additionally, we leveraged the existing infrastructure to select between different popcount implementations, avoiding additional complexity.

Algorithm Overview:
1. For larger inputs, align the buffers to avoid double loads. For smaller inputs alignment is not necessary and might even degrade the performance.
2. Process the aligned buffer chunk by chunk till the last incomplete chunk.
3. Process the last incomplete chunk.
Our setup:
Machine: AWS EC2 c7g.8xlarge - 32vcpu, 64gb RAM
OS : Ubuntu 22.04.5 LTS
GCC: 11.4

Benchmark and Result:
We have used John Naylor's popcount-test-module [0] for benchmarking and observed a speed-up of more than 3x for larger buffers. Even for smaller inputs of size 8 and 32 bytes there aren't any performance degradations observed.

                                           [cid:da1f7dfc-7d31-438a-a5e8-579e96f4a8e0]                                                                     [cid:05551fcb-925c-43f6-a2b4-4dc2341322fe]
We would like to contribute our above work so that it can be available for the community to utilize. To do so, we are following the procedure mentioned in Submitting a Patch - PostgreSQL wiki<https://wiki.postgresql.org/wiki/Submitting_a_Patch>. Please find the attachments for the patch and performance results.
Please let us know if you have any queries or suggestions.


Thanks & Regards,
Susmitha Devanga.

  2. Re: Popcount optimization using SVE for ARM

    Kirill Reshke <reshkekirill@gmail.com> — 2024-12-06T07:22:19Z

    On Fri, 6 Dec 2024 at 10:54, Devanga.Susmitha@fujitsu.com <
Devanga.Susmitha@fujitsu.com> wrote:

> Hello,   This email is to discuss the contribution of the speed-up
> popcount and popcount mask feature we have developed for the ARM
> architecture using SVE intrinsics.
> The current method for popcount on ARM relies on compiler intrinsics or C
> code, which processes data in a scalar fashion, handling one integer at a
> time. By leveraging SVE intrinsics for popcount, the execution can process
> multiple integers simultaneously, depending on the vector length, thereby
> significantly enhancing the performance of the functionality.
> We have designed this feature to ensure compatibility and robustness. It
> includes compile-time and runtime checks for SVE compatibility with both
> the compiler and hardware. If either check fails, the code falls back to
> the existing scalar implementation, ensuring fail-safe operation.
> Additionally, we leveraged the existing infrastructure to select between
> different popcount implementations, avoiding additional complexity.
>
> *Algorithm Overview:*
> 1. For larger inputs, align the buffers to avoid double loads. For smaller
> inputs alignment is not necessary and might even degrade the performance.
> 2. Process the aligned buffer chunk by chunk till the last incomplete
> chunk.
> 3. Process the last incomplete chunk.
> *Our setup:*
> Machine: AWS EC2 c7g.8xlarge - 32vcpu, 64gb RAM
> OS : Ubuntu 22.04.5 LTS
> GCC: 11.4
>
> *Benchmark and Result:*
> We have used John Naylor's popcount-test-module [0] for benchmarking and
> observed a speed-up of more than 3x for larger buffers. Even for smaller
> inputs of size 8 and 32 bytes there aren't any performance degradations
> observed.
>
>
>
> We would like to contribute our above work so that it can be available for
> the community to utilize. To do so, we are following the procedure
> mentioned in Submitting a Patch - PostgreSQL wiki
> <https://wiki.postgresql.org/wiki/Submitting_a_Patch>. *Please find the
> attachments for the patch and performance results.*
> Please let us know if you have any queries or suggestions.
>
>
> Thanks & Regards,
> Susmitha Devanga.
>
Hi! Is this patch somehow related to [0] ?


[0]
https://www.postgresql.org/message-id/010101936e4aaa70-b474ab9e-b9ce-474d-a3ba-a3dc223d295c-000000%40us-west-2.amazonses.com

-- 
Best regards,
Kirill Reshke

  3. Re: Popcount optimization using SVE for ARM

    Devanga.Susmitha@fujitsu.com <devanga.susmitha@fujitsu.com> — 2024-12-06T09:29:29Z

    Hi Kirill,
This work has been conducted independently and is not connected to https://www.postgresql.org/message-id/010101936e4aaa70-b474ab9e-b9ce-474d-a3ba-a3dc223d295c-000000%40us-west-2.amazonses.com.

Our patch uses the existing infrastructure, i.e. the "choose_popcount_functions" method, to determine the correct popcount implementation based on the architecture, thereby requiring fewer code changes. The patch also includes implementations for popcount32, popcount64 and popcount masked. We'd be happy to discuss any potential overlaps and collaborate further to ensure the best solution is integrated.
Looking forward to your feedback!


Thanks & regards,
Susmitha Devanga.


________________________________
From: Kirill Reshke <reshkekirill@gmail.com>
Sent: Friday, December 6, 2024 12:52
To: Susmitha, Devanga <Devanga.Susmitha@fujitsu.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>; Hajela, Ragesh <Ragesh.Hajela@fujitsu.com>; Bhattacharya, Chiranmoy <Chiranmoy.Bhattacharya@fujitsu.com>; M A, Rajat <Rajat.Ma@fujitsu.com>
Subject: Re: Popcount optimization using SVE for ARM



On Fri, 6 Dec 2024 at 10:54, Devanga.Susmitha@fujitsu.com<mailto:Devanga.Susmitha@fujitsu.com> <Devanga.Susmitha@fujitsu.com<mailto:Devanga.Susmitha@fujitsu.com>> wrote:
Hello,   This email is to discuss the contribution of the speed-up popcount and popcount mask feature we have developed for the ARM architecture using SVE intrinsics.
The current method for popcount on ARM relies on compiler intrinsics or C code, which processes data in a scalar fashion, handling one integer at a time. By leveraging SVE intrinsics for popcount, the execution can process multiple integers simultaneously, depending on the vector length, thereby significantly enhancing the performance of the functionality.
We have designed this feature to ensure compatibility and robustness. It includes compile-time and runtime checks for SVE compatibility with both the compiler and hardware. If either check fails, the code falls back to the existing scalar implementation, ensuring fail-safe operation. Additionally, we leveraged the existing infrastructure to select between different popcount implementations, avoiding additional complexity.

Algorithm Overview:
1. For larger inputs, align the buffers to avoid double loads. For smaller inputs alignment is not necessary and might even degrade the performance.
2. Process the aligned buffer chunk by chunk till the last incomplete chunk.
3. Process the last incomplete chunk.
Our setup:
Machine: AWS EC2 c7g.8xlarge - 32vcpu, 64gb RAM
OS : Ubuntu 22.04.5 LTS
GCC: 11.4

Benchmark and Result:
We have used John Naylor's popcount-test-module [0] for benchmarking and observed a speed-up of more than 3x for larger buffers. Even for smaller inputs of size 8 and 32 bytes there aren't any performance degradations observed.

                                           [cid:ii_1939ad8bcdacb971f161]                                                                     [cid:ii_1939ad8bcdacb971f162]
We would like to contribute our above work so that it can be available for the community to utilize. To do so, we are following the procedure mentioned in Submitting a Patch - PostgreSQL wiki<https://wiki.postgresql.org/wiki/Submitting_a_Patch>. Please find the attachments for the patch and performance results.
Please let us know if you have any queries or suggestions.


Thanks & Regards,
Susmitha Devanga.
Hi! Is this patch somehow related to [0] ?


[0] https://www.postgresql.org/message-id/010101936e4aaa70-b474ab9e-b9ce-474d-a3ba-a3dc223d295c-000000%40us-west-2.amazonses.com

--
Best regards,
Kirill Reshke

  4. Re: Popcount optimization using SVE for ARM

    Kirill Reshke <reshkekirill@gmail.com> — 2024-12-06T09:41:49Z

    I did not yet look into this in detail,  but please note that PostgreSQL
comments style is /**/ not //. Also, please,  do not top post on this list

  5. Re: Popcount optimization using SVE for ARM

    Nathan Bossart <nathandbossart@gmail.com> — 2024-12-06T15:39:43Z

    I suggest we move this discussion to the existing thread on this subject:

	https://www.postgresql.org/message-id/flat/010101936e4aaa70-b474ab9e-b9ce-474d-a3ba-a3dc223d295c-000000%40us-west-2.amazonses.com

-- 
nathan

  6. Re: Popcount optimization using SVE for ARM

    Devanga.Susmitha@fujitsu.com <devanga.susmitha@fujitsu.com> — 2024-12-09T05:34:28Z

    Hi Nathan,

Thanks for your suggestion. I’ll move this discussion to the existing thread so we can all work together toward a more efficient solution.

Regards,
Susmitha Devanga.

________________________________
From: Nathan Bossart <nathandbossart@gmail.com>
Sent: Friday, December 6, 2024 21:09
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Susmitha, Devanga <Devanga.Susmitha@fujitsu.com>; pgsql-hackers <pgsql-hackers@postgresql.org>; Hajela, Ragesh <Ragesh.Hajela@fujitsu.com>; Bhattacharya, Chiranmoy <Chiranmoy.Bhattacharya@fujitsu.com>; M A, Rajat <Rajat.Ma@fujitsu.com>
Subject: Re: Popcount optimization using SVE for ARM

I suggest we move this discussion to the existing thread on this subject:

        https://www.postgresql.org/message-id/flat/010101936e4aaa70-b474ab9e-b9ce-474d-a3ba-a3dc223d295c-000000%40us-west-2.amazonses.com

--
nathan