Going deep and learning to love the haters Advice for graduate school Kay Ousterhout UC Berkeley PhD
Depth fi rst Starting grad school Draw an outline Starting a project Ask questions Log log log Running experiments Love the haters Getting feedback Write sh***y slides Presenting
Depth First
Pick a project, any project Depth fi rst
“Facts precede concepts” Depth fi rst
Go deep (learn as much as possible, even the boring stu ff ) Depth fi rst
2013: Monotasks: promising performance improvement How much might they improve performance by? Pretty confusing performance measurements Concurrently: trying to publish work based on Yahoo! traces Depth fi rst
2013: Monotasks: promising performance improvement 2015: NSDI paper on understanding performance Monotasks more useful as mechanism to reason about performance? Depth fi rst
Pick a project, any project “Facts precede concepts” Go deep Depth fi rst
Draw an outline
l a v e Make an outline Write it as questions 7.3 How do task constraints a ff ect performance? 7.4 How do scheduler failures impact job response time? 7.6 How does Sparrow compare to Spark’s native, centralized scheduler? 7.7 How well can Sparrow’s distributed fairness enforcement maintain fair shares? 7.8 How much can low priority users hurt response times for high priority users? 5.2 How much to stragglers a ff ect job completion time? 5.3 Are these results inconsistent with past work? Draw an outline
Draw all of your graphs Ask: Is ths the graph we want in the paper? Do you agree these are the expected results? Is there any thing else I should graph? Draw an outline
Draw all of your graphs Fail fast Know what to measure Sanity Draw an outline
“Use your intuition to ask questions …not to answer them”
Measure one level deeper Corroborate results with multiple views of data Running experiments you trust is hard Distrust good results Ask questions
Log log log
Script experiments: Copy con fi guration Copy Git commit history Log log log
Keep a log on a computer One useful thing for debugging is vmstat -SM 1 , which basically runs free -m at regular intervals and prints the output. Sangjin suggested this: echo 1000 > /proc/sys/vm/vfs_cache_pressure Another idea in a similar vein is to attempt the suggestions described here: http://serverfault.com/questions/516074/why-are-applications-in-a-memory- Also re-launch as ext4 / xfs. Also consider turning journalling o ff ; this means that for every write, a bunch of extra data needs to be written. To figure out whether there’s journalling in the file system, do dumpe2fs /dev/xvdb To turn journalling o ff , you can run this command: tune2fs -O^has_journal /dev/xdy’’ Write-optimized (I used Latex. Don’t do this.) Log log log
Love the haters
You are e a sc scien entist st. . No Not a sa sales es per erso son. Love the haters
Talk to the people who hate your work No No em email Assume they’re correct Explain it back to them Love the haters
Put the limitations in the paper jobs on higher priority users. Constraints Our current design does not handle inter- job constraints (e.g. “the tasks for job A must not run on racks with tasks for job B”). Supporting inter-job con- straints across frontends is difficult to do without signif- icantly altering Sparrow’s design. Gang scheduling Some applications require gang scheduling, a feature not implemented by Sparrow. Gang scheduling is typically implemented using bin-packing algorithms that search for and reserve time slots in which an entire job can run. Because Sparrow queues tasks on several machines, it lacks a central point from which to perform bin-packing. While Sparrow often places all jobs on entirely idle machines, this is not guaranteed, and deadlocks between multiple jobs that require gang scheduling may occur. Sparrow is not alone: many clus- ter schedulers do not support gang scheduling [8, 9, 16]. Query-level policies Sparrow’s performance could be Love the haters
Write sh***y slides
Outline the presentation fi rst (every slide should look bad) Give this version to someone you trust Write sh***y slides
Outline the presentation fi rst (every slide should look bad) Give this version to someone you trust Write sh***y slides
Outline the presentation fi rst (every slide should look bad) Give this version to someone you trust Write sh***y slides
Outline the presentation fi rst (every slide should look bad) Give this version to someone you trust Write sh***y slides
Pick any project, Depth fi rst learn as much as possible Starting grad school Draw an outline Draw graphs, get buy-in Starting a project Measure deeper Ask questions Fear good results Log log log Save commits + conf, Ctrl+F! Running experiments Talk to the haters Love the haters Getting feedback Put limitations in the paper Get feedback early Write sh***y slides Avoid paralysis Presenting
Don’t give up
Pick any project, Depth fi rst learn as much as possible Starting grad school Draw an outline Draw graphs, get buy-in Starting a project Measure deeper Ask questions Fear good results Log log log Save commits + conf, Ctrl+F! Running experiments Talk to the haters Love the haters Getting feedback Put limitations in the paper Get feedback early Write sh***y slides Avoid paralysis Presenting
Recommend
More recommend
