Laurent-Stéphane Didier
email: laurent-stephane.didier@univ-tln.fr

Jean-Marc Robert
email: jean-marc.robert@univ-tln.fr

Yssouf Fangan
email: fanganyssouf.dosso@emse.frnadia.el-mrabet@emse.fr

Nadia El Dosso

Mrabet

A software comparison of RNS and PMNS

Keywords: Modular arithmetic, Residue Number System, Polynomial Number System, SIMD

The Polynomial Modular Number System (PMNS) and the Residue Number System (RNS) are integer number systems which aim to speed up modular arithmetic. Their parallel properties make them suitable for the implementation of cryptographic applications on modern processors with SIMD instructions. In this work, we will show the implementation choices made for the modular multiplication in both systems and compare their implementation performances for several sizes of moduli. We target the Intel 64-bit sequential instruction set and the Intel AVX-512 vector instruction set. This instruction set allows significant speed-ups up to 1 621 bit size moduli, while the vectorized PMNS implementation is up to 2.5 times faster than the vectorized RNS, though the vectorized RNS becomes slightly better for 3 251 bits, due to the difficulty to find a PMNS with a suitable parameter n. The vectorized RNS implementations reach performance levels close the state-of-the-art GMP library, while the retired instruction counts are lower for sizes between 401 and 3 251 bits.

I. INTRODUCTION

Most protocols in public key cryptography require modular arithmetic operations over large integers. The classical representation is the main choice of cryptographers and standards [START_REF] Nist | NIST publications[END_REF]. In this representation an element of a finite field F p , for p a large integer, is seen as an integer modulo p. The GMP library [START_REF] Granlund | GNU multiple precision arithmetic library 6[END_REF] is the reference for efficiency in the classical representation.

Alternative candidates such as Residue Number System (RNS) and Polynomial Modular Number System (PMNS) have been independently studied in the literature [START_REF] Shenoy | Fast base extension using a redundant modulus in rns[END_REF]- [START_REF] Coladon | MPHELL: A fast and robust library with unified and versatile arithmetics for elliptic curves cryptography (extended version)[END_REF]. Those representations of a finite field aim to speed up implementation of modular arithmetic. The RNS representation consists in choosing a base of n small relatively primes m i such that n i=1 m i ≥ p. The computations are done in the smaller fields F mi and the reconstruction of the integers relies on the Chinese remainder theorem. The size of the m i s is adapted to fit the machine words. The Polynomial Modular Number System (PMNS) is a non positional, modular integer number system in which elements are represented as polynomials with integer coefficients. The representation ensures that the coefficient size is small enough to make the computation efficient. In practice, this size corresponds to the size of machine words. These two representations support the paralellization of the computation since operations over each moduli or coefficients are independent. Furthermore, both arithmetics have sidechannel attack resistance properties [START_REF] Didier | Randomization of Arithmetic over Polynomial Modular Number System[END_REF], [START_REF] Courtois | Resilience of randomized rns arithmetic with respect to side-channel leaks of cryptographic computation[END_REF], [START_REF] Negre | Side channel counter-measures based on randomized AMNS modular multiplication[END_REF].

Several hardware implementations illustrate that those representations can be more efficient than the classical one [START_REF] Bigou | Single base modular multiplication for efficient hardware RNS implementations of ECC[END_REF]- [START_REF] Chaouch | Two hardware implementations for modular multiplication in the AMNS: sequential and semi-parallel[END_REF]. However, no software comparison exists. The software library available in [START_REF] Coladon | MPHELL: A fast and robust library with unified and versatile arithmetics for elliptic curves cryptography (extended version)[END_REF] implements the PMNS arithmetic in sequential mode. The parallelization is now possible using vectorization even in software implementation.

Our contributions: we propose the first software comparison of the RNS and PMNS, in both cases, i.e. parallel and sequential implementations of Montgomery modular multiplications. The coefficient number in PMNS representation influences the efficiency of computations. We propose an evaluation of the optimal number of coefficients for given sizes of large prime p. We compare the performance results of our parallel and sequential PMNS and RNS implementations to the GMP library [START_REF] Granlund | GNU multiple precision arithmetic library 6[END_REF].

Organisation of the paper: In Section II we will recall the definition and properties of RNS and PMNS representation. The complexity of both representations is analysed in Section III. Section IV presents our implementations and results.

II. BACKGROUND ON PMNS AND RNS

A. Background on RNS

Residue Number Systems are non positional integer number systems based on the Chinese Remainder Theorem [START_REF] Garner | The residue number system[END_REF]- [START_REF] Knuth | Art of computer programming[END_REF]. In this system an integer x is represented by its remainders x i = x mod m i , where m i are relatively prime numbers. The set B m = {m 1 , m 2 , . . . , m n } constitutes the RNS base composed of n channels. Usually, the moduli m i are chosen of the same w-bit size. We denote M their product. The advantage of such a number system is that additions, subtractions and multiplications can be performed in parallel on each channel:

z i = x i y i mod m i where ∈ {+, -, ×}
a) Conversions: The forward conversion from binary system is simply a modular operation on each base channel. The backward conversion can be done using different approaches. The Chinese Remainder Theorem provides a computation formula in the target number system [START_REF] Knuth | Art of computer programming[END_REF].

x i M m i -1 mi M i M = n i=1 x i M m i -1 mi M i -k • M (1) where M i × M m i -1 mi ≡ 1 (mod M)
Unfortunately, the values used in this sum are large. The conversion to the Mixed Radix System requires modular computations on w-bit integers. In this positional system, an integer x MRS is expressed as follows:

x MRS = x 0 + x 1 m 0 + x 2 m 0 m 1 + • • • + x n-1 n-2 i=0 m i
The conversion into this system [START_REF] Szabo | Residue arithmetic and its applications to computer technology[END_REF] requires O(n 2 ) operations on w-bit numbers and O(n 2 ) stored constants.

A trade-off between these two methods has been proposed by Kawamura et al. [START_REF] Kawamura | Cox-rower architecture for fast parallel montgomery multiplication[END_REF]. They propose to estimate k in equation ( 1) with approximate values through O(n) operations on small values with O(n) constants.

b) Base extension: The base extension allows the conversion of an RNS number from one RNS base to another. This operation consists in a backward conversion and a forward conversion to the targeted RNS base. Both operations are usually interleaved in order to minimize intermediate-value storage.

The base extension proposed by Szabo and Tanaka is based on the mixed-radix conversion [START_REF] Szabo | Residue arithmetic and its applications to computer technology[END_REF]. Shenoy and Kumaresan suggested to compute the value k in equation ( 1) using an extra modulus m e [START_REF] Shenoy | Fast base extension using a redundant modulus in rns[END_REF]. The knowledge of k allows to compute equation [START_REF] Nist | NIST publications[END_REF] in the target RNS base. Similarly, Kawamura et al. proposed another conversion method using an approximate evaluation of k [START_REF] Kawamura | Cox-rower architecture for fast parallel montgomery multiplication[END_REF].

c) Modular multiplication: The RNS modular multiplication is derived from the Montgomery multiplication [START_REF] Montgomery | Modular multiplication without trial division[END_REF] and requires base extensions [START_REF] Bajard | An RNS montgomery modular multiplication algorithm[END_REF], [START_REF] Posch | Modulo reduction in residue number systems[END_REF]. In Algorithm 1 the base extensions can be performed with different strategies. In [START_REF] Bajard | A full RNS implementation of RSA[END_REF], the authors remark that if the dynamic range of base B m is large enough, then the first extension can be approximated. For the second, they use the Shenoy-Kumaresan method [START_REF] Shenoy | Fast base extension using a redundant modulus in rns[END_REF]. In the multiplication described in [START_REF] Kawamura | Cox-rower architecture for fast parallel montgomery multiplication[END_REF] both extensions are Kawamura's.

In our implementations of Algorithm 1, we chose B m and B m in order to use the Bajard-Imbert [START_REF] Bajard | A full RNS implementation of RSA[END_REF] first extension at step 3. For the second extension in step 7, we use the Kawamura et al. method [START_REF] Kawamura | Cox-rower architecture for fast parallel montgomery multiplication[END_REF].

B. Background on PMNS

Polynomial Modular Number System (PMNS) is a nonpositional, modular integer number system in which elements are represented as polynomials with integer coefficients. A PMNS is defined by a tuple (p, n, γ, ρ, E), where p, n, γ and ρ are nonzero positive integers, and E ∈ Z[X] is a monic polynomial, such that deg(E) = n and E(γ) ≡ 0 (mod p).

Algorithm 1 RNS Modular Multiplication

Require: x in B m and B m ; y in B m and B m such that x < 2p and y < 2p.

Precomputation: -p -1 in B m ; p in B m ; M -1 in B m Ensure: z = x × y × M -1 mod p in B m and B m such that z < 2p. 1: s ← x × y in B m and B m 2: t ← s × (-p -1 ) in B m 3: Base extension of t from B m to B m 4: u ← t × p in B m 5: v ← s + u in B m 6: w ← v × M -1 in B m 7: Base extension of w from B m to B m 8: return w
This system has been pioneered by Bajard et al. [START_REF] Bajard | Modular number systems: Beyond the mersenne family[END_REF]. Many works have then been done to improve it [START_REF] Negre | Efficient modular arithmetic in adapted modular number system using lagrange representation[END_REF], [START_REF] Coladon | MPHELL: A fast and robust library with unified and versatile arithmetics for elliptic curves cryptography (extended version)[END_REF], [START_REF] Bajard | Arithmetic operations in the polynomial modular number system[END_REF], [START_REF] Didier | Efficient modular operations using the Adapted Modular Number System[END_REF] or to use it for higher level operations [START_REF] Didier | Randomization of Arithmetic over Polynomial Modular Number System[END_REF], [START_REF] Mrabet | Finite field multiplication combining AMNS and DFT approach for pairing cryptography[END_REF], [START_REF] Mrabet | Efficient multiplication over extension fields[END_REF], [START_REF] Negre | Side channel counter-measures based on randomized AMNS modular multiplication[END_REF], [START_REF] Bouvier | An alternative approach for sidh arithmetic[END_REF].

