OberonCore

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

:lol:

Если Вы используете потоки процессора (ОС), то всё равно, на чём писать. Диспетчить их будет ОС - и нагружать ими ядра тоже. Но иметь сильно больше потоков, чем ядер, неэффективно.

Посему такие системы, как Эрланг, диспетчат задачи сами.
И Вам тоже никто не мешает эти же заниматься, независимо от языка.

Интересный всё-таки ум у Влада.

Впечатление от всей этой concurrency, что тут общее явление для всех настоящих пролем (т.е. таких, истинный "шаблон" которых не хочет выясняться):
каждый прикладывает к ней нечто своё любимое -- в том числе и с потолка взятое, и со всякими неявными предположениями.
В результате получается большая куча на проблеме, и сама проблема интерпретируется сквозь эту кучу.

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

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

Т.е. на Active Oberon, Zonnon, по хорошему, должна быть аллергия?

Эти два языка - эксперимент. Интересный с точки зрения "внутренней кухни" для любого системщика.

По фундаментальности (т.е. реальной значимости и долгосрочности идей, в них засунутых) они не идут ни в какое сравнение с базовыми Оберонами. А если сопоставлять с параллельными языками - то ни с Адой, ни с Эрлангом, ни c Хансеновскими системами.

Кое-что, вроде, там нащупано. Но это кое-что, имхо, наиболее у них видно как раз в Композите.

Как связаны библиотечность и наличие убедительной (для вас) теории? А DSL имеет право на существование тоже только при наличии теории?

Вирт уже всё сказал.

Вам нужно разобраться с точным смыслом слова "теория". Можно оттолкнуться от древнегреческого значения.

Вот тут есть кое что про теорию:
Серебрянский А.И., Сыч Г.А. Обзор распараллеливающих компиляторов
http://www.sysprog.info/2008/09.pdf

Вы в своем репертуаре. Сначала скажете глупость, потом отписываетесь туманными замечаниями - типа некогда тут разжевывать очевидные вещи.

Ну, очевидны, как минимум, два соображения:

1) С точки зрения разработки. Создание языка по сравнению с библиотекой требует значительных усилий и потом ограничивает возможность эксперимента. Без уверенности в том, что выбранная модель достаточно основательна, глупо брать такое ярмо, не правда ли?

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

Смотря какой язык создавать Если С++ - то да, страшно Однако оберонщики не чураются дотачивать компилятор под свои нужды (подсистема COM в BB), не говоря уже о рантайме (Active BB). Сам info21 упомянул как он круто доточил BB для интервальных вычислений, а уж какой-то там GC подменить - так вообще плевое дело
Так что я не вижу ничего страшного в "языке под задачу". Очень может быть, что создание такого языка окажется дешевле библиотеки на чем-то универсальном. Особенно если умеючи. Применительно к обсуждаемой теме можно вспомнить Композиту. Ну фиг знает получится из нее что-то или нет, но вот нормально "пощупать" на бибиотеке то, что для чего она создавалась - нельзя. Задачи не ждут, пока придет очередной Дейкстра и все затеоретизирует.



Ага. Поэтому я не считаю оберон-07 продолжением линейки "универсальных оберонов" и называю его "языком под задачу".

Влад, не комплексуйте. На вашу брехню мне отвечать западло.

Ну и повторю совет: книжки хорошие читайте, а не одни мануалы.

Спасибо, любопытно.

Только это теория не в том строгом смысле, который я имел в виду.

В общем, подтверждается ранее высказанное впечатление.
Комбинаторная деятельность у компиляторщиков.
Не значит, что там не может быть ценных зерен. Просто их еще надо там раскапывать...

Был такой язык Occam, Тони Хоар участвовал в его разработке, так этот язык как раз был основан на теории -- Communicating Sequential Processes (CSP) process algebra.
Так что есть как мимнимум один широко известный пример использования теории в языке программирования со встроенными средствами параллельных вычислений. Не считая всяких экспериментальных никому не известных языков на основе всяких pi-calculus...

Да, про книгу Хоара хотел упомянуть.

Только вот язык к ней совершенно не нужен.

Теория Хоора -- это пока "a theory" (неопределенный артикль),
а не "the theory".

Впрочем, Хоора читать стоит. Надо будет пересмотреть, где-то рядом лежит, а то давно уж дело было.

Теория-то чего?
Первоисточник назовите, а то мож я читал?