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

V>>Технология generics в .Net позволит при надобности построить полностью типизированные узлы в рантайм, но у меня оччень большие сомнения в необходимости этого (обрати внимание на вывод типа узлов верхнего уровня — мрак).

EC>А можно о выделенном чуть поподробнее?

Я имел ввиду, что сейчас AST обычно оперируют базовыми классами, что-то вроде такого:

class Expr {}

class BinExpr : Expr { 
  public Expr Left {get; } 
  public Expr Right { get; } 
}

В то время как можно и так:

class Expr {}

class BinExpr<TLeft, TRight> : Expr 
  where TLeft : Expr 
  where TRIght: Expr 
{ 
  public TLeft Left {get; } 
  public TRIght Right { get; } 
}

Я подобную технику применял для динамических вычислителей по вводимым юзверем формулам. Сначала строил AST как в первом варианте (код формирования AST в процессе разбора проще для первого варианта), а затем упрощал/трансформировал выражение, порождая результат в виде второго варианта, который к тому же был сделан на value-type (это важно для генериков, иначе такая оптимизация не имеет большого смысла). Получал примерно в 4-6 раз более быстродейственную версию такого динамического вычислителя. Все эти потуги были от того, что вводимая формула натравливалась на большое кол-во данных (котировки ценных бумаг).

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

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

T>>Поверю, когда увижу.

AVK>Так официально сказано, что там слегка улучшенные ядра 486. Что может помешать?

Помешать? Подсистема памяти, шедулер потоков и заданий, и исполнительный конвейр в шейдерных процессорах весьма специально устроены. Ну очень нетрадиционно. Обычный аппаратный мультитред проиграет им по отдаче производительности с миллиметра кристалла. И модель выполнения там отличается от обычной — шейдерные программы относительно короткие, и работают пачками на разных данных, подо что и оптимизируется архитектура. Вот такого:

"алгоритм любой сложности, написанный на С/С++ можно будет сгрузить на GPU."

вряд-ли стоит ожидать. Три раза "ха".

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

R>На днях NVidia анонсировала новый процессор T10P для высокопроизводительных вычислений и новую модель 1U сервера Tesla S1070.

R>http://www.ddj.com/hpc-high-performance-computing/208404203?cid=RSSfeed_DDJ_All
R>http://www.nvidia.com/object/tesla_s1070.html

И вот что на основе этих Tesla собрали: http://www.ddj.com/hpc-high-performance-computing/216500117?cid=RSSfeed_DDJ_All

V>Кстати, наткнулся у тебя в блогах на твои эксперименты с примитивными комбинаторами разбора. И там ты сам же и замечал, что даже на небольших входных цепочках у тебя быстро заканчивается память. Собственно, на твоём комбинаторе выбора и идёт раздвоение параллелизма. Но ситуация всё-равно плохо понятна в случае Хаскеля, он же ленивый.

Приводи ссылку.

А то я такого не помню.

Здравствуйте, vdimas, Вы писали:
V>Я подобную технику применял для динамических вычислителей по вводимым юзверем формулам. Сначала строил AST как в первом варианте (код формирования AST в процессе разбора проще для первого варианта), а затем упрощал/трансформировал выражение, порождая результат в виде второго варианта, который к тому же был сделан на value-type (это важно для генериков, иначе такая оптимизация не имеет большого смысла). Получал примерно в 4-6 раз более быстродейственную версию такого динамического вычислителя.
Пардон, а почему не сделать Expr.Compile? Тогда-то наверное вообще в 40-60 раз быстрее выйдет, нет?

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

S>Пардон, а почему не сделать Expr.Compile? Тогда-то наверное вообще в 40-60 раз быстрее выйдет, нет?

Нет, раза в полтора максимум получалось по отношению к вычислителю на структурах в лучшем случае, там же сплошной инлайн идёт, вот примерный код вычислителей:

struct PlusInt32<TLeft, TRight> :IEval<int> 
  where TLeft:IEval<int> 
  where TRight:IEval<int> {
...
  public int Eval() { return _left.Eval() + _right.Eval(); }
}

struct Const<T> : IEval<T> {
...
  public T Eval() { return _value; }
}

struct Int32Field : IEval<int> {
...
  public int Eval() { return _reader.ReadInt32(_index); }
}

Последний вычислитель и есть бутылочное голышко, которое делает ненужным дальнейшую оптимизацию (отрабатывает раз в 20-30 медленнее первых двух при первом обращении к полю в этой же строке, и примерно в 5 раз при последующих) — вычисления происходили практически со скоростью выборки данных. Опять же, апп-сервер потенциально работает очень долго без перезагрузок, и бесконечно набивать память сборками как бы спорно, да и ручной эмит сложен малость (ту разницу получил на экспериментах на простейших операциях +-*/) , и было это за пару лет до VS2008.

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

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

S>>Пардон, а почему не сделать Expr.Compile? Тогда-то наверное вообще в 40-60 раз быстрее выйдет, нет?

V>Опять же, апп-сервер потенциально работает очень долго без перезагрузок, и бесконечно набивать память сборками как бы спорно, да и ручной эмит сложен малость (ту разницу получил на экспериментах на простейших операциях +-*/) , и было это за пару лет до VS2008.

Expression.Compile() работает через DynamicMethod

MSDN:

You can use the DynamicMethod class to generate and execute a method at run time, without having to generate a dynamic assembly and a dynamic type to contain the method. The executable code created by the just-in-time (JIT) compiler is reclaimed when the DynamicMethod object is reclaimed. Dynamic methods are the most efficient way to generate and execute small amounts of code.

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

G>Expression.Compile() работает через DynamicMethod

Еще раз для непонятливых, это было сделано за пару лет до DynamicMethod.

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

V>Еще раз для непонятливых, это было сделано за пару лет до DynamicMethod.

Ну я тоже из непонятливых. DynamicMethod появился одновременно с дженериками.

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


K>Ну я тоже из непонятливых. DynamicMethod появился одновременно с дженериками.

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

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

R>> (2) за счёт повышения тактовой частоты в ближайшую декаду сещественного роста не предвидится

AVK>Я бы не был так уверен в этом. Текущая ситуация с частотами в основном обусловлена маркетинговыми моментами. ... Однако при этом известно, что теперешние Penryn массово работают на 4.5ГГц с воздушным охлаждением.

Все равно про рост частоты можно забыть, такого как в предыдущие 10-20 лет не будет уже никогда.
Уже при частоте 4.5ГГц свет проходит за такт 6 см (если не ошибаюсь). Даже без технологических тонкостей, при существенно большх частотах это уже бы была скорее распределенная система. Когда за такт сигнал(свет) не успевает пройти весь кристалл, архитектура значительно усложнится. И это уже будет "не полноценная" частота условная, так сказать. сильно не синхронная работа разных кусков кристалла связанных медленными каналами.

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

S_>Все равно про рост частоты можно забыть, такого как в предыдущие 10-20 лет не будет уже никогда.
S_>Уже при частоте 4.5ГГц свет проходит за такт 6 см (если не ошибаюсь). Даже без технологических тонкостей, при существенно большх частотах это уже бы была скорее распределенная система. Когда за такт сигнал(свет) не успевает пройти весь кристалл, архитектура значительно усложнится.

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