. Но почему ты думаешь, что интерес к этому направлению будет повышаться?
Мне представляется, что наиболее перспективное направление для дальнейшего развития железа — это не наращивание скорости одного калькулятора (сейчас уже два в одно ядро вставляют — одного мало ), который обслуживает всех, а использование десятка-другого простых процессоров (без хитрых конвееров, гипертредингов и сложных микрокодов). Например, наращивание мощности компа может производиться не апгрейдом процессора, а увеличением их количества.
Ествественно, это будет иметь смысл, если найдется способ генерировать код программы так, чтобы он мог быть автоматически распараллелен на очень большое число процессоров. Если развитие "Concurrent и Distributed Programming" приведет к созданию компилятора, с которым не надо вообще думать о разделении и синхронизаци — это будет идеальный случай; если нет, то будет создан язык и возможно новая парадигма, где это будет неотемлемой частью программирования, а не дополнительной головной болью.
Кодёнок wrote: > Ествественно, это будет иметь смысл, если найдется способ генерировать > код программы так, чтобы он мог быть автоматически распараллелен на > очень большое число процессоров. Если развитие "Concurrent и Distributed > Programming" приведет к созданию компилятора, с которым не надо вообще > думать о разделении и синхронизаци — это будет идеальный случай; если > нет, то будет создан язык и возможно новая парадигма, где это будет > неотемлемой частью программирования, а не дополнительной головной болью.
Такой язык есть уже много лет, называется Erlang. Минус его в том, что
он чисто функциональный, а поэтому не всегда удобный.
Здравствуйте, Кодёнок, Вы писали:
Кё>Если развитие "Concurrent и Distributed Programming" приведет к созданию компилятора, с которым не надо вообще думать о разделении и синхронизаци — это будет идеальный случай; если нет, то будет создан язык и возможно новая парадигма, где это будет неотемлемой частью программирования, а не дополнительной головной болью.
Во-первых, рассматривать "Concurrent и Distributed Programming" только в рамках одной программы, которая хитрым способом умным компилятором распараллеливается на независимые потоки исполнения -- это слишком зауженная интерпритация данного понятия. В более интересно создание и развитие технологий, которые позволят выходить не только за рамки одного компьютера и одного процесса, но и за рамки одного приложения. Т.е. развитие того, что сейчас делается с помощью CORBA или WebServices. Например, чтобы поисковая машина Google естественным образом становилось частью твоего приложения.
Во-вторых, от проблем синхронизации все равно никуда не уйдешь. Как бы тебе не помогали компиляторы и средства промежуточного слоя, если что-то работает параллельно, то синхронизироваться результаты работы должны в строго определенных местах. И если ты в выборе этих мест ошибаешься, то... сам понимаешь. А ошибиться очень просто.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Такой язык есть уже много лет, называется Erlang. Минус его в том, что C>он чисто функциональный, а поэтому не всегда удобный.
Ну так я не имел ввиду чисто функциональный язык. Конечно, такое код легко параллелить, но он может работать только специально подготовленной для этого среде, которая бы для него выделяла и освобождала пямять и т.д.
Здравствуйте, Кодёнок, Вы писали:
Кё>...но он может работать только специально подготовленной для этого среде, которая бы для него выделяла и освобождала пямять и т.д.
Это ты про C# или Java?
Я к тому, что кого сейчас такие вещи пугают?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
Кё>>...но он может работать только специально подготовленной для этого среде, которая бы для него выделяла и освобождала память и т.д.
E>Это ты про C# или Java? E>Я к тому, что кого сейчас такие вещи пугают?
Я о том, что хоть чисто функциональный язык легко автоматически паралелится, на нём далеко не все задачи можно решить. Реализация стоящая за ним на самом деле модифицирует память, общается с устройствами и вообще производит кучу побочных эффектов... Так что не думаю, что Erlang годится на роль [единственного] языка общего назначения в той архитектуре, хотя может иметь очень широкое применение.
Здравствуйте, Кодёнок, Вы писали:
Кё>Мне представляется, что наиболее перспективное направление для дальнейшего развития железа — это не наращивание скорости одного калькулятора (сейчас уже два в одно ядро вставляют — одного мало ), который обслуживает всех, а использование десятка-другого простых процессоров (без хитрых конвееров, гипертредингов и сложных микрокодов).
Ну... тут такая ситуация... Работать с одним процессором проще. Поэтому пока позволяют резервы, увеличивается мощность одного процессора. Как только возникает барьер --- вспоминают о том, что можно их поставить несколько
Фактически увеличение производительности можно добиться не только на уровне железа, но и на уровне софта
Зачем увеличивают производительность железа? В большинстве случаев, сделать более дешевым софт (более проста разработка, реализация, ...). Разрабатывать софт с поддержкой параллельной архитектуры сложнее, вполне может дешевле оказаться дешевле оптимизировать приложении под один процессор, чем поддерживать распараллеливание. Другое дело системы, в которых в ТЗ заложена параллельность
Кё>Ну так я не имел ввиду чисто функциональный язык. Конечно, такое код легко параллелить, но он может работать только специально подготовленной для этого среде, которая бы для него выделяла и освобождала пямять и т.д.
Проблема в том, что в императивных языках существует такая неприятная штука как внешние эффекты.
И фактически, описанием внешнего эффекта является тело конкретной функции или целой программы.
Получается, что в этом случае нужно построить такой суперкомпилятор, который бы формализировал внешние эффекты, находил те участки программы, которые могут быть распаралелены, и, соответственно, распаралеливал.
Как ты думаешь, насколько сложно и вообще возможно ли сделать такой компилятор?
Здравствуйте, Кодёнок, Вы писали:
Кё>Мне представляется, что наиболее перспективное направление для дальнейшего развития железа — это не наращивание скорости одного калькулятора (сейчас уже два в одно ядро вставляют — одного мало ), который обслуживает всех, а использование десятка-другого простых процессоров (без хитрых конвееров, гипертредингов и сложных микрокодов). Например, наращивание мощности компа может производиться не апгрейдом процессора, а увеличением их количества.
Чем больше процессоров, тем меньше алгоритмов способны их эффективно использовать. И никакой магический компилятор тут не поможет — он может распаралелить только если алгоритм поддается распаралеливанию.
... << RSDN@Home 1.2.0 alpha rev. 629 on Windows XP 5.1.2600.131072>>
Здравствуйте, Cyberax, Вы писали: C>Такой язык есть уже много лет, называется Erlang. Минус его в том, что C>он чисто функциональный, а поэтому не всегда удобный.
1) Erlang не является чисто функциональным языком, побочные эффекты — его неотъемлемая черта.
2) То, что он местами функциональный (именно местами) является не минусом, а плюсом, так сделали специально, и "не всегда удобен" он совсем не поэтому.
3) Компилятор Erlang никогда не занимается автоматическим распараллеливанием. Ни при каких условиях. Параллелизм всегда явный.
4) Программист на Erlang должен думать о распаралеливании и синхронизации.
5) Таким образом, твой пост ошибочен практически везде — в каждом слове.
5) Мое мнение такое — не знаешь, не надо отвечать. Это же надо было облажаться в таком количестве мест. Не стыдно?
Брат Gaperton,
G>5) Таким образом, твой пост ошибочен практически везде — в каждом слове. G>5) Мое мнение такое — не знаешь, не надо отвечать. Это же надо было облажаться в таком количестве мест. Не стыдно?
Жостко. Ну ошибся человек, ну зачем же его так сразу втаптывать в ... Чуть-чуть терпимее.
Здравствуйте, Кодёнок, Вы писали:
Кё>Ествественно, это будет иметь смысл, если найдется способ генерировать код программы так, чтобы он мог быть автоматически распараллелен на очень большое число процессоров. Если развитие "Concurrent и Distributed Programming" приведет к созданию компилятора, с которым не надо вообще думать о разделении и синхронизаци — это будет идеальный случай; если нет, то будет создан язык и возможно новая парадигма, где это будет неотемлемой частью программирования, а не дополнительной головной болью.
Есть стандарт стандарт OpenMP. Пишешь в однопоточном императиве, тока стараясь так писать чтобы это можно было теоретически расспаралелить. Потом расставляешь специальные комментарии, где и какие данные меняются независимо. И все. После нескольких этапов — компиляции, профилирования, программа становится расспаралеленой в нужных местах.
Незнаю, как правда это на практике получается...
Насколько я понимаю, вы хотите примерно такого же, но только в компонентном программировании?
-- Главное про деструктор копирования не забыть --
Здравствуйте, AndrewVK, Вы писали:
Кё>>Мне представляется, что наиболее перспективное направление для дальнейшего развития железа — это не наращивание скорости одного калькулятора (сейчас уже два в одно ядро вставляют — одного мало ), который обслуживает всех, а использование десятка-другого простых процессоров (без хитрых конвееров, гипертредингов и сложных микрокодов). Например, наращивание мощности компа может производиться не апгрейдом процессора, а увеличением их количества.
AVK>Чем больше процессоров, тем меньше алгоритмов способны их эффективно использовать. И никакой магический компилятор тут не поможет — он может распаралелить только если алгоритм поддается распаралеливанию.
Может это проблема алгоритмов, и того, как мы привыкли думать об алгоритмах (один исполнитель).
Например, любую классическую сортировку распараллелить трудно, но если разрабатывать алгоритм специально для такой архитектуры, то может получиться например, когда несколько процессоров сортируют части, а затем один или два занимаются слиянием.
Здравствуйте, mishaa, Вы писали:
M>Есть стандарт стандарт OpenMP. Пишешь в однопоточном императиве, M>Незнаю, как правда это на практике получается... M>Насколько я понимаю, вы хотите примерно такого же, но только в компонентном программировании?
Нет, я хочу уничтожить в мире все калькуляторы Я не верю, что пошаговая инструкция для одного исполнителя в общем случае может быть переделана в инструкцию для нескольких исполнителей без полного анализа её смысла и переписывания.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Брат Gaperton,
G>>5) Таким образом, твой пост ошибочен практически везде — в каждом слове. G>>5) Мое мнение такое — не знаешь, не надо отвечать. Это же надо было облажаться в таком количестве мест. Не стыдно?
LCR>Жостко. Ну ошибся человек, ну зачем же его так сразу втаптывать в ... Чуть-чуть терпимее.
Знаешь, я все понимаю, но настолько откровенная дезинформация — это уж слишком. Такое очень редко случается, к счастью. На моей памяти было всего несколько случаев за 3 года.
От себя могу добавить, что многим из тех алгоритмов, которые практически не параллелятся дикая скоростью вычислений и не нужна! Каждый из них можно и на одном процессоре выполнять, даже если этот процессор медленный.
Например, рисование интерфейса. Стандартные Windows-контролы и диалоги замечательно и очень быстро рисовались ещё когда у меня был машины Celeron-433 и Pentium-200MMX. А ведь это те же самые кнопочки, с которыми мы и сейчас работаем. Интерфейсы на Gecko и HtmLayout на Celeron-433 тоже отлично работали, а ведь там ещё есть что оптимизировать. Никаких больших потребностей в UI, с которыми бы они не справились, я ещё не встречал.
Много алгоритмов используют чтение и запись файлов, и ограничены быстродействием жестких дисков или флеш-памяти, которые ещё долго не смогут перегрузить тот же P200.
Здравствуйте, Gaperton, Вы писали:
G>4) Программист на Erlang должен думать о распаралеливании и синхронизации.
Имхо, это правильно. При разработке распределенных приложений лучше иметь инструмент, который позволяет программисту контролировать распараллеливание и синхронизацию, чем полагаться на то, что все как-то неявно будет работать так как надом.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Кодёнок,
Кё>Нет, я хочу уничтожить в мире все калькуляторы Я не верю, что пошаговая инструкция для одного исполнителя в общем случае может быть переделана в инструкцию для нескольких исполнителей без полного анализа её смысла и переписывания.
А и не надо не верить. Достаточно заглянуть в учебники по вычислительной сложности.
Идея распараллеливания имеет смысл только если удаётся получить выигрыш. Если кроме усложнения алгоритма и нажитой головной боли мы не получим долгожданного ускорения, то грошь цена такой оптимизации. Думаю это понятно.
Теперь пример для охлаждения оптимизма: есть задача о Максимальном Независимом Множестве в графе. Независимое множество — это множество попарно несмежных вершин:
Задача формулируется просто: найти независимое множество максимальной мощности.
Вот жадный алгоритм для этой задачи:
Начинаем с пустого множества.
Пока текущий граф не пуст делаем следующее:
Добавляем вершину v с наименьшей степенью.
Удаляем все смежные с v.
Этот алгоритм невозможно параллелизовать в принципе. (это происходит потому, что каждое последовательное удаление вершины приводит к пересчёту всех степеней в графе, и пока пересчёт не будет выполнен, мы следующую вершину взять не сможем).
А заменить алгоритм можно не везде. Так что вывод мой будет таков: параллелится алгоритм — хорошо, нет — увы. Параллельная архитектура — хорошо, но это не будущее вычислений — она не универсальна
), который обслуживает всех, а использование десятка-другого простых процессоров (без хитрых конвееров, гипертредингов и сложных микрокодов). Например, наращивание мощности компа может производиться не апгрейдом процессора, а увеличением их количества.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Я не верю, что пошаговая инструкция для одного исполнителя в общем случае может быть переделана в инструкцию для нескольких исполнителей без полного анализа её смысла и переписывания.
