Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, remark, Вы писали:
R>>Да, было такое в DDJ в прошлом сентябре: R>>http://www.ddj.com/hpc-high-performance-computing/201804248 R>>Статья, конечно, больше в стиле вопросов, нежели ответов. Т.к. после каждого пункта хочется спросить "А как?"
AJD>Особенно хочется спросить, "А как?" на совет
AJD>
AJD>Avoid using locks. Simply say "no" to locks. Locks slow programs, reduce their scalability, and are the source of bugs in parallel programs
На этот вопрос сразу хочется ответить вопросом "А где?"
Т.е. вариантов-то много. Всё зависит от конкретной ситуации и деталей.
Здравствуйте, eao197, Вы писали:
E>В качестве выводов автор в очередной раз говорит, что нельзя использовать статические данные в многопоточных программах, так же как плохо вообще разделять какие-либо данные между потоками. Ну это и понятно (не понятно, однако, насколько та же Java приспособлена к другим подходам в многопоточности)
Пока не добавят встроенный ассемблер — нисколько не приспособлена
Пока будьте любезны обходится мейнстримом, который встроен в язык/библиотеку/ран-тайм
Здравствуйте, рыбак, Вы писали:
Р>Как сказал какой-то умный тип: многопоточность придумали те, кто не понимают конечных автоматов.
Что касается "многопоточности на одном процессоре", то в принципе, наверное, да.
Что касается "многопоточности на множестве процессоров", то это совсем о другом, это перпендикулярные вещи.
Здравствуйте, remark, Вы писали:
R>Позавчера однопоточная программа на одноядерном процессоре использовала 100% аппаратных ресурсов. Хорошо. R>Вчера однопоточная программа на двухядерном процессоре использовала 50% аппаратных ресурсов. Допустим. R>Сегодня однопоточная программа на четырёхядерном процессоре использует 25% аппаратных ресурсов. Хммм. R>Завтра однопоточная программа на шестнадцатиядерном процессоре будет использовать 6.25% аппаратных ресурсов. R>Послезавтра однопоточная программа на восьмидестиядерном процессоре будет использовать 1.25% аппаратных ресурсов.
R>Арифметика очень простая. Хотите быть автором программы, которая работает только на 1.25% от возможного?
Говорят, мы используем возможности нашего мозга только на 2 процента. Видимо, Творец так и не смог это безобразие по-нормальному распараллелить...
It's kind of fun to do the impossible (Walt Disney)
In principal, Ct works with any standard C++ compiler because it is a standards-compliant C++ library (with a lot of runtime behind the scenes). When one initializes the Ct library, one loads a runtime that includes the compiler, threading runtime, memory manager — essentially all the components one needs for threaded and/or vectorized code generation. Ct code is dynamically compiled, so the runtime tries to aggregate as many smaller tasks or data parallel work quanta so that it can minimize threading overhead and control the granularity according to run-time conditions. With the Ct dynamic engine, one gets precise inter-procedural traces to compile, which is extremely useful in the highly modularized and indirect world of object-oriented programming.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Дополнительные ссылки для интересующихся:
E>Ct: C for Throughput Computing -- какая-то новая штука от Intel-а (как я понял, пока находящаяся в стадии разработки). E>
E>How does it work?
E>In principal, Ct works with any standard C++ compiler because it is a standards-compliant C++ library (with a lot of runtime behind the scenes). When one initializes the Ct library, one loads a runtime that includes the compiler, threading runtime, memory manager — essentially all the components one needs for threaded and/or vectorized code generation. Ct code is dynamically compiled, so the runtime tries to aggregate as many smaller tasks or data parallel work quanta so that it can minimize threading overhead and control the granularity according to run-time conditions. With the Ct dynamic engine, one gets precise inter-procedural traces to compile, which is extremely useful in the highly modularized and indirect world of object-oriented programming.
Спасибо. Погляжу.
На первый взгляд это что-то типа гибрида RapidMind и Cilk.
При использовании RapidMind вычислительная программа описывается на смеси шаблонов с макросами, и потом тоже в ран-тайме компилируется в нативный оптимизированный код, под конкретную платформу.
А из Cilk спёрли "spawn" и "task parallelism".
Огорчает то, что это всё, и всё то, и то тоже, всё это рассчитано исключительно для вычислительных задач. Т.е. пока тебе не надо перемножать матрицы в миллион элементов, или обрабатывать видео, или считать САПР какой-нибудь, пользы от этого мало... Не то, что от SObjectizer
Здравствуйте, remark, Вы писали:
R>Огорчает то, что это всё, и всё то, и то тоже, всё это рассчитано исключительно для вычислительных задач. Т.е. пока тебе не надо перемножать матрицы в миллион элементов, или обрабатывать видео, или считать САПР какой-нибудь, пользы от этого мало...
Тут вот народ выход Fortress 1.0 обсуждает, так в обсуждении какие-то прям зубры HPC затесались. Оказывается, очень восстребованная штука это нонче. Если разработки Intel-а им жизнь облегчат, так это же хорошо.
Примечательно так же, что подобные штуки для неуправляемых C/C++ делают. Что-то managed среды типа Java/C# у Intel-а не котируются
R>Не то, что от SObjectizer
А то!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, remark, Вы писали:
R>Что бы эффективно использовать новые аппаратные платформы, нужны совершенно новые принипы и подходы. Нужна «многопоточность на множестве ядер». Под эффективностью я подразумеваю, что бы программа на 8 ядрах выполнялась хотя бы не медленнее, чем на одном. Шутка шуткой, а на форумах посвящённым многопоточности сейчас один из самых распространённых вопросов «Почему моя программа, которая делает Х, на 4-ёх ядерной машине работает медленнее, чем на 1-ядерной?»
Многопроцессорные системы и кластеры вовсе не новое явление, новое только в том, что они добрались до массового рынка для которого просто оказалось недостаточно квалифицированных специалистов, притом и среди преподавателей тоже.
Разумеется, проблемы написания программ с по-настоящему, параллельными вычислениями были и есть, но сдаётся мне, что 99% программистов, которым хочется эффективно задействовать несколько ядер достаточно использовать давно уже известные приёмы, методики и библиотеки. Ещё конечно проблема, что в системах, в которых до недавнего времени использовали многопроцессорность, Windows с одной стороны была не очень популярна, с другой — она сама не слишком на них рассчитывалась, несмотря на поддержку мультипроцессорности.
Здравствуйте, eao197, Вы писали:
E>Примечательно так же, что подобные штуки для неуправляемых C/C++ делают. Что-то managed среды типа Java/C# у Intel-а не котируются
Так управляемая же среда должна и на процессорах AMD работать
Здравствуйте, Хитрик Денис, Вы писали:
E>>Примечательно так же, что подобные штуки для неуправляемых C/C++ делают. Что-то managed среды типа Java/C# у Intel-а не котируются
Потому как в управляемой среде производительность программы зависит от кучи внешних факторов.
Какой смысл устраивать гонки на скоростных болидах по трассе, где придется часто тормозить на каждом гаишнике для проверки бардачка.
Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, Sinclair, Вы писали:
AVM>>>Может быть только для того, чтобы сделать компьютер умеющий их перемножать? S>>Перемножение матриц имеет невероятно широкий спектр прикладных применений. AVM>Например?
Любая из современных игр. Правда, там все происходит на гпу.
По твоему зря оптимизацию векторных вычислений в процессоры встраивают?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, remark, Вы писали:
R>Что бы эффективно использовать новые аппаратные платформы, нужны совершенно новые принипы и подходы. Нужна «многопоточность на множестве ядер».
Кому она нужна? Тебе? Заказчикам? Зачем? И так впринципе можно жить — купите лоадбалансер Менеджерам по продажам CPU? А, ну да
Тезис Черча (не считая недоказанности — ИМХО ерунда) имеет серьёзную проблему — на "реальных МТ" требования алгоритма к времени или памяти могут быть неприемлимы. Эту особенность эксплуатирует например современная криптография. В тоже время, при достаточно большом количестве ядер, суперядерный процессор сможет эмулировать квантовый компьютер, и решать многие задачи грубой силой. Будет решена проблема P = NP современной плоской модели. RSA Security уже убрали Chalenge.
Да, для некоторого класса задач суперядерность ничего не даст! Ну и что, 2+2 можно и на калькуляторе посчитать, и даже в уме.
Но можно будет решать новые задачи, конечно это потребует некоторого повышения уровня... абстракции, вроде как обычная арифметика была, а появились поля и кольца...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>Тезис Черча (не считая недоказанности — ИМХО ерунда) имеет серьёзную проблему — на "реальных МТ" требования алгоритма к времени или памяти могут быть неприемлимы. Эту особенность эксплуатирует например современная криптография. В тоже время, при достаточно большом количестве ядер, суперядерный процессор сможет эмулировать квантовый компьютер, и решать многие задачи грубой силой. Будет решена проблема P = NP современной плоской модели. RSA Security уже убрали Chalenge.
Это как это будет решена? Непонятно. Всё равно при линейном росте длины ключа мы получаем экспоненциальный рост поиска обратного ключа.
Здравствуйте, WFrag, Вы писали:
WF>Это как это будет решена? Непонятно. Всё равно при линейном росте длины ключа мы получаем экспоненциальный рост поиска обратного ключа.
Алгоритм Шора был разработан Питером Шором в 1994 году. Семь лет спустя, в 2001 году, его работоспособность была продемонстрирована группой специалистов IBM. Число 15 было разложено на множители 3 и 5 при помощи квантового компьютера с 7 кубитами.
Понятно, что всегда можно найти неприемлимые для МТ объемы данных. Я имел ввиду вот что — сейчас рассматривают два требования алгоритма — к объёму памяти и времени выполнения (фактически принимают как функцию от тактовой частоты). Но появится третий ресурс — количество исполнителей. Если исполнителей достаточно — NP-полная задача решается брутфорсом за полиномиальное время. Конечно 80 ядер — мало, как 80 байт и wintel не та архитектура.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Michael7, Вы писали:
M>Здравствуйте, remark, Вы писали:
R>>Что бы эффективно использовать новые аппаратные платформы, нужны совершенно новые принипы и подходы. Нужна «многопоточность на множестве ядер». Под эффективностью я подразумеваю, что бы программа на 8 ядрах выполнялась хотя бы не медленнее, чем на одном. Шутка шуткой, а на форумах посвящённым многопоточности сейчас один из самых распространённых вопросов «Почему моя программа, которая делает Х, на 4-ёх ядерной машине работает медленнее, чем на 1-ядерной?»
M>Многопроцессорные системы и кластеры вовсе не новое явление, новое только в том, что они добрались до массового рынка для которого просто оказалось недостаточно квалифицированных специалистов, притом и среди преподавателей тоже.
M>Разумеется, проблемы написания программ с по-настоящему, параллельными вычислениями были и есть, но сдаётся мне, что 99% программистов, которым хочется эффективно задействовать несколько ядер достаточно использовать давно уже известные приёмы, методики и библиотеки. Ещё конечно проблема, что в системах, в которых до недавнего времени использовали многопроцессорность, Windows с одной стороны была не очень популярна, с другой — она сама не слишком на них рассчитывалась, несмотря на поддержку мультипроцессорности.
Если ты имеешь в виду HPC сообщество, то это совершенно не так. HPC сообществу практически нечего предложить нам — прикладным/системным программистам.
Вот, к примеру, ряд вопросов, которые поставят в ступор любого HPC специалиста.
— Как организовать архитектуру сетевого сервера для обеспечения хорошей масштабируемости?
— Как эффективно организовать управление памятью в многопроцессорной среде?
— Как эффективно организовать управление временем жизни объектов в многопроцессорной среде?
Согласись, что это базовые вопросы для любого прикладного приложения. У HPC просто нет ответов на такие вопросы. Они варятся в своей каше из гиперкубов и тета-нотации.
Есть другой класс специалистов — это разработчики высокопроизводительных серверов (сетевые, баз данных и т.д.), которые работали с SMP машинами. Они, действительно, имеют ответы на некоторые вопросы. Но во-первых, далеко не на все. Во-вторых, далеко не самые идеальные ответы. В третьих, таких людей очень мало (я общался только с одним, он действительно даёт достаточно вразуметильные ответы по поводу архитектуры, взаимодействия потоков и т.д.).
И это разработчики далеко не всех "высокопроизводительных" серверов. Например, такая "продвинутая" и "высокопроизводительная" СУБД как PostgreSQL использует "тупейшую" схему для обеспечения масштабирования — под каждую сессию запускает отдельный процесс, всё остальное решается с помощью блокировок.
Т.ч. я совершенно не согласен, что типа просто "а мужики-то не знали", уже всё есть готовое, а мы тут тупим, как же нам быть.
Сейчас многоядерность двинулась в сектор серверного ПО, клиентского ПО, игрового ПО. И на встающие вопросы ещё ни у кого нет ответов.
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, remark, Вы писали:
R>>Что бы эффективно использовать новые аппаратные платформы, нужны совершенно новые принипы и подходы. Нужна «многопоточность на множестве ядер».
GN>Кому она нужна? Тебе? Заказчикам? Зачем? И так впринципе можно жить — купите лоадбалансер Менеджерам по продажам CPU? А, ну да
Я бы в принципе не отказался, если бы на моём компьютере, способном выполнять 3,6*10^10 операций в секунду, не тормозил текстовый процессор...
лоадбалансер? т.е. ты предлагаешь мне купить домой несколько компьютеров и объединить лоадбалансером?
GN>Что нужно — так это реальный стимул, что бы этим занимались серьезно. И он есть — снижение сложности вычислений. In 1998 the EFF built Deep Crack for less than $250,000
GN>Тезис Черча (не считая недоказанности — ИМХО ерунда) имеет серьёзную проблему — на "реальных МТ" требования алгоритма к времени или памяти могут быть неприемлимы. Эту особенность эксплуатирует например современная криптография. В тоже время, при достаточно большом количестве ядер, суперядерный процессор сможет эмулировать квантовый компьютер, и решать многие задачи грубой силой. Будет решена проблема P = NP современной плоской модели. RSA Security уже убрали Chalenge.
Вообще, я говорил не о HPC, не о гипер-кубах замешанных с тета-нотацией. Я говорил об обычных прикладных/системных программистах, которым надо создавать серверное ПО, клиентское ПО, stand-alone ПО, GUI ПО, игры, графические редакторы и т.д.
Здравствуйте, remark, Вы писали:
R>Некоторое время назад я был свидетелем следующей ситуации. Серверное ПО запустили на двух-процессорной машине (в надежде, что оно будет работать в 2 раза быстрее. ха-ха). Оно стало работать в 10 (!) раз медленнее (как потом оказалось причиной было постоянное разделение модифицируемых данных между двумя потоками).
R>Всё это я называю «многопоточность на одном ядре». Фактически система, построенная по таким принципам, образно является «однопоточной с кооперативной многозадачностью».
Хммм... имхо хорошо подходит термин "Мультиплексирование". Фактически один процессор просто мультиплексирует разные функции — повыполнял одну, потом другую.
Здравствуйте, remark, Вы писали:
R>Я бы в принципе не отказался, если бы на моём компьютере, способном выполнять 3,6*10^10 операций в секунду, не тормозил текстовый процессор...
Кстати, о редакторах ... показательный пример. Есть 2 родственных продукта: Understand for C++ и Source Insight. Первый в 2 раза дороже, но, я так и не смог хоть как-то его оценить — на исходниках, размер которых представляет практический интерес, эта штука просто не работает... точнее очень долго их парсит, что-то около часа было. На современном железе, думаю, будет быстрее, но даже пробовать не хочу... много модулей на перле.
R>лоадбалансер? т.е. ты предлагаешь мне купить домой несколько компьютеров и объединить лоадбалансером?
Нет конечно Но для ряда задач это вполне приемлимое решение. И, главное, железо стоит дешевле, чем что-то переделывать.
R>Вообще, я говорил не о HPC, не о гипер-кубах замешанных с тета-нотацией. Я говорил об обычных прикладных/системных программистах, которым надо создавать серверное ПО, клиентское ПО, stand-alone ПО, GUI ПО, игры, графические редакторы и т.д.
Я хотел примерно о том же, но абстрагировался через чур. Чему учат в школе? ИМХО проблема даже не в слабой изученности lock-free алгоритмов. А в том, что, например, с точки зрения теории сложности вычислений, увеличение количества ядер ничего не даёт! Нужна какая-то исправленная теория, которая будет учитывать количество ядер...
Вот например, если ОС будет давать определённые гарантии, то можно без локов обходиться. Возьмём определение Дейкстры:
Семафор — объект, позволяющий войти в заданный участок кода не более чем n потокам
Тут не сказано о внутреннем устройстве, поэтому некоторые начинают крутить спинлок или вызывают сервис ОС (суть планировщик). А между тем, для компилятора элементарная операция — создать в исполняемом модуле таблицы (подобные как для С++ исключений) с адресами участков защищенного кода, а планировщик посмотрит туда и решит, нужно ли переключать контекст. Но это фантаситка Или вспомнить упомянутое здесь отсутствие в IRPе поля affinity...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
