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

А это не важно, они ничем не помогут даже при отсутствии расходов на синхронизацию. man закон Амдала, в общем

Ты не виртуал anonimous?

Ты чо охренел? это только при последовательном алгоритме. типа факториала.

Садись, два. Это для любого алгоритма с какой-то долей вычислений, которые возможно распараллелить. Если их параллелится 95%, ускорение можно получить всего лишь в 20 раз, а большинство вычислений так хорошо не параллелятся.

большинство вычислений так хорошо не параллелятся.

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

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

Ты все-таки абсолютно и неизлечимо ебанутый.

О! Ты почти изобрел эрланг (который скоро отметит тридцатилетие). А еще порядок вычислений приведенный тобой напоминает пролог, которому больше 40 лет и из которого отпочковался эрланг.

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

Сейчас появился еще Go, более низкоуровневый (чем эрланг), но вместе с этим более шустрый за счет статики и возможности компиляции.

Просто этот упорыш еще не открыл для себя Excel.

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

Блядь, да ты совсем идиот. Выпей в следующий раз метанола, что ли.

Сдрисни отсюда, школьник. Excel как раз пример dataflow программирования. Если у тебя анальные страдания от excel, замени на cells или org-mode.

Интересно, какие кирпичи отложит это тупое ничтожество, когда про ОоО узнает.

Не,нормальные пацаны в такое мараться не будут. Спалился ты, программист эксель.

ОоО

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

Ну точно, школьник. Иди учить уроки, жалкий сопляк.

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

Не должно. Проблема номер один: общая переменная (man семафоры, потоки и т.д.). Проблема номер два: instruction2 ожидает получения значения из instruction1, а instruction1 ожидает значения из instruction2. Проблема номер три: непредсказуемое поведение (недетерминированность) всего процесса выполнения -> сложно предсказать точное поведение программы -> сложно отлаживать -> сложно проектировать систему с учетом всех возможных вариаций.

асинхронщина щас рулит

Асинхронщина в нынешнем виде не решает фундаментальных проблем на уровне железа. Все, что делает ПК (x86/x86_64) делается практически последовательно. Проблема не столько в том, что процессор не может выполнять множество инструкций, сколько в том, что работа с памятью накладывает 100500 ограничений. Что можно, то параллелится на уровне ОС/железа.

Вникай в суть и ты узнаешь сколько костылей сделано вокруг асинхронщины.

P.S. Платиновые треды ЛОРа.

Тупое, грязное школоло не может распарсить Out-of-Order? Небось и про алгоритм Томасуло не слышало, ничтожество?

Советую посмотреть на lisp, forth, smalltalk, prolog, erlang, haskell и по желанию на всякие ML, agda, epigram, idris, coq.

Там ты найдешь то что уже придумал, то что придумаешь и то до чего никогда не додумаешься.

Я подозреваю, что это опенофис. Ты чо оффисный планктон? Чо ты в девелопменте со своими секретарскими замашками делаешь? То ексель у тебя, то опенофис. Тут люди за прораммирование трут, епт.

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

На весь лисп смотреть не надо, досаточно посмотреть на Cells.

Erlang и Go вполне себе разруливают.

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

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

Тут еще phill есть, явно вместе с этими двумя ширяется.

Томасуло наше усе. Его как лучше спереди пользовать, или сзади, нетрадиционным путем?

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

Erlang и Go вполне себе разруливают.

А я говорил, что что-то где-то не разруливает? Вообще, оба они (на сколько известно) базируется на (lib)pthread. Внутри этой либы столько всего... :)

Еще не выпил метанола, школоло? Поспеши! А этот Томасуло в твоем CPU работает, упорыш ты грязный. Инструкции выполняются асинхронно и в произвольном порядке, все как ТС хотел.

Pthread? В ебланге? Ну и ебанут же ты!

В моем это в каком? IBM 360/91? Как ты угодал то?

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

Да кому какое дело до их реализации.

Мало ли. Может ТС ищет истинных знаний. А не мифических идей о том, что все это реализовано где-то, ну чуть ли не идеально. И вот никто, кроме них, не додумался до этого! Это же вранье чистой воды.

Что касается ерланга + pthread. Насколько мне известно последние версии (ну лет так 2-3 назад уже) эрланг позволяет использовать все ядра за счет обычных потоков. Внутри каждого потока находятся эрланго-рутины. Т.е. это гибрид. Отсюда и pthread, или они осилили сделать свою независимую реализацию потоков? Может кто адекватно напомнит/расскажет? Или там процессы + shm/sockets?

