**Parallel and Distributed Computation of a Fingerprint Access Control System**

\*\*Double blind review, please do not include authors information in this version \*\*

Received Date: \*date

Accepted Date: \*date

Published Date: \*date

**HIGHLIGHTS**

  - Design of a fingerprint-based access control system to secure premises

  - Evaluation of the execution time of a fingerprint-based access control system, sequential and parallel approach

  - Comparison of the execution time of a fingerprint-based access control system to secure premises, sequential and parallel approach

ABSTRACT

*This work evaluates the runtime performance of a single-mode biometric recognition system for fingerprint-based access control to secure premises. To speed up the computation time in this system, we resorted to parallel programming, targeting more loops in the verification module. Our approach would therefore be to parallelize all loops that are computationally intensive during the verification of fingerprints in the database. On this, we exploited Microsoft's Task Parallel Library, specifically exploiting the for and foreach loops. On the test set performed in sequential and parallel versions in the different data sizes, namely 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, and 600, we can state that the results obtained by the sequential and parallel implementations of our performance test programs allowed us to determine the best approach. Therefore, it is very clear that the sequential program is too greedy in terms of computation time compared to the parallel program which minimizes the computation time.*

*Keywords:* Task Parallel Library, Biometrics, Fingerprint, Access control, Parallel computing.

**0. INTRODUCTION**

**0.1. Problem**

Each technological progress opens the horizon to new needs.

Applications are becoming very demanding in terms of computing time and memory space, especially real-time and simulation applications. Parallelism has always been a possibility to meet this demand for performance.

The real problems that arise, as far as verification in a student access control system in an institution is concerned, especially when we have a mass of information in the database, are slow, high computation time, which makes verification tedious.

Thus, in order to motivate the continuation of this work, questions of the kind listed below will not be ruled out:

  - What are the most efficient methods we can apply to reduce the computation time in an access control system?

  - How can we optimise the runtime computation problem in a fingerprint-based access control system?

These issues are the real problems that we will examine in the following.

**0.2. Assumptions**

To solve these problems, the optimal solution we propose in this work is to exploit parallel programming, with the aim of improving the capabilities of the parallel computing verification module through the implementation of parallel loops.

More precisely, we will design a parallel computation verification module based on Microsoft's Task Parallel Library, exploiting more precisely the for and foreach loops.

**0.3. Objective**

The general objective of this work is to design a tool that will optimize the computation time of an access control management system.

**0.4 Interest of the subject**

The interest of such an approach is to make a major contribution to the scientific community, by providing them with a logical approach to optimizing the runtime performance of an access control system for premises secured by fingerprints.

**1. Parallel processing**

**1.1 Some general information**

Parallel processing is a form of information processing that allows the exploitation of concurrent events at runtime. These events are located at several levels: at the program level, at the procedure level (coarse-grained parallelism), at the instruction block level (medium-grained parallelism) or within an instruction (fine-grained parallelism) \[6, 8\].

Parallelism is the fact of making several processors cooperate with the aim of accelerating the resolution of a single problem, improving computing performance, increasing the size of the problems to be solved, producing machines with a good cost/performance ratio, etc. \[10, 14\].

The introduction of parallelism within a program can be done at the level of procedures or even loops of the procedure. It requires the decomposition of the program into tasks, the search for dependency relationships between these tasks by constructing a directed graph, whose vertices represent the tasks and edges represent the dependencies between the tasks, called a "dependency graph", and the parallel programming of independent tasks \[1, 3, 11\].

**2. Presentation of the work**

This work is in the context of parallel application programming which requires high computational capacities. Its objective is to study the execution time performance of an access control system for premises secured by fingerprints \[16, 17, 18\].

To do so, we proceed as follows:

  - We take our fingerprint verification program, in its sequential performance test version, on a set of six hundred individuals.

  - We run this sequential version on the different data sizes, namely 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, and 600. The aim here is to evaluate the execution times of each data size by responding to the sequential test program.

  - We parallelize our test program, namely the fingerprint verification program, using the parallelism of the for and foreach loops of the Task Parallel Library.

  - We run this parallel version on the different data sizes, namely 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, and 600. The aim here is to evaluate the execution times of each data size by responding to the parallel test program.

  - We interpret the results obtained from the sequential and parallel implementations of our performance test programs to determine the best approach.

**2.1. System Implementation and Architecture**

**2.1.1. Implementation**

In this last part, we are interested in the tools used for the realization of our application as well as the main interfaces of the application.

**2.1.1.1. Choice of hardware and software**

**1. Hardware environment**

In order to carry out our research project, we have used the following materials **\[2\]**:

  - Three laptops (LAPTOP) from the HP EliteBook brand.

Here are the characteristics of this machine:

  - Mark : HP EliteBook ;

  - Operating system: Windows 8.1 Professionnel 64 bits ;

  - Processor : Intel (TM) Core i5 1,70 GHz, \(\sim\)2,40 GHz ;

  - RAM Memory capacity : 8 Go ;

  - Hard disk capacity: 300 Go.

**These computers contain a biometric application in C\# that allows instructions to be given to the Arduino card via the serial port and a database replicated in three different instances representing our three sites.**

**2.1.1.2. Hardware architecture of the system**

The material architecture of the project is as follows **\[2, 3\]** :

  - > Personal Digital, a fingerprint reader, communicating through the USB port ;

  - > A computer, containing a biometric application in C\# that allows instructions to be given to the Arduino card via the serial port and a database replicated in three different instances representing our three sites.

  - > The Arduino card, which is programmed to analyse and generate electrical signals, in order to carry out automatic door opening and closing tasks (access control).

  - > TOWER PROTM Micro Servo 9g SG90, a stepper motor that will allow us to make the opening and closing movements of the doors.

![](621945f36931b_media/media/image1.png)

Figure 2-1: Hardware architecture of the system

**2.2. Results obtained**

Here is a representation of some of the graphical interfaces of our application:

![](621945f36931b_media/media/image2.png)

Figure 2-2: The material tools of our project

![](621945f36931b_media/media/image3.png)

Figure 2-3 : The enrolment window

![](621945f36931b_media/media/image4.png)

Figure 2-4: The identification window with a valid fingerprint

**2.3 Interpretations of the results obtained**

The table below represents the different values of execution time of the sequential version on the different data sizes, namely 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, and 600.

Table 2-1: Sequential version run times

| Data size | Execution time(ns) |
| --------- | ------------------ |
| 50        | 0,11               |
| 100       | 0,26               |
| 150       | 0,39               |
| 200       | 0,53               |
| 250       | 0,67               |
| 300       | 0,81               |
| 350       | 0,95               |
| 400       | 1,09               |
| 450       | 1,23               |
| 500       | 1,37               |
| 550       | 1,51               |
| 600       | 1,65               |

The following graph is intended to evaluate the execution times of each data size when responding to the sequential test program.

<span class="chart">\[CHART\]</span>

Figure 2-5: Execution time of the sequential version

The table below represents the different values of execution time of the parallel version on the different data sizes, namely 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, and 600.

Table 2-2: Parallel Version Execution Times

| Data size | Execution time (mn:s:ms) |
| --------- | ------------------------ |
| 50        | 0,05                     |
| 100       | 0,12                     |
| 150       | 0,18                     |
| 200       | 0,25                     |
| 250       | 0,31                     |
| 300       | 0,38                     |
| 350       | 0,44                     |
| 400       | 0,51                     |
| 450       | 0,57                     |
| 500       | 0,64                     |
| 550       | 0,7                      |
| 600       | 0,77                     |

The following graph is intended to evaluate the execution times of each data size when responding to the parallel test program \[4, 5, 6\].

<span class="chart">\[CHART\]</span>

Figure 2-6: Execution time of the parallel version

The table below represents the different values of execution times of the sequential and parallel versions on the different data sizes, namely 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, and 600. The aim is to evaluate the execution times of each data size by responding to the sequential and parallel test program to determine the best approach.

Table 2-3: Sequential and parallel execution times

| Data size | Sequential execution time (mn:s:ms) | Parallel execution time (mn:s:ms) |
| --------- | ----------------------------------- | --------------------------------- |
| 50        | 0,11                                | 0,05                              |
| 100       | 0,26                                | 0,12                              |
| 150       | 0,39                                | 0,18                              |
| 200       | 0,53                                | 0,25                              |
| 250       | 0,67                                | 0,31                              |
| 300       | 0,81                                | 0,38                              |
| 350       | 0,95                                | 0,44                              |
| 400       | 1,09                                | 0,51                              |
| 450       | 1,23                                | 0,57                              |
| 500       | 1,37                                | 0,64                              |
| 550       | 1,51                                | 0,7                               |
| 600       | 1,65                                | 0,77                              |

