Planet CDOT

November 24, 2015

Armen Zambrano G. (armenzg)

Mozilla CI tools meet up

In order to help the contributors' of mozci's quarter of contribution, we have set up a Mozci meet up this Friday.

If you're interested on learning about Mozilla's CI, how to contribute or how to build your own scheduling with mozci come and join us!

9am ET -> other time zones
Vidyo room:

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

by Armen Zambrano G. ( at November 24, 2015 05:52 PM

November 19, 2015

Armen Zambrano G. (armenzg)

Buildapi client released - thanks F3real!

When we wrote Mozilla CI tools, we created a module called in order to schedule Buildbot jobs via Self-serve/Buildapi.

We recently ported it as a Python package and released it:

This was all thanks to F3real, who joined us from Mozilla's community and released his first Python package. He has also brought forth the integration tests we wrote for it. Here's the issue and  PR if you're curious.

F3real will now be looking at removing the buildapi module from mozci and making use of the python package instead.

Thanks F3real!

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

by Armen Zambrano G. ( at November 19, 2015 04:31 PM

Joseph Jaku

Assembler Lab

Last week in class we took a look at coding in assembly language. Coding in a low-level programming language is a good way to better understand how computers work and really helps when you're trying to comprehend the output of an objdump. Any programmer in pursuit of optimizing their code should really learn how machine code works because by doing so they can control exactly how the CPU will process their program. But as far as actually creating usable software within a reasonable amount of time; forget about it!

To complete our look into machine code we were tasked to combine two scripts written by Chris, one a simple Hello World, the other a basic looping program and use them to write a program that would output the loop from 0-30 printing the loop count each pass.

Essentially this:

for i in {0..30}; do echo "Loop: $i"; done

It may be a one-liner in bash but in assembly it took me over 30 lines. And here is how I did it:

 x86_64 on Xerxes                                                 Aarch64 on Aarchie

It took a while to understand how to write in assembly because there are a lot of problems you don't face in other programming languages. The biggest is keeping track of which registers to use when. Most of them have specific purposes and if you don't know what they do you could use them incorrectly or accidentally write over things in your code that you need. On top that it is an entirely new and different style of syntax to get used to. The good thing is that their aren't a ridiculous amount of instructions to learn, you just have to learn the capabilities of each one.

In IPC144 one of the first things I was told was never to use GOTO, which bummed me out because it was something I liked to do a lot when writing small batch scripts. In assembly it's perfectly acceptable and a neat way to do conditional statements. In this example it was used to solve the challenge of not printing the preceding 0 in our 00-30 loop from numbers 1-9.

The lab was fairly difficult and took a lot of tinkering. I tried to do things step-by-step and test each time I made a change because debugging in assembly proved to be difficult. Most of my errors came only at run-time indicating a core dump, which gave me no error information. Also, finding information online is a lot harder for assembly than C or other high level languages and then the people who know it explain it in ways I can't even understand. Chris's intro to assembly was the greatest resource and he threw in a lot of hints which helped.

Aarch64 and x86_64 assembly are very similar and I found it a lot easier to complete the Aarch64 code after doing the x86_64 loop. To me Aarch64 makes a little more sense in its use of registers, their is less to memorize when writing in it. With x86 some of what you do seems sort of arbitrary, like the way the remainder of a division is stored in %rdx. It makes more sense to me to simply calculate the remainder yourself and store it where you'd like to. Yes it's one more instruction to write but isn't that the idea behind low-level programming, you want to have full control. 

by Joseph J ( at November 19, 2015 02:36 AM

November 17, 2015

LEAP Project

LEAP at FSOSS 2015

Greetings everyone. Recently we at LEAP team did a short presentation about the LEAP project at FSOSS 2015 which is the Free Software and Open Source Symposium hosted by Seneca College. We go over a brief history of the project from its origin to where we’re at currently as well as go into a bit of details on the work we’ve done and the results that came from it. If you’re interested in some of that as well perhaps seeing some of the faces of the team do watch the following video. We’ve also uploaded the slides to our presentation on our wiki page.

Other than us, there were many other presenters that all that very interesting talks. You can watch our presentation as well as all the other great talks that happened at FSOSS here.

by hzhuang3 at November 17, 2015 07:08 PM

November 16, 2015

Donald Nguyen

Getting to know Tcl : Stage I

I'm at the start of becoming knowledgeable of the Tool Command Line(Tcl) package. Tcl is an easy to learn, open-source, and highly extensive programming language that has a large range of uses. From web applications to networking, Tcl is mature, yet evolving, language. 

Tcl, sometimes pronounced as 'tickle'.

I will be working with Tcl 8.6.4 for this assignment.

Once I've downloaded and uncompressed the package, I had to add a few options to the configuration file, so I used the following command: 

./configure --enable-threads --prefix=/home/dtnguyen11/SPO600/a1/tcl_a1 --exec-prefix=/home/dtnguyen11/SPO600/a1/tcl_a1 CFLAGS=-O3

--enable-threads - this option allow Tcl to compile itself with multithreading support
--prefix and --exec-prefix - set to place install in these directories
CFLAGS - compile with these compiler flags. In this case, I choose the -O3, the highest of the optimization levels in GCC.

For the make process, I've simply used the make command. For subsequent makes, I've removed the previous compilation using the 'make clean' command. 

During the configuration and make of the package, I've timed and observed both processes on a x86_64 and ARMv8 AArch64 system for anything unusual. I've ran each process of the install five times. Here are the results:

Configure Run
ARMv8 AArch64
4.634 seconds
26.910 seconds

ARMv8 AArch64
2m4.248 sec
17m28.81 sec

Since I was working on shared systems, I did not fully install the Tcl package, so I can't measure execution performance. Both the configure and compile times look consistent on both systems, and I had no dependency issues. A variant of .1 millisecond or 1 second are negligible, however here is a noticeable difference on both systems between the first and any subsequent compile times. On the x86 system, the difference is about 13 seconds, and for the ARMv8 AArch64, it's over a minute. The difference in time is the CPU fetching data from main memory versus cache. During the first run, none of the data is (or shouldn't be) in cache, but subsequent run, which were done right after the previous completed, will have some data in cache. For this package, the difference in time is worth overlooking, but larger packages may need a better build strategy than mines to successfully configure and compile.  


by Donald Nguyen ( at November 16, 2015 03:28 PM

November 15, 2015

Andrew Smith

CC Registry – What it’s all about

In this series:

Wouldn’t it be nice if one day you could find an image online and know whether you can legally use that image and for what purpose? This is fundamentally what the Creative Commons registry is about.

The concept is simple:

  • Publishing tools (such as Flickr) automatically hash uploaded images and register them, including the name of the author, the licence, and a URL to the image.
  • The registry holds the hashes, the other metadata, but not the image itself, only a thumbnail.
  • Later this information is provided to anyone querying the service and can be displayed to the user in whatever way makes sense in that application.

The implementation is not so obvious, which is why we spent a couple of semesters at the Seneca Centre for Development of Open Technologies (CDOT) working on it.

There have been attempts at this in the past. None of them have gone very far, at least in part because they were trying to do too much. All past attempts were attempting to provide some kind of guarantee that the licence information in the registry is 100% correct – which of course is impossible.

Instead of doing that – we decided to leverage existing platforms (e.g. Wikimedia Commons, Flickr) because they already deal with this issue.


by Andrew Smith at November 15, 2015 03:24 AM

November 13, 2015

Dmytro Yegorov

Building Firefox with default options

So for our project we have to pick a package and build it using different optimization options. We will have to find the best build of this package for each machine (arm64 and xerxes).

As with any package, firefox had its own prerequisites. Thankfully, mozilla got a script that automatically checks your system for all dependencies and installs what is missing (dependencies for Linux systems). For some reason I could not do this on ARM64 machine – will have to check for all tools manually. On xerxes it took around 5 minutes to run this script and install all requirements. Of course, this time cannot be used for evaluating purposes, as it highly depends on network usage.

After you are done with dependencies, the build process is pretty much the same as with any other package – download the source, compile, build. However, mozilla uses specific tools for all these steps.

In order to download the source, they suggest to use hg clone command, which is like git – it downloads (synchronizes) content from their server. If you have a slow connection, you can download the source code manually and then unbundle it (how to). After you downloaded the source, you have to configure it by running “./mach mercurial-setup” from source directory. Mozilla comes with a wizard that asks you lots of questions, such as if you want to install specific plugins etc. Configure time takes around 5 seconds system time (depending and the options you choose). All of the configuration options you put in a file .mozconfig. Detailed instructions, options description and examples of config files can be found here.

After that you can finally build the firefox. Simply run “./mach build” from source directory. Build process took 44 minutes of system time on xerxes machine, so you can grab a coffee or have a snack while it is building. More detailed information about building process can be found on Mozilla’s website.


by dyegorov at November 13, 2015 07:39 AM

FSOSS 15 or How to contribute your project

This year I got a chance to attend FSOSS 2015 at Seneca@York. There were lots of interesting and worth attending presentations, but the most interesting and, as for me, the most useful one, was “Optimizing your OS project for contribution” by Joshua Matthews. The presenter pointed out many important things to consider when preparing your project, and to summarize most important ones I would conclude that you should sort off your tasks (bugs/developing problems) and reply as soon as you can. Interesting fact, if contributor doesn’t get a reply from project manager or whoever is in charge within 24 hour, there is a chance of 80%, as I remember, that he will leave. You can lose around 80% of your potential contributors only because you do not reply on time. Seriously, who wants to work with a person, for whom he is not important enough even to reply within considerable amount of time. Yes, you might not be available all the time, or you can be on a vacation or whatsoever, but in that case create an auto-reply or something like that, so the contributor will see that you acknowledged his question/request and will get back to him shortly.

Another important point was that you have to sort your tasks. Everyone gives the best performance at what he can do the best – java developers should be working on with java, C devs. with C etc. Not only you have to sort your tasks by languages/areas of work, but also in terms of skill level of a contributor. You don’t want to give a newbie tasks with high difficulty as well as you don’t want to waste potential of professionals. At the same time, if the person is proficient in C, let’s say, and you have a bug in your core (which is written in C as well), you might want to give this task to a person, who is more familiar with your code and have just enough skills and knowledge to solve the issue, instead of assigning this to someone more professional in programming language, but have no idea about your core structure.

Another amazing point mentioned by presenter was to use tags. With tags you can sort your assignments by all the categories at the same time. Also it is way easier to identify, if you are using multi-colour tags, let’s say.


Overall FSOSS was realy interesting and entertaining event to attend.

Hopefully I will be able to visit it next year :)



by dyegorov at November 13, 2015 06:36 AM

November 11, 2015

LEAP Project

LEAP Koji Account Registrations are Open

Greetings everyone.

For the folks who have been using LEAP and have been wanting to build their own packages for the distribution, the wait for that ability is nearing a close. We had initially announced that we would be opening the build system we use for LEAP to the public and we’re beginning now to take registrations for accounts to our Koji build system.

To register please proceed to the following registration page on our wiki. Follow the instructions as stated and that will create some certificates for your use with our build system. Afterwards we’ll be reviewing the registrations and upon completion of that we’ll provision the accounts. The review process may take a few days.

If there are any questions in regards to the registration or related issues, leave a comment on the blog, find the team on irc, or drop a line on the mailing list.

by hzhuang3 at November 11, 2015 10:46 PM

Tales of LEAP: Introducing ILP32

It’s been quite some time since our last posts but that doesn’t mean we haven’t been actively working on LEAP.  I’ll be taking some time here to kickoff a hopefully more regularly posting schedule and to talk about a feature our team had been working on for quite some time. That feature is having ILP32 support in our tool chain.

What is ILP32?

ILP32 is a data model for the C language. What this means is that Integers, Longs and Pointers will be represented by 32 bits. AArch64 normally runs under an LP64 data model (wherein Longs and Pointers are 64 bit while Integers remain 32 bit). The AArch64 instruction set is a 64 bit instruction set and was made with the expectation that the LP64 data model would be mostly commonly used on this platform.

What’s the significance of ILP32 on AArch64?

By including support for this data model for this architecture, we will then enable the ability to compile and run code that uses the ILP32 model. In essence that means we can allow for the usage of 32 bit code on the 64 bit instruction set of AArch64 which is quite a nice bonus. Applications that were written with ILP32 in mind from years ago can then be used on this new architecture without any changes to the codebase.

What are the pieces involved in achieving a ILP32 capable tool chain?

There are four major pieces that are involved:

  1.  Firstly is binutils which provides the Linker that will link object code together to form the final executable binary. The Linker needs to be able to understand that the code being linked is to be linked in ILP32. To do so it needs to also understand what ILP32 is and have a proper ILP32 emulation mode as well as some flags in place to activate said mode.
  2. Secondly is the Compiler which in this case is gcc which is what will compile the source code into object code. gcc will have to also understand the data model as well as have new flags in place that will tell it to compile for ILP32.
  3. Thirdly is the glibc Libraries which are what the Linker will link the object code to achieve an resulting executable. These libraries need to be ILP32 as well in order to create a ILP32 executable.
  4. Lastly is the kernel which is the Linux kernel in our case. The kernel needs to be able to understand ILP32 as well in order to actually execute the ILP32 program.

Having established what what is necessary for ILP32, let’s illustrate the pieces and how they need to be changed and how the process would go when trying to compile a simple hello world program in ILP32:

The compilation process starting with the source code.

As can be seen the process is very similar to compiling a hello world program in the conventional way but with some additional compiler flags needed for ILP32 as well as a varying degree of patches needed on some components of the tool chain.

Why is LEAP incorporating this feature?

There are a few reasons we as to why we’re developing this support in the tool chain for LEAP:

  1. We want the ability for users to be able to run 32 bit code on AArch64 hardware which could be a handy ability for old code that hasn’t been adjusted for 64 bit systems or where standards are 32 bit for those use cases.
  2. We also would like to be able to run the SPEC CPU2006 benchmark in 32 bit for an apples to apples comparison between AArch64 and x86_64 hardware.
  3. Lastly and perhaps most importantly, we want to simply become a distribution that a potential user can just install on their AArch64 hardware and it would have ILP32 capability from the get-go. At the time of this writing, there isn’t a publicly released tool chain that supports ILP32 on this architecture. We think this feature holds promise for the platform and by having an implementation of it in our distribution we can allow for interested parties to play around with it and perhaps it can develop more from there.


I think we’ll leave it off here for now as an introductory post on ILP32. Next time we’ll continue with the actual work we have done up to this point for this feature and of course the stories and struggles we had while trying to understand it all. Hopefully everyone has been having a lot of fun running leap.

If there are any questions in regards to ILP32 please leave some comments and perhaps we can answer them. Or find the LEAP team on our irc. Otherwise catch y’all next time.

by hzhuang3 at November 11, 2015 09:13 PM

Ramanan Manokaran

recommendations for the test framework design Week 6

What makes a good benchmark?

The results of your benchmark should be consistent. This can be done multiple ways. We ensure we are using the same data. We also should test the configure, build and execution multiple times. The operating system should be same when comparing benchmarks.

A process of a given scenario would be

  1. Start Server
  2. give test data
  3. set up client
  4. record how long it takes

We should try the same process with different data sets to see how the program performs.

By using different make and ./configure options we can try to find the best executable or which will give us the best performance.

To give us the best performance the speed that it takes to process the data and the size of the build size file

It is also important to note when looking at the total time spent on building or configure the difference between the initial run and the second would be the greatest when compared to the rest and should be excluded on our benchmark so the difference between the time it spent on each run is more consistent.

by ramanan136 at November 11, 2015 06:53 PM

Andrew Smith

Installing proprietary NVidia drivers in CentOS7

I don’t even know if this should go into Open Source, but there are definitely machines that will not run with the Nouveau driver with some of the newest NVidia cards, and this is the only realistic way I know to fix it.

The procedure for installing this thing is incredibly weird and error-prone on CentOS 7. I used to do this on Slackware without any effort at all. Oh well, I guess in software this is called progress.

After downloading the latest driver from the NVidia website (let’s say it’s in ~andrew/Downloads/ you’ll need to make sure you have the latest update of the kernel from CentOS:

yum groupinstall "Development Tools"
yum install kernel-devel kernel-headers
yum -y upgrade kernel kernel-devel

And reboot. You’ll be doing a lot of rebooting for this procedure.

Now you’ll need to make sure that the Nouveau driver is not turned on automatically on boot (that’s the open source driver that works pretty well except for the current NVidia cards):

sudo mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
sudo dracut -v /boot/initramfs-$(uname -r).img $(uname -r)

And reboot. At this point when your system boots it won’t look as pretty as it used to, that’s ok.

Now you’ll need to kill X. Use the key combination Ctrl+Alt+F2 (or other F keys) to get to a command-line-only screen. Log in as root. Now run this command to turn off X:

systemctl stop gdm

And now you’re ready to install the driver (change the path and name of the installer to suit your user’s name and the version you downloaded):


Hopefully that will all work now. At the end it will ask if it should modify the X configuration file for you – tell it yes.

Now reboot again. Your system should now be using the NVidia driver. You can check in a terminal like this:

lsmod | grep nvidia

It should print something like this:

nvidia 8638316 43
drm 311588 3 nvidia
i2c_core 40325 3 drm,i2c_piix4,nvidia


by Andrew Smith at November 11, 2015 12:46 PM

November 10, 2015

Joseph Jaku

NETPBM Package Install

Netpbm, rather than being a single software packages is a suite of over 300 separate tools that can be used in the manipulation of graphics. Examples of this manipulation pulled right from their website include, "Shrinking an image by 10%; Cutting the top half off of an image; Making a mirror image; Creating a sequence of images that fade from one image to another."

For this project I'm going to be building the latest stable release of Netpbm which is 10.35.87 acquired from Sourceforge. This package has a few dependencies, make and a c compiler of course. On top of that it requires perl and flex (lex).

Each program can be run as simple as something like this:
ppmtogif <inputfilename> <outputfilename>
This program seems to meet all the criteria necessary for our final project which includes bench marking it. Firstly, it's compiled in C with a set of compiler options already used to optimize the program, this should make things interesting when we mess around with them.

The options used are:
 -O3 -ffast-math  -pedantic -fno-common -Wall -Wno-uninitialized -Wmissing-declarations -Wimplicit -Wwrite-strings -Wmissing-prototypes -Wundef
 The only apparent issue is that the installation procedure has several prompts included to customize the installation. These however are controlled by a Perl script located in the buildtools folder in the downloadable tarball. I've been able to fill in the answers in the script and make it fully automated, this will make it easier to build the same program over and over and get more accurate build times.

The build procedure is slightly different than most packages listed for the assignment. First, you have to run configure; this configure points to a perl script. The time it takes to run this script is next to nothing so I won't be including the results of this. For my testing I plan on using the same Makefile for each build.

The next step is to run make. On Aarchie I had no issues running this command. The entire procedure on average took about 7m34s. However on Xerxes I was unable to make. The error listed said that my png library was too new for this package. Many programs depends on this library so I did not want to downgrade to an older one for the sake of my project, especially on a public machine. I tried downloaded the source code and built a new libpng (version 1.2). I then went into the Makefile and changed the directory to look for the png library. This still! did not work. So I decided to try a newer version of Netpbm (10.47.04) and this dismissed the error, however I ran into another error later on involving the converter xpmtoppm. I found a bug report regarding this with an included patch. However this was found in 2009 and has since been patched already in the source code I was using.

I'll have to work on getting this to compile on Xerses more later on but for now I will list my results for another x86_64 system; an old Intel i3 box I have setup as a home server. I was able to get netpbm-10.35.47 to make without any issues on CentOS. The make time was averaging a much shorter 41.93s. This is not surprising due to this being a dedicated machine with no background processing going on.

After having run make you have to run the command make package pkgdir=<dir>, this command will copy all of the files needed for the install into a directory of your choosing, I just threw them into a tmp folder. On Aarchie this took about 30.15s on average and 4.63s on my home server. 

Now that the package is ready to be installed, we can run the script "installnetpbm" in the source directory. What this does it pretty self explanatory. Similar to the configure, the time it takes to run the install command is negligible. The install directory of netpbm on Aarchie was 21704B and on my home server, 21364B. The bin directory being the most at 20000B and 19644B respectively. Odd thing to note, Aarchie had two more utilities available after install, 315 vs 313. Due to the libraries present on each machine, some of the tools may not have been able to install.

In order to complete the assignment, we need to be able to alter the C flags used when running make. In my case I am able to do so by editing the Makefile. At the bottom there is a variable that stores the flags, I'm going to set it to use the environment variable "CFLAGS" which I will be able to export from each permutation created by our m10k_build script.

Thankfully for my chosen package the bench marking will be fairly straightforward. I'm going to have several varying images downloaded onto the machine and then I will run some of the utilities available on each image file. Most of which are converters so I will do a few of them (applicable ones for the image selected) and then several of the other tools that involve actually changing attributes of the image. This can all be achieved using a simple bash script.

I'm mostly going to be looking at the time it takes for each command to run, however I also want to see the effects on the output file size of each conversion. They may not vary at all, but I guess we'll jut see. I haven't yet decided on how many tests I'm going to run. I just know I have to make sure that the time it takes to run the commands is large enough that I can see the variation in each run.

by Joseph J ( at November 10, 2015 09:34 PM

Miguel Dizon

Benchmarking AArch64 and x86_x64 with Make

Two computer architectures can vary in performance. To test this out, I’m using the AArch64 and x86_64 architectures to measure their performance. I’ve decided to use Make for the benchmark.

For benchmarking AArch64 and x86_64, I’m using the computers that Seneca offers. I ran each test 3 times on both systems and recorded the average of how much time each test took.

For the first test, I ran the configure tool in the Make package.

Average Configure Time
AArch64 x86_64
25 seconds 8 seconds

x86_x64 beats AArch64 by 312%.

Next, I built the program with its default settings.

Average Build Time
AArch64 x86_64
35 seconds 7 seconds

x86_x64 beats AArch64 by 500%.

The Make package comes with its own unit tests, which is convenient for measuring runtime performance and for further benchmarking.

Average Test Time
AArch64 x86_64
1 minute 4 seconds 50 seconds

x86_x64 beats AArch64 by 28%.

Overall, the x86_x64 system beats the AArch64 machine in all the tests. Since AArch64 is a newer architecture compared to the matured x86_x64, programs and compilers might not be optimized for AArch64.

I’m currently testing out different compiler flags for Make so that I can optimize the performance of the application for both architectures. I’ll also document the results when I’m finished with it in the near future.

by madizonseneca at November 10, 2015 08:23 PM

Ramanan Manokaran

Lab 3- Algorithm Selection

The following code shows example of sound being fed:

We created one function that multiply the scale by a volume scaling factor expressed as a floating point number in the range of 0-1.

The second function is using a lookup table that is has an array of 65536 values.

vol2, Taken from Professor Chris Tyler

vol2, Taken from Professor Chris Tyler

Here is the function that performs vol 2.

Run time on both of these machines are as follows for function 1 and 2

lab3 runs

executing vol2.c while Aarchie runs on average the slowest.  However during the third run on Aarchie vol2 run performed better than Aarchie vol1 third run and almost matches Aarrchie vol 1 first run.

by ramanan136 at November 10, 2015 08:18 PM

Jayme Laso-Barros

My First Attempts at Building MariaDB

Our project for the SPO600 course requires each student to build, test, and benchmark an open-source software package (that benefits from GCC compiler flags), and then communicate the results upstream. Our professor provided a list of packages to choose from, and for my project I chose MariaDB (version 10.1) simply because database software was the most familiar to me compared to other options I was able to choose from. The project is divided into three stages: baselines, flag variations, and final results. This post will be covering the first stage of the project.

Update: I added a screenshot of the build results for the AArch64 system since I forgot to do so when I originally posted this. I also included another screenshot of what the build process looks like while make is running.

Update 2: Removed all references to the server names.

Before I start explaining my first steps towards building MariaDB, I believe it’s important to give a brief description of how the software came to be. MariaDB is an open-source relational database management system (RDMS) that describes itself as “a drop-in replacement of MySQL with more features, new storage engines, fewer bugs, and better performance.” The project is led by the core members who created MySQL, most of whom left the dev team the moment Oracle announced the purchase of Sun Microsystems back in 2009. Their reason for departing was they felt that Oracle’s respect towards open-source and its community in general was lackluster (to put it nicely), and so they decided to fork the MySQL software and continue their vision of a true open-source RDMS.

For this project, the following servers will be used to build, test, and benchmark MariaDB:

  • an x84_64 system running Fedora 21
  • an AArch64 system running LEAP7

To prepare building the software, I downloaded the source code, which can be found on its GitHub page. This is my first time using GitHub – or even just Git in general – on either of the servers however, so before checking out the code I went through the setup guide to generate a couple SSH keys for my GitHub account and then cloned the repository into my local directory.

Next, I installed the packages required for building MariaDB by running this command:

sudo yum-builddep mariadb

I knew that both the x86_64 and AArch64 systems would have most packages already installed, but when I ran the command I noticed that each required a couple packages (and dependencies) that the other didn’t.

This is what xerxes need to install...This is what the x86_64 system need to install…
...and this is what aarchie needed.…and this is what the AArch64 needed.

Now that all the required packages are installed it’s time to start the build. Looking at the generic build instructions, MariaDB currently uses cmake, a command I am all but unfamiliar with. After a bit of Googling, I found that cmake does not have a “make clean” equivalent. The recommended solution is to do an out-of-source build by simply creating a new directory to place the all build files in. Afterwards, the directory can easily be removed using “rm -rf”.  For the purposes of this project, our professor instructed us to time at least three builds on each system to get a good average. So with that said, here is what I did each time I built the software (from the root of the source code):

# Create the build directory.
# Note: Not to be confused with source code's own BUILD directory.
mkdir build

# Go to the directory.
cd build

# Configure the build as is, without changing any configuration options.
cmake ..

# Time the actual build.
# Note: I used /usr/bin/time instead of time for possibly more accurate results.
/usr/bin/time -p -o ~/project/buildTime1.txt make

# Remove the build directory and repeat all the above steps a couple more times.
cd ..
rm -rf build

You may have noticed that I didn’t actually install MariaDB afterwards. Well, I don’t know how to perform a proper uninstall of the software after using cmake and make and feared that I would have unexpected results when rebuilding MariaDB.

Pictured below are the results of the build times. I accidentally messed up my first time building MariaDB on both systems because I forgot to add /usr/bin/time on the command line when running make. All I know is after roughly half an hour, the x86_64 system was finished building and the AArch64 system was at 42%.

Build results for the x86_64 system. The file size of the build was found using "du -sb build".Build results for the x86_64 system. The file size of the build was found using “du -sb build”.
Build results for the AArch64 system. The file size of the build was found using "du -sb build". Note the incredible difference in build time.Build results for the AArch64 system. The file size of the build was found using “du -sb build”. Note the incredible difference in build time.
This is the build progress that's shown while running make.This is the build progress that’s shown while running make.

Admittedly at this point I hit a wall. After some more research on cmake I found that the compiler flags can be set in the CMakeLists.txt file. However, when I looked through the file I found multiple places where compiling flags were being set and I didn’t know which ones I would need to modify. Here’s a piece of code that I was looking at in particular, lines 184-234 of the code:


OPTION(WITH_ASAN "Enable address sanitizer" OFF)
  # gcc 4.8.1 and new versions of clang
  MY_CHECK_AND_SET_COMPILER_FLAG("-fsanitize=address -O1 -Wno-error -fPIC"
    # older versions of clang
    MY_CHECK_AND_SET_COMPILER_FLAG("-faddress-sanitizer -O1 -fPIC"

    MESSAGE(FATAL_ERROR "Do not know how to enable address sanitizer")

# enable security hardening features, like most distributions do
# in our benchmarks that costs about ~1% of performance, depending on the load
  SET(security_default OFF)
  SET(security_default ON)
OPTION(SECURITY_HARDENED "Use security-enhancing compiler features (stack protector, relro, etc)" ${security_default})
  # security-enhancing flags
  MY_CHECK_AND_SET_COMPILER_FLAG("-fstack-protector --param=ssp-buffer-size=4")

OPTION(ENABLE_DEBUG_SYNC "Enable debug sync (debug builds only)" ON) 
OPTION(ENABLE_GCOV "Enable gcov (debug, Linux builds only)" OFF)
  MY_CHECK_AND_SET_COMPILER_FLAG("-fprofile-arcs -ftest-coverage -lgcov" DEBUG)


I will spend more time researching cmake to make sure I know what I should be doing to set the GCC compiler options, though if anyone else happens to know already or has an idea feel free to leave a comment below.

The final portion of the first stage of this project is to come up with a benchmarking strategy. Since I am working with an RDMS, I figure the best way to start benchmarking would be to first setup a database in MariaDB, and then use a random SQL generator online to get a table with thousands (or perhaps hundreds of thousands) of rows of data. With that, I will time how long it takes to run SQL statements such as CREATE TABLE and SELECT. I may also try fetching large amounts of data from multiple tables using JOINs. I will be sure to update my blog periodically with my benchmark results.

by Jayme LB at November 10, 2015 07:44 AM

Gaurav Patel

File Transferring

A couple of days ago I wanted to transfer some source files on Archie (CDOT's ARMv8 - AArch64 system) and Xerxes (CDOT's x86_64 system) machines and run my program and analyze the result between these systems. When I regularly connect to these systems it uses my private key generated on my Linux machine as password and provides me access to Archie and Xerxes systems. I was having problems making a file transfer to these systems but after some research and help from professor (Chris Tyler) I learn few more interesting things as well.

Transferring file to Xerxes system was easy, If I’m on College’s network then I can just use “scp test.cpp (filename) (username)”. Xerxes server is only access able from Seneca’s network so, if you want to connect to Xerxes server from outside you can use other system which can be access able from outside like Archie and Matrix and using that you can connect to Xerxes system but you have to transfer the private key to these systems. Also after connection name if you do not include “: (destination)” the file will not be transferred it will just make copy of that file and put it in current directory with connection name as file name.

When you want to transfer file on Archie machine it’s little complicated because you have to specify the port number. Archie machine connection is set up to connect via different system so you have to connect to it using “ssh –p 2200 (connection name)”. Also for Archie there are two different connection names, one for connecting from outside College network ( and another for connecting from within Seneca network ( so if you want to transfer file on Archie system you can use “scp –P 2200 test.cpp (filename) (username)@(connection name either internal or external):(destination)”. Also keep in mind that because Linux is case sensitive the scp command uses capital ‘P’ to specify port number.

If you have your private key protected by a passphrase and every time you want to connect to different machines you use your private key and you have enter your passphrase to unlock private key. If you use ssh-agent and add your private key to that agent and by doing that you can connect to multiple servers without entering your passphrase and also keeping you private key secured at the same time. You can do that by entering command “eval $(ssh-agent)” the add your private key by entering “ssh-add ~/.ssh/id_rsa (path to private key)” and you will be prompt to enter your passphrase and enjoy.

Finally, there are many other services you can use to transfer files like: ftp, sftp, filezilla (GUI), wget, and more.

by Gaurav ( at November 10, 2015 02:05 AM

November 09, 2015

Gaurav Patel

Algorithm Selection

A couple of weeks ago, we were asked to write two different approaches to adjusting the volume of sound samples. The two approaches we were asked to write was:
  • Scaling the values of sound sample by multiplying value by a scaling factor.
  • Scaling the values of sound sample by multiplying value by a scaling factor and storing it into a lookup table. So, when the program needs the data it will provide it from lookup table until the scaling factor isn’t changed.

To analyze the performance I’ll be using the Archie system (CDOT's ARMv8 - AArch64) and Xerxes system (CDOT's x86_64). I’m going to be using data type int16_t (16 bits) to represent a sound sample and providing 5,000,000 samples which adds up to 10MB of sound sample’s volume to adjust.
To calculate the performance of each approach I first made a dummy run of the program to get its performance without adjusting the volume. In this the program just creates a 10MB of sample data and prints out all its values.  Then I calculated the performance on each approach of volume adjustment. I made five runs on each approach on each system.

Performance on Archie:
Dummy run
10.86s (11392 KB)
7.79s  (11328 KB)
10.82s  (11328 KB)
7.49s  (11328 KB)
10.82s  (11392 KB)
9.54s  (11328 KB)
9.50s  (11392 KB)
12.15s  (11392 KB)
9.06s  (11392 KB)
11.99s  (11392 KB)
Lookup Table
7.96s  (11584 KB)
11.39s  (11584 KB)
7.37s  (11584 KB)
11.39s  (11648 KB)
11.42s  (11584 KB)

Performance on Xerxes:
Dummy run
0.86s  (12416 KB)
0.85s  (12360 KB)
0.87s  (12368 KB)
0.85s  (12364 KB)
0.93s  (12392 KB)
0.92s  (12308 KB)
0.90s  (12416 KB)
0.91s  (12316 KB)
0.91s  (12424 KB)
0.86s  (12472 KB)
Lookup Table
0.93s  (12448 KB)
0.95s  (12496 KB)
0.92s  (12524 KB)
0.94s  (12608 KB)
0.92s  (12540 KB)

As you can see results from Archie system is inconsistent in terms of run time, but the memory usage of the program is consistent and Xerxes system is providing consistence run time and memory usage. By looking at these stats we can say that Xerxes system is faster in performing these tests.

The average run time on Archie system is: 9.556s on dummy run, 10.448s on multiplication, and 9.906 on the lookup table; and the average run time on Xerxes system is: 0.892s on dummy run, 0.900 on multiplication, and 0.932s on the lookup table. Using the average we can calculate the run time of adjusting volume on Archie system is: 0.892s on multiplication method and 0.350s on lookup table; and for Xerxes system is: 0.008s on multiplication method and 0.04s on lookup table method. You can also see that Xerxes system consumes more memory than Archie system. So, based on these results I would say that the approach of adjusting volume depends on the system you are using.

by Gaurav ( at November 09, 2015 01:51 AM

November 07, 2015

Ramanan Manokaran

Lab 2.5 Compiler Option


Enable profile feedback directed optimizations, and optimizations generally profitable only with profile feedback available.

The following options are enabled: -fbranch-probabilities, -fvpt, -funroll-loops, -fpeel-loops, -ftracer.


Profiling has 3 phases:

  • -fprofile-generate to generate a flag that collects statistics at run time about the executitions.
  • -fprofile- use can be used at least after the program has been compiled once. The profile information saved in the previous compilation is used to guide the optimizer.
  • the drawback however is that every time the program is compiled it carry along this training guide


Definition: Reorder basic blocks in the compiled function in order to reduce number of taken branches and improve code locality.

Enabled at levels -O2, -O3.

by ramanan136 at November 07, 2015 08:58 PM

Gaurav Patel

Open Source Community

There are a lot of open source software’s out there and a lot of programmers come to gather to make that software. One of the open source software I looked at was Front Accounting which is licenced under GNU General Public License. This license basically allows users the freedom to run, study, share, and modify the software

How to Contribute to Software
To begin contributing to this software you can head over to Front Accounting’s wiki page which gives you the information on the project, like: different ways to obtain project source code, links to forums/discussions, and more.  On their forum page you can find out the project broken down into many little pieces and how are they planning to implement it, place for reporting bugs, wish list, modules discussions, and even job offers.
Bug Tracker
On the forum page there is a place to report bugs and people discuss on how to fix these but the primary system is Mantis bug tracking system which is allowed for registered users only but you can make an account easily. Mantis system is an issue tracker that provides a delicate balance between simplicity and power.
Bug fixes/Patches
Eventually someone who will be fixing bugs will be discussing their progress and on forum or on the Mantis bug tracking system and many people would be testing to see if the patch fixes these problems or not and according to these results that patch will be used in project.
The community can jump into discussions or issues and provide solutions. The source code is made available on GitHub, SourceForge, BitBucket and with different versions/modules. On the Forum page there are over 7,000 registered users and they have discussed in over 4,000 topics about Front Accounting software.

Second open source software I looked at was Spam Assassin licenced under The Apache Software Foundation. Apache license agreement allows users the freedom to run, study, and share. The licence agreement must be sign if you want to modify the software.
How to Contribute to Software
To begin contributing to this software you can head over to Spam Assassin wiki page where you can learn about the software, join to mailing list, look at reviews, and etc. There is also a linkfor developers where it gives you information about joining to development spam assassin software. You can find information on general rules like coding style, development rules, how to get source code, and etc. You will have to join a mailing list in order to get latest updates on software. Contributors are divided in to different roles, like: contributors (anyone can provide feedback, submit bug reports, or submit patches), committers (a committer is simply an individual who was given write access to the code base), PMC Members (the project management committee is responsible for managing a project), and finally there are users who uses the software.
Bug Tracker
There is a forum pagewhere all the problems are reported and discussed by developers. You have to be registered to report bugs and collaborate on solving these problems.
Accepting Patches
Eventually someone will come around to fix the bugs reported in software, they will be discussing their progress on bug tracker system and when they are done they will be submitting it. According to development mode page some one will be reviewing the code and after that they will be testingit.

by Gaurav ( at November 07, 2015 08:00 PM

November 06, 2015

Donald Nguyen

30 Years of Freedom - FSOSS 2015

'30 Years of Freedom' was the theme of the Seneca College's Centre for Development of Open Technology's 14th annual Free Software and Open Source Symposium, celebrating the 30th birthday of the Free Software Foundation. For the uninitiated, the FSOSS is an event where presenters from many walks of the Open Source community come together and share ideas, development, or issues to others. Among the many presentations are keynote presentations, the 'must-see' events. The day is divided into three streams for the presentations, so three presentations can take place at the same time in different rooms, but no other presentations occur during the keynotes. The keynote presenters for this year's FSOSS were Ruth Suehle, Community Marketing Manager for Open Source and Standards at Red Hat, Mark Surman, Executive Director of the Mozilla Foundation, and Chris Tyler, Industrial Research Chair at CDOT. The keynotes, in my opinion, have been nothing but great.

I unfortunately missed Chris Tyler's keynote presentation(Sorry! I will watch the VOD later), however I did get to attend the other two keynote presentations.

Before I get into sharing anything, kudos to the artist who personified this year's theme as a dove on the FSOSS 2015 t-shirts. 

Ruth Suehle:
I think what separates the top presenters from everyone else is the ability to present your purpose with such passion, that the audience wants to know more at the end of the piece, and Ruth definitely did that during her keynote. Kicking off the presentation with a brief background, she then introduces us to the term 'Maker', describing it as a someone who makes things. Whether it be costumes or code, Ruth goes on to describe the spirit of all Makers, pointing us to the documentary 'Vintage Tomorrow' as the perfect example of a Maker. At this point, I'm beginning to see how Makers ties into Open-Source, as members of both communities have the drive to make, tinker, and repair. Another term she used are 'Sharers', one who shares to help succeed. She used a picture of one caveman sharing how they made fire, thus both keeping warm to drive the point home. 'A true Maker is also a Sharer', a quote that I will remember for a while. As we now know what Makers and Sharers are, Ruth goes into the works of different Open-Source communities, such as the OS hardware and prosthetics. Throughout the presentation, Ruth shares a few concerns, such as the lack of protection within OS hardware, and Makers who are not Sharers and only seek a profit. She also recommends a few links to explore more (I will post them below). I haven't had the chance to explore these links yet, but I it's definitely on my to-do list once I finish my semester. From start to finish, Ruth was passionate and unwavering in her beliefs, and I highly recommend watching the VOD once it uploads. Thanks Ruth for the great presentation!   

Mark Surman:
Just like Ruth, Mark is ivy league in term of presenters. Mark's passionate and steadfast presentation was all about the Free Software Movement, it's history and where it stands now. Mark used a variety of pictures, from a black-and-white painting of a group of scientist, including Isaac Newton, sharing ideas, to screenshots of the Mozilla Foundation throughout key points in its life, to his very own high school picture, to engage the audience to his moral and concerns. I've not only learned a lot about the Free Software Movement and the Mozilla Foundation, but enjoyed the comic relief Mark sprinkles throughout his presentation. Like Ruth and many other presenters of FSOSS 2015, I can help but notice his passion for the Open-Source and the Free Software Movement. The Mozilla Foundation has the perfect person for an Executive Director. Here is to 350 years of freedom! 

Fuel the Movement - Mark Surman

This year is my 3rd time attending FSOSS and as always, I left the event intrigued, curious, and motivated to contribute to the open-source(OS) community. While I've only shared my tidbit about the keynote speakers, I've learned a lot from the other presenter and I would not have attended FSOSS if it weren't for the them. I noticed this year that FSOSS had more sponsors supporting than the previous two years. I hope that's a sign that FSOSS, the Free Software Movement, and Open-Source is growing better and stronger.

FSOSS Source:

Ruth Suehle Recommendations:

by Donald Nguyen ( at November 06, 2015 02:35 PM

November 05, 2015

Jae Jo

Fedora22: Python Virtual Enviroment: virtualenv with Paramiko

In this blog post, we will learn “virtualenv” which is isolated python virtual environments.

Isolated environment will help you to install packages in separate virtual space.

Therefore, you can only install python related packages into this virtual environment so you can manage your main machine cleanly and efficiently.  

Paramiko is a python implementation that help you to manipulate Linux commands with python codes.

Install Python Virtual Enviroment Folder With Paramiko

Install virtualenv →sudo yum install python-virtualenv

Create Virtual Python Enviroment Folder → virtualenv ~/.venv

Activate Vfolder → source ~/.venv/bin/activate

Install Plugin → pip install paramiko

Check Installed Plugins → pip freeze

Deaactivate Vfolder → deactivate

Make a Shortcut Command:

From Host Home → vim ~/.bashrc

Add line to .bashrc → alias activate =”source ~/.venv/bin/activate”

Source to Update System Variables → source .bashrc

Test Enviroment:

Go Into “.venv” Mode → actle

Install Test Enviroment → pip install pytest

Run Plugin → py.test tests/

Congratulation! You have successfully installed virtualenv with paramiko.

by jae910108 at November 05, 2015 06:24 PM

November 04, 2015

Joel Aro

Algorithm Selection

Consider the following: You are given a file containing sample data, consisting of 16-bit integers, from an audio source. Your job is to take that data and scale it by a floating point value from 0.0 to 1.0.

In the situation above, what algorithm should the developer use? Does that algorithm have consistent run times when ran on different architectures? In this post I will be investigating this case.

The two algorithms I will be using are:

  1. Scaling the values by simply calculating each sample by the factor
  2. Scaling the values by calculating the data and storing into a lookup table, so that when the program reads the same data, it will check the lookup table for the scaled value.

Here is my implementation for both algorithms:
Scale each sample:
Using a lookup table:

I will also be using an x86_64 system and a ARMv8 system for testing.

Let’s do some benchmarking:

From the results above we can see that my implementation of the problem ran much better on the x86_64 machine than the ARMv8 machine for both algorithms. The reason this might be the case is that my implementation reads from a file, it has to read from the file for each sample.

We can also see that both algorithms run more inconsistently on the ARMv8 machine compared to eh x86_64 machine. Based on the results of my implementation I would suggest that the developer use the first algorithm to implement this problem, but depending on how they implement it they may find that the lookup table algorithm is much faster.

by joelaro at November 04, 2015 10:48 PM

November 02, 2015

Donald Nguyen

A Peek Into Open-Source

Throughout my time at Seneca College, I’ve heard the term 'open-source' used as an advantage of using Linux over Windows, software that is free to use, and as a way to describe a community of developers that like to use and modify software. While I had a vague idea of how open-source projects work, I've never looked into the details of how a contribution is proposed, examined by a community, and then applied to a build. Today, I've looked into the GNU D compiler (GDC), a D compiler under the General Public License (GPL), and Firefox, a popular web browser that's under the Mozilla Public License (MPL), to take a peek behind the scenes of open-source projects.  

GDC Project Revived
GNU D Compiler
GDC is currently developed by a small team under the lead of Iain Buclaw. In the GDC project website, I found links to the source code on Github, bug reporting website, and forum of the D Programming language. When I clicked on bugs tab, it brought me to a website where 4 big icons caught my attention, File a Bug, Search, Open a new account, and Documentation. To File a Bug, you will need to create an account, however anyone is free to search for bugs and read the documentation. Within the search result, you can click on any bug and read the details and interactions from other members regarding that bug. 

GDC Project Bugzilla
Bugzilla is not pretty, but it works
To see the process of bug resolution from start to finish, I looked at Bug 54, titled 'GC corruption of TLS memory'. If you'd like to see the Bug, you can follow the link here, but it's gist of issue is that a package compiled with GDC using a particular option produced a bad result. Once the bug was submitted, user Iain Buclaw replied with a situation, and the submitter responded, letting Iain know their solution worked. The conversation was brief and lasted two weeks. From the looks of it, it seems really easy to submit a bug and have a bug go from new to resolved. I also liked how I was able to easily search for bugs and read the interaction. I felt that if I had the anything to contribute to any bug, I can make an account and comment. An issue I found while reading the bugs was that sometimes users submit various amounts of details regarding the platform they used. For instance, I found one user specify 'x86 Other' and another putting 'x86_64 Linux' in the hardware section of the bug. I think the submission system should vet the users to include more details regarding the platform, as it may help users who want to recreate the bug themselves. Another odd thing I noticed was the forum of the D Programming Language. You can find this forum by clicking on mailing list lab on the GDC homepage. When I clicked on tab, it redirected me to the GDC group within the D Programming language forum, and the first thing I saw was rows of bug submissions! Why is it possible to submit bugs in two places for the same project?

Mozilla Firefox
Mozilla Firefox (I'm sure you knew that already...)
The process of contributing to Mozilla Firefox, is a bit more complicated. First off, I had to do some Google-foo to find the page that lays out the steps towards contributing to Mozilla. That page (found here) has guides that building Firefox, searching for bugs and fixing them, and recommendations of what part of the project you may want to work on based on particular skills. For instance, if you know Java, they say you can contribute to Firefox Mobile, Firefox on Android, and MozStumbler. To find bugs, there is a link to a page similar to GDC's bug reporting page where you can search and browse current bugs. In fact, both GDC and Firefox both use the same system (Bugzilla), so the process of submission, progress, and solution is nearly identical. The difference I noticed was the number of people participating is bigger. Looking at Bug 1123671, where a feature in Firefox fails, about nine developers participated in the conversation. Some confirmed the bug, others ask questions and provided feedback on possible solutions. Some of the solutions used development tools that Mozilla Development Network (MDN) recommended. MDN has a review process, outlines in Steps 4,5, and 6 on that page that I mentioned earlier. To get a patch reviewed, you make a request when you attach a patch to a bug(following some key steps, like including the bug ID) and wait for a reviewer to respond. 

MDN's Patch Submission Process
Who the reviewers are is not clear, but the name and profile are there to check out once someone does respond to the review request. Once the patch passes the review stage, it goes through another step where it needs to succeed in a "try server" run. This seems like a timely process, but I figure for a project as big as Firefox, it's necessary. At the final step, the patch get marked as 'ready to commit' and gets passed to a "Mozillian", who will push the patch to the repository. From there, the patch may be updated and must pass another test before being applied to a nightly build. After reading all that, I'm rather impressed of the number it steps it takes to get a patch applied to a build. With the sheer volume of bug submissions however, I can see a number of gone ignored and have no views to them. Also, since this uses the same submission system as GDC, a user can post various amount of details about the platform they are running on. Maybe the platform is not so important for Firefox, but it doesn't hurt to add more detail, right? 

While I'm writing this as part of an evaluation, I'm glad to have looked into the works behind the open-source aspects of the GDC project and Firefox. I think I have a clearer picture of the community aspect of the term open-source and can see the advantages myself. 


by Donald Nguyen ( at November 02, 2015 05:02 AM

What's Going on in There?

That's the question I asked myself when I was first introduced to my first programming language, C. C is a compiled language where, as I was told in class, "source code is "translated" from your written code to machine code using a compiler". I didn't put my hand up to ask what machine code looked like, or what magic the compiler ran on because I was too timid, but the question never went away. Fast forward a couple years and I'm now enrolled in a class that I believe will provide some insight behind the mechanics of the compiler. Here are some observations (with pictures, yay!) of compiler behaviours that were made by my class. 

As a baseline, we've compiled a simple "Hello World" program in C using gcc with options -O0 -fno-builtin -g -o hello. Then, we looked at the object file the program produced using the objdump command. Our class tinkered with the compiler options, and made the following observations.

The first group was tasked with compiling with an additional option, -static, and report any differences from the baseline. According to the gcc man pages, -static is an option that prevents linking with shared libraries on systems that support dynamic linking. Upon compilation, the first thing they noticed was the large file size. The modified executable, hello1, was 738115 bytes (~721 kb), as opposed to our original, which is about 8 kb. When they attempted to look into the object file, the sequence of calls of the main function was similar, but the hello1 program had much more activity, thus the bigger executable file. 
Size Comparison, hello vs hello1
Size Comparison, hello vs hello1
Different calls for printf()
Another group was tasked with compiling without the -fno-builtin option. -fno-builtin tells the compiler to not use built-in optimizations. When reading about this option in the man pages, GCC has functions with the prefix "__builtin_" that it will try to use if it results in faster, more efficient code. When the group removed the builtin option, the object code was very similar, except for the function that was called to output Hello World.  While the source code was identical, the compiler called puts instead of printf for hello2.
First look at an optimization option. Notice the different function calls.
In the same theme as the last group, another compiled the hello program without the -g option. -g is a one of many debugging options in GCC, where it will produce debugging information in the operating systems native format. Comparing the two hello programs, with one without debugging information was smaller than the original. Also, the object files look very different.

Less information to write tends to lead to a smaller file size
Without debugging information, the object file looks different
The final group to mess with compiler options worked with -O option. The baseline option was -O0, which is no general optimizations. Reading the man pages, there are many -Ox options, which enable, ignore, or complete some kind of action(s). This group used -O3 instead of the default, which turned on optimizations options specified from -O2 and -O. The executable file was bigger, but the interesting part was reading the object file. Comparing the two object files, the one with -O3 required less calls to run than the original. It's hard to tell if the optimizations applied did much for our Hello program, but I can imagine programmers and developers making the decision to use this option for a better optimized program at the expense of memory.    
-O0 vs -O3
There were a couple groups that modified their source code before compiling with the same options as the original Hello program. I don't know Assembly well enough to fully read the object files, but I noticed a pattern occurring with the file for the program with 10 printf arguments. For the object file with the user-written output function, I found it cool how the function was called just the way I taught in my first Introduction to C Programming class.
I didn't expect that many MOVL

Call to user-made function
This experiment was the first time I've read object files using objdump and read anything that had Assembly instructions in it. After this class, I went about to do this with much bigger programs just out of boredom and curiosity. Now that I know a little bit more about compilers and what I was going on when I was in Introduction to C Programming, I feel intrigued to know more!


by Donald Nguyen ( at November 02, 2015 05:01 AM

So Many (Compiler Optimization) Options...

A week ago, we learned about compiler optimizations, where code is altered to run like the original, but with better performance. Using GCC with the correct options, better performance can be faster program execution, or smaller file size or smaller executable size. Don't get the idea that putting all the possible options in will result in an well optimized program however, many of the options conflict with another, so a little research is needed before putting the compile command together. Today, everyone in our class presented their research and observations on two of the many optimization options in GCC.

-fno-inline was one of two topics I've chosen to research and present. -fno-inline, or no inlining as I ended up calling it during my presentation, is self-explanatory. This option tells the compiler to ignore the inline keyword and not attempt to use inline techniques anywhere else. 
Inlining takes code from a function is places it directly in the calling routine
For this option, I wrote a simple C program that added random numbers to elements of an integer array. This program used a for loop and function call, similar to the inlining example above. I've compiled this program twice, with and without -fno-inline.

After compilation, I've compared the executable files side-by-side using objdump. The program compiled with inlining ran without making a call to my addRandom function, while the other, put together with the -fno-inline option, did. The program running without inlining had more instructions, but just barely. One odd observation I found, was that the program compiled with inlining made three calls to rand() directly and sequentially. I realize this is a simple program, but it isn't explicit whether the add portion of addRandom() occurred, so I had to put some trust that it did. For this simple program, I didn't observe any significant performance difference.

gcc -O0 -finline -o inlineon l3a.c vs gcc -O0 -fno-inline -o inlineoff l3a.c

-ftree-loop-if-convert was my other option. This option is not as easy to understand as the no inlining, so it took me a while to somewhat get my head around this one. According the man pages, this option will attempt to remove flow-control in the innermost loop, so for this experiment I created this program and compared the object files. 

When I attempted to compile the program like how I did earlier, I kept getting object files that looked identical. The result was suspect, I was either forgetting an option that -ftree-loop-if-convert required to run, or my program didn't have anything for that option to optimize. It wasn't until I found this website that noted that without the optimize argument, -O, some options would not be enabled, even if specified. Knowing that, I compiled one with -O and the other with -O0 (no optimization) and compared my results. Looking at the object files, the optimized version is much shorter, making fewer calls to rand() and jumps to main. As a mentioned before, I don't know assembly well enough to walkthrough the instructions but less is more, right? 
gcc -O -ftree-loop-if-convert -o ftreeon l3c.c vs gcc -O0 -o ftreeoff l3c.c
 Presenting these topics went the way I expected, however I was asked what vectorization was after my presentation. On one of my slides introducing -ftree-loop-if-convert, I've put the description of the option that's right from GCC man pages. During research, I found this option referencing vectorization a few times, however I didn't have much time to fully grasp what it was and play around with it myself, as I usually do with learning new concepts. Chris Tyler answers his own question by mentioning Parallel Computing. A quick trip to Wikipedia and I found myself going link-to-link.

Here is a link to the presentation I made.


by Donald Nguyen ( at November 02, 2015 05:01 AM

Archie and Xerxes

A couple weeks ago, we were introduced to the 'archie', CDOT's ARMv8 AArch64 system. I knew that during the first couple weeks of the course I had access to this system, however I mostly ignored it as I did my labs on my personal 64-bit laptop or on 'Xerxes', CDOT's x86_64 system. As archie is an ARMv8 system, it is vastly different than any system I've used, thus calling for some experimentation to observe their behaviors.

Just as we don't compare apples to oranges, I will not make any comparisons against themselves. Instead, I will experiment, observe, and compare the results against themselves.

The experiment I keep mentioning involves two programs that have the same solution, but operate differently. The program takes a 16-bit signed interger, multiplies it by a factor between 0 and 1, and stores the result. Program A will take the interger, multiply it by the factor, and store it into an array that has been created before the multiplication. Program B will take the interger, pass it to a function that will do the multiplication, then pass it back to a variable.

I ran each program 5 times and recorded the result. Execution times were consistent on Xerxes running both programs and while Xerxes executed Program A .110 seconds faster than B, I don't find that to be a significant difference. On Archie, both programs had execution times with a significant variance between runs. For instance, during the 5 executions of program A, there was a 10 second difference between the first run and the second. The same happened during with Program B. Archie showed good performance running Program B over Program A. 

Run Xerxes - A Xerxes - B Archie - A Archie - B
1 0m0.995s 0m1.110s 0m14.480s 0m11.080s
2 0m0.997s 0m1.114s 0m24.440s 0m16.550s
3 0m0.997s 0m1.111s 0m14.550s 0m12.260s
4 0m0.997s 0m1.104s 0m22.780s 0m26.140s
5 0m0.998s 0m1.117s 0m14.130s 0m11.790s

I expected both systems to run differently and that's what I see during this short lab. I can see many factors skewing these results, but the purpose here isn't to measure performance and optimize as much as possible.


by Donald Nguyen ( at November 02, 2015 05:01 AM

October 31, 2015

Joel Aro

Seneca FSOSS: Day 2

The second (and final) day of FSOSS started out a little differently than the first. I slept through 3 alarms and as a result ended up missing the first time slot of presentations. If I did somehow get to one of the presentations I would have chosen to go to the 3D on the Web one.

Empowering OS Contributions and Your Community
Regnard Raquedan gave a very interactive presentation talking about his role in the Mozilla community and that when we contribute to any open source projects to understand not only your role, but the roles of others you are working with. Most open source communities do not have a defined structure that keeps the project moving, and as a result the community themselves have to work together.

Regnard contributes to Mozilla as a Mozilla Rep, which is essentially a leadership program where “mentors” drive the community and keep them motivated and to assist newcomers. He mentioned that the reps are picked from the Mozilla community and are given access to resources such as: funding, merchandise, etc, that might help in any events they might have in mind.

Near the end of the presentation, Regnard gave us a few mini case studies, which also happened to be related to real cases, to discuss. This was interesting, because open source is dependant on the community, and situations where contributors take advantage of funding or abuse their position, it affects the community as a whole. These situations have to be resolved in such a way to not disrupt the delicate balance that the project stands on.

Keynote – Mark Surman
The keynote speaker for today was Mark Surman, who gave a very enthusiastic presentation on his experience with the open source movement. In his talk, he discussed how Mozilla’s decision for Firefox being open source was how Firefox was allowed to emerge into the browser race as a strong competitor. At the time, Netscape (later Mozilla), decided that to be a competitor they needed something different than what was being offered at the time. They decided that open source was the way to go, and looking back on it now, it definitely was the best choice.

As the open source movement grew, the community backing it up grew more passionate about it. Mark talked about the Stop Online Piracy Act (SOPA) back in 2012, and how when the community found out how it would affect their ability to browse the web with freedom, they protested against the act. Large websites and organizations such as Mozilla, Wikipedia, Google, Reddit, and Flickr began to blackout their websites in protest. This event was inspiring and demonstrates the power of the people, and not just the open source community, people who simply browse Reddit or read articles on Wikipedia were informed about the act, resulting in a widespread awareness of the act.

Mark talked about how desperately the open source community needs leaders. They need people who can not only innovate, but drive people to accomplish goals. They need to be able to fuel the movement so that the movement itself can continue to exist.

Skills Track: Linux Power Tools
This presentation by Christopher Markieta was very useful. In it he showed various linux commands and tools that a developer might use throughout his workflow. I found it informative and remembered situations in the past where most of these tools would have been useful. Unfortunately, he ran out of time and had to skim through the Vim section of his presentation, which I wanted to learn more about.

The one tools I will definitely use in the future is pushd. I constantly find myself navigating through 5 or more directories when installing new software and with pushd it will make it much easier.

I also was interested in the “tmux” command that Christopher demonstrated. I often ssh into a server I use for personal projects and the thought of getting a graphic display from the ssh sometimes popped into my mind, and now, thanks to his demo, I have an answer for it.

Customizing Your Ubuntu Desktop to Make it Awesome
Philip Ballew gave a entertaining presentation on customizing the Ubuntu desktop, and while I personally don’t use Ubuntu Unity, I still found cool tricks that I might use for my laptop running Xubuntu. He demonstrated how to make workspaces show different backgrounds, how to utilize the Unity Tweak Tool for further customization, and terminal emulators.

He also demonstrated how to customize launchers in Ubuntu, which I found interesting, because sometimes when I use the terminal to work on stuff I find myself spending about a minute in just setting up the environment with multiple windows, the layout, etc. Being able to simply click an icon and have all that done for me is definitely going into my linux toolbox.

Justin Flowers presentation on Vagrant was the last presentation, that I visited, of the day, and in it he talked about the software for managing environments, Vagrant. The process of having to manage environments was never a problem for me, since I have never worked with others that needed a specific environment, but I still found Justin’s presentation interesting. He demonstrated where to find and how to install Vagrant, some scenarios where it might be used, and the simplicity of it. By simply pulling a repo’s .box file a contributor is instantly able to test the project in a working environment, without having to spend hours of setting up dependencies and editting config files, the entire process as he showed it took about 1 minute max.

While it does not apply to any projects that I might work on in the near future, I can definitely see situations where I might need to use Vagrant.

Day 2 Close & FSOSS Final Thoughts
I ended up not going to the reception after, since I am not really good in forced social environments, so I can’t say much about it, but the rest of FSOSS was great. I learned so much in just two days, and got to hear about amazing projects. There was a lot of people and can see how much of a community the free software and open source movement has brought about. It seemed like everyone wanted to contribute in discussing topics about the presentations, and showed very concerned about the future of the movement itself.

Before coming to FSOSS I was blank slate when it came to open source stuff, I didn’t have much experience in it yet, but was interested in learning more about it. When people asked me in the past Why do people show their code online for everyone to see, instead of making money off of it? I probably would have given a lazy answer about it being easier to get help from others and that would be the end of the conversation, but now, I feel like I can have an actual discussion about it.

After two days of listening to presentations I can say that I am more motivated about contributing to open source projects more than I ever have been. If you are reading this post in the future when FSOSS is coming around again, and you are on the fence about getting tickets, I highly suggest you go. There are lots of people with different experiences, backgrounds, and opinions on text editors! Even if you don’t talk to any of them, just sitting in the presentations like I did was a great learning experience as a student and as a developer. Still kind of wish I got a sticker though. Anyways, thanks for reading up on my experience for a first timer at the Free Software & Open Source Symposium it was a lot of fun. Definitely excited to see how the movement will evolve over the years, and its conferences like these that keep it alive and inspire others to join as well.

by joelaro at October 31, 2015 06:25 AM

October 30, 2015

Joel Aro

Seneca FSOSS: Day 1

The Free Software & Open Source Symposium(FSOSS) is a [1]conference hosted by Seneca College’s Centre for Development of Open Technology(CDOT),  where students, programmers, hobbyists, hackers, and open source enthusiasts gather from all over to discuss open source topics, share information, showcase projects, and meet with others in the open source community. For more information about the conference you can visit it’s home page at

As someone who is interested in the open source movement, I decided to attend this year’s FSOSS conference being held at Seneca@York. Having never attended any previous FSOSS’s or any conferences for that matter, I was excited. It also happened to be the 30th anniversary of the Free Software and Open Source movement, which made the day a little more special. As you can tell from the title of this post, I will be describing my thoughts on the first day(Oct. 29th) of the symposium.

Registrations, Goodie Bags, & The Refreshment Room
The morning began with registrations at 8:30am, and attendees were given their name tags and a cool Mozilla lanyard. Along with the nametag they were given a green tote bag full of goodies:

Tote bag with the FSOSS 2015 logoTote bag with the FSOSS 2015 logo
Green water bottle, "I <3 Mozilla" wristband, Savoir-faire Linux bookmark?, Mozilla water tattoo, FSOSS itinerary, and FSOSS t-shirtGreen water bottle, “I
Mozilla lanyardID and Mozilla lanyard

The goodie bag was great, but I wish we got some laptop stickers to litter my laptop with. Unfortunately these pictures were the only ones I took during day one, and they weren’t even taken on site, I must have been too interested in the presentations to remember to take photos. After receiving my ID and tote bag I headed for The Refreshment Room which was conveniently located beside two of the three rooms that held presentations. Inside was a long table full of refreshments such as coffee, tasty treats, chips, and water. There was also a screen that was projecting a live feed of the presentations happening in one of the rooms. There were seats to sit down and eat, but I headed down to the first presentation instead, which was the Welcome to FSOSS portion of the day.

Welcome to FSOSS 2015
This presentation was being held in one of the two large lecture halls that we had at Seneca@York. I’ve been to the room for my previous classes, but never for a big event like this. There was a big camera in the center (the one responsible for the live feed in The Refreshment Room), photographers taking pictures of attendees and presenters, camera/sound crews, students, professionals in the field, and the presenters themselves. At 9:30, once everyone was setup, the presentations began.

Unforunately, I also did not bring my bag which would have contained both a notepad and a pen so I could take notes, so the next few paragraphs will be me trying my best to recollect the day’s presentations. I did however remember that my phone also works as a notepad, but that didn’t work out too well as I soon found myself paying more attention to my fingers than to the presenters.

Back to the presentation, it began with an introduction and greeting from the Faculty of Applied Science and Engineering Technology Dean, Ranjan Bjattacharya, who presented John Selmys, a recent Faculty retiree, an invite to all future FSOSS conferences.

Ranjan then called up a member of Seneca College’s Alumni, who talked mainly to the students in the audience a bit about the benefits of joining Seneca Alumni. He then passed the stage over to Chris Tyler, the Industrial Research Chair in Open Source Technology for Emerging Platforms at CDOT, who also happens to be my SPO600 professor. Chris gave a very informative talk about the history of open source, what it’s roots were, how it evolved over time, and the differences in views. He ended his presentation on the note saying that although Free Software and Open Source has brought about controversies, they should not be seen as separate movements, but rather unify them with the word AND, resulting in a term that describes the movement as a whole, Free Software AND Open Source. He then concluded his presentation, and opened the stage for discussion and questions.

Open Source Cloud with Open Stack
My original plan after exiting the presentation room was to head for the presentation on N1QL Query Without Compromise being presented by Don Pinto, but when I got to the room I was informed that the presenter did not show up, and the staff suggested that we head on over to one of the two other presentations being held in the same time slot. That is how I ended up in the presentation for Open Source Cloud with Open Stack being presented by Mirza Kamaludeen.

My knowledge with cloud technology is not exactly the best, but from what I understood from the presentation was that this cloud computing solution, OpenStack, was going to make working with big data much easier and faster compared to the current implementation of cloud computing. You can view more information here:

OpenStack is scaleable in that depending on what your intentions for the cloud, you simply add services you want to use and remove services you don’t want to use. As shown here, OpenStack has six services that the user/company can use and Mirza went into detail talking about each one and how they each had a function that was separate from the others. He also mentioned that OpenStack was built with failure in mind, and showed a diagram describing how each component was built to be independent from the others, and also showed how each component manages their own databases in case one component did fail. There were also a number of optional components that did more specific tasks, and Mirza talked about each of those.

The presentation was very interesting, but I don’t have much experience with the cloud computing industry and as a result, could not fully follow most of his presentation.

After the presentation was the designated lunch period at 12:00pm. The Seneca@York cafeteria was filled with plates full of delicious sandwiches, wraps, and salads. The seats were filled quickly and I ended up having to eat my delicious sandwich in the chilly Canadian outdoors.

Keynote – Makers
After lunch I went to the Keynote presentation where Ruth Suehle gave us a very interesting presentation on Makers. Ruth is the Community Marketing Manager for Open Source at Red Hat. She gave us a really quick rundown of makers from the past to the makers of the present, and talked about how the goal of a maker never changed. As interesting as her presentation was, often times causing a small chuckle in the audience, I didn’t take notes of it, and since she was moving a mile a minute we were barely given room to breathe until she moved onto the next topic. Her main focus was that we, as people working in the technology field, should contribute to the cycle of makers. That even though people use our code to make software, we should use it as an incentive to keep on improving.

Ring: A Free Decentralized Communication Software
The presentation on Ring was presented by Alexandre Lision and Adrien Béraud. This presentation was by far my favourite, mostly because they actually had a demo that where we could see the product in action, but also because it was a field I wanted to see improvements in. Communication software so far has been simple client to server interactions, but Ring set out with the goal of removing a centralized server in mind. More information can be viewed here. This meant that clients needed to be able to connect to other clients and, from my understanding, they were able to solve that with a Distributed Hash Table(DHT), a technology similar to how bittorrents work.

After the initial installation of Ring, the client is given a string of characters which acts as a public key for the client. When the client connects to another client it sends it’s key which is then authenticated on the receiving end to ensure that the person who sent the message is who they say they are.

This allows messages to be encrypted over the network and can only be decrypted by the person with the corresponding private key. Meaning that if someone is listening on the connection, they won’t be able to decrypt the message since their private key doesn’t match. The result is a highly secure connection between two clients, without the need for a server.

The demo showed the basic UI of Ring, some of its features, its insanely long key, and the contact list. One feature that caught my attention was the ability to drag and drop video files into the program and it was automatically begin streaming on the other person’s client. I may have not noticed the feature in other communication software both proprietary and open source, but that feature, for me, was a game changer. Although seemingly simple, I was amazed at how long it took for something like that to exist. I am looking forward to seeing how Ring develops, and I might consider trying to contribute to the project.

Day One End
I did stay for one more presentation, The Power of Two, but was also writing notes from the past presentations into my phone. I left before the final time slot presentations began, since the last topics did not interest me much.

The first day round of presentations were very informative, and made me more interested in the Open Source community than I originally was. The other presentations that I didn’t go to must have been equally interesting also, and a part of me wishes I could go to the Open edX, Ring, and LEAP presentations all at once, but the volunteers have informed me that the recordings of those presenatations should be uploaded, so I am hoping to view them there. Overall, I had a great time and I love the atmosphere that FSOSS had. Being surrounded by professionals, and people who have actual work experience in the field made me realize how much more I have to learn. The Open Source community seems very friendly and was open to discussion, which made it a very good experience for me to learn and understand more about the mentality behind big projects such as OpenStack or Ring. I hope tomorrow is just as interesting, and hopefully this time I will remember to bring a pen and paper.

1. About FSOSS

by joelaro at October 30, 2015 02:58 AM

October 21, 2015

Ali Al Dallal

How to redirect ssl www to ssl non-www in nginx

I recently got my beta access with and wanted to make sure my SSL is enabled for all traffic to my blog, so I figured I can easily rewrite non ssl traffic using www or non-www to send everyone to one consistent URL which is the non-www with SSL.

You can use this simple virtual.conf

server {  
    listen      80;
    rewrite     ^   https://$server_name$request_uri? permanent;

server {  
    listen 443 ssl;

    ssl_certificate        /etc/letsencrypt/live/;
    ssl_certificate_key    /etc/letsencrypt/live/;
    if ($host = www.$server_name) {
      rewrite ^(.*) https://$server_name$request_uri? permanent;

Let me explain what's going on here...

server {  
    listen      80;
    rewrite     ^   https://$server_name$request_uri? permanent;

This block basically listen to any non SSL traffic (http) and redirect to https:// and try to preserve the request_uri at the end.

For the second part you can ignore everything and just look at the magic here:

  if ($host = www.$server_name) {
    rewrite ^(.*) https://$server_name$request_uri? permanent;

What happen here is that we are checking for any requested URL with www and redirect them to non-www version with ssl version enabled.

If you have any question hit me on twitter @alicoding :)

by Ali Al Dallal at October 21, 2015 02:30 AM

October 19, 2015

Suk-Joong Han

October 16, 2015

Jae Jo

Git Basics – Open-Source Version Contol Software

In this blog post, we will learn about basic Git commands and features.

The Git is very useful open-source software that can help you to easily manage version control while developing software.

Useful Sites:

Tutorials –

Try Git Commands –

Learn Git Branching –


> mkdir gittest
> cd gittest
Initialize git Folder             > git init
Check Status                       > git status


> touch gittesttouch
Add the changes              > git add gittesttouch
Log Snapshot Point            > git commit -m “gittesttouch added
Check Log                   >git log


Check Branch             > git branch
Create Branch             > git branch gittest2
Run Snapshot                         > git checkout gittest2
Go Back to Original        > git checkout master

Congratulation! You have successfully mastered basic Git.

by jae910108 at October 16, 2015 07:59 PM

October 15, 2015

Anna Fatsevych

SIP, FreeSWITCH and mod_sofia

I have ben working on attempting to create an iOS client that will successfully connect to a BigBlueButton session via audio.

So far I have spent a great deal of time researching the protocols involved that might make this possible. Technologies used by the BBB server are: FreeSWITCH (SIP protocol), mod_sofia, WebRTC, JSON-RCP, and more – but I will go into a little more detail about what is FreeSWITCH, SIP and mod_sofia.

SIP is an Application layer Session Initiation Protocol – it is a signalling protocol that allows two media points to establish media session with each other.

FreeSWITCH is a powerful modular open source communication platform that handles the communication of end-points.
It is written in c and due to its modularity can be built upon and also has a library that can be imbedded into third party apps.

Sofia-SIP is a library which provides the programming interface for SIP. mod_sofia allows for the SIP constructs to be transferred into FreeSWITCH ones, and vice versa, as well as registered endpoints, establish session, register endpoints, send notifications, and provide voice mail. mod_sofia allows for control over channels by manipulating data (e.g. set variables) with ease.

   extension name="calltasks"
     condition field="destination_number" expression="^2000$"
       action application="set" data="var=val"
       action application="bridge" data="user/2000"

This extension has a condition – if the destination number matches the regex expression, if yes
it will carry out a set of tasks – application is the application name and data is the variable to pass on to that application – “user/2000” is passed to application “bridge”.
In the application = “set” , variable named “var” is set with the value “val”.
This is a very convenient and relatively simple interface that encompasses quite complex operations.

More to come on this topic,


by anna at October 15, 2015 02:46 AM

October 13, 2015

Justin Flowers

Dynamically Loading Python Classes

The design for our fault injection framework has required the writing of a suite class which loads in other defined case classes located in their own directory. This means we need to fill a list in the suite class with case classes defined somewhere else. After doing some research we found a few methods of performing this, including using imp and __import__. We ended up approaching the problem by appending the directory containing the classes to the Python path using sys.path.append(). Then we could import each case by removing the “.py” part of the filename and feeding them into __import__(). After importing the class as a module we could use the getattr() function to retrieve its constructor and create a new instance. However we hit a problem here; in order to use getattr() function you must know the name of the attribute you want to remove. We then made the decision that all case classes in our framework must contain the string “Case” in their name. By doing that we could use the dir()  function to get a list of all properties the module had, take the first one containing “Case” in it, and feed it into getattr to get the class definition. After getting the definition for the class we could then instantiate our own and add it to a list of cases. The code to perform this functionality ended up looking like this:

# Create path to classes and get list of filenames in that directory
suite_to_import = "suites/" + suite_name
cases = os.listdir(suite_to_import)

# Append folder to path

# And import every file
for case in cases:
    # Safety to make sure we don't "index()" a string not containing a "."
    if "." not in case:
        print "Not a valid python file for case: " + case

    # Remove the ".py" section
    case = case[:case.index(".")]
    # Import the file
    case = __import__(case)

    # Find the class name
    for name in dir(case):
        if "Case" in name:
            attr = name

    # Get the class object
    case_class = getattr(case, attr)
    # Create a new instance of it and store
    case = case_class()

by justin at October 13, 2015 01:13 AM

October 10, 2015

Nitish Bajaj

Presentations on compiler options.

Compiler option #1: -ftree-vrp
Definition: Perform Value Range Propagation on trees. This is similar to the constant propagation pass, but instead of values, ranges of values are propagated. This allows the optimizers to remove unnecessary range checks like array bound checks and null pointer checks. This is enabled by default at -O2 and higher. Null pointer check elimination is only done if -fdelete-null-pointer-checks is enabled.
Here is my implementation: 
#include <stdio.h>
int main(){
    printf("Array Bound Check: \n");
    int a[10];
    a[3] = 4;
    a[20000] = 3; //gives segmentation fault   
    for(int i = 0; i < 10; i++){
        printf("%i.) %i\n",i,a[i]);
Here are the executable or object code file size:
Without the flag: 9743
With the flag: 11677

Here is the output:

As you can see, the one without the flag gives me a segmentation error when I try to insert the number 3 at element 20000. However, with the flag on, it does not give me a segmentation error. It removes the array size check; if the array is big enough to even allocate that number in that element.

I also noticed another thing while working on this flag. If I try to insert a number/value that is not in the range of the array size but near it, it does not give me a segmentation error. For example:
    int a[10];
    a[3] = 4;
    a[11] = 3;//does not give segmentation fault
    a[25] = 4;//does not give segmentation fault

The value 4 being inserted into element 3 is not giving any errors, without any flags. C/C++ doesn't actually do any boundary checking with regards to arrays. It depends on the OS to ensure that you are accessing valid memory. You are declaring a stack based array. Depending upon the particular implementation, accessing outside the bounds of the array will simply access another part of the already allocated stack space.

Compiler option #2: -ftree-loop-distribution
Definition: Perform loop distribution. This flag can improve cache performance on big loop bodies and allow further loop optimizations, like parallelization or vectorization, to take place.
Here is what the code actually does: 
DO I = 1, N
A(I) = B(I) + C
D(I) = E(I) * F
is transformed to
DO I = 1, N
A(I) = B(I) + C
DO I = 1, N
D(I) = E(I) * F
As you can see, it takes the statements inside a loop, creates a loop and puts 
each statement in their loop.
Here is my implementation of it:
const int size = 100000; 
double* a = new double[size];
double* b = new double[size];
int c = 10;
double* d = new double[size];
double* e = new double[size];
int f = 20;
for(int i = 0; i < size; i++){
c += i;
a[i] = b[i] + c;

f += c;
d[i] = b[i] + f;
I did not see a difference with or without the flag, maybe I did not implement it properly or 
the right way. It does ask for a complicated/bigger loop, which mine is not. 
Here are the executable or object code file size: 
Without the flag: 9935
With the flag: 9911


by Nitish ( at October 10, 2015 08:44 PM

October 08, 2015

Neil Guzman

Python Imports (from ... import ... vs import ...)

I recently came across a problem when accessing and setting variables across different modules. It turns out from ... import ... behaves differently than import ... (see: Python Imports)

The problem I was having was that changes done to a variable in another module was not being shown in a different module when accessing it. To demonstrate this, let's say we have 3 files:


from a import CONFIG
from c import foo

if __name__ == '__main__':
    CONFIG = 13
    print "CONFIG in b = {}".format(CONFIG) # prints 13
    foo() # prints None

from a import CONFIG

def foo():
    print "CONFIG in c = {}".format(CONFIG)

The problem is that foo() in wants to access the changed variable of CONFIG done by, but ends up returning None.

The solution was to use import a instead of from a import CONFIG: (no change):


import a
from c import foo

if __name__ == '__main__':
    a.CONFIG = 13
    print "CONFIG in b = {}".format(a.CONFIG) # prints 13
    foo() # prints 13

import a

def foo():
    print "CONFIG in c = {}".format(a.CONFIG)

The difference between from a import CONFIG and import a is that from a import CONFIG creates a reference to the value of CONFIG in the local namespace that it is being imported in. import a on the other hand, creates a reference to the module a itself.

So by importing CONFIG specifically, you are creating a local copy of the variable CONFIG, whereas importing a creates a reference of that module in your local namespace. By using the a.CONFIG form, modules will be able to modify it and also allow the modules to see changes done by other modules.

by nbguzman at October 08, 2015 04:00 AM

James Shin

Looking at 2 more C compiler options (-fpeel-loops & -funsafe-math-optimizations)

Here’s two more C compiler options I looked at. Hold on to the edge of your seats folks.


Definition from the GNU man page:

Peels the loops for that there is enough information that they do not roll much (from profile feedback). It also turns on complete loop peeling (i.e. complete removal of loops with small constant number of iterations).

Essentially, this option is one way to optimize for-loops by “peeling”. Peeling is the action of splitting the first or last few iterations from a loop and running them outside of the loop body. It is enabled with the -fprofile-use option, which allows the compiler to “profile” your code by reading it multiple times with feedback to learn how to optimize it optimally.

Here is an example of how peeling works.

int p = 10;
for (int i=0; i<10; ++i) {
y[i] = x[i] + x[p];
p = i;

You can see p = 10 only for the first iteration. For the rest of the iterations, p = i – 1. Therefore, the first iteration can be “peeled”.

y[0] = x[0] + x[10];
for (int i=1; i<10; ++i){
y[i] = x[i] + x[i-1];

By peeling, we have eliminated the need for the variable p, which increased performance.

In summary, -fpeel-loops will optimize loops and increase your build time, but decrease run time. Therefore, it is useful in situations where run time is more important than the build time such as if the program will be distributed to users and consumers.


Definition from the GNU man page:

Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link-time, it may include libraries or startup files that change the default FPU control word or other similar optimizations.

This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.

The default is -fno-unsafe-math-optimizations.

As the title states, this options makes some “unsafe math optimizations” – specifically with floating-point arithmetic. Seems unsafe right? It depends. Are you a mad rocket scientist trying to blow up an asteroid with laser beams where the tiniest of fractions and signed and unsigned zeroes could destroy the earth instead? Me neither. So you’re probably okay to use it. You may lose a few tiny decimal points, but if strictly adhering to  IEEE/ANSI standards or being extremely precise isn’t important, then it won’t matter. So to hell with unsafe. Go ahead and try it. Maybe compare the output to make sure though…

by James at October 08, 2015 02:35 AM

Analyzing the effects of basic C compiler options

In this post I’ll talk about the effects of some basic C compiler options I tried out.


The C program I used was a bare-bone Hello World as shown:

#include <stdio.h>

int main() {
printf(“Hello World!\n”);

-g -O0 -fno-builtin

The program was first compiled with the -g, -O0, and -fno-builtin options.
Below is a quick summary of what each option does.

-g               # enable debugging information
-O0              # do not optimize (that’s a capital letter and then the digit zero)
-fno-builtin     # do not use builtin function optimizations

Here is the run time, file size, and the main() section of the objdump binary ELF (Executable and Linkable Format).

real      0m0.113s
user     0m0.032s
sys       0m0.004s

9592 bytes

0000000000400536 <main>:

#include <stdio.h>


int main() {

400536:         55                   push   %rbp

400537:         48 89 e5                      mov    %rsp,%rbp

printf(“Hello World!\n”);

40053a:         bf d4 05 40 00             mov    $0x4005d4,%edi

40053f:          b8 00 00 00 00            mov    $0x0,%eax

400544:         e8 c7 fe ff ff                callq  400410 <printf@plt>


400549:         b8 00 00 00 00            mov    $0x0,%eax

40054e:         5d                   pop    %rbp

40054f:          c3                   retq

Awesome. The ELF looks like gibberish, but it means stuff. Let’s move on.

-static added

The option -static was added.

-static prevents linking with the shared libraries and links a program statically instead. This means any library required will be completely written into the executable. In turn, this means that your executable will obviously be bigger with the big increase in code. The size before 9592 bytes as you saw without -static and became 883200 bytes after.
So why would you use -static? Speed at run time. Dynamic linking takes more time than having everything already statically in the executable. If you desire run time speed over executable size, -static may be a useful option.

-fno-builtin removed

The option -fno-builtin was removed from the original set of options.

As explained earlier, having this option on disables certain builtin function optimizations. Therefore, removing it allowed optimization on the printf() function using a puts instead of printf, which will be more efficient. See the differences in the main section of the ELF.

WITH -fno-builtin

printf(“Hello World!\n”);

40053a:         bf d4 05 40 00             mov    $0x4005d4,%edi

40053f:          b8 00 00 00 00            mov    $0x0,%eax

400544:         e8 c7 fe ff ff                callq  400410 <printf@plt>

WITHOUT -fno-builtin

printf(“Hello World!\n”);

40053a:     bf d4 05 40 00               mov    $0x4005d4,%edi

40053f:     e8 cc fe ff ff                  callq  400410 <puts@plt>

-g removed

-g provided debugging information. So remove it and you get fewer headers, your file size gets a little smaller, and it should compile a little quicker. The size goes down from 9592 bytes to 8560 bytes. The run time goes down from 0m0.113s to  0m0.053s. So it’s not a huge difference, but if you don’t need to debug, I guess -g is unnecessary.

Additional arguments added to the printf() function

Arguments were added like below.

#include <stdio.h>

int main() {
int a = 0;
int b = 1;
int c = 2;
int d = 3;
int e = 4;
int f = 5;
int g = 6;
int h = 7;
int i = 8;
int j = 9;
printf(“Hello World! %i %i %i %i %i %i %i %i %i %i \n”, a, b, c, d, e, f, g, h, i, j);

There’s supposed to be a pattern in which register each argument is placed in. But I haven’t figured it out yet. I’ll come back with an edit on this one;) If you figure it out, let me know.

Moved printf() call to a seperate function named output()

Here’s the new code.

#include <stdio.h>

void output(char str[] ){
printf(“%s”, str);
int main() {
char c[50] = “Hello World!\n”;

The purpose of rewriting it this way was to see what the changes were in the object code. Essentially output() got its own section and could be seen being called from the main section.

Replace -O0 with -O3

I swear I’ll stop boring you. The last compiler option tested was to see how -O0 and -O3 differentiated. -O0 (the default if no -O is specified) means don’t optimize at all. The compiler time should be faster with -O0 since it has no optimizing to do. -O3 is the highest and most aggressive level of optimization turning on a big group of optimization options. The compilation time will be increased and more memory might be used, but performance should increase as well.







by James at October 08, 2015 01:30 AM

October 06, 2015

Joel Aro

GCC Optimization: -funroll-loops

According to the GCC Optimize Options documentation, -funroll-loops can be defined by: Unroll loops whose number of iterations can be determined at compile time or upon entry to the loop. -funroll-loops implies -frerun-cse-after-loop. It also turns on complete loop peeling (i.e. complete removal of loops with small constant number of iterations). This option makes code larger, and may or may not make it run faster.

To simplify it, here’s a basic for loop that does a simple task:

for(i = 0; i <= 10000; i++) {
    n += 5;
    printf("%d\n", n);

If we compile this code under optimization level 2 or higher we will see the following in objdump:

004082e0 <_main>:
#include <stdio.h>

int main()
  4082e0:	55                   	push   %ebp
  4082e1:	89 e5                	mov    %esp,%ebp
  4082e3:	53                   	push   %ebx
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
		n += 5;
  4082e4:	bb 0a 00 00 00       	mov    $0xa,%ebx
#include <stdio.h>

int main()
  4082e9:	83 e4 f0             	and    $0xfffffff0,%esp
  4082ec:	83 ec 10             	sub    $0x10,%esp
  4082ef:	e8 7c 99 ff ff       	call   401c70 <___main>
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
		n += 5;
		printf("%d\n", n);
  4082f4:	c7 44 24 04 0a 00 00 	movl   $0xa,0x4(%esp)
  4082fb:	00 
  4082fc:	c7 04 24 64 a0 40 00 	movl   $0x40a064,(%esp)
  408303:	e8 f8 fb ff ff       	call   407f00 <_printf>
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
		n += 5;
  408308:	8d 43 05             	lea    0x5(%ebx),%eax
		printf("%d\n", n);
  40830b:	89 44 24 04          	mov    %eax,0x4(%esp)
  40830f:	c7 04 24 64 a0 40 00 	movl   $0x40a064,(%esp)
  408316:	e8 e5 fb ff ff       	call   407f00 <_printf>
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
		n += 5;
  40831b:	8d 53 0a             	lea    0xa(%ebx),%edx
		printf("%d\n", n);
  40831e:	89 54 24 04          	mov    %edx,0x4(%esp)
  408322:	c7 04 24 64 a0 40 00 	movl   $0x40a064,(%esp)
  408329:	e8 d2 fb ff ff       	call   407f00 <_printf>
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
		n += 5;
  40832e:	8d 4b 0f             	lea    0xf(%ebx),%ecx
		printf("%d\n", n);
  408331:	89 4c 24 04          	mov    %ecx,0x4(%esp)
  408335:	c7 04 24 64 a0 40 00 	movl   $0x40a064,(%esp)
  40833c:	e8 bf fb ff ff       	call   407f00 <_printf>
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
		n += 5;
  408341:	8d 43 14             	lea    0x14(%ebx),%eax
		printf("%d\n", n);
  408344:	89 44 24 04          	mov    %eax,0x4(%esp)
  408348:	c7 04 24 64 a0 40 00 	movl   $0x40a064,(%esp)
  40834f:	e8 ac fb ff ff       	call   407f00 <_printf>
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
		n += 5;
  408354:	8d 53 19             	lea    0x19(%ebx),%edx
		printf("%d\n", n);
  408357:	89 54 24 04          	mov    %edx,0x4(%esp)
  40835b:	c7 04 24 64 a0 40 00 	movl   $0x40a064,(%esp)
  408362:	e8 99 fb ff ff       	call   407f00 <_printf>
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
		n += 5;
  408367:	8d 4b 1e             	lea    0x1e(%ebx),%ecx
		printf("%d\n", n);
  40836a:	89 4c 24 04          	mov    %ecx,0x4(%esp)
  40836e:	c7 04 24 64 a0 40 00 	movl   $0x40a064,(%esp)
  408375:	e8 86 fb ff ff       	call   407f00 <_printf>
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
		n += 5;
  40837a:	8d 43 23             	lea    0x23(%ebx),%eax
  40837d:	83 c3 28             	add    $0x28,%ebx
		printf("%d\n", n);
  408380:	89 44 24 04          	mov    %eax,0x4(%esp)
  408384:	c7 04 24 64 a0 40 00 	movl   $0x40a064,(%esp)
  40838b:	e8 70 fb ff ff       	call   407f00 <_printf>
  408390:	89 5c 24 04          	mov    %ebx,0x4(%esp)
  408394:	c7 04 24 64 a0 40 00 	movl   $0x40a064,(%esp)
  40839b:	e8 60 fb ff ff       	call   407f00 <_printf>
int main()
	int i;
	int n = 5;
	for(i = 0; i <= 10000; i++) {
  4083a0:	81 fb 5a c3 00 00    	cmp    $0xc35a,%ebx
  4083a6:	0f 85 5c ff ff ff    	jne    408308 <_main+0x28>
		n += 5;
		printf("%d\n", n);
	return 0;
  4083ac:	31 c0                	xor    %eax,%eax
  4083ae:	8b 5d fc             	mov    -0x4(%ebp),%ebx
  4083b1:	c9                   	leave  
  4083b2:	c3                   	ret    
  4083b3:	90                   	nop
  4083b4:	90                   	nop
  4083b5:	90                   	nop
  4083b6:	90                   	nop
  4083b7:	90                   	nop
  4083b8:	90                   	nop
  4083b9:	90                   	nop
  4083ba:	90                   	nop
  4083bb:	90                   	nop
  4083bc:	90                   	nop
  4083bd:	90                   	nop
  4083be:	90                   	nop
  4083bf:	90                   	nop

What is happening above is that the compiler is unrolling the loop. Which means that instead of iterating through the loop and doing a block of code each time, the compiler takes the process and repeats it a few times in each iteration. This means that each iteration now has multiple lines of the same process inside it.

To benefit from this option being enabled, there must be a few factors that have to be true:

  • The number of iterations of the loop must be determined at compile-time.
  • The process inside each iteration is a small enough to be repeated a few times without any impact on speed.
  • When compiling the program, use optimization level 2 and up.

Difference in Binary Size
In terms of the size of the binaries with the option on and the option off, the binary with the option on had a larger binary size. This is because of the extra lines that the loop unrolling produces.

Difference in Code Readability
There is no difference in source code, but when comparing the binaries, the binary with the option enabled is much more messier.

Dangers of -funroll-loops
The problem with loop unrolling is that if the [1]loop body is large, the loop overhead control is trivial, and the extra code to unroll a loop is large, it can cause cache misses.

If you have a loop with a large code body, disable -funroll-loops. You won’t notice any improvement. It will only show an improvement if the code body is small, and if the loop header is simple.


  1. In which scenario would unroll loops not making result code faster

by joelaro at October 06, 2015 06:28 PM

October 05, 2015

Kirill Lepetinskiy

Looking at C compiler optimizations

Let's look at a simple program and how various optimization options of the C compiler affect the output.
Here's our victim:
#include <stdio .h>

int main()
printf("Hello World!\n");
We'll compile our baseline version like so:
gcc l0.c -o l0 -g -O0 -fno-builtin
These compiler options provide a version of the program that include debug information for the user (-g), turn off the majority of optimizations (-O0, that's "capital oh zero"), and turns off optimizations for the built in C functions like printf. All of this results in an untouched version of the code that we can compare the other options against.
  1. -static 
    I had originally started this lab on the matrix server and couldn't get the -static switch to work, something about "cannot find -lc". This turns out to mean that the static C library (glibc-static) isn't installed on the machine. Oops. I moved over to aarchie and it worked just fine.
    This option disables the usage of shared libraries by your program. This means that all needed code will be included in the executable verbatim. The advantages of this operation is speed, as dynamic linking involves a performance hit at run time. Additionally it may be beneficial to ship a program that is fully independent of any outside libraries, potentially making it more stable.
    The downside is increased executable size. The hello world example went from 9KB to over 600KB. It should be noted that this size penalty will remain constant, meaning that as your program becomes larger, the size increase will become a less and less significant portion of the total. One more disadvantage is that the program will not benefit from any updates to shared libraries, fixing possibly catastrophic bugs (remember heartbleed?), but it all depends on your application.

  2. Remove -fno-builtin
    This option disables optimizations for some built in functions such as printf.
    For example, the call to printf where you print a string that ends with a newline will be replaced with a call to puts, which does exactly that but is lighter than printf. A call to printf while printing a string of one character will likewise be replaced with putchar. These optimizations come at essentially no run-time cost, so the only reason to turn them off would for debugging, since the calls in the machine code will not be shuffled around or replaced by the compiler.

  3. Remove -g
    Turning on the -g option includes debug information in the executable so that it can be debugged with GDB or other tools such as objdump. Disabling the option reduced the size from 9KB to 8KB. While that's not a huge increase, the real cost is the loss of performance when the debug info is included. Only enable this option when you need to debug.

  4. Give printf some parameters
    The following lines appear before the call to printf
      4005e0:       52800181        mov     w1, #0xc                        // #12
      4005e4:       52800442        mov     w2, #0x22                       // #34
      4005e8:       97ffff9e        bl      400460 <printf@plt>
    Debug information helpfully includes comments with the constants that I added as parameters, 12 and 34. The calling of the printf function looks identical, but it looks like populating the appropriate registers is enough for it to figure things out.

  5. Move printf to a new function
    This one is pretty straightforward. The function I wrote can be seen in its own section and it is called from main.

  6. Change -O0 to -O3
    Two instructions that were usually at the top stp and mov are now missing. The more interesting change is what happened to the call to printf. In the original, the bl instruction was used to call it, then coming back to main and returning from there. In the -O3 version the b instruction is used to simply jump into printf, so that we go back straight to the operating system when printf returns. Neat!

by Kirill ( at October 05, 2015 04:00 AM

Joseph Jaku

Compiler Optimization Options

The two GCC optimization options I chose to present last week in SPO600 are -fdce and -fcse-skip-blocks.


This option will be enabled with any –O optimizations.
DCE is as simple as it sounds. This optimization traverses through the code and removes lines that are not needed. For example an unused variable or a piece of code that is unreachable.
This optimization will save memory be deleting variables that are never used and save time by ignoring lines of code.

int main() {

        const int a = 20;
        const int b = 30;
        const int c = 40;

        if (a < b) printf ("Yes!\n");
        if (c < a) printf ("Yes!\n");


In this example the second if statement would never be true and therefore unreachable. This would consider it dead code and would be removed be this option.


This option will be enables at –O2, -O3, and –Os.
CSE or common sub-expression elimination parses the code for common expressions and if possible will combine the common expressions. (into a new variable for example)

a = b * c + g;
d = b * c * e;

tmp = b * c;
a = tmp + g;
d = tmp * e;

If this option is enabled when the CSE scan through the code is performed, it will bypass the interior of a conditional statement when it fails. This will speed up processing time by skipping unnecessary calculations.

if (b < 10) {
else if (b > 10) {


if (b < 10) {
else bar();

Because the compiler knows that if b is not less than 10, it is definitely more, so it has no reason to check this condition each time the code is run. It can simply erase the second if and just let the alternate option run.

by Joseph J ( at October 05, 2015 02:24 AM

Compiled C Lab

In class we were tasked as a group to choose one of the following variations from the original compilation below and to present our findings. Here is the breakdown of all six variations and the original.

The code we compiled is as simple as it gets, a Hello World app in C. We'll be working on the Xerxes x64_86 server.

#include <stdio.h>

int main() {
    printf("Hello World!\n");

This was the original compilation command used. 

gcc -g -O0 -fno-builtin -o original hello.c

-rwxr-xr-x 1 jjaku jjaku  9875 Oct  2 15:55 original

08048404 <main>:
#include <stdio.h>
objdump -f -s -d --source original | less

int main() {
 8048404:       55                      push   %ebp
 8048405:       89 e5                   mov    %esp,%ebp
 8048407:       83 e4 f0                and    $0xfffffff0,%esp
 804840a:       83 ec 10                sub    $0x10,%esp
        printf ("Hello World!\n");
 804840d:       b8 f0 84 04 08          mov    $0x80484f0,%eax
 8048412:       89 04 24                mov    %eax,(%esp)
 8048415:       e8 22 ff ff ff          call   804833c <printf@plt>

 804841a:       c9                      leave
 804841b:       c3                      ret
 804841c:       90                      nop
 804841d:       90                      nop
 804841e:       90                      nop
 804841f:       90                      nop

(1) Add the compiler option -static. Note and explain the change in size, section headers, 
and the function call.

gcc -g -O0 -fno-builtin -o static -static hello.c

-rwxrwxr-x. 1 jjaku jjaku   9521 Oct  4 20:00 original
-rwxrwxr-x. 1 jjaku jjaku 823978 Oct  4 20:04 static

objdump -f -s -d --source static | less

0000000000400b5e <main>:
#include <stdio.h>

int main() {
  400b5e:       55                      push   %rbp
  400b5f:       48 89 e5                mov    %rsp,%rbp
    printf("Hello World!\n");
  400b62:       bf 90 03 49 00          mov    $0x490390,%edi
  400b67:       b8 00 00 00 00          mov    $0x0,%eax
  400b6c:       e8 0f 0b 00 00          callq  401680 <_IO_printf>
  400b71:       5d                      pop    %rbp
  400b72:       c3                      retq
  400b73:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  400b7a:       00 00 00
  400b7d:       0f 1f 00                nopl   (%rax)

When compiling using the -static option, the first thing you notice is that the file is enormous compared to the original. This is because the option -static includes libraries in the binaries rather using the system dynamic libraries at run-time. You can see when printf is called it is called from IO rather than plt.

(2) Remove the compiler option -fno-builtin. Note and explain the change in the function call.

gcc -g -O0 -o builtin hello.c

-rwxrwxr-x. 1 jjaku jjaku   9511 Oct  4 20:15 builtin
-rwxrwxr-x. 1 jjaku jjaku   9521 Oct  4 20:00 original

objdump -f -s -d --source builtin | less

0000000000400536 <main>:
#include <stdio.h>

int main() {
  400536:       55                      push   %rbp
  400537:       48 89 e5                mov    %rsp,%rbp
    printf("Hello World!\n");
  40053a:       bf e0 05 40 00          mov    $0x4005e0,%edi
  40053f:       e8 cc fe ff ff          callq  400410 <puts@plt>
  400544:       5d                      pop    %rbp
  400545:       c3                      retq
  400546:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)

  40054d:       00 00 00

The -fno-builtin option shuts off the built in optimizations performed by GCC. By removing this option you are turning on these optimizations. In the case of our code you can see that it replaced "printf" with "puts". GCC determined that printf would not be necessary in our program and replaced it with the cheaper puts. 

(3) Remove the compiler option -g. Note and explain the change in size, section headers, and disassembly output.

gcc -O0 -fno-builtin -o nog hello.c

-rwxrwxr-x. 1 jjaku jjaku   8505 Oct  4 20:21 nog
-rwxrwxr-x. 1 jjaku jjaku   9521 Oct  4 20:00 original

objdump -f -s -d --source nog | less

0000000000400536 <main>:
  400536:       55                      push   %rbp
  400537:       48 89 e5                mov    %rsp,%rbp
  40053a:       bf e0 05 40 00          mov    $0x4005e0,%edi
  40053f:       b8 00 00 00 00          mov    $0x0,%eax
  400544:       e8 c7 fe ff ff          callq  400410 <printf@plt>
  400549:       5d                      pop    %rbp
  40054a:       c3                      retq
  40054b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)

The -g option tells the compiler to generate debugging information. Because this option was turned off, you can see that the file size has shrunk a bit from the original because there is no debugging information. You can also see that the main section contains a bit less info including no source code even though objdump was run with the --source option.

(4) Add additional arguments to the printf() function in your program. Note which register each argument is placed in. (Tip: Use sequential integer arguments after the first string argument. Go up to 10 arguments and note the pattern).

int main() {

    printf("Hello World! %d %d %d %d %d %d %d %d %d %d\n", 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13);


gcc  -g -o0 -fno-builtin -o addarg hello1.c

-rwxrwxr-x. 1 jjaku jjaku   9522 Oct  4 20:38 addarg
-rwxrwxr-x. 1 jjaku jjaku   9521 Oct  4 20:00 original

0000000000400536 <main>:
#include <stdio.h>

int main() {
  400536:       55                      push   %rbp
  400537:       48 89 e5                mov    %rsp,%rbp

    printf("Hello World! %d %d %d %d %d %d %d %d %d %d\n", 1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
  40053a:       48 83 ec 08             sub    $0x8,%rsp
  40053e:       6a 0a                   pushq  $0xa
  400540:       6a 09                   pushq  $0x9
  400542:       6a 08                   pushq  $0x8
  400544:       6a 07                   pushq  $0x7
  400546:       6a 06                   pushq  $0x6
  400548:       41 b9 05 00 00 00       mov    $0x5,%r9d
  40054e:       41 b8 04 00 00 00       mov    $0x4,%r8d
  400554:       b9 03 00 00 00          mov    $0x3,%ecx
  400559:       ba 02 00 00 00          mov    $0x2,%edx
  40055e:       be 01 00 00 00          mov    $0x1,%esi
  400563:       bf 10 06 40 00          mov    $0x400610,%edi
  400568:       b8 00 00 00 00          mov    $0x0,%eax
  40056d:       e8 9e fe ff ff          callq  400410 <printf@plt>
  400572:       48 83 c4 30             add    $0x30,%rsp
  400576:       c9                      leaveq
  400577:       c3                      retq
  400578:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
  40057f:       00

When we add arguments to our printf function they need to be stored in registers. The first 5 integers are assigned using mov to their respective registers, 0x1, 0x2, etc. The next 5 are stored using pushq into their registers as well. 

(5) Move the printf() call to a separate function named output(), and call that function from main(). Explain the changes in the object code.

#include <stdio.h>

void output(){
        printf ("Hello World!\n");
int main() {

gcc -g -O0 -fno-builtin -o function hello2.c

-rwxrwxr-x. 1 jjaku jjaku   9617 Oct  4 20:45 function
-rwxrwxr-x. 1 jjaku jjaku   9521 Oct  4 20:00 original

0000000000400536 <output>:
#include <stdio.h>

void output(){
  400536:       55                      push   %rbp
  400537:       48 89 e5                mov    %rsp,%rbp
        printf ("Hello World!\n");
  40053a:       bf f0 05 40 00          mov    $0x4005f0,%edi
  40053f:       b8 00 00 00 00          mov    $0x0,%eax
  400544:       e8 c7 fe ff ff          callq  400410 <printf@plt>
  400549:       5d                      pop    %rbp
  40054a:       c3                      retq

000000000040054b <main>:
int main() {
  40054b:       55                      push   %rbp
  40054c:       48 89 e5                mov    %rsp,%rbp
  40054f:       b8 00 00 00 00          mov    $0x0,%eax
  400554:       e8 dd ff ff ff          callq  400536 <output>
  400559:       5d                      pop    %rbp
  40055a:       c3                      retq
  40055b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)

By putting our printf in a separate function and calling it you can see that there is a new section in the compiled code. Where before, it would call the printf function it now calls the output function in the same manner. When you look at the section of code containing the new function you can see that it looks very similar to the printf called in our original code.

(6) Remove -O0 and add -O3 to the gcc options. Note and explain the difference in the compiled code.

gcc -g -O3 -fno-builtin -o opti3 hello.c

-rwxrwxr-x. 1 jjaku jjaku  10961 Oct  4 20:47 opti3

-rwxrwxr-x. 1 jjaku jjaku   9521 Oct  4 20:00 original

0000000000400440 <main>:
#include <stdio.h>

int main() {
    printf("Hello World!\n");
  400440:       bf e0 05 40 00          mov    $0x4005e0,%edi
  400445:       31 c0                   xor    %eax,%eax

  400447:       e9 c4 ff ff ff          jmpq   400410 <printf@plt>

The option -O3 is used to create a code that is fast, using optimizations meant for speed and not efficiency. We can see this in increased comp time (not so much in this case) and a larger file size. One example of this option I found was that it would simply drop the main function after printf was called rather than closing it like in the original.

by Joseph J ( at October 05, 2015 01:28 AM

October 04, 2015

Gaurav Patel

Compiler Options

A few weeks ago, we learn about gcc compiler and few of it's options, using these options your compiler will change/move your code around to make your code for better performance. I'm going to discuss about GCC compiler options which I researched on for my presentation for my Software Portability and Optimization course.

-ftree-dce is one of the option which I've chose for my research. -ftree-dce performs dead code elimination (DCE) on trees. This flag is enabled by default at -O and higher.

int main(){
    int t = 5 + 5; //dead code
    int r = 3 + 3;
    printf(“Result is %d”, r);

In this example variable ‘t’ is considered a dead variable because it takes result of two numbers but the value of ‘t’ is never used. It isn't going to affect the final result so, calculating 5 + 5 and assigning the result to a variable will consume resources and space for something that can be avoided. Dead Code Elimination checks for conditions that will never be true and unnecessary calculations on variables which are not affecting the final result and it will remove that block of code before it converts the code into machine language which will provide better performance in your program by eliminating steps that are unnecessary.

Hence compiler option is enabled by default at -O level, so the dead code elimination option is always in use, unless you compile with –fno-tree-dce but still there are other similar options which eliminates dead code.
These are: -fdump-rtl-dce, -fdump-rtl-dce1, -fdump-rtl-dce2 and –ftree-builtin-call-dce which gives warning on unused variables it's default enabled at -O2  

-fmove-loop-invariants is another compiler option which I've chose for my research. -fmove-loop-invariants enables the loop invariant motion pass in the RTL loop optimizer and its enabled at level -O1. Its purpose is to find any value or expression that remains the same on all iterations of the loop. By substituting out the expressions which are unchanged on all iteration the computer will have less number of operations to perform then original.


Loop invariants transform following code:
             for (int i = 0; i < n; i++) {    
                   x = y + z;
                   array[i] = 6 * i + x * x;
              Int x = y + z;
              Int t = x * x;

              for (int i = 0; i < n; i++){ 
                    array[i] = 6 * i + t;
Let's calculate number of operation in each code if n is 10. For untransformed code it will be 10 iterations * (2 for x=y+z + 4 for array[i] = 6 * i + x * x ) which is 60 operations and if we look at transformed code it will be 4 for code before loop + 10 iterations * (3 for array[i] = 6 * i + t) which is 34 operations. So, in small code as this we have almost half the number of difference and which means less processing for computer and you could have better performing applications.

by Gaurav ( at October 04, 2015 10:11 PM

SPO600 Lab 2 - Examining compiler options

SPO600 - Lab 2

Modifying C program and compiling the program with gcc options and examining the output. Link to Lab is: SPO600_Compiled_C_Lab. Everything shown in this page has been ran on aarchie 64 machine.

Simple C - hello world program.

int main(){
    printf("Hello World!");

Compiling Using: gcc -g -O0 -fno-builtin hello.c
Examining Executable File Using:
objdump -f -s -d --source (executable filename)
Executable File Size: 9569 bytes

1. Add the compiler option -static. Note and explain the change in size, section headers, and the function call.
Executable File Size: 681707 bytes

Using the objdump command to determine changes gcc compiler did using -static option tell us that there was no changes made on how the main function is going to run, it just prevented linking with shared gcc libraries. This makes compiler copy all required information from gcc libraries to the executable file.

2. Remove the compiler option -fno-builtin. Note and explain the change in the function call.

Executable File Size: 9182 bytes

One small changed has been made in executable file, In original executable the printf() function is called to print
the line/it makes a one line function results in smaller and faster code but without -fno-builtin option the printf()
is using puts@plt option it puts printf() function on stack so it will be called later.

3. Remove the compiler option -g. Note and explain the change in size, section headers, and disassembly output.
Executable File Size: 8192 bytes

The executable file doesn't contain information on what each line does in main function, -g option adds debuggig information
to the executable file.

4. Add additional arguments to the printf() function in your program. Note which register each argument is placed in.

Executable File Size: 9456 bytes

Modified print line: printf("Helo World! %d, %d, %d, %d, %s, %f, %f, %f, %f, %s\n", 10, 20, 30, 40, "fifty", 59.99, 69.99, 79.99, 89.99, "Hundred");
I added multiple intergers, floats and strings arguments to printf funtion and the compiler uses ldr to create floating variables and fmove
pushes stores these variable into memory and adrp makes a string variables and add pushes/adds these varibles to memory.

5. Move the printf() call to a separate function named output(), and call that function from main(). Explain the changes in the object code.

Executable File Size: 9359 bytes

The executable file has few steps which is doing the same thing in both function like: stp and mov steps after function calls and
ldp and ret after function closing. Two bl (callq) are being made one to output function from main and then another to printf function
from output function these extras and repeting steps are made, for this scenario the function calls are too many then actucal task(printf) thats why this is inefficient. Having an extra function adds more work to the program and it provides less performance.

6. Remove -O0 and add -O3 to the gcc options. Note and explain the difference in the compiled code.

Executable File Size: 10616 bytes

The main function doesn't have the steps stp, mov, ldp and ret for main function because in main function is calling printf function and nothing else so the compiler doesn't save information about main function. Before it use to make callq to printf function and then comes back to main functions to finish its steps but now it just jumps to printf function and doesn't come back to make closing statements on main like ldp and ret because there isn't anything other then printf function so the return from printf function will go to operating system rather then going back to main function and main function returning to operating system. Option -O3 is optimized for program speed over memory space, the compiler will apply all optimiations to make it's speed better without worrying about memory space.

by Gaurav ( at October 04, 2015 07:18 PM

October 03, 2015

Andrew Smith

OSTD: an experiment that didn’t work

There are plenty of people in our industry (software development) who advise to fail early and fail often. This is a story of such a project.

The OSTD is a really cool idea: get free translations, or at least get started on them. I never pushed it too hard but I developed it to the point where the fundamental features worked. And I waited to see if anyone would use it. As far as I know almost noone did.

Eventually I translated two of my own relatively popular open source apps using the OSTD hoping that when people see there is a 10% complete translation in their language – that will encourage them to fix it up, making them a contributor to my project. That didn’t happen either. You can see the red lines for Asunder and ISO Master.

Like so many others I sometimes preach fail early and often, and I’m glad I practice it as well. Even knowing that failure is a required part of the process of developing great things – it’s still annoying. Especially when you don’t understand what the problem is. Oh well, writing this post was my way to vent.

The OSTD has failed, I am finally admitting it to myself and to everyone else :)

by Andrew Smith at October 03, 2015 04:15 AM

David Humphrey

How to become a Fool Stack Programmer

At least once in your career as a programmer, and hopefully more than once and with deliberate regularity, it is important to leave the comfort of your usual place along the stack and travel up or down it. While you usually fix bugs and add features using a particular application, tool, or API and work on top of some platform, SDK, or operating system, this time you choose to climb down a wrung and work below. In doing so you are working on instead of with something.

There are a number of important outcomes of changing levels. First, what you previously took for granted, and simply used as such, suddenly comes into view as a thing unto itself. This layer that you've been standing on, the one that felt so turns out to have also have been built, just like the things you build from above! It sounds obvious, but in my experience, the effect it has on your approach from this point forward is drastically changed. Second, and very much related to the first, your likelihood to lash out when you encounter bugs or performance and implementation issues gets abated. You gain empathy and understanding.

If all you ever do is use an implementation, tool, or API, and never build or maintain one, it's easy to take them for granted, and speak about them in detached ways: Why would anyone do it this way? Why is this so slow? Why won't they fix this bug after 12 years! And then, Why are they so stupid as to have done this thing?

Now, the same works in the other direction, too. Even though there are more people operating at the higher level and therefore need to descend to do what I'm talking about, those underneath must also venture above ground. If all you've ever done is implement things, and never gone and used such implementations to build real things, you're just as guilty, and equally, if not more likely to snipe and complain about people above you, who clearly don't understand how things really work. It's tantalizingly easy to dismiss people who haven't worked at your level: it's absolutely true that most of them don't understand your work or point of view. The way around this problem is not to wait and hope that they will come to understand you, but to go yourself, and understand them.

Twitter, HN, reddit, etc. are full of people at both levels making generalizations, lobbing frustration and anger at one another, and assuming that their level is the only one that actually matters (or exists). Fixing this problem globally will never happen; but you can do something at the personal level.

None of us enjoys looking foolish or revealing our own ignorance. And one of the best ways to avoid both is to only work on what we know. What I'm suggesting is that you purposefully move up or down the stack and work on code, and with tools, people, and processes that you don't know. I'm suggesting that you become a Fool, at least in so far as you allow yourself to be humbled by this other world, with its new terminology, constraints, and problems. By doing this you will find that your ability to so easily dismiss the problems of the other level will be greatly reduced. Their problems will become your problems, and their concerns your concerns. You will know that you've correctly done what I'm suggesting when you start noticing yourself referring to "our bug" and "how we do this" instead of "their" and "they."

Becoming a Fool Stack Programmer is not about becoming an expert at every level of the stack. Rather, its goal is to erase the boundary between the levels such that you can reach up or down in order to offer help, even if that help is only to offer a kind word of encouragement when the problem is particularly hard: these are our problems, after all.

I'm grateful to this guy who first taught me this lesson, and encouraged me to always keep moving up the stack.

by David Humphrey at October 03, 2015 01:04 AM

October 02, 2015

Justin Flowers

Designing a Fault Injection Framework

Over at CDOT we have another phase of the log centralization project that involves producing a fault injection framework. This framework should be:

  1. Modular, such that different faults and fault cases can be applied simply
  2. Cross platform, such that this framework can be run from Windows or Linux
  3. Easy to use
  4. Allow programmatic definition of tests
  5. Allow non-programmatic definition of tests

Approaching this problem, we decided to take the ideas of test suites and test cases from the various Unit testing frameworks. We took the idea of a test case and made a fault case, which would be a combination of faults applied at once. From there we expanded outward and made fault suites, which would be combinations of test cases with different settings. This setup would allow for modularity in the individual test cases themselves and in running them together as one suite.

To approach the problem of having multiple types of fault, we decided to use a plugin system. Using the template design pattern would allow us to define how to inject a fault and how to check if the fault was successfully injected. With this common definition of how a plugin operated, not only could we create many different types of fault plugins easily, but others as well. Then, test cases would simply need to be combinations of plugin calls.

We additionally had two different kinds of fault cases: faults that applied to a single node (server) and faults that applied to multiple. To achieve this we decided to have two different types of plugins: single and multi-node. The difference between the two would be that single node plugins take in, you guessed it, information about a single node, while multi-nodes would take in information about more than one.

The overall design of our system would apply the template method generously to allow the user to define:

  • How a plugin would inject faults
  • What plugins a test case should define
  • What test cases should be part of a suite

This setup would also allow for  the automated production of test cases and suites with definitions of the nodes and their relationships, which I will be writing about in the next post.


by justin at October 02, 2015 10:59 PM

Dmytro Yegorov

How so-called a.out depends on gcc options.

As we all know, computers do not understand what “printf (“Hello world!”)” is. In order for us to get expected result, we need to translate our code into the language that computer can understand. This can be done, just like with translating any human languages, by using “dictionaries” – compilers. One of the compilers we played with was gcc.

So how exactly our code will be translated into pc’s language? Just like with human languages, it can be done in many ways – you can say one thing in many ways (e.g. “How are you?”, “What is up?”, “How’re you doing?”). Even though the meaning remains the same, the form is different. Same thing with gcc – using different options, you get same result (output), but in different forms.

Test 1 -static

With this option we got enormous increase in size – around 8.600%! As for man page, -static prevents linking with shared libraries, so my guess is that it links ALL available libraires – that is why our output file got so much bigger.
Using objdump, I noticed that we got way more sub-sections in <text>  section, such as backtrace and map, group_number etc. Our function got changed from printf@plt to _IO_printf. Also .rodata section got a lot bigger.

Test 2 remove -fno-built-in

With this option we save about 0.2% of space, which might not be that big with our program, but imagine if we have a 100GB program – 0.2% would be around 200MB, which is already something. printf@plt got changed to puts@plt. In this example it uses built-in function optimization, so it decided that using puts function is more efficient than using printf.

Test 3 remove -g (debug)

Around 10% less size!!! EFL file doesn’t have debug info, which explains why output file got smaller. On the other hand, now we do not have any “explanations” for sections in EFL file.

Test 4 add int parameters to printf

Our “data” for printf is now stored in registers. After adding 3 integers we saved 0.1% of space – we got more data that takes less space, which may sound weird, but now we tell printf of what data type our argumets are. It probably links less libraries that were used to determine what data type the arguments for printf are.
After adding more integers, I noticed a pattern:
first five are “mov *register*, 6-9 are “pushq $0x6 $0x7 etc”, 10+ are “pushq $xa $xb etc”

Test 5 put printf in separate function

Now we have separate declaration/section for the output function; in >main> we have less action/data. Some fields are replicating in main and output, such as “push %rbp; mov %rsp,%rbp” and closing registers – probably used to make an action stack 64bit long (my guess).
New file is 1.6% bigger than the original one – can say that all that duplicated data, such headers for functions, are worth this 1.5% in our case.

Test 6 -O3 (optimization lvl3)

15% less space! This is just huge! We got rid of headers/footers for our <main> function. With more complex program, we definitely would be able to see more changes.

by dyegorov at October 02, 2015 12:49 AM

Bugzilla? GitHub?

Few months ago I was talking to my friend and he showed me the bug in Mozilla and told me how that is that all the people using Mozilla will benefit from his small, but noticeable, fix. And now, as I’m taking SPO600, this Mozilla story “strikes back”. So how do you contribute to the Mozilla community?

After making some research on this, I found a page on Mozilla developers portal that actually describes this process step-by-step. Firstly, you have to install Mozilla, of course, (even though in order to fix some bugs, you don’t even need Mozilla, as “bugged” code is provided in a bug description – I found in pretty funny). After that, find a bug that you can fix on bugzilla – good choice for beginners would be bugs marked as “good for beginners”, or you can just search for the “beginner” key-word. You can look for bugs in all of Mozilla’s modules starting from Firefox and ending with Thunderbird or even their Marketplace.

So after you decided what you want to work on, and you got it done and working, you attach your patch/fix on the bug web-page and ask for review. However, it is not as simple as it looks – you have to find a reviewer ID first. Your options for finding the correct person are here. Of course, you have to follow it up, as the reviewer might ask for some additional info or you might have to change your code. As with any code, you will have to spend some time on fixing minor (or major) errors to make it perfect and to make it fit into the tree. This process goes on until you get an r+ from your reviewer (just like in school, eh?) – when you get it, it means that your code is ready to be implemented into the tree!

At the final step, your code will be tested on a try-server (your mentor will help you with that), and after it receives a green light, you just mark that your patch is ready to commit by adding “checkin-needed” keyword to the keywords of your bug (you can find it at the top of the page). Shortly your patch will be implemented into Mozilla! More detailed info can be found here and here.

Now let’s talk about another Open Source project and one of the most used OpenSource portals GitHub.


This digital currency-open source project is developed and released under MIT licence and “hosted” by GitHub. So how do we contribute to this project? Simple as one-two-three!

  1. Register on GitHub if you are not registered yet;
  2. Go to the Bitcoin section on GitHub
  3. Create you patch proposal and make a “pull request” at their page and upload your proposal.
  4. As with any project, you will have to wait for some time for people to review and approve your proposal. Meanwhile you can review proposals of other contributors.
  5. After your proposal got approved, project maintainers will merge the pull together and Project leader will O.K. your proposal.

The good thing about GitHub is that everyone can review everyone – it is pretty democratic portal. People can point out your mistakes or give you suggestions on how to make your code more efficient as well as you can be the one who reviews others code.

Which “method” of working in OpenSource is “better”? I would stick with GitHub, as you can work on many projects there as well as you are not depended on your “mentor”/reviewer – everyone can be this person, which fastens the contribution process and simplifies the work of project managers.

by dyegorov at October 02, 2015 12:11 AM

October 01, 2015

James Shin

Contributing to open source software packages

A little late to the game, but excited to begin!

This post will briefly speak of two open source software packages that anybody can contribute to and how it can be done.


The digital currency of the future – spawning hilarious, yet non-trivial branch-offs like dogecoin, is in fact open source. Released under the terms of the MIT license, Bitcoin, can be developed by anybody willing to contribute. Here’s how.

  1. Visit their GitHub repository. There, you can see all the development ideas and discussions taking place.
  2. To contribute a patch proposal, make a “pull request” abiding to the specified rules and guidelines.
  3. Wait for others to comment and review your proposal.
  4. (3.5?) While waiting, help review others’ pull requests. Also, sign up for the developer mailing list to discuss more complicated and controversial ideas.
  5. If thoroughly review and approved, project maintainers will merge the pull request.
  6. Finally, the project leader will O.K. each Bitcoin release.

And that’s it.

How hard is it to get a patch accepted? How long will it take? Well, that depends. Firstly, open source means contributors work on their own time. So review times can vary widely. Secondly, if the patch is very minor and simple, there probably won’t need to be much discussion. But if the patch is complicated and controversial, it will take much longer and require more reviews and reviewers.

In summary, Bitcoin’s GitHub method of contributing seems like a fairly democratic and organized way to open source and build software. One tiny kink may be that the project maintainers and leaders may have unequal power in what gets merged or not. But you need some kind of system. So…hopefully they are fair. And not stupid.


GIMP (GNU Image Manipulation Program), released under GNU GPLv3+ licence, does things quite a bit differently than Bitcoin. Although also open source, GIMP development is managed by a team of specific developers. Here is how to contribute patches to GIMP.

  1. Look through the bug reports in GNOME Bugzilla that you could work on.
  2. This step is important for GIMP. Contact the GIMP team first about the patch you want to make. Somebody else may already by working on the patch, or the idea may not be relevant to the direction of GIMP.
  3. Once approved, submit the bug report with the patch and appropriate documentation attached.
  4. The GIMP team will review then potentially merge the patch on their git server.
  5. Wait for further communication with the GIMP team.

So a much more behind-closed-doors approach for GIMP. More of a, “You give us some code. We’ll see if we like it” vibe. The disadvantages? Contributors have less control and sense of power if that’s what they want in open source. Some may value the greater openness used by the likes of Bitcoin. The advantages? GIMP’s development can be more focused and directed with a fewer number of people managing ideas of how things are run.

So which is preferable to contribute to? With my preliminary research, I wouldn’t be able to say. But it seems like preference at the end of the day. Personally, I’m liking Bitcoin’s way:)

by James at October 01, 2015 05:36 AM

Neil Guzman

Combinatorial Explosion in Fault Injection

As mentioned in the previous post, I will be going into more detail regarding the problem of generating cases when building a series of test cases to be used in our fault injection framework.

The problem is that we are generating way too many cases--which is kind of what we want because we want to go through every single possible combination of fault cases. Below are simple examples of how we generate cases.

Simple case: 2 nodes, 1 plugin:

Nodes: n1, n2
Plugins: p1

Combinations of Relationships:
n1 - n2

Combinations of Plugins that can apply to a single node at a time:
none, p1

Combinations of plugins applied to combinations of nodes:

Total: 4 cases (3 if excluding none:none)

Simple case: 2 nodes, 2 plugins:

Nodes: n1, n2
Plugins: p1, p2

Combinations of Relationships:
n1 - n2

Combinations of Plugins that can apply to a single node at a time:
none, p1, p2, (p1 & p2)

Combinations of plugins applied to combinations of nodes:
(p1 & p2):none
(p1 & p2):p1
(p1 & p2):p2
none:(p1 & p2)
p1:(p1 & p2)
p2:(p1 & p2)
(p1 & p2):(p1 & p2)

Total: 16 cases (15 if excluding none:none)

As you can see, the total number of cases increases exponentially the more plugins you add in from just simple cases. It gets even larger when increasing the nodes. For example, having 3 nodes that are connected to each other generates a combination of: (n1-n2, n1-n3, n2-n3). This is an example of Combinatorial Explosion. This is when the number of combinations grow exponentially.

Our total number of cases is equal to C^N, where C is the combination of plugins and N is the number of nodes. This only takes into consideration of node-to-node relationships, if each node has the same plugins available to them, and if the plugins only apply to 1 node.

To decrease the number of generated cases, we thought of Fault Collapsing. Because some cases are necessary (duplicates) or have obvious results (having all nodes being tested shut down), we would be able to decrease the total number of cases that should actually be run. So our next course of action would be to start implementing these rules to rule out the illegal combination of plugins and nodes.

by nbguzman at October 01, 2015 04:00 AM

James Shin

September 30, 2015

Jae Jo

How to Install Fedora22 Virtual Machine with VirtualBox

In this blog post, we will learn how to install Fedora22 Virtual Machine(VM) with VirtualBox.

First, please turn on the VirtualBox and Click “New”


Fill the Name of VM, OS Type and Version of OS.


Allocate the Memory

(Make sure to allocate enough memory. Recommend to allocate at least 4GB = 4096MB for smooth running VM).


Select “Create a virtual hard drive now”.


Select “VDI(Virtual Disk Image)”.

VDI: Native.

VMDK: Compatible with vmware.

HDD: Compatible with MAC parellels.

VHD: Compatible with VirtualPC and New Microsoft Products.


Select “Dynamically allocated”.

Dynamically Allocated: Expanding when it needs more space to perform(Efficient, but can cause the host operating system to become very fragmented).

Fixed: Reserve the fixed space from host(Faster, not efficient).


Allocate reasonable space of disk, so VM can perform faster.


VM configuration is done and new VM created.

Select the new VM and click start from VirtualBox WIndow.


Road Fedora22 ISO Image.



Select “Install to Hard Drive”.


Select preferred language settings and press “Continue”.


Press “Installation Destination”.


Turn on the “I will configure partitioning” radio button then press “Done”.


Use “+” button to add up all the partitions.

/boot – 500MB: Partition where all the bootstrap process is happening, and contains OS kernel and system booting files.

/{root} – 10GB(Min 5GB): Partition where the root directory is located, and contains the system data.

/home – 10GB(Min 10GB): Partition where user data will be stored.

swap: Partition where support virtual memory.

(Double if allocated memory is less than 2GB.

Equal if allocated memory is more than 2GB and less than 8GB.

Half if allocated memory is more than 8GB.)

More Detail:

Press “Done”.


Press “Accept Changes”.


Press “Begin Installation”.


While installing, please setup the “ROOT PASSWORD” and “USER CREATION”.





Press “Quit” after installation is completed.


You have successfully installed Fedora22 into your VM.

However, you are currently using Fedora as Live mode right now.

To be able to launch complete version of Fedora,

you need to unmount Fedora22 ISO Image.


To unmount Fedora ISO image,

perform next procedures from the top toolbar.

“Devices” > “CD/DVD Devices” > “Remove disk from virtual drive”


Confirmation window will pop up and just press “Force Unmount” to confirm unmount.


Restart VM.






Congratulation! You have successfully Installed Fedora VIrtual Machine with VirtualBox.

by jae910108 at September 30, 2015 06:46 PM

Joel Aro

Open Source & Contributing to Mumble

mumblelogoMumble’s logo

Mumble is an open source voice over IP(VOIP for short) program that allows people to talk to each other over the internet. Supporting features such as [1]low latency, high quality audio, overlays, positional audio, server administration, and scriptability, it is a popular piece of software that is most commonly used among the gaming commmunity. Mumble is licensed with the [2]BSD License, specifically the 3-clause license which is considered the “modified BSD license”. This license can be simplified to redistribution and modifications to this software are allowed as long as the following 3 conditions are met:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  3. Neither the name of the Mumble Developers nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

How to Contribute
The project is very well documented by the community, and almost everything you could ever ask can be found at Mumble’s wiki page. Also on that wiki page you can find information about How to contribute.

Unlike GIMP, Mumble does not have a fixed bug tracker. According to the wiki, the project uses GitHub for issue tracking and Sourceforge for suggesting new features. Since the topic is about bug fixing and not suggesting features, we’ll focus on their bug tracker.

GitHub’s bug tracker system works the same way as Bugzilla’s system, users can open issues and the community can work together to develop a fix. While also being very pretty to look at, with it’s clean interface, it works very nicely with the open source projects themselves, since there are a lot of projects being hosting on GitHub.

Bug Tracking
Similar to how I did my post on GIMP, I will now follow one of the patches from start to finish in an attempt to show what the process is like.

I will be tracking Issue #1271.

1. Opening an issue
An issue can be opened by any user with a GitHub account. The issue will be assigned an issue number(in this case 1271) and given a title that briefly describes the problem decided by the user reporting the issue.

In their opening post, they will try to give as much detail about the issue as possible. The user will then choose a milestone that this issue will be aiming for and also add tags that the issue can be associated with to allow other bug trackers to help find it. The user also self-assigns themselves to the issue. Self-assigning is a way of finding out who is working on a fix for the particular issue.

In our case, user mkrautz opened a issue regarding Skype’s click-to-call certificates interfering with Mumble. They described the problem in detail and even added a link that might help the people working on the fix. They also submitted a possible solution, along with a milestone that they want to target.

2. Community Involvement
After the opening post, the community will begin work on trying to get a fix. They will post their environments where the issue can be found, possible solutions, questions, etc. anything that will help progress the issue.

The user the-hive joins in this issue and suggests a revised version of mkrautz code, but unfortunately it does not solve the problem.

3. Back and Forth
The community responds to other users hoping to narrow down the problem. This may go on for a while until the issue is resolved.

In our case, since there is only two users working on the issue, it doesn’t take long for a patch to be committed.

4. Committing a Patch
GitHub has a different procedure than Bugzilla in terms of how they approve of patches. In Bugzilla, you attach the files related to the fix and wait for a user with commit permissions to review it before it can be committed. In GitHub, you can simply link you commit id of your solution in the post body, and then await approval from one of the users with commit permissions. GitHub is much easier for users to test submissions, because since you can fork repositories and work on your own version of the project you can simply add a possible solution to your version. Once someone with commit permissions approves of the solution, they will commit it to the project.

This was a pretty small issue, and only required 2 users to find a fix. Fortunately, the user reporting the issue also has commit permissions, and was able to commit to master (aef3509).

In Summary
Both Bugzilla and GitHub’s bug/issue tracker systems are great. They allow an easy way for the community to contribute to a project. GitHub’s system allows seamless integration with open source projects, and allows easy linking of commit ids. When using GitHub though, you would need to have a firm understanding of git to fully utilize its features. There is no real advantage of choosing one over the other, in fact some open source projects use multiple bug/issue tracking systems to handle features, issues, etc.

1. Mumble Features

by joelaro at September 30, 2015 04:30 PM

September 29, 2015

Kevin Manuel Paiva

Compiler Options (Lab 3)

I did some research on 2 compiler optimization options provided in GCC. My 2 options were -fassociative-math an -fcompare-elim. The following is what i found:

Regarding -fassociative-math, I found that this option allows the compiler to re-order operands of floating point operations. Now the problem with re-ordering operands is that the compiler can re-order an operand that causes the calculation to report a different result. This violates the ISO C and C++ language standard and makes the feature less likely to be used by most developers. To use fassociative-math you also need to have -fno-signed-zeros and fno-trapping-math in your compilation line. This is very helpful when optimizing arithmetic that does not need to be 100% accurate.

-fcompare-elim uses flags set by the processor on compilation in order to decide whether or not the processor needs to do a comarison. If it does not need to do a comparison it doesn’t bother trying. By default this is enabled at optimization levels: -O -O2 -O3 -Os.

It was very interesting looking through these compiler options and I feel like I understand a little more, exactly what these 2 options do during compilation.

by Kevin Paiva at September 29, 2015 04:23 PM

Kirill Lepetinskiy


From GCC documentation:
Consider all functions for inlining, even if they are not declared inline. The compiler heuristically decides which functions are worth integrating in this way.
If all calls to a given function are integrated, and the function is declared static, then the function is normally not output as assembler code in its own right.
Enabled at level -O3.
Function inlining is a technique where the compiler replaces a call to some function with the body of the function. Performance is improved because the overhead for calling the function, such as saving the execution context, is eliminated.
In C++ it possible for the programmer to declare a function as inline, but this optimization, which is activated at the -O3 level, attempts to do this automagically. At level 3, it is considered aggressive due to the risk of the program increasing in size significantly as functions all over the place are copied over and over.

Let's take a look at an example, consider this program:
#include <stdio.h>
void engage()
int main(void)
printf("Make it so.\n");
This version is compiled with -O0:
00000000004005d0 <engage>:
4005d0: a9bf7bfd stp x29, x30, [sp,#-16]!
4005d4: 910003fd mov x29, sp
4005d8: 90000000 adrp x0, 400000 <_init-0x3f0>
4005dc: 911aa000 add x0, x0, #0x6a8
4005e0: 97ffffa0 bl 400460 <puts@plt>
4005e4: a8c17bfd ldp x29, x30, [sp],#16
4005e8: d65f03c0 ret

00000000004005ec <main>:
4005ec: a9bf7bfd stp x29, x30, [sp,#-16]!
4005f0: 910003fd mov x29, sp
4005f4: 90000000 adrp x0, 400000 <_init-0x3f0>
4005f8: 911ac000 add x0, x0, #0x6b0
4005fc: 97ffff99 bl 400460 <puts@plt>
400600: 97fffff4 bl 4005d0 <engage> <--- engage called here
400604: a8c17bfd ldp x29, x30, [sp],#16
400608: d65f03c0 ret
This version is compiled with -O3:
0000000000400470 <main>:
400470: a9bf7bfd stp x29, x30, [sp,#-16]!
400474: 910003fd mov x29, sp
400478: 90000000 adrp x0, 400000 <_init-0x3f0>
40047c: 911aa000 add x0, x0, #0x6a8
400480: 97fffff8 bl 400460 <puts@plt>
400484: 90000000 adrp x0, 400000 <_init-0x3f0>
400488: a8c17bfd ldp x29, x30, [sp],#16
40048c: 911a8000 add x0, x0, #0x6a0
400490: 17fffff4 b 400460 <puts@plt> <--- no call to engage(), but a second puts()
400494: 00000000 .inst 0x00000000 ; undefined

by Kirill ( at September 29, 2015 05:40 AM


From documentation:
Attempt to also if-convert conditional jumps containing memory writes. This transformation can be unsafe for multi-threaded programs as it transforms conditional memory writes into unconditional memory writes.
This optimization will attempt to convert code like this:
for (i = 0; i < N; i++)
if (cond)
A[i] = expr;
To this:
for (i = 0; i < N; i++)
A[i] = cond ? expr : A[i];
This will change the processor instruction from a conditional jump to a conditional move. What I could understand from my research is that mispredicted jumps are expensive and it would be best to avoid them when possible.

by Kirill ( at September 29, 2015 05:39 AM

September 24, 2015

Joel Aro

Experimenting with GCC compiler options

gcclogoGNU Compiler Collection logo

On our second week into the class, we played a bit with the different GCC optimization options, and came up with some interesting results. Before we begin, there were two things that we needed to do before we compiled. First, we connected via SSH to the school’s remote server, an x86_64 system known as Xerxes.

Once we had access, we had to create a simple Hello World! program in C:

// hello.c

#include <stdio.h>

int main() {
    printf("Hello World!");

Then we compiled with the following command:

gcc -o hello hello.c -g -O0 -fno-builtin

This command does a few things:

  • Enables debug information(-g)
  • Disables GCC optimizations(-O0)
  • Disables C optimizations(-fno-builtin)

Compilation was successful and the resulting binary file was a few kilobytes in size. At this point each group was assigned a different task related to the binary and source files. I will now attempt to explain our findings for each task.

1. Add the compiler option -static
By appending -static to our compile command above, we found that the biggest difference was the size of the resulting binary. The size of the original binary was about 9.4kb while the binary that output from the -static command was over 800kb. Looking inside with objdump, showed that the binary has over 190,000 more lines of operations, compared to the original’s 300+ lines.

The reason for it being so much larger than the original is that -static adds in all dependencies for the program in the binary. Everything including the libstdc++ library is compiled along with the source code. This option, while making the program access links much faster, increases the size of the binary by a large amount. Without this option, the program will dynamically look for links.

We also found that there were differences inside the objdump section:


00000000004005f6 <main>:
  4005f6:	55                   	push   %rbp
  4005f7:	48 89 e5             	mov    %rsp,%rbp
  4005fa:	bf a0 06 40 00       	mov    $0x4006a0,%edi
  4005ff:	b8 00 00 00 00       	mov    $0x0,%eax
  400604:	e8 c7 fe ff ff       	callq  4004d0 <printf@plt>
  400609:	b8 00 00 00 00       	mov    $0x0,%eax
  40060e:	5d                   	pop    %rbp
  40060f:	c3                   	retq   

Binary with -static applied:

0000000000400b5e <main>:
#include <stdio.h>

int main() {
  400b5e:	55                   	push   %rbp
  400b5f:	48 89 e5             	mov    %rsp,%rbp
	printf("Hello World!\n");
  400b62:	bf 90 03 49 00       	mov    $0x490390,%edi
  400b67:	b8 00 00 00 00       	mov    $0x0,%eax
  400b6c:	e8 0f 0b 00 00       	callq  401680 <_IO_printf>
  400b71:	5d                   	pop    %rbp
  400b72:	c3                   	retq   
  400b73:	66 2e 0f 1f 84 00 00 	nopw   %cs:0x0(%rax,%rax,1)
  400b7a:	00 00 00 
  400b7d:	0f 1f 00             	nopl   (%rax)

We can see that in the original objdump, it doesn’t contain any source code, while the objdump with -static contains the source code of the binary.

2. Remove the compiler option -fno-builtin
The option -fno-builtin tells the compiler not use any built-in optimization techniques. In our case, it changes the printf() command found at :

  400604:	e8 c7 fe ff ff       	callq  4004d0 <printf@plt>

to puts():

  40053f:	e8 cc fe ff ff       	callq  400410 <puts@plt>

The two functions do the same thing, except that printf() validates each character to determine whether or not it is a format character. puts() on the other hand, simply takes the argument and throws it on to the screen without looking at it. The difference in our code is nearly undetectable, but with source code containing hundreds of outputs, this optimization will be much more noticeable. printf() → puts() is not the only optimization technique that is changed. Many functions that we are not aware of that affect compile and runtimes, can be reduced by switching to operations that are much faster and more direct.

3. Remove the compiler option -g
The compiler option -g is useful when having to debug your program. If you compile with -g, open GDB, and the run the program, you get the following response:

Reading symbols from Hello...done.
(gdb) run
Starting program: /home/jaro/lab2/0/Hello
Missing separate debuginfos, use: debuginfo-install glibc-2.20-8.fc21.x86_64
Hello World!
[Inferior 1 (process 5184) exited normally]
Missing separate debuginfos, use: debuginfo-install libgcc-4.9.2-6.fc21.x86_64 libstdc++-4.9.2-6.fc21.x86_64

and without -g:

Reading symbols from Hello...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/jaro/lab2/3/Hello
Missing separate debuginfos, use: debuginfo-install glibc-2.20-8.fc21.x86_64
Hello World!
[Inferior 1 (process 5190) exited with code 015]

We can see from the messages above that:

  1. We seem to be to be missing some dependencies.
  2. Error codes are replaced with useful messages.

In the example above, we can understand what [Inferior 1 (process 5184) exited normally] means, but have no idea what code 015 in [Inferior 1 (process 5190) exited with code 015] is.

The -g option allows many debugging symbols to be shown which can make debugging a lot more easier for the developer, but also increase the binary file size.

4. Add additional arguments to the printf()
When we add additional parameters to printf(), for example:

printf("Hello World!\n%d%d%d%d%d%d%d%d%d%d", 0, 1, 2, 3, 4, 5, 6, 7, 8, 9);

and then open up objdump, we can see the following:

00000000004005f6 <main>:
#include <stdio.h>

int main() {
  4005f6:       55                      push   %rbp
  4005f7:       48 89 e5                mov    %rsp,%rbp
        printf("Hello World!\n%d%d%d%d%d%d%d%d%d%d", 0, 1, 2, 3, 4, 5, 6, 7, 8, 9);
  4005fa:       48 83 ec 08             sub    $0x8,%rsp
  4005fe:       6a 09                   pushq  $0x9
  400600:       6a 08                   pushq  $0x8
  400602:       6a 07                   pushq  $0x7
  400604:       6a 06                   pushq  $0x6
  400606:       6a 05                   pushq  $0x5
  400608:       41 b9 04 00 00 00       mov    $0x4,%r9d
  40060e:       41 b8 03 00 00 00       mov    $0x3,%r8d
  400614:       b9 02 00 00 00          mov    $0x2,%ecx
  400619:       ba 01 00 00 00          mov    $0x1,%edx
  40061e:       be 00 00 00 00          mov    $0x0,%esi
  400623:       bf d0 06 40 00          mov    $0x4006d0,%edi
  400628:       b8 00 00 00 00          mov    $0x0,%eax
  40062d:       e8 9e fe ff ff          callq  4004d0 <printf@plt>
  400632:       48 83 c4 30             add    $0x30,%rsp
  400636:       b8 00 00 00 00          mov    $0x0,%eax
  40063b:       c9                      leaveq
  40063c:       c3                      retq
  40063d:       0f 1f 00                nopl   (%rax)

In the above output, we can see that:

  1. The values 0-4 are loaded from the registry
  2. The values 5-9 are pushed onto the stack

5. Move the printf() call to a separate function named output(), and call that function from main()
When we put printf() into its own function, we can see that the function is called inside main:

0000000000400536 <output>:
#include <stdio.h>

void output() {
  400536:	55                   	push   %rbp
  400537:	48 89 e5             	mov    %rsp,%rbp
	printf("Hello World!\n");
  40053a:	bf f0 05 40 00       	mov    $0x4005f0,%edi
  40053f:	b8 00 00 00 00       	mov    $0x0,%eax
  400544:	e8 c7 fe ff ff       	callq  400410 <printf@plt>
  400549:	5d                   	pop    %rbp
  40054a:	c3                   	retq   

000000000040054b <main>:

int main() {
  40054b:	55                   	push   %rbp
  40054c:	48 89 e5             	mov    %rsp,%rbp
  40054f:	b8 00 00 00 00       	mov    $0x0,%eax
  400554:	e8 dd ff ff ff       	callq  400536 <output>
  400559:	5d                   	pop    %rbp
  40055a:	c3                   	retq   
  40055b:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)

Other than that addition, the two binaries are pretty much the same.

6. Remove -O0 and add -O3 to the gcc options
The -OX command is the optimization that you want to apply to the program (X being the level of optimization, where 0 is the minimal level of optimization and 3 is the most optimized). -O3 can potentially break your program in favour of being the most optimized, so use it carefully. According to the GCC documentation, -O3 does the following:

Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-loop-vectorize, -ftree-loop-distribute-patterns, -ftree-slp-vectorize, -fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone options.

In the objdump with the -O3 option we can see the following in main:

0000000000400440 <main>:
#include <stdio.h>

int main() {
	printf("Hello World!\n");
  400440:	bf e0 05 40 00       	mov    $0x4005e0,%edi
  400445:	31 c0                	xor    %eax,%eax
  400447:	e9 c4 ff ff ff       	jmpq   400410 <printf@plt>

which when compared to the original:

00000000004005f6 <main>:
  4005f6:	55                   	push   %rbp
  4005f7:	48 89 e5             	mov    %rsp,%rbp
  4005fa:	bf a0 06 40 00       	mov    $0x4006a0,%edi
  4005ff:	b8 00 00 00 00       	mov    $0x0,%eax
  400604:	e8 c7 fe ff ff       	callq  4004d0 <printf@plt>
  400609:	b8 00 00 00 00       	mov    $0x0,%eax
  40060e:	5d                   	pop    %rbp
  40060f:	c3                   	retq   

is more compressed. In particular the line 400445: 31 c0 xor %eax,%eax is the fastest way of returning either a 1 or 0. This is because of the xor command, which does the following: returns a 0 if the values being compared are the same, or returns a 1 if the values being compared are different. The resulting binary will be a more optimized version of the original.

In Summary
GCC is very powerful in that, it allows the user to choose what kinds of optimizations they want to apply to their code. We only barely scratched the surface of what GCC can do, but hopefully I was able to show its strength. With this information, we can choose to turn on autopilot and let GCC use it’s default optimizations, which is fine because we can just sit back and watch it compile. OR we can push our programs to their max, and utilize everything that our compiler has to offer. We can control the program not only from inside it’s source code, but outside as well. A whole new world of possibilities has opened up and it is up to you as the developer to choose what paths you want to take, and our friend, the compiler, is there giving us the options.

1. GCC Optimize-Options

by joelaro at September 24, 2015 06:40 PM

Neil Guzman

Fault Injection Framework

From my previous post, I shortly talked about what my current project is about. This post will go into further detail on what my team and I are trying to do.

As discussed in the previous post, I am now in a team that is developing a Fault Injection Framework in order to help find weaknesses in a system so that developers/maintainers can fix them. I mentioned Netflix's Simian Army and how we are taking a different approach: permutating through each failure case instead of doing cases randomly.

First off, some definitions:

  • Node - a single service or host (e.g. a web service)
  • Relationship - a node-to-node connection in a system (e.g. a web service that connects to a database)
  • Cluster - a collection of relationships (e.g. a web service that connects to a database and a load balancer)
  • System - a collection of clusters (e.g. the entire system network graph)
  • Plugin - the type of fault we are injecting (e.g. increasing latency, or forcing a shutdown). It is categorized by single- or multi-noded plugins. Single being a fault that involves recycling a database. Multi being a fault that involves introducing latency in a relationship.
  • Injection Case - a combination of plugins used on a relationship/cluster to simulate failure
  • Injection Suite - a series of injection cases to run on a system

We want to be able to run an injection suite on a system so that we can find the weaknesses of the system and allow the system's developers/maintainers to be better prepared for when one of the generated cases happen in a production environment.

In order to accomplish this, we need to find every different plugin combinations that can apply to each relationship. For example, if we have a 2-node relationship and each node has the same 1 plugin (plugin1), then we have 4 different cases:

  1. Node1{none}:Node2{none}*
  2. Node1{none}:Node2{plugin1}
  3. Node1{plugin1}:Node2{none}
  4. Node1{plugin1}:Node2{plugin1}

NOTE: "none" being a case where no plugin is applied to the node.

Now, adding a new plugin (plugin2) to both nodes increases the 4 different cases to 9 different cases. Adding another (plugin3) increases combinations to 16. Another increases to 25, and so on exponentially... This is only part of the problem. It grows even further when you start adding clusters and plugins that work with multiple nodes.

However, there are cases that do not need to be tested. For example, the case (Node1{none}:Node2{none}) does not need to be tested because nothing is happening. Other generated cases might require to shutdown Node A and increase latency to Node A--an illegal case because Node A would be shutdown, thus not being able to increase its latency. And herein lies the problem: how do we systematically generate legal injection cases, without generating all injection cases under the sun.

This is a problem I will go further into detail about in the next post.

by nbguzman at September 24, 2015 04:00 AM

September 23, 2015

Suk-Joong Han

When people use compile option "-O#"

This shows what happens simply when people use "-O#".

This a difference between the objdump files of ELF files.


by 한석중 ( at September 23, 2015 03:22 AM