# Protein database search using Processing-in-Memory
architecture

Charly Airault, Charles Deltel, Florestan de Moor, Erwan Drezen, Meven Mognol, Dominique Lavenier

► To cite this version:

Charly Airault, Charles Deltel, Florestan de Moor, Erwan Drezen, Meven Mognol, et al. Protein database search using Processing-in-Memory architecture. IPDPS 2025 - IEEE International Parallel and Distributed Processing Symposium, IPDPS, Jun 2025, Milano, Italy. pp.939-948, 10.1109/IPDPSW66978.2025.00146. hal-05375748

HAL Id: hal-05375748

https://hal.science/hal-05375748v1

Submitted on 21 Nov 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Protein database search using
Processing-in-Memory architecture

Charly Airault

IRISA / CNRS

Rennes, France

charly.airault@irisa.fr

Charles Deltel

Inria

Rennes, France

charles.deltel@inria.fr

Florestan De Moor

IRISA / CNRS

Rennes, France

florestan.de-moor@irisa.fr

Erwan Drezen

Pasteur Institute

Paris, France

erwan.drezen@pasteur.fr

Meven Mognol

IRISA / UPMEM

Rennes, France

meven.mognol@irisa.fr

Dominique Lavenier

IRISA / CNRS

Rennes, France

dominique.lavenier@irisa.fr

*Abstract*—This paper describes the implementation of align-
ment search within a protein sequence database using the
Processing-in-Memory concept. The PiM memory component
used is a specialized DRAM developed by UPMEM. The study
examines two main aspects: the acceleration achieved compared
to a traditional multi-core server and the energy savings enabled
by this architecture. These evaluations highlight the potential of
PiM technology for enhancing the performance and efficiency of
computationally intensive bioinformatics applications.

*Index Terms*—Processing-in-memory, protein database, sequence alignments

# I. INTRODUCTION

One of the earliest and most fundamental steps in genomic
data processing involves sequence comparison. This operation
is central to many bioinformatics workflows and is based on
the concept of sequence alignment. Sequence alignment allows
for the comparison of biological sequences—such as DNA,
RNA, or protein sequences to identify regions of similarity
that may indicate functional, structural, or evolutionary rela-
tionships between them. This process of alignment is present
in a wide range of applications:

* Database searches: Sequence alignment is essential for searching protein sequence databases or DNA sequence repositories. This helps identify matches or similarities between sequences, aiding in the discovery of functional or evolutionary relationships.

* Variant discovery and mapping: In genomics, identifying variants often requires mapping sequences to reference genomes. Sequence alignment facilitates this process, enabling researchers to pinpoint mutations, insertions, deletions, or other genetic variations.

* Phylogenetic tree construction: Aligning sequences can be a time consuming step in building phylogenetic trees,

which illustrate evolutionary relationships among species
or genes based on their genetic information.

* Sequence annotation: Annotating sequences to identify genes, regulatory elements, or other functional regions also relies on accurate sequence alignment. This process is key for understanding the biological significance of genetic data.

* Comparative Genomics: Sequence alignment enables the comparison of genomes across different organisms. This helps in identifying conserved regions, understanding genome evolution, and uncovering genetic elements that contribute to specific traits or diseases.

Beside, the volume of genomic data is increasing at an
unprecedented rate, driven by advances in sequencing tech-
nologies. They have become faster and more affordable, mak-
ing it easier than ever to generate vast amounts of genetic
information. As a result, sequence databases are expanding
exponentially. With this explosion of data, the computational
processes required to analyze and interpret these data are
becoming increasingly time consuming. This explosion in de-
mand requires substantial investment both in the design of new
algorithms and in high-performance computing infrastructures,
which are costly and energy-hungry.

To address the growing challenges associated with pro-
cessing genomic data and reducing energy costs, researchers
have explored numerous alternatives to accelerate sequence
alignment [12]. Among these, specialized hardware solutions
have shown significant potential.

VLSI Components: Very-Large-Scale Integration (VLSI)
components dedicated to sequence alignment were among
the earliest alternatives [9]. These components are exception-
ally fast and energy efficient, making them ideal for high-
throughput applications [8]. However, their primary drawbacks
include high manufacturing costs and very limited programma-
bility, which restricts their adaptability to evolving algorithms
and applications. In practice, this approach has not developed.
Today, there are no ASIC components specialized for this type

The work described in this paper is funded by the European Union's Horizon Europe Programme for research and innovation under grant 101047160 (BioPIM project), and by the French ANR program ANR-21-CE46-0012 GenoPIM..
of processing.

**FPGA Technology:** Unlike ASICs, Field-programmable gate arrays (FPGAs) offer a versatile and adaptable solution. These devices enable algorithms to be embedded directly into hardware while retaining the ability to be reprogrammed, allowing for updates and modifications without the need to replace physical components [15] [11], [30], [13]. Despite their advantages, FPGA programming is complex and demands specialized expertise, which can hinder their broader adoption. Nevertheless, many manufacturers have embraced this technology to accelerate computations, exemplified by the DRAGEN hardware accelerator used in Illumina's sequencers [10].

**GPUs:** Graphics Processing Units (GPUs) are a more recent form of hardware acceleration. GPUs are highly programmable and versatile, making them well suited to computationally intensive tasks such as sequence alignment [7] [14] [23] [31]. Despite their ease of use compared to FPGAs, GPUs have one major drawback: their high energy consumption, which can offset some of the gains in computational efficiency. This is particularly critical in large-scale computing environments, where energy costs and thermal management are key concerns.

