Wednesday, July 25, 2007

My Home Network Joys and Woes



Qwest DSL + foreThought.net ISP

I have a Qwest DSL line coming into the condo. My ISP is through foreThought.net. They gave me a dedicated IP address from which I serve a few different web sites (e.g. weathermole.com). I have no complaints here. I have experienced few service interruptions, and the guys at foreThought are responsive whenever I have a question or an issue arises.

Zoom X6 Gateway

This product claims to be an "all-in-one" solution. It has a wireless-G access point, router, and 4-port switch. I have a headless Mac Mini plugged into one of the ports. The Zoom X6 has a little embedded web server inside that users can configure the modem, set up the firewall, block ports, etc. I purchased it because it was recommended by my ISP and they know how to work with Zoom modems.

I was not crazy about this product after I purchased it. I found it hard to configure, and it froze up regularly so I would have to reboot often. After installing a bunch of firmware updates throughout the months, it seems to be doing better. I only rarely have to reboot it. The folks at foreThought originally helped me set it up shortly after I purchased it. I have since made a million screen shots of the configuration so that I will hopefully never have problems with the setup. I do not know if I would recommend it, but it basically works at this point.

Headless Mac Mini

On the Mac Mini I host a few websites (e.g. weathermole.com) and serve iTunes for various devices around the house.

I think this is a clever solution not to have a keyboard and monitor, and it does not take up much room in our tiny condo; it sits under our bed. But the fact that it is headless makes it hard to deal with at times. I connect to it via ssh to control it remotely with the command line. For desktop UI applications -- basically just iTunes-- I use Chicken of the VNC, but it is somewhat slow and kludgy. Moreover, I am always nervous during a software update that it is not going to come back up, and I do not have a spare monitor/keyboard lying around to see what is going on if that ever happens. When I originally set it up, I brought it to work and plugged it into a monitor/keyboard there to do the initial configuration. As Mac users know, a lot functionality on a Mac needs to be accessed via a user interface.

Also, my wife and I both have iPods. It is really inconvenient when we have to them sync them up. Again, it sits under a bed. I have to control iTunes via Chicken of the VNC. This aspect is pretty lame. If I ever have the funds to upgrade, the next machine will not be headless.

In the meantime, I thought about setting up a cross-mount (over the wireless) and having the iTunes directory visible on the laptops, as if it were local. I tried this plan half-heartedly , but I never had any success, and in the end, I am not sure it would work. It would nicely solve the iPod syncing problem if it did.

The headless Mac Mini is a fun but imperfect solution.

UPS

I have one of the cheaper varieties that supply uninterruptible power to the Zoom gateway and Mac Mini at least for a few minutes. We have had power interruptions so it has served its purpose.

Roku Soundbridge Radio

I have a love / hate relationship with this product. It seems to have limitless potential for serving music and Internet radio. My favorite local stations are KUNC, KUVO, KGNU -- which I could, of course, listen to with good old-fashioned technology. On the Internet we listen to WeFunk and Radio Paradise. For foreign stations, I like to listen to France Culture, Radio France Internationale, Europe 1. Plus, it is a client for our gazillions of scanned CDs that reside on the Mac Mini. My wife used to be a music writer so we have a lot of CDs.

This is all great, but I find the user interface of the Roku to be a pain in the neck. It is really hard to navigate and find a CD or podcast I want to listen to via the remote control and the small screen on the Roku. For this reason, we still use a regular CD player from time to time. Ideally, it would be great to have a full fledged iTunes interface, but without the computer. This could almost be achieved through an iPod that we would carry around the house and plug into various iPod-ready radios. The iPod's interface is far superior to that of the Roku. But, iPods cannot stream Internet radio, so that solution is out.

Apple TV could possibly work, but I want a portable solution that I can carry around the house.

It is theoretically possible that an iPhone could solve all these problems, assuming that you could somehow use the iPhone as a middle tier to the various audio devices sitting around the house. Can the iPhone iTunes connect to to Internet radio? Can you purchase an iPhone without a phone plan? Maybe there is a business opportunity in here somewhere.

Still, the Roku remains one of my favorite toys in the house.

MacBooks

I also have a couple of Macbooks which are both really great and naturally hook into the wireless network.

Other networking problems...

When I am on my local wireless network, for various reasons, I would really like to see my websites through the regular web address (i.e. weathermole.com NOT 10.0.0.10, the local address). I think that I would have to muck with a configuration file somewhere on the client machine, but I do not know which one.

Friday, July 13, 2007

Sea Change Coming for Scientific High Performance Computing Languages?