In the sequel, Z n [X] denotes the set of polynomials in Z[X] which degrees are lower than or equal to n.

If A ∈ Z n [X], we assume A(X) = a 0 + a 1 X + • • • + a n X n
and can equivalently be represented as the vector a = (a 0 , . . . , a n ). Let D, E ∈ Z[X] be two polynomials, then D mod (E, φ) denotes the polynomial reduction D mod E, where the coefficients of the result are computed modulo φ ∈ N \ {0, 1}. Definition 1. Let p 3 and n, ρ 2 be three integers.

Let E ∈ Z n [X] be a monic polynomial and γ ∈ Z/pZ \ {0}, such that E(γ) ≡ 0 (mod p). A tuple B = (p, n, γ, ρ, E) is a PMNS if: 1) ∀A ∈ B, deg(A) < n and A ∞ < ρ, 2) ∀a ∈ Z/pZ, ∃A ∈ B such that: A(γ) ≡ a (mod p). Such a polynomial A is called a representation of a in B and we denote A ≡ a B .
Thus, B designates a PMNS (p, n, γ, ρ, E).

The main operations in PMNS are polynomial addition and multiplication. However, additional operations must be done in order to ensure outputs in B. Indeed, if A, B ∈ B. Then A + B ∞ and A × B ∞ might be greater than ρ. Also, deg(A × B) is most-likely to be greater than n. For the first case, an internal reduction has to be performed and an external reduction for the latter.

1) External reduction: Let

C ∈ Z[X]. The external reduc- tion consists in computing a polynomial R ∈ Z n-1 [X] such that R(γ) ≡ C(γ) (mod p), using E of B, as follows: R = C mod E . Since E ∈ Z n [X] and is monic, R ∈ Z n-1 [X]. Moreover, E(γ) ≡ 0 (mod p) ensures that R(γ) ≡ C(γ) (mod p). The polynomial E is called the external reduction polynomial. 2) Internal reduction: Let R ∈ Z n-1 [X].
The internal reduction aims to compute a polynomial S ∈ B such that S(γ) ≡ C(γ) (mod p). In this paper, we focus on the Montgomery-like approach presented in [START_REF] Negre | Efficient modular arithmetic in adapted modular number system using lagrange representation[END_REF], see Algorithm 2.

It is one of the most efficient internal reduction methods and requires three additional parameters, two polynomials M, M and an integer φ 2 such that:

M (γ) ≡ 0 (mod p) and M = -M -1 mod(E, φ)
Algorithm 2 Coefficients reduction (RedCoeff) [START_REF] Negre | Efficient modular arithmetic in adapted modular number system using lagrange representation[END_REF] Require:

B = (p, n, γ, ρ, E) a PMNS, V ∈ Z n-1 [X], M ∈ B such that M (γ) ≡ 0 (mod p), φ ∈ N \ {0} and M = -M -1 mod(E, φ). Ensure: S(γ) = V (γ)φ -1 (mod p), with S ∈ Z n-1 [X] 1: Q ← V × M mod (E, φ) 2: T ← Q × M mod E 3: S ← (V + T )/φ 4: return S
This method is efficient if φ is a power of two. Also, it induces a multiplicative factor φ -1 on the output. In [START_REF] Didier | Efficient modular operations using the Adapted Modular Number System[END_REF], Didier et al. explain how to deal with this factor. They also present a process to generate efficient PMNS, where φ can be any power of two.

Algorithm 3 presents the Montgomery-like modular multiplication. RedCoeff refers to Algorithm 2.

Algorithm 3 Multiplication in PMNS

Require: A ∈ B, B ∈ B and B = (p, n, γ, ρ, E) Ensure: S ∈ B with S(γ) ≡ A(γ) B(γ) φ -1 (mod p) 1: C ← A.B mod E 2: S ← RedCoeff(C) 3: return S

C. Complexities

In this section, we discuss RNS and PMNS complexities for modular multiplication with the Algorithms 1 and 3. We consider a w-bit processor architecture and basic arithmetic computations performed on w-bit words. Let M and A respectively denote the multiplication and the addition of two w-bit integers. Let L be the notation for logical operations, for instance the AND function, or the right and left shifts on w-bit integers.

1) RNS complexity: The RNS addition and multiplication complexities are linear, while the base extensions are quadratic. However, software RNS implementations suffer from the cost of the basic w-bit modular additions and multiplications which are not provided by the processor instruction set. In Table I, we provide the count of elementary arithmetic operations where n is the number of RNS channels.

2) PMNS complexity: The performances and the required memory storage of a PMNS mainly depend on the target architecture and the value of n. We assume the modular multiplication inputs belong to a PMNS B = (p, n, γ, ρ, E), such that: ρ = 2 II gives the modular multiplication theoretical cost in both cases.

E: E(X) = X n -2 or E(X) = X n -X -1. Table
E(X) Cost X n -2 3n 2 M + (5n 2 -3n)A + (2n -1)L X n -X -1 3n 2 M + (5n 2 -n -2)A + nL

III. SOME COMPLEXITY ANALYSES

In this section, we give an estimation of the optimal value of the parameter n for RNS and PMNS. For RNS, we explain the construction of the system in the context of SIMD software implementations. This leads to the determination of the sizes of p we will consider in the sequel.

We also compare PMNS and RNS complexities, given a modulus size.

A. Estimation of n for a RNS

The authors in [START_REF] Bajard | A full RNS implementation of RSA[END_REF] have provided a bound for the value of M depending of the value of p, thus its size, and also the number n of moduli:

(n + 2) 2 • p < M
The compliance of this condition ensures the correctness of the modular multiplication.

B. Estimation of n for a PMNS

From Table II, it appears that the smaller the number of coefficients n is, the better the cost is. When the value of φ is given, parameter n is computed during the PMNS generation process and cannot be estimated as easily as the number of channels in RNS. In this process, we have to set some PMNS parameters.

In [START_REF] Didier | Efficient modular operations using the Adapted Modular Number System[END_REF], the authors introduce a parameter δ for the PMNS which corresponds to the desired maximum number of consecutive additions without an internal reduction before a modular multiplication. Our implementation strategy for PMNS requires to set values for p, δ and φ.

It is shown [START_REF] Didier | Efficient modular operations using the Adapted Modular Number System[END_REF] that Algorithm 3 outputs a polynomial S ∈ B with inputs

A, B ∈ Z n-1 [X], A ∞ , B ∞ < (δ + 1)ρ, if: ρ 2n|λ| M ∞ and φ 2n|λ|ρ(δ + 1) 2 , where E(X) = X n -λ, with λ ∈ Z \ {0}. If E(X) = X n -2 or E(X) = X n -X -1, we can bound the coefficients of C computed step 1 in Algorithm 3 from [30, Chapter 2, Proposition 2.1]: C ∞ (2n -1) A ∞ B ∞
Thus, the bounds on ρ and φ presented in [START_REF] Didier | Efficient modular operations using the Adapted Modular Number System[END_REF] become:

ρ 2(2n -1) M ∞ and φ 2(2n -1)ρ(δ + 1) 2
This leads to:

φ 4(δ + 1) 2 (2n -1) 2 M ∞
As explained in [START_REF] Didier | Efficient modular operations using the Adapted Modular Number System[END_REF], the parameter M is computed as a short vector of a n-dimensional Euclidean lattice whose covolume is equal to p. From Minkowski's theorem [START_REF] Minkowski | Geometrie der Zahlen[END_REF], we can expect to have:

M ∞ p 1/n
This leads to this approximation:

φ 4(δ + 1) 2 (2n -1) 2 p 1/n (2)
Now, let p be an l-bit modulus; that is p < 2 l . Thus, we look for the smallest integer n such that:

φ 4(δ + 1) 2 (2n -1) 2 2 l/n (3)
So, once p, δ and φ are given, the approximate best value for n is the smallest integer satisfying Equation 3. It can be noticed that the bigger n is, the smaller the right side of Equation 3 is, since p is supposed to be a large integer. Example 1. Let's set φ = 2 64 , δ = 3 and a prime p of size 256 bits (i.e. p < 2 256 ). Then, Equation 3 becomes:

2 64 4(3 + 1) 2 (2n -1) 2 2 256/n
= 64(4n 2 -4n + 1)2 256/n Thus:

2 58 (4n 2 -4n + 1)2 256/n
The minimum value satisfying this equation is n = 5. Remark 1. Equation 3 allows to find an estimation of the best value for n, based on Minkowski's theorem. In practice, this is not always the smallest value of n. Indeed, the lattice reduction used to find M (see [START_REF] Didier | Efficient modular operations using the Adapted Modular Number System[END_REF]Section 5.4]) can compute a polynomial M with an infinity norm small enough to allow better (i.e. smaller) value for n. For instance, with φ = 2 64 , δ = 5 and a prime p of size 401 bits, the minimum value of n satisfying Equation 3 is 9. However, we were able to generate PMNS with n = 8. So, the better the lattice reduction is, the smaller the value of n will be. This lattice reduction process depends on p, γ and the algorithm used (LLL [START_REF] Lenstra | Factoring polynomials with rational coefficients[END_REF] in our case).

C. Complexity comparison for software implementation

In the classic sequential implementation, the word size is 64 bits. In the SIMD case (AVX512 instruction set) and for both systems, we make use of the fused multiplier-adder VPMADD52, which computes simultaneously 8 multiplications-additions of 52-bit operands for the multiplications, providing the results on 64-bit words.

For the RNS system, this leads to the consideration of the values of n whose are multiples of 8. Table III We choose to consider the sizes listed in Table III as reference sizes in our implementations. In the sequel, the value of n for the RNS bases considered with 63-bit moduli is estimated in Table IV Let's now consider the PMNS case. For the integer sizes determined in Table III, we estimated the optimal value of n, for φ = 2 52 and φ = 2 64 , when δ = 5. Table V From Tables I and II, it is clear that for a given value of n, PMNS is more efficient than RNS. However, for a given modulus size, the number of coefficients for PMNS is greater than the number of RNS channels; see Tables III, IV, V. Thus, for larger p, the PMNS complexity will approach that of RNS. We now estimate the threshold above which the PMNS complexity will exceed the RNS one. For this purpose, we consider that all operations except multiplications are equivalent. The cost of one elementary multiplication is considered to be twice that of the other operations, i.e. M = 2A. This leads to the global cost of the RNS modular multiplication:

C RN S = (36n 2 + 101n)A
where n is the number of channels. Similarly, the cost of the PMNS modular multiplication is C P MNS = (11c2 c -2)A where c is the number of coefficients. So, RNS and PMNS performances will meet when:

C RN S ≈ C P MNS , that is c ≈ 1.81n.
A numerical evaluation of n and c gives the following results:

• in case of 52-bit words, this threshold is reached for p of approximately 5 281 bits; • in case of 64-bit words, this threshold is reached for p of approximately 45 000 bits. One may notice that the sizes of p in both cases are above the range of our implementation target. Furthermore, the schoolbook hypothesis for the polynomial multiplication complexity evaluation is undoubtedly greatly unfavorable to the PMNS.

IV. IMPLEMENTATIONS

In this section, we describe the software implementations for both systems, RNS and PMNS. We target sequential native 64bit and AVX512 SIMD implementations. The code is written in C and uses intrinsics for the vectorized version. The vector implementation uses AVX512 instructions that simultaneously compute 8 operations, processed on 512-bit registers. This implementation also uses the FMA instructions which group a multiplication and an addition. Our implementations are available on GitHub 1 .

A. RNS implementation

The elementary operations in RNS are word-length modular operations. Several choices of moduli are possible. In our implementations we chose pseudo-Mersenne numbers whose values are 2 ec with c < 2 e/2 [START_REF] Crandall | Method and apparatus for public key exchange in a cryptographic system[END_REF]. The advantage of such moduli is that c ≡ 2 e mod (2 ec). Thus, the modular reduction is a simple multiplication by c of the leftmost bits added to the rightmost bits [START_REF] Plantard | Efficient word size modular arithmetic[END_REF]. The challenge is to obtain the carry of the addition and the rightmost word of a multiplication without conditional statement in order to have the most efficient of the instruction pipeline.

In our sequential implementation, we target 64-bit operations. We consider 63-bit values in order to easily obtain the carry of an addition. In the target processor, the multiplication can be performed on 64-bit words and provides the result in one 128-bit word. Thus, the rightmost bits can be obtained with simple logical operations.

In our vectorized implementation we make use of the VPMADD52 instructions which are vectorized, fused multiplier-adders. With these vector instructions, the 52-bit integers are packed in 64-bit elements. The higher and lower 52-bit parts of their 104-bit multiplication product is provided 1 https://github.com/rns-pmns-arith by separate instructions. These AVX512 instructions operate on 8-element vectors.

B. PMNS implementation

Our sequential PMNS implementations also make use of the 64-bit native multiplier available in the Intel processors that computes a full 128-bit result. In this case, the value of φ is set to 2 64 .

The VPMADD52 vectorized fused multiplier-adder instructions are also used in the AVX512 versions. As in the RNS case, we take advantage of the SIMD possibilities. In this case, the value of φ is set to 2 52 .

We generated and implemented modular multiplications for PMNS with various modulus p sizes, and we set the parameter δ = 5. This value is, for instance, large enough for elliptic curve scalar multiplication, using the Montgomery Ladder approach described in [START_REF] Goundar | Scalar multiplication on weierstraß elliptic curves from co-Z arithmetic[END_REF] (Algorithm 9); see [30, Chapter 3, Section 3.4.3] for details. We observed that the number n of coefficients of the PMNS does not grow linearly with the width of p as explained in section III-B, and for the AVX512 versions of sizes above 2 029 bits, due to the necessity of systems with positive coefficients for M , the value of n is greater than the one for the corresponding sequential systems. The parameters of the generated PMNS are summarized in table VI. These PMNS were generated using the generator available on GitHub 2 . Our sequential implementations are obtained from the C codes generator available in the same repository. Additionally, we have implemented a C codes generator which takes advantage of AVX512 instruction set extension. It is also available on GitHub3 .

C. Results

1) Experimentation procedure: The measurements were performed on a Dell Inspiron laptop with an 11th Gen Intel Tiger Lake processor i7-1165G7 2.80GHz. The code has been compiled with gcc 10.2.0 and the following options: -O3 -g -lgmp -mavx512f -mavx512dq -mavx512vl -mavx512ifma.

The test procedure was as follows:

• the Turbo-Boost® is deactivated during the tests;

• 1 000 runs are executed in order to "heat" the cache memory; • 50 random data sets are generated, and for each data set the minimum of the execution clock cycle numbers over a batch of 1 000 runs is recorded; • the performance is the average of all these minimums; The same procedure has been used in order to record the number of instructions. The clock cycle counter is rdtsc and the instruction counter is rdpmc with the corresponding selection [START_REF]Intel 64 and IA-32 architectures software developer's manual combined[END_REF]. 2) Results: The performance results are shown in Table VII, and figures 1, 2, 3 and 4. We compared the performance software implementations of RNS, PMNS and the GMP library [2] (6.2.0 version) for 256-bit up to 3 251bit moduli p. The results for 256-bit moduli are irrelevant for the SIMD RNS implementation, since the number of channels should be at least 8 moduli. In our PMNS implementation, the polynomial multiplication is the schoolbook method. In a future work, we intend to study other strategies such as Karatsuba approach [START_REF] Karatsuba | Multiplication of many-digital numbers by automatic computers[END_REF] and multiple word coefficients.

As a general fact, the vectorized implementations dramatically improve the performances of PMNS and RNS operations. The vectorized AVX512 implementation of the PMNS version is the fastest and has the lowest instruction count. It is more than twice as fast as the state of the art GMP Block Montgomery multiplication and is always faster than both sequential and SIMD RNS implementations, except for the greatest size, that is p of size 3 251 bits. Indeed, for such size, we could not find a PMNS with the parameter n estimated section III-C and we had to increase n dramatically in order to have positive coefficients for M (see section IV-B and table VI). This explains why the AVX512 RNS is slightly better than the corresponding AVX512 PMNS for this size of p. Improving our generation process to obtain PMNS suited for AVX512 with smaller value for n remains a challenge we are working on.

The GMP Block Montgomery multiplication is faster than the sequential C implementations of PMNS with φ = 2 64 , regardless of n. However, for the 401-bit primes, the performances are equivalent and the instruction count is smaller by 13 %. The GMP implementation does not seem to take a significant advantage of the SIMD architecture. As a matter of fact, the internal representation of integers is basically a high radix positional representation for which the carry chain has to be maintained. According to the GMP documentation, the library makes limited use of the SIMD instructions except on some specific cases for shift operations [START_REF] Granlund | GNU multiple precision arithmetic library 6[END_REF]. Furthermore, one may notice that the GMP Block Montgomery multiplication is not a constant time implementation, unlike our PMNS/RNS implementations, and might be weak to side channel attacks.

The sequential RNS implementation is the slowest approach, due to the complexity of the base extensions and the cost of the word-size modular arithmetic operations. However, this implementation appears to make the best use of the processor and retires up to 2.8 instructions per cycles.

The vectorized RNS is roughly 1.5 slower than the GMP Block Montgomery multiplication, though the retired instruction counts are 10 to 20 % lower. This is due to the lower Instructions Per Cycle characteristic of the instruction set at the processor micro-architectural level. The SIMD implementations present an acceleration of up to 8.5. This value over 8 is due to some SIMD instructions that have a throughput smaller than 1, and also the efficiency of the fused multiplieradder VPMADD52.

V. CONCLUSION

