The Future of Computing Performance: Game Over or Next Level?.

A nice, thorough explanation of the current challenges in computing performance, ranging from transistor-level power vs. speed problems, up to how to program the circuits we’re likely to end up with.

Also includes a bonus reprint of two classic papers, Gordon Moore’s “Cramming More Components onto Integrated Circuits” from 1965 – that’s the paper you might expect it is, and Robert Dennard’s “Design of Ion-Implanted MOSFET’s with Very Small Physical Dimensions”, which I was less familiar with.

Embedded in Academia : Squeezing a CS Research Idea.

Matt Welsh (ex Harvard Professor, now at Google) on the phasing out of Intel’s “Lablets”, which were a new kind of company-supported research center that was co-located with major universities. His blog post title notwithstanding, this doesn’t seem to be about Intel moving away from research in general, just this particular model of heavy university interaction.

I don’t want to comment directly on his post (see disclaimer below), but I’m posting this because there are a lot of interesting comments on his site, including some people sharing their views from inside other industrial labs. Welsh suggests that industrial research is on the wane and that Google’s model of advanced development is the future, and others chime in to say that research is alive at many companies, some more directly focused on (read: paid for by) product groups than others.

Update: See also the comments on the post at Hacker News, in particular this long one by NY_USA_Hacker, who is continuing his (?) tradition of posting marathon irreverent comments about the value of a PhD, and advocating mathematics PhDs over computer science, even for tech folks.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

HPCWire is a well-known news source for HPC. It has daily news updates, and occasional columns by guests from around the industry. Most of the news is press releases from companies and government labs, but it’s nice to have a single place to check for them. However, there is apparently no RSS feed, and to get email updates, you have to buy a subscription. I haven’t, but I do check back occasionally to read the columns.

Supercomputing Online is another professional news outlet, which reads a little less like a press release, seems to have more coverage of academic news, and does have an RSS feed.

insideHPC.com is more of a weblog than either of the first two – John E. West covers news stories in brief with some added perspective and analysis. I like his approach, and I’ve joined him to help cover academic HPC issues, both computing research and issues affecting computational scientists.

One of many blogs at Sun is the HPC Watercooler, covering Sun’s HPC products and services, as well as some non-Sun related news. I’ve found it pretty interesting already, and I’d be interested to see weblogs from other HPC vendors.

Finally, a couple of blogs that are less directly related to HPC but still very relevant for computing researchers, are Dan Reed’s weblog at the Renaissance Computing Institute, and the CRA Computing Research Policy Blog, both of which cover computing research policy and funding issues that don’t often show up in news coverage of either government or computing.

* – if anyone wants to start an LTU-alike site for HPC research, or point me to one, I’ll sign up and contribute in an instant.

This is a pretty interesting attempt to get around the problems facing processor design today. Clock speeds have stalled, but the actual Moore’s Law – the one about transistor count, not “speed” – is still going, so we have the problem of what to do with just a lot of copies of basically the same old chip?

A lot of answers you hear involve pushing that complexity up to the programmer, forcing more people to become parallel programmers. This is almost certain to happen at least a little, but let’s hope we don’t have to give up on the sequential programming model completely. If you think software is bad now…

The TRIPS processor is an example of another approach – placing more of the burden of finding and using parallelism onto the compiler and architecture, keeping programmers’ heads above water. It’s pretty exciting to see something this different make its way into actual silicon.

The basic idea is that instead of a single piece of control logic organizing the actions of multiple functional units, finding concurrency within a window of instructions using reordering, the TRIPS processor is distributed at the lowest level – each functional unit is a mini-processor (called a tile), and instructions executing on separate processor tiles communicate operands directly, not through a register file. Usually this is described as executing a graph of instructions instead of a single instruction at a time.

Current processors certainly don’t just execute one instruction at a time, and they do plenty of moving instructions around, so I tend to see this explicit-data-graph description as just the far end of a spectrum that starts with old superscalar designs, continues through out-of-order processors and multithreaded architectures, and currently seems to end here.