The graph below allows us to interpret the results obtained by the sequential and parallel implementations of our performance test programs to determine the best approach. It is very clear that the sequential program is too greedy in terms of computation time compared to the parallel program which minimises the computation time.

<span class="chart">\[CHART\]</span>

Figure 2-7: Comparison between sequential and parallel execution times

**CONCLUSION**

We have come to the end of our work which allows us to evaluate the execution time performance of a single mode biometric recognition system for access control to premises secured by fingerprints.

To speed up the computation time in this system, we resorted to parallel programming, targeting more loops in the verification module.

Our approach was therefore to parallelize all loops that are computationally intensive during the verification of fingerprints in the database.

For this, we exploited Microsoft's Task Parallel Library, specifically exploiting the for and foreach loops.

On the test set performed in sequential and parallel versions in the different data sizes, namely 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, and 600, we can state that the results obtained by the sequential and parallel implementations of our performance test programs allowed us to determine the best approach. Therefore, it is very clear that the sequential program is too greedy in terms of computation time compared to the parallel program which minimizes the computation time.

**Bibliographic references**

**\[1\].** Manel ABDELLATIF, Accéleration des traitements de la sécurité mobile avec le calcul parallèle, Mémoire présenté à l’Ecole de Technologie Supérieure, Montréal, le 31 mars 2016.

**\[2\].** *Bopatriciat Boluma Mangata et Al., Contribution of an Embedded and Biometric System in a Replicated Database for Access Control in a Multi-Entry Institution, International Journal of Science and Research (IJSR), Volume 10 Issue 3, March 2021.*

**\[3\].** Bopatriciat Boluma Mangata *& al*, Performance evaluation of a single access contol system, journal of research in engeneering and applied sciences, january 2022.

**\[4\].** Chunchao Li & Al., GPU parallel implementation for real-time feature extraction of hyperspectral images, September 2020.

**\[5\].** Daniele Dall’Ollo & Al., Impact of concurrency on the performance of a whole exome sequencing pipeline, BMS Bioinformatics, Febuary 2021.

**\[6\].** Diane & Al., GPU parallelization of a hybrid pseudospectral geophysical turbulence framework using CUDA, Atmosphere, Febuary 2020.

**\[7\].** T. Fryze & Al., Overview of parallel platformsfor common high performancy computing, RadioEngeneering, Aprel 2021.

**\[8\].** FABIEN REUMONT-LOCKE, Méthodes efficaces de parallélisation de l’analyse de traces noyau, Département de génie informatique et génie logiciel, Ecole polytechnique de Montréal, Mémoire présenté en vue de l’obtention du diplôme de maîtrise ès sciences appliquées (génie informatique), août 2015.

**\[9\].** Ocena K & Al, Parallel computing in genomic research: advances and applicarions, November 2015.

**\[10\].** Shirin Tavara & Al, Effects of network topology on the performance of consensusand distributed learning of SVM using ADMM, PEERJ computer science, March 2021.

**\[11\].** Shixcang Wan & Al., Halign-II: efficient ultra-large multiple sequence alignment and phylogenetic tree reconstruction with distributed and parallel computing, Algorithms for molecular biology, September 2017.

**\[12\].** Volodymyr Melnykov & Al., MixSim: An R package for simulating data to study perfoemance of clustering algorithms, Journal of statistical software, November 2012.

**\[13\].** David B. williams-young & al., on the efficient evaluation of the exchange correlation potention potential on graphics prossing unit cluster, frontiers in chemistry, decembre, december 2020,

**\[14\].** Yiming Miao & Al., Reseach and implementation of ECG-Based biological recognetion parallelization, IEEE Access, January 2018.

**\[15\].** Parallel Programming in .NET : <http://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/>

**\[16\].** Développement parallèle pour des machines multi-cœur en .NET 4.0 : [https://blog.octo.com/developpement-parallele’pour-des-machines-multi-coeurs-en-net-4-0/](https://blog.octo.com/developpement-parallele'pour-des-machines-multi-coeurs-en-net-4-0/)

**\[17\].** Dataflow (Task Parallel Library) : <https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/dataflow-task-parallel-library>

**\[18\].** Read TPL Dataflow by Example: <https://leanpub.com/tpldataflowbyexample/read>
