FR,

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

Ну так я же сказал, это неединственный источник информации.

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

К>Набрёл на довольно интересный пост, спорный конечно, но основная мысль даже не вынесенная в заголовок, а в том, что архитектура фон Неймана — не единственная возможная схема, но на неё завязаны большинство современных языков программирования.
К>Но возникает вопрос — а что можно противопоставить им? Какие языки будут хорошо ложиться на архитектуру Cell?
К>(в статье приводится Erlang, насколько он подходит не берусь утверджать, а с другой стороны 1 язык это маловато)

Пока мы тут спорим о языках, производители аппаратуры рождают настоящих монстров:

http://www.ixbt.com/news/news.php?id=58202

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

AVC>>Как в ФЯ разруливается вопрос о доступе потоков к общим ресурсам (например, куче) без мьютексов или мониторов?
LCR>Синхронизация обеспечивается внутренними средствами RTS (вполне вероятно, что это могут быть системные мьютексы).

Или мониторы (если грубо определить монитор = доступ к разделяемому ресурсу + мьютекс).
Наверное, так и есть. Все как у людей.
Только одно непонятно: в чем же тогда особая 'легкость потоков', если мы как обычно пользуемся мьютексами?

LCR>Там для модифицируемых данных применяется реал-тайм менеджер памяти, а для обычных данных one-pass real-time mark-and-sweep:

LCR>

LCR>Armstrong and Virding have proposed a one-pass mark-and-sweep garbage collector [AV95]. The collector is designed for languages that prohibit destructive operations (i.e. values can not be overwritten), and is used in a Erlang implementation. Since destructive operations are not allowed, references can only refer to older objects. The collector marks the objects from the youngest to the oldest. If no other object has referred to an object that is being marked, it can be reclaimed immediately (since only younger objects can refer to it.) All objects are kept in a singly linked list to keep the objects in order. All GC operations have predictable runtime
LCR>behavior. Thus, it can be used for real-time systems if it is scheduled to guarantee memory availability.

LCR>Опять же консервативные предположения и здесь позволяют неможечко подкрутить...

Идея, что из ограничений можно извлекать большую пользу, мне близка.
Например, некоторые ограничения в синтаксисе императивного языка (хотя бы исключение goto) облегчают оптимизацию кода и повышают читабельность.
Type-safe языки могут обеспечить безопасность даже на машине без аппаратной защиты памяти.
И т.д. и т.п.
Вот и идея Армстронга и Вирдинга мне понравилась. Раз ссылки возможны только от младших к старшим, то сборка мусора, по идее, должна требовать всего лишь O(n), т.е. имеет место линейная зависимость (если я не ошибаюсь).
Но вопрос о 'цене ФЯ' остается (по крайней мере, для меня).
Локальные переменные в стеке по прежнему гораздо легче, чем объекты в любой куче, а их 'сборка' вообще не требует времени — достаточно выйти из подпрограммы.

AVC>>Обычный поток не требует специальных средств синхронизации до тех пор, пока он не обращается к разделяемым ресурсам. Например, скромно вычисляет что-то в своем стеке с помощью реентерабельных функций без побочных эффектов.
LCR>Просто чудесно. Мне только интересно, как это будет выглядеть.

LCR>1. При передаче объекта в функцию, мы должны копировать его, или
LCR>2. При передаче объекта в функцию, позволяется вызывать только немодифицирующие методы.

Например, 2.
В Си++ есть модификатор const для метода.

LCR>И получаем другую проблему, которая ставит в тупик нормальное отображение предметной области на язык. При копировании объектов рвутся ссылки, что превращает моделирование в мучение. Модифицирование состояния — это основа моделирования в императивных языках.

Именно! Изменение состояния — основа моделирования, это одна из причин, почему мне не слишком нравятся ФЯ.
Слишком неестественно отображение понятия состояние на ФЯ.
Тот же автоматный подход гораздо естественнее.

LCR>Возможно запутал, но вкратце будет так: чтобы смоделировать изменяющуюся сущность, мы отображаем эту сущность на язык (в виде объекта) и изменение этой сущности во времени моделируется с помощью изменения состояния объекта во времени. Есть альтернативный подход: изменение этой сущности во времени моделируется дискретной функцией (у которой значения меняются в зависимости от аргумента t, сама же функция является константной). Это подход ФЯ.

