I think that the following are the main points of interest href="http://www.vmars.tuwien.ac.at/people/puschner.html">Peter Puschner
tried to get drilled into our skulls. The course focuses on the worst case
analysis, and for that there are three major items one needs to take into
account: the piece of code to analyse, the input it consumes and the hardware
it runs on. Giving the fact the most code consumes input means that there is
some state associated with it, that determines the paths takes in the static
code graph. Peter clearly stated that the input should be part of the problem
specification, which often complicates the analysis. Additionally, the hardware
has some associated state as well (think caches, branch prediciton, etc.) that
influences the timing of each task we want to analyse. Different instances of
actions in the task have different durations, and as such the sequence of the
actions carries out during each task becomes the important factor. It was
clearly illustrated that measurements are not adequatefor dealing with worst
case scenario’s. I think the lesson to take away from the first class is that
there is no way to measure WCET, one must therefore analyse the program.

The second lesson dealt with a number of approaches for determining the WCET:
tree-based (from the program graph), path-based (potential dynamic execution
paths), and IPET based. Tree-based WCET does not scale well, path=based does,
but that has the disadavantage of getting quite complex as the program size
increases. To deal with this, the IPET technqiue can be used, in which we
desribe the flow of control by using a number of equations that constrain the
possibilities: program flow going ionto a node, must come out of it, so this
yields a number of equations that state how many times an edge can be taken.
The drawback here is that solving the equation using ILP is NP hard in general.
Another technique discussed was the modelling of execution time by mapping a
sequence of instructions to an execution time. This however requires
information on the hardware timing to deal with the various hardware
enhancements to the processor (think pipelines, caches, out=of-order execution,
…). I think this seems to have quite some non-deterministic aspects. Peter
then moved on to show how one can model pipelines, to be used in the WCET
analysis, as well as how one can model caches within the IPET framework. The
takeway lesson here is that there is no straighforward technique to estimate
the WCET, and the most powerful techniques must use hardware timing
information, which is a hard problem in itself.

The third lesson dealt almost exclusively with the modeling of the caches,
moving from a concrete state to an abstract state, which can be reasoned about.
Peter identified 4 essential categories for the analysis in a cache model:
always hit, always miss, globally persistent, locally persistent, plus one
leftover category. For each of these categories, there is a different semantics
for the start state, the update function and the join function on the abstarct
cache model. Finally, we received an introduction to potential timing anolalies
that can occur and how to deal with those.

In the fourth lesson, the focus moved to measuring execution times. Here the
key takeway was that it is very unlikely that the hardware will be set to the
worst case state for executing the application, leading to (at times gross)
underestimates of the WCET. For a WCET bound, more systematic techniques are
required. One of the best performing WCET measurements tools relies on genetic
algorithms for generating the input that drives the WC scenario. Still, for the
benchmarks shown, there can be quite a large discrepancy between the
analytically obtained WCET and the WCET obtained through use of a GA. Other
potential techniques include a probabilisitc approach and program segmentation
with a path based analysis.

In the final class on Friday, Peter discussed some issues with time-predicatble
sofware and hardware. Predicates, transforming execution paths, etc. can be
used to get more reliable WCET bounds. The major takeaway here was that the
classical analysis where one focuses on the mean execution time (with its
distribution, like we did in href="http://www.itkovian.net/base/statistically-rigorous-java-performance-evaluation">our
Java stats paper at OOPSLA) is not
going to work at all for a WCET analysis. Peter also argued for better WCET
bounded hardware, or at least hardware that could make the WCET analysis
easier.

View Larger Map

The facilities are sweet, the food is good (so far), and there is a neat swimming pool. And free WiFi.

Case in point: my room. It had WiFi, and UTP jacks at the desk and the toilet

The building had a very neat design, using rusty metal and metal moveable shutters.

The pool was really enjoyable, even at 1:00 AM, though people tended to dive in with their clothes on at that point.

Next to the main conference hotel, there was an older building, where we held our poster session. And where the wedding party we crashed on Friday was held.

Over the next few days, I’m going to post the notes I have taken in the courses I am attending. Nothing fancy, just what I jotted together.

If you are on twitter, you can also grab the posts tagged with #acaces09, since Alasdair Hawsthorne (previously with Transitive) asked us to use them during his invited talk on Monday evening.

As I have been appointed as the official photographer of the event, pictures will be available in large quantities on flickr. There is also a flickr ACACES group pool where you can add notes, tag the pictures and add your own.

Deciding to go with the shop recommend by the apartment owners, we set out to go rent some equipment — which turned out to be subpar to last years, which we got at the Intersport shop, at a similar price, if memory serves well (it usually does not). We were driven over the by the shop owner, yet we had to return on foot, as the other friendly folks who took the ride with us, kindly forgot to remember we were still at the shop when they were brought back. A minor setback, I thought, taking the opportunity to go fetch ski passes. Without any success, as I did not have Elias passport with me. Dang. Back to the apartment, and then on a quick run back to the closest lift for buying passes.

This year, we enrolled Elias in the ski school; this time starting at the top of the CityXpress lift, rather than going to Schuttdorf. This mean he had to take the CityXpress lift to get to the school, rather than get on a ski bus. Which was way more cool for him. He did remarkably well, shifting groups three times, each time moving on to a better group, or rather different teacher for more advanced skiing craziness. The first two days, he stayed at the Kindergarten site, where he was trained in ploughing to stop and make turns on a very gentle (read: flat) slope. It also allowed him to get back up this slope using the automated floor matt.

Of course, there also was the obligatory fun in the snow with Lize, his niece.

On Tuesdays, he was shifted with several other children to form a group that was allowed on a bit steeper slope, where they had to climb back up themselves using a rope to stay upright and make it more likely the ascent would succeed without meeting the surface face down. There he further practiced making turns, gently skiing around sticks planted in the snow and to stop at the bottom of the rope.

The fourth day, he again had a different teacher, who taught them the intricacies of turning and sent back on kid who did not seem to understand the concept of shifting weight to a single leg and putting pressure there to make a turn (the poor fellar was Russian (I guess), and so he might have had a lot of difficulties understanding either English, Dutch or German). This was the only day with a clear sky and lots of sun, and we had lunch outside.

In the afternoon, they moved with 6 kids to a real slope, with a real (albeit very irritating (for adults)) lift. After classes we did a few extra practice runs, so Elias would be well prepared for the race on Thursday. It turned out that his race was scheduled immediately after the daily warmup dance.

And he did very well! Two kids (Elias and Holly) managed to make all the turns in the right way around the right flags, whereas the others — understandably, since they wanted to go fast — chose to ignore either flags or turns or went around the wrong side, thus helping them finish quicker (no penalty seconds were awarded . Elias got down in about 28 seconds. The real bonus of the day was when his teacher told us we could take him up the blue slope with the chairs lift. And so our skiing week ended in success! On Friday, in quite bad weather, we went up and took Elias down a blue slope, where he did very well. He fell down four or five times, and we skied for about 35 to 40 minutes.

In the locker room, we ran into Holly:

Due to the snowfall, there were already numerous small bumps, and 10 cm of fresh white powder. So we took it slowly, making sure he enjoyed himself. After lunch, I decided to go down another blue slope to finish the day. Halfway, he got a bit fed up with falling down, so it took us a bit longer than expected. But in the end, all was well (I did help him on the last part, as the slope was blue/black there, so a bit steeper than he was used to).

The last day, we checked out the town once more, buying some gifts and stuff for Elias and Nathan. I had planned on purchasing a pocket knife, but that money will now be spent on Munchkin Quest

Riding back, we had to check out the news we missed: