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

G>Ты мало слишком писал на Эрланге, чтобы представлять себе этот толк. Никаких проблем выразить простейшие параллельные задачи, которыми и являются числодробилки, в модели Эрланга нет. Модель Эрланга может быть перенесена в любой язык. В том числе и в С++.
Некоторые примтивы сложно перенести, типа неизменяемой кучи (для soft realtime GC). Ну и прерываемость тоже...

У меня есть персистентное желание сделать что-то типа Erlang'а, портировав Скалу под LLVM. Времени сейчас нет поглубже заняться только...

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

G>У меня получилось. Мой планироващик отрабатывает за O(1), независимо от количества задач. Так же, как планировщик в современной венде или Linux.

Тебе же недоступна вся та информация, которой располагает ОС, так? Например, сотни твоих потоков ждут чего-то от ввода-вывода, откуда ты знаешь, кому давать квант? Разве что все вызовы АПИ оборачивать своими наворотами и плодить лишние примитивы синхронизации.

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

G>А вообще, нет проблем сделать и планировщик с жестким рилтаймом. Алгоритмы гибридных планировщиков, обеспечивающих хард рилтайм описывались еще в книге по оперсистемам Цикридзиса-Бернстайна. Другое дело, что в случае файберов жесткие гарантии обеспечить тяжело — не охота их насильственно прерывать. Хотя — и это можно.

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

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

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

G>>Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.

AVK>Суть, к сожалению, все таки несколько меняется, и проблемы при HPC и работе с IO все таки несколько разные, особенно в плане акцентов. К примеру, грануляризация для IO почти по барабану, а для HPC — ключевой момент.

Мы видимо о том же говорим разными словами.

G>>Axum в этом не помощник, он как раз старается грузить минимум.
AVK>Думаю, ты ошибаешься все же.
Я вроде посмотрел все материалы по Axum, которые нашел. Не увидел способов задействовать все доступные ядра для вычислений. С PFX это жедается автоматически.

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

G>>>Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях.

E>>Даже в области серверных приложений с требованиями 24x7 подход Erlang-а далеко не единственный.

G>Единственных подходов вообще не бывает. Их всегда пруд пруди. Я тебе сейчас не о подходе говорю, а о тех преимуществах, которые есть не подход, а свойства, и которые ты попытался отмести предыдущим постом.

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

E>>Которые будут использовать 8-16 имеющихся в их распоряжении ядер даже для простейшей обработки 20-30 мегапиксельных фотографий. Какой толк от Erlang-а во внутренностях IrfanView (с горячей заменой кода, немутабельных данных, сопоставлении с образцом и принципом let it fail) я не представляю. В отличии от использования data-flow механизмов на агентах типа Axum-овских.

G>Ты мало слишком писал на Эрланге, чтобы представлять себе этот толк. Никаких проблем выразить простейшие параллельные задачи, которыми и являются числодробилки, в модели Эрланга нет. Модель Эрланга может быть перенесена в любой язык. В том числе и в С++.

Здесь есть два вопроса: "можно ли?" и "нужно ли?". И прежде чем обсуждать вопрос возможности переноса свойств Erlang-а в другие языки, имеет смысл дать ответ на вопрос "нужно ли?" Так вот, для многих предметных областей не требуется ни возможностей дробления задачи на сотни тысяч изолированных мелких процессов, ни горячая замена кода, ни даже обеспечение приципа let it fail. Поэтому в этом случае вообще бессмыслено обсуждать вопросы возможности переноса свойств Erlang-а куда-нибудь.

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

G>>>Данная "декларативность" его имхо затрудняет.
G>>Данная декларативность не влияет на наблюдаемое поведение.

G>Она влияет на поведение программы.

Как?

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

E>>Вот, например, описание агента. Более-менее сложного.

V>Жень, тебе надо компилятор из некоего DSL в целевой С++ делать, а то как-то действительно "более-менее сложно" получается.

Я уже поднимал этот вопрос. И даже пытался представить, что может получиться при использовании Ruby в качестве host-языка для DSL. Вот, как тот же самый "более-менее" агент мог бы выглядеть в DSL.

Но самое удивительное для меня то, что многие заинтересованные в SObjectizer разработчики не хотят иметь внешних DSL. По разным причинам. Но категорически. Поэтому в конце-концов и возникла идея о том, как можно сделать все то же самое средствами C++.

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