However, recent versions of these accelerators incorporate advanced power management features that allow users to control and adjust power consumption based on the specific requirements of an application. By dynamically tuning power limits, clock speeds, and voltage levels, modern GPUs can achieve a better balance between performance and energy efficiency. This flexibility enables significant improvements in overall energy consumption, making GPUs more suitable for workloads where power efficiency is a critical factor, such as bioinformatics applications.

Each of these alternatives offers unique advantages and trade-offs, and the choice often depends on the specific requirements of the task at hand, such as speed, energy efficiency, or flexibility.

Another promising solution for accelerating sequence alignment and reducing energy consumption is computing directly within memory [17]. This approach, known as processing-in-memory (PiM), addresses a fundamental limitation in traditional Von Neumann architectures: the "memory wall."

The memory wall refers to the bottleneck created by the separation of computation and memory in conventional architectures, which becomes more pronounced in multicore processors [16]. Applications that process massive amounts of data, such as those in genomics, overwhelm the communication pathways between the host processor and memory. This results in a significant decrease in the scalability of parallel programs.

Furthermore, data transfers between the host processor and memory consume a substantial amount of energy. While caching mechanisms help by reducing the need for frequent off-processor memory access, they are not always effective for "data-intensive" applications. Such applications often involve irregular access patterns, making traditional caching strategies less efficient. The PiM concept offers a compelling alternative

by enabling computations to be performed directly within the memory. This not only reduces the memory wall effect but also minimizes energy consumption by limiting the amount of data transferred between the processor and memory. By merging computation and storage into a single component, PiM creates opportunities for higher efficiency in handling large-scale genomic datasets [18].

Several research projects have already explored the parallelization of sequence alignment algorithms on PiM architectures. In [22], four implementations are evaluated: the Needleman and Wunsh's algorithm [27] which globally compares two sequences of similar size, the Smith-Waterman-Gotoh algorithm [26] which searches for local alignments with an affine gap model, the GenASM algorithm [25] that modifies and adds a traceback method to the bitap algorithm [24], and the Wavefront algorithm [28] which is used to also globally compare two sequences. Implementations show substantial acceleration gains compared to conventional CPU systems. Order-of-magnitude speed-ups compared with CPU execution are measured in [29], where the BiWFA (Bidirectional Wavefront Alignment) algorithm is parallelized on the PiM to compare long DNA sequences.

From an architectural point of view, PiMs can be classified into two main categories: those whose computations are carried out directly in the memory cells, and those whose computations are carried out outside the memory blocks, but with the computation resources on the same die [17]. In both cases, the data does not pass outside the memory component. The first architecture offers massive parallelism but with limited operations, while the second approaches more limited parallelism but over a wider range of operations.

The paper focuses on the second approach and explores the parallelization of sequence alignment searches within protein sequence databases, focusing particularly on use cases where the alignment process is computationally intensive. One such case is sequence annotation, where a list of unknown sequences is compared against a reference database to assign functional or structural annotations. This is crucial for understanding the role of novel proteins or genes within biological systems. Another demanding scenario is the search within public databases with thousands of users querying large datasets simultaneously. The sheer volume of queries and data requires optimization to ensure efficient processing. In both cases, the execution time of queries must be minimized to provide fast results, making parallel processing techniques essential for handling large-scale sequence comparison tasks. Compared to other work on sequence alignment, we investigate here how an alignment search based on a standard heuristic can be parallelized on a complete system integrating a PiM memory space.

Implementation has been done on Processing-in-Memory (PiM) devices designed by the UPMEM company. Today, the company is the only one to offer a commercial solution on which real experiments can be carried out. These PiM memories integrate processing units directly within DRAM modules, enabling data processing to occur close to the data storage.
As introduced earlier, the UPMEM architecture belongs to the second category. Calculations are performed outside the memory blocks.

In this work, we mainly investigate two critical aspects of performance:

* Acceleration: The UPMEM PiM architecture is compared to a conventional multi-core server. The analysis focuses on how the integration of computation within memory significantly accelerates sequence alignment by reducing the data movement overhead typical in Von Neumann architectures.

* Energy efficiency: A detailed comparison of energy consumption between the PiM solution and conventional multicore systems is provided. The aim is to estimate energy gains at the level of a complete system.

The remainder of this paper is structured as follows. Section 2 provides a brief overview of the PiM architecture developed by UPMEM, describing its key features and functionalities. Section 3 explains the alignment search algorithm utilized for querying a database. The following section presents the parallelization framework adopted to maximize the use of all resources in a server equipped with PiM memory. Section 5 discusses the results obtained, highlighting performance and efficiency improvements. Finally, Section 6 concludes the paper by summarizing the findings and suggesting directions for future work.

## II. UPMEM PiM TECHNOLOGY

### A. Hardware

UPMEM has developed a Processing-in-Memory (PiM) component that integrates both DRAM memory and processing units on the same chip [3]. This PiM device is packaged in Dual Inline Memory Modules (DIMMs), each module containing 128 DRAM processing units (DPUs) divided into 2 ranks of 64. A rank corresponds to a physical set of DPUs sharing a common control with the host processor. A DPU is a 32-bit RISC processor whose clock frequency is matched to the DRAM frequency. Each DPU has access to a memory block of 64 MB, referred to as MRAM, resulting in a total of 8 GB of memory per module [4].

