ISCA 29 Conference Notes

ISCA-29 Conference Report

The 29th annual International Symposium on Computer Architecture was held in Anchorage, Alaska this past weekend,from May 25 through May 29. Originally, I was not expecting to attend, especially since I had not submitted any paper to the conference. However, I was asked by Dr Bruce Jacob to assist in his DRAM tutorial that was scheduled for Sunday, May 26. So I went along for the ride. I have written a few points that summarizes my view of the conference.

Conference Overview

A minor criticism for the conference, as the conference was held at the Anchorage Hilton, and Hilton contracted a shuttle bus to bring conference attendees from the airport to Hilton. Unfortunately, there were either no signs, or the signs were too small and easily missed. The result was easy to predict, as nearly everyone waited patiently for a van with the name “Hilton” on it to arrive at the airport to pickup conference attendees, only to run out of patience and call a cab instead. This story was repeated by several attendees. I too was going to call a cab, but called the hotel to verify the shuttle information. I was then informed that the shuttle was not a little van that makes 30 minute runs, rather the shuttle was a full sized tour bus that waits patiently (with a tiny “ISCA” sign on the door of the bus) for anyone attending ISCA to show up. Armed with this information, I was then able to locate the bus, got on, and the bus made a special trip ferrying just myself to the Hilton.

Anchorage, Alaska was an interesting choice for the conference. Overall the weather was fairly nice, and the infamous mosquitoes had yet to emerge, so we had good weather, and no mosquitos. Unfortunately, the nice weather pulled a few folks away from attending the tutorials and workshops, but the weather was indeed quite nice, and if I hadn’t been obligated to participate in the tutorial, perhaps I too would have gone out and enjoyed the sun instead. Speaking of the sun, at this time of the year, there’s about 18 to 20 hours of daylight in Anchorage, and it’s a bit odd trying to sleep at midnight with the streets still bright from daylight. Overall I enjoyed the trip to Anchorage, and the interaction with all the different people from industry and academia have generated a few new ideas that may be worth exploring.

Workshop and Tutorial Session Notes (Sunday, May 26th)

From my perspective, I believe that the DRAM tutorial was a good success. Approximately 50 conference attendees participated in the tutorial, and the immediate feedback was excellent. Even Andy Glew (Intel P6 architect) gave us the thumbs up. Although his feedback was that he wished we had covered more novel and emerging DRAM architectures. My response to that request was that we only had 3 1/2 hours, and were we to focus on the advanced discussions at that level, we would’ve lost 90% of the audiance, and the nature of the tutorial fundamentally limited the scope of our coverage. Still, the positive reviews were very encouraging, and the hoarding of the tutorial handouts further reinforced the positive feedback.

Technical Paper Sessions: Day 1 Observations (Monday, May 27th)

The first three papers presented at the conference were remarkably similar, as IBM, University of Texas/Compaq, and Intel all presented their own respective paper on “optimal pipeline depth”. The conclusions were also fairly similar. The general consensus was that as far as performanace was concerned, long pipelines were beneficial until the pipestages became too short as to create the situation where the overhead of the pipeline stage limits the magnitude of the clock rate increases, and the increase in clock frequency can no longer cover the decrease in IPC. There was a consensus that a depth of between 6 and 8 FO4 logic gates constituted a lower bound in logic depth per stage. IBM examined the application dependence on pipeline depth, and concluded that the “optimal range” appears as a somewhat lopsided bell curve that centers around 21-24 stages.

The Intel paper was much more aggressive in its conclusions, as the paper presented a theoretical P4-like architecture, and the estimates give here was that in order to obtain a 2X increase in frequency, the pipeline depth would have to be increased from 20 to 52 stages, and the 150% increase in pipeline depth would yield a 100% increase in frequency, and retain 72% of the IPC of the 20 stage P4-like architecture. From the tone of the paper and presentation, it appears likely that the next generation x86 processor from Intel will have deeper pipelines still. These papers also discussed the non-linear characteristic of design effort versus pipeline depth. (i.e. it takes a lot more than 100% increase in design effort to design a pipeline that is 100% longer). Still, if power consumption concerns can be ignored, design resources are infinite, and highest performance is the goal, then it appears that pipeline depths can be stretched longer still to increase performance.

I went with the conference crowd to a cruise into Prince William Sound on Monday evening. It was a 3 hour cruise. A 3 hour cruise. No Ginger or Mary Ann, but plenty of professors. I spent some time chatting with Andy Glew, and I mentioned that from time to time there would be a post on comp.arch lamenting his absence. Andy replied that he’s not well setup to read comp.arch from Intel at this time, and when he gets home, he’s got his wife and a new baby to contend with. However, he promises that he will pick comp.arch back up soon, as he would like to get back into the groove of things and he would like to start hiring again. He had found that comp.arch to be a good place to hire architects from and would like to do so again in the future. We then spent a few minutes discussing the qualities that he wants in his architects, and the qualities exhibited by the P6 architects that he had worked with. Basically his take on the topic was that he likes to hire people that can manage complexity well. Architects can be trained about architecture, but the ability to manage complexity is perhaps a far more valuable attribute to him. He gave as an example OS programmers. The reason given was rather simple, “What else is a processor but a project with multi-million lines of code?” The cruise was rather enjoyable, as the ship slowly wandered about in the bay, passing by glaciers, waterfalls created by melting glaciers, and the wildlife in the area. Unfortunately the food was rather less enjoyable, as the fish was served lukewarm, and the vegetables were still cold and icy.

Technical Paper Sessions: Day 2 Observations (Tuesday, May 28th)

Dr Robert Colwell’s (Intel P6, Willamette Architect) keynote speech on Tuesday Morning was very well received. His injection of self deprecating humor and interesting slides were very popular with the crowd. His implicit jab at Intel’s “other great architecture” also elicited embarrassed smiles from architects that work on Intel’s “other great architecture”, as well as bursts of laughter from the general audiance. It was interesting and a bit surprising for me to hear of his laments on the clock rate/power consumption/performance curve on the P4 line of processors, in a line similar to those often seen on usenet discussion groups, especially since he was the person ultimately responsible for the direction of the P4 architecture. He promised to make the slides available, and the slides may be available on the web somewhere sometime soon.

During lunch on Tuesday, Todd Austin ran over to our table rather excitedly and he flipped open his notebook and showed a web page to Bruce. The web page (formerly located at http://www.theinquirer.net/26050204.htm) was from “The Inquirer”. The article on the web page roughly summarized ISCA-29 with a couple hundred words, but gave heavy play to the DRAM tutorial. We then spent the next 10 minutes discussing whether the mention in the Inquirer helps or hurts our academic credibility. No conclusions were reached on this topic.

The reception Tuesday evening was very productive. Unfortunately I was engrossed in a discusion about how to design a DRAM based cache with 4 way set associativity and a N-MRU replacement algorithm. By the time I finished, the food was all gone. I was not particularly happy with this particular development. I was also asked if I had heard of the use of multi-valued logic in DRAM cells. My response was no. There were discussions on the use of multivalued logic on the wires, and multivalued logic in Flash memory, but I hadn’t yet heard of such use of multivalued logic in DRAM.

Since the Hilton charges $155 + $12 in taxes for an evening’s stay, I decided to leave early, and skipped the Wednesday sessions that included the Alpha Tarantula paper. So immediately after the Tuesday evening reception, I bid farewell to a few folks, got in the taxi, and got on the red eye and back to the east coast.