G>Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке.
какая библиотека для создания агентов в net на данный момент есть?

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

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


G>>Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке.
C>какая библиотека для создания агентов в net на данный момент есть?
CCR. http://www.microsoft.com/ccrdss/

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


G>Я вроде посмотрел все материалы по Axum, которые нашел. Не увидел способов задействовать все доступные ядра для вычислений. С PFX это жедается автоматически.
каким образом это достигается в PFX?

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

G>CCR. http://www.microsoft.com/ccrdss/
агента покажешь на ней или отправишь к dss?

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

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

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


G>>>Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке.
C>>какая библиотека для создания агентов в net на данный момент есть?

вот на F# пример пинг-понга, вполне себе агентный:

#light

type Message = Finished | Msg of int * Message MailboxProcessor

let ping iters (outbox : Message MailboxProcessor) =
    MailboxProcessor.Start(fun inbox -> 
        let rec loop n = async { 
            match n with
            | 0 -> outbox.Post Finished
                   printfn "ping finished"
                   return ()
            | _ -> outbox.Post <| Msg(n, inbox)
                   let! msg = inbox.Receive()
                   printfn "ping received pong"
                   return! loop(n-1)}
        loop iters)
            
let pong() =
    MailboxProcessor.Start(fun inbox -> 
        let rec loop () = async { 
            let! msg = inbox.Receive()
            match msg with
            | Finished -> 
                printfn "pong finished"
                return ()
            | Msg(n, outbox) -> 
                printfn "pong received ping"
                outbox.Post <| Msg(n, inbox)
                return! loop() }
                    
        loop())

ping 100 <| pong() |> ignore
System.Console.ReadLine() |> ignore

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

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


G>>Я вроде посмотрел все материалы по Axum, которые нашел. Не увидел способов задействовать все доступные ядра для вычислений. С PFX это жедается автоматически.
C>каким образом это достигается в PFX?
В PFX парллелизм строится на задачах, выполнение которых раскидывается на все доступные ядра.

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


G>В PFX парллелизм строится на задачах, выполнение которых раскидывается на все доступные ядра.
кто их раскидывает, в PFX свой шедулер?

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

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

G>>CCR. http://www.microsoft.com/ccrdss/
C>агента покажешь на ней или отправишь к dss?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Ccr.Core;

namespace Agent
{
    public class AdderAgent
    {
        DispatcherQueue _queue;
        public Port<int> X { get; private set; }
        public Port<int> Y { get; private set; }

        public Port<int> Result { get; private set; }

        public AdderAgent(DispatcherQueue queue)
        {
            _queue = queue;
            X = new Port<int>();
            Y = new Port<int>();
            Result = new Port<int>();

            Arbiter.Activate(_queue, Arbiter.JoinedReceive(true, X, Y, (x, y) => Result.Post(x + y)));
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            using (Dispatcher dispatcher = new Dispatcher())
            {
                DispatcherQueue queue = new DispatcherQueue("queue", dispatcher);

                var agent = new AdderAgent(queue);

                agent.X.Post(1);
                agent.Y.Post(2);

                Arbiter.ExecuteToCompletion(queue, agent.Result.Receive(x => Console.WriteLine(x)));                
                Console.ReadLine();
            }
        }
    }
}

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

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

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


G>>В PFX парллелизм строится на задачах, выполнение которых раскидывается на все доступные ядра.
C>кто их раскидывает, в PFX свой шедулер?
Угу. В .NET 4.0 это будет встроенная возможность.

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


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

/// <summary>
/// Base type for all service messages. Defines a response PortSet used
/// by all message types.
/// </summary>
public class ServiceOperation
{
    public PortSet<string, Exception> ResponsePort = new PortSet<string, Exception>();
}

public class Stop : ServiceOperation
{
}

public class UpdateState : ServiceOperation
{
    public string State;
}

public class GetState : ServiceOperation
{
}

/// <summary>
/// PortSet that defines which messages the services listens to
/// </summary>
public class ServicePort : PortSet<Stop, UpdateState, GetState>
{
}
/// <summary>
/// Simple example of a CCR component that uses a PortSet to abstract
/// its API for message passing
/// </summary>
public class SimpleService
{
    ServicePort _mainPort;
    DispatcherQueue _taskQueue;
    string _state;

    public static ServicePort Create(DispatcherQueue taskQueue)
    {
        var service = new SimpleService(taskQueue);
        service.Initialize();
        return service._mainPort;
    }

