As the final lab assignment for our Concurrent Programming module, we were asked to optimize matrix multiplication. C++ was set as the language and Linux was set as the environment for this task. The tasks for this lab assignment were as follows:
- Write a naive sequential program to perform matrix multiplication on a n x n matrix containing double precision values. The matrices were to be filled with random double values. Only the time taken for the actual multiplication part was to be recorded.
- Identify a C++ library for Linux environment which supports parallel for loops and write a parallelized version of the above program.
- Running the above 2 versions of matrix multiplication for matrix sizes of n = 100 to n = 1000 in increments of 100 and record the time taken for each of these executions.
- We were then supposed to look in to ways to optimize matrix multiplication taking the processor architecture into account as well and come up with a 3rd version of the matrix multiplication making use of both parallel for loops and various optimization techniques.
The full source code of this project can be found here: https://github.com/pubudu91/mm-optimization
Naive Sequential Version
For this, the standard matrix multiplication algorithm was used. If the matrices are called A, B and C,
Recently, I created a Governance Registry cluster on EC2 using Nginx as a load balancer. The cluster created was a 3 node cluster, fronted with Nginx. The initial plan was to create a cluster with 2 Nginx load balancers, one each for the Store components and the Publisher components, as given below.
Originally proposed deployment pattern
As the first step in creating the cluster, I was advised to create a cluster (same deployment pattern as above) of just one G-Reg node. Although I successfully managed to deploy the cluster, there was a major issue in it. The scenario for the G-Reg cluster I was creating was that the artifacts would be deployed by the publishers and as such, the Publisher context should only be accessible by publishers (typically in a company). The artifacts would be consumed by users and they would access these artifacts through the Store.
Now in the cluster I created, the issue was that if a user signs in to the Store, he/she would also be able to access the Publisher and vice versa. This is problematic since only the publishers (i.e: the company) should be able to publish artifacts. This is because G-Reg has the Single Sign On (SSO) feature enabled by default. When SSO is used, a user signed into one system can access other, connected systems without the need to sign in again at those particular systems. More on SSO can be found here.
The WSO2 Application server is used for hosting, deploying and managing applications, built on the WSO2 Carbon platform. A detailed documentation of the Application Server can be found here.
As is the case with other WSO2 products, multiple instances of the Application Server can be installed in a cluster. When in a cluster, the work is shared between the multiple instances although it appears as if though there is only a single instance of the Application Server (AS).
In this tutorial, we will be using AWS EC2 instances to create a AS cluster. The EC2 instances will be Ubuntu based. We’ll be creating a cluster of 3 AS nodes, using Nginx for load balancing and MySQL for storing the user management and registry data of the AS. More information on load balancing can be found here and here.