Showing posts with label Databases. Show all posts
Showing posts with label Databases. Show all posts

Friday, June 27, 2014

Article: Open CPU Database; Race Your Favorite Processors Head-to-Head

I thought I'd share “CPU DB: Recording Microprocessor History” written by members of the Stanford sponsored team that put together the database. I highly recommend this article, I thought it is a great example of the way that data, science, and data-science can work with the hardware and broader computer science industry.


The CPU DB (cpudb.stanford.edu) is an open database curated by a group at Stanford which stores information on processors throughout history. While the goals of the database addressed in the article are mostly concerned with using the database to analyze and predict processor performance the database is intended to be used by researchers with any subject in mind. I was especially impressed at how accessible the DB is, with multiple data interactions offered and example code for analysis. This article is both an introduction to the database by its proud parents as well as a demonstration of the analytical power the database allows.

Trendy Processors
The main research subject demonstrated by the authors is the use of the historic data to test for trends in the manufacture and performance of processors over time. The authors use several examples to show these features with graphical representations and statistical insights. Addressing the ubiquitous laws of Moore and Pollack the authors use data from the DB to show the performance gains over tiem and the impact of density and area afforded through manufacture. Despite my lack of deep knowledge in the area of hardware and architecture this aspect was most interesting to me. While many who worked in the hardware industry may know the history of decisions made to improve CPUs this DB gives a birds eye view of what the actual results have been. While we sometimes take for granted today that processors improve inevitably over time, the CPU DB gives us many parameters to empirically answer the question of how these improvements were made. Among many other examples the authors show that it’s true that clock frequency has increased dramatically from the 1980s to the mid 2000s they are able to show through empirical analysis that the introduction has all but halted progress on single core clock frequency in the past decade. This fact, while somewhat obvious from a macro trend is made more interesting with the detail the CPU DB provides. Citing the constant improvements in compiler optimization the authors show that while clock frequencies have been stagnant for some time, even single core performance has been increasing (albeit very slightly) in the last decade. This fact might be overlooked by a more narrowly focused industry report or consumer oriented technology journalism.


Open Analysis
The idea this article presents is fascinating to me, and I’m especially excited by the idea of the open data. Before I got to page two I was already thinking of how I might chop this data up with R. Much to my surprise when I went to the “Downloads” page the team has posted some sample R code. Just for fun I put together a quick chart of my own based on the CPU DB data, a wonky looking count of transistors per die over time.



R script:
require(ggplot2)
 
processor <- read.csv("processor.csv")
 
processor <- processor[!is.na(processor$date),]
 
processor <- processor[!is.na(processor$transistors),]
 
processor$date <- as.Date(processor$date)
 
processor <- processor[processor$date >= '2000-01-01',]
 
ggplot(data=processor, aes(x=date, y=transistors)) + geom_line(colour="blue", size=1) + ggtitle("Transistor Count 2000 to Today")
Created by Pretty R at inside-R.org

Monday, January 27, 2014

Favorite Tools: NDBC and the Chesapeake Bay Interpretive Buoy System

This one is not really a tool I use at work, just a favorite public data source of mine.  I really love the combination of physical computing and data.  The NOAA Buoy system might be considered one of the most widespread internet of things installations.

The NOAA Buoy System, consists of a network of buoys from different programs all tracked by NOAA.  Many of these are not under the direct supervision of NOAA, some are academic, others are state or local government installations.

The National Data Buoy Center website and database provides instant access to the status of many of these buoys.  Also included within the network are the observations from volunteer ships outfitted with sensors and telemetry equipment.  Individual buoys can be found via a map applet or within a mobile optimized site.


The Chesapeake Bay Interpretive Buoy System is part of the NDBC network and was designed to track the health of the bay using a network smartBuoys installed around the Chesapeake Bay watershed.  The smart buoys include a suite of sensors a  DIY Arduino weather station might dream of.  The program supplements this environmental data with a parallel historic lesson, combining the bay health with the history of development in the watershed area, including the connection of the buoy locations with the historic journeys of a favorite historical figure of mine, Captain John Smith.

