Здравствуйте, AndrewVK, Вы писали:

E>> Можно, например, написать интерпретатор С++, который проверяет корректность всех указателей и т. п.

AVK>Нельзя, семантика С++ не позволяет. Чтобы позволяла нужен safe код.

Не надо писать никаких интерпретаторов и не нужен никакой safe код. Надо просто взять Bounds Checker , инструментировать программу и запустить. Он прекрасно справлялся с этой задачей (говорю в прошлом времени потому что , увы, как утверждают, нынешние версии хуже).

E>>Хороший пример -- FORTRAN, который умел правильно написанную программу компилить и на крэй и на х86.

AVK>Хороший. Потому что FORTRAN намного абстрактнее С++, и, как следствие, позволяет намного больше оптимизатору.

А С он тоже намного абстрактнее ?

E>> Но при этом тебе всё равно надо было писать такие алгоритмы, которые ложатся на архитектуру...

AVK>Потому что уровень абстракций недостаточен . Вот для SQL уже не надо учитывать архитектуру платформы.

Для Бейсика тоже.

Здравствуйте, Cyberax, Вы писали:

C>>> Оптимизатору там простор из-за того, что сам язык очень ограничен, и ты вынужден строить программ из оптимизаторно-дружественных примитивов.
AVK>>Это и есть высокая степень абстракции.
C>Нет. Это высокая степень ограниченности. Скажем, в Фортране-77 запрещена рекурсия

Реально разрешена была в тех компиляторах, которыми я пользовался.

> невозможен алиасинг

А это что такое ? EQUIVALENCE куда девал ? Или ты о другом ?

>массивы переменной длины

Ввели в Фортран-90. ИМХО довольно криво.

C>Из "высокой степенни абстракции" там только встроенные настоящие многомерные массивы.

Это да.

Здравствуйте, thesz, Вы писали:

T>>>Рантайм у меня был Хаскельный, я просто расставил в нужных местах аннотации par+pseq и запускал с разным количеством процессоров. Потратить 20 минут на ускорение в 20% — приемлемо, по-моему.

R>>Ну я надеюсь, ты понимаешь, что вот так просто "на слабо" никто не будет садиться и реализовывать полноценную систему.

T>Причём здесь "на слабо"?

T>Вот тебе интересна какая-то тема. Её надо обязательно изучить. Любое теоретическое изучение будет неполным, поэтому надо изучить практически.

T>Значит, надо сделать систему.

Ну почему же сразу обязательно. Во-первых, я интересуюсь таким кол-вом вещей, что на всё делать по полномасштабной системе — это мне надо будет по 48 часов свободного времени в сутки. Приходится искать какие-то разумные компромиссы, что-то я пробую практически, что-то — нет. Во-вторых, с опытом и знаниями приходит т.н. "техническая интуиция", это когда даже не пробуя технологию практически можешь предвидеть, где у неё будут сильные стороны, где слабые, откуда ждать подвохов и т.д.
Симуляцию на агентном подходе я не пробовал, но 2 самых критичных места я подозреваю — я их указывал. И я не говорил, что сделанная с наскоку симуляция на агентном подходе будет прекрасно масштабироваться, я как раз уверен в обратном — поэтому писать целиковую систему, что бы увидеть, что она действительно не будет масштабироваться мне мало смысла...



T>Мне этот агентный подход совсем не нужен. Мне больше нравится dynamic dataflow, в котором состояние уже разбито, как надо, то есть так, чтобы никому лишнему ничего не мешало. С его помощью можно добиться практически теоретического потолка параллелизма.

А можешь дать какие-то ссылки на "dynamic dataflow".
Исходя из того, что я нашёл (хотя я не уверен, что нашёл именно то, что ты имеешь в виду), это фактически тот же агентный подход — имеем фифо-очереди, имеем агентов. Как я понял отличие в том, что агенты — примитивные, т.е. выполняют очень простые операции (хотя это и не было там явно указано).
Если это так, то сильно напоминает COSA:
http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm
Правда COSA — синхронная и детерминированная, а из-за этих свойств там достаточно сложно добиться эффективной реализации — автор как-то очень уклончиво говорит о реализации...