The host server directly accesses the 64 MB memory block of each DPU and is responsible for uploading and launching specific programs onto the DPUs. One of the unique features of the DPU is its instruction set architecture, which includes fused jump instructions. This feature allows for cycle-free jumps after most instructions, improving execution efficiency through optimized branching.

To speed up memory accesses, each DPU is equipped with a 64 KB working random access memory (WRAM), accessed in one cycle, operating in the same way as a high-bandwidth cache. In addition, specialized transfer instructions enable data blocks to be rapidly exchanged between MRAM and WRAM.

The DPU is a true multi-threaded processor, capable of switching tasks every clock cycle. It can handle up to 24 hardware threads, known as tasklets, simultaneously sharing the

<figure><img src="image_2.png" /><figcaption>Fig. 1. UPMEM PiM memory architecture: A DIMM module integrates 2 ranks of 64 DPUs. Each DPU, a small 32-bit processor, is connected to a 64 MB DRAM memory block. Total DIMM capacity is 8 GB and 128 DPUs.</figcaption></figure>

DPU's resources. The DPU's instruction pipeline is 11 cycles deep, meaning each instruction requires 11 cycles to retire. However, this pipeline cannot execute multiple instructions from the same tasklet simultaneously, so optimal performance is achieved by running at least 11 tasklets in parallel.

Direct communication between DPUs is not possible, as no interconnection network exists between them. Any data transfer between DPUs must go through the host server. This architectural model must be considered when designing parallel algorithms for systems based on UPMEM's PiM architecture. For optimal performance, workloads on individual DPUs should be independent of one another.

In large systems, with several hundred gigabytes of memory, the challenge becomes designing efficient parallel algorithms that can leverage the UPMEM PiM architecture. These algorithms must ensure proper load balancing across thousands of threads. A typical PiM-based UPMEM system consists of both legacy DRAM and PiM DRAM memory, with the host (a multi-core processor) accessing both memory types in an indistinguishable manner, as illustrated in Figure 1. For example, our UPMEM server integrates 20 DIMM modules, i.e. 2560 DPUs capable of running up to 24 threads in parallel, i.e. more than 60,000 threads.

### B. Programming

Programming a UPMEM-PiM server typically involves writing two separate programs: one for the host CPU and another for the DPUs, with synchronization between them. For example, when querying a database stored in the PiM memory, each DPU is responsible for processing a small section of the database. The host program sends requests to each DPU, runs the DPU, and then collects the results. In this case, only two programs are required: one for the host and one for the DPUs.

The DPU programs must be written in C, with a library of routines available to handle DPU-specific tasks, such as tasklet
synchronization and efficient memory transfers between the WRAM and the 64 MB MRAM. Additionally, simulator and debugging tools are provided to test the PiM parallelization of new programs.

On the host side, the program can be written in C, C++, Python, or Java. This program manages the overall application, initializing the DPUs with the appropriate programs, transferring data to and from the DPUs, synchronizing the DPU execution, and more. A library of primitive routines is also provided to facilitate these basic tasks, ensuring smooth interaction between the host and DPUs.

### C. Challenges

In short, a server equipped with UPMEM PiM memory modules can contain thousands of additional small processors operating directly on small memory blocks. Each processor runs a dozen threads, which means that managing massive parallelism with tens of thousands of threads becomes a major challenge. Within a DPU, threads can communicate via memory. However, not all DPUs can communicate with each other, hence the need for efficient parallel task management.

Moreover, current servers are typically multi-core and multi-threaded, adding another layer of parallelism that must be managed. The complexity arises from the necessity to exploit both the intra-processor parallelism (inside the small processors within the memory modules) and the inter-processor parallelism (between the multiple cores of the host processor). This requires designing algorithms that can effectively utilize these different levels of parallelism, maximizing performance while minimizing overhead and resource contention.

## III. ALIGNMENT SEARCHING METHOD

A protein sequence database consists of a collection of sequences represented over a 20-character alphabet, corresponding to the 20 standard amino acids. The average length of a sequence in such a database is approximately 350 characters, and a database can hold hundreds of thousands of sequences. For instance, UniProtKB/SwissProt [19], one of the most comprehensive protein sequence databases, currently contains more than 570,000 manually curated protein sequences. The sequences in SwissProt are highly reliable, as they are carefully reviewed and annotated by experts. This database, alongside its sister database UniProtKB/TrEMBL, that contains orders of magnitude more proteins and which includes automated annotations, provides data on protein function, structure, localization, and much more. The database resulting from large metagenomic projects can be even larger.

When given a query in the form of a protein sequence, the task is to search the database and identify all sequences that share textual similarities with the query. The results of such a search are referred to as alignments. Each alignment represents a pair of sequences where regions of similarity are identified, typically through matching amino acids in specific positions. Figure 2 represents an alignment.

One of the most widely used methods for sequence alignment is the seed-and-extend approach [20]. This standard

<figure><img src="image_3.png" /><figcaption>Fig. 2. Alignment example: An alignment is a superposition of two strings of characters corresponding to the amino acids of two proteins. When amino acids are identical, they are linked by the | character. When they share similar chemical properties, they are linked by the ':' character. The '-' sign indicates the loss (or acquisition) of an amino acid. This is known as a "gap".</figcaption></figure>

method is effective and forms the basis of well-known software tools like BLAST (Basic Local Alignment Search Tool) [5]. In the seed-and-extend method, the search starts by identifying short, identical segments (seeds) between the query and sequences in the database. Once seeds are found, the algorithm extends these alignments by progressively comparing the surrounding regions of the sequences to improve the overall match.

