Sass

In order to help organize my front-end design code, I've been learning SASS. SASS is a language that is a more structured and succinct version of CSS. SASS allows for things like variables, function, and inheritance, none of which are available in traditional CSS. SASS also removes things like curly braces from CSS, meaning that it is not backwards compatible. SCSS is a backwards compatible version of SASS, that personally seems more practical than SASS.

You gotta have a website

I've been working on making a website, mostly because it's fun. I've also been working on developing a tetris clone. Developing the correct handling and controls for the game is extremely difficult- there are a lot of high-level nuances to tetris that are hard to replicate using javascript. For example, the tetris guidelines specify very specific behaviors for rotations and wall kicks.

Temporal caching / temporal prefetching

Previously I had been researching the results of a temporal influence on caching. However, this wasn't productive because a lot of changes were being made to the code so I was almost always working with old code. Now, I'm researching temporal influences on prefetching, which means getting used to a new code and different coding style. I can't really go into any more detail, but you're welcome to read this article on the ISB if you want more details.

Switching simulators

I've had to switch simulators from an old competition simulator called CRC to a more updated and more formalized simulator called FSim. Also, the code for Hawkeye was changing a lot, so I am not working with the Irregular stream buffer, which means that I have also shifted focus from caching  to prefetching. This has required a lot of code migration and changing of job workflow. On the plus side, I can reorganize my simulation results, which is good since they were not very well organized.

Computer maintenance

One of the computers in the comp sci room broke, so we first cleaned out the liquid cooling system and replaced the cooling fluid. The computer still would not start, so we tried unplugging various parts and eventually decided that none of that worked, so we eventually decided to replace the thermal paste, after which it booted but with major data loss. We are still working on this.

Arch linux

I recently switched from Ubuntu to Arch linux, and I have to say that Arch is the largest waste of time I have ever invested in- but you should try it! It offers negligible performance gain and marginal control over basic system resources. If you switch to Arch linux today, you also have to set up your wifi via a clunky obtuse command line interface. There are many benefits, most notably that the package manager is called "pacman"! How cute is that?

I'm making a tetris

Making tetris is a standard beginners computer science exercise. Doing the basic layout for the game is pretty straightforward, but getting the game to handle well is another issue entirely. I've been playing a number of online tetris games as research, but many of them have serious control problems, e.g. no fast drop or awkward left/right shfting. This tetris clone looks very nice, (The DEMO screen in particular is reminiscent of old-school arcade games) but actually playing the game is awful! Here is the pen in its current state.

Computin