R>>Поэтому намекни просто, что же я должен увидеть после самостоятельной реализации. Вполне вероятно, что намёка будет достаточно. Так в чём же была причина плохой распараллеливаемости? Это именно агентный подход плох для распараллеливания задач симуляции или конкретная реализация? У меня подозрение, что конкретная реализация.

T>Я утверждаю, что необходимые для применения агентного подхода преобразования программ не проще, чем необходимые для, допустим, применения OpenMP. Читай, любого другого современного подхода.

Что ты имеешь в виду под преобразованиями? Для OpenMP в общем случае не нужны никакие преобразования (хотя анализ нужен). Для агентного — это зависит. Если гранулярность обработчиков сообщений достаточна, то особо ничего делать и не надо; если недостаточна, то один вариант — действительно делать какие-то преобразования программы (возможно — тривиальные, возможно — нет), второй вариант — всё же попытаться наделить ран-тайм достаточным интеллектом.



R>>По поводу 20% — смотря какую цель ставить. Само по себе 20% за 20 минут, конечно, не плохо. Но если задача, например, — создать среду для эфективного моделирования на современном многоядерном железе (сейчас — 2/4 ядра, завтра — 8) — то задача не решена. Если на 2 ядрах, у тебя 20%, это значит, что на 4 будет 30%, а на 8 — 35%, т.е. используем только 17% вычислительной мощности.

T>А если она не решается? Ась?

То что? По-моему — ничего, просто не очень хороший контекст для разговора о распараллеливании.
Гораздо более интересно если всё же решается, то тут видно, что одни подходы решают её, другие — нет.


Или ты имеешь в виду, что теоретический максимум это и есть те самые 20% и наша задача как выжать их? Ну тогда тут надо заниматься такими вещами как ограничивать кол-во рабочих потоков числом 2, иначе мы в лучшем случае будем тратить процессорное время впустую, а в худшем производительность будет деградировать. Далее детектировать топологию системы и привязать эти два потока к ближайшим ядрам желательно разделяющим кэш (но ни в коем случае ни к двум аппаратным потокам внутри одного ядра, и ни в коем случае не к двум процессорам, находящимся на разных NUMA узлах).
Кстати, хороший вопрос — какие из упоминавшихся систем (Haskell, Erlang) это могут?


T>(вообще-то решается, конечно, но отнюдь не простым вставлением par и pseq. Преобразования будут потяжелее. И для разных типов систем — синхронные, асинхронные — разными, с разным результатом.)

T>>>У меня, например, получается совершенно нетривиально. Например, необходимо выделять слабосвязанные подграфы и тщательно смотреть, не может ли кто послать некоторому подграфу лишнего или гарантировать низкую вероятность этой посылки.
R>>Так проблема была в низкой гранулярности?

T>Не "была", а "будет".

T>Это я рассуждал о будущей системе, которую я сейчас прикидываю.

Ты это хочешь перекладывать на конечного программиста? Или этот анализ будет делать ран-тайм?


R>>По поводу автоматического увеличения гранулярности, пока ничего не могу сказать — это я просто на скорую руку рекомендовал человеку куда надо думать, что бы достить эффективного распараллеливания. Скорее всего я буду думать над этой задачей, но пока не могу ничего сказать. Гипотеза, что есть некоторые относительно простые эвристики, которые позволят автоматически добиваться близкой к оптимальной кластеризации.

T>Её, как и всё остальное, надо проверять.

T>Бремя доказательства лежит на высказавшем.

Её надо не только проверять, для начала надо придумать алгоритм, как это можно делать...


R>>>>А во-вторых, сотня актёров хватит лет на 5 точно, а то и больше. Для серверного ПО это может быть более, чем приемлемо.

T>>>Э-эх.

R>>Не согласен? Если, например, имеется 4-ядерный сервер, или 2-процессорный х 4-ядерный, сотня агентов более чем хватит. Нет? А через 3 года при существенном увеличении нагрузки всё-равно большую часть переписывать.

T>Я про другое.

T>Ты сперва добейся независимой работы этой сотни агентов.

T>А то ты о самом сложном говоришь, как о решённой задаче.

Не понял. Работа разных агентов по определению независима. Что ты имеешь в виду?

Здравствуйте, Erop, Вы писали:


PD>>Было мне 20 с чем-то лет. И вот на машине с памятью 32 КСлова (слово — 48 бит) надо было...

E>В названии магинки число "6" часом не присутствовало?

БЭСМ-6 . Но точно не из-за этого. Хотя... До этого была БЭСМ-4, а вот БЭСМ-5, насколько я знаю, не было.

Здравствуйте, AndrewVK, Вы писали:

AVK>Только все равно нет никакой гарантии, что при любом, сколь угодно большом количестве прогонов без проблем втоя программа доказанно корректна.

Не подменяй понятий. Речь шла о том, что это можно сделать, а не о том, что можно доказать корректность этой программы.

Здравствуйте, Erop, Вы писали:

E>Дык о том-то и речь, что С++ спроектирова так, что нифига не изолирует тебя от аппаратуры.

Я в курсе.

E> Абастракция-то дырявая!

И в этом основная проблема С++

Здравствуйте, AndrewVK, Вы писали:

M>>Так не в наличии промежуточных уровней абстракции дело, а в невозможности их перепрыгнуть, в отсутствии в них "дырок".

AVK>То есть в асбтракции самой по себе уже ничего плохого нет? Уже хорошо.

Не прошло и года, как до тебя это дошло.

AVK>Ну а вместо наличия дырок нормальные люди делают абстракции расширяемыми. Начиная с примитивных решений навроде intrinsic функция и заканчивая теми же макросами Немерле или механикой linq в шарпе.

intrinsic — это не расширение. Ну, я подожду, пока до тебя и это дойдёт.

M>>Если у тебя есть JVM — то ты её перепрыгнуть не можешь.

AVK>Могу. Воспользовавшись JNI.

Далеко не всегда. Если речь идёт о том, чтоб иметь возможность сделать нечто "в принципе" — то можешь.
Если речь идёт о дырке нужной для оптимизации кода — то JNI тебе здесь не помошник.

M>>Если у тебя есть FPGA — не надо писать программы в терминах вентилей, надо только из программы иметь возможность перенастроить эти вентили.

AVK>Нет, нужна возможность добавить в компилятор FPGA возможность расширения. Прямое управление через все слои абстракции это бееее.

Вот чтоб была возможность добавить расширение в компилятор FPGA — тебе и нужна возможность управления через все слои абстракции.
Никак иначе это сделать нельзя.

Здравствуйте, AndrewVK, Вы писали:

AVK>И в этом основная проблема С++
Ну а я считаю, что кроме того, что это основная проблеме С++, это ещё и основное его достоинство

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>БЭСМ-6 . Но точно не из-за этого. Хотя... До этого была БЭСМ-4, а вот БЭСМ-5, насколько я знаю, не было.

Упс, а я именно на эту пашинку и намекал. А про то, что там ещё и аллюзия на размер тамошнего слова получилась не подумал

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Спасибо за совет, мне такое действительтно не приходило в голову , но суть дела это мало изменяет. Посоветуй такой способ ввода данных в реальных формах
При чём здесь формы? Мы говорим о языке программирования, а не UI.

Здравствуйте, lomeo, Вы писали:
L>В MySQL есть.
Именно про него я и говорил во фразе "некоторые диалекты..."

T>>Мне этот агентный подход совсем не нужен. Мне больше нравится dynamic dataflow, в котором состояние уже разбито, как надо, то есть так, чтобы никому лишнему ничего не мешало. С его помощью можно добиться практически теоретического потолка параллелизма.

R>А можешь дать какие-то ссылки на "dynamic dataflow".

Можно начать с английской Wikipedia.

R>Исходя из того, что я нашёл (хотя я не уверен, что нашёл именно то, что ты имеешь в виду), это фактически тот же агентный подход — имеем фифо-очереди, имеем агентов. Как я понял отличие в том, что агенты — примитивные, т.е. выполняют очень простые операции (хотя это и не было там явно указано).
R>Если это так, то сильно напоминает COSA:
R>http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm
R>Правда COSA — синхронная и детерминированная, а из-за этих свойств там достаточно сложно добиться эффективной реализации — автор как-то очень уклончиво говорит о реализации...

Нет, это не так.

FIFO очередей нет, агентов тоже нет. Вся информация для выполнения "узла" (отдельного элемента пространства вычислений программы) содержится в отправленной узлу информации. Для изменения знака числа нужно всего лишь это число, для сложения/умножения/деления — левый и правый операнды.

Программа узла настолько примитивна (одна-две полезных операции), что даже говорить об агентном подходе вообще нельзя. И состояния нет.

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

T>>Я утверждаю, что необходимые для применения агентного подхода преобразования программ не проще, чем необходимые для, допустим, применения OpenMP. Читай, любого другого современного подхода.
R>Что ты имеешь в виду под преобразованиями? Для OpenMP в общем случае не нужны никакие преобразования (хотя анализ нужен).

Приватизация, например.

Я же изучал преобразования, необходимые для работы с OpenMP.

R> Для агентного — это зависит. Если гранулярность обработчиков сообщений достаточна, то особо ничего делать и не надо; если недостаточна, то один вариант — действительно делать какие-то преобразования программы (возможно — тривиальные, возможно — нет), второй вариант — всё же попытаться наделить ран-тайм достаточным интеллектом.

Ты сперва преобразуй программу побольше в агентный вариант исполнения.

Возьми пример, и попробуй.

А потом попробуй последовательно избавляться от любых препятствий.

T>>А если она не решается? Ась?
R>То что? По-моему — ничего, просто не очень хороший контекст для разговора о распараллеливании.
R>Гораздо более интересно если всё же решается, то тут видно, что одни подходы решают её, другие — нет.

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

"В отличии от."

R>Или ты имеешь в виду, что теоретический максимум это и есть те самые 20% и наша задача как выжать их? Ну тогда тут надо заниматься такими вещами как ограничивать кол-во рабочих потоков числом 2, иначе мы в лучшем случае будем тратить процессорное время впустую, а в худшем производительность будет деградировать. Далее детектировать топологию системы и привязать эти два потока к ближайшим ядрам желательно разделяющим кэш (но ни в коем случае ни к двум аппаратным потокам внутри одного ядра, и ни в коем случае не к двум процессорам, находящимся на разных NUMA узлах).
R>Кстати, хороший вопрос — какие из упоминавшихся систем (Haskell, Erlang) это могут?

Вообще ничего не понял.

Переформулируй.

T>>Не "была", а "будет".
T>>Это я рассуждал о будущей системе, которую я сейчас прикидываю.
R>Ты это хочешь перекладывать на конечного программиста? Или этот анализ будет делать ран-тайм?

Рантайм, само собой. Специально заточенный под моделирование аппаратуры.

Не под любую задачу, заметь.

T>>Её, как и всё остальное, надо проверять.
T>>Бремя доказательства лежит на высказавшем.
R>Её надо не только проверять, для начала надо придумать алгоритм, как это можно делать...

А для динамического потока данных, когда нет состояния в агентах, этот алгоритм уже готов.

И для OpenMP тоже есть.

Ну, и кто в проигрыше?

По-моему, в проигрыше агентный подход.

T>>Ты сперва добейся независимой работы этой сотни агентов.
T>>А то ты о самом сложном говоришь, как о решённой задаче.

R>Не понял. Работа разных агентов по определению независима. Что ты имеешь в виду?

Я имею в виду алгоритм, который "для начала надо придумать".

Ты его ещё, оказывается, не придумал, а уже споришь о преимуществах агентного подхода.

По-моему, ты зря тратишь чужое время.

Здравствуйте, lomeo, Вы писали:

IT>>Ну-ка, ну-ка? Что у нас за той дверью?

L>С++!

Понятно. Только что вышел из комнаты с плюсами и тут же опять в неё попал. Это называетя circle reference, проблема не имеющая вменяемого решения для плюсов.