To speed-up the matching seed process, before the actual search begins, the sequence database is indexed. For protein sequences, the indexing typically uses 3-amino-acid-long seeds. For each seed, the index records the positions of its occurrences in the database, allowing the search algorithm to quickly locate regions where similar patterns might exist.

The search alignment algorithm can be expressed as follows:

1: Input
2: PD1 # protein database
3: PD2 # protein database
4: T # threshold
5: Main
6: I = index(PD1)
7: LA = [] # list of alignments
8: for all protein P2 in PD2
9: for all seeds S2 in P2
10: for all seed S1 in I[S2]
11: A = extend(S1, S2)
12: if A.score > T
13: add A to LA
15: Output
16: LA # list of alignments

As input (lines 2 and 3), two databases are considered. The parameter T is a threshold value that indicates the validity of an alignment (line 4). The first database is indexed (line 6). For each protein sequence in the second database (line 8), all amino acid triplets are examined (line 9). The index generates all the positions where these triplets are present in the first database (line 10). From the coordinates of the two seeds, an alignment (A) is calculated (line 11). If the alignment score exceeds the threshold T, the alignment is stored.

For our study, only simple alignments are calculated. They do not incorporate gaps. These alignments only account for
<figure><img src="image_4.png" /><figcaption>Fig. 3. Global parallelization. The most time-consuming task (finding relevant hits) is deployed and parallelized on the PiM memories. Other tasks (reading the query bank, computing full alignments and writing the results) are executed on the host processor and handled by several threads. The whole system is synchronized using FIFOs, thus overcoming differences in query execution times.</figcaption></figure>

substitution errors, unlike standard software, which typically includes both insertion and deletion errors. The primary objective here is to focus on the overall behavior of a database search and to streamline the process by concentrating on the essentials.

## IV. PARALLELIZATION

The parallelization approach implemented is straightforward. The index of the first database is evenly distributed across all PiM memories. To query the database with a given protein sequence, the sequence is broadcast to all DPUs. Each DPU independently performs its alignment search and sends its results back to the host processor.

Actually, the DPUs do not compute complete alignments. Instead, they identify positions where an alignment is likely to exist. These positions (derived from the query and a database protein) are referred to in the following as “hits”. This enables significant filtering, allowing the computation of complete alignments to be performed only on a limited set of coordinates. The final alignment calculations are carried out on the host processor, ensuring efficient use of computational resources while leveraging the parallel capabilities of the PiM architecture.

As a matter of fact, the complete system incorporates multiple levels of parallelization, including the DPUs and the cores of the host processor. To maximize overall performance, an application must balance the workload across all hardware resources effectively. In this setup, the host processor manages several tasks. It reads data from the storage device, sends queries to the DPUs, collects the hits where potential alignments can arise, computes the full alignments based on those hits, and finally writes the results back to the storage system.

To implement filtering and fully leverage the potential of PiMs, the index does more than simply storing the positions of the seeds. It also records the neighboring characters of each seed. This enables a direct assessment of whether the neighboring regions are similar without requiring additional memory block accesses on the MRAM of the DPUs. While this approach significantly speeds up the process, it comes at the cost of a substantial increase in the size of the index. This parallelization scheme together with an enhanced index was chosen because the time dedicated to identifying regions potentially eligible for alignment accounts for 70% to 80% of the total computation time. This portion of the workload is highly parallelizable and can therefore be effectively offloaded to in-memory computation. By doing so, the bandwidth required between the host and the memory is drastically reduced, as only a very small fraction of the possible positions is returned.

At the level of a DPU, tasklet-based parallelization is implemented by distributing the workload according to the seeds. Each tasklet processes one seed out of K, where K represents the number of tasklets per DPU. Tasklets independently query the index for their respective seed and then extend both to the right and left to detect potential alignments. When a high-similarity region is present, multiple consecutive seeds (handled by different tasklets) may detect the same alignment. This requires maintaining a shared list of alignments updated by all tasklets, along with implementing the necessary synchronization mechanisms to ensure consistency.

The index of a protein sequence database can fit into the memory of a few dozen DPUs. In a system comprising several thousand DPUs, the database can be duplicated. This allows queries to be sent to a subset of DPUs, enabling multiple queries to be processed in parallel. The overall parallelization framework, where a continuous stream of queries is handled,
is illustrated in Figure 3. The system operates with a fully asynchronous workflow, ensuring efficiency despite varying query processing times caused by differences in the number of alignments discovered.

* A first thread on the host reads data from the input source and places it in a queue.

* A set of threads, corresponding to the number of database duplications, fetches queries from this input queue and sends them to a subset of available DPUs. These DPUs process the queries and return hits, which are placed in a second queue.

* Another set of threads running on the host retrieves tasks from this second queue to calculate the complete alignments. The results of these computations are stored in a third queue.

* Finally, a last thread synchronizes the results from the third queue and store them.

This asynchronous design is critical, as query processing times can vary significantly depending on the number of alignments identified. It ensures that each stage of the pipeline operates independently, maximizing throughput and resource utilization.

# V. RESULTS

## A. Experimental setup

**Hardware:** On the hardware side, we run all benchmarks on the same server with an Intel® Xeon® Silver 4215 processor (16 hyper-threaded cores) at 2.5 GHz (Skylake architecture), 256 GB DDR4 RAM at 2.4 GHz and 20 UPMEM DIMMs at 350 MHz (corresponding to 40 ranks, or 2,560 DPUs, and a total of 160 GB MRAM memory). The server runs under Debian 10 and uses version 2023.2.0 of the UPMEM SDK. To evaluate energy savings, we connected a power meter that samples power consumption every 10 milliseconds.