Last week we set up the other computer that was sitting in the teachers lounge. There was a lot of difficulty getting an install of any OS running (at first it wouldn't recognize bootable flashdrives etc.) but now we have a clean install of Arch Linux! Woo! We (me and ryan) also added RAM to the other computer and tried to add graphics cards/capability, but it caused strange screen issues. We also organized wires so it's not a jumbled mess and set up the new monitor for the "new" computer. That computer has a liquid cooling system which no one knows how it works, that somehow needs  to be refilled, so that might be part of what we're doing next week. It was pretty productive although unrelated to anything else. Hopefully I can get accustomed to Arch soon.

Results

In computer science, some data points can be very expensive to calculate, so compiling a sufficient array of data for analysis can take a very long time. In the past week I have been collecting many different kinds of data for this reason.

Mess up on Stampede

In bash, you can run commands in parallel by terminating them with an "&", rather than a ";". I thought that running commands in parallel on Stampede would help them finish quicker, since I had a job limit of one. However, by doing this I inadvertently submitted the parallel commands to my user nodes, rather than the job nodes, which is against Stampede user policy. So, after having my account terminated for improper conduct, I contacted TACC and they reactivated my account. Since, I've only had the chance to do basic simulations on the new system.

Move to different servers

I moved from Lonestar, an old TACC server cluster kept for posterity, to Stampede, the 7th most powerful computer in the world. The server comprises 6400 nodes, 102400 cpu cores, 205 TB total memory, 14 PB total and 1.6 PB local storage. Since, I've been migrating simulators and getting used to the new system of queueing jobs.

Neat Code

Code written in javascript, css, html, etc. is all very free-form, which means that taking care to organize code neatly is particularly difficult. As I work on a project, I often find that there are many ways to write a certain part of my code, but that I'm not sure which one is the nicest, most readable way to write the code. Given that the different options are nearly identical in performance, I don't have an easy tie-breaker for the different styles. Shorter code is not always easier to read, but longer code is not always sufficiently succinct. If a single css file is becoming thousands of lines long, it seems like I should refactor some of it, but isn't it uglier to have the code split between css files than have it all be in one easily searchable document? My solution to this has typically been to read others' code and model it off theirs. For this reason, I spend a fair amount of time browsing websites like codepen.io and various web design blogs to catch a glimpse of others' programming paradigms. But who is to say that their code is better? For this reason, I've read various books on general code organization, e.g. Code Complete and The Pragmatic Programmer, two books that I plan on looking back upon over the break.

Material Design and color selection

I decided to take a break from my internship and instead read up on web design. Google has a pretty exhaustive article on their own design philosophy, dubbed material design. These guidelines are extremely specific (they even specify to have no space in between en-dashes when specifying a range of times). The entire design philosophy centers around imitating tangible objects (mostly paper) in your websites, to have an intuitive and elegant aesthetic. Beyond that, the design rules are pretty typical- attractive colors, strategic placement of elements, and intuitive animations.

Temporal grouping in Streams

I have been working on a modified version of the Irregular Stream Buffer that considers the instruction time between consecutive memory accesses in it's stream definition, i.e. there are twice the average number of memory accesses between two accesses in the same program counter, so a new stream is created and the old one is discarded. Theoretically, this will benefit the program because the buffer will have a steady stream of new information. However, if the algorithm clears out the buffer too often, then the buffer will constantly be re-calibrating and will become inaccurate.

Frailty, thy name is visually intuitive representations of large quantities of arbitrary data

For my internship I have graphed the number of memory addresses that have been accessed by each individual PC (Program Counter), in order to analyze the distribution of accesses between programs. Simply recording the data yields a fairly obtuse bank of data: literally 2 long strings of unreadable numbers. To represent his data in an intuitive manner, I am using 3 different approaches:

1. Sort the PCs by their access frequency (i.e. the total number of accesses) and graph the expansion of the PCs so that the expansion is on the Y axis and the frequency is on the X axis.
2. Create a histogram expressing the expansion v. the number of PCs.
3. Create a cuumulative distribution function (CDF) graphing the PCs sorted by expansion v. the expansion. (This graph will constantly be increasing, so the importance is in the rate of increase.)

Fuzzy fuzzy access streams

In memory access streams there is a topic called "contraction", which refers to the ratio of the number of physical addresses to the number of structural addresses in an Irregular Stream Buffer. (You can read more about the Irregular Stream Buffer here.) A contraction of 1, i.e. having the same number of physical addresses and structural addresses, is best for caching because it means that accuracy will improve and the same thing will never the be cached twice.

Contraction has a close cousin, expansion. Expansion refers to the situation in which there are more structural addresses than physical addresses, so the Stream Buffer ends up having a larger than necessary memory footprint. Contraction refers to the opposite situation: there are more physical addresses than structural addresses, which leads to lost information.

Say we have the access stream
ABCDEF

Now, say we have the following access stream after this one
XBDCEF
This will cause expansion because this second stream will be recognized as a separate stream.

Alternatively, consider this access stream instead
AVWXYZ
This will cause contraction because this second stream will be recognized as a modification of the first access stream (assuming that the stream recognition system is lenient enough)

Give that man some soup

For many memory prefetching algorithms, it is necessary to predict the re-reference interval of a memory access, so that the memory can be moved to the cache before the memory is called for, vastly decreasing memory access time.

Consider the following address stream:

ACDACBBD

In this example, the re-reference interval of D would typically be 4, because there are 4 memory accesses between consecutive accesses of D(I'll get to the reason that I say "typically" in a second). This means that, given the following access stream

ACDACBBDACAC

it would be natural to prefetch D, because, based on the idea that D is accesses every 4 accesses, it would likely be the next address. However, in practice, it has been shown that the next memory access is more likely to be something like BBD. Why is that? Well, we're not quite sure, but studies have shown that prefetching based on the unique re-reference interval, i.e. the number of unique memory accesses between consecutive addresses, produces significantly better results. Under this model, the unique re-reference interval of the first example would be 3, since there are 3 unique memory addresses: A, B, and C. The problem is that keeping track of the data required to find the unique re-reference interval is extremely difficult to do efficiently, so, for the past 2 weeks, I have been researching methods to do this efficiently.

Some background information

I was told by my PI to graph the number of physical memory addresses that are passed through our simulator, and compare these to the structural addresses that these are mapped to. Many of the simulations didn't complete because the files' simpoints needed to be recompiled, so we recompiled the simpoints. To do all of this, we are using a software called Intel PIN tool that is a program through which one can run C++ code with a great deal of control over how the code is run. Simpoints are sets of instructions that are run. So, for example, if we compile 3 simpoints per benchmark, we are given 3 sets of output per benchmarks, each set being the result of ~25,000,000 instructions. We are using SPECfp as a benchmark, which is a standard floating-point algorithm benchmark that works by running state-of-the-art algorithms such as the Einstein evolution algorithm and quantum mechanical simulations.

I apologize that I can't give more accurate details as to the actual code that I'm working with, but I'm not really allowed to talk about it because the research is going towards an unreleased paper.

Good morning world

I'm splitting my time between the lasauil project that Neil, Ryan, and Evan are working on, and an internship with UT. For my internship I need to ssh into the UTCS computers, as well as a TACC (Texas Advanced Computing Center) allocations. Unfortunately, AISD blocks all SSH requests, so I've been trying to find ways around the block, with the help of Sam Grayson- I'm also contacting AISD directly about an exception. The work I am doing is related to cache architecture, specifically caching algorithms.

Graphing

Most libraries built for graphing data on web pages are large and clunky, so I opted to write my own client code to generate graphs of user data for the uil website. The data is given as two groups of time stamps and question ids, one for questions answered correctly and one for questions answered incorrectly. First, the data is normalized so that the time stamps are between 0 and 1, inclusive, so that the question with time stamp 0 is your first question answered and 1 is your last question answered. The data is then sorted and iterated through and graphed, keeping track of the ratio between your number of questions answered correctly and incorrectly, generating a graph of your general performance over time.

This style of data crunching is briefly very computationally intensive, so if users are opening a lot of pages it could chew up some bandwidth. Additionally, I'm not sure how well this will work if users have a very long history, but there won't be more data points than there are questions in the whole database, so that should be fairly easy for us to control.