Комментарии 81
Я давно думал о том, что сколько может продолжаться такая вот гонка: процессоры мощнее — программы прожорливее. Но судя по статье не долго…
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Прости, ошибся со ссылкой.
prog21.dadgum.com/140.html
prog21.dadgum.com/140.html
Спасибо за перевод, крайне интересно.
Увы сейчас есть следующая тенденция, был неоднократно свидетелем, время работы программиста стоит дороже машинного времени. Поэтому часто бывает такое что скорость разработки идет в ущерб качеству кода. Крайне печально, но во многих фирмах это практикуется (особенно на момент запуска продукта)
Увы сейчас есть следующая тенденция, был неоднократно свидетелем, время работы программиста стоит дороже машинного времени. Поэтому часто бывает такое что скорость разработки идет в ущерб качеству кода. Крайне печально, но во многих фирмах это практикуется (особенно на момент запуска продукта)
Этой тенденции уже лет десять, как минимум.
Увы, десять лет назад мне было 12 и представление о состоянии программирования в то время у меня весьма смутные
Ну мне по схожей причине тяжело судить о том, что было более 10 лет назад ;)
Спольски пишет, что уже в конце восьмидесятых Лотус проиграл Майкрософту именно потому, что пока первые оптимизировали, вторые сделали релиз, а к моменту релиза уже и железо подоспело.
НЛО прилетело и опубликовало эту надпись здесь
Когда прога необычная или нишевая, приходится «прощупывать почву» силами внештатных бета-тестеров, и одновременно доводить ядро до более-менее оптимизированного состояния.
Опытные программисты пишут качественный код даже если их ограничивают временными рамками, т.к. они осознают, что только качественный код можно написать и оттестировать быстро, но правда время таких программистов стоит намного дороже.
Нету тенденции. И нету печали.
Нужно понимать простую вещь — если ускорить программу выгодно (профита больше, чем стоит время программистов) — нужно ускорять. Если и так всё работает приемлимо и в перспективе не начнёт тормозить — то зачем заниматься лишней работой? Да и золотое правило инженерии «не трогай то, что работает» — никто не отменял))
Нужно понимать простую вещь — если ускорить программу выгодно (профита больше, чем стоит время программистов) — нужно ускорять. Если и так всё работает приемлимо и в перспективе не начнёт тормозить — то зачем заниматься лишней работой? Да и золотое правило инженерии «не трогай то, что работает» — никто не отменял))
И ни слова про функциональное программирование.
Кстати да, сидел и в подсознании крутилось: когда же заговорят о функциональном программировании
ФП — это круто, конечно. Но не мейнстрим. И боюсь, что никогда не станет: высокий порог входа, невозможность написать что-то большое и т.п. Например, создатели Котлина, рассказывая про Scala говорят, что под Scala невозможно сделать нормальную IDE.
Есть расхожее мнение, что «чисто функциональные программы не имеют side-эффектов, а поэтому хорошо параллелятся». Но это слова. На самом деле, хороший вопрос, что такое «чисто функциональная программа» и что такое «хорошо параллелятся». Хорошо — в смысле «корректно», это да. Но вот в смысле «эффективно» — не уверен.
Есть расхожее мнение, что «чисто функциональные программы не имеют side-эффектов, а поэтому хорошо параллелятся». Но это слова. На самом деле, хороший вопрос, что такое «чисто функциональная программа» и что такое «хорошо параллелятся». Хорошо — в смысле «корректно», это да. Но вот в смысле «эффективно» — не уверен.
> И боюсь, что никогда не станет: высокий порог входа,
> И боюсь, что никогда не станет: высокий порог входа,
Ничего высокого. Вон, в C# ввели толпу функциональщины, в Java введут.
> невозможность написать что-то большое и т.п
В этом месте можно смеяться в голос
Ничего высокого. Вон, в C# ввели толпу функциональщины, в Java введут.
> невозможность написать что-то большое и т.п
В этом месте можно смеяться в голос
для того, чтобы написать что-то большое с помощью ФП нужно где-то достать много Фпрограммистов, не? А их днём с огнём.
Разве чисто функциональное программирование не является панацеей в данном случае? (Привет, Хаскель).
Панацеей — нет. Предоставляет ли оно облегчённые абстракции для параллельного программирования — да.
скорее erlang
No Silver Bullet.
Сайд-эффектов не будет, это да. Но при этом всё равно придётся думать над тем, как эффективно распараллеливать задачи.
Плюс «чистое ФП» — сложно и дорого. Плюс под него нельзя сделать IDE. Знаете, сколько стоят программисты, которые умеют круто работать без IDE?
В серьёзных современных конторах, где есть реальный HighLoad люди уже давно научились писать корректные многопоточные программы на мэйнстримовых языках типа Java, C++, C#. Там всё давно уже упирается в вычислительную и/или транспортную мощность железа.
Язык — слабый помощник и там и там. Если нужно быстро считать или быстро гонять данные, то зависимость от платформы практически пропадает.
Сайд-эффектов не будет, это да. Но при этом всё равно придётся думать над тем, как эффективно распараллеливать задачи.
Плюс «чистое ФП» — сложно и дорого. Плюс под него нельзя сделать IDE. Знаете, сколько стоят программисты, которые умеют круто работать без IDE?
В серьёзных современных конторах, где есть реальный HighLoad люди уже давно научились писать корректные многопоточные программы на мэйнстримовых языках типа Java, C++, C#. Там всё давно уже упирается в вычислительную и/или транспортную мощность железа.
Язык — слабый помощник и там и там. Если нужно быстро считать или быстро гонять данные, то зависимость от платформы практически пропадает.
Статья больше подходит для мобильных разработчиков, особенно тех которые работают с нативным кодом. И кстати сейчас вроде на топовых шестиядерных Phenom можно до 6 ггц разогнать даже на воздушном охлаждении?
Спасибо, очень интересно!
Когда я поставил первый двухядерный процессор, очень радовался тому, что можно запускать тяжёлую софтину, не подвешивая при этом систему.
Теперь же быдлокодеры спешат осваивать параллелизм, чтобы их говнософтины смогли продолжать сжирать все ресурсы системы.
И пусть 99,99% программ с пользой используют только 0,001% потребляемых ими ресурсов, почему-то никто не думает о том, как бы сделать их хоть немного полегче, главное — побольше абстракции в коде, побольше визуального мусора в интерфейсе вроде закруглённых уголков, прозрачных заголовков и прочих анимаций. Естественно, что всему этому уже не хватает одного процессора.
Время быдлокодера стоит дороже машинного времени, ага. Но если бы быдлокодер писал качественный код, он бы и потреблял машинного времени ровно столько, сколько нужно, а не в 9000 раз больше.
Теперь же быдлокодеры спешат осваивать параллелизм, чтобы их говнософтины смогли продолжать сжирать все ресурсы системы.
И пусть 99,99% программ с пользой используют только 0,001% потребляемых ими ресурсов, почему-то никто не думает о том, как бы сделать их хоть немного полегче, главное — побольше абстракции в коде, побольше визуального мусора в интерфейсе вроде закруглённых уголков, прозрачных заголовков и прочих анимаций. Естественно, что всему этому уже не хватает одного процессора.
Время быдлокодера стоит дороже машинного времени, ага. Но если бы быдлокодер писал качественный код, он бы и потреблял машинного времени ровно столько, сколько нужно, а не в 9000 раз больше.
Сложность кода растёт с каждым годом. Писать корректный и эффективный multi-threaded код в разы сложнее, чем single-threaded. А как уже заметили выше, писать качественный код банально невыгодно в плане денег.
Ещё бы. Сложность кода растёт, а задачи решаются те же (только хуже).
Не нужна многопоточность корректному и эффективному коду. Несколько потоков в одном процессе — дань быдлокодерам, которые не осилили асинхронную работу. В юниксах по началу не было многопоточности, хотя вычисления прекрасно распараллеливались и суперкомпьютеры работали. Несколько потоков выполнения в одном адресном пространстве — это низкоуровневый хак уровня ассемблера, крайне опасный и некрасивый.
корректный и эффективный multi-threaded код
Не нужна многопоточность корректному и эффективному коду. Несколько потоков в одном процессе — дань быдлокодерам, которые не осилили асинхронную работу. В юниксах по началу не было многопоточности, хотя вычисления прекрасно распараллеливались и суперкомпьютеры работали. Несколько потоков выполнения в одном адресном пространстве — это низкоуровневый хак уровня ассемблера, крайне опасный и некрасивый.
Есть задачи, которые хорошо параллелятся, например числодробление. Объясните, почему числодробилки не нужно многопоточить? Или вы предлагаете вместо тредов создавать отдельные процессы?
это часто действительно хорошее решение, по-крайней мере в linux, где процессы не сильно дороже потоков и есть множество средств ipc. при этом код может получится проще и понятней
Ну это просто поиск баланса между производительностью и безопасностью. Код будет проще и понятней, и даже безопасней, но менее производителен (насколько — нужно мерять). Тут уже зависит от задачи, где-то это решение применимо, где-то нет. Апач вон когда-то на каждый запрос по процессу рожал (сейчас не знаю как), потом перед ним стали ставить nginx'ы разнообразные, ибо накладно это было слишком.
для многих числодробилок многопоточность-хорошее решение, если это не усложнит всё сильно и не приводит к ошибкам, гонкам и т.п. лучше более медленный код но корректрый и безопасный.
несколько лет назад Линус был против появления многопоточности в линукс =)
мы, ортодоксальные юникс-программисты, всегда предпочитали форкнуться, но времена меняются…
несколько лет назад Линус был против появления многопоточности в линукс =)
мы, ортодоксальные юникс-программисты, всегда предпочитали форкнуться, но времена меняются…
Вместо того что бы выёбываться я бы советовал написать корректный многопоточный код для серьезной софтины (отличной от hello world) и выложить его на общее обозрение. Думается мне, вас бы говном быстро закидали.
Программы всё больше и больше уходят в веб, то есть в браузерный яваскрипт. А значит будущее за новыми подходами, которые смогут, наконец, подружить браузер и скриптовую многопоточность.
Первый шаг сделан: яваскрипт постепенно превращается из интерпретируемого языка в компилируемый.
Дальше — вопрос логики и новых редакций стандартов.
Вот где действительно развернётся будущая битва за производительность.
И здесь бы, пожалуй, помог отказ от классической синхронизации потоков с использованием мьютексов и прочих семафоров. Для браузерного программирования более адекватным будет параллельное программирование через обмен сообщениями между объектами, работающими в разных потоках. Это, конечно, создаёт не только возможности, но и сопутствующие проблемы.
С одной стороны, де-факто отсутствие разделяемой памяти упростит расширение на сколь угодно большое количество ядер. С другой стороны, появляется масса проблем, связанных как с самим подходом (задержки и прочее), так и увязкой этого с визуализацией DOM. Похоже, это дело браузеров будущего.
Первый шаг сделан: яваскрипт постепенно превращается из интерпретируемого языка в компилируемый.
Дальше — вопрос логики и новых редакций стандартов.
Вот где действительно развернётся будущая битва за производительность.
И здесь бы, пожалуй, помог отказ от классической синхронизации потоков с использованием мьютексов и прочих семафоров. Для браузерного программирования более адекватным будет параллельное программирование через обмен сообщениями между объектами, работающими в разных потоках. Это, конечно, создаёт не только возможности, но и сопутствующие проблемы.
С одной стороны, де-факто отсутствие разделяемой памяти упростит расширение на сколь угодно большое количество ядер. С другой стороны, появляется масса проблем, связанных как с самим подходом (задержки и прочее), так и увязкой этого с визуализацией DOM. Похоже, это дело браузеров будущего.
Согласен, что все больше расчетов ведется на стороне клиента javascript — ом. Но серверная часть никуда не денется, и от нее тоже требуется производительность. Это я так, к тому, что на стороне клиента происходят довольно простые расчеты, как правило не требующие оперирования большими объемами данных, самое сложное обычно происходит на сервере, и сервер как правило нуждается в оптимизации больше чем клиент на javascript.
Мне кажется, что если сравнить количество строк кода веб-сервера с веб-браузером, то у последнего будет больше. Примерно так же и с объёмом данных, который обрабатывается, DOM — объёмная структура, да и если HTTP протокол без состояния, а вот состояние страницы поддерживать приходится. БД и визуальную среду в сравнение не включаем.
Количество строк на сервере или в браузере крайне сильно зависит от приложения. В туду листе будет много javascript-а, а в поисковике его может даже не быть. Тут не все однозначно, но есть однозначность такого плана, что сложные расчеты по обработке данных происходят обычно на сервере, т.к. передавать клиенту все данные может оказаться невозможным и недопустимым.
Мне кажется, «отказ от классики» тут не поможет.Какой-нибудь MPI или Linda tuples уже не менее классика, чем семафоры. Там свои проблемы появляются, и общий вывод, как всегда, печален: В разных задачах разные подходы оказываются оптимальными.
Нам срочно требуется более продвинутая модель параллельного программирования чем та, что предлагают современные языки. Об этом подробнее я скажу в другой статье.
Будете ли вы переводить эту «другую статью»? было бы интересно её почитать. В крайнем случае, можете просто указать в тексте ссылку на неё?
Мне кажется, что проблема описанная в статье в частности привела сегодня к развитию языков использующих акторы, которые позволяют писать очень многопоточные приложения достаточно легко по трудозатратам, только жалко что мейнстримом они таки не спешат становиться. Плюс мне очень бы хотелось что бы возродилось незаслуженно забытое на рубеже 90-х dataflow программирование, которое тоже позволяет достаточно легко писать очень многоптоточные приложения, вплоть до того что встаёт проблема слишком сильной параллельности (fine-grained).
P.S.: На будущее, есть специальный тип поста, называется «перевод».
честно говоря в оригинале статьи не было ссылки на «следующую статью». подозреваю, что статья была написана позднее а ссылка на нее не поставлена: скорей всего это вот эта статья:
Software and the Concurrency Revolution,
ACM Queue, September 2005
queue.acm.org/detail.cfm?id=1095421
Software and the Concurrency Revolution,
ACM Queue, September 2005
queue.acm.org/detail.cfm?id=1095421
Прошу простить меня за такую точку зрения, но проблема в статье надуманная и никакой революции параллелизма не будет. Не так уж и много задач, требующих выжимания максимума производительности из одного процессорного устройства. Более того, серьёзный вычислительный процесс никогда не станет себя ограничивать рамками одного процессора/железа, пусть даже многоядерного. Может случиться так, что уже завтра задача потребует в 8 раз больше пиковых мощностей. Никто не будет ждать log2(8)*18 месяцев по закону Мура, что бы потом, наконец-таки, купить самую мощную топовую железку и получить 8-кратный рост производительности в пиках. Те, кому такие мощности действительно необходимы, уже давно параллелятся в облаках и прекрасно знакомы со всеми «прелестями» параллельного программирования.
Не согласен. Главная задача параллелизма в бизнесе обрабатывать большие массивы данных. А количество данных очень быстро растет. И практически везде в бизнес-приложениях эта проблема стоит очень остро от Microsoft Excel до Sap. Так что то, что вчера работало на одном сервере, сегодня физически не может, из-за гораздо большего количества данных и эта проблема очень распространена.
Речь в статье про софт для простых смертных, а не про трудоёмкие научные вычисления, которые по возможности делают на суперкомпах и в облаках.
Игрушки и видео вы тоже будете «параллелить в облаках»? Да что игры, даже скорость работы графических редакторов, сред разработки и т.д. и т.п. почему-то не приближается к идеальной (0 сек на любую операцию).
В общем и целом, от всё большего количества софта требуется способность эффективно использовать все ядра. Не знаю уж, «революция» это или нет, но факт остаётся фактом.
Игрушки и видео вы тоже будете «параллелить в облаках»? Да что игры, даже скорость работы графических редакторов, сред разработки и т.д. и т.п. почему-то не приближается к идеальной (0 сек на любую операцию).
В общем и целом, от всё большего количества софта требуется способность эффективно использовать все ядра. Не знаю уж, «революция» это или нет, но факт остаётся фактом.
Спасибо, познавательная статья!
Многоядерные архитектуры, скорость света, параллелиз, обращаться к многоядерным (multicore) решениям… Как мне все это знакомо.
Жалко, что большинство мощных процессоров ожидает в лучшем случае участь кубика.
Многоядерные архитектуры, скорость света, параллелиз, обращаться к многоядерным (multicore) решениям… Как мне все это знакомо.
Жалко, что большинство мощных процессоров ожидает в лучшем случае участь кубика.
Гораздо интереснее было бы почитать какое-нибудь авторитетное руководство/учебник по современному параллельному программированию(ПП). С одной стороны вроде бы всем все понятно, но с другой — тут может обнаружиться множество не очевидных приемов.
Раз уж ПП это такая же революция как и ООП, то где аналоги книги банды четырех по ПП? Может уже есть?
Раз уж ПП это такая же революция как и ООП, то где аналоги книги банды четырех по ПП? Может уже есть?
Например, вот.
увы, дружище, перевод книг подпадает уже под другую категорию перевода. бесплатного супа не быват — трясите издательства чтобы они не спали в шапку и не тратить силы на издания вской дряни типа html для чайников. а то такими темпами перевод книги изданной в 2008 году вы увидите дай бог в 2018. были уже такие прецеденты
Количество транзисторов и количество ядер так же упрется в физические возможности, интересно что будет тогда? Возможно люди, наконец-то, возьмутся за оптимизацию своего кода? =)
к счастью количество ядер езе не скоро упрется в физические пределы. пока у индустрии есть большие возможноти пкаовать все больше и больше тразисторов на чипе. а значит увеличивать мощнось проессора не за счет повышения тактовой частоты, а за счет плотности логики на квадратный сантиметр. влоть до размеров атомов.
Недавно читал книгу Программист прагматик, и там была глава про параллелизм.
Особенно понравился совет использовать UML диаграмму (activity diagram) для анализа возможных параллельных операций.
Глава 28. Временное связывание
Особенно понравился совет использовать UML диаграмму (activity diagram) для анализа возможных параллельных операций.
Глава 28. Временное связывание
Я выбрал данную статью для перевода потому, что она на мой взгляд является очень известной и фундаментальной. На нее ссылаются многие другие статьи в интернете, а также она часто упоминается в литературе по параллельному программированию, как отправная точка, как начальный документ, с которым должен ознакомиться программист, чтобы быть в теме.
Список из нескольких книг, в которых упоминается данная статья:
2007 — Intel Threading Building Blocks: Outfitting C++ for Multi-Core Processor Parallelism
2009 — The Art of Concurrency: A Thread Monkey's Guide to Writing Parallel Applications
2010 — Professional Parallel Programming with C#: Master Parallel Extensions with .NET 4
2012 — C++ Concurrency in Action: Practical Multithreading
Судя по тому, какие процессоры мы видим вокруг себя сейчас в 2012 году, автор статьи, написанной в 2005 году, оказался совершенно прав. 10ГГцовых процессоров мы так и не увидели, и даже 4ГГцовых процессоров в продаже сейчас нет. Производители процессоров действительно сейчас во всю разрабатывают тему многоядерности (multi-core) и аппаратной многопоточности (hardware threads) процессоров: Intel, Oracle Sparc, Power, ARM.
Многоядерные процессоры стали обыденным явлением. Сейчас трудно купить настольный компьютер с процессором, который бы не был многоядерным. такие процессоры проникли на сервера, в настольные компьютеры, лаптопы, в игровые приставки, в мобильные устройства, в планшеты, ультрабуки, сотовые телефоны и даже в бытовую технику.
Гонка за герцами сменилась на гонку за ядрами. 2, 4, 6, 8 ядер в процессоре уже есть сейчас. И каждое такое ядро поддерживает 2, 4, 16, 32 потока на ядро — уже сейчас. Спрятаться от этой гонки уже не удастся ни одному программисту. Если раньше многоядерность была головной болью системных программистов, писавших операционные системы, системы управления данными, научные вычислительные программы и системные утилиты, то теперь это касается тех, кто пишет веб-приложения, рядовые вычислительные программы, игры, прикладные программы, конвертеры фотографий и видео, архиваторы, почтовые программы, браузеры, программы моментальной передачи сообщений.
Раз предпосылки статьи оказались верными, значит и выводы из нее тоже верны: каждый программист должен подумать о том, как бы ему освоить параллельное программирование, чтобы не отстать от жизни и быть востребованным на рынке.
Список из нескольких книг, в которых упоминается данная статья:
2007 — Intel Threading Building Blocks: Outfitting C++ for Multi-Core Processor Parallelism
2009 — The Art of Concurrency: A Thread Monkey's Guide to Writing Parallel Applications
2010 — Professional Parallel Programming with C#: Master Parallel Extensions with .NET 4
2012 — C++ Concurrency in Action: Practical Multithreading
Судя по тому, какие процессоры мы видим вокруг себя сейчас в 2012 году, автор статьи, написанной в 2005 году, оказался совершенно прав. 10ГГцовых процессоров мы так и не увидели, и даже 4ГГцовых процессоров в продаже сейчас нет. Производители процессоров действительно сейчас во всю разрабатывают тему многоядерности (multi-core) и аппаратной многопоточности (hardware threads) процессоров: Intel, Oracle Sparc, Power, ARM.
Многоядерные процессоры стали обыденным явлением. Сейчас трудно купить настольный компьютер с процессором, который бы не был многоядерным. такие процессоры проникли на сервера, в настольные компьютеры, лаптопы, в игровые приставки, в мобильные устройства, в планшеты, ультрабуки, сотовые телефоны и даже в бытовую технику.
Гонка за герцами сменилась на гонку за ядрами. 2, 4, 6, 8 ядер в процессоре уже есть сейчас. И каждое такое ядро поддерживает 2, 4, 16, 32 потока на ядро — уже сейчас. Спрятаться от этой гонки уже не удастся ни одному программисту. Если раньше многоядерность была головной болью системных программистов, писавших операционные системы, системы управления данными, научные вычислительные программы и системные утилиты, то теперь это касается тех, кто пишет веб-приложения, рядовые вычислительные программы, игры, прикладные программы, конвертеры фотографий и видео, архиваторы, почтовые программы, браузеры, программы моментальной передачи сообщений.
Раз предпосылки статьи оказались верными, значит и выводы из нее тоже верны: каждый программист должен подумать о том, как бы ему освоить параллельное программирование, чтобы не отстать от жизни и быть востребованным на рынке.
Не могу ответить за всех, но по-моему в любой достаточно сложной программе всегда использовалась многопоточность. У вас же в 3Ds Max не подвисает вся IDE во время рендеринга. И, например, к вам поступает звонок если вы тайпитесь в скайпе. А музыкальный плэер как был однопоточным, так и останется.
при чем тут многопоточность?
тайпитесь
многопоточность существовала задолго до многоядерных процессоров. многопоточнеы программы выполнялись на одном процессере и это была просто имитация паралельного исполнения потоков. с появлением многоядерных машин потоки исполняются на параллельных ядрах, а значит это уже не имитация параллельного исполнения потоков, а реальное параллельное исполнение. вот именно при таком вот исполнении многие многопоточные программы начнут показывать ввсякие неожиданные глюки и ошибки. которые не выскакивали на однопроцессорных машинах. вот именно поэтому параллельное программирование теперь становится для программистов вторым хлебом. о чем и говорится в данной статье.
в дополнение могу заметить что не все многопоточные программы написанные ранее масштабируются — например программасоздает 5 потоков. и эти 5 потоков поочередно выполнялись на одном процессоре. на 5-ядерной машине жти потоки попадут на разные ядра и прекрасно загрузят процессор… но вот если программу запустить на 10 ядерной машине — программа по прежнему будет использовать только 5 ядер для 5 потоков. и значит будет использовать машну лишь на 50%. видите как усложняется задача параллельного программирования на реальных параллельных машинахз? и мы говорим не о суперкомпьютерах, не о кластерах или сверх=супер-пуер серверх. а о реальных потребительских компьютерах: настольниках, лаптопах, планшетах, мобильных телефонах, игровых приставках и может леч через 5холодильник или какой-нить пылесос
в дополнение могу заметить что не все многопоточные программы написанные ранее масштабируются — например программасоздает 5 потоков. и эти 5 потоков поочередно выполнялись на одном процессоре. на 5-ядерной машине жти потоки попадут на разные ядра и прекрасно загрузят процессор… но вот если программу запустить на 10 ядерной машине — программа по прежнему будет использовать только 5 ядер для 5 потоков. и значит будет использовать машну лишь на 50%. видите как усложняется задача параллельного программирования на реальных параллельных машинахз? и мы говорим не о суперкомпьютерах, не о кластерах или сверх=супер-пуер серверх. а о реальных потребительских компьютерах: настольниках, лаптопах, планшетах, мобильных телефонах, игровых приставках и может леч через 5холодильник или какой-нить пылесос
Спасибо за столь подробное объяснение! Но я всё равно не до конца понял — а хочется разобраться.
Я понимаю что многопоточность существовала, на моём старом 386 в Win 3.11 я мог открыть одновременно MS Paintbrush и играть в Miner в параллельном окне. Команды из процессов выполнялись по очереди, тем чаще чем выше приоритет.
Теперь же MS Paintbrush будет идти на одном ядре, а Miner — на другом. НУ или если бы это был один процесс, разделённый на несколько потоков — теперь каджый поток будет выполняться отдельным ядром, и это гарантирует операционная система.
Я к чему — и раньше приходилось писать программы, в которых создаётся много потоков, они между собой синхронизируются и т.п. Что принципиально нового в двух ядрах? Просто будет выполняться всё быстрее.
А если программист из вашего примера разделил задачу на 5 потоков на однопоточной машине, то она скорее всего не делится на большее количество частей, или дальнейшее разделение неразумно — потоки будут много простаиваться и ждать друг друга. Не все ведь алгоритмы можно распараллелить.
Я понимаю что многопоточность существовала, на моём старом 386 в Win 3.11 я мог открыть одновременно MS Paintbrush и играть в Miner в параллельном окне. Команды из процессов выполнялись по очереди, тем чаще чем выше приоритет.
Теперь же MS Paintbrush будет идти на одном ядре, а Miner — на другом. НУ или если бы это был один процесс, разделённый на несколько потоков — теперь каджый поток будет выполняться отдельным ядром, и это гарантирует операционная система.
Я к чему — и раньше приходилось писать программы, в которых создаётся много потоков, они между собой синхронизируются и т.п. Что принципиально нового в двух ядрах? Просто будет выполняться всё быстрее.
А если программист из вашего примера разделил задачу на 5 потоков на однопоточной машине, то она скорее всего не делится на большее количество частей, или дальнейшее разделение неразумно — потоки будут много простаиваться и ждать друг друга. Не все ведь алгоритмы можно распараллелить.
Принципиально новое — два потока могут обращаться к одному объекту в в действительно одно и то же время, т.е. одновременно, т.е. в один и тот же момент. Одновременная запись приводит ко всяким забавным потерям информации
Возможно я и правда отстал от жизни. И что, обычные семафоры, локи и т.п. в этом случае уже не будут работать? Ведь в регистрах обоих процессоров всё же разные наборы данных. Они могут одновременно обращаться разве что к чему-нибудь внешнему, к оперативке например.
если язык и его компилятор хорошо и правильно их поддерживает — да. вот например Java 1.4 плохо это поддерживала и несмотря на все старания — синхронизации и volatile — программисты не могли добиться нужного результата. пришлось все переделывать в Java 5 и Java 6. и все равно правильно писать многопоточные на Java — очень трудно. мозг закипает
а что уж говорить про С++, где нет на уровне языка многопоточности и приходится пользоваться стоонними библиотеками, в которых тоже свои глюки могут оказаться.
а что уж говорить про С++, где нет на уровне языка многопоточности и приходится пользоваться стоонними библиотеками, в которых тоже свои глюки могут оказаться.
>>> MS Paintbrush и играть в Miner в параллельном окне
это не многопоточность. это мултипроцессность. MS Paintbrush в своем процессе, Miner — в своем. Ну сами посудите, какими такими данными MS Paintbrush ваш обменивался с Miner-ом?
это не многопоточность. это мултипроцессность. MS Paintbrush в своем процессе, Miner — в своем. Ну сами посудите, какими такими данными MS Paintbrush ваш обменивался с Miner-ом?
> автор статьи, написанной в 2005 году, оказался совершенно прав. 10ГГцовых процессоров мы так и не увидели
это было очевидно в нулевых, pentium4 оказался тупиковой веткой и вернулись к архитектуре схожей с pentium pro — pentium m, потом core и т.д.
это было очевидно в нулевых, pentium4 оказался тупиковой веткой и вернулись к архитектуре схожей с pentium pro — pentium m, потом core и т.д.
Кстати, если бы кукурузную ветку Tejas со сверхдлинным конвейером на 5-9 ГГц все же развили, интересно, она бы хоть догнала сегодняшние 3-4 ГГц процы в SuperPI или кукурузилась где-то на уровне Core 2 Duo?
это не было очевидным в нулевых. возвращение к архитектуре pentium pro не имело никакого отношения к многоядерности кроме того не одним pentium pro жива компьютерная индустрия.
Еще один момент статьи, который наверное упустили поспешные читатели.
Автор явно намекает, что теперь и обучение программированию в университетах должно измениться. к основам программирования должны добавиться еще основы параллельного программирования, чтобы не оказалось так, что в институте учат, что код программы выполняется последовательно, как задумано программистом, а на практике оказывается есть out-of-order execution, memory model, memory barriers, согласование кешей, отложенная запись и чтение и прочая прочая прочая. то есть старая модель программирования — мысленное понимание программистом того, как выполняется его программа — не соотствествует новым дизайнам процессоров.
Автор явно намекает, что теперь и обучение программированию в университетах должно измениться. к основам программирования должны добавиться еще основы параллельного программирования, чтобы не оказалось так, что в институте учат, что код программы выполняется последовательно, как задумано программистом, а на практике оказывается есть out-of-order execution, memory model, memory barriers, согласование кешей, отложенная запись и чтение и прочая прочая прочая. то есть старая модель программирования — мысленное понимание программистом того, как выполняется его программа — не соотствествует новым дизайнам процессоров.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бесплатного супа больше не будет