Subject: Lecture Notes From: "Lin Xu" Date: Fri, 6 May 2005 16:15:42 -0700 To: CS Lecture (notes by cs162-dk, Lin Xu) ---------- Administrivia: No lecture on Monday! Assignment: "Hints for computer system design" by Butler Labson (in reader) Two things to talk about today: 1) Design principles 2) Grad school -------------------------------------- Design principles -------------------------------------- Butler is Berkeley faculty, who around 1960 started the "Berkeley computer corporation". It lasted a 2 or 3 years then folded. Never sold anything nor built anything. What does this mean? Research is hard, and even harder to get good results (or even any results). To have a research lab, means having monopoly at the leading research facility. * The difference between US and Japanese development * Japanese were doing better then the US because they kept on innovating with new ideas. BUT, research is hard -> Japanese made very little money Examples: "5th generation" AI stuff: Japanese put a lot of money into universities, research, etc. Lots of money -> stupid projects were funded, eg. LISP stuff, "out there" stuff. Lead to problem, everytime toshiba, etc. added new people on to the teams, they had to re-educate. Expensive! Tron Project is a specific example. Ken Sakumura was at the Uni. of Tokyo, he was designing computer architecture: * Tron OS was Tron BIG * ITron was this embedded Tron version Ended up writing an in house OS. (Gave up and wrote a movie instead?) Another example: Computer digital readers. If they spent a little more time instead of killing project would have been better then US. BUT: japanese still succeeding: so much money getting pumped in, invest in everything = successes by law of large numbers. Response: US invests only in "good" things. Now: US good at doing IP (intellectual property), China does manufacturing... --------------------------------------- Hints for computer system designers --------------------------------------- * 2nd system is always better: "Let's build the best system, ever, the FIRST time around". Leads to horribly complicated/ambitious system, too hard to make, ends up being cancelled. Example: Multix uses CTS. Then they decided to build best time sharing system ever. They got it to run, but, when it was stable, the market window had passed! GE is stupid. Honeywell buys them out. It didn't fail completely because developers were very smart. * Interfaces should be small and complete Small = understandable = makes system useable Most important part of design! (Also most difficult.) Unix is very non userfriendly, and Windows _tries_ to be user friendly. Interfaces use English mostly because everyone uses it. (Ed note: really? What happened to internationalization?) * KISS - Keep it simple, stupid. Do a few things, and do it well. This is because you can't Do everything. If it's complex, make as simple as possible. * Get it right. Neither abstractions or simplicity is subsitute for getting it right! * Make it fast. Make common case as fast as possible. Powerful, complex ops are usually wrong. * Find the bottleneck before optimizing * Don't hide power Purpose of the OS is to give you extended machine, not to hide everything behind (sometimes) useless abstractions that aren't needed * Low overhead interfaces * Keep interfaces stable Good not to change interfaces: IBM, Intel, MS, successful Because they keep everything running. (Ed note: eg, Intel 64bit processor failed, AMD x64 successful.) * Compatible interfaces If you do have to change interfaces, make sure it's still Compatible. * Plan to throw one away, you will have to (Ed note: I don't agree with this!! Refactoring is far better. Too much knowledge in code earned with months/years of debugging, etc., to waste doing it again!) First implementation will have to be redone from scratch. Building things from scratch is very hard; the second time around, it's a lot easier. It's hard to take a system that's only slightly wrong and "fix" it - usually end up recreating the whole thing. Plan to prototype. The second time around... * Review old decisions With full system, realize optimizations, assumptions are bad: Examples: memory size? Paging - important, goes through entire OS/memory hierarchy. * Keep secrets (Ed. note: you mean, learn to abstract? Pfft.) Clients won't know what you don't tell them - also, don't want people to just bypass your interface code. If you keep secrets, they won't know about certain things, can't assume on internal stuff. * 1 crash a week is better for 20% performance (Ed. note: even nowadays? cf MS bashing, Linux server share growth) * Cache answers to things * When in doubt, brute force it. * Rapid response for user - delay actions, but show response immediately * Batch processing is good; incremental processing has worse performance. * Make sure nothing is loaded more then 2/3s (implies buying gigs of ram, etc....) * Shed load, rather then thrashing: Bob Morris said "each terminal should have large red button if he dissatisfied" -> improve the service or shut the user off * Develop from the bottom up MS is "Swiss cheese", "plugging all it's holes" (Ed. note. But what does this have to do with bottom up development? Does bottom up imply that this won't happen?) * Error checking * Log updates * Make atomic stuff retry-able ------------------------------------------------- Graduate School ------------------------------------------------- 1) "I wanna get a PHD in Physics": you gotta be really, really smart 2) If you're that smart, realize no jobs in physics after PHD 3) Decide to become a CS programmer. 4) ... 5) profit??? Reasons why go to graduate school: ------------------------------------ * Insufficient training from BS degree. Advanced degree is useful, good for career. Better salary, and affects what work you do. (Less likely to be offshored?) * Make friends, contacts * People take you more seriously Degrees and what they mean: BS I can code, do basic technical work MS More design responsibility and more independence PhD Research, teaching, or architecting/design Some statistics (from the Career center) ------------------------------------------ BS 2k 62k 2k1 65k 2k2 58k 2k3 55k MS 2k1 72k 2k2 76k 2k3 74k When do you apply? ------------------ Apply around November and January; some schools also admit students midyear. Now or later? ------------ People generally appreciate grad school if you work for a while; also you can earn some money, put in bank. However, it's difficult to return to school after career and job starts (more tied-down). How long? ------------ MS: 1 to 3 years PhD: 3 to 10 years - average is around 5 or 6, and increasing. Where to go? ------------ Go to a good school, with a reasonable location. Pick a school with a large department, because more choices in what to focus on. This leads to the question of... Where are you going to get in? ------------------------------ All depends on grades, GREs, recommendations and statement of purpose. (Also how unemployment is: more unemployed, more BS graduates enter grad school to avoid the "real world"). Some faculty emphasize grades, smartness, others like experience. * Recommendations You need at least 3, although sometimes you might want more if some of your recommendations are from industry. * Financial support Usually, at "good" schools, all PhDs are supported with some kind of grant: whether fellowship, research assistant, or teaching assistant. * Should I stay at Berkeley? Go to your best school. That might mean Berkeley. And finally... Rankings of CS grad schools (1993) ------------------------------ Stanford MIT UCB