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

А тут речь о том, чтобы прямо в железе можно было сделать запуск задач на нескольких процессорах.
Вот, когда можно будет написать
params # xt cpu# SТАРТ - все и встанет на свои места

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

но для некоторых языков более формально, а для некоторых более реально (Форт, Лисп, Смолтолк)


этими моментами можно еще и с помощью контекста управлять

а это у Форта не отнять. Достаточно вам не пользоваться переменными, а решать все через стек. Ну и всякие мьютексы тоже не помешают.


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

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

А нигде нет гарантии, поэтому нужен механизм который будет запоминать все решения и выделять самые эффективные.


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

Даже если число вариантов представляет собой факториал или экспоненту от чего-нибудь немелкого?


От HDL до суперскаляра очень и очень далеко. HDL работают на более низком уровне, и способны описать не только суперскаляр, но и неконвейеризованный процессор, и даже вообще правильно соединенную, но бесполезную схему. Правильная точка приложения усилий в HDL - уровень регистровых передач (RTL, Register Transfer Level). На этом уровне можно прекрасно распараллелить вычисления, но никто не гарантирует, что разработчик правильно представляет себе принципы работы своей схемы и передает все промежуточные результаты вовремя и куда нужно.

"я..не думал.." - так вроде бы говорил Шульга инженеру Гарину..
и я не думал - что самый что ни есть обычный вопрос породит целую тему
..и она сразу же успешно скатится в философию

Тема о параллельности - она вообще очень богата на "вечные мотивы". Самый заметный "мотив": наличие мультиядренной и мультипроцессорной среды, будто бы потребует какого-то особенного параллельного программирования, которое должно открыть почти мистические возможности
Ага. "5 капель - переворот сознания" . Как будто мало тех переворотов, которые для маркетинга делает Макрософт раз в 2 года.
А на самом деле? Реклама "новой эры", пришедшей к нам вместе с CoreDuo
Однако: при многопоточности обязаность шедулить все хозяйство - забота ядра ОС (макро- или микро- -- неважно), а никак не компилятора, и тем более программиста. И не надо заморачиваться количеством потоков - их в любом случае сильно больше, чем ядер. (Ну, если ядра не тысчами мерить;) ). И даже если многопоточность сильно не используем, то количества процессов (по 1 поток штучка) в любой ОСи вполне хватит для работы -надцати ядер (если, конечно, ОСь не клон МС-ДОС;) А спецеффекты с out-of-order по своей природе - вещь похожая на pinhole-оптимизацию. Со всеми вытекающими..

К сожалению, я от процессоростроения очень далеко:( - пришлось с гуглом пообщаться, чтобы узнать чего хотят от процессоров заокеанские Чамберлены и Навуходоносоры ;( А хотят они ILP (instruction level parallelism). Для CISC, похоже, это единственный вариант. Насчет RISC - трудно сказать.
Для интелообразных это значит несколько конвейеров длиной минимум 20 шагов каждый, плюс по несколько исполнительных устройств.
Где-то даже проскакивала мысль, что главный плюс "внеочередного выполнения" - это нахождение операндов, которые все еще
отсутствуют в регистрах, для их заблаговременного считывания (извините, линк не помню).

Навскидку - для мультяидерности выглядит выгоднее стек. Для ILP - у суперскаляра out-of-order и предикторы разные, для стека - разве что VLIW. А в сумме что?
Придется, наверно, вспомнить всенародно известные "мелочи", и баланс подбивать - стек против суперскаляра.

P.S. А квантовые компьютеры - это неактульно. Они где-то в будущем. А живем мы в настоящем;). Но главная причина другая: если б это было технически возможно сейчас, то Интел и/или АМД с их деньгами эти супер- гипер- уже бы выпускали. Гиганты частоты любят;)

P.P.S. Представляете себе 80186 на кварковой тяге? Страшно? "..та ото ж бо й воно.."

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

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

пардон, только заметил.
не знаю есть ли 8(

возвращаясь к теме обсуждения.
Форт код линеен, то есть в нем нет места для ловли "мелкого" параллелизма, хотя бы уже потому, что он очень близок к минимальному процессору или самому простому процессору.
Проще говоря, о каком распараллеливании может идти речь на всего 2х регистрах!
Только явный паралелизм может быть, то есть еще одно вычислительное ядро.
зато, на сколько оно получается проще!:
- не нужен КЭШ данных, так как его роль прекрасно выполняет стек,
- не особо нужен кэш команд, так как программы достаточно компактные (маленький размер команд)
- не нужно сложных конвееров, и всяких слишком мудрых распараллеливателей кода
- не нужно солжных компиляторов
- не нужно сложных систем охлаждения ))

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

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



Мда..

ну, во-первых, ФМ (форт-машина) не столь простые команды имеет на самом деле. И шитый код тут вообще никаким боком, точнее не так, ШК - это не уровень ФМ, а уровень ее симуляции, так что тут мимо.


это бред, уж извините за прямолинейность. Чем больше размер кода, тем выше трафик по шине команд\данных, тем медленнее работает проц.
Так как все сейчас борются за скорость исполнения, ни в коем случае нельзя сказать, что это никого не волнует. Так как сколько я помню историю PC память всегда была самым узким местом.


опять ничего не понятно. О каком следующем уровне речь.
А кэширование данных получается достаточно эффектнивное.