I work at an institution where scientists and engineers are busy predicting the weather and the Earth's climate in decades to come. These predictions are done by simulations on very specialized super-computers and high performance computing (HPC) platforms such as the IBM Blue Gene machines.

Unfortunately, there has not been a lot of modern programming language support to take advantage of these parallel processing behemoths, mainly because of their highly specialized and narrow use in the fields of climate and weather forecasting, nuclear reaction simulations, etc. The languages that are supported are typically Fortran, C, and C++.

As a younger generation software engineer, I am a fan of more modern programming languages such as Java, C#, Python, etc., so the prospect of developing software on HPC platforms has not always been my cup of tea. Those old-school languages seem to lack many features that make life easier for programmers -- e.g. virtual machines to address portability concerns, simpler builds, more developer buy-in leading to rich community support etc. Moreover, as far as Fortran is concerned, there does not seem to be much in terms language support such as numerous open source libraries or sophisticated IDEs. Plus, I prefer modern OO languages for their notions of encapsulation and polymorphism that, if done correctly, ultimately reduce complexity and let programmers achieve more with less code.

As far as the scientific HPC programming language landscape is concerned, Fortran has been the status quo for a few decades now. I suspect that there is a sea change coming, however, in the world of HPC languages. This speculation is, of course, fueled by multi-core revolution sweeping across desktop and even laptop computers. As single CPUs have hit the wall in terms of performance, the only option is to add more CPUs (cores) per processor and shove more processors into the computer. The computer that I am using right now is a laptop with 2 cores. Apple just released an 8 core (2 quad core processors) machine. This trend hints at the fact that desktops and laptops are becoming HPC platforms.

As we start seeing a preponderance of these types of architectures, programming languages and software engineers are having to adapt. In particular, languages are going to make greater use of threads and other concurrency features to take advantage of the multi-cores. All this is not really news to anyone who has cracked open a DDJ in the last three years.

What is interesting to think about is how these changes will affect the rarefied world of HPC and supercomputing. I speculate that tomorrow's weather and climate simulation super-computers are going to be the same kinds of multi-core computers that run on our desktops, but just with a bunch more processors. The simple explanation is that this will be the path of least resistance to building a big parallel processor, rather than creating custom, one-off solutions. (A corollary perhaps is that super-computers could become cheaper. We have really seen all of this before with off-the-shelf linux clusters and the Beowulf type machines.)

In other words, the architecture will be similar enough that standard desktop applications could run on a 1024 processor machine in the not too distant future. This assumes, of course, that desktop applications will have been ported to the new multi-core architectures, but this is inevitable over time as the multi-cores become prevalent. More apropos, we could see Java Virtual Machines running on big multi-processors. And with Java's built-in support for threads, and the forthcoming fork-join framework, using Java as an HPC language remains in the realm of possibility. Software developers are already running Java on big parallel machines at places like Azul Systems, but as far as I know, they are not doing scientific programming.

For various reasons, however, Java is not the best language for scientific HPC. For one thing, there is no operator over-loading in Java. That makes dealing with complex numbers (which must necessarily be represented as objects) annoying because developers have to therefore rely on method calls that can be unwieldy for arithmetic operations. There are a multitude of other reasons why Java is poorly suited to scientific programming that go beyond what I want to write about here. With the possible exception of C++, the difficult truth is that while Fortran is not a great language, until now there has been little or nothing better to address scientific HPC domain.

Fortunately, computer scientists at various research centers are busy developing new programming languages that are well suited to the multi-core world of today and also have the potential to address various scientific-computing problems. In particular, a couple have been receiving some attention: Fortress from Sun, and X10 from IBM.

What is promising is that these languages are new (especially compared to Fortran) with modern programming notions like object orientation, but also address scientific HPC needs. Here are just a few highlights of features that look interesting:

Easy parallel task decomposition - They make it straightforward to break up work for parallel execution. For loops are parallel, by default, in Fortress. X10 has a number of built-in concurrency idioms.

Science oriented - Fortress and X10 both allow operator overloading, for example. Fortress accommodates Unicode characters in identifiers allowing for Greek symbols in code. Fortress also allows static checking of physical units and dimensions and multidimensional arrays.

Portable by way of virtual machines - The project websites of both these projects claim the languages will run on the Java Virtual Machine. Not only does this have the potential to solve all sorts of portability concerns, but, speaking speculatively, they could take advantage of any jar bytecode library that can run on the JVM. No need to write a separate lexer parser for XML in X10, in theory.

Supported by the Eclipse IDE - Fortress and X10 have Eclipse plug-ins.

There are also many other improvements over previous languages which you can read about here and here. But in conclusion, scientific programmers may finally have access to several modern programming languages that may, at long last, get us past Fortran.