Вот, IMHO, пример такой неестественности.

AVC>>Для потока активного объекта поле этого объекта также является "локальной переменной".
AVC>>Ведь это поле принадлежит только активному объекту. Поэтому не требуются (за исключением особых случаев) средства синхронизации.
LCR>Если один объект вызывает метод другого объекта и этот метод возвращает значение?
LCR>

LCR>class A { public X meth(); }

LCR>class B
LCR>{
LCR>  private X x;
LCR>  public void fun(A a)
LCR>    {
LCR>        this.x = a.meth(); // здесь лок нужно захватить, а?
LCR>    }
LCR>}
LCR>

LCR>Вопрос там, в комментарии...

Скорее, лок захватывается в методе A::meth() и там же освобождается.
Т.е. используется мьютекс.
Такой мьютекс может быть объявлен как поле в классе A, превращая любой экземпляр этого класса в монитор.

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

LCR>

LCR>class A { public X meth(); }

LCR>class B
LCR>{
LCR>  private X x;
LCR>  public void fun(A a)
LCR>    {
LCR>        this.x = a.meth(); // здесь лок нужно захватить, а?
LCR>    }
LCR>}
LCR>

LCR>Вопрос там, в комментарии...

Нужно или не нужно — никого кроме самого A не касается. Поэтому смело пишите просто a.meth().
Другое дело, что реализация этого метода может быть, например, такой:

C#:

public X Meth ()
{  
  System.Monitor.Enter(this);
  try
  {
    X x = ...
    return x;
  }
  finally
  {
    System.Monitor.PulseAll(this);
    System.Monitor.Exit(this);
  }
}

то же самое на Active Oberon:

PROCEDURE Meth (): X;
  VAR x: X;
BEGIN {EXCLUSIVE}
  x := ...
  RETURN x
END Meth;

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

AVC>>Оказывается, все наоборот, и Си++ быстрее, чем Си в 6 (!) раз.
AVC>>Что, IMHO, уже кажется весьма странным.

M>Видимо, libstdc++.so собирался с NPTL-версией glibc.
M>А программы на C компилялись с помощью LinuxThreads-версией glibc

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

Здравствуйте, Lazy Cjow Rhrr

Хочется уточнить пару моментов.

AVC>>И не надо забивать голову специфическими проблемами ФЯ.

LCR>Ну да, создание копии. И никаких проблем.

Какие накладные расходы будут на создание отдельных копий данных при перемножении, например матриц 500x500?
Какие здесь вообще предполагается создавать копии?

LCR>На этой диаграммке всё видно, в частности отрыв "лёгкой" многопоточности от "тяжёлой".
LCR>(В этом тесте запускается 500 потоков, что для Эрланга — просто детский лепет — для него и 50000 по зубам, если интересно могу привести рекорд).

Когда одновременно работают 1000 потоков, какой квант времени выделается одному потоку?
Какая многопоточность (кооперативная или конкурентная)? Что происходит, если один или несколько потоков начинают выполнять длительную операцию?

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

LCR>FR,

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

LCR>Ну так я же сказал, это неединственный источник информации.

Это источник дезынформации.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

E>Какая многопоточность (кооперативная или конкурентная)?

Хотел написать кооперативная или вытесняющая.

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

ГВ>>Притом рассуждает иной раз так, что мама, не горюй. Как архитектура Cell принципиально противоречит фон Нейману?
К>Если говорить строго — да, не противоречит (как ты вообще себе что-либо противоречащее фон Неймановской модели представляешь?), но это не машина фоннеймоновской модели, где есть процессор, память и операции выполняются строго последовательно

Если не противоречит, то почему "не машина фоннеймоновской модели"? Просто у нас появляется много машин фон Неймана в одном флаконе с теми или иными особенностями межпроцессного обмена и своей спецификой процессора.

ГВ>>Или в более общем смысле — машине Тьюринга? Там что, процессор процессором не является? Или память — это не память?
К>AFAIK, основное отличие от x86 — в явном прицеле на параллельные вычисления и развитые коммуникации.
К>(выделено мной)
К>Видимо ты не улавливаешь мысли, которую уже твердят давно и на RSDN в том числе, что стандартные языки (аля C и т.п.) не дают удобных концепций для описания свободно распараллеливаемых алгоритмов. Часто ФЯ упоминаются, но там далеко не всё так гладко как хотелось бы

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

ГВ>>Так что, вопрос о языках для Cell, это вопрос о языках с поддержкой параллелизма, а никакой не contra-von Neuman. Кстати, "в лоб" параллелизм можно и на обычном C поддержать. Набор инструкций, это что? Правильно, это — процедура.
К>...
К>Много чего можно, можно и на ассемблере GUI-приложения писать и ещё много чего. Вопрос — насколько просто и удобно

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

Собственно, "новопарадигматологи" как раз и бодаются вокруг того, чтобы сохранить язык по возможности последовательным, а программу при том сделать распараллеливаемой. Поскольку автоматически это сделать нелегко (часто и невозможно), то начинается свистопляска вокруг очередной серебряной парадигматической пули и "лени" программистов. Как дети, прямо. Если 100 функций завязаны в цепочку результатами друг друга, то такую программу никакой компилятор не распараллелит при всём желании.

К>Как раз на эту тему и мысль того поста — программисты ленивы, им лень изучать новые парадигмы, языки и т.п.

Конечно, ленивы. Особенно когда вместо твёрдой алгоритмо-методической базы подсовывают обёртку "новой парадигмы". Угу, восьмой подход к снаряду, но уже в синем костюме. Серебряной пулей-с попахивает. Да-с.

К>because they like to minimize the amount of crap(Довыделено мной. — ГВ.) they have to learn. Because learning is painful
К>Я лично имею привычку бороться с ленью, но это личный выбор каждого

Лень и работоспособность бывают разными. Бывает трудоспособность, которая мешает понимать простые вещи объективной реальности.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Нужно или не нужно — никого кроме самого A не касается. Поэтому смело пишите просто a.meth().

То есть лок делается при вызове любого метода, если он находится в другом объекте?

СГ>Другое дело, что реализация этого метода может быть, например, такой:

СГ>C#:
СГ>[c#]
СГ>public X Meth ()
СГ>{
СГ> System.Monitor.Enter(this);
СГ> try
СГ> {
СГ> X x = ...
СГ> return x;
СГ> }
СГ> finally
СГ> {
СГ> System.Monitor.PulseAll(this);
СГ> System.Monitor.Exit(this);
СГ> }

очень интересно. На работе ты вот прямо так и пишешь?

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

ГВ>Конечно, ленивы. Особенно когда вместо твёрдой алгоритмо-методической базы подсовывают обёртку "новой парадигмы". Угу, восьмой подход к снаряду, но уже в синем костюме. Серебряной пулей-с попахивает. Да-с.

Где ты её конкретно увидел? Не надо с ветряными мельницами бороться, Геннадий.

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

ГВ>>Конечно, ленивы. Особенно когда вместо твёрдой алгоритмо-методической базы подсовывают обёртку "новой парадигмы". Угу, восьмой подход к снаряду, но уже в синем костюме. Серебряной пулей-с попахивает. Да-с.

К>Где ты её конкретно увидел? Не надо с ветряными мельницами бороться, Геннадий.

У меня профессиональное чутьё. Разговоров о пуле ещё нет, но я их уже чую.

Здравствуйте, Сергей Губанов, Вы писали:

Знаешь, что такое Очень Плохая Вещь?

Это вот она:

СГ>C#:
СГ>

СГ>  System.Monitor.Enter(this);
СГ>

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

ГВ>Здравствуйте, Курилка, Вы писали:

ГВ>>>Конечно, ленивы. Особенно когда вместо твёрдой алгоритмо-методической базы подсовывают обёртку "новой парадигмы". Угу, восьмой подход к снаряду, но уже в синем костюме. Серебряной пулей-с попахивает. Да-с.

К>>Где ты её конкретно увидел? Не надо с ветряными мельницами бороться, Геннадий.

ГВ>У меня профессиональное чутьё. Разговоров о пуле ещё нет, но я их уже чую.

Извини, но паранойей попахивает

AVC

LCR>>И получаем другую проблему, которая ставит в тупик нормальное отображение предметной области на язык. При копировании объектов рвутся ссылки, что превращает моделирование в мучение. Модифицирование состояния — это основа моделирования в императивных языках.

AVC>Именно! Изменение состояния — основа моделирования, это одна из причин, почему мне не слишком нравятся ФЯ. Cлишком неестественно отображение понятия состояние на ФЯ.
AVC>Тот же автоматный подход гораздо естественнее.

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

Ну а с эффективностью боремся помаленьку...

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

Геннадий Васильев,

СГ>>  System.Monitor.Enter(this);

А что не так?

Например, в джаве это нормальная практика:

sychronized public void meth() {...}

всё равно что

public void meth()
{
    synchronized(this) {...}
}

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

LCR>>Ну да, создание копии. И никаких проблем.

E>Какие накладные расходы будут на создание отдельных копий данных при перемножении, например матриц 500x500? Какие здесь вообще предполагается создавать копии?

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

Касаемо матриц. Здесь я буду говорить только про Эрланг, в других языках всё иначе.

Итак, зависит от представления. Векторы (mutable arrays) можно представлять в туплах, словаре, в ETS (Erlang Term Storage), и ещё в какой-то необычной форме (этот подход использован в HiPE), в которой я ещё не разобрался

Словарь и ETS — это модифицируемые хранилища, с ними всё понятно.

Если в туплах, то при каждой модификации элемента, весь тупл (то есть массив ссылок) копируется Это не рекомендуется делать для туплов больших размеров. Необходимость копирования тупла связана с ограничениями на риал-тайм в ГЦ. Если представлять матрицу в виде тупла туплов, то при наивном последовательном подходе 1by1 каждая строка будет скопирована n^2 раз и в результат попадёт только последняя копия. Ненаивный подход — это вычислять несколько элементов одновременно. Если например вычислять одновременно 2 элемента, то количество ненужных копий уменьшится более чем в 2 раза.

Hipe-овский подход позволяет достичь скорости ETS, при этом сохранив декларативность.

LCR>>(В этом тесте запускается 500 потоков, что для Эрланга — просто детский лепет — для него и 50000 по зубам, если интересно могу привести рекорд).

E>Когда одновременно работают 1000 потоков, какой квант времени выделается одному потоку?
E>Какая многопоточность (кооперативная или конкурентная)? Что происходит, если один или несколько потоков начинают выполнять длительную операцию?

Процессы в Эрланге квантуются в зависимости от редукций. Одна редукция это в-общем эквивалент одному вызову фукнции. Процесс выполняется пока он не тормознётся для ожидания сообщения от другого процесса или пока он не выполнит 1000 редукций (кажется, раньше было 500).

Нормальных длительных атомарных операций нет, то есть всегда можно обойтись без них. (Скажем, есть length(L) = O(n), однако всегда можно обойтись без функции length. А из "ненормальных" атомарных операций можно привести пример функции с 10000 аргументами, причём каждый аргумент меняет значение. Тогда вызов функции (редукция) будет занимать внушительное по меркам real-time время).

Есть функции для тонкой настройки квантования — yield/0, bump_reductions/1.
Процессу, ожидающему сообщение будет выделен квант, как только пришло что-то новое в очередь сообщений процесса, или как только сработал таймаут. Имеется ввиду следующий таймаут:

    receive
        Msg -> true
    after Time ->  % вот здесь
        Pid ! Alarm
    end.

Процессы могут иметь один из 4-х приоритетов (max, high, normal, low). Эрланг для мультипроцессорных систем (совсем новая версия) может использовать системные потоки, и системные приоритеты.

Многопоточность вытесняющая.

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

LCR>А что не так?

LCR>Например, в джаве это нормальная практика:

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

Lazy Cjow Rhrr wrote:
> А что не так?
> Например, в джаве это нормальная практика:
> sychronized public void meth() {...}
И используется такая фича достаточно редко, так как обычно надо
использовать монитор, отличный от самого объекта.

Дарней,

Д>значит, в жабе тоже неправильно делают. Нельзя синхронизироваться на объекте, который видно снаружи. Вот придёт кому-то в голову синхронизироваться на этом же объекте, но в другом месте и в других целях — и всё, приплыли.

Куда приплыли? Этот "другой" просто будет ждать в очереди на захват монитора. В книжках об этом предупреждают уже на второй странице, сразу после примера про synchronized.

Да конечно, потенциальный bottleneck. Но это можно сказать про любое расшаренное состояние.