You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: sections/technology.tex
+264Lines changed: 264 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -6,6 +6,15 @@ \section{Wombat}
6
6
\section{Python}
7
7
8
8
\section{C++}
9
+
\textbf{Author: Maximilian Dragosits}
10
+
11
+
C++ is a high-level precompiled programming language with support for low level memory management, object oriented programming, generic and functional programming.
12
+
It was designed and created by Danish computer scientist Bjarne Stroustrup with efficiency, performance and flexibility as its core goals.\footcite{lecture_essence_cpp}
13
+
Being based on C, and due to its highly sophisticated design C++ is being used in all kinds of places nowadays. From desktop applications, servers, video games and
14
+
even very performance critical use cases like digital equipment in space. The International Organization for Standardization (ISO) standardized this programming
15
+
language in 1998 as SO/IEC 14882:1998. Due to its popularity many libraries and frameworks for C++ have been made including Catch2\footcite{catch2_git} and
16
+
Doxygen\footcite{doxygen_main_site} both of which are being used in this project. We chose this coding language as one of the two frontend because of its speed and
17
+
efficiency as well as the sheer number of external frameworks and libraries already created for it, which are essential in the development of the RECT library.
9
18
10
19
\section{Rust}
11
20
\textbf{Author: Jeremy Sztavinovszki}
@@ -15,6 +24,147 @@ \section{Rust}
15
24
Right now there is now standardized async-runtime, so you normally use runtimes like tokio, async-std, or smol for programming asynchronously.
16
25
17
26
\section{gRPC}
27
+
\textbf{Author: Maximilian Dragosits}
28
+
29
+
gRPC\footcite{grpc_main_site} is an open source framework, that facilitates Remote Procedure Calls (RPC) across a multitude of environments. It has a wide variety of use cases in terms of
30
+
service to service connections and usage in the development of microservices and libraries. The framework is available in 11 different programming languages and
31
+
has a simple service definition and generation structure in order to streamline the process of integration. It also has pluggable authentication, load balancing, tracing
32
+
and health checking in order to control service communication. gRPCs ability to connect a client to backend services is particularly important for this project
33
+
and is therefore used to handle the communication from the individual Python and C++ frontends to the Rust backend and vice versa.
34
+
35
+
\section{Protocol Buffers}
36
+
\textbf{Author: Maximilian Dragosits}
37
+
38
+
Protocol Buffers are a platform neutral way to serialize structured data similar to XML, JSON or YAML. These data constructs can easily be used by automatically
39
+
generated source code in a multitude of different programming languages of the developers choosing. Including, but not limited to, Java, Kotlin, Python and various
40
+
C-based languages. An example of a Protocol Buffer file is this:
41
+
42
+
\begin{verbatim}
43
+
syntax = "proto3";
44
+
package msg;
45
+
46
+
47
+
message From {
48
+
string conn_name = 1;
49
+
string topic = 2;
50
+
}
51
+
52
+
53
+
message To {
54
+
string conn_name = 1;
55
+
string topic = 2;
56
+
}
57
+
58
+
59
+
message Msg {
60
+
bytes data = 1;
61
+
oneof fromto {
62
+
From f = 2;
63
+
To t = 3;
64
+
}
65
+
}
66
+
\end{verbatim}
67
+
68
+
The first part of any .proto file is the definition of the protobuf language version. Either \textit{proto2} or \textit{proto3}. Next the package within this will be
69
+
stored in when it is converted into a programming languages code is defined. In this case it will be \textit{msg}. After that you can import any other .proto file.
70
+
Then it is possible to define any amount of the following types and many others not used by this project:
71
+
\begin{enumerate}
72
+
\item\textbf{message:} Defines a special data structure that houses multiple variables of potentialy different data types, which can then be used in other enums or services.
73
+
\item\textbf{enum:} Defines an enum which acts like the equivalent type of structure in other programming languages. This can then be used in other parts of then .proto file.
74
+
\item\textbf{service:} Defines a Remot Procedure Call (RPC) system. The generated code for this will include service interfaces and stubs to be used by RPC frameworks.
75
+
\end{enumerate}
76
+
77
+
\subsection{Protofile message definition}
78
+
79
+
Message types in proto3 are relatively simple to define.
80
+
81
+
\begin{verbatim}
82
+
message message_name {
83
+
field_type field_name = number;
84
+
}
85
+
\end{verbatim}
86
+
87
+
First the \textit{message} keyword is used to signify that the following is a declaration for a message type. Then a freely choose able \textit{message\_name} is
88
+
used as the name for the later resulting message structure. After that any number of fields can be defined within the curly brackets. The \textit{field\_type} can be
89
+
one of multiple supported data types, which includes but is not limited to double, flout, integer, boolean, string as well as bytes. After defining an appropriate
90
+
\textit{field\_name} this format requires the assignment of a number between 1 and 536,870,911 to each field in a message. This is required in order to identify
91
+
the field after encoding.
92
+
93
+
There are also three other modifiers, that can be applied to fields:
94
+
95
+
\begin{enumerate}
96
+
\item\textbf{optional:} If a field with this modifier does not have its value explicitly set later it will instead return a default value. It also possible to check if this it has been set.
97
+
\item\textbf{repeated:} A field with this modifier can be repeated any number of times within the message and the order of the repetition will be saved.
98
+
\item\textbf{map:} A field with this modifier acts like a key/value pair with the definition syntax being like that of a C++ map.
99
+
\end{enumerate}
100
+
101
+
Another way of defining fields, that can have a multitude or a currently unkown type, is to use either the \textit{any} or the \textit{oneof} types.
102
+
The \textit{any} type is then later resolved by Protobufs internal reflection code.
103
+
\textit{Oneof} is then automatically later defined as one of the given data types within curly brackets placed after the \textit{field\_name} is given.
104
+
105
+
\subsection{Protofile enum definition}
106
+
107
+
Enums are share a lot of the same traits as message types in terms of the defintion syntax.
108
+
109
+
\begin{verbatim}
110
+
enum enum_name {
111
+
constant_value = number;
112
+
}
113
+
\end{verbatim}
114
+
115
+
Similarly to messages the enum is given an \textit{enum\_name} and then any number of \textit{constant\_value}s can be defined. All of these constants need an associated
116
+
value in order to function properly and the first of those needs to have 0 as its number, so that the enum has a default value in cases like fields with the \textit{optional}
117
+
modifier.
118
+
In order to bind multiple \textit{constant\_value}s to the same \textit{number} the \textit{allow\_alias} option must be set to true. This is done by inserting this line
119
+
into the enum before any definition of \textit{constant\_value}s:
120
+
121
+
\begin{verbatim}
122
+
option allow_alias = true;
123
+
\end{verbatim}
124
+
125
+
Once an enum is defined then it can be used in other parts of the Protocol Buffer, as seen in this example:
126
+
127
+
\begin{verbatim}
128
+
enum Success {
129
+
Ok = 0;
130
+
}
131
+
132
+
enum SendError {
133
+
NoSuchConnection = 0;
134
+
SendFailed = 1;
135
+
}
136
+
137
+
message SendResponse {
138
+
oneof result {
139
+
Success s = 1;
140
+
SendError err = 2;
141
+
}
142
+
}
143
+
\end{verbatim}
144
+
145
+
\subsection{Protofile service definition}
146
+
147
+
Services allow the easy generation of service interfaces and stubs to then be used by RPC implementations.
A service is defined with a \textit{service\_name} and after that any number of inidvidual methods. In order to define the methods first the keyword \textit{rpc} must be used.
157
+
Then a name for the method is given through \textit{rpc\_name} and a parameter for the \textit{message\_type} that this method accepts. And then a \textit{message\_type}
158
+
is defined as the return value of the RPC. A stream of a particluar \textit{message\_type} can be defined by putting the keyword \textit{stream} before the type.
159
+
160
+
An example of this would be the SubListen service from this project:
Catch2\footcite{catch2_main_site} is a C++-based unit testing framework. It is design to be easily integrated into C++ code and match the overall look and feel
230
+
of normal functions and boolean expressions. This framework also provides micro-benchmarking capabilities. It is a good fit for this project, because it serves
231
+
to develop the C++ frontend with unit tests in mind and optimizations spurred on by benchmarks measuring the speed and efficiency of the implemented methods.
232
+
233
+
\subsubsection{Unit Tests}
234
+
235
+
Unit Tests in Catch2 are defined very similarly as normal functions in C++. This example, pulled from the Github repository of Catch2, shows the simplicity of
236
+
this framework and its integration into projects.
237
+
238
+
\begin{verbatim}
239
+
#include <catch2/catch_test_macros.hpp>
240
+
241
+
#include <cstdint>
242
+
243
+
uint32_t factorial( uint32_t number ) {
244
+
return number <= 1 ? number : factorial(number-1) * number;
245
+
}
246
+
247
+
TEST_CASE( "Factorials are computed", "[factorial]" ) {
248
+
REQUIRE( factorial( 1) == 1 );
249
+
REQUIRE( factorial( 2) == 2 );
250
+
REQUIRE( factorial( 3) == 6 );
251
+
REQUIRE( factorial(10) == 3'628'800 );
252
+
}
253
+
\end{verbatim}
254
+
255
+
First the relevant Catch2 headers are included and then a function with a return value is defined. In this case it is the function factorial.
256
+
This function will be executed by Catch2 during the testing process. Then a test case is a macro defined as:
The argument \textit{testname} is a arbitrary name given to the unit test, which is then later during the running of the test printed alongside the results of the macro.
263
+
Tags can be given to the test by inputting one or multiple tags into the \textit{tags} field and change the behavior of the macro accordingly. In the case of the example above
264
+
the only given tag is the name of the function to be tested. After this the \textit{TEST\_CASE} macro has a curly brackets-enclosed body in which the logic of the test can
265
+
be defined.
266
+
This requires the use of other specific macros included in the Catch2 framework. For example:
267
+
268
+
\begin{verbatim}
269
+
REQUIRE( function(value) == expected_value );
270
+
CHECK( function(value) == expected_value );
271
+
\end{verbatim}
272
+
273
+
The two macros described above, REQUIRE and CHECK, operate in a similar way. They both execute the given \textit{function} with the provided \textit{value} or \textit{values}
274
+
and then assert if the returned data equals true or false according to the provided boolean operator. If it does then it was successful and the rest of the \textit{TEST\_CASE} is executed. The difference
275
+
between REQUIRE and CHECK is however that if a REQUIRE macro fails it throws an exception and the unit test is stopped from executing the remainder of code inside it.
276
+
277
+
\subsubsection{Micro-benchmarks}
278
+
The benchmarking macros in Catch2 are defined similarly to how unit tests are. Benchmarking in itself is a useful practice, that provides a way to measure the performance
279
+
and speed of a particular function.
280
+
281
+
\begin{verbatim}
282
+
#include <catch2/catch_test_macros.hpp>
283
+
#include <catch2/benchmark/catch_benchmark.hpp>
284
+
285
+
#include <cstdint>
286
+
287
+
uint64_t fibonacci(uint64_t number) {
288
+
return number < 2 ? number : fibonacci(number - 1) + fibonacci(number - 2);
In the example above the unit test macros and benchmark macros from Catch2 are first included in order to be used later. The function to be benchmarked is then defined
307
+
After that the TEST\_CASE macro is used combined with the [\!benchmark] tag in order to turn this unit test into a benchmark. In the actual body of the test the function
308
+
is first tested weather or not it actually works as intended before any benchmarks are done. This is done with the REQUIRE macro, since it throws an exception if the
309
+
assertion fails, preventing the rest of the benchmark from executing unnecessarily. If all the tests before the benchmarks pass then the actual BENCHMARK macros are
310
+
executed.
311
+
312
+
\begin{verbatim}
313
+
BENCHMARK(string name) {
314
+
... benchmark ...
315
+
};
316
+
\end{verbatim}
317
+
318
+
As part of the BENCHMARK macro a arbitrary name is given to it, which is then later during the output of the test used as a identifier for the specific benchmark.
319
+
Then the actual logic of the benchmark is then defined within curly brackets giving a lot of freedom in how a certain benchmark is executed. Adding a return statement
320
+
within the benchmark will ensure that the compiler doesn't mess with the test.
321
+
322
+
After this is run a summary is automatically output within the command line window. This includes multiple data points that pertain to the execution speed of the tested
323
+
function:
324
+
\begin{enumerate}
325
+
\item\textbf{Samples:} The amount of times the code within the curly brackets of the BENCHMARK macro is repeated in order to build a dataset to calculate the mean execution time.
326
+
\item\textbf{Iterations:} %Need to find out what this is
327
+
\item\textbf{Estimated run time:} The estimated amount of time the code within the benchmark will take to run. Mesured in milliseconds.
328
+
\item\textbf{Mean/low mean/high mean run time:} The mean time it will take for the code to run as well as the low mean and high mean for this in nanoseconds.
329
+
\item\textbf{Standard deviation:} The standard deviation from the mean time in nanoseconds,
0 commit comments