title = {Архитектура компьютеров и проектирование компьютерных систем.},
author = {Паттерсон Д., Хеннеси Дж.},
publisher = {Питер},
year = {2012},
series = {«Классика computer science»},
edition = {4-е},
Кто читал и одобряет? Какие самые ценные мысли вы оттуда почерпнули?
Awards[edit]
Fellow of the ACM
Fellow of the IEEE
Member of the Royal Netherlands Academy of Arts and Sciences[33]
IEEE Computer Society Tech. Committee on Distributed Processing Outstanding Technical Achievement Award, 2022
Eurosys Lifetime Achievement Award, 2015
Honorary doctorate from Petru Maior University, Targu Mures, Romania, 2011
Winner of the TAA McGuffey award for classic textbooks for Modern Operating Systems, 2010
Coauthor of the Best Paper Award at the LADC Conference, 2009
Winner of a 2.5 million euro European Research Council Advanced Grant, 2008
USENIX Flame Award 2008 [34] for his many contributions to systems design and to openness both in discussion and in source
Honorary doctorate from Polytechnic University of Bucharest, Romania
Coauthor of the Best Paper Award at the Real-Time and Network Systems Conf., 2008
Winner of the 2007 IEEE James H. Mulligan, Jr. Education Medal[35]
Coauthor of the Best Paper Award at the USENIX LISA Conf., 2006
Coauthor of the Best Paper for High Impact at the IEEE Percom Conf., 2006
Academy Professor, 2004
Winner of the 2005 PPAP Award for best education on computer science software
Winner of the 2003 TAA McGuffey award for classic textbooks for Computer Networks
Winner of the 2002 TAA Texty Award for new textbooks
Winner of the 1997 ACM SIGCSE for contributions to computer science education
Winner of the 1994 ACM Karl V. Karlstrom Outstanding Educator Award
Coauthor of the 1984 ACM SOSP Distinguished Paper Award
Keynote talks[edit]
Tanenbaum has been keynote speaker at numerous conferences, most recently
ICDCS 2022 Bologna, Italy, July 12, 2022
Qualcomm Security Summit San Diego, May 18, 2022
RIOT Summit 2020 Online Event, September 14, 2020
FrOSCon 2015 Sankt Augustin, Germany, August 22, 2015
BSDCan 2015 Ottawa, Canada, June 12, 2015
HAXPO 2015 Amsterdam May 28, 2015
Codemotion 2015 Rome Italy, March 28, 2015
SIREN 2010[permanent dead link] Veldhoven, The Netherlands, November 2, 2010
FOSDEM Brussels, Belgium, February 7, 2010
NSCNE '09[permanent dead link] Changsha, China, November 5, 2009
E-Democracy 2009 Conference Athens, Greece, September 25, 2009
Free and Open Source Conference Sankt Augustin, Germany, August 23, 2008
XV Semana Informática Archived May 28, 2020, at the Wayback Machine of the Instituto Superior Técnico, Lisbon, Portugal, March 13, 2008
NLUUG 25 year anniversary conference, Amsterdam, November 7, 2007
linux.conf.au in Sydney, Australia, January 17, 2007
Academic IT Festival in Cracow, Poland, February 23, 2006 (2nd edition)
ACM Symposium on Operating System Principles, Brighton, England, October 24, 2005
"A quantitative approach" — одна из ценнейших книг вообще в IT — разумеется, для тех, кто хоть как-то думает про эффективность.
Мне с заметным прошлым опытом помогла систематизировать, что знал. Для новичка будет отличным учебником, хотя уже надо знать основы (грубо говоря, это книга для тех, кто уже бакалавр).
ЭФ> title = {Архитектура компьютеров и проектирование компьютерных систем.},
А это более базовый учебник, как раз для студента, который только начал входить в тему.
N> для студента, который только начал входить в тему.
Да в какую тему-то? Стану ли я от этого лучше программировать на JavaScript?
Может и не надо это всё читать просто?
N> для тех, кто хоть как-то думает про эффективность.
Мне казалось, что для этого надо как-то думать про многопоточность, синхронизацию, пулы...
Здравствуйте, DiPaolo, Вы писали:
DP>Не, ну если сам blacklion (карма:4, рейтинг: 0) с хабра сказал (https://habr.com/ru/company/vdsina/blog/534542/#comment_22539410), и даже один плюсик получил, то это — весомый аргумент. Надо тащить это в качестве референса и цитировать
Вот смотреть на хабровскую карму — точно
А blacklion — разработчик с 20+ стажа преимущественно на "системном" уровне и его мнение имеет смысл хотя бы рассмотреть.
DP>Танненбаума уж точно можно рекомендовать.
Для чего именно?
Что его учебник неплох в качестве начального введения в тему — безусловно.
И его другие учебники, как про ОС — тоже.
Но вот например его попытки впихнуть Minix в каждый утюг точно не то, на что надо ориентироваться.
DP>Ну и раз уж я заговорил про референсы, то вот про него (https://en.wikipedia.org/wiki/Andrew_S._Tanenbaum):
Здравствуйте, Эйнсток Файр, Вы писали:
N>> для студента, который только начал входить в тему.
ЭФ>Да в какую тему-то? Стану ли я от этого лучше программировать на JavaScript?
На JavaScript? Тогда вообще читать вредно, от этого появляются мысли.
ЭФ>Может и не надо это всё читать просто?
Согласен, не надо.
N>> для тех, кто хоть как-то думает про эффективность.
ЭФ>Мне казалось, что для этого надо как-то думать про многопоточность, синхронизацию, пулы...
"Многопоточность" вам не поможет, когда набираете на амазоне толпу двукоровых инстансов и сравниваете, что от перехода, например, с Python на Java ваш бэкенд начинает работать в 10 раз быстрее, а на C++ с правильным размещением данных — ещё в 5 раз быстрее.
Да и на 16-коровых без разницы, если задачи естественно параллелятся сами.
"Мы вкатим сюда в 5 раз больше железа/инстансов и всё будет хорошо" работает очень ограниченно.
Это самый крутой из доступных без NDA учебник уровня старших курсов магистратуры
ЭФ>Image: 6161485706.jpg ЭФ>Кто читал и одобряет? Какие самые ценные мысли вы оттуда почерпнули?
У меня 4е издание. В целом книга очень классная и разбирает работу процессора на очень низком уровне.
Едва ли не первая книга в этом роде. После каждой главы есть упражнения + решения можно в интернете скачать.
Подробно разбирается работа HDD -- скорость работы, mttf и прочие метрики. Т.е. работа процессора, подсистема памяти (MMU),
жесткие диски, виртуализация + еще что-то по мелочи. В 5ю часть добавили сеть и всякую всячину(вроде gpu, но точно не знаю, не смотрел).
Считают, что подобные книги надо праробатывать, если есть желание повысить свою квалификацию.
Здравствуйте, netch80, Вы писали:
N>на C++ с правильным размещением данных — ещё в 5 раз быстрее.
А можно реальных, практических примеров, на конкретных задачах, которые удалось ускорить в пять раз за счет "правильного размещения данных", и чтоб это "правильное размещение" становилось очевидным только после глубокого изучения архитектуры, а соблюдения элементарных (и часто интуитивных) правил было бы недостаточно.
Я пока вижу, что ускорение в 10-100-1000 раз чаще всего может быть достигнуто совершенно банальными методами, вроде запоминания результатов разбора конфига вместо того, чтобы сотни-тысячи раз открывать файл (в винде — реестровую ветку) и разбирать конфиг заново. Практически весь современный софт, с которым приходится работать — и обычный, и серверный (через web-интерфейсы) тормозит на простейших операциях настолько неприлично, что нет оснований подозревать там неправильное размещение данных или недостаточную привязку к целевой архитектуре — только крайне грубый, примитивный, топорный подход к работе с теми данными.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>на C++ с правильным размещением данных — ещё в 5 раз быстрее. ЕМ>А можно реальных, практических примеров, на конкретных задачах, которые удалось ускорить в пять раз за счет "правильного размещения данных", и чтоб это "правильное размещение" становилось очевидным только после глубокого изучения архитектуры, а соблюдения элементарных (и часто интуитивных) правил было бы недостаточно.
Утверждение было не про правильное размещение, а про С++ с правильным размещением. Так что для ускорения надо ещё сменить язык и компилятор.
1. Из неинтуитивных штук, которые есть в С++ и ускоряют работу — это padding в lock_free структурах между данными и механизмом синхронизации, чтобы они не попадали в одну кэш-линию. То есть в структуру добавляется просто char paddibg[сколько-то байт]. Тогда один поток может работать с данными в ней, а другие, не мешая ему, пытаться синхронизироваться в это время. В некоторых сценариях ускорение синхронизации получается как раз в разы.
2. Ещё из неочевидного small string optimization — размещение самой строки на месте служебных данных самой структуры std::string. То есть для коротких строк исчезает аллокация и можно написать вполне такие тесты, где это даст ускорение в разы.
3. Всякие вычисления на GPU в том числе, где есть учёт размера кэша и архитектуры устройства. И у меня был опыт, когда приходилось оптимизировать код под конкретное железо, теперь я им просто пользуюсь в виде Intel mkl, cuDNN и т.д. Там именно что для каждой архитектуры своя реализация, учитывается вплоть до количества регистров, по разному кладутся в память данные, по разному они читаются (scatter, gather).
Здравствуйте, Евгений Музыченко, Вы писали:
N>>на C++ с правильным размещением данных — ещё в 5 раз быстрее.
ЕМ>А можно реальных, практических примеров, на конкретных задачах, которые удалось ускорить в пять раз за счет "правильного размещения данных", и чтоб это "правильное размещение" становилось очевидным только после глубокого изучения архитектуры, а соблюдения элементарных (и часто интуитивных) правил было бы недостаточно.
Нельзя. Потому что такого сочетания условий, которые ты тут привёл, никто не обещал.
"Глубокое" изучение под твой уровень — это скорее всего под жесточайшим NDA.
А книга рассчитана на то, чтобы понимали, например, почему смена порядка переменных при перемножении матриц приводит к резкому ускорению на современном железе, хотя замедляла на древнем.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, netch80, Вы писали:
N>>на C++ с правильным размещением данных — ещё в 5 раз быстрее.
ЕМ>А можно реальных, практических примеров, на конкретных задачах, которые удалось ускорить в пять раз за счет "правильного размещения данных", и чтоб это "правильное размещение" становилось очевидным только после глубокого изучения архитектуры, а соблюдения элементарных (и часто интуитивных) правил было бы недостаточно.
Здравствуйте, Nuzhny, Вы писали:
N>Утверждение было не про правильное размещение, а про С++ с правильным размещением. Так что для ускорения надо ещё сменить язык и компилятор. N>1. Из неинтуитивных штук, которые есть в С++ и ускоряют работу — это padding в lock_free структурах между данными и механизмом синхронизации, чтобы они не попадали в одну кэш-линию. То есть в структуру добавляется просто char paddibg[сколько-то байт]. Тогда один поток может работать с данными в ней, а другие, не мешая ему, пытаться синхронизироваться в это время. В некоторых сценариях ускорение синхронизации получается как раз в разы.
Не понял, в чем тут суть? Уменьшается cache coherence или что? К тому же у каждого процессора свой кэш.
Здравствуйте, Nuzhny, Вы писали:
N>Утверждение было не про правильное размещение, а про С++ с правильным размещением.
Теория мне хорошо известна. Интересны, повторю, практические примеры. Не "правильное размещение данных позволяет ускорить обработку на 30%", а "наша программа выполняла операцию XXX за 3 (1, 0.5, 0.1) секунды, а после оптимизации размещения данных, без изменения алгоритма, это время было снижено на 30%".
Здравствуйте, netch80, Вы писали:
N>Нельзя. Потому что такого сочетания условий, которые ты тут привёл, никто не обещал.
Меня интересуют не обещания, а конкретные достижения. Пока я на фоне всех этих глубокомысленных рассуждений о "тонкой оптимизации", способной сэкономить максимум десяток-другой процентов затрат, наблюдаю совершенно чудовищный рост затрат за счет кривых алгоритмов, их примитивной реализации, многослойных абстракций и прочего.
Допускаю, что где-нибудь в сфере майнинга или автоматизированной биржевой торговли, где выигрыш в производительности непосредственно конвертируется в доход, вся эта тонкая оптимизация применяется. А там, где непосредственной конвертации нет?
N>А книга рассчитана на то, чтобы понимали, например, почему смена порядка переменных при перемножении матриц приводит к резкому ускорению на современном железе, хотя замедляла на древнем.
Ну вот конкретно в Ваших собственных задачах есть возможность применить почерпнутые оттуда знания, чтобы это заметно отразилось на производительности, "доступной в ощущениях", а не по тестам?
N>такой пример не подойдёт?
Да, такое подойдет, спасибо. Но это, по большому счету, редкие случаи, их доля в современном софтостроении ничтожна, а вот популярность дискуссий о таких тонкостях несоизмеримо велика.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну вот конкретно в Ваших собственных задачах есть возможность применить почерпнутые оттуда знания, чтобы это заметно отразилось на производительности, "доступной в ощущениях", а не по тестам?
Да, есть. Сильно меньше, чем хотелось, но есть.
ЕМ>Да, такое подойдет, спасибо. Но это, по большому счету, редкие случаи, их доля в современном софтостроении ничтожна, а вот популярность дискуссий о таких тонкостях несоизмеримо велика.
У меня за последние 10 лет доля количества работ, где требовалась оптимизация производительности и она хотя бы частично основана на описанных методах (начиная с банального — собрать данные, с которыми работают вместе, в соседние ячейки) — около половины.
Самих таких действий, да, было мало от общего количества работы — условно говоря, 2%.
Но не ноль.
Здравствуйте, netch80, Вы писали:
N>У меня за последние 10 лет доля количества работ, где требовалась оптимизация производительности и она хотя бы частично основана на описанных методах (начиная с банального — собрать данные, с которыми работают вместе, в соседние ячейки) — около половины. N>Самих таких действий, да, было мало от общего количества работы — условно говоря, 2%.
А таких случаев, когда самых общих познаний было недостаточно, и требовалось более глубокое исследование, и в итоге это приводило к заметному увеличению быстродействия, и не только по тестам, но и в плане решаемых задач?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Теория мне хорошо известна. Интересны, повторю, практические примеры. Не "правильное размещение данных позволяет ускорить обработку на 30%", а "наша программа выполняла операцию XXX за 3 (1, 0.5, 0.1) секунды, а после оптимизации размещения данных, без изменения алгоритма, это время было снижено на 30%".
На CUDA/OpenCL такое сплошь и рядом, там и занимаешься тем, что не столько алгоритм придумываешь, сколько потом его в памяти упаковываешь. Там реально в десятки раз скорость вырастает.
В С++ на CPU у меня был скачок производительности, когда я свою очередь на мьютексах заменил на lock-free из гитхаба. Вот там я и подсмотрел, что есть проблема false sharing. Но время работы самой очереди не замерял, на практике производительность всего пайплайна выросла на несколько fps, что позволило мне вписаться в тайминг.
Ну и очевидные замены типов данных, когда память начинает выделяться на стеке вместо кучи считается?
