Обсуждение

подход интересный, но никак не оригинальный. PRAM - это действительно наиболее простая для использования и наиболее сложная для реальной реализации модель параллельной машины из тех, которым нас в 1994-ом году обучали на курсе "эффективное использование массивно-параллельных архитектур". В те годы обучение (в университете на спецкурсе) начинали именно с этой модели - так проще всего ощутить драйв от резкого ускорения программ: еще бы, имея N-PRAM можно определить минимум\максимум в массиве из N чисел за два шага ( О(1), строго говоря)! А потом переходили к использованию архитектур, реально существующих в железе. Приятно, что за 15 лет железо сильно поумнело и подешевело, так что можно реализовывать PRAM-подобные архитектуры.

Конечно, "новое -- это хорошо забытое старое". Основной пойнт авторов именно в этом: "железо уже достаточно поумнело, чтобы его сложность дала возможность программировать нормальным людям, а не только яйцеголовым".

Профессора уже наплодили "программистов на Ява", которые могут писать, но не понимают, что делают. В результате фирмы вынуждены отсеивать тех, у кого язык стоит в профиле, но не в голове. Впрочем, корпорациям всё равно. Но у них отделы продаж крутые.

Это хорошо сказано: "язык стоит в профиле, но не в голове". Хотя ничего не понял, причем тут "профессора" -- они ведь все разные, одни плодят бездарей, другие вполне себе учат понимающих людей. Сам Uzi вполне себе хорош, у него студент за пару лет обучения процессор с нестандартной архитектурой и развитой параллельностью разрабатывает.

Мне думается проблема не в том чтобы записать параллелизм, а в том, чтобы его найти. В этом смысле параллельное программирования сильно отличается от последовательного. Есть даже специальные методы создания математических алгоритмов, которые содержат в себе много параллелизма.

После того, как параллельная разработка выйдет в массы, получится ужас. Защита от дурака хороша, если дураков мало. А так, дурной работой можно и шестнадцать процессоров нагрузить. Как писал Союз Инженеров Германии: "Сертифицированный Микрософтом компьютерный инженер - это единственный вид инженеров, на подготовку которых тратят четыре дня, а не четыре года" После чего в Германии слово "инженер" Микрософт из своих сертификатов убрал.

Опять чрезвычайное обобщение, никак не относящееся к теме постинга :( Я считаю, что выход в массы чего угодно приводит к ужасу. С другой стороны, без выхода в массы происходит тот же ужас, но по-другому. Эти процессы опопсения серьезных знаний неинтересны, их нужно выносить за скобки и воспринимать как обычную часть мира, которую если и обсуждать, то обсуждать специально, а не приписывать-с к каждому-с постигу-с, как когдато-с приписывали-с с-с. Я ведь не могу каждый раз приписывать "Disclaimer. Потому как написанным в постинге непременно воспользуются идиоты разных мастей, все вокруг останется таким же плохим, как оно было раньше, плюс еще и хуже за счет получения идиотами нового эффективного средства, которое им позволит вредить круче".

Если нет шансов параллельность записать, то нет шансов ее и найти. Ибо тренировка на нахождение параллельностей требует учебника с примерами записей уже найденной параллельности.

Я просто работаю с реальными людьми. Первым делом, те страшилки, что по первой ссылке идут справа мне как-то сомнительны. Не так всё ужасно и метафоры в качестве доказательства приводить несколько не честно. Второе, фразы типа FPGA+compiler operated nearly flawlessly вызывают смутные подозрения. Короче, для определённого класса задач, которые IMVHO лучше решать без eXplicit, это пойдёт. В остальном, не понятно что будут делать умные компиляторы, чтоб посреди распараллеленных вычислений не вылезли блокировки? А то я видел, как системы, которые "теоретически невозможно повесить", застывали в дидлоках.

+1 + > ...реальные архитектурные прорывы могут быть именно в командах, занимающихся разработкой учебных курсов. Вот и занимались университеты двиганием науки... А потом госмужи решили, что дешевле, если науку будет Микрософт за свой счет двигать (это то, что мне ближе, однако, кажется, тенденция не с программирования началась...)

Без понятия. http://www.microsoft.com/germany/learning/zertifizierung/default.mspx

Давно дело было. Может изменили - что-то. Насколько я помню, борьба была за приставку Ing., которую немцы любят к имени присобачивать. И, вроде, готовят не четыре дня, а две недели.

Ну, это содержательные вопросы, их вполне можно задать авторам подхода (а вопросы таковы, что наверняка уже есть где-то письменные разборки в статьях). Ответы, думаю, будут ровно такими же, как и для многих других систем: компилятор сравнимого качества с любыми другими (в том числе неучебными) компиляторами, FPGA сделана без учета каких-то оптимизаций, формальная верификация не проводилась (но теоретически возможна, ибо под этим подходом есть формальная теория) и т.д. Насчет сомнительности первой страшилки -- это требует отдельного разворачивания и каких-то экспериментов.

Дык, возможностей-то для записи параллельности куча. В чистых функциональных языках, параллельность вообще неявно встроена, ибо аргументы функций можно вычислять в любом порядке, в том числе и параллельно.

Там имелось ввиду как я понял "математические алгоритмы" с потенциалом распараллеливания. Например, часто встерчающаяся несложная задача "линейного программирования" - поиск оптимального решения какой то экономической задачи. Там часто встречаются матрицы до тысячных размеров, и казалось бы взять кусками раздать по процессам, но есть практически только один метод решения - "симплекс-метод", а он вообще не распараллеливается. Сейчас создаются новые на других принципах (плавной сходимости например).

Именно так. Но есть и более простые случаи. К примеру, суммирование элементов массива в последовательной записи: res = 0 for i = 0 to n res = res + a[i] параллелизуется только с учетом законов ассоциативности. Что означает изменение порядка операций и значит может повлиять на ошибки округления чисел с плавающей точкой, что не всегда допустимо в расчетах. Т.е. вообще говоря, он не параллелизуется без явных указаний компилятору. Ну и другой случай - даже если последовательная запись допускает извлечение параллелизма, компилятор не всегда сможет это распознать. К примеру, если треугольную матрицу плотно упаковать в линейный массив, для экономии памяти, то компилятор потеряет весь параллелизм.

Чтобы не застаиваться на месте, нужно не только что-то крутое делать, но и кого-то этому крутому учить. Вот я тоже на эту тему думаю. У меня знакомый утверждал, что можно так объяснить математику, что она будет проста и понятна с 12 летнего возраста. Я вот задумался над обучением старшекласников и студентов конструктивной математик и логике, которые гораздо лучше ложится в основу компьютеров и программирования, нежели классические. По понятным причинам - ибо конструктивная математика/логика в качестве доказательства существования требует сконструировать постулируемый объект, вывести возможность его существования, как следствие принципе исключения третьего, в ней недостаточно. А конструирование объекта - это уже алгоритм :).

>> Чтобы не застаиваться на месте, нужно не только что-то крутое делать, но и кого-то этому крутому учить. Т.е. разделение на исследовательские инстутуты и обучающие университеты принципиально порочно?

Да, принципиально порочное. На Западе (да и в России) лучшие -- это исследовательско-учебные заведения.