    private void Initialize()
    {
        // using the supplied taskQueue for scheduling, activate three
        // persisted receivers, that will run concurrently to each other,
        // one for each item type
        Arbiter.Activate(_taskQueue,
            Arbiter.Receive<UpdateState>(true, _mainPort, UpdateHandler),
            Arbiter.Receive<GetState>(true, _mainPort, GetStateHandler)
        );
    }

    private SimpleService(DispatcherQueue taskQueue)
    {
        // create PortSet instance used by external callers to post items
        _mainPort = new ServicePort();

        // cache dispatcher queue used to schedule tasks
        _taskQueue = taskQueue;
    }
    void GetStateHandler(GetState get)
    {
        if (_state == null)
        {
            // To demonstrate a failure response,
            // when state is null will post an exception
            get.ResponsePort.Post(new InvalidOperationException());
            return;
        }

        // return the state as a message on the response port
        get.ResponsePort.Post(_state);
    }
    void UpdateHandler(UpdateState update)
    {
        // update state from field in the message
        _state = update.State;

        // as success result, post the state itself
        update.ResponsePort.Post(_state);
    }
}

G>Хотя не знаю насколько оправдано создание таких агентов без DSS.
+1 прада он за собой много чего тащит, и банально не удобен. Жду Dublin

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

E>Я уже поднимал этот вопрос. И даже пытался представить, что может получиться при использовании Ruby в качестве host-языка для DSL. Вот, как тот же самый "более-менее" агент мог бы выглядеть в DSL.

E>Но самое удивительное для меня то, что многие заинтересованные в SObjectizer разработчики не хотят иметь внешних DSL. По разным причинам. Но категорически.

Странно, а как же народ пользуется IDL, всякими ASN.1, да и просто, не побоюсь этого слова, XML-based DSL? Декларативные вещи на декларативном DSL должны быть написаны, ИМХО.

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

agent a_channel_t 
    // extends 
    = so_sysconf_2::agent_with_fatal_state_t;
  
    // messages:
    -> imit_deliver (count:UINT sequence_number:UINT protocol_id:UCHAR) <own checker>
    -> imitation_mode (submit_sm_resp_command_status:UINT message_id:STRING) <own checker>
    -> send <own_mbapi>

    // states and handlers
    * closed (start                   start)
             (client_connected        client_connected)
             (client_disconnected     UNEXPECTED)
    
    * imitation_mode (start|client_connected|connect_fail UNEXPECTED)
                     (:default IGNORE)

Раза в 3 меньше писанины, если еще и префиксы для идентификаторов С++ напр. "msg_", "m_", "evt_" подать как аргумент командной строки генератора.

И сдается мне, что написать компилятор подобного "тупого" DSL на Ruby попроще будет, чем подготовить на нем же встроенный DSL. Даже если заказчики против, подобный тул сэкономит время на старте проекта, когда надо "накидать" кучу агентов. Еще поинт в том, что "сочные" описания — документация сама по себе.

И кстати, не факт, что заполнять таблицу по столбцам удобнее, повторяющиеся обработчики скорее будут для одного сообщения, поэтому может оказаться удобным после объявления сообщения тут же указать обработчиков (в духе описанного выше):

-> msg1 (args) <flags>
   state1|state2|state3 => handler1
   state4 => handler2
   :default => IGNORE

E>Поэтому в конце-концов и возникла идея о том, как можно сделать все то же самое средствами C++.

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

T>>>>2) Использовать агенты в HPC — немного совсем малоэффективное решение.
E>>>Агенты в HPC вполне могут заменить старый добрый MPI более современными решениями.
T>>А чем они от него отличаются-то?

E>Если речь об Axum, то там, насколько я могу судить, на уровне языка декларируются контракты между агентами.

Проблемы уровня библиотеки в нормальном языке.

E>Тогда как в MPI сборкой/разборкой сообщений программист занимается вручную. Соответственно, в MPI накосячить гораздо проще и косяки эти будут вылезать в run-time.

http://www.pgroup.com/products/workindex.htm

T>>Уверен насчёт Scheme?
MC>В том, что для нее реализован матчинг? Было бы странно, если бы это было не так, ибо макросы рулят.

Я про изменяемость значений.

Вот пример кода:

f x = h x (g x)

Каким образом в Схеме могут изменить значение, связанное с x в функции g? Не саму "переменную" x, а значение, которое мы передадим в h.