A TRIPS processor can run four thread contexts at once, with an instruction window of 1024 instructions to reorder and 256 memory operations in flight at once. For comparison, the late ’90s Tera MTA ran 128 threads at once (128 different program counters), and the 2003-vintage Cray X1 processors kept track of 512 memory operations at once. Just like TRIPS, each of those architectures required extensive compiler support for good performance.

A particularly interesting point is the fully partitioned L1 cache – meaning that there are multiple distributed L1 caches on the chip, so where your instructions are physically executing will be important for performance – if they’re near the cache bank holding their operands, they will execute sooner.

The natural question when looking at a new and interesting architecture like this, especially one that promises a tera-op on a chip, is whether it will make its way to a laptop you can buy anytime soon. I have no idea if the UT team has any industry deals in the works, but I would bet against something like this becoming mainstream quickly – the fact that these architectures rely so much on a custom compiler with aggressive optimization means that a lot of dirty work is required to move existing software to it.

It will be interesting to follow this project and see how their actual hardware performs.

Even though we keep our research papers stored on disk as PDF, all too often we print them out to read and write notes on. There’s something missing in the experience of reading papers on a computer, but it doesn’t have to be that way.

Announcing Skim. Skim is a PDF reading and note-taking app for Mac OS X that is designed to make reading research papers and manuals better. Just like in Preview, you can search, scan, and zoom through PDFs, but you also get some custom features for your workflow:

• Snapshots: if there’s a graph on page two and the description continues to page three, just draw a box around the graph with the command key down and a snapshot window pops up with the graph, and you can keep on reading with the graph in view. For more fun, minimize that snapshot window – they stick around in their own dock in the document window.

• Tooltips: If a PDF has links, such as for citation references or indexes and section headings, you can click on them as usual to go to the destination, but there’s more – hover the mouse over those links and Skim will show you a tooltip with the target of the link. No more losing your place to peek at a citation! For more fun, command-click on a link to pop up a snapshot window showing the link’s destination.

• Presentation and Full-screen Modes: Full-screen reading is handy. So is showing a PDF as a presentation. But they’re a little different. For instance, you might not want to show the table of contents in a presentation, but it’s nice to see it when you’re just reading by yourself. So Full-screen and Presentation are separate modes in Skim.

There’s plenty more – download it and take a look, and join the mailing list to discuss it. There’s even a full help book in the first public beta release!

Many thanks to everyone who has worked on this app, and especially to Christiaan Hofman, who moved the app from a prototype to something really useful faster than I would have thought possible.

It’ll be on Thursday Nov. 16th at 12:15PM.

As with all really interesting questions, this has a quick, easy answer that reveals your point of view. My immediate answer is “No”, because of the productivity problems the focus on high utilization causes for many HPC users, mainly through the use of a batch queue. However, when considering the interests of everyone involved (including the people who have to evaluate how money is spent on these systems), the only responsible way to answer is “it depends”.

It’s an interesting topic that never fails to generate some controversy, and from what I can tell we’ll have some diverse speakers at the BOF (including myself, discussing user surveys we’ve conducted as part of DARPA HPCS). It should be enlightening.

I see an increasing number of Macs at research meetings I go to, and I usually can’t help but peek on their dock to look for that yellow folder. I usually don’t ask people if they’ve heard of it, but I have thought of putting a big sticker with the BibDesk icon on my PowerBook, just to see if anyone recognizes it.

I found out about this through an email from the Coverity CTO on the GCC mailing list, and it seems to have been received with some moderate enthusiasm. I think it’s a good idea, but as usual the specter of false positives makes the developers itchy, especially when they’re publishing bug counts…

Dawson Engler, the professor at Stanford who was behind all this bug-finding work (and co-founded Coverity) gave a talk recently here at CSE, about newer approaches to finding bugs that uses execution on symbolic inputs – meaning that you mark some inputs to a program as symbolic, and somewhere there’s a theorem prover that goes to work finding out if any value of those inputs can cause an error or a crash – then you can run the original code on the input to verify the problem. A nice consequence here is that the generated ‘bad’ input is then guaranteed to actually be bad, since you can test it and force the error.

There’s a paper about that from Engler’s group here, and apparently this PLDI 2005 paper from Bell Labs is very similar.

Here’s Prof. Engler’s slides from talks about the new work on bug finding and an entertaining talk about commercializing the MC Checker.