В эрланге процессы, использовать он может хоть 20 ядер и все раскидывается по ним автоматом, с выделением каждому процессу пропорционального времени (а их можно создавать хоть миллионами). Конкретная реализация малоинтересна, но я как то размышлял над этим и в голову пришла такая мысль: можно представить как функцию с состоянием. И эрланг тупо накапливает вызовы функций раскидывая их по ядрам. И все, никакой магии.

В эрланге процессы

А синхронизация данных через что? В любом случае, даже если там не phtread проблемы с синхронизации данных между процессами как были, так и остались. И узкое место в том, что чем больше используется межпроцессорной синхронизации, тем более это похоже на потоки (со всеми вытикающими) и преимущества легковесных потоков сходят на нет. Это ботлнек для любого ПО. Хоть на Go, хоть на Erlang, хоть на плюсах.

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

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

Спасибо за информацию. Я надеялся на чудо, чтобы уползти с перла :) А так, везде все тоже самое и горстка спецов может что-то менять раз в десятилетия... эх.

Из википедии

Серверное ПО WhatsApp написано на Erlang; в январе 2012 года серверы WhatsApp использовали ОС FreeBSD, в них было установлено по 96 ГБ оперативной памяти, и каждый мог обрабатывать от 1 до 2,8 млн соединений, что на несколько порядков выше классической проблемы C10k.

Если это не чудо, то я не знаю :)

Если это не чудо, то я не знаю :)

Не знаю правда или нет:

http://mrotaru.wordpress.com/category/c10m/

Как видно все зависит от детали задачи :)

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

We used ten servers Dell PowerEdge SC1435 having 16 GB RAM and 2 dual-core AMD Opteron CPU @2.0 GHz to run ten instances of MigratoryData Client Benchmark. Hence, from each client machine we opened 1.2 million sockets.

Так оно даже и не дотягивает.

Не знаю, вот их сайт: http://migratorydata.com/

пока instruction1 не завешится, instruction2 не отработает

> head (repeat 1)
1

Посмотрел на цены:

MigratoryData Small Instance Maximum Concurrent Connections = 5000 Maximum Concurrent Subjects = 5000 Ежегодная абонентская плата = 2000 Евро

MigratoryData Large Instance Maximum Concurrent Connections = 25000 Maximum Concurrent Subjects = 25000 Ежегодная абонентская плата = 8000 Евро

А теперь давай ты подсчитаешь сколько будет стоить один сервер с 1.2 миллонами коннектов. А после мы сравним больше это или меньше чем бесплатный эрланг.

Да не буду я ничо тебе доказывать, кококо

угу. защитан

А после мы сравним больше это или меньше чем бесплатный эрланг.

Эээ.. Такой же бесплатный как линукс-сервер. Линукс бесплатен до тех пор, пока за его настройку, поддержку не отстегиваешь денежку сис.админу. Не надо сравнивать готовое решение с инструментом. Тут логично сравнить эрланг с сишарп/го/плюсы.

А на том платном написание нужного софта включено в прайс?

А на том платном написание нужного софта включено в прайс?

О чем спор? О том, что эрланг позволяет бесплатно писать программы туеве туче программеров, которых продали за 17 миллиардов?

Я дал пример, что даже на яве, якобы тормозной и слишком много жрущей памяти, можно делать аналогичные решения. И эрланг это не язык богов :P

avtoritetniy-expert ты серьёзно? Не знал, что можно настолько не понимать алгоритмы. Кстати, все нормальные ЯП уже сто лет в обед имеют поддержку многопоточности и можно даже на GPU считать на 100500 ядрах или даже на нескольких компах, объединённых в сеть. Одна проблема - далеко не все задачи можно делать параллельно, соответственно для них нельзя составить распараллеленный алгоритм. Ну и надо помнить, что GPU легко считает простые вещи, где 100500 потоков одновременно, каждый поток при этом медленно выполняется, но их очень много (на моей видяшке их 960), отчего и производительность будет выше (при условии одновременной нагрузки на достаточное количество ядер GPU), чем при решении такой же задачи на CPU. Но в случае тех же 8 потоков их лучше на CPU считать (т.к. они там будут быстро выполняться каждый). Тонкости того, как считать и как синхронизировать потоки оставлю в стороне, не в этом суть.

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

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

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

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

Ты не поверишь, но и в пыщ-пыщ-вебе чаще всего это математика так или иначе. Если конечно это пыщ-пыщ-веб, а не просто пыщ-пыщ.

ну если instruction2 зависит от данных, получаемых при работе instruction1, то никакой «асинхронщины» тут получить не получится, как не крути. Это у вас мозг затуманен, когда отойдете, подышите воздухом, погуляете, пробежку сделаете, тогда вообще не вспомните, что вас так до самого сердца проняло.