**PiM implementation:** The code is available on github: https://github.com/lavenier/pimpang. It requires an UPMEM server to be run.

**Protein Database:** The database stored in the PiM's memory is the UniProt/SwissProt sequence database (version 2020-04) which contains 563,082 proteins. The index requires about 4 GB and can fit into a block of 64 DPUs.

**Query banks:** Two query sequence banks have been constructed. They are respectively made up of 1,000 and 10,000 proteins randomly selected from the UniProt/TrEMBL protein database.

**Reference software:** Blastp is used as reference software [6]. This software has been in common use for over nearly 30 years, and is the benchmark for bioinformatics. By default, it produces alignments with gaps, but can be constrained to produce alignments without gaps. Blastp is parallelized and the number of threads is configurable. The command below specifies Blastp parameters to produce results equivalent to our implementation.

1: blastp -query <query_file> -db <db_file>

2: -ungapped

<figure><img src="image_5.png" /><figcaption>Fig. 4. Quality evaluation: number of similar and different alignments founded by Blastp and our PiM implementation when querying the SwissProt database with 1,000 proteins</figcaption></figure>

3: -out <align_file>

4: -comp_based_stats F -evalue 1e-6

5: -seg yes

6: -outfmt 6

7: -num_threads N

Line 1: query and database file

Line 2: generate alignments without gap

Line 3: output = alignment file

Line 4: statistical parameters

Line 5: filter to eliminate low complexity sequences

Line 6: output format

Line 7: N = number of threads

## B. Quality

The aim of this work was not to design an algorithm offering better sensitivity than state-of-the-art software, but to design a parallel algorithm on a PiM architecture with a quality of results equivalent to the reference algorithm which, in the case of a protein database search, is Blastp. To compare execution times, we need to ensure that the results are comparable. They are not identical, because the heuristics are different and in some cases lead to different choices. Blastp doesn't find all the alignments. Neither did our implementation. Figure 4 shows the number of alignments found by the two software packages with the 1,000-protein database versus the UniProt/SwissProt database.

Over 90% of alignments are identical. All the alignments found, whether by Blastp or our implementation, are statistically correct. The same statistical model based on alignment scores is used in both cases (no composition-based statistics). The difference essentially stems from the heuristics implemented, even though the “seed-and-extend” strategy is used in both cases. False negatives often concern “small” alignments that are more difficult to spot and whose similarity percentage is low. Alignments with high similarity between proteins are systematically found by both software packages.
### C. Speedup

The speedup was measured by varying the number of the following resources: (1) The number of active cores on the host processor. This can be controlled by the linux `taskset` command that, for a given application, specifies which cores will be activated; (2) The number of PiM DIMMs used during a database search. The following table (TABLE 1) reports the execution times of Blastp and the execution for the various PiM configurations. It corresponds to the search of 10,000 proteins in the UniProt/SwissProt database (563,082 proteins).

<table><caption>TABLE I
EXECUTION TIME AND SPEED-UP.</caption><thead><tr><th rowspan="2">#cores</th><th rowspan="2">Blastp</th><th colspan="5">PiM: # DIMMs</th></tr><tr><th>1</th><th>2</th><th>4</th><th>8</th><th>16</th></tr></thead><tbody><tr><td>16</td><td>850</td><td>485 (1.8)</td><td>247 (3.4)</td><td>130 (6.5)</td><td>77 (11.0)</td><td>56 (15.2)</td></tr><tr><td>8</td><td>1493</td><td>488 (3.1)</td><td>249 (6.0)</td><td>132 (11.3)</td><td>81 (18.4)</td><td>60 (25.7)</td></tr><tr><td>4</td><td>2821</td><td>488 (5.8)</td><td>249 (11.3)</td><td>131 (21.5)</td><td>78 (36.2)</td><td>59 (47.8)</td></tr></tbody></table>

The execution times are in seconds. Hyperthreading is activated. The column "Blastp" indicates the execution time of the software Blastp according to the number of cores used (leftmost column). The number of threads allowed is twice the number of cores to make the most of the multi-threaded architecture. The columns "1" to "16" indicate the execution times of the PiM implementation run with 1 to 16 PiM DIMMs and using 4, 8 and 16 physical cores. The speedup is indicated between parenthesis. It is computed as the Blastp execution time divided by the PiM execution time at equivalent core resources. The figure 5 plots the result.

To achieve significant acceleration compared to a multi-core server, the number of DIMMs must be proportional to the number of cores. For example, the addition of a single DIMM on a server with a 16-core processor brings little additional performance. But the greater the difference between the number of cores and the number of DIMMs, the better the speed-up.

<figure><img src="image_6.png" /><figcaption>Fig. 5. Speedup Blastp vs PiM implementation. It is given for several configurations depending on the number of cores and DIMM modules.</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Fig. 6. Instantaneous power consumption of Blastp and PiM execution on the UPMEM server (unit = Watts). Blastp is successively run with 32 threads, 16 threads and 8 threads. PiM is successively run using 16, 8, 4, 2 and 1 PiM DIMMs.</figcaption></figure>