The CBIBS includes some cool data visualization features, like a graphing applet and csv downloads.  It also has a mobile app, which I've added to my wonkApp collection along with the FRED app.


While this data is used more urgently by mariners and scientists I love checking this data to consider the environment at some of my favorite places in the area; in the lower Potomac near where I grew up, Jamestown Island (visible from the fort site), and in the Upper Potomac (visible from my apartment).


I've even written some shell commands which I use to check on the Alexandria Buoy for real-time weather stats 200 yards from my apartment building while at work:

alias bTemp='wget -q http://www.ndbc.noaa.gov/mobile/station.php?station=44042 -O - | grep Air | cut -c1-15'

(Buoy Station changed in code to reference an active station.  Sadly, the Upper Potomac is offline for winter maintenance)

Sunday, January 19, 2014

Favorite Tools: FRED and St. Louis Fed Research Tools

I'd like to use this series as a set of love notes on my favorite data tools.  Some of these I use almost constantly at work, others are personal favorites I have come across.


FRED is a tool I came across a few years ago while reading economics blogs.  The distinctive color of a standard FRED graph (with obligatory recession shading) was something I began to associate with the econ blogger crowd.  It seems this has been noticed by many, and Paul Krugman, his blog being one I first noticed FRED on, is quoted as saying "I think just about everyone doing short-order research — trying to make sense of economic issues in more or less real time — has become a FRED fanatic."

After using these tools at work and home I have come to feel the same way about the tool, even evangelizing its merits to my coworkers and friends.

FRED graphs are distinctive and immediately recognizable


In my work in data analysis at a national bank, I have come to greatly value FRED for two main reasons.  FRED is a singularly well organized and populated database and it allows the immediate reference to data which is often useful in a one off fashion.  Pulling this data out during a meeting has more than once garnered some recognition of my economic knowledge which might not have otherwise occurred.

The breadth of data available is somewhat astounding.  International Data might usually take you all over the web and to a few commercial sites, but FRED has enough to do most high level macroeconomic survey work.  I find the somewhat more obscure metrics very interesting at times, and it's fun to eyeball for trends.

It's too easy to make weird charts...


After discovering FRED's website I was ecstatic to find that an Excel Add-In had been developed.  i immediately made use of the feature and made sure I spread the news around.  Being able to quickly pull in common economic data while doing simple (or complex) analysis can save a lot of time.  Outsourcing the data storage and update costs to FRED is wonderful.  I've been able to cut down on some user table creation and maintenance I owned was a time saver.

In order to facilitate the access to my company's internal economic data hub I even created my own version of the FRED Excel Add-In, which I named ED.  Using some simple VBA  GUI elements (drop downs, radio buttons, many MsgBox's...) and an ODBC connection I was able to mimic the Excel Add-In functionality of FRED.  Adding in some charting code I was able to mimic the distinctive graphs as well.  Given that the data is proprietary, I don't see any issue in my imitation of FRED, and I view it as a labor of love in tribute to the data tool.
Tying FRED into R was an obvious result, and I've already begun to make use of this data.  Being able to pull this data down into the R environment makes it even easier to manipulate the data quickly, without the worry of Excel resources (Autosave I'm looking at you!), or adding the data to a database structure.  A R programming project I'll detail later exhibiting geographical plotting uses similar data, maybe I'll tie FRED in to show off the functionality.

I also happily own the FRED mobile app, which I find entirely too amusing, and has come in handy for wonky discussions, and to prove my data nerdiness to anyone in sight.

If they sold T-shirts, sign me up for two.


The St.. Louis Fed includes three other tools GeoFred (data Mapping), ALFRED (historical economic series), and CASSIDI (a personal favorite of mine, which details US banking industry data).  I believe I'll include love notes on these as well, CASSIDI especially.