In this work, we have compared sequential and SIMD implementations of RNS and PMNS modular multiplication, and presented the performance results. The SIMD implementations largely take advantage of the parallel nature of both arithmetics and improves their performances, compared to the sequential cases. PMNS SIMD implementations are faster than GMP implementations, since the underlying arithmetic in GMP is not parallel. RNS implementations suffer from the lack of word-size, modular, arithmetic instructions in the target processor. The presence of such instructions might greatly improve the software performance of this arithmetic. We observed that the degree n of PMNS built for large moduli p grows faster than the number of RNS channels. Thus, for the moduli p up to 1 621 bits, the SIMD PMNS implementation outperforms the GMP library by at least 35% (#clock cycles, p of 1 621 bits). In a future work, we intend to study the impact of the use of multiple-word coefficients and Karatsuba polynomial multiplication, in order to further improve the PMNS implementations.

Fig. 3 :Fig. 4 :

 34 Fig. 3: Timing comparison, PMNS, RNS and GMP block Montgomery modular multiplications, 52-bit words

TABLE I :

 I RNS operation theoretical cost.

	each of them. Thus, addition is a simple polynomial addition,
	whose cost is nA.
	In this paper, we consider sparse external reduction polyno-
	mials

TABLE II :

 II PMNS Modular multiplication theoretical cost, for for two external reduction polynomials, where φ = 2 h .

  provides the sizes of the modulus p corresponding to the different RNS systems we consider in the SIMD implementation case, using 52-bit words multiplication operands.

	n	8	16	24	32
	Size of p	401	807	1 214	1 621
	n	40	48	56	64
	Size of p	2 029	2 436	2 844	3 251

TABLE III :

 III Estimation of p bit size for n multiple of 8, for RNS SIMD implementations, with 52-bit moduli.

  .

	Size of p	401	807	1 214	1 621
	n	7	13	20	26
	Size of p	2 029	2 436	2 844	3 251
	n	33	39	46	52

TABLE IV

 IV

: Estimation of n optimal values for RNS, with 64-bit moduli.

  presents these estimations based on Equation 3.

			φ = 2 64
	Size of p	401	807	1 214	1 621
	n	9	18	27	37
	Size of p	2 029	2 436	2 844	3 251
	n	47	57	67	77
			φ = 2 52
	Size of p	401	807	1 214	1 621
	n	12	24	38	52
	Size of p	2 029	2 436	2 844	3 251
	n	66	81	96	112

TABLE V :

 V Estimation of n optimal values for PMNS, δ = 5, for φ = 2 64 and. φ = 2 52

https://github.com/arithPMNS/low_memory_efficient_PMNS

https://github.com/rns-pmns-arith/C-code-generators


Antonio Bucchiarone

Federico Ciccozzi

Leen Lambers

Alfonso Pierantonio

Matthias Tichy

Massimo Tisi

Andreas Wortmann

Vadim Zaytsev

What is the Future of Modelling?

Keywords: Software Modelling, Success Stories, Research Roadmap

Modelling languages and frameworks have been the key technology for advancing Model-Driven Engineering (MDE) methods and tools. Many industrial and research tools have been realised and are used across many domains. Hence, we think it is the right time to define what should be the future of modelling technologies, especially the requirements for the next generation of modelling frameworks and languages.

In January 2020, the Second Winter Modelling Meeting (WMM2020) was held in San Vigilio di Marebbe (Italy), focusing on the analysis of the state of research, state of practice, and state of the art in MDE. The event brought together experts from industry, academia, and the open-source community to assess (i) what had changed in research on modelling in the last ten years, (ii) which problems are still unsolved, and (iii) which new challenges have arisen.

This article presents a set of success stories and driving success factors of modelling and MDE, as well as a set of challenges and corresponding research directions that emerged from the synthesis of the results of our analysis.

I. INTRODUCTION

The use of models in computer science can be traced back to the earliest efforts in the field. The sequences of designs by Charles Babbage on his "Analytical Machine" [START_REF] Baltes | Sketches and diagrams in practice[END_REF] were the first models of a Turingcomplete mechanical device. Since then, many different modelling languages have been designed in software engineering and strongly shaped the discipline of Model-Driven Engineering (MDE) [START_REF] Bucchiarone | Grand challenges in model-driven engineering: an analysis of the state of the research[END_REF] .

The role of models in improving productivity in software engineering is a recurring theme. During Antonio Bucchiarone is with the Fondazione Bruno Kessler, Italy Federico Ciccozzi is with Mälardalen University, Sweden Leen Lambers is with the HPI, University of Potsdam, Germany Alfonso Pierantonio is with Università degli Studi dell'Aquila, Italy Matthias Tichy is with Ulm University, Germany Massimo Tisi is with the Institut Mines-Telecom Atlantique, France Andreas Wortmann is with the RWTH Aachen, Germany Vadim Zaytsev is with the University of Twente, The Netherlands 1 https://en.wikipedia.org/wiki/Analytical Engine 2 See also https://modeling-languages.com the "Peak of Inflated Expectations" in the hype cycle [START_REF] Burgueño | Contents for a model-based software engineering body of knowledge[END_REF] at the beginning of the 2000s, concepts like Model Driven Architecture (MDA), Model-Driven Software Engineering (MDSE), as well as the promotion of the Unified Modelling Language (UML) as the panacea for all possible problems in software engineering, have substantially influenced the MDE discipline.

Since then, software modelling has arrived at the "Plateau of Productivity," and the modelling community learned when and how to use its founding principles for improving the productivity of software engineering [8].

The aim of this report is (1) to present three success stories where modelling has been applied in various ways for different target groups to achieve other goals, and (2) to formulate a set of areas and corresponding research directions.

II. MODELLING SUCCESS STORIES

In the following sections, we review successful shapes of modelling: model-based systems engineering, low-code software development, and informal software modelling. Each of the three sections concludes with a summary of the success factors relevant for that modelling shapes illustrated in Figure 1.

A. Model-Based Systems Engineering

For the systematic and reliable engineering of (cyber-physical) systems, modelling, as a technique to describe or prescribe the system's properties under development, is the essential foundation. Consequently, engineers from various domains have been modelling for ages. For instance, electrical engineers use mathematical formulae to describe a system's processes, and mechanical engineers use technical drawings to prescribe constructions. The automated analysis and synthesis of system models and their parts have become possible thanks to modeling notations that helped define and establish practices in application areas (e.g., automotive, railway, aerospace).

Via model-based analyses, simulations, and syntheses across system parts provided by experts of different domains, challenges and mistakes too costly to address in real systems can be uncovered early. For example cases like extreme situations (cf. Boeing 737 MAX) or incompatible assumptions of system parts (cf. Ariane 5), if proactively discovered, can significantly reduce failures in the resulting systems.

Research and industry have produced various modelling techniques for the engineering of software for embedded and cyber-physical systems. Those techniques address different phases in the engineering process. Large systems engineering companies in avionics successfully apply architecture modelling languages to decompose system components' structure and behaviour and facilitate development, analysis, and integration of subcomponents across multiple departments. Particularly, the modelling and analysis of extra-functional requirements like dependability and timeliness have been a success in that area.

To describe continuously varying behaviour, corresponding modelling languages have been broadly and successfully adopted. In many engineering departments, MatLab's Simulink4 has become one of the prime modelling tools. Modelling languages enable both the automated analysis of correctness and other properties and automatic generation of code that is widely used in today's products like Eclipse, MetaEdit+, and Modelica.

The standardisation of modelling languages by ANSI/ISA, NIST, or ISO has built the foundation for multi-stakeholder, cross-company modelling required to successfully engineer cyber-physical systems. Popular standards that employ modelling techniques, define modelling languages, such as function block diagrams (IEC 61131-3 [START_REF] Cabot | Cognifying model-driven software engineering[END_REF] ), IDEF0 manufacturing functions (NIST FIPS 183 [START_REF] Dyck | A framework for model recommenders requirements, architecture and tool support[END_REF] ), or the EXPRESS data modelling language (ISO 10303 [START_REF] France | Model-driven Development of Complex Software: A Research Roadmap[END_REF] ). These standards allow companies and stakeholders to rely on the same explicit models to ensure the systems' compatibility under development. Moreover, they enable tool builders to rely on stable shared foundations. Overall, standards are vital to the success of modelling in industrial practice.

The success of modelling for cyber-physical systems is due to the levels of precision of the modelling languages, standardisation, and the im-portance of frontloading in systems engineering: successful languages, such as AADL [START_REF] Liebel | Model-based engineering in the embedded systems domain: an industrial survey on the state-of-practice[END_REF] or Simulink, are tailored to broad domains without being overly specific.

Moreover, this broad use of such sufficiently precise modelling languages fosters communication, understanding, and development across experts from different departments, companies, and domains. Another reason for the success of explicit modelling in engineering is that modelling languages-and, by extension, the tools featuring them-are either supported by large industrial consortia or standardised. The broad commitment to specific technologies, languages, and standards enables companies to rely on their availability and stability in the future, which encourages further commitments to their use, development, and extension. However, this generality introduces a challenging conceptual gap [7] between the experts' domains, with their concepts and methods, and the solution domain of software engineering, along with its own concepts and methods; this gap needs to be addressed in the next generation modelling tools. The idea of bridging these two worlds with automated means is intriguing and has engaged the community, but it has not always worked. Successful applications in these areas focus on the domains' specifics and provide well-integrated platforms with clear technical benefits for the developers.

Heavyweight modelling, profoundly relying on rigorous specification and state of the art engineering practices, as employed in cyber-physical systems, works well if models are continually used throughout the development process. Ideally, models provide the single source of truth; tools are used to analyse the models, performing timing analysis, correctness, control stability of feedback controllers, easy deployment, code generation, or interpretation of the model.

In Model-Based Systems Engineering, modelling is successful if standardised or established modeling techniques and languages lead to cost-and time-savings for domain experts and system integrators. This is often achieved by enabling analysis and synthesis of system parts at design time, long before the real system or its components are manufactured, in order to These benefits are also shown in the highly positive results of empirical studies on the effect of modelling in the embedded systems domain, where modelling affects very positively the productivity of engineers and the quality of the products [8].

B. Low-Code Software Development

Recently, low-code development platforms have been considered promising for democratising digital processes in organisations [4]. Notably, earlier attempts to simplify software development, e.g., fourth-generation languages (4GLs), were not exempt from problems. Nowadays, end-user programming, mashups, or situational programming leverage abstraction and automation by making full use of recent advances in domain-specific modeling, visual editing, and user experience. Spreadsheet applications' overwhelming success inspired low-code platforms with their ease of use and substantial computational power. The major market analysis firms have highlighted the current impressive investments by vendors and customers in low-code platforms for business applications, and foreseen a positive trend for the next years. Besides the current commercial success in business application development, other domains are considered reasonable grounds for these solutions, like knowledge management and digital transformation in manufacturing.

Several web giants have recently started providing their own low-code development platform (Microsoft PowerApps [START_REF] Madni | Model-based systems engineering: Motivation, current status, and research opportunities[END_REF] , Google App Maker10 , Amazon Honeycode [START_REF] Rios | MDD maturity model: A roadmap for introducing model-driven development[END_REF] ). Some medium-sized vendors were recently protagonists of impressive acquisitions (e.g., $360 million by KKR and Goldman Sachs for OutSystems [START_REF] Störrle | How are conceptual models used in industrial software development?: A descriptive survey[END_REF] , and $730 million by Siemens for Mendix [START_REF] Tisi | Lowcomote: Training the Next Generation of Experts in Scalable Low-Code Engineering Platforms[END_REF] ). Other popular low-code platform providers include AppSheet 14 , Caspio 15 , FileMaker 16 , Kony 17 , Parabola 18 , QuickBase 19 and Salesforce 20 .

The prominent success of low-code platforms in business applications is tied to the present-day software production landscape. Despite aggressive recruitment efforts and innovative working conditions, the IT industry's development capability is at capacity. Low-code development platforms enable the inclusion of non-professional developers into the application production process, letting IT experts to focus on the more knowledge-intensive tasks.

Typically, low-code platforms are inspired by different modeling paradigms and tailored to the most diverse domains. Therefore, it is not trivial to provide a unifying and informative characterisation of the features they offer and for which types of applications. Nevertheless, they can be distinguished by the following factors: (1) advanced user-interfaces that help the user develop his/her proficiency with the tool in a learning-by-doing manner quickly; (2) Platform-as-a-Service architecture to mitigate the accidental complexity of managing (e.g., installing and upgrading versioned components) the modelling environment, deploying the application, and monitor its execution. Finally, (3) machine-learning techniques to ease the user's development process by providing him with automatic assistance tools, such as a recommendation system. Modelling languages and model-driven techniques are used within lowcode platforms either explicitly or implicitly (e.g., hidden behind visual editors or forms).

Low-code development platforms' technical merits do not fully explain their significant commercial success thoroughly. While their interoperability, openness, and scalability are still subject to further investigations [13], their accessibility, user focus, strategies for hiding accidental complexity, and a convenient learning curve can spur innovation leading to better model-driven platforms.

In Low-Code Software Development, modelling is successful if it enables software engineering with a minimal upfront investment in setup (e.g., by native integration with an existing development platform), training (e.g., by advanced user interfaces, self-explaining and AI-assisted IDEs), and deployment (e.g., as Platform-as-a-Service), and with costs rising in proportion to the business value of the developed applications.

C. Informal Modelling

The above two scenarios show the application and value of modelling in two specific and different application areas. Additionally, modelling is also extensively used in generic software engineering albeit with different intentions than the applications above.

Störrle conducted a survey [12] to identify how and with which frequency modelling is used in the software engineering industry. The results show that over 70% of all survey participants used models often or always for communicative and cognitive processes, which were the most popular usage areas; code generation was never or rarely used by half of the survey's population. Additionally, models were used more in the early phases of the development, e.g., for domain-and requirements-oriented discussions. This means that models were used more as a "thought tool" and to facilitate discussions among stakeholders with diverse backgrounds. According to the survey results, software architects were the stakeholders benefiting the most from modelling, with 91% of the respondents rating the benefits for software architects as "a lot" or "crucial".

Another empirical study by Baltes and Diehl [1] showed that informal modelling such as sketching is frequent in software engineering. 77% of the study participants created and/or used model sketches in the previous week, and 68% of the sketches were rated as informal. In line with the findings of Störrle, Baltes and Diehl reported that design, explaining or understanding were the most common purposes of the sketches. Similarly, sketches were often used to analyse requirements. Sketches are not only used as informal and temporary means for communication and discussion; whiteboard sketches are sometimes subsequently detailed on paper, later more formally modelled in a tool and sometimes converted to text too. Interestingly, also generic drawing tools like yEd21 , miro 22 or Visio are reported to be used for modelling. Finally, the study reported that about half the sketches were rated as helpful to understand the related source code artefact(s) in the future.

An example of informal modelling via collaborative sketching on an interactive whiteboard is brought by OctoUML 23 , which supports the creation of UML models at various levels of formality (or precision), collaborative and multi-modal interaction. OctoUML is a prototype of a new generation design environment that enhances informal collaboration when architecting a product. Similar approaches are beneficial in other settings, such as teaching and training.

In contrast to formal and, more generally, less flexible modelling, informal modelling (e.g., by sketching on a whiteboard) is particularly useful for communication, collaboration, and understanding. Here, cheap solutions like whiteboard or drawing tools are enough to reap significant benefits and make the design phase faster and more effective without high investments. Moreover, being more flexible and less chained to specific formalisms and constraints, informal modelling pushes down the learning/training curve of beginners and supports the needs of a wider variety of stakeholders. Industrial experience using modelling tools shows a noteworthy division between stakeholders preferring different types of modelling notations; we believe that informal and thereby flexible modelling is the only viable way to broaden acceptance of modelling tools by industrial stakeholders.

..

In Informal Modelling, modelling is successful if a wide variety of stakeholders can employ it for communicative and cognitive processes in early development phases using emergent and flexible graphical notations while postponing any structural limitations on the sketched models as long as possible.

III. CHALLENGES AND OPPORTUNITIES

There have been many empirical studies carried out in modelling-rich domains about standing issues, apparent trends, and future challenges: objectoriented modelling, business process modelling, model-data management, self-adaptive systems, and specifically in MDSE [2]. Many mention the same issues, but in different contexts: demonstration of added value to potential users/customers, integration 23 https://github.com/Imarcus/OctoUML of produced artefacts, learnability, reliability, etc. In the following, we highlight the most important new issues that have changed significantly over the last few years, as discussed during WMM2020.

A. Artificial Intelligence

Admittedly, it was impossible to overlook the recent advances in Artificial Intelligence (AI), which are now dramatically changing how we design, engineer, and maintain software. Many believe that this will cause a massive shift in a skill set that software developers are expected to carry. MDE techniques are also being enhanced with AI extensions for automation and bringing quantifiable advantages [5]. The main reason is that many MDE techniques are already based on the intensive use of knowledge and data. Even success factors of other areas of AI like TensorFlow24 and its internal DSL, are similar to those of software modelling. In the future, we will only see more applications like modelling bots that assist modellers by identifying potential issues and giving advice [5] or model recommenders integrated into IDEs [6]. For example, the new version of Matlab Simulink includes reusing components by creating library blocks from subsystem clones and replacing clones with library links.

B. Multi-Paradigm Modelling

When engineering cyber-physical systems, experts from different domains collaborate to contribute solutions to various aspects of the systems under development. To engineer these solutions, experts employ different paradigms (discrete vs. continuous, geometric vs. functional, ...), reified in modeling languages, tool, and processes, that need to be integrated to describe the systems under development. One of the solutions to this integration is known as Multi-Paradigm Modelling (MPM) [10], which envisions to "model everything", i.e., each aspect of the system and each corresponding process is specified using models at the appropriate level of abstraction, while model transformations propagate information. By modeling everything, the paradigms (models plus related processes) provided by different domain experts are made explicit and can be integrated, analyzed, and synthesized automatically. This ultimately enables to support cross-disciplinary communication and collaboration.

Informal Modeling

Communication & collaboration "over 70% of all survey participants used models often or always for communicative and cognitive processes" "models were used more as a "thought tool" and to facilitate discussions among stakeholders with diverse backgrounds" [12] C. Adoption Model for Modelling

As outlined in Section II, different types of modelling can be successful for various reasons, in different domains, and with different characteristics. Another challenge that we therefore identified is how to support organisations on their ways towards applying modelling successfully. In other words, how can an organisation assess, evaluate, and improve its modelling activities?

An initial idea for coming up with a concrete solution to this overall challenge is elaborating an adoption model for modelling. This idea is closely related to the development of a maturity model for model-driven development initiated by Rios et al. [11].

The overall goal of the adoption model will be to provide guidelines for discovering the right level of adoption of modelling within (different parts of) an organisation as well as to support the transitioning from one level to the next when needed.

Implementing such guidelines goes along with appropriate training and education. Teaching modelling is commonplace and almost any degree program offers courses at different levels that range from foundational aspects to laboratory practice. Recently, the state-of-the-practice of modelling and MDE has been characterized in [3], where a precise picture of the covered topics and their relevance is presented. In particular, it emerges that modelling can be considered a trait d'union between software and language engineering: on the one hand, models can be used at any stage of the development process for documenting, analyzing, designing, deploying and simulating systems; on the other hand, metamodelling techniques can be used for designing notations and the associated modelling environment. Consequently, this distinction makes place for a diversity of courses at both bachelor and master level covering the most relevant aspects of model-based software engineering and model-driven engineering.

D. Model Management

Current modelling tools are sophisticated tools that provide features to simplify and automate development activities. However, the sheer complexity of modern software systems often requires designers to deal with heterogeneous collections of related models. Their continuous management, deployment, and integration are crucial at different development stages and can take the form of reusing artifacts, analysing their characteristics, managing consistency or leveraging the underlying informative contents. Several model repositories have been proposed over the last decade. A daunting challenge is represented by the enhancement of these platforms from merely cloud storage to (possibly collaborative) modelling environments where the designer can smoothly maintain collections of artifacts consistent, efficiently cluster, quickly locate and reuse them, and compose different transformations. More recently, several initiatives, including Visual Studio Code25 , Eclipse Che26 , Theia27 and others, hold great promise to shift modelling environments from monolithic installations to cloud-based platforms to reduce the accidental complexity and extend the set of offered features. In a way, this represents a refreshing scenario where commercial competitors will also contribute to the field's advance. As a consequence, it seems that state-of-the-art suggests that versioning tools will soon be part of the modeling environment alongside collaborative modeling possibilities.

IV. CONCLUSION Figure 1 provides a visual summary of this paper. It captures what we discussed at a single glance: how modelling is being increasingly adopted across the diverse areas of software and system engineering, and beyond. Besides fields where models are traditional instruments, like embedded and cyber-physical systems domains, new areas of applications emerged, including the so-called lowcode development platforms where even people with considerably less programming experience can develop software applications within organizations. Empirical studies showed that modelling positively affects both engineers' productivity and the products' resulting quality, also thanks to consortia and standardisation bodies.

The urge for improved platforms and foundations is stringent because of the pervasive adoption of models and related environments. The paper presented some of the most daunting challenges to move towards a community roadmap. Such a roadmap aims to provide a motivated collection of challenges, addressing which can be used to improve modelling technology and leverage adjacent research and development fields.

ACKNOWLEDGMENT

The authors that compiled this document would like to thank all participants of the Second Winter Modelling Meeting28 , especially those that actively contributed to discussing these issues and describing them.

Fig. 1 .

 1 Fig. 1. Modelling Success Stories and Challenges.

https://en.wikipedia.org/wiki/Hype cycle

https://www.mathworks.com/products/simulink.html

https://plcopen.org/status-iec-61131-3-standard

https://csrc.nist.gov/publications/fips

https://www.iso.org/standard/38047.html

http://www.aadl.info avoid failures, rather than to detect reasons for them.

https://powerapps.microsoft.com

https://developers.google.com/appmaker

https://www.honeycode.aws

https://www.outsystems.com

https://www.mendix.com

https://www.appsheet.com

https://www.caspio.com

https://www.filemaker.com

https://www.kony.com

https://parabola.io

https://www.quickbase.com

https://www.force.com

https://www.yworks.com/products/yed

https://miro.com

https://www.tensorflow.org

https://code.visualstudio.com

https://www.eclipse.org/che/

https://theia-ide.org

http://eventmall.info/WMM2020/


Davide Di Ruscio

Dimitris Kolovos
email: dimitris.kolovos@york.ac.uk

Juan De Lara
email: juan.delara@uam.es

Alfonso Pierantonio

Massimo Tisi
email: massimo.tisi@imt-atlantique.fr

Manuel Wimmer
email: manuel.wimmer@jku.at

Low-code development and Model-driven engineering: Two sides of the same coin?

Keywords: Low-code development, No-code development, Model-driven engineering

The last few years have witnessed a significant growth of so-called low-code development platforms (LCDPs) both in gaining traction on the market and attracting interest from academia. LCDPs are advertised as visual development platforms, typically running on the cloud, reducing the need for manual coding and targeting also non-professional programmers. Since LCDPs share many of the goals and features of model-driven engineering approaches, it is a common point of debate whether low-code is just a new buzzword for model-driven technologies, or whether the two terms refer to genuinely distinct approaches. To contribute to this discussion, in this expert-voice paper, we compare and contrast low-code and model-driven approaches, identifying their differences and commonalities, analysing their strong and weak points, and proposing directions for cross-pollination.

Introduction

Low-code development platforms (LCDPs) are on the rise, with an increasing number of cloud vendors, such as Google, Microsoft, and Amazon, offering solutions for developing and operating complex software applications with little or no code. The main aims of LCDPs are to reduce the development and maintenance effort required to deliver and operate certain types of applications and to enable digital-savvy citizen developers who lack or have limited programming experience to contribute to the software development process directly.

As model-driven engineering (MDE) [START_REF] Brambilla | Model-Driven Software Engineering in Practice[END_REF] has similar aims, there is an ongoing debate on how low-code software development is different from model-driven engineering and to what extent work carried out in the field of MDE is directly transferable to LCDPs [START_REF] Cabot | Positioning of the low-code movement within the field of model-driven engineering[END_REF]. In this paper, we aim at clarifying the commonalities and differences between both approaches. We argue that while the two approaches share similar high-level aspirations, for instance, not all model-driven techniques aim at reducing the amount of code needed to implement software solutions, and not all low-code approaches are model-driven.

The rest of the paper is organised as follows. In Section 2, we summarise the history of the low-code movement we have seen so far. In Section 3, we provide an overview of typical low-code development processes and tools that LCDPs offer. In Section 4, we contrast and compare the principles and practices of low-code development and MDE. In Section 5, we discuss possible reasons behind the increasing adoption of LCDPs. In Section 6, we identify lessons that the two communities can learn from each other. Finally, Section 7 summarises and concludes the paper.

The history of low-code development

The past decades have been marked by several industry trends aiming at reducing the amount of handcrafted code required to produce software such as 4GLs in the 80's [START_REF] Martin | Application Development without Programmers[END_REF], Rapid Application Development in the 90's [START_REF] Martin | Rapid Application Development[END_REF], End-User Development in the 00's [START_REF] Lieberman | End-User Development: An Emerging Paradigm[END_REF], and MDE in the last two decades [START_REF] Schmidt | Guest editor's introduction: Model-driven engineering[END_REF].

The first use of the term low-code can be traced back to the market analysis firm Forrester in 2014 [START_REF] Richardson | New development platforms emerge for customer-facing applications[END_REF] (cf. Fig. 1), where low-code development platforms (LCDPs) were defined as "platforms that enable rapid delivery of business applications with a minimum of hand-coding and minimal upfront investment in setup, training, and deployment." It is interesting to note that this report identified the LCDP segment as specific to the production of business applications, such as software for accounting, customer relationship management, human resource management, outsourcing relationship management, field service, enterprise resource planning, enterprise content management, business process management, product lifecycle management, and other productivity-enhancing applications. In 2016, Forrester detailed the successful application domains for LCDPs in four specific application scenarios, i.e., database, request-handling, process, and mobile-first [START_REF] Rymer | The Forrester Wave: Low-Code Development Platforms, Q2[END_REF].

The definition has evolved, and in 2017, Forrester provided a more detailed version, characterizing LCDPs as "products and/or cloud services for application development that employ visual, declarative techniques instead of programming and are available to customers at low-or no-cost in money and training time to begin, with costs rising in proportion of the business value of the platforms" [START_REF] Rymer | The Forrester Wave: Low-Code Development Platforms For AD&D Pros, Q4[END_REF]. The focus here is on visual interfaces and declarative techniques, with Forrester especially emphasizing visual WYSIWYG development and model-driven development [START_REF] Hammond | The Forrester Wave: Mobile Low-Code Development Platforms, Q1[END_REF]. The focus on the platform is highlighted as a key differentiating aspect of these solutions with respect to the previous generation of declarative tools: LCDPs are platforms first, with features for application deployment and life-cycle management, as well as platform management [START_REF] Rymer | Vendor Landscape: The Fractured, Fertile Terrain Of Low-Code Application Platforms[END_REF].

Gartner identified a similar segment from 2016, called low-code application platform (LCAP) [START_REF] Vincent | Magic Quadrant for Enterprise Low-Code Application Platforms[END_REF]. In particular, it introduced enterprise LCAPs, which aim at producing enterprise-class applications requiring high performance, scalability, high availability, disaster recovery, security, SLAs, resource use tracking, technical support from the provider, and API access to and from local and cloud services.

The year 2017 noted the start of a series of acquisitions for LCDP vendors as reported in [START_REF] Rymer | Siemens Snaps Up Mendix; Low-Code Platforms Enter New Phase[END_REF]. Appian In July 2018, OutSystems received investments of $360 million and was rated with $100 million in annual revenue. In August 2018, Siemens announced the acquisition of Mendix for $730 million in cash or at least 7-8 times its annual revenue [START_REF] Rymer | Siemens Snaps Up Mendix; Low-Code Platforms Enter New Phase[END_REF].

In 2017, Forrester estimated a market size for LCDPs of $3.8 billion 2 . Forrester also periodically surveys developers about LCDP usage1 : In 2018, 23% of developers reported using low-code platforms, and another 22% planned to do so within a year [START_REF] Rymer | The Forrester Wave: Low-Code Development Platforms For AD&D Professionals, Q1[END_REF]. In 2019, 37% of developers were using or planning to use lowcode products [START_REF] Mines | Predictions 2020: More Changes For Software Development[END_REF].

In 2021, most large cloud providers offer LCDPs within their cloud-based solutions. Microsoft was among the first to embrace the trend by releasing its Power Apps LCDP in November 2016. In January 2020 Google acquired the LCDP provider AppSheet, and made it its flagship low-code solution. In June 2020 Amazon released Honeycode, an LCDP for web and mobile application development.

No-Code Development Platform (NCDP) is a related term used for platforms that eliminate the need for programming using visual languages, graphical user interfaces, and configuration. While the term is widely used in marketing, market analysis firms currently oppose using it to identify a clear market segment [START_REF] Rymer | Now Tech: Rapid App Delivery, Q1[END_REF]. For the context of this paper, we consider NCDP and LCDP interchangeably, and consequently, hereafter, we use the term LCDP only.

Overview of low-code development platforms

In this section, we present an overview of the most significant LCDPs by considering the typical steps that Fig. 2 Top-level features of LCDPs (refinement of [START_REF] Sahay | Supporting the understanding and comparison of low-code development platforms[END_REF]) are performed when using them and by relying on a refined taxonomy originally presented in [START_REF] Sahay | Supporting the understanding and comparison of low-code development platforms[END_REF].

LCDPs support the development of applications that can be web-only or also native for the target deployment environments. Thus, they can natively support both desktop and mobile devices, and integrate with existing workflows developed with popular Software-as-a-Service (SaaS) applications, including Zapier, Amazon AppFlow, and Trello to mention just a few. Appian [2] is among the most long-lived LCDP, whereas Amazon Honeycode [1] and Google AppSheet [START_REF]Google AppSheet[END_REF] are among the most recent approaches.

Particular characteristics that distinguish existing LCDPs pertain to the user experience of advanced Graphical user interfaces (see Fig. 2) providing tools and widgets to enable citizen developers to conceive the desired applications. Drag-and-drop facilities, advanced reporting features, decision engines for modelling complex logic, and form builders are just examples of functionalities provided in the front-end of LCDPs. Moreover, LCDPs can give the users some Live collaborative development support to help developers that are geographically distributed and that want to work on the same applications collaboratively. Another distinguishing aspect of existing LCDPs is related to the Supported application domain intended to be the primary focus of interest. For instance, the main focus of Node-RED [START_REF]Node-RED[END_REF] is supporting the development of IoT applications. Other platforms support the development of chatbots [START_REF] Pérez-Soler | Choosing a chatbot development tool[END_REF], whereas the majority of existing LCDPs aim at being general-purpose supporting the development of any data-intensive application.

LCDPs can provide users with pre-defined artifacts, which can be used as starting points. This is reflected by the Reusability support feature shown in Fig. 2. For instance, Salesforce App Cloud [START_REF]Salesforce[END_REF] includes the extensive AppExchange marketplace [START_REF]Salesforce (AppExchange marketplace[END_REF] consisting of pre-built applications and components, reusable objects Fig. 3 A simple domain model specified in Mendix [START_REF] Sahay | Supporting the understanding and comparison of low-code development platforms[END_REF] and elements, drag-and-drop process builder, and inbuilt Kanban boards.

As discussed in [START_REF] Sahay | Supporting the understanding and comparison of low-code development platforms[END_REF], realizing software systems with LCDPs encompasses several tool-supported steps, which are summarised below. Domain modeling. In this phase, users are provided with modeling constructs to represent concepts and relationships underpinning the application being developed. Fig. 3 shows a simple domain model specified with the Mendix platform to describe training courses. Pre-built templates can be exploited as starting point, and interactive application analytics are provided out of the box. Other tools follow a similar approach. For example, Codebots [START_REF]Codebots[END_REF] uses UML to specify domain models that are consumed to automatically generate target artifacts, including complete REST APIs, client libraries, Swagger API documentation, and a JSON Schema definition for each domain object.

User interface definition. Users define data forms and pages to create, edit, and visualize data that the application under development will manage. Fig. 4 shows a form-based screen in Microsoft Power Apps.

Business logic specification. Users define the control and data flows of the system under development through intuitive Business logic specification mechanisms. Graphical workflows and textual business rules are examples of business logic specifications that typically make use of one or more API call(s). Fig. 5 shows a simple Node-RED workflow. Node-RED implements a programming model that permits developing event-based applications, which can be specified by a wide range of node types available in an extensible palette. Workflow specification is also prominent in Kissflow [START_REF] Kissflow | [END_REF], which mainly focuses on workflow automation for small businesses.

Integration with external services. LCDPs typically provide Interoperability support with external services and data sources to use Fig. 5 Business logic specification with Node-RED [START_REF]Node-RED[END_REF] services or consume data provided by third-party systems, e.g., using dedicated APIs. LCDPs can consume services provided by external providers such as Dropbox, Zapier, Office 365, and Google Drive. Thus, users might connect or integrate such services to build forms or to compile data reports. For instance, Fig. 6 shows the page in Zoho Creator [START_REF]Zoho Creator[END_REF] to configure the connection with Google Drive. Application generation and deployment. The next step of the process consists of generating and deploying the modeled application by means of provided Application build mechanisms. Several execution environments can be supported, as for instance, in the case of zAppDev [START_REF] Zappdev | [END_REF], which provides users with different code generation facilities. Once the desired system has been specified and built, a dedicated Deployment support is available to deploy the system in private or public environments. Deployments are typically done on cloud infrastructures with a few clicks, as shown in Fig. 7. In particular, OutSystem [START_REF]Outsystems[END_REF] provides developers with quick mechanisms to publish developed applications, connect different services, and create real-time dashboards.

Application maintenance. The last step of the process is monitoring and maintaining the developed system by means of dedicated features, e.g., to react in case of unforeseen requirements that need to be addressed or fix issues that might occur during the operation of the system.

Low-code vs. Model-driven Engineering

Having discussed the main features of LCDPs, we compare them with MDE processes and technologies in this section. MDE [START_REF] Brambilla | Model-Driven Software Engineering in Practice[END_REF] encompasses software paradigms emphasizing the use of models as first-class artefacts during the development lifecycle. Hence, in MDE, models are used to specify, test, simulate, verify, modernize, maintain, understand, and generate code for the system, among many other activities. Still, not every MDE process ends with code generation but actively uses models. The goal of MDE is to increase productivity by automating different steps in software development employing models while augmenting the overall quality [START_REF] Hutchinson | Modeldriven engineering practices in industry: Social, organizational and managerial factors that lead to success or failure[END_REF][START_REF] Kelly | Domain-Specific Modeling -Enabling Full Code Generation[END_REF]. For this purpose, MDE processes often rely on Domain-Specific Languages (DSLs), specially tailored for the domain at hand. Using domain-specific models makes descriptions more intentional and include less accidental detail than code written using generalpurpose programming languages. Hence, those models become easier to create, verify, and maintain than the corresponding low-level code.

In their turn, LCDPs promote the construction of applications using forms and graphical editors with little or no hand-crafted code. Since some of their target users are citizen developers, one of their key points is to reduce accidental complexity regarding the installation and operation of both the development environments and the developed applications. This way, they typically provide cloud-based development environments and manage the lifecycle of the designed applications (e.g., hosting, resource allocation and provisioning, usage analytics, etc.) Therefore, low-code development shares some of the goals of MDE, but there are some differences, too. Fig. 8 schematically illustrates the commonalities and differences between low-code and MDE approaches using a Venn diagram. The diagram represents the approaches following MDE, low-code development, and development based on low-code platforms in terms of sets. This leads to 5 regions of interest (marked as 1-5 in the figure). This way approaches termed "modeldriven" by our community fall under regions 1, 2, and 3; with an overlap under 2 and 3 with low-code platforms and low-code development approaches. Instead, regions 4 and 5 are exclusively low-code, while region 1 is exclusively model-driven. The regions can be described as follows:

1. This region contains the model-driven approaches that use models as machine-processable artefacts but do not aim at reducing the amount of code required to implement the system. Instead, they focus on automating tasks like simulation, formal verification, software optimization, or reverse engineering.

Examples of works in this category include the work of Cortellessa et al. [START_REF] Cortellessa | From software architecture to analysis models and back: Model-driven refactoring aimed at availability improvement[END_REF] on analysing and refactoring UML design models for optimizing their perfor-mance; or reverse engineering tools like Modisco [START_REF] Brunelière | Modisco: A model driven reverse engineering framework[END_REF], which extracts models from code. 2. These are the approaches that use models as machine-processable artefacts and aim to reduce the amount of code required to implement a system (e.g., via code generation or interpretation) but without offering deployment or lifecycle management capabilities for the produced system. Examples of this class of approaches are JHipster [20] and its JDL [START_REF]JHipster's JDL DSL[END_REF] domain-specific language, Google Protocol Buffers [START_REF]Google's protocol buffers[END_REF], or the OlivaNova model execution system [START_REF] Pastor | The OO-method approach for information systems modeling: from object-oriented conceptual modeling to automated programming[END_REF]. 3. This region contains the platforms that use models to facilitate the development of software applications with reduced code and offer built-in deployment and lifecycle management facilities for the produced application. Examples include the Codebots [START_REF]Codebots[END_REF] and Judo [22] low-code platforms, both of which are based on technologies of the Eclipse Modelling ecosystem [START_REF] Steinberg | EMF: Eclipse Modeling Framework[END_REF]. 4. This region, and the next one, contain approaches that cannot be considered model-driven. In particular, region 4 contains the platforms that facilitate the development of software applications with reduced code. Such approaches offer built-in deployment and lifecycle management facilities for the produced application. However, they do not use models that conform to explicitly defined languages/metamodels (e.g., they use data stored in a relational database or schema-less XML/JSON documents). 5. These approaches aim to reduce the amount of code required to implement a system without offering deployment or lifecycle management capabilities for the produced system, and -like region 4 -without using models that conform to explicitly defined languages/metamodels. Examples of this type of approach include database-schema-driven generators like Phreeze [41] and one-off generators such as those provided by Ruby on Rails [START_REF] Ruby | Agile Web Development with Rails 6. The Pragmatic Programmers[END_REF].

Next, we elaborate on other aspects that differentiate model-based and low-code approaches, based on Fig. 8:

Platform. Low-code application platforms (regions 3 and 4 in the figure) are cloud-based: they can be used from the web browser and host the defined applications. This frees the user from both installing the development platform itself and from deploying the defined applications. This approach simplifies the adoption of low-code by newcomers. While MDE solutions can be cloud-based (falling in region 3) [START_REF] Corley | Evaluating the Cloud Architecture of AToMPM[END_REF], this is not the norm today. Instead, many solutions are based on the desktop, for example, those using the Eclipse Modelling Framework (EMF) [START_REF] Steinberg | EMF: Eclipse Modeling Framework[END_REF], or meta-modelling tools like MetaEdit+ [START_REF]MetaEdit+ by Metacase[END_REF]. These approaches would fall under region 2 -and be considered low-code development approaches -if their aim is automating application development, otherwise they would fall in region 1.

Users. Low-code development platforms mainly target end-users, so-called citizen developers. Therefore low-code platforms tend to be easy to use for people with a non-technical background. This means that frequently (but not always), users of tools in regions 3 -4 are citizen developers and non-professional programmers. For example, while low-code platforms like OutSystems target citizen developers, others like Judo target teams of business analysts, software architects, and programmers.

In their turn, MDE solutions can target end-users, but many of them are directed to professional software developers since they are expected to be used within development processes. Therefore, typically, users of approaches in regions 1 and 2 have a more technical background.

Domains.

As mentioned in Section 2, the first wave of low-code targeted business applications. Recently, we are witnessing proposals for low-code tools in other domains, like IoT/event-driven applications (e.g., Node-RED [START_REF]Node-RED[END_REF]), chatbots (e.g., Google's Dialogflow [10], Amazon's Lex [START_REF][END_REF], IBM's Watson Assistant [START_REF] Watson | [END_REF]) or Machine Learning (e.g., Google's AutoML [14] or RapidMiner [START_REF]RapidMiner[END_REF]). MDE solutions (in regions 1-3 of the figure) can target those domains but frequently also target more technical areas, which require specialized engineers. These include domains like automotive [START_REF] Drave | SMArDT modeling for automotive software testing[END_REF], power engineering [START_REF] Gómez | Scalable modeling technologies in the wild: an experience report on wind turbines control applications development[END_REF], or cyber-physical systems [START_REF] Mohamed | Modeldriven engineering tools and languages for cyber-physical systems. a systematic literature review[END_REF] in general, among many others.

5 Low-code development: why now?

In terms of their core ambition to expedite the delivery of software systems, low-code development platforms are not very dissimilar to previously tried approaches like 4GLs, case tools, etc., as already mentioned in Section 2. Essentially, they provide an environment for specifying the structure and behavior of a software system at a high level of abstraction. Such an environment shields developers from low-level concerns (e.g., specific databases, object-relational mappers, service, messaging, and security middleware). They then generate executable code that realizes the specified software system. Given the broad consensus that previous approaches were not wildly successful, why should low-code envi-ronments fare any better? There are multiple reasons why this may be the case, which we analyse next.

Cloud-Based Deployment. Beyond generating code, modern low-code platforms can also deploy the produced software systems on scalable cloud-based infrastructures and make them instantly available to users globally through web-based interfaces. This can dramatically shorten the time and effort required to release applications (and updates) to users and increase the appeal for low-code platforms as a medium for rapid application development and delivery.

Digital Native Workforce. Computer literacy has improved dramatically over the last 40 years. The basics of computer programming are taught in many countries as part of compulsory education, and the new generations of domain experts (e.g., accountants, medicinal practitioners, construction engineers) are digital natives. As a consequence, while most domain experts would require substantial training to master some part of the complexity of a CASE tool released 40 years ago, a growing number of contemporary domain experts have substantial experience with working with computers and non-trivial software, and arguably require a lot less training to use a low-code platform to implement bespoke applications.

Zero Setup. The fact that many low-code platforms are cloud-based and do not require installation of bespoke software significantly lowers the entry barrier for new users, who can evaluate such platforms and even develop and deliver small-scale applications at no cost from the familiar environment of their web browser.

Developer Shortfall. As software is becoming pervasive in all aspects of human activity, the demand for software developers has outgrown the supply of suitably skilled professionals, and the gap is constantly widening [START_REF] Breaux | The 2021 software developer shortage is coming[END_REF]. Moreover, highly skilled software developers are attracted to intellectually demanding (and financially rewarding) software systems instead of runof-the-mill applications. This creates a growing gap for business applications that would be more effective than shared spreadsheets but are too expensive to implement and maintain manually.

Training Facilities. The media through which users learn have also changed considerably recently. A couple of decades ago, the primary learning media for application development environments were books written by technology experts. This landscape has changed dramatically with the growth of the web and, particularly, video sharing services such as YouTube, making it easier to deliver up-to-date training material aimed at different audiences. This enables citizen develop-ers to develop and share their own training material (e.g., walk-throughs, screencasts) rather than acting as passive consumers. Fostering ecosystems. Providing a LCDP is the first step, but then an ecosystem for this platform is required to ensure the continuous growth of a healthy user base. This may be even more important for LCDPs as professional developers as well as citizen developers may be targeted. Thus, the availability of documentation, support, consultancy, reusable components, etc., is of major importance. In MDE, such an ecosystem was triggered by Eclipse, i.e., a large and active ecosystem around the Eclipse Modeling Framework was established from the industrial and academic sides. It has to be further explored how such ecosystems will develop for LCDPs, as most current platforms are single vendor efforts. This issue also concerns the academic area, where scientific community efforts are required to stimulate research on topics related to low-code [START_REF] Tisi | Lowcomote: Training the next generation of experts in scalable low-code engineering platforms[END_REF]. For instance, a current example is the low-code workshop [START_REF]LowCode Workshop at MODELS[END_REF] hosted with the MOD-ELS conference since 2020, which provides a forum to discuss low-code development and MDE.

Managing software evolution. Notably, one of the most crucial stages of the software lifecycle is the maintenance of a software product after its release.

Providing support to such activities requires the ability to grow in functionality and size without unwanted side effects satisfying new requirements emerging from the routine usage of the product. Managing software evolution processes in LCDPs is an interesting line of research since these platforms are managed and allow cloud-based monitoring of the developed applications. Consequently, the platform provider should offer as much support for evolution as possible. However, this may involve many different aspects. Considering the application level, we may need support for model/data co-evolution, e.g., the data model is changing and there are already running instances of the application in usage. Evolution also applies on the language level, which has been extensively researched in MDE, and is often referred to metamodel/model co-evolution [START_REF] Hebig | Approaches to co-evolution of metamodels and models: A survey[END_REF]. Here, the problem applies both to low-code and MDE approaches. Low-code will only be successful if applications developed with low-code approaches can evolve for a longer time in combination with the LCDPs themselves.

Summary

This paper compared and positioned the relatively new low-code movement against the established modeldriven engineering discipline. We summarised the history of low-code so far, provided an overview of typical low-code development processes and the tools that LCDPs offer to support them, and contrasted and compared the principles and practices of low-code and model-driven engineering. While low-code and model-driven engineering both aspire to improve software development by raising abstraction and hiding implementation-level details, we argue that the two practices are not identical. Indeed, not all model-driven approaches aim at reducing the amount of code needed to implement software solutions, and not all low-code approaches are modeldriven. However, being close conceptually creates substantial potential for applying existing knowledge and cross-pollination between the two disciplines.

Fig. 1

 1 Fig. 1 Major events in low-code history

Fig. 4

 4 Fig.4User interface definition with Microsoft Power-Apps[START_REF]Microsoft Power Apps[END_REF]

Fig. 6

 6 Fig.6Configuring the Google Drive connector in Zoho Creator[START_REF]Zoho Creator[END_REF]

Fig. 7

 7 Fig. 7 Application deployment with OutSystem [38]

Fig. 8

 8 Fig. 8 Venn diagram showing commonalities and differences between model-driven approaches, low-code application platforms and low-code software development

The survey included more than 3 thousand developers in Australia, Canada, China, France, Germany, India, the UK, and the US. Developers participated with small material incentives.

Acknowledgements

This work has received funding from the Lowcomote project under European Union's Horizon 2020 research and innovation program under the Marie Sk lodowska-Curie grant agreement n. 813884.