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.
Sunday, 25 January 2015
Monday, 19 January 2015
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.
Wednesday, 14 January 2015
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.
Sunday, 14 December 2014
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.
Sunday, 7 December 2014
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.
Thursday, 27 November 2014
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.
Sunday, 19 October 2014
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:
- 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.
- Create a histogram expressing the expansion v. the number of PCs.
- 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.)
Subscribe to:
Posts (Atom)