Откуда идет эта модель вычислений?

А должно быть все асинхронно.

Кому должно? Код это не просто последовательность вызовов, это расчёты, изменения значений переменных, возврат данных. Ты попробуй асинхронщину дебажить и разбираться, какой поток значение переменной изменил и когда.

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

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

На каждый момент исполнения не надо держать. Обобщение рулит. Ваще то, каждому свое наверное.

расскажи как ты будешь решать самую простую задачу (возьмем, например квадратное уравнение) в асинхронном режиме.

Поверим, что ТС искренен. Хотя трудно. Истоки CS начинались с выполнения громоздких расчетов, которые мог делать и человек, записывая промежуточные результаты на бумагу. Соответственно первые языки отражали именно этот подход.

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

Но и сегодня «асинхронщина» покрывает(ну или более осторожно является лучшей) не всё.

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

промежуточные результаты на бумагу.

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

Когда instruction2 не зависит от результатов instruction1 - можно параллельно выполнить, да. Но, где-то в дальнейшем, может возникнуть ситуация, когда нужны результаты instruction1, instruction2 сразу.

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

Может возникнуть точка синхронизации. На практике это решается обычно таймаутами или реализацией паттерна «наблюдатель»

В простейшем случае асинхронное поведение наиболее ярко выражено в AJAX-запросах. Отправляется запрос и вешается обработчик на него - никто ничего не ждет, когда сработает, тогда и будет реакция. Если будет превышено время ожидания или сервер вернет ошибку, ничего страшного не произойдет в общем.

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

когда прогер пишет код, он должен головой думать

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

На одну бумагу сразу много секретуток же могут писать.

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

Да не буду я ничо тебе доказывать, у меня бошка трещит. Дело твое, не веришь, не надо. Это на интуитивном уровне надо прочувствовать. А у меня сомнений нет в своей правоте. Буду пилить ЯП и технологии в этом направлении.

Это все банальщина, все разруливается. Я не сказал, что они одновременно будут писать, я сказал, что считать одновременно будут, а писать по очереди. No problem. Все как IRL

но тут её внезапно вызвал начальник

В нее не заложено такое поведение. Она за раз будет выполнять одно действие. Если поступает вызов начальника, она все равно допишет. Надуманная тоже проблема. Не надо усложнять.

Не знаю, ща голова не соображает, я с бодуна

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

а ты часто квадратные уравнения в реальных приложениях решаешь?

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

http://play.golang.org/p/Y1IkrpXBR_ Не? ;)

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

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

Use Go, Luke!

depricated и considered harmfull.
depricated
harmfull

Садись, два.

Ты ищешь Dataflow programming

Я вообще не понимаю, откуда это все взялось-повелось, идиоты сидели у истоков CS, очевидно.

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

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

См. хаскель, в нём порядок выполнения кода явно не задан.

Что значит, явно не задан? На уровне реализации, или как? Instruction2 начнет выполняться не дожидаясь завершения instruction1? В этом ващем LC все наоборот заточено под строгий порядок

/x/y->xy

В хаскеле код вида instruction1; instruction2; может оказаться только внутри формы do, которая по сути — синтаксический сахар для определённой формы композиции функций. А как считаются остальные функции — на усмотрение реализации, в т.ч. параллельно.

Авторитетные эксперты не слышала ни о {систолических,dataflow} архитектурах, ни о VHDL-подобных языках. Окай.

В хаскеле и прочем фп, аналогом instruction1; instruction2; будет

instruction2(instruction1)

Их есть у меня парочку.

-module(asynchro_kvur).
-export([start/1]).

start({0, _, _}) ->
  io:format("читай книжки, умник~n", []);

start({A, B, C}) ->
  spawn(fun () ->
    F = fun(D) when D < 0 ->
      io:format("корней иванович чуковский нет~n");
        (0) ->
      io:format("x = ~w~n", [-B/2/A]);
        (D) ->
      io:format("x1 = ~w, x2 = ~w~n", [(-B-math:sqrt(D))/2/A, (-B+math:sqrt(D))/2/A])
        end,
    F(-B*B -4*A*C)
  end).