It can also be seen that from 8 DIMM modules upwards, and whatever the number of cores, acceleration progresses more slowly. This is due, in part, to the time required to load the index into all the PiM memories. This operation is sequential, and its execution time is proportional to the number of DIMM modules. The higher the number of DIMMs, the longer the loading time. On the other hand, the number of requests that can be processed in parallel increases, which reduces overall computing time. The execution time of the sequential part increases, while the execution time of the parallel part decreases, resulting in slowing down the speed-up. However, this phenomenon tends to fade as the pool of requests increases. Another situation would be to consider a server completely dedicated to querying a protein sequence database. In this case, the bank loading time would be completely amortized over time.

The measurements carried out vary two parameters: the number of host processor cores and the number of PiM modules. It shows that a modest-sized server equipped with PiM memory is very competitive compared with a larger server. In our experiments, Blastp using cores 16 of the UPMEM server (850 sec.) is 14 slower than a 4-core server equipped with 128 GB of PiM memory running a similar program on the same data (60 sec.).

### D. Energy consumption

The UPMEM server has been equipped with a power meter that samples instantaneous power every 10 ms. The wattmeter is directly connected to the server's power supply. It therefore
<figure><img src="image_8.png" /><figcaption>Fig. 7. Total energy consumption of Blastp and PiM execution in kJ.</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Fig. 8. Energy saving on a 16-core and 8 core server according to the number of PiM modules.</figcaption></figure>

measures the instantaneous and actual power consumption of all server components. For each program execution, we therefore have the exact consumption profile.

Figure 6 displays the instantaneous power of Blastp and different PiM configurations relatively to the number of PiM DIMM modules. A first observation is that a server in idle mode, i.e. without running any user applications, consumes a significant amount of electrical power, in the present case around 410 Watts. Although surprising, this idle consumption is in line with other studies on the subject [1].

The following table reports the average power consumption in Watts of the UPMEM server when running Blastp and PiM implementation.

<table><caption>TABLE II POWER CONSUMPTION IN WATTS</caption><thead><tr><th rowspan="2">#cores</th><th rowspan="2">Blastp</th><th colspan="5">PiM: # DIMMs</th></tr><tr><th>1</th><th>2</th><th>4</th><th>8</th><th>16</th></tr></thead><tbody><tr><td>16</td><td>520</td><td>651</td><td>662</td><td>676</td><td>677</td><td>686</td></tr><tr><td>8</td><td>483</td><td>555</td><td>569</td><td>577</td><td>576</td><td>581</td></tr><tr><td>4</td><td>462</td><td>503</td><td>507</td><td>510</td><td>510</td><td>515</td></tr></tbody></table>

From this electrical consumption, we can easily deduce the energy consumed for a given run: it is computed as the product of its execution time with its average power consumption. The figure 7 displays these values (unit = kJ) for Blastp and PiM implementation.

To accurately assess the energy savings, it would be necessary to measure Blastp's power consumption on a server without PiM modules. The UPMEM server contains 20 modules. When these modules are not in use, the power consumption per module is around 5 Watts, according to UPMEM designers. We can therefore estimate that the energy consumption of a server without PiM components, and when no user application is running, is about 310 watts. (410 - 20 × 5). The energy saving (ES) is then given by:

$$ES = \frac{ET_{Blastp} \times (PW_{Blastp} - 100)}{ET_{PiM} \times PW_{PiM}}$$

with:

<table><tr><td>ET<sub>Blastp</sub></td><td>Execution time of Blastp</td></tr><tr><td>PW<sub>Blastp</sub></td><td>Average power of Blastp</td></tr><tr><td>ET<sub>PiM</sub></td><td>Execution time using PiM modules</td></tr><tr><td>PW<sub>PiM</sub></td><td>Average power using PiM modules</td></tr></table>

Figure 8 shows energy savings as a function of the number of PiM modules. The 16-core curve corresponds to the actual measurement on the UPMEM server. The 8-core curve is an extrapolation based on [2] to estimate the energy consumption of an 8-core server. We can clearly see that energy savings are directly proportional to the number of PiM modules. An 8-core server equipped with 16 PiM modules will consume 13 times less for the same run application with the same data.

Another way of measuring the energy efficiency brought by the addition of PiM devices, and probably more suited to the application context, is to look at the energy cost per request. Here, a request corresponds to a similarity search in the bank for a single protein sequence. Figure 9 shows the energy cost per request. For Blastp we considered a server without PiM DIMM modules. The consumption of the server has also been adjusted according to 16-core or 8-core configurations.

## E. GPU comparison

GPUs are powerful hardware accelerators that can also advantageously be used to accelerate sequence comparison tasks. Their high parallel processing capabilities make them well-suited for handling large-scale computational workloads. Recent studies [23] [31] show impressive speedup factors compared to CPU implementations. It is therefore particularly interesting to compare PiM and GPU approaches in terms of both execution time and energy consumption.

A common metric for evaluating computing power in this domain is GCUPS or TCUPS (10⁹ or 10¹² Cell Update Per Second). It refers to the dynamic programming algorithm, where the computational complexity is expressed by the number of matrix cells computed per second. This metric applies to both global and local alignment searches. Searching a query
<figure><img src="image_10.png" /><figcaption>Fig. 9. Cost in Joule of a request to search the SwissProt protein bank for Blastp and PiM implementation according to the number of PiM DIMM modules</figcaption></figure>

bank of $N_q$ amino acids against a reference bank of $N_b$ amino acids leads to the computation of $N_q \times N_b$ CUPS.

