I’m very happy with Southwest Airlines on this trip. Still cattle car boarding, but the legroom is better than any airline (United, American, Continental, Delta, Northwest) that I have flown recently. My shoulders are still wider than the seats, but that’s true of any airline below first class. (And I never travel first class.)
Here’s a nice touch: by Southwest’s gates in Austin’s Bergstrom airport, they have quite a few (8 that I can see) cabinets with power outlets besides unusually comfortable chairs. They even have USB, to charge up your phone. This is a welcome change from the usual airport “socket hunt”, having to walk all around to find an outlet, often far distant from your gate and requiring you to sit on the floor.
--
Peeve: pay internet.
At the Hilton in Austin: bad enough that I was paying twice what I should have, but that I had to pay 14$/day for Internet in my room as well? Or, rather, I did not pay, except two nights. The conference had free wireless, but with 150 slots for more than 500 people it was usually unavailable. Trouble is, my coworkers expect me to be connected. Now, here I am at the Austin airport, reluctant to pay for Boingo hotspot access. If I did pay, I could have my expense report (which must be completed online via a web app) before I got home. But I won’t pay, so even that trivial task piles up. If I were still at my hotel room I would have the last few of my second 24 hours. It’s not so much the paying for Internet, as the paying for it repeatedly because I am moving around. I swear I will get a data plan for my phone…
--
My new laptop computer has no privacy screen. That has a chilling effect. Must order one. I wonder why my company’s IT department doesn’t automatically provide one. I suppose that I should have ordered one as soon as I got my machine.
The chilling effect: so much for reading email at the conference, when it is visible to all behind me. I wanted to use the free internet at the conference, rather than the pay internet in my room. So much for reading ion the plane. I was willing to risk blogging, but then a few calendar reminders popped up.
Friday, June 26, 2009
Blogging from ISCA: couldn't keep up
I couldn't keep up. Not only is my typing limited, but my laptop PCs could not keep up.
I am not a touch typist, although I am a very fast hunt and pecker. It's not clear how much value there is to stream of consciousness blogging while I am watching a talk. Why not just get the slides from the speaker? There's value in recording answers to audience questions and off the cuff remarks that won't be on slides. But it is not clear that I will not be hurting myself by making such recordings. E.g. the remarks by HP's Kauffman about Intel's Atom in datacenters.
My company provided HP 8530 laptop is fast enough. When it is up. But when it takes 15 minutes to come out of a power save mode (as mine just did), it is darned easy to miss most of a 20 minute talk.
My OLPC XO is fast enough, and comes out of standby more quickly. I ran into a problem with fairly large text files - at a certain file size it slowed down to a crawl. Even slower than my work PC.
Anyway, enough excuses. My attempt to blog ISCA was not a success. Too bad.
I am not a touch typist, although I am a very fast hunt and pecker. It's not clear how much value there is to stream of consciousness blogging while I am watching a talk. Why not just get the slides from the speaker? There's value in recording answers to audience questions and off the cuff remarks that won't be on slides. But it is not clear that I will not be hurting myself by making such recordings. E.g. the remarks by HP's Kauffman about Intel's Atom in datacenters.
My company provided HP 8530 laptop is fast enough. When it is up. But when it takes 15 minutes to come out of a power save mode (as mine just did), it is darned easy to miss most of a 20 minute talk.
My OLPC XO is fast enough, and comes out of standby more quickly. I ran into a problem with fairly large text files - at a certain file size it slowed down to a crawl. Even slower than my work PC.
Anyway, enough excuses. My attempt to blog ISCA was not a success. Too bad.
Monday, June 22, 2009
Blogging from ISCA: limted WiFi
Only 150 connections for 500 people.
To reduce contention, will blog offline to a text file.
What were we saying about ubiquitous connectivity? You only get that if using cell services.
To reduce contention, will blog offline to a text file.
What were we saying about ubiquitous connectivity? You only get that if using cell services.
Sunday, June 21, 2009
Blogging from ISCA: WDDD: Is TM easier than locks?
Is TM really easier than locks? Programmers must still write critical sections.
Experiment: measure on a class of inexperienced programmers in a UT OS class.
The problem: sync gallery: a rogue's gallery of synchronization. Rogues shoot paint balls in lanes. Cleaners. Etc.
9 different variations: {single lane, two lane, cleaner thread} X {coarse, fine, TM}
TM support: Year1 DSTM2 (Herlihy 06). Year2 JDASTM (Ramadan 09). Library, not langage support.
DSTM syntax baroque. "thread.doit(method)" == thread.execute_method_as_transaction(method).
JDASTM: txbegin, txend.
Survey included experience, hours, rankings
147 students
Hours reported:
single lane: coarse grained > tm > fine grain. They did coarse grained first.
Best syntax: coarse > (TM|Coarse) > fine > (fine|conditions)
Easiest to think about: coarse > fine|conditions > tm
Defects tested using condor.
Errors taxonomy:
---
Wants support for atomic blocks.
---
I asked if there were programmer visible abort actions - if there was contention. There was not.
AFG opinion: abort actions will be a source of errors. Hard to test. I like transactions, but I hate increasing non-determinism.
Audience Q: learning curve. Why not teach TM first, and then translate into locks?
I was surprised at syntax preference for coarse grained locks. IMHO txstart/txend is almost equivalent to lock/unlock coarse grained locks. The presenter was similarly puzzled.
Experiment: measure on a class of inexperienced programmers in a UT OS class.
The problem: sync gallery: a rogue's gallery of synchronization. Rogues shoot paint balls in lanes. Cleaners. Etc.
9 different variations: {single lane, two lane, cleaner thread} X {coarse, fine, TM}
TM support: Year1 DSTM2 (Herlihy 06). Year2 JDASTM (Ramadan 09). Library, not langage support.
DSTM syntax baroque. "thread.doit(method)" == thread.execute_method_as_transaction(method).
JDASTM: txbegin, txend.
Survey included experience, hours, rankings
147 students
Hours reported:
single lane: coarse grained > tm > fine grain. They did coarse grained first.
Best syntax: coarse > (TM|Coarse) > fine > (fine|conditions)
Easiest to think about: coarse > fine|conditions > tm
Defects tested using condor.
Errors taxonomy:
- lock ordering - 8%
- lock cond - 7%
- lock forgot - 15%
- cv exotic - 8%
- cv use - 11%
- tm exotic - 3%
- tm forgot ..
- tm order - not really a bug ..
---
Wants support for atomic blocks.
---
I asked if there were programmer visible abort actions - if there was contention. There was not.
AFG opinion: abort actions will be a source of errors. Hard to test. I like transactions, but I hate increasing non-determinism.
Audience Q: learning curve. Why not teach TM first, and then translate into locks?
I was surprised at syntax preference for coarse grained locks. IMHO txstart/txend is almost equivalent to lock/unlock coarse grained locks. The presenter was similarly puzzled.
Blogging from ISCA: WDDD: Emmett Witchel: Mondriaan-like
Wrote paper: lots of people need metadata. Mondriaan. Pixie dust.
Mondriaan is a general solution, but must be engineered to fit a specific problem.
Mukti-paper projects. Emphasize novelty. Features disappear because they didn't work; lack of space; lack of novelty.
Mondriaan gave metadata for each 32-bit word. No alignment restrictions. No warts.
MMP hardware: like page table. Perm Table Base. Perm Table. Protection Lookaside Buffer.
Mondriaan tradeoffs:
Space:
PLB refill costs: minimize refills / maximize reach.
SW overheads writing table entries: infrequent updates and/or simple table updates.
Mondriaan stored permissions data, but can handle arbitrary metadata.
Talk is something like a design rationale for Mondriaan. 2 bit permissions for each word. (Byte?) Run length encoded. Zones <= 4 for 16 words. Fallback to pointer to a bitmap entry.
(AFG: I'm not interested in zones. Bad security model. But the metadata mechanisms may be interesting.)
RLE made writes slow.
Mondrix wrote permissions table entries a lot. RLE made it slow. Fell back to using bitmap entries. Coarser grained protection. Page granularity.
Emmett walks through examples of other work using Mondriaan-like metadata.
Colorama. Luis Ceze HPCA 2007. Explicitly uses Mondriaan. Colors data structures.
Measured dynamic memory allocations (malloc) every 1,900 instructions.
Loki. OSDI 2008. All data has 32 bit security tag. Tags per page, tags per word.
Concusion:
Balance space, PLB reach, write overhead.
PLB reach neglected.
Measuring write overhead maybe too hard for research project: suggests counting, multiplying by a cost estimate.
Audience Q: Dave Christie. PLB coherency? A: Mondrix did not deal with.
Dave Christie of AMD (also of my high school) asked about single threaded coherency and multithreaded. It sounds like he has some familiarity with the issue.
I think that it is also interesting that David chose this talk to attend.
Colorama: Gabriel Loh, Luis Ceze, Emmett: not totally practical, but interesting. Luis: had some deadlocks, might need TM support as well.
Mondriaan is a general solution, but must be engineered to fit a specific problem.
Mukti-paper projects. Emphasize novelty. Features disappear because they didn't work; lack of space; lack of novelty.
Mondriaan gave metadata for each 32-bit word. No alignment restrictions. No warts.
MMP hardware: like page table. Perm Table Base. Perm Table. Protection Lookaside Buffer.
Mondriaan tradeoffs:
Space:
PLB refill costs: minimize refills / maximize reach.
SW overheads writing table entries: infrequent updates and/or simple table updates.
Mondriaan stored permissions data, but can handle arbitrary metadata.
Talk is something like a design rationale for Mondriaan. 2 bit permissions for each word. (Byte?) Run length encoded. Zones <= 4 for 16 words. Fallback to pointer to a bitmap entry.
(AFG: I'm not interested in zones. Bad security model. But the metadata mechanisms may be interesting.)
RLE made writes slow.
Mondrix wrote permissions table entries a lot. RLE made it slow. Fell back to using bitmap entries. Coarser grained protection. Page granularity.
Emmett walks through examples of other work using Mondriaan-like metadata.
Colorama. Luis Ceze HPCA 2007. Explicitly uses Mondriaan. Colors data structures.
Measured dynamic memory allocations (malloc) every 1,900 instructions.
Loki. OSDI 2008. All data has 32 bit security tag. Tags per page, tags per word.
Concusion:
Balance space, PLB reach, write overhead.
PLB reach neglected.
Measuring write overhead maybe too hard for research project: suggests counting, multiplying by a cost estimate.
Audience Q: Dave Christie. PLB coherency? A: Mondrix did not deal with.
Dave Christie of AMD (also of my high school) asked about single threaded coherency and multithreaded. It sounds like he has some familiarity with the issue.
I think that it is also interesting that David chose this talk to attend.
Colorama: Gabriel Loh, Luis Ceze, Emmett: not totally practical, but interesting. Luis: had some deadlocks, might need TM support as well.
Blogging from ISCA: CARD: Panel Session, Multicore Programming
Arvind, David August, Keshav Pingali
Phrased as a debate between A and P
The motion: How should the potential of multicore processors be extracted by applications programmers?
Implicit vs. Explicit
...composability...
Too much detail => programming to hard. But is there an appropriate level of detail.
(AFG: infinite fine grain CPUs. Expose memory, cache, line size.)
Is expressing non-determinism essential to ||?
Speculation? Or not?
Debaters: August for (implicit), Pingali against (implicit, for explicit).
The motion: How should the potential of multicore processors be extracted by applications programmers.
NOT parallel programming
NOT parallel compilers
FOR implicitly parallel programming, + parallelizing compilers.
What is implicitly parallel programming.
E.g. "inline" directive on function. - explicit. Implicit inlining done automatically by compiler. Often better than human.
Tim Mattson's list of >150 explicit parallel programming languages/systems.
Q: Is explicit parallel programminginherently more difficult than implicit parallel programming?
Quotes Pingali PLDI, quoting Tim Sweeney, who said that Unrel || tripled SW development.
SQL: ... implicit parallel. Another Pingali quote.
Example: commutative annotation. e.g. indicating orderof rand calls between loop iterations. "It's okay if I get my random numbers out of order."
SPECint2000, modified ~50 lines of code of 2M. "Restored the trend" ...
Is it important to be able to express non-dererminism: YES.
Speculative Execution? YES
Is explicitly || needed by anyone other than compiler writers and systems programmers? NO
Only explicit indications needed are of the form function/anti-function (ad-to-list/remove-from-list).
Allies: Church Turing Thesis
Full Employment for Compiler Writer's Thesis.
For explicit.
Necessary evil for applications programmers writing irregular programs, e.g. linked data structures.
YES to non determinism. YES to speculation. (Data value dependent parallelism.)
Delaunay Mesh Refinement.
Don't care non-determinism.
Parallelism depends on run-time analysis. Compiler can't...
(AFG: can compiler generate the code to do the analysis?)
Galois model (non deterministic set iterators.)
Collections approach: libraries implemented parallel by experts,
used by higher level programmers. E.g. database B-trees.
Problems: no fixed set of datastructures.
Even generic datastructures need to be tuned.
In many applications the API functions do little computation. Little time in the datastructures. (AFG: but ||ing e.g. a map execute-over-all...)
A: Are there more libraries than programs?
P: Doesn't matter. App programmer still needs to optimize data structure for his app.
A: since in Q&A, I won't explain how you were wrong.
A: Are there patterns? Cliches? Compiler support for same.
In the past when compilers were a 15% solution, not enough money to develop.
(AFG: how many compilers handle even the Gang of 4 patterns? Let alone parallel programming.)
P: functional languages, compilers, haven't gone anywhere over the years.
A: analysis wrong crutch to lean on. E.g. perl (perlbmk). Parallelism in input set. No amount of analysis, neither compiler nor Perl programmer, will know ||ism.
Runtime analysis.
Mattav (sp?) UT prof: Parallelism not a problem. Implicit works. Explicit works. Tuning is the problem.
A: compiler needs to observe effects of transformation. Run-time feedback.
Mattav summarized P and A's response as "both of you are saying implicit for locality".
I asked my STL question.
To P: not using STL grounds for firing. Customizing grounds for firing. Maybe just fire them all / wait until ew generation hired?
P: STL doesn't parallelize. Is just the datastructure. (He didn't follow the map applicator). Joe programmers, doman specific. Stephanie programmers, ||. (He didn't say ninja/padawab.)
To A: people using iterators, but not map application. Can your compiler convert?
A responded: there exist tools that change datastructure, e.g. list to vector,
or to skiplist.
...
Audience Q: to A: where do you draw the line between explicit ad explicit.
A: if the annotation brings information that cannot be determined automatically, that's implicit. (AFG: copout. That's explicit. But nevertheless still appropriate.)
If a course is important enough to teach to grad students, why not teach to freshmen?
Should || programming be taught to freshmen?
A: explicitly || programming taught to junior/senior (3rd/4th year)
P: Teach about parallelism in algorithms first. Later, implicit parallel at Joe level.
Later still, fully explicitly parallel.
Applications programmers do not need to write explicitly parallel programs.
The motion does not carry.
Phrased as a debate between A and P
The motion: How should the potential of multicore processors be extracted by applications programmers?
Arvind: Intro
Implicit vs. Explicit
...composability...
Too much detail => programming to hard. But is there an appropriate level of detail.
(AFG: infinite fine grain CPUs. Expose memory, cache, line size.)
Is expressing non-determinism essential to ||?
Speculation? Or not?
Debaters: August for (implicit), Pingali against (implicit, for explicit).
The motion: How should the potential of multicore processors be extracted by applications programmers.
August
NOT parallel programming
NOT parallel compilers
FOR implicitly parallel programming, + parallelizing compilers.
What is implicitly parallel programming.
E.g. "inline" directive on function. - explicit. Implicit inlining done automatically by compiler. Often better than human.
Tim Mattson's list of >150 explicit parallel programming languages/systems.
Q: Is explicit parallel programminginherently more difficult than implicit parallel programming?
Quotes Pingali PLDI, quoting Tim Sweeney, who said that Unrel || tripled SW development.
SQL: ... implicit parallel. Another Pingali quote.
Example: commutative annotation. e.g. indicating orderof rand calls between loop iterations. "It's okay if I get my random numbers out of order."
SPECint2000, modified ~50 lines of code of 2M. "Restored the trend" ...
Is it important to be able to express non-dererminism: YES.
Speculative Execution? YES
Is explicitly || needed by anyone other than compiler writers and systems programmers? NO
Only explicit indications needed are of the form function/anti-function (ad-to-list/remove-from-list).
Allies: Church Turing Thesis
Full Employment for Compiler Writer's Thesis.
Pingali
For explicit.
Necessary evil for applications programmers writing irregular programs, e.g. linked data structures.
YES to non determinism. YES to speculation. (Data value dependent parallelism.)
Delaunay Mesh Refinement.
Don't care non-determinism.
Parallelism depends on run-time analysis. Compiler can't...
(AFG: can compiler generate the code to do the analysis?)
Galois model (non deterministic set iterators.)
Collections approach: libraries implemented parallel by experts,
used by higher level programmers. E.g. database B-trees.
Problems: no fixed set of datastructures.
Even generic datastructures need to be tuned.
In many applications the API functions do little computation. Little time in the datastructures. (AFG: but ||ing e.g. a map execute-over-all...)
August counterexamination of Pingali
A: Are there more libraries than programs?
P: Doesn't matter. App programmer still needs to optimize data structure for his app.
A: since in Q&A, I won't explain how you were wrong.
A: Are there patterns? Cliches? Compiler support for same.
In the past when compilers were a 15% solution, not enough money to develop.
(AFG: how many compilers handle even the Gang of 4 patterns? Let alone parallel programming.)
P: functional languages, compilers, haven't gone anywhere over the years.
A: analysis wrong crutch to lean on. E.g. perl (perlbmk). Parallelism in input set. No amount of analysis, neither compiler nor Perl programmer, will know ||ism.
Runtime analysis.
Audience
Mattav (sp?) UT prof: Parallelism not a problem. Implicit works. Explicit works. Tuning is the problem.
A: compiler needs to observe effects of transformation. Run-time feedback.
Mattav summarized P and A's response as "both of you are saying implicit for locality".
I asked my STL question.
To P: not using STL grounds for firing. Customizing grounds for firing. Maybe just fire them all / wait until ew generation hired?
P: STL doesn't parallelize. Is just the datastructure. (He didn't follow the map applicator). Joe programmers, doman specific. Stephanie programmers, ||. (He didn't say ninja/padawab.)
To A: people using iterators, but not map application. Can your compiler convert?
A responded: there exist tools that change datastructure, e.g. list
or to skiplist
...
Audience Q: to A: where do you draw the line between explicit ad explicit.
A: if the annotation brings information that cannot be determined automatically, that's implicit. (AFG: copout. That's explicit. But nevertheless still appropriate.)
Arvind's close
If a course is important enough to teach to grad students, why not teach to freshmen?
Should || programming be taught to freshmen?
A: explicitly || programming taught to junior/senior (3rd/4th year)
P: Teach about parallelism in algorithms first. Later, implicit parallel at Joe level.
Later still, fully explicitly parallel.
Vote
Applications programmers do not need to write explicitly parallel programs.
The motion does not carry.
Blogging from ISCA: I fell behind
I fell behind. Laptop battery died, couldn't find a plug. Session hopped. I'll write more when I get a chance.
TBD:
FutMem tutorial
HP Kauffman datacenters.
TBD:
FutMem tutorial
HP Kauffman datacenters.
Subscribe to:
Posts (Atom)