пока не исполнится instruction1; instruction2; не начнет выполнятся, обычно так, по-дефолту. А должно быть все асинхронно

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

Это просто потому, что так все привыкли, это уже в мозгах засело.

асинхронность и event-driven программирование лежат в сердце Tcl

А добавь больше ада^W^Wеще асинхронное вычисление B*B-4*A*C.

Да тикль вообще, имхо, лучший яп во всех отношениях. Жаль что широкого применения не нашел. Остался уделом маргиналов, по-большому счету, к сожалению.

потому что процессор исполняет инструкции последовательно (в общем случае, по крайней мере на уровне абстрактной модели, там где можно параллельно, делают параллельно)

Процессоров то может быть сколько угодно много.

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

Потому что часто приходится знать результат от instruction1; чтобы выполнить instruction2; или instruction3;

Это смотря какой алгоритм, блин.

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

Немного практики, и осознание, что тесты и дебаггер — основные инструменты разработки, а не побочные, придет. Надо только чуть-чуть пописать что-то больше хеловорлда и пережить парочку глобальных рефакторингов, тут то оно и случится.

Кстати за cps style слыхал?

-module(mm).
-export([start/1]).

start({0, _, _}) ->
  io:format("читай книжки, умник~n", []);

start({A, B, C}) ->
  spawn(fun () ->
    apply (fun(D) when D < 0 ->
      io:format("корней иванович чуковский нет~n");
        (0) ->
      io:format("x = ~w~n", [-B/2/A]);
        (D) ->
      io:format("x1 = ~w, x2 = ~w~n", [(-B-math:sqrt(D))/2/A, (-B+math:sqrt(D))/2/A])
        end,
          [
            begin
              Parent = self(),
              Parent2 = spawn (fun() ->
                receive
                  AC4 ->
                    Parent ! B*B -AC4
                end end),
              spawn (fun() ->
                Parent2 ! 4*A*C end),
              receive
                Det ->
                  Det
              end
            end])
  end).

правда они всё равно последовательно работают. Что бы ъ-асинхронно, надо что-то вроде рекурсивных лямбд, но это перебор уже ящитаю)

Что бы ъ-асинхронно, надо что-то вроде рекурсивных лямбд, но это перебор уже ящитаю)

В этом топике нужно больше асинхронного ада.

Ты либо вместе в anonimous одну траву жрешь? У вас обоих упоротые темы с проблемами высосанными из пальца. А вообще, если так любишь асинхронщину, то дорога тебе в Erlang. Там все намного асинхронней чем js.

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

Благое дело что много ЯП (Scala, Rust, Go, Haskell) умеют описывать цепочки асинронных вычислений как линейный код - специальные монады, го-рутины. Ты ничего не изобрел

Вот, опохмелись: http://brikis98.blogspot.ru/2014/04/six-programming-paradigms-that-will.html

А на Оккаме это было бы как-то так:

PROC solve(CHAN OF float ch_a, ch_b, ch_c, ch_x1, ch_x2)
    FLOAT a, b, c, d
    SEQ
        PAR
            ch_a ? a
            ch_b ? b
            ch_c ? c
        PAR
             t1 := b*b
             t2 := 4*a*c
        d := t1-t2
        PAR
             ch_x1 ! (-b + sqrt(d))/(2*a)
             ch_x2 ! (-b - sqrt(d))/(2*a)

моя твоя не понимать.

а с присваиванием t2 это опечатка или синтаксис такой?

Думаю на vhdl код получилось бы ещё асинхронее )

а с присваиванием t2 это опечатка или синтаксис такой?

Исправленная опечатка.

Думаю на vhdl код получилось бы ещё асинхронее )

Наверное. И еще отвратительнее, чем на Erlang %)

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

Даже в Эрланге, с его паралеллизмом на всю голову, последовательные вычисления решили оставить.

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