In [23] (Table 3), the scan of the SwissProt database (release 23.03, 569793 sequences, 206858779 aa) of 20 protein sequences (39436 aa) with the CUDASW++4.0 software on a server equipped with an NVIDIA Hopper H100 GPU board takes 2.9 seconds. This gives an overall performance of 2.81 TCUPS. On a 16-DIMM PiM configuration, comparing 10,000 query sequences (3359776 aa) with the SwissProt database (release 20.04, 563032 sequences, 202799066 aa) is completed in 56 seconds (cf. TABLE 1), resulting in a performance of 12.16 TCUPS. However, this comparison should be nuanced by the fact that computation on PiM is simpler, as it only produces alignments without gaps. This is not the case for the CUDASW++4.0 software that computes full gap alignments.

The same GCUPS or TCUPS metric can also be used to compare energy consumption. Referring to TABLE II, scanning the SwissProt database consumes 686 watts on the PiM server, resulting in an energy efficiency of 16.5 GCUPS/Watt. In [23], CUDASW++4.0 achieves optimal energy efficiency when the power consumption of the H100 GPU is capped at 200W. In this case, the energy efficiency reaches 15.7 GCUPS/Watt. However, this does not account for the total power consumption of the server in which the H100 GPU board is installed.

## VI. CONCLUSION

This study shows the benefits, both in terms of faster execution times and energy savings, for protein database search using PiM components. This type of application lends itself particularly well to PiM parallelization. The principle is to distribute the database overall the PiM memories and broadcast a query to each processing element. Each of them works independently and returns to the host processor only relevant information. This process is akin to filtering. Only a fraction of useful information is sent back to the processor, thus avoiding numerous memory transfers and relieving it of low-complexity calculations.

A major challenge is to manage parallelism throughout the system. Several levels of parallelism coexist: the host processor has several cores, the PiM memory has a large number of small computing units and, in the case of the processors developed by UPMEM, these are multithreaded. A good implementation is one that makes skilful use of all resources and ensures a good balance between them. Direct parallelization of an algorithm or software is not usually immediate. It often requires a restructuring of the overall code framework to adapt to the hardware architecture. Our implementation does not follow the structure of the original Blastp code. However, the principles are retained, but adapted to make the most of hardware resources.

The current PiM implementation is a degraded version of Blastp, since it only calculates alignments without gaps. The aim was above all to demonstrate that this type of application was suitable for parallelization on PiM, and that the gains could be substantial. The next step is to integrate the calculation of alignments with gaps. In this implementation, the host processor rapidly calculates gap-free alignments from the “hits” produced by the PiMs memories. It will do the same to generate alignments with gaps. The calculation is more complex and should require more computing resources on the host. For the moment, as we can see, the limitations do not come from the host, since the number of cores (see Table 1, section V-C) has an extremely limited effect on the total execution time. The computation of more complex alignments should therefore not drastically alter current results.

Although Blastp is still the benchmark, other protein database search programs are emerging as excellent tools for processing ever larger volumes of data more quickly. These include DIAMOND [21], which incorporates different search heuristics. It has several sensitivity modes that can be set according to the precision required. Execution times are, of course, inversely proportional to the sensitivity required. Our next target is this type of software, as it is often involved in huge projects requiring thousands of hours of computation.

Many conditions are now in place for PiM architectures to find their place on the memory market. Firstly, they offer a paradigm that avoids the bottleneck of the von Neumann model, whose computation speed is limited by memory access time, a fundamental limitation for many applications centered on massive data usage. Secondly, they respond to the need to reduce the power consumption of digital systems. Finally, they have reached a good level of technological maturity, confirmed by various prototypes and industrial products.

Large-scale adoption of the PiM paradigm depends, however, on the ability to create an ecosystem in which several approaches can be tested, evaluated or compared. This will ensure that the concept is assimilated and accepted by a range of players, such as system architects, software engineers and end-users, who will directly see the benefits in terms of reduced energy power and processing times. The creation of this ecosystem requires joint design across the entire chain, from technology, hardware, system, software and programming environment, right through to application development.
A key point is undoubtedly the ease of access to their programming. But we still have a long way to go before we can automatically compile and parallelize code that takes these memories into account. A good scenario would be for modifications to existing code to be as minimal as possible, independent of hardware architecture and based on high-level generic standards. Pending standardization of the PiM model, we need to build a programming framework that reflects this paradigm, but with minimal exposure to implementation details. This implies a major effort at software and systems level. We are also working on this to offer a simplified programming framework.

## REFERENCES

[1] M. Jay, V. Ostapenco, L. Lefèvre, D. Trystram, A-C. Orgerie, et al., "An experimental comparison of software-based power meters: focus on CPU and GPU", CCGrid 2023 - 23rd IEEE/ACM international symposium on cluster, cloud and internet computing, May 2023, Bangalore, India.

[2] Y. Falevoz, J. Legriel, "Energy Efficiency Impact of Processing in Memory: A Comprehensive Review of Workloads on the UPMEM Architecture", In: Zeinalipour, D., et al. Euro-Par 2023: Parallel Processing Workshops. Euro-Par 2023. Lecture Notes in Computer Science, vol 14352.

[3] UPMEM web site: https://www.upmem.com/

[4] F. Devaux, "The true Processing In Memory accelerator," 2019 IEEE Hot Chips 31 Symposium (HCS), Cupertino, CA, USA, 2019.

[5] S.F. Altschul, W. Gish, W. Miller, E.W Myers, D.J Lipman, "Basic local alignment search tool", Journal of Molecular Biology, 215(3), 1990.

[6] S.F. Altschul, T.L. Madden, A.A. Schäffer, J. Zhang, Z. Zhang, W. Miller, D.J. Lipman, "Gapped BLAST and PSI-BLAST: a new generation of protein database search programs", Nucleic Acids Research, 25(17), 1997.

[7] S. Goenka, Y. Turakhia, B. Paten and M. Horowitz, "SegAlign: A Scalable GPU-Based Whole Genome Aligner," in 2020 SC20: International Conference for High Performance Computing, Networking, Storage and Analysis (SC), Atlanta, GA, US, 2020.

[8] A. Haghi et al., "WFAsic: A High-Performance ASIC Accelerator for DNA Sequence Alignment on a RISC-V SoC", ICPP 2023: 52nd International Conference on Parallel Processing, Salt Lake City UT USA, 2023.

[9] P. Guerdoux-Jamet, D. Lavenier "SAMBA: hardware accelerator for biological sequence comparison", Comput Appl Biosci, 1997.

[10] Illumina documentation, https://help.dragen.illumina.com/

[11] M. Isa et al., "FPGA-based protein sequence alignment: A review", EPJ Web Conf, International Conference on Applied Photonics and Electronics, 2017

[12] A. Al Kawam, S. Khatri, A. Datta, "A Survey of Software and Hardware Approaches to Performing Read Alignment in Next Generation Sequencing", IEEE/ACM Transactions on Computational Biology and Bioinformatics, vol 14, no 6, 2016.

[13] J. Cheng, L. Hu, W. Xu, H. Chen, T. Xia, "Hardware Acceleration of Minimap2 Genomic Sequence Alignment Algorithm", ICPP'24: Proceedings of the 53rd International Conference on Parallel Processing. 2024.

[14] N. Ahmed, J. Lévy, S. Ren, et al., "GASAL2: a GPU accelerated sequence alignment library for high-throughput NGS data", BMC Bioinformatics 20, 520, 2019.

[15] D. Lavenier; L. Xinchun; G. Georges, "Seed-based genomic sequence comparison using a FPGA/FLASH accelerator", 2006 IEEE International Conference on Field Programmable Technology, 2006

[16] Sally A McKee, "Reflections on the memory wall", Proceedings of the 1st conference on Computing frontiers, 2004.

[17] D. Fujiki, X. Wang, A. Subramaniyan, R. Das, "In-/near-Memory Computing", Morgan and Claypool publisher, 2021.

[18] K. Asifuzzaman, N.R. Miniskar, A. R. Young, F. Liu, J.S. Vetter, "A survey on processing-in-memory techniques: Advances and challenges", Memories - Materials, Devices, Circuits and Systems, Vol 4, 2023.

[19] The UniProt Consortium, "UniProt: the Universal Protein Knowledge-base in 2025", Nucleic Acids Research, Volume 53, Issue D1, 6 January 2025.

[20] W.Haque, A. Aravind, B. Reddy, "Pairwise sequence alignment algorithms: a survey", ISTA '09: Proceedings of the 2009 conference on Information Science, Technology and Applications, 2009.

[21] B. Buchfink, C. Xie, D.H. Huson, "Fast and sensitive protein alignment using DIAMOND", Nature Methods 12, 2015.

[22] S. Diab, A. Nassereldine, M. Alser, J. Gómez Luna, O. Mutlu, I. El Hajj, "A framework for high-throughput sequence alignment using real processing-in-memory systems", Bioinformatics, Volume 39, Issue 5, May 2023.

[23] B. Schmidt, F. Kallenborn, A. Chacon, et al., "CUDASW++4.0: ultrafast GPU-based Smith-Waterman protein sequence database search", BMC Bioinformatics 25, 342, 2024.

[24] R. Baeza-Yates, G. Gonnet, "A new approach to text searching" Commun. ACM, 35(10), 1992.

[25] D. Cali, G. Kalsi, Z. Bingöl Z., et al., "GenASM: A high-performance, low-power approximate string matching acceleration framework for genome sequence analysis", In: 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 2020.

[26] O. Gotoh, "An improved algorithm for matching biological sequences. Journal of molecular biology", 162(3), 1922.

[27] S. Needleman, C. Wunsch, "A general method applicable to the search for similarities in the amino acid sequence of two proteins", Journal of molecular biology, 48(3), 1970.

[28] Marco-Sola S., Eizenga J. M., Guarracino A., et al., "Optimal gap-affine alignment in o (s) space", bioRxiv, 2020.

[29] A. Alonso-Marín, I. Fernandez, Q. Aguado-Puig, J. Gómez-Luna, S. Marco-Sola, O. Mutlu, M. Moreto, "BIMSA: accelerating long sequence alignment using processing-in-memory", Bioinformatics, Volume 40, Issue 11, November 2024.

[30] E. Rucci, C. Garcia, G. Botella, AE. De Giusti, M. Naiouf, M. Prieto-Matias, "OSWALD: OpenCL Smith and Waterman on Altera's FPGA for Large Protein Databases", the International Journal of High Performance Computing Applications, 32(3), 2016.

[31] F. Kallenborn, A. Chacon, C. Hundt, H. Sirelkhatim, K. Didi, C. Dallago, M. Mirdita, B. Schmidt, M. Steinegger, "GPU-accelerated homology search with MMseqs2", bioRxiv, bioRxiv 2024.11.13.623350; doi: https://doi.org/10.1101/2024.11.13.623350, 2024.