Re[36]: Nemerle vs. C#. До сих пор привыкнуть не могу :) - Nemerle

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

VD>>Это чушь. На фрагментацию влияет количество перезоемов больших объектов и паттерн распределения памяти.

I>Это факты.

Факты в студию, плиз. Или не трепись по чем зря.

>>А для загрузки длл отводится соврешенно другая область памяти, которая никак не влияет на область памяти выделяемой под LOH.

I>Чудеса, да и только.

Учи матчасть.

I>Какая область памяти отводится, дело десятое. Главное что сборки жрут именно ту часть АП, которая может использоваться GC.

Области резервируются при старте дотнета. Влиять на фрагментацию они не могут.

Да и смешно говорить о влиянии на фрагментацию нескольких килобайт. Ты двумя занятыми массивами фрагментируешь LOH куда больше.

Ты хоть в значение слова "фрагментация" вдумайся. Фрагменировать можно только что-то сплошное.

I>Проверить просто — берешь консольное приложение безо всяких зависимостей и выделяешь память. Выходит около 1.6-1.9 гб в завимости от размера блока. 1.9 будет если выделять кусками по 16мб

I>Дальше просто — вгружаешь сборки и, внезапно, когда количество и разным сборок сравнимо с количеством в реальном приложении, память почемуто начинается заканчиваться на планке 1гб+200мб. Все зависит естественно от способа расходования памяти.

Вот, блин, удивительно, да? Если занять 100 мег чем-то другим, то 100 мег окажется недоступным. Только причем тут фрагментация?

Если ты даже очень постараться немерловая сборка у тебя выйдет на 100 Кб больше аналогичной на шарпе. Это 100 Кб ты в микроскоп не заметишь. У IT вырожденный случай. Вызван он убогостью шарпа и нежеланием IT переписывать этот код (так как он объемный и работает). Если бы он писал код на Немерле изначально, то его сборка была бы не больше шарповской, а меньше, так как то что он эмулирует на лямбдах и делегатах можно было бы выразить макросами генерирующими эффективный низкоуровневый код.

I>У меня >50мб исходного кода. Ты хорошо понимаешь, что это значит ?

Ну, и? Они превратятся в ~50 длл-и. Объем занимаемой ими памяти один хрен не будет определяться размером ДЛЛ-и, а будет определяться объемом хранимых в памяти данных.

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

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

Как правильно сказал НН, если бы тебя реально заботила эффективность генерируемого немерлом кода, ты примкнул бы к нам и помог проекту. За одно свой уровень поднял бы. А у тебя другая задача — срач устроить. Но это без меня.

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

F>>>>Делегат может быть быстрее.
A>>>За счет чего?
F>> За счет того, что никакого диспатчинга не происходит. Делегат — это this и массив готовых указателей на методы. Ну и их хорошенько оптимизировали в .net 2+, если память не изменяет.
A>Work — невиртуальный метод, никакого диспатчинга нет.
Function.Invoke — виртуальный. Например, имеем классы A->B->C с неким виртуальным методом apply.
Как только мы сделаем делегат на какой-то конкретный метод, конкретного типа — нас не будет волновать виртуальность метода, — банально, есть this, и есть адрес какой позвать. Махинации со стёком ещё остаются, в случае делегатов, может там чего и оптимизировали — но практика как раз показывает, что они дешевле, чем виртуальность.
Т.е., имея виртульный метод — рантайм фактически всегда обязан разобраться какой же именно метод нужно позвать (при каждом вызове). При чём в общем случае — даже sealed не способен помочь, — мы обычно как раз принимаем базовый тип на входе (некий Function) — так что от виртуальности никак не избавится. Теоретически, можно lookup нужного метода вынести за пределы цикла, но это будет работать только на циклах, и я очень сомневаюсь, что такая оптимизация производится — JIT на самом деле генерирует очень прямолинейный код (ну или так было). Именно поэтому делегаты всегда побеждают в циклах. Но... (читаем дальше)

A>А оптимизируют с каждой новой версией .Net.
A>Возможно, уже имеет смысл переходить на делегаты в компиляторе. Т.е. утверждение, что делегаты тормознее перестает быть правдой...
Оно перестало быть правдой давно. Но это всё, всё равно ерунда, — различия они минимальны. Получить 20-50% разницы на миллиарде! фактически пустых вызовов — ну действительно пофигу. Там где они не минимальны (коллекции с кастомным компаратором, например) — должен быть полноценный инлайнинг, а не какие-то там косвенные вызовы — и делегаты и виртуальные вызовы — работают одинаково плохо в таких случаях. Но этот самый полноценный инлайнинг даёт ощутимое преимущество разве, что специализированных коллекциях, и отлично пишутся на том же самом C# ручками. %) То, что в разных случаях более эффективны — разные подходы — я думаю понятно, но как только становится вопрос о взаимедействии между сборками — нам, просто необходима общая база. В случае N — это функциональный тип. В случае C# — делегаты. На самом деле подход в N к этому делу общеизвестен, прост и логичен, и как я понимаю, родился в эпоху когда не было стандартных Action/Func.
По сути в этой подветке кртикие подвергается не сам подход, а "недостаточная" оптимизация компилятора — т.е. при возможности, не генерировать класс-функтор вообще. При возможности — хорошо бы его объединять с объектом-замыканием (только, когда это возможно!). Ну ещё я бы отметил, отсутствие кеширование делегата, по тем же правилам как и у C#. Но, без этого жить наверное можно.
А качество кодогенератора — да — надо улучшать. Откровенно лишние слоты в методах, излишние stloc/ldloc, когда всё должно быть совершенно просто на стёке. От этого тоже растёт объем сборки кстати, и опять таки — не факт, что это JIT способен эффективно выбросить. А даже если он и может это выбросить — для JIT — это лишняя работа, а это в свою очередь тоже увеличивает startup time.

PS: Ну, где не прав — не обезсудьте.

Декомпильнул тут (Решарпером) один из наших небольших классов и по началу его не узнал. Вроде бы в исходниках был малюсенький такой классик. На страничку:

using Nemerle;
using Nemerle.Collections;
using Nemerle.Extensions;
using Nemerle.Text;
using Nemerle.Utility;

using System;
using System.Collections.Generic;
using System.Linq;

namespace N2.Internal
{
  [Record]
  [StructuralEquality]
  public class RecoveryResult
  {
    public StartPos    : int;
    public RuleEndPos  : int;
    public EndPos      : int;
    public StartState  : int;
    public StackLength : int;
    public Stack       : list[RecoveryStackFrame].Cons;
    public Text        : string;
    public FailPos     : int;

    public BeforeFail     : string { get { Text.Substring(0, FailPos) } }
    public Skiped         : string { get { Text.Substring(FailPos, StartPos - FailPos) } }
    public SkipedCount    : int    { get { StartPos - FailPos } }
    public Recovered      : string { get { try Text.Substring(StartPos, RecoveredCount)            catch "<unknown>" } }
    public RecoveredHead  : string { get { try Text.Substring(StartPos, RecoveredHeadCount)        catch "<unknown>" } }
    public RecoveredTail  : string { get { try Text.Substring(GetRuleEndPos(), RecoveredTailCount) catch "<unknown>" } }

    public RecoveredCount     : int    { get { EndPos - StartPos } }
    public RecoveredHeadCount : int    { get { GetRuleEndPos() - StartPos } }
    public RecoveredTailCount : int    { get { EndPos - GetRuleEndPos() } }

    GetRuleEndPos() : int { if (RuleEndPos < 0) StartPos else RuleEndPos }

    public override ToString() : string
    {
      $<#$(Stack.Head) StartState=$StartState  Skiped="$Skiped"  Recovered: Head="$RecoveredHead" Tail=="$RecoveredTail" #>
    }
  }
}

А в результате получилось (и ведь не выбросишь не капли):

// Type: N2.Internal.RecoveryResult
// Assembly: N2.Runtime, Version=896.0.0.0, Culture=neutral, PublicKeyToken=e080a9c724e2bfcd
// MVID: 6EF974BD-7AC2-4A0B-94B4-C3222EE7A587
// Assembly location: G:\P\Nitra\N2\N2.Runtime\bin\Debug\N2.Runtime.dll

using Nemerle.Core;
using Nemerle.Internal;
using System;
using System.Collections;
using System.Collections.Generic;

namespace N2.Internal
{
  public class RecoveryResult : IEquatable<RecoveryResult>, IStructuralEquatable
  {
    public readonly int StartPos;
    public readonly int RuleEndPos;
    public readonly int EndPos;
    public readonly int StartState;
    public readonly int StackLength;
    public readonly list<RecoveryStackFrame>.Cons Stack;
    public readonly string Text;
    public readonly int FailPos;

    public string BeforeFail { get { return this.Text.Substring(0, this.FailPos); } }
    public string Skiped { get { return this.Text.Substring(this.FailPos, checked (this.StartPos - this.FailPos)); } }
    public int SkipedCount { get { return checked (this.StartPos - this.FailPos); } }
    public string Recovered
    {
      get
      {
        string str;
        try
        {
          str = this.Text.Substring(this.StartPos, this.RecoveredCount);
        }
        catch (Exception ex)
        {
          str = "<unknown>";
        }
        return str;
      }
    }

    public string RecoveredHead
    {
      get
      {
        string str;
        try
        {
          str = this.Text.Substring(this.StartPos, this.RecoveredHeadCount);
        }
        catch (Exception ex)
        {
          str = "<unknown>";
        }
        return str;
      }
    }

    public string RecoveredTail
    {
      get
      {
        string str;
        try
        {
          str = this.Text.Substring(this.GetRuleEndPos(), this.RecoveredTailCount);
        }
        catch (Exception ex)
        {
          str = "<unknown>";
        }
        return str;
      }
    }

    public int RecoveredCount { get { return checked (this.EndPos - this.StartPos); } }
    public int RecoveredHeadCount { get { return this.GetRuleEndPos() - this.StartPos; } }
    public int RecoveredTailCount { get { return checked this.EndPos - this.GetRuleEndPos(); } }

    [RecordCtor]
    public RecoveryResult([MappedMember("StartPos")] int startPos, [MappedMember("RuleEndPos")] int ruleEndPos, [MappedMember("EndPos")] int endPos, [MappedMember("StartState")] int startState, [MappedMember("StackLength")] int stackLength, [MappedMember("Stack")] list<RecoveryStackFrame>.Cons stack, [MappedMember("Text")] string text, [MappedMember("FailPos")] int failPos)
    {
      this.StartPos = startPos;
      this.RuleEndPos = ruleEndPos;
      this.EndPos = endPos;
      this.StartState = startState;
      this.StackLength = stackLength;
      this.Stack = stack;
      this.Text = text;
      this.FailPos = failPos;
    }

    public static bool operator !=(RecoveryResult first, RecoveryResult second)
    {
      return !(first == second);
    }

    public static bool operator ==(RecoveryResult first, RecoveryResult second)
    {
      if ((object) first != null)
        return first.Equals(second);
      return (object) second == null;
    }

    public int GetHashCode(IEqualityComparer _comparer)
    {
      return this.GetHashCode();
    }

    public bool Equals(object other, IEqualityComparer _comparer)
    {
      return this.Equals(other);
    }

    public override int GetHashCode()
    {
      int num1 = 0 + this.StartPos;
      int num2 = num1 + (num1 << 10);
      int num3 = (num2 ^ num2 >> 6) + this.RuleEndPos;
      int num4 = num3 + (num3 << 10);
      int num5 = (num4 ^ num4 >> 6) + this.EndPos;
      int num6 = num5 + (num5 << 10);
      int num7 = (num6 ^ num6 >> 6) + this.StartState;
      int num8 = num7 + (num7 << 10);
      int num9 = (num8 ^ num8 >> 6) + this.StackLength;
      int num10 = num9 + (num9 << 10);
      int num11 = num10 ^ num10 >> 6;
      list<RecoveryStackFrame>.Cons cons = this.Stack;
      int num12 = 0;
      if ((list<RecoveryStackFrame>) cons != (list<RecoveryStackFrame>) null)
        num12 = cons.GetHashCode();
      int num13 = num12;
      int num14 = num11 + num13;
      int num15 = num14 + (num14 << 10);
      int num16 = num15 ^ num15 >> 6;
      string str = this.Text;
      int num17 = 0;
      if (str != (string) null)
        num17 = str.GetHashCode();
      int num18 = num17;
      int num19 = num16 + num18;
      int num20 = num19 + (num19 << 10);
      int num21 = (num20 ^ num20 >> 6) + this.FailPos;
      int num22 = num21 + (num21 << 10);
      return num22 ^ num22 >> 6;
    }

    public override bool Equals(object other)
    {
      object obj = other;
      if (obj is RecoveryResult)
        return this.EqualsImpl((RecoveryResult) obj);
      else
        return false;
    }

    public bool Equals(RecoveryResult other)
    {
      return this.EqualsImpl(other);
    }

    private int GetRuleEndPos()
    {
      if (this.RuleEndPos < 0)
        return this.StartPos;
      else
        return this.RuleEndPos;
    }

    public override string ToString()
    {
      string[] strArray = new string[10];
      int index1 = 0;
      string str1 = Convert.ToString((object) this.Stack.Head);
      strArray[index1] = str1;
      int index2 = 1;
      string str2 = " StartState=";
      strArray[index2] = str2;
      int index3 = 2;
      string str3 = Convert.ToString(this.StartState);
      strArray[index3] = str3;
      int index4 = 3;
      string str4 = "  Skiped=\"";
      strArray[index4] = str4;
      int index5 = 4;
      string str5 = Convert.ToString(this.Skiped);
      strArray[index5] = str5;
      int index6 = 5;
      string str6 = "\"  Recovered: Head=\"";
      strArray[index6] = str6;
      int index7 = 6;
      string str7 = Convert.ToString(this.RecoveredHead);
      strArray[index7] = str7;
      int index8 = 7;
      string str8 = "\" Tail==\"";
      strArray[index8] = str8;
      int index9 = 8;
      string str9 = Convert.ToString(this.RecoveredTail);
      strArray[index9] = str9;
      int index10 = 9;
      string str10 = "\" ";
      strArray[index10] = str10;
      return string.Concat(strArray);
    }

    protected virtual bool EqualsImpl(RecoveryResult other)
    {
      if ((object) other == null)
        return false;
      else
        return this.FailPos == other.FailPos && (string.Equals(this.Text, other.Text) && (EqualityComparer<list<RecoveryStackFrame>.Cons>.Default.Equals(this.Stack, other.Stack) && (this.StackLength == other.StackLength && (this.StartState == other.StartState && (this.EndPos == other.EndPos && (this.RuleEndPos == other.RuleEndPos && this.StartPos == other.StartPos))))));
    }
  }
}

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

I>

На самом деле тут надо подойти более трезво.
Насколько реально иметь 1000 лямбд с выражениями в проекте это раз.
Во вторых 200КБ это не 200МБ , поэтому я бы не сказал что размер такая серьезная проблема.

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

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

I>>Поэтому компактность кода это очень важно.
_NN>Это конечно важно, но всегда есть вопрос цены.
_NN>Я бы сказал, что Nemerle с новым бек-эндом гораздо важнее чем проблемы размера сборок.

А можно я буду смотреть на проблемы со своей стороны ?

I>>Но вообще меня забавляет ваше отношение к деталям, похоже, кроме как нетленкой вы ничем не хотите заниматься.
_NN>Откуда такие выводы ?
_NN>Было бы много свободного времени у всех, уже бы давно можно было бы все исправить.
_NN>А можно и задать вопрос наоборот, почему вам бы помочь проекту Nemerle ? Глядишь исправили бы все проблемы.

Я как то не имею обыкновения сотрудничать с теми, у кого нет времени, потому что как правило в таких случаях состояние проекта "вечные 90%".

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

_NN>... и не стоит делать из мухи слона.

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

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

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

I>>>>С тех самых. Есть проекты и побольше — Chromium сгодится ? Офис ? Windows ? Linux ? всякие BD ?
_NN>>>Кстати Chromium на С++.
_NN>>>Некоторые библиотеки в Windows тоже на С++.
I>>Это неважно. Си как то со сцены никуда не делся. Странно ожидать другого, если до сих пор пишут и на лиспе и на коболе и на фортране.
F> Ну как же неважно, когда подавляющее большинство проектов пишутся на C++.

Пусть пишутся. Что с того ?

>V8 на C представить себе и вовсе сложно. Есть и полностью написанные проекты на C, например netsurf, но это скорее — исключение. В C ничего плохого нет, но не использовать возможности C++ тоже глупо — это как писать на C#2+ и принципиально не пользоваться генериками, безо всяких на то оснований.

Сферическую конницу не хочется обсуждать.

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

_NN>А вы лучше попробуйте скомпилировать какой-нибудь реальный код компилятором Nemerle. ( Он конечно не весь C# поддерживает, но большинство кода осиливает. )

Надо называть вещи своими именами — "язык похожий на C#"

_NN>И посмотрите насколько действительно увеличивается размер сборки.
_NN>Синтетические тесты интересны , но полезности в них не всегда достаточно.

Проект уже заморожен фактически. Почему меня интересует Немерле(в той части, что без макров) дело десятое.

_NN>Еще раз , если вы видите в этом реальную проблему Nemerle, можно было уже давно помочь исправить.
_NN>Ну или хотя бы выложить идеи как это исправить.
_NN>А то по вашим словам складывается, что эта проблема для вас камень преткновения повсеместного использования Nemerle

Не эта, а целая куча самых разных.

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

I>Такой уникальный подход к обсуждению проблем почему-то у проекта Немерле. Сколько ни переписывался с авторами других проектов, подход примерно такой "проблема-обсуждение" или "проблема-тикет-приоритет"

Как бы многих проектах с открытым кодом принцип сделай сам.
Иначе зачем открытый код

Для всех тикетов есть GitHub issues

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

Здравствуйте, Аноним, Вы писали:

А>Программы на Nemerle гораздо меньше потребляют батарею на ноутбуках.

Ясен пень, потому что их там нет. Хотя как я понял они всё равно что-то потребляют

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

I>http://www.rsdn.ru/forum/nemerle/4855827.1
I>Неконтролируемые зависимости, непрозрачный выхлоп компилятора, размер сборок, функциональные типы идентичные стандартным дотнетовским, отсутствие поддержки полной версии языка, который могут выдавать всякие недо-,полу-, Üбер-визарды и прочие генераторы, т.к. переписать такой код нет никакой возможности.
Ээээ... это были мои единоразовые хотелки, когда основная масса возможностей N — не требуется. Т.е. эдакий C# в синтаксисе N.
В остальном у меня положительный опыт с N. Улучшать там есть чего и много, но и то, что уже есть — можно успешно использовать.

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

A>Ну давай, успокой общественность, найди в тесте ошибку.

A>У меня примерно те же числа при нескольких запусках.
Я их не читал. Просто от оборудования результаты сильно могут зависить на микротесте.

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

F>>Делегат может быть быстрее.
A>За счет чего?
За счет того, что никакого диспатчинга не происходит. Делегат — это this и массив готовых указателей на методы. Ну и их хорошенько оптимизировали в .net 2+, если память не изменяет.

F>>Но затраты на его создание, афаик, довольно большие.
A>Я его создаю за пределами цикла.
Это понятно. На практике можем просто иметь метод с единоразовым созданием делегата vs создать класс и вызывать виртуальный метод. Что будет в общем зачете эффективнее — сложно судить.

F>>В любом случае на таком микротесте понятно не будет. + разбор процессоров по всей видимости дают разные результаты.
A>А на каком будет понятно?
Как найти эту золотую середину простым сбособом за 5 минут — мне, увы, не известно. Особенно, когда имеем такие противоречивые результаты. Ничего лучше профилирования двух подходов на более крупных задачах — я не знаю. Наверное самый простой способ сделать это — научить компилятор использовать делегаты — а это задача нифига не тривиальная.

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

A>Да. Вызов виртуального метода (который может еще и инлайниться JITом, если фактический тип известен) заметно быстрее вызова делегата.
A>Если есть основания, что в последнем фреймворке это уже не так, просьба показать.

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

У делегатов есть одно преимущество — они поддерживают ко[нтр]вариантность.

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

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

I>>Такой уникальный подход к обсуждению проблем почему-то у проекта Немерле. Сколько ни переписывался с авторами других проектов, подход примерно такой "проблема-обсуждение" или "проблема-тикет-приоритет"

VD>А ты попробуй высосать проблему из пальца, как в данном случае. И не забудь упомянуть про фрагментацию LOH. Это важно.

Обчно люди сразу честно говорят — проблема есть, приоритет низкий, фиксить не будем и предлагают какие нибудь пути решения. А у тебя куда ни ткни, все время тот воркфлоу что указал, начинается с отрицания и заканчивается "сделай сам".

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

Хороший кстати вопрос, насчет декомпиляции в макросы.
В принципе компилятор может знать какие трансформации проходят и имея неизменяемый AST это все дело могло бы быть обратимо...
И тогда Resharper бы выдал оригинальный код.

VD>    public override int GetHashCode()
VD>    {
VD>      int num1 = 0 + this.StartPos;
VD>      int num2 = num1 + (num1 << 10);
VD>      int num3 = (num2 ^ num2 >> 6) + this.RuleEndPos;
VD>      int num4 = num3 + (num3 << 10);
VD>      int num5 = (num4 ^ num4 >> 6) + this.EndPos;
VD>      int num6 = num5 + (num5 << 10);
VD>      int num7 = (num6 ^ num6 >> 6) + this.StartState;
VD>

Hash code беспонтово считается. Где bit shuffling без потерь информации: умножения на большие нечётные константы, XOR-ы с масками, циклические сдвиги подстроки битов, сложения с большими константами?

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

VD>Декомпильнул тут (Решарпером) один из наших небольших классов и по началу его не узнал. Вроде бы в исходниках был малюсенький такой классик. На страничку:

Ну дык, у Немерле ещё тот оптимизатор кода. Помнится, когда он научился компилировать BLToolkit, то размер сборки был толи в 2, толи в 3 раза больше, чем аналогичный результат выдаваемый шарпом.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

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

N>Hash code беспонтово считается. Где bit shuffling без потерь информации: умножения на большие нечётные константы, XOR-ы с масками, циклические сдвиги подстроки битов, сложения с большими константами?

Я вообще не знаю кто эту химию нагородил.

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

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

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

N>>Hash code беспонтово считается. Где bit shuffling без потерь информации: умножения на большие нечётные константы, XOR-ы с масками, циклические сдвиги подстроки битов, сложения с большими константами?

VD>Я вообще не знаю кто эту химию нагородил.

Я нагородил. Почему без умножений? Вот почему: http://www.rsdn.ru/forum/nemerle/4429772.1

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

VD>Если хочешь, можешь помочь проекту и тряхнуть стариной, сделать идеальную, с твоей точки зрения, реализацию.

Я ж говорил: пока я в MS, мне без одобрения наших юристов этим никак нельзя заниматься.

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

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

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

N>>>Hash code беспонтово считается. Где bit shuffling без потерь информации: умножения на большие нечётные константы, XOR-ы с масками, циклические сдвиги подстроки битов, сложения с большими константами?

VD>>Я вообще не знаю кто эту химию нагородил.

C>Я нагородил. Почему без умножений? Вот почему: http://www.rsdn.ru/forum/nemerle/4429772.1

Сейчас умножение в 20-300 раз медленнее доступа в память в случае промоха кеша....

Здравствуйте, Аноним, Вы писали:

Сейчас умножение в 20-300 раз быстрее доступа в память в случае промоха кеша....

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

N>Я ж говорил: пока я в MS, мне без одобрения наших юристов этим никак нельзя заниматься.

Что-то я не пойму, как реализация алгоритма хэшкода связана с твоей работой в МС. Ну, да ничего не поделать.

Лично мне в общем-то по фигу как там хэш получается. Я и обычными ^ обошелся бы. А где нужна скорость и качество можно и руками своять.

ЗЫ

Возвращайся в ДжетБрэйнс. Вместе Н2 будем ваять.

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

IT>Ну дык, у Немерле ещё тот оптимизатор кода. Помнится, когда он научился компилировать BLToolkit, то размер сборки был толи в 2, толи в 3 раза больше, чем аналогичный результат выдаваемый шарпом.

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

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

http://ru.wikipedia.org/wiki/FNV

function FNV1aHash(const buf; len: Integer): LongWord;
var
  pb: PByte;
  i: Integer;
begin
  pb := PByte(@buf);
  Result := $811C9DC5;
  for i := len downto 1 do
  begin
    Result := (Result xor pb^) * $01000193;
    Inc(pb);
  end;
end;

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

IT>>Ну дык, у Немерле ещё тот оптимизатор кода. Помнится, когда он научился компилировать BLToolkit, то размер сборки был толи в 2, толи в 3 раза больше, чем аналогичный результат выдаваемый шарпом.

VD>Если честно, не помню такого (возможно дело в классах под лямбды было).

У вас же есть тестовые проекты под C#. Возьмите и сравните. Я в своё время тоже этого дела надекомпилировался и проблема там не в лямбдах, а в ПМ, и, в результате, в любом банальном if. Код там может по производительности и более менее эффективный генерируется, но лишнего мусора тоже хватает, явно больше чем надо.

VD>Но тут явно не в этом дело. Просто привыкаешь, что кучу рутинного кода можно заменить двумя макросами, а синтаксис позволяет писать многие вещи в строку, а не разносить на пять (try-и, например).

Ну это понятно. А когда у вас до оптимизаторов руки дойдут?

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

IT>Ну это понятно. А когда у вас до оптимизаторов руки дойдут?

Лапши захотелось?

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

IT>У вас же есть тестовые проекты под C#. Возьмите и сравните. Я в своё время тоже этого дела надекомпилировался и проблема там не в лямбдах, а в ПМ, и, в результате, в любом банальном if. Код там может по производительности и более менее эффективный генерируется, но лишнего мусора тоже хватает, явно больше чем надо.

Тут скорее проблема в декомпиляторе Reflector вообще кривой. ILSpy нормально декомпилирует, но иногда врет. Нет там ничего лишнего.

VD>>Но тут явно не в этом дело. Просто привыкаешь, что кучу рутинного кода можно заменить двумя макросами, а синтаксис позволяет писать многие вещи в строку, а не разносить на пять (try-и, например).

IT>Ну это понятно. А когда у вас до оптимизаторов руки дойдут?

А на фиг одни нужны? Скорость такая же. Если какие-то шероховатости и есть, то оптимизатор jit-а и gnen-а их устраняет. Да и про какие-то страшные не оптимальные конструкции это ты преувеличиваешь. Я этот декомпилированный код почти каждый день смотрю. Там все ОК.

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

IT>>У вас же есть тестовые проекты под C#. Возьмите и сравните. Я в своё время тоже этого дела надекомпилировался и проблема там не в лямбдах, а в ПМ, и, в результате, в любом банальном if. Код там может по производительности и более менее эффективный генерируется, но лишнего мусора тоже хватает, явно больше чем надо.
VD>Тут скорее проблема в декомпиляторе Reflector вообще кривой. ILSpy нормально декомпилирует, но иногда врет. Нет там ничего лишнего.

А куда оно делось? То, что было это 100%, это я хорошо помню ещё когда с дебагером возился. Неужели кто-то этим специально занимался?

IT>>Ну это понятно. А когда у вас до оптимизаторов руки дойдут?
VD>А на фиг одни нужны? Скорость такая же. Если какие-то шероховатости и есть, то оптимизатор jit-а и gnen-а их устраняет. Да и про какие-то страшные не оптимальные конструкции это ты преувеличиваешь. Я этот декомпилированный код почти каждый день смотрю. Там все ОК.

Понятно. Другого ответа трудно было ожидать.

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

IT>А куда оно делось? То, что было это 100%, это я хорошо помню ещё когда с дебагером возился. Неужели кто-то этим специально занимался?

Я не знаю что ты помнишь. Давай смотреть на конкретные примеры.

IT>Понятно. Другого ответа трудно было ожидать.

Приятно что та свое невнятный вопрос ты получил ожидаемый ответ. Еще раз повторяюсь. Приводи примеры проблем — будем смотреть.

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

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

I>"Декомпильнул тут (Решарпером) один из наших небольших классов и по началу его не узнал"

I>"Я этот декомпилированный код почти каждый день смотрю. Там все ОК."

I>

Да, действительно

. Влезть в середину разговора, вырвать из контекста пару строк. Ничего не понять и начать

-ы ставить. Это несомненно

. Я бы на твое месте со стыда сгорел.

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

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

IT>>Понятно. Другого ответа трудно было ожидать.

VD>Приятно что та свое невнятный вопрос ты получил ожидаемый ответ. Еще раз повторяюсь. Приводи примеры проблем — будем смотреть.

А размер сборки это по твоему не проблема ?

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

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

IT>>>Понятно. Другого ответа трудно было ожидать.

VD>>Приятно что та свое невнятный вопрос ты получил ожидаемый ответ. Еще раз повторяюсь. Приводи примеры проблем — будем смотреть.

I>А размер сборки это по твоему не проблема ?

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

Здравствуйте, Аноним, Вы писали:

I>>А размер сборки это по твоему не проблема ?

А>Жуть. Такое впечатление что я вернулся во 90 когда исполняемый файл надо было втиснуть на остатки места на дискете и приходилось его дезассемблерить и заменять инструкции на более короткие или машинный код (можно было на этом 100 байт выйграть) а потом компилировать, сжимать автораспаковщиком преобразовывая в ком....

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

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

I>А размер сборки это по твоему не проблема ?

А размер то с чего изменится? Если написать код вручную на C#, то он столько же места будет занимать.

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

I>>А размер сборки это по твоему не проблема ?
VD>А размер то с чего изменится? Если написать код вручную на C#, то он столько же места будет занимать.

Влад, я тебе уже говорил. Размер сборки, генерируемый Немерлом толи в два, толи в 3 раза больше аналогичного кода на C#. Можешь вытащить из проекта linq2db версию над которой мы когда-то вместе работали и проверить сам.

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

IT>Влад, я тебе уже говорил. Размер сборки, генерируемый Немерлом толи в два, толи в 3 раза больше аналогичного кода на C#. Можешь вытащить из проекта linq2db версию над которой мы когда-то вместе работали и проверить сам.

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

Короче, нужно смотреть конкретно твои длл-и.

Здравствуйте, Аноним, Вы писали:

I>>А размер сборки это по твоему не проблема ?

А>Жуть. Такое впечатление что я вернулся во 90 когда исполняемый файл надо было втиснуть на остатки места на дискете и приходилось его дезассемблерить и заменять инструкции на более короткие или машинный код (можно было на этом 100 байт выйграть) а потом компилировать, сжимать автораспаковщиком преобразовывая в ком....

Ты видел, как в .NET сборках метаданные упаковываются, чтобы выжать несколько лишних битов?
"Expert .NET 2.0 IL Assembler", Serge Lidin, p. 150

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

I>А размер сборки это по твоему не проблема ?

Да нет этой проблемы на практике. Вот гляжу на сборки самого немерла.

Nemerle.Compiler.dll      1 903 616
Nemerle.VisualStudio.dll  1 748 992
Nemerle.dll                 330 752

Nemerle.VisualStudio.dll написана на шарпе и большая она потому что содержит библиотеку MPF (в исходниках) для упрощения работы с API студии.

Для стравнения размеры компилятора C#:

csc.exe  1 972 552 (32 bit)
csc.exe  2 492 232 (64 bit)

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

И это еще дебаг-сборки. В релизе они поменьше.

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

IT>>Влад, я тебе уже говорил. Размер сборки, генерируемый Немерлом толи в два, толи в 3 раза больше аналогичного кода на C#. Можешь вытащить из проекта linq2db версию над которой мы когда-то вместе работали и проверить сам.

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

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

N>Ты видел, как в .NET сборках метаданные упаковываются, чтобы выжать несколько лишних битов?
N>"Expert .NET 2.0 IL Assembler", Serge Lidin, p. 150

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

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

Меж тем весь инсталлятор немерла 4.5 метра. Хотел бы я поглядеть на продукты от МС с такими инсталляторами.

А еще не давно размер был 2 метра. И я уверяю, что кодогенерация и объем кода не изменились. Дело же в каких-то сопутствующих сборках от МС.

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

Ради хохмы пожал немерловые сборки зипом. В среднем они сжимаются в три раза. Ну и зачем было эти биты выжимать?

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

IT>После чего уже я тебе отвечал, что смотрел это дело под микроскопом, когда занимался дебагером для Немерла и дело там в коде, который генерирует для match, а он в Немерле везде.

Уверен, что тебе показалось. if-ы переведенные в match компилируются в те же самые if-ы. Ты что-то путаешь.

Вот для примера взял метод из Н2:

public TryGetPrefix(pos : ref int, prefixAst : ref int) : int
{
  mutable bestResult = ast[prefixAst + ExtensibleRuleParser.PrefixOfs.List];
  when (bestResult < 0)
  {
    def error = ErrorData[~bestResult];
    when (error.Skip.Length == 0)
      return -1;//правило восстановилось пустым.
    pos += error.Skip.Length; // грязь
    prefixAst = GetAst(pos, ast[prefixAst + ExtensibleRuleParser.PrefixOfs.Id]);
    bestResult = ast[prefixAst + ExtensibleRuleParser.PrefixOfs.List]; // исходная ссылка на AST
    assert3(bestResult >= 0 || ErrorData[~bestResult].Skip.Length == 0);
  }
  bestResult;
}

И его декомпилированный вариант:

public int TryGetPostfix(ref int pos, ref int postfixAst)
{
    checked
    {
        int num = this.ast[postfixAst + 2];
        int result;
        if (num < 0)
        {
            ParseErrorData parseErrorData = this.ErrorData[~num];
            if (parseErrorData.Skip.Length == 0)
            {
                result = -1;
                return result;
            }
            pos += parseErrorData.Skip.Length;
            postfixAst = this.GetAst(pos, this.ast[postfixAst + 0] & 1073741823);
            num = this.ast[postfixAst + 2];
            bool flag = num >= 0 || this.ErrorData[~num].Skip.Length == 0;
            if (!flag)
            {
                throw new AssertionException("Internal\\Parser.n", 143, "bestResult >= 0 || ErrorData[~bestResult].Skip.Length == 0", "");
            }
        }
        result = num;
        return result;
    }
}

Ну, лишняя переменная "result" присутствет. Но вряд ли она может дать увеличение объема кода в 2-3 раза.

ЗЫ

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

В прочем, если ты так уверен в том, что немерлу срочно нужен оптимизатор уменьшающий объем кода, то ты можешь помочь проекту. Я вот периодически допиливаю немерл, если ощущаю, что в нем что-то действительно не хватает.

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

N>Ты что, это же job security для тестировщиков приложений, которые читают-пишут метаданные!

Ну, да. И за одно геморрой для тех кто пишет эти библиотеки.

А еще геморрой для тех кто компиляторы. С этими спец-опкодами ведь еще поприседать надо.

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

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

I>>А размер сборки это по твоему не проблема ?

VD>А размер то с чего изменится? Если написать код вручную на C#, то он столько же места будет занимать.

"Помнится, когда он научился компилировать BLToolkit, то размер сборки был толи в 2, толи в 3 раза больше," @ IT

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

I>"Помнится, когда он научился компилировать BLToolkit, то размер сборки был толи в 2, толи в 3 раза больше," @ IT

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

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

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

I>>"Помнится, когда он научился компилировать BLToolkit, то размер сборки был толи в 2, толи в 3 раза больше," @ IT

VD>Я уже IT отвечал, что во-первых не помню такого, а во-вторых, если это так, то причина не в оптимизации кода, а в чем-то другом. Возможно макрос поддержки линка слишком много кода добавляет, или еще что-то.

После сравнения с размером бинарного кода нету доверия к таким словам

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

Насколько я понимаю IT говорил об этом.
Тут лямбды + C# взрывают компилятор.
Полагаю здесь генерировалось много лишнего кода.

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

_NN>Насколько я понимаю IT говорил об этом.
_NN>Тут лямбды + C# взрывают компилятор.
_NN>Полагаю здесь генерировалось много лишнего кода.

Там про размеры кода ни слова не сказано. Там про скорость компиляции гворится. Это проблема известная. Выличить ее получится только когда Н на Н2 перепишем.

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

_NN>>Полагаю здесь генерировалось много лишнего кода.

VD>Там про размеры кода ни слова не сказано. Там про скорость компиляции гворится. Это проблема известная. Выличить ее получится только когда Н на Н2 перепишем.

Поторопись, а то ИТ к тому времени выйдет на пенсию.

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

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

_NN>>Насколько я понимаю IT говорил об этом.
_NN>>Тут лямбды + C# взрывают компилятор.
_NN>>Полагаю здесь генерировалось много лишнего кода.

VD>Там про размеры кода ни слова не сказано. Там про скорость компиляции гворится. Это проблема известная. Выличить ее получится только когда Н на Н2 перепишем.

Вот небольшой тест.
Создаем простой класс с 1000-ю делегатами вида:
a<число> : Expression[Func[int, int]] = x => x;

Получаем:
Nemerle: 224 768 bytes
C#: 60 416 bytes

Разница почти в 4 раза.

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

_NN>Итого: мы нашли место, которое можно оптимизировать, и не стоит делать из мухи слона.
У него просто идея фикс найти в немерле ну хоть какой-то недостаток.
Вот он и цепляется за всякие мелочи.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

I>>

_NN>На самом деле тут надо подойти более трезво.
_NN>Насколько реально иметь 1000 лямбд с выражениями в проекте это раз.

У меня вот лямбды практически везде

_NN>Во вторых 200КБ это не 200МБ , поэтому я бы не сказал что размер такая серьезная проблема.

А если в проекте 10 млн строчек кода ?

_NN>Итого: мы нашли место, которое можно оптимизировать, и не стоит делать из мухи слона.

Проблема есть, а басни про мух и слонов рассказывай своим детям.

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

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

I>>>

_NN>>На самом деле тут надо подойти более трезво.
_NN>>Насколько реально иметь 1000 лямбд с выражениями в проекте это раз.

I>У меня вот лямбды практически везде

_NN>>Во вторых 200КБ это не 200МБ , поэтому я бы не сказал что размер такая серьезная проблема.

I>А если в проекте 10 млн строчек кода ?

_NN>>Итого: мы нашли место, которое можно оптимизировать, и не стоит делать из мухи слона.

I>Проблема есть, а басни про мух и слонов рассказывай своим детям.

Только что наткнулся на эту же проблему.

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

_NN>Итого: мы нашли место, которое можно оптимизировать, и не стоит делать из мухи слона.
Я уже как-то указывал на это место, с небольшим разбором. http://www.rsdn.ru/forum/nemerle/4855827.1
С точки зрения языка — это действительно мелочь, т.к. внешне обеспечивает всё тоже самое.

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

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

_NN>>Итого: мы нашли место, которое можно оптимизировать, и не стоит делать из мухи слона.
WH>У него просто идея фикс найти в немерле ну хоть какой-то недостаток.
WH>Вот он и цепляется за всякие мелочи.

Для х32 платформы размер сборки => расходование АП => LOH-фрагментация. Неконтролируемые зависимости только усугубляют эту проблему.

Поэтому компактность кода это очень важно.

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

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

I>Для х32 платформы размер сборки => расходование АП => LOH-фрагментация. Неконтролируемые зависимости только усугубляют эту проблему.

I>Поэтому компактность кода это очень важно.
Это конечно важно, но всегда есть вопрос цены.
Я бы сказал, что Nemerle с новым бек-эндом гораздо важнее чем проблемы размера сборок.

I>Но вообще меня забавляет ваше отношение к деталям, похоже, кроме как нетленкой вы ничем не хотите заниматься.
Откуда такие выводы ?
Было бы много свободного времени у всех, уже бы давно можно было бы все исправить.

А можно и задать вопрос наоборот, почему вам бы помочь проекту Nemerle ? Глядишь исправили бы все проблемы.

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

_NN>Вот небольшой тест.
_NN>Создаем простой класс с 1000-ю делегатами вида:
_NN>a<число> : Expression[Func[int, int]] = x => x;

То есть, как я и предполагал, дело в особенностях реализации лямбд и делегатов, а не в ПМ?

Это логично. Немерл в любом случае строит класс для лямбд. В шарпе это делает рантайм дотнета.

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

I>А можно я буду смотреть на проблемы со своей стороны ?
Да пожалуйста, но тут проект с открытым кодом.
Помоги себе — поможешь другим.

I>Я как то не имею обыкновения сотрудничать с теми, у кого нет времени, потому что как правило в таких случаях состояние проекта "вечные 90%".
Боюсь тогда проекты с открытым кодом просто не для вас.

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

_NN>Насколько реально иметь 1000 лямбд с выражениями в проекте это раз.

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

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

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

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

I>Для х32 платформы размер сборки => расходование АП => LOH-фрагментация. Неконтролируемые зависимости только усугубляют эту проблему.

Метаданные не хранятся в LOH. А 200 кил оперативки (да и пару мег) на сегодня — это не особая проблема. Особенно с учетом того что сборки разделяются разными процессами. В рантайме же накладных расходов от классов не много. Тому же GC метаданные вообще не нужны. Он универсально работает. Так что на практике немерловые сборки не отличимы от шарповских. Да и делегаты, при программировании на Немерле, не так часто используются. А родные функциональные типы сильного оверхэда не дают.

Кроме того немерловый функциональный тип быстрее. Так что программа написанная в функциональном стиле будет работать на немерле даже быстрее шапрповской. Уж точно не медленнее.

А если вспомнить про макросы, то не трудно догадаться, что с их помощью можно вообще избавиться от непроизводительных расходов путем генерации низкоуровневого кода по некому ДСЛ-ю/модели.

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

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

_NN>А можно и задать вопрос наоборот, почему вам бы помочь проекту Nemerle ? Глядишь исправили бы все проблемы.

Я тебе уже выше говорил. У него цель другая. Он исходно пришел сюда дерма вбросить. К созиданию он не готов.

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

I>А можно я буду смотреть на проблемы со своей стороны ?

Конечно. Можно даже в другом месте. Даже лучше в другом

.

Конструктивную критику мы за всегда рады видеть. А вот бесполезные наезды — нет. Это только время отвлекает, которого и так мало.

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

I>""Я этот декомпилированный код почти каждый день смотрю. Там все ОК.""
I>"во-первых не помню такого,"
I>"Да нет этой проблемы на практике."

I>

Не ужели тебе так приятно выглядеть глупо?

Берем и читаем сначала:
IT>>>Ну дык, у Немерле ещё тот оптимизатор кода. Помнится, когда он научился компилировать BLToolkit, то размер сборки был толи в 2, толи в 3 раза больше, чем аналогичный результат выдаваемый шарпом...

VD>>Если честно, не помню такого (возможно дело в классах под лямбды было). Но тут явно не в этом дело. Просто привыкаешь, что кучу рутинного кода можно заменить двумя макросами, а синтаксис позволяет писать многие вещи в строку, а не разносить на пять (try-и, например)...

IT>У вас же есть тестовые проекты под C#. Возьмите и сравните. Я в своё время тоже этого дела надекомпилировался и проблема там не в лямбдах, а в ПМ, и, в результате, в любом банальном if. Код там может по производительности и более менее эффективный генерируется, но лишнего мусора тоже хватает, явно больше чем надо.

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

ЗЫ

Следовало бы тебя забанить за троллинг и провокации флэйма, но жаль лишать тебя возможности продемонстрировать твою неадекватность.

Здравствуйте, Аноним, Вы писали:

А>Программы на Nemerle гораздо меньше потребляют батарею на ноутбуках.

Это от алгоритмов использованных в программе зависит, а не от языка/компилятора. Просто писать хорошие алгоритмы удобнее на Немерле. Может в этом дело.

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

I>>Для х32 платформы размер сборки => расходование АП => LOH-фрагментация. Неконтролируемые зависимости только усугубляют эту проблему.

VD>Метаданные не хранятся в LOH.

Спасибо, капитан. Многие вещи не хранятся в LOH и тем не менее влияют на фрагментацию этого LOH.

>А 200 кил оперативки (да и пару мег) на сегодня — это не особая проблема. <порожнее скипнул> В рантайме же накладных расходов от классов не много.

Это ты сильно заблуждаешься. Если сборки отличаются в разы, то и выхлоп после джыта так же будет отличаться в разы и это будет не пару мег. Хочешь поспорить — объясни почему в 32х процессе для дотнета доступно только 1гб +- 200мб. Куда девается 1 гиг ?

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

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

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

Здравствуйте, Аноним, Вы писали:

I>>Для х32 платформы размер сборки => расходование АП => LOH-фрагментация. Неконтролируемые зависимости только усугубляют эту проблему.
I>>Поэтому компактность кода это очень важно.

А>Программы на Nemerle гораздо меньше потребляют батарею на ноутбуках.

Дай линку на программу скажем простецкий офис или IDE и чтоб на Немерле, посмотрим и сравним. Без этого придется сравнивать компилятор немерле с компилятором C# и тут победитель уже известен заранее

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

I>Дай линку на программу скажем простецкий офис или IDE и чтоб на Немерле, посмотрим и сравним. Без этого придется сравнивать компилятор немерле с компилятором C# и тут победитель уже известен заранее

Тут как бы от тестов зависит и победитель.
Скажем для C# есть Resharper , который экономит время работы, а для Nemerle ничего нет. Засчитываем проигрыш Nemerle ?

У Nemerle другие преимущества по сравнению с C#.
А увеличение размера сборок на 200кб по сравнению с ними совсем не критично.
Конечно было бы приятно, но это никак не уменьшает других достоинств языка.

P.S.
Кстати, апологеты С именно это и говорят в упрек С++, однако разрабатывать большой проект на С мало кто желает.

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

I>Многие вещи не хранятся в LOH и тем не менее влияют на фрагментацию этого LOH.

Это что же за вещи такие? Да, кто такой АП?

>>А 200 кил оперативки (да и пару мег) на сегодня — это не особая проблема. <порожнее скипнул> В рантайме же накладных расходов от классов не много.

I>Это ты сильно заблуждаешься. Если сборки отличаются в разы, то и выхлоп после джыта так же будет отличаться в разы и это будет не пару мег. Хочешь поспорить — объясни почему в 32х процессе для дотнета доступно только 1гб +- 200мб. Куда девается 1 гиг ?

Я не понял причем тут ограничения дотнета. В прочем тут ты тоже ошибаешься. Без учета на фрагментацию в 32-битном процессе 4-го дотнета можно выделить где-то 1.6 гига. Учитывая что размер оперативки доступный 32-битному процессу равен 2 гигам не трудно догадаться, что остальное приходится на загрузку библиотек и накладные расходы.

Сборки же грузятся неуправляемым кодом и на хипы дотнета не влияют. Да и влияние даже в 3 мега по сравнению с гигабайтами достпными процессу просто несерьезно.

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

Ну, и еще раз хочу повторить для тех кто в танке. Описанная разница может возникнуть только в довольно редких случаях. В то же сборке IT данная проблема (если это вообще проблема) возникла из-за убогости самого C#-а. Если бы IT писал библиотеку исходно на Немерле, то он выбрал бы совсем другой подход основанный на макросах. Это существенно сократило бы как расход памяти, так и время компиляции сборки. А не делает он это потому что текущее решение уже написано (потом и кровью) и переписывать его просто тяжело.

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

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

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

Дай ссылку, почитаю. Здесь ты только только фэйспалмы бессысленные расставлял.

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

I>Поторопись, а то ИТ к тому времени выйдет на пенсию.

Быстро только кошки родятся. А серьзный продукт приходится делать усердно и кропотливо. Он мозг взрывает по полной программе.

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

_NN>Тут как бы от тестов зависит и победитель.
_NN>Скажем для C# есть Resharper , который экономит время работы, а для Nemerle ничего нет. Засчитываем проигрыш Nemerle ?

Цитирую:
"Программы на Nemerle гораздо меньше потребляют батарею на ноутбуках."

_NN>У Nemerle другие преимущества по сравнению с C#.
_NN>А увеличение размера сборок на 200кб по сравнению с ними совсем не критично.

Сборки увеличиваются, как ты показал, в 4 раза, а не на 200кб. У меня например для LOH есть всего 100-150мб, при чем моих объектов там ровно один, сотальные принадлежат 3r-party. Пара конских сборок убьёт это окно из за фрагментации. Так что для меня преимущества совсем не очевидны.

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

_NN>P.S.
_NN>Кстати, апологеты С именно это и говорят в упрек С++, однако разрабатывать большой проект на С мало кто желает.

nginx не считать ?

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

_NN>>P.S.
_NN>>Кстати, апологеты С именно это и говорят в упрек С++, однако разрабатывать большой проект на С мало кто желает.

I>nginx не считать ?
С каких это пор 4 мегабайта исходного кода стали большим проектом?

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

I>>Многие вещи не хранятся в LOH и тем не менее влияют на фрагментацию этого LOH.

VD>Это что же за вещи такие? Да, кто такой АП?

Адресное пространство.

>>>А 200 кил оперативки (да и пару мег) на сегодня — это не особая проблема. <порожнее скипнул> В рантайме же накладных расходов от классов не много.

I>>Это ты сильно заблуждаешься. Если сборки отличаются в разы, то и выхлоп после джыта так же будет отличаться в разы и это будет не пару мег. Хочешь поспорить — объясни почему в 32х процессе для дотнета доступно только 1гб +- 200мб. Куда девается 1 гиг ?

VD>Я не понял причем тут ограничения дотнета.

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

> В прочем тут ты тоже ошибаешься. Без учета на фрагментацию в 32-битном процессе 4-го дотнета можно выделить где-то 1.6 гига.

1.6гб это консольное приложение без каких либо сборок

Спасибо, кушай сам.

>Учитывая что размер оперативки доступный 32-битному процессу равен 2 гигам не трудно догадаться, что остальное приходится на загрузку библиотек и накладные расходы.

Рельный размер, на который можно рассчитывать в серьезном приложении 1гб+200мб.

VD>Сборки же грузятся неуправляемым кодом и на хипы дотнета не влияют. Да и влияние даже в 3 мега по сравнению с гигабайтами достпными процессу просто несерьезно.

Влияют, еще как. Они расходуют АП и увеличивают фрагментацию.

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

Это решение годится на консольных программ, писаных на коленке. Билдны больших приложений превращаются в хаос.

VD>Ну, и еще раз хочу повторить для тех кто в танке. Описанная разница может возникнуть только в довольно редких случаях. В то же сборке IT данная проблема (если это вообще проблема) возникла из-за убогости самого C#-а. Если бы IT писал библиотеку исходно на Немерле, то он выбрал бы совсем другой подход основанный на макросах. Это существенно сократило бы как расход памяти, так и время компиляции сборки. А не делает он это потому что текущее решение уже написано (потом и кровью) и переписывать его просто тяжело.

У меня такое же случай как у ИТ

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

I>Цитирую:
I>"Программы на Nemerle гораздо меньше потребляют батарею на ноутбуках."

Я такого нигде не утверждал.

_NN>>У Nemerle другие преимущества по сравнению с C#.
_NN>>А увеличение размера сборок на 200кб по сравнению с ними совсем не критично.

I>Сборки увеличиваются, как ты показал, в 4 раза, а не на 200кб. У меня например для LOH есть всего 100-150мб, при чем моих объектов там ровно один, сотальные принадлежат 3r-party. Пара конских сборок убьёт это окно из за фрагментации. Так что для меня преимущества совсем не очевидны.

В 4 раза увеличиваются только код использования делегатов с выражениями.
Сомневаюсь, что ваша сборка состоит исключительно из этого кода.
Согласен, что сборка может быть большего размера, но чтобы сборка занимала 100МБ это надо постараться

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

_NN>>P.S.
_NN>>Кстати, апологеты С именно это и говорят в упрек С++, однако разрабатывать большой проект на С мало кто желает.

I>nginx не считать ?
То, что можно сделать на более низкоуровневом языке не говорит о том, что затраты времени легко окупаются.
У разработчиков nginx есть свои требования на основании которых они решают пожертвовать скоростью разработки, например возможность запуска в эмбэддэд.

Я вот не представляю сколько времени заняло бы написать код моего проекта на С.

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

_NN>>>Кстати, апологеты С именно это и говорят в упрек С++, однако разрабатывать большой проект на С мало кто желает.

I>>nginx не считать ?
F> С каких это пор 4 мегабайта исходного кода стали большим проектом?

С тех самых. Есть проекты и побольше — Chromium сгодится ? Офис ? Windows ? Linux ? всякие BD ?

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

I>С тех самых. Есть проекты и побольше — Chromium сгодится ? Офис ? Windows ? Linux ? всякие BD ?
Кстати Chromium на С++.
Некоторые библиотеки в Windows тоже на С++.

Они что-то не знают ?

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

I>>С тех самых. Есть проекты и побольше — Chromium сгодится ? Офис ? Windows ? Linux ? всякие BD ?
_NN>Кстати Chromium на С++.
_NN>Некоторые библиотеки в Windows тоже на С++.

Это неважно. Си как то со сцены никуда не делся. Странно ожидать другого, если до сих пор пишут и на лиспе и на коболе и на фортране.

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

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

I>>Цитирую:
I>>"Программы на Nemerle гораздо меньше потребляют батарею на ноутбуках."

_NN>Я такого нигде не утверждал.

Это я тебе контекст напомнил.

_NN>В 4 раза увеличиваются только код использования делегатов с выражениями.
_NN>Сомневаюсь, что ваша сборка состоит исключительно из этого кода.
_NN>Согласен, что сборка может быть большего размера, но чтобы сборка занимала 100МБ это надо постараться

Мне снова цитировать себя про лямбды и 50мб кода ?

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

I>Это неважно. Си как то со сцены никуда не делся. Странно ожидать другого, если до сих пор пишут и на лиспе и на коболе и на фортране.
Мне непонятен ваш вывод.
Получается не стоит стремиться к лучшему, ведь и так все можно сделать ?

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

I>>>С тех самых. Есть проекты и побольше — Chromium сгодится ? Офис ? Windows ? Linux ? всякие BD ?
_NN>>Кстати Chromium на С++.
_NN>>Некоторые библиотеки в Windows тоже на С++.
I>Это неважно. Си как то со сцены никуда не делся. Странно ожидать другого, если до сих пор пишут и на лиспе и на коболе и на фортране.
Ну как же неважно, когда подавляющее большинство проектов пишутся на C++. V8 на C представить себе и вовсе сложно. Есть и полностью написанные проекты на C, например netsurf, но это скорее — исключение. В C ничего плохого нет, но не использовать возможности C++ тоже глупо — это как писать на C#2+ и принципиально не пользоваться генериками, безо всяких на то оснований.

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

А вы лучше попробуйте скомпилировать какой-нибудь реальный код компилятором Nemerle. ( Он конечно не весь C# поддерживает, но большинство кода осиливает. )
И посмотрите насколько действительно увеличивается размер сборки.
Синтетические тесты интересны , но полезности в них не всегда достаточно.

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

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

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

I>>Это неважно. Си как то со сцены никуда не делся. Странно ожидать другого, если до сих пор пишут и на лиспе и на коболе и на фортране.
_NN>Мне непонятен ваш вывод.
_NN>Получается не стоит стремиться к лучшему, ведь и так все можно сделать ?

Я за тебя дополню, идёт ?

"К лучшему можно стремиться разными путями, если эти пути — Немерле"

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

I>Я за тебя дополню, идёт ?

I>"К лучшему можно стремиться разными путями, если эти пути — Немерле"

Я такого не говорил.
Более того как ни странно но проект у меня на C#, а не на Nemerle.

Это все , однако, не означает, что у Nemerle нет никаких преимуществ по сравнению с C#.

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

I>>Сферическую конницу не хочется обсуждать.
F> Так это ж ты её начал обсуждать и упорствуешь. Видимо флейма ради. А мир как не был идеальным, так и остаётся, что с того?

Да, это я с твоего аккаунта написал следующее: "писать на C#2+ и принципиально не пользоваться генериками, безо всяких на то оснований"

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

_NN>Это все , однако, не означает, что у Nemerle нет никаких преимуществ по сравнению с C#.

Я где то сказал что у немерле нет никаких преимуществ ? Дай что ли ссылку. Похоже, ты сам притянул такую трактовку на основании утверждения о наличии важной для меня проблемы.

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

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

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

_NN>>А вы лучше попробуйте скомпилировать какой-нибудь реальный код компилятором Nemerle. ( Он конечно не весь C# поддерживает, но большинство кода осиливает. )

I>Надо называть вещи своими именами — "язык похожий на C#"

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

_NN>>И посмотрите насколько действительно увеличивается размер сборки.
_NN>>Синтетические тесты интересны , но полезности в них не всегда достаточно.

I>Проект уже заморожен фактически. Почему меня интересует Немерле(в той части, что без макров) дело десятое.
Заморожен не полностью конечно.
Если чего-то не хватает всегда можно добавить.

_NN>>Еще раз , если вы видите в этом реальную проблему Nemerle, можно было уже давно помочь исправить.
_NN>>Ну или хотя бы выложить идеи как это исправить.
_NN>>А то по вашим словам складывается, что эта проблема для вас камень преткновения повсеместного использования Nemerle

I>Не эта, а целая куча самых разных.

Увы, что есть то есть.

Ждем N2 , или денежных вложений в Nemerle, что менее вероятно.

Есть проблемы которые можно решить, есть на которые можно закрыть глаза в угоду более быстрой разработки, а есть которые не дадут возможность писать на нем.
Увы, не всех финансирует MS ..

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

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

I>>Проект уже заморожен фактически. Почему меня интересует Немерле(в той части, что без макров) дело десятое.
_NN>Заморожен не полностью конечно.
_NN>Если чего-то не хватает всегда можно добавить.

Я про свой проект, это он заморожен. Относительно Немерле у меня пассивное ожидание некоторой стабилизации и появления продуктов в некоторой интересной для меня области.

_NN>Лучше эти проблемы обсуждать, а не упрекать.

Я как ни загляну в топик, где актуальные для меня проблемы, так вижу(в хронологическом порядке):
"у меня все хорошо",
"такой проблемы нет",
"во-первых не помню",
"это не проблема",
"виноват рефлектор(C#, .Net, JIT, GC, MS, нужное вписать)"
"это минорная проблема",
"у нас мало времени",
"сделай сам",
"ждём Н2"
и все это перемешивается обсуждением квалификации, расклеиванием ярлыков в той или иной форме.
Самое интересное, что к большей части таких обсуждений я вообще отношения не имею, разве как пассивный наблюдатель.

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

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

I>>Такой уникальный подход к обсуждению проблем почему-то у проекта Немерле. Сколько ни переписывался с авторами других проектов, подход примерно такой "проблема-обсуждение" или "проблема-тикет-приоритет"

_NN>Как бы многих проектах с открытым кодом принцип сделай сам.
_NN>Иначе зачем открытый код

Это очевидно, только както указаного воркфлова "у меня все хорошо"..."ждём Н2" ни у кого кроме Немерле нет.

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

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

Представляю разговор с продукт овнером:
— Есть классный язык Немерле, там все круто, функциональщина, метапрограммирование на макрах и прочие ДСЛы. Давай юзать ?
— Давай !
— Есть небольшой бажок, что бы проект взлетел у наших кастомеров с допотопными компами-виндами, которые и приносят больше всего денег, надо переписать компилятор Немерле...
— ???WTF???

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

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

I>Итого, решение небольшой проблемы из "сделай сам" переросло в "переписывание компилятора"

Я не сказал, что из-за небольшой проблемы надо переписывать компилятор.
В общем плане разработка на Nemerle не требует вмешательства в компилятор.

Есть конкретные проблемы, которые не просто решить.
Например возможность генерировать сборки для другой версии .NET-а. (Из-за ограничения System Reflection Emit )
Или улучшить скорость работы компилятора.

I>Представляю разговор с продукт овнером:
I>- Есть классный язык Немерле, там все круто, функциональщина, метапрограммирование на макрах и прочие ДСЛы. Давай юзать ?
I>- Давай !
I>- Есть небольшой бажок, что бы проект взлетел у наших кастомеров с допотопными компами-виндами, которые и приносят больше всего денег, надо переписать компилятор Немерле...
I>- ???WTF???

Этот разговор может быть в плане любой технологии, не обязательно Nemerle.
У меня похожего типа разговоры были неоднократно (если что Nemerle тут не при чем =) )
Разве у вас не бывает желания что-то улучшить в работе, но это упирается во всякого рода ограничения , которые невозможно просто устранить ?

Скажем, такой же разговор мог быть если хотим использовать последний F# с .NET 2.0 или что-нибудь в этом духе.

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

_NN>Этот разговор может быть в плане любой технологии, не обязательно Nemerle.

Если для указаных проблем надо переписывать компилятор, то аргументы "присоединяйся", "сделай сам", "ждём Н2" как то неактуальны.

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

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

_NN>>Этот разговор может быть в плане любой технологии, не обязательно Nemerle.

I>Если для указаных проблем надо переписывать компилятор, то аргументы "присоединяйся", "сделай сам", "ждём Н2" как то неактуальны.

А можно узнать, что конкретно вам мешает ?
Возможно действительно вы Nemerle использовать не сможете.

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

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

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

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

_NN>>Как бы многих проектах с открытым кодом принцип сделай сам.
_NN>>Иначе зачем открытый код

I>Это очевидно, только както указаного воркфлова "у меня все хорошо"..."ждём Н2" ни у кого кроме Немерле нет.
Ой ли... Все настолько за....сь ждать Рослин, что все кто мог и кому это было интересно — давно забили хрен на него, потому что от Nemerle до NRefactory — давно решаются все эти задачи, даже без их патентованых никому не нужных пальцев.

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

_NN>Это конечно важно, но всегда есть вопрос цены.
_NN>Я бы сказал, что Nemerle с новым бек-эндом гораздо важнее чем проблемы размера сборок.

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

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

I>Я как то не имею обыкновения сотрудничать с теми, у кого нет времени, потому что как правило в таких случаях состояние проекта "вечные 90%".

Дык, языку ещё и 10 лет нету, а уже целых 90%.

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

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

Вы же всё позакрывали и всех послали. Как тут можно помочь?

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

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

А ты сам-то проверял или в этой ветке чьё-то мнение прочитал.

VD>Следовало бы тебя забанить за троллинг и провокации флэйма, но жаль лишать тебя возможности продемонстрировать твою неадекватность.

Давно уже следовало бы отобрать у тебя модерилку, чтобы лишить тебя возможности демонстрировать твою неадекватность в модерировании

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

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

_NN>>>Как бы многих проектах с открытым кодом принцип сделай сам.
_NN>>>Иначе зачем открытый код

I>>Это очевидно, только както указаного воркфлова "у меня все хорошо"..."ждём Н2" ни у кого кроме Немерле нет.
F> Ой ли... Все настолько за....сь ждать Рослин, что все кто мог и кому это было интересно — давно забили хрен на него, потому что от Nemerle до NRefactory — давно решаются все эти задачи, даже без их патентованых никому не нужных пальцев.

Я как то не заметил, что все забили хрен на Рослин

Учитывая все это:
его закрытость, поддержку исключительно C# и VB и то, что выйдет не скоро.
Я бы сказал, что N2 будет раньше пригодным для использования.

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

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

_NN>А можно узнать, что конкретно вам мешает ?

Предлагаешь начать второй круг ?

_NN>Возможно действительно вы Nemerle использовать не сможете.

Начинать второй круг нет возможности.

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

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

_NN>>А можно узнать, что конкретно вам мешает ?

I>Предлагаешь начать второй круг ?
А где написано что мешает ?
Кроме жалоб на размер лямбд я так и не понял что конкретно мешает

_NN>Подружить Resharper (другой инструмент) с Nemerle конечно не получится без содействия с jetBrains (другим инструментом), хотя думаю это и так понятно.

В случае с Resharper вполне может получиться. У Resharper достаточно открытая архитектура, можно подцепить свой языковой плагин и как минимум навигация, всякие find usages и другие простые штуки заведутся. В SDK и в паблике есть несколько примеров языков с навигацией, и первые шаги с Nemerle идут довольно легко. У меня были экспериментальные попытки на эту тему. Но до стадии "можно что-то показать" не дошло — вылезает куча пустой работы из-за того что внутренний фреймворк решарпера заточен на выхлоп их генератора парсеров.

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

I>>Предлагаешь начать второй круг ?
_NN>А где написано что мешает ?
_NN>Кроме жалоб на размер лямбд я так и не понял что конкретно мешает

http://www.rsdn.ru/forum/nemerle/4855827.1

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

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

I>>Неконтролируемые зависимости, непрозрачный выхлоп компилятора, размер сборок, функциональные типы идентичные стандартным дотнетовским, отсутствие поддержки полной версии языка, который могут выдавать всякие недо-,полу-, Üбер-визарды и прочие генераторы, т.к. переписать такой код нет никакой возможности.
F>Ээээ... это были мои единоразовые хотелки, когда основная масса возможностей N — не требуется. Т.е. эдакий C# в синтаксисе N.

У меня ровно то же, только это все обязательно в моем случае

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

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

I>>>Неконтролируемые зависимости, непрозрачный выхлоп компилятора, размер сборок, функциональные типы идентичные стандартным дотнетовским, отсутствие поддержки полной версии языка, который могут выдавать всякие недо-,полу-, Üбер-визарды и прочие генераторы, т.к. переписать такой код нет никакой возможности.
F>>Ээээ... это были мои единоразовые хотелки, когда основная масса возможностей N — не требуется. Т.е. эдакий C# в синтаксисе N.

I>У меня ровно то же, только это все обязательно в моем случае

Теперь все ясно.

Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал..

Насчет контроля зависимостей, тут я даже не знаю что и придумать.
Nemerle.dll это как любая Utility.dll , которая всегда нужна.
Скажем в .NET 3.5 нет System.Threading.dll, а таски использовать хочется, получается лишняя зависимость , и как решить этот случай ?

Можно подумать как базовые типы выразить в терминах фреймворка, а все остальное вынести в отдельную библиотеку Nemerle.Lib.dll.
Тут бы хорошо подошли макротипы

Можно попробовать ILMerge-м объединить в одну сборку.
Есть идеи лучше ?

В любом случае кто-то должен будет это сделать, а если некому, то это не случится.

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

_NN>Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал..
Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов.

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

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

_NN>>Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал..
A>Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов.

А какая причина ?
Скорость ?

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

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

IT>А ты сам-то проверял или в этой ветке чьё-то мнение прочитал.

Я не однократно видел код ПМ и уверен, что ты ошибешься по его поводу. Что касается замыканий, лямбд и делегатов, то это вполне вероятно, так как я знаю как оно там реализовано и какие проблемы эта реализация может породить. НН озвучил результаты вполне очевидного эксперимента. Не вижу оснований не доверять его результатам.

IT>Давно уже следовало бы отобрать у тебя модерилку, чтобы лишить тебя возможности демонстрировать твою неадекватность в модерировании

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

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

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

IT>Вы же всё позакрывали и всех послали. Как тут можно помочь?

Что по закрывали? Кого послали? Чем помочь?

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

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

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

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

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

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

_NN>>>Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал..
A>>Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов.
_NN>А какая причина ?
_NN>Скорость ?

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

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

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

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

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

_NN>>>>Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал..
A>>>Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов.
_NN>>А какая причина ?
_NN>>Скорость ?

A>Да. Вызов виртуального метода (который может еще и инлайниться JITом, если фактический тип известен) заметно быстрее вызова делегата.
A>Если есть основания, что в последнем фреймворке это уже не так, просьба показать.

Я так понимаю это называется теперь FSharpFunc.
В F# есть карринг, без него конечно будет сложно , получится что-то вроде Func[int, Func[string, double]] вместо Func[int, string, double].
Но в Nemerle то карринга нет.

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

I>Спасибо, капитан. Многие вещи не хранятся в LOH и тем не менее влияют на фрагментацию этого LOH.

Это чушь. На фрагментацию влияет количество перезоемов больших объектов и паттерн распределения памяти. А для загрузки длл отводится соврешенно другая область памяти, которая никак не влияет на область памяти выделяемой под LOH.

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

Я то знаю о чем говорю. Компилируются только метода. После компиляции метаданные методам нужны только для рефлексии, которая не так уж часто применяется.

Хочешь поспорить — объясни почему в 32х процессе для дотнета доступно только 1гб +- 200мб. Куда девается 1 гиг ?

Я тебе уже говорил, что реальная цифра около 1.6 гига. И определеяется она объемом виртуальной памяти доступной процессу под 32-битной Виндовс. Остальное резервируется под нужды рантайма. Ты же занимавшийся выдумками.

В любом случае на фоне гига даже мегабайтная сборка — это 0.1%. Она рояли не играет. Чтобы создать мегабайтную сборку нужно не один мег исходников наколбасить. А ты намеренно пытаешься сделать из мухи слона.

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

I>>Спасибо, капитан. Многие вещи не хранятся в LOH и тем не менее влияют на фрагментацию этого LOH.

VD>Это чушь. На фрагментацию влияет количество перезоемов больших объектов и паттерн распределения памяти.

Это факты.

>А для загрузки длл отводится соврешенно другая область памяти, которая никак не влияет на область памяти выделяемой под LOH.

Чудеса, да и только. Какая область памяти отводится, дело десятое. Главное что сборки жрут именно ту часть АП, которая может использоваться GC.

Проверить просто — берешь консольное приложение безо всяких зависимостей и выделяешь память. Выходит около 1.6-1.9 гб в завимости от размера блока. 1.9 будет если выделять кусками по 16мб

Дальше просто — вгружаешь сборки и, внезапно, когда количество и разным сборок сравнимо с количеством в реальном приложении, память почемуто начинается заканчиваться на планке 1гб+200мб. Все зависит естественно от способа расходования памяти.

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

VD>Я то знаю о чем говорю. Компилируются только метода. После компиляции метаданные методам нужны только для рефлексии, которая не так уж часто применяется.
VD>Хочешь поспорить — объясни почему в 32х процессе для дотнета доступно только 1гб +- 200мб. Куда девается 1 гиг ?
VD>Я тебе уже говорил, что реальная цифра около 1.6 гига. И определеяется она объемом виртуальной памяти доступной процессу под 32-битной Виндовс. Остальное резервируется под нужды рантайма. Ты же занимавшийся выдумками.

Это цифра для консольного приложения без каких либо сборок, только самый минимум. В реальном приложении будет 1гб +-200мб.

VD>В любом случае на фоне гига даже мегабайтная сборка — это 0.1%. Она рояли не играет. Чтобы создать мегабайтную сборку нужно не один мег исходников наколбасить. А ты намеренно пытаешься сделать из мухи слона.

У меня >50мб исходного кода. Ты хорошо понимаешь, что это значит ?

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

Тест:

Скрытый текст

using System;
using System.Diagnostics;

namespace DelegPerf
{
    public abstract class Function<T, TR>
    {
        public abstract TR Invoke(T v);
    }

    class Program
    {
        private long x;

        private long Work(int n)
        {
            x += n;
            return x;
        }

        public sealed class MyFunction : Function<int, long>
        {
            private readonly Program p;

            public MyFunction(Program p)
            {
                this.p = p;
            }

            public override long Invoke(int n)
            {
                return p.Work(n);
            }
        }

        private static void Main()
        {
            const int M = 100;
            const int N = 10*1000*1000;

            var p = new Program();

            Func<int, long> myDelegate = p.Work;
            Function<int, long> myFunction = new MyFunction(p);

            long directBestResult = long.MaxValue;
            long delegateBestResult = long.MaxValue;
            long myFuncBestResult = long.MaxValue;

            p.Work(1);
            myDelegate(1);
            myFunction.Invoke(1);

            var sw = new Stopwatch();

            for (int i = 0; i < M; i++)
            {
                sw.Reset();
                sw.Start();
                for (int j = 0; j < N; j++)
                    p.Work(1);
                sw.Stop();
                directBestResult = Math.Min(directBestResult, sw.ElapsedTicks);

                sw.Reset();
                sw.Start();
                for (int j = 0; j < N; j++)
                    myDelegate(1);
                sw.Stop();
                delegateBestResult = Math.Min(delegateBestResult, sw.ElapsedTicks);

                sw.Reset();
                sw.Start();
                for (int j = 0; j < N; j++)
                    myFunction.Invoke(1);
                sw.Stop();
                myFuncBestResult = Math.Min(myFuncBestResult, sw.ElapsedTicks);
            }

            Console.WriteLine("Direct: {0}", directBestResult);
            Console.WriteLine("Delegate: {0}", delegateBestResult);
            Console.WriteLine("MyFunction: {0}", myFuncBestResult);
            Console.WriteLine("Delegate - Direct: {0}", delegateBestResult - directBestResult);
            Console.WriteLine("MyFunction - Direct: {0}", myFuncBestResult - directBestResult);

            Console.ReadKey();
        }
    }
}

.Net 4.5, x64, Release, запуск вне студии, результаты:

Direct: 65315
Delegate: 110651
MyFunction: 148791
Delegate — Direct: 45336
MyFunction — Direct: 83476

Это что ж получается, вызов делегата почти в 2 раза быстрее вызова виртуального метода?

Кто-нибудь может объяснить случившееся?

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

i3-3220, net45, x64, release:

Direct: 68005
Delegate: 65950
MyFunction: 78167
Delegate — Direct: -2055
MyFunction — Direct: 10162

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

A>.Net 4.5, x64, Release, запуск вне студии, результаты:

A>Direct: 65315
A>Delegate: 110651
A>MyFunction: 148791
A>Delegate — Direct: 45336
A>MyFunction — Direct: 83476

A>Это что ж получается, вызов делегата почти в 2 раза быстрее вызова виртуального метода?

A>Кто-нибудь может объяснить случившееся?

Сделал так:

    Func<int, long> myDelegate = n => p.Work(n);

Результаты:

Direct: 65300
Delegate: 135309
MyFunction: 149690
Delegate — Direct: 70009
MyFunction — Direct: 84390

Все равно Delegate быстрее...

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

F>Delegate — Direct: -2055
Ну давай, успокой общественность, найди в тесте ошибку.

У меня примерно те же числа при нескольких запусках.

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

A>Сделал так:
A>

A>    Func<int, long> myDelegate = n => p.Work(n);
A>

"p" от этого в замыкание попадает, поэтому direct не совсем direct получается.

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

A>Все равно Delegate быстрее...

А у меня наоборот.

Direct: 80635
Delegate: 114950
MyFunction: 78258
Delegate — Direct: 34315
MyFunction — Direct: -2377

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

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

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

A>>Все равно Delegate быстрее...
F>А у меня наоборот.

F>MyFunction — Direct: -2377[/q]
Это понятно, т.к. direct тут не совсем direct.

F>Делегат может быть быстрее.
За счет чего?

F>Но затраты на его создание, афаик, довольно большие.
Я его создаю за пределами цикла.
Сделал, чтоб создавалось каждый раз:

//...
for (int j = 0; j < N; j++)
{
    myDelegate = p.Work;
    myDelegate(1);
}
//...
for (int j = 0; j < N; j++)
{
    myFunction = new MyFunction(p);
    myFunction.Invoke(1);
}
//...

Результаты:

Direct: 65322
Delegate: 275326
MyFunction: 245319
Delegate — Direct: 210004
MyFunction — Direct: 179997

Да, создается заметно дольше.

F>В любом случае на таком микротесте понятно не будет. + разбор процессоров по всей видимости дают разные результаты.
А на каком будет понятно?

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

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

F>>Delegate — Direct: -2055
A>Ну давай, успокой общественность, найди в тесте ошибку.

A>У меня примерно те же числа при нескольких запусках.

Для direct дополнительно происходит копирование "p" в стеке. Видимо, этого оказалось достаточно, чтобы direct оказался медленнее.

Я обманул, x64 — это операционка, а сбилдил я под any cpu (забыв убрать Prefer 32, поэтому запускалось как WoW64).
Поменял на x64:
1.

Direct: 74636
Delegate: 72299
MyFunction: 72307
Delegate — Direct: -2337
MyFunction — Direct: -2329

2.
Если пересоздавать делегат и myFunction на каждой итерации:

Delegate: 372441
MyFunction: 296651

3.
Если не пересоздавать, но заменить делегат на "n => p.Work(n)"

Delegate: 109622
MyFunction: 74634

4.
Если при этом еще и пересоздавать на каждой итерации (делегат пересоздавать как "n => p.Work(n)"):

Delegate: 125970
MyFunction: 301498

В 4м случае, видимо, сработал оптимизатор и пересоздание выкинул, поэтому делегат сработал быстрее.
В 2м случае оптимизации не произожло, т.к. method group, а его (по спецификации) нельзя кэшировать.
3й результат ожидаем, хотя я думал, что различие будет более существенным.
1й результат показывает, что вызов method group работает со скоростью виртуального метода!

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

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

F>>>Делегат может быть быстрее.
A>>За счет чего?
F> За счет того, что никакого диспатчинга не происходит. Делегат — это this и массив готовых указателей на методы. Ну и их хорошенько оптимизировали в .net 2+, если память не изменяет.
Work — невиртуальный метод, никакого диспатчинга нет.
А оптимизируют с каждой новой версией .Net.
Возможно, уже имеет смысл переходить на делегаты в компиляторе. Т.е. утверждение, что делегаты тормознее перестает быть правдой...

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

I>Проект уже заморожен фактически.

Мечтать не вредно.

I>Почему меня интересует Немерле(в той части, что без макров) дело десятое.

Батхерт у тебя. Вот и бьешься ты в истошной боли.

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

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

I>>Проект уже заморожен фактически.

VD>Мечтать не вредно.

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

I>>Почему меня интересует Немерле(в той части, что без макров) дело десятое.

VD>Батхерт у тебя. Вот и бьешься ты в истошной боли.

Я вижу кому то батхерт мешает прочитать уже в который раз.

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

I>Я вижу кому то батхерт мешает прочитать уже в который раз.

Читать не чего особо. То что ты понаписал я прочел. Вывод один — батхерт и домыслы.

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

VD>>>Это чушь. На фрагментацию влияет количество перезоемов больших объектов и паттерн распределения памяти.

I>>Это факты.

VD>Факты в студию, плиз. Или не трепись по чем зря.

Факты простые — сборка и код генереный компилятором, лежат в менеджед хипах. Странно, да ? Сборка, по моему, лежит в GC Heap, код — в JIT Heap. Для GC, это просто хипы, как и LOH, Loader Heap, Fast, Slow, COM-Heap и тд и тд и тд. Он со всеми умеет работаеть, только сценарии меняются.
Нет никакой особой области памяти, куда загружаются сборки. Нужна память — создаётся новый хип, если в старом память закончилась.

>>>А для загрузки длл отводится соврешенно другая область памяти, которая никак не влияет на область памяти выделяемой под LOH.
I>>Чудеса, да и только.
VD>Учи матчасть.

Да, да, кое кому не мешает подучить матчать, а по после откровения "просто задай своим сборкам базовый адрес загрузки отличный от остальных. Это заметно повысит скорость загрузки, кстати." твои слова всерьёз невозможно воспринимать. Каждый школьник знает, что один только JIT съест весь профит. Но все даже хуже — даже без джыта профит сложно получить.

I>>Какая область памяти отводится, дело десятое. Главное что сборки жрут именно ту часть АП, которая может использоваться GC.
VD>Области резервируются при старте дотнета. Влиять на фрагментацию они не могут.

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

VD>Да и смешно говорить о влиянии на фрагментацию нескольких килобайт. Ты двумя занятыми массивами фрагментируешь LOH куда больше.

Десятки, как минимум, мегабайт, вдруг стали килобайтами ? Ну-ну.

I>>Дальше просто — вгружаешь сборки и, внезапно, когда количество и разным сборок сравнимо с количеством в реальном приложении, память почемуто начинается заканчиваться на планке 1гб+200мб. Все зависит естественно от способа расходования памяти.

VD>Вот, блин, удивительно, да? Если занять 100 мег чем-то другим, то 100 мег окажется недоступным. Только причем тут фрагментация?

Фрагментируется адрессное пространство. Сборки как раз уменьшают непрерывную область. А дальше хипы LOH кладутся как бог на душу положит.

VD>Если ты даже очень постараться немерловая сборка у тебя выйдет на 100 Кб больше аналогичной на шарпе. Это 100 Кб ты в микроскоп не заметишь. У IT вырожденный случай. Вызван он убогостью шарпа и нежеланием IT переписывать этот код (так как он объемный и работает). Если бы он писал код на Немерле изначально, то его сборка была бы не больше шарповской, а меньше, так как то что он эмулирует на лямбдах и делегатах можно было бы выразить макросами генерирующими эффективный низкоуровневый код.

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

I>>У меня >50мб исходного кода. Ты хорошо понимаешь, что это значит ?

VD>Ну, и? Они превратятся в ~50 длл-и. Объем занимаемой ими памяти один хрен не будет определяться размером ДЛЛ-и, а будет определяться объемом хранимых в памяти данных.

В том числе и размером самих ДЛЛ и размером генеренного джытом кода. Когда нужно большое окно в АП, все лишние помехи это фейл.

VD>Кроме того это косвенный показатель того, что ты используешь экстенсивные методы — пишешь код руками. У нас вот код еденицами метров измеряется, но это мета-код. Он порождает уже очень много эффективного кода. Но так как мы его генерируем мы можем плевать на абстракции, инкапсуляцию и прочие заморочки нежные для рукописного кода. В итоге получается эффективный код жрущий минимум ресурсов. В ручную ты это просто задолжаться делать.

А ты похоже не читатель.

VD>Короче тратить свое время на твое образование слишком расточительно. Все равно ты не слушаешь, а долдонишь одно и то же. Оставайся дальше упертым и ищи дальше фатальные недостатки в том, чего сам понять и освоить не можешь. Твои проблемы.

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

VD>Как правильно сказал НН, если бы тебя реально заботила эффективность генерируемого немерлом кода, ты примкнул бы к нам и помог проекту. За одно свой уровень поднял бы. А у тебя другая задача — срач устроить. Но это без меня.

Давай вместе посмотрим, от кого здесь аргументы навроде "баттхёрт" и прочих вещей, включая намёки на квалификацию и тд и тд и тд ?

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

I>Факты простые — сборка и код генереный компилятором, лежат в менеджед хипах. Странно, да ?

Не странно, а полная чушь. Сборки грузятся в память как и любые другие ДЛЛ-и в Виндовс — по средствам отображаемых в память файлов. Сборки дотнета не что иное как обычный PE (Portable Executabl) файл виндовс. Возьми любую свою сборку и отправь на http://pedump.me. Сам это увидишь. За в какую область памяти грузится ДЛЛ отвечает параметр компиляции /baseaddress. Если его не задавать, то высока вероятность колизий между сборками. При этом все кроме первой сборки будут сдвигаться загрузчиком ОС. При сдвижке занимается память в процессе. Но это не менеджед-память, а обычныая (выделяемая ВиртуалАлоком). Если же задать для ДЛЛ-ей /baseaddress (можно задать в настройках проекта шарпа, например), то сборки будут проецироваться в память процесса и разделяться всеми процессами загружающими эту бсору. На объем доступного процессу адресного пространства это влиять не должно, так как не зависимо от того разделяется длл или нет они все равно занимает память.

I>Сборка, по моему, лежит в GC Heap, код — в JIT Heap.

Ранайм фрэймворка — это анменеджед код. Он не может пользоваться управляемыми хипами. Где и как лежит сборка я описал выше. Джит используют свою память, но ты можешь воспользоваться NGEN-ом. Образы полученные с помощью NGEN подгружаются в процесс точно так же как и любые другие длл-и — поецированием файлов в память.

I>Для GC, это просто хипы, как и LOH, Loader Heap, Fast, Slow, COM-Heap и тд и тд и тд.

GC вообще ничего не знает о анменеджет-хипах. Учи матчасть. Все хипы используемые дотнетом размещаются в адресном пространстве процесса и занимаются через системные функции вроде VirtualAlloc и OpenPEFile. Но это все что их обоъеденяет.

I> Он со всеми умеет работаеть, только сценарии меняются.

Ошибаешься.

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

Ошибаешься. Хипы для этого не нужны. Точнее рантайм конечно размещает какие-то данные о типах из сборок в областях памяти отведенных под АппДомен. Но сами сборки грузятся проецированием файлов в память.

I>Сборками можно выюзать хоть всю память и при этом "Влиять на фрагментацию они не могут". Ты точно это хотел сказать ?\

Ау! Меня не слышат? Сборки, ну, кроме динамически подгружаемых, грузятся во время старта процесса. В это время для них выделяется адресное пространство. Выделяется системными (виндовыми) средствами. Далее оно не меняется. Влиять на фрагментацию LOH они не могут.

VD>>Да и смешно говорить о влиянии на фрагментацию нескольких килобайт. Ты двумя занятыми массивами фрагментируешь LOH куда больше.

I>Десятки, как минимум, мегабайт, вдруг стали килобайтами ? Ну-ну.

Какие, на фиг, десятки мегабайт? Чтобы получить сборку в десяток мегабайт нужно написать код в десятки мегабайт. Да и десятки мегабайт по сравнению с гигабйтами доступной памяти в микроскоп не различимы.

I>Фрагментируется адрессное пространство. Сборки как раз уменьшают непрерывную область. А дальше хипы LOH кладутся как бог на душу положит.

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

I>Макросы вдруг стали выдавать более компактный код. Похоже, тут пахнет нобелевкой

Похоже тут пахнет невежеством.

VD>>Ну, и? Они превратятся в ~50 длл-и. Объем занимаемой ими памяти один хрен не будет определяться размером ДЛЛ-и, а будет определяться объемом хранимых в памяти данных.

I>В том числе и размером самих ДЛЛ и размером генеренного джытом кода. Когда нужно большое окно в АП, все лишние помехи это фейл.

В том числе будет 0.001%.

И вообще, если у тебя проблемы с адресным пространством в 32-битном приложении, то перейди на 64-битный процесс или, если у тебя какие-то завязки на x86, задай при старте винды ключик позволяющий отдавать под пользовательские данные 3 гига и гиг будет в твоем распоряжении.

I>Давай вместе посмотрим, от кого здесь аргументы навроде "баттхёрт" и прочих вещей, включая намёки на квалификацию и тд и тд и тд ?

Это не аргумент, а констатация факта. Чем-то тебе очень сильно задел, то ли Немерл, то ли я.

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

A>Это что ж получается, вызов делегата почти в 2 раза быстрее вызова виртуального метода?

A>Кто-нибудь может объяснить случившееся?

У тебя промежуточный объект да еще и через поле зацепленный. Немерловые замыкания прослоек не используют.
Вот более достоверные тесты.
Немерл:

using System;
using System.Diagnostics;

module Program
{
  Main() : void
  {
    def timer = Stopwatch.StartNew();
    mutable x = 0;
    def f = () => x ++;
    while (x < int.MaxValue)
      f();
    WriteLine(timer.Elapsed);
    _ = ReadLine();
  }
}

C#:

using System;
using System.Diagnostics;

namespace PerfTestCs2
{
  class Program
  {
    static void Main(string[] args)
    {
      var timer = Stopwatch.StartNew();
      var x = 0;
      Action f = () => x++;
      while (x < int.MaxValue)
        f();
      Console.WriteLine(timer.Elapsed);
      Console.ReadLine();
    }
  }
}

Результаты на Intel Core i7-2670QM (процессор важен, так как в Core улучшены алгоритмы предсказания ветвления):

00:00:05.7368620 - Nemerle x86 .Net 4.0
00:00:05.3505237 - Nemerle x64 .Net 4.0
00:00:06.8788378 - C#      x86 .Net 4.0
00:00:06.8795763 - C#      x64 .Net 4.0

Итого Немерл немного быстрее, но разница не столь велика. В прошлых версиях фрэймворка разница была в разы.

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

F> А качество кодогенератора — да — надо улучшать. Откровенно лишние слоты в методах, излишние stloc/ldloc, когда всё должно быть совершенно просто на стёке. От этого тоже растёт объем сборки кстати,

На доли процентов.

F>и опять таки — не факт, что это JIT способен эффективно выбросить.

Факт. Выбрасывает. Иначе скорость немерловых алгоритмов была бы ниже. А она обычно даже выше получается.

F> А даже если он и может это выбросить — для JIT — это лишняя работа, а это в свою очередь тоже увеличивает startup time.

Ее опять же не видно в микроском. Если тебя трогает время джита, то используй NGEN.

А вот на замыкания время джита тратися сильно. По тому для больших немерловых сборок NGEN ощутимо ускоряет время загрузки.

F> PS: Ну, где не прав — не обезсудьте.

Тут вопрос цены и производительности. Конечно оптимизировать можно. Но и шарп не идеальный код генерирует. Ту вопрос сколько нужно вложить усилий и что получим в итоге. Мы много раз прикидывали и каждый раз забивали на оптимизации.

A>Кто-нибудь может объяснить случившееся?

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

using Nemerle.Collections;
using Nemerle.Text;
using Nemerle.Utility;

using System;
using System.Collections.Generic;
using System.Console;
using System.Diagnostics;
using System.Linq;

class Test
{
  public static Foo[T](x : T) : T
  {
    x
  }
}
module Program
{
  Main() : void
  {
    def timer = Stopwatch.StartNew();
    mutable x = 0;
    while (x < int.MaxValue)
    {
      def f = Test.Foo;
      x = f(x + 1);
    }
    WriteLine(timer.Elapsed);
    _ = ReadLine();
  }
}

Шарп:

using System;
using System.Diagnostics;

namespace PerfTestCs2
{
  class Test
  {
    public static T Foo<T>(T x)
    {
      return x;
    }
  }

  class Program
  {
    static void Main(string[] args)
    {
      var timer = Stopwatch.StartNew();
      var x = 0;
      while (x < int.MaxValue)
      {
        Func<int, int> f = Test.Foo;
        x = f(x + 1);
      }
      Console.WriteLine(timer.Elapsed);
      Console.ReadLine();
    }
  }
}

Результаты:

Nemerle: 00:00:05.3410730
C#:      00:00:22.2171454

А ты попробуй высосать проблему из пальца, как в данном случае. И не забудь упомянуть про фрагментацию LOH. Это важно.

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

I>Если для указаных проблем надо переписывать компилятор, то аргументы "присоединяйся", "сделай сам", "ждём Н2" как то неактуальны.

У твоей проблемы — небольшое превышение размеров сборок по сравнению с шарповскими в следствии того, что для функциональных объектов создаются классы переписвать весь компилятор не нужно. Но попахать нужно. И не мало. А вот бенефиты очевидны только тебе. Фрагментация LOH никого кроме тебя не волнует.

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

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

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

Собственно с тем, что SRE является проблемой я никогда не спорил. Если кто-то займется этой проблемой я буду только рад. У меня лично такой потребности нет. Зато есть куча более приоритетной работы. У Хардкейса, который как раз занимался переводом Немерла на бэкэнды, тоже работы выше крыши. Так что в ближайшее время он за бэкэнды вряд ли сядет.

Если кто-то хочет этой задачей заняться, мы с радостью скажем куда и как лучше копать.

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

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

IT>Вы же всё позакрывали и всех послали. Как тут можно помочь?

Не надо передергивать. Мы никого никуда не посылали. Все что я тебе сказал — ты заблуждаешся говоря о качестве кодогенерации кода для ПМ. И что проблема в другом. То что проблема есть тоже никто не спорит. Вопрос только в ее актуальности. Для всех пока что она была не актуальна.

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

Рост размеров вызван генерацией классов. Решение это архитектурное и просто так от него не избавиться. Кроме того от этого и бенефиты есть.

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

I>Похоже это хроническое заболевание у немерлистов, не могут прочесть, что речь про мой проект, это он заморожен.

А из каких слов можно вывести, что речь идет о каком-то своем проекте?

I>Я вижу кому то батхерт мешает прочитать уже в который раз.

Что прочитать то?

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

I>>Похоже это хроническое заболевание у немерлистов, не могут прочесть, что речь про мой проект, это он заморожен.

VD>А из каких слов можно вывести, что речь идет о каком-то своем проекте?

Если читать ветку, а не отдельные сообщения, то вполне понятно.

I>>Я вижу кому то батхерт мешает прочитать уже в который раз.

VD>Что прочитать то?

Сильное ощущение, что ты тыкаешь наобум в первое попавшееся сообщение и чтото пишешь.

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

VD>Не странно, а полная чушь. Сборки грузятся в память как и любые другие ДЛЛ-и в Виндовс — по средствам отображаемых в память файлов. Сборки дотнета не что иное как обычный PE (Portable Executabl) файл виндовс. Возьми любую свою сборку и отправь на http://pedump.me. Сам это увидишь. За в какую область памяти грузится ДЛЛ отвечает параметр компиляции /baseaddress. Если его не задавать, то высока вероятность колизий между сборками. При этом все кроме первой сборки будут сдвигаться загрузчиком ОС. При сдвижке занимается память в процессе. Но это не менеджед-память, а обычныая (выделяемая ВиртуалАлоком). Если же задать для ДЛЛ-ей /baseaddress (можно задать в настройках проекта шарпа, например), то сборки будут проецироваться в память процесса и разделяться всеми процессами загружающими эту бсору. На объем доступного процессу адресного пространства это влиять не должно, так как не зависимо от того разделяется длл или нет они все равно занимает память.

Этими сведениями для менеджед сборок можно пренебречь.

I>>Сборка, по моему, лежит в GC Heap, код — в JIT Heap.

VD>Ранайм фрэймворка — это анменеджед код. Он не может пользоваться управляемыми хипами. Где и как лежит сборка я описал выше. Джит используют свою память, но ты можешь воспользоваться NGEN-ом. Образы полученные с помощью NGEN подгружаются в процесс точно так же как и любые другие длл-и — поецированием файлов в память.

А кто говорил про ngen ?

I>>Для GC, это просто хипы, как и LOH, Loader Heap, Fast, Slow, COM-Heap и тд и тд и тд.

VD>GC вообще ничего не знает о анменеджет-хипах.

Который из хипов выше анменеджед ?

I>>Сборками можно выюзать хоть всю память и при этом "Влиять на фрагментацию они не могут". Ты точно это хотел сказать ?\

VD>Ау! Меня не слышат? Сборки, ну, кроме динамически подгружаемых, грузятся во время старта процесса. В это время для них выделяется адресное пространство. Выделяется системными (виндовыми) средствами. Далее оно не меняется. Влиять на фрагментацию LOH они не могут.

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

I>>Десятки, как минимум, мегабайт, вдруг стали килобайтами ? Ну-ну.

VD>Какие, на фиг, десятки мегабайт? Чтобы получить сборку в десяток мегабайт нужно написать код в десятки мегабайт. Да и десятки мегабайт по сравнению с гигабйтами доступной памяти в микроскоп не различимы.

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

I>>Фрагментируется адрессное пространство. Сборки как раз уменьшают непрерывную область. А дальше хипы LOH кладутся как бог на душу положит.

VD>Внимание, вопрос. Если сборки грузятся практически одновременно во время загрузки приложения, то как они могу влиять на фрагментацию того, что занимается после этого?

"если" это ты притягиваешь за уши нужный тебе результат. Но вообще могут — картина распределения меняется и хипы GC и Loh распределяются совершенно иначе.

I>>Макросы вдруг стали выдавать более компактный код. Похоже, тут пахнет нобелевкой

VD>Похоже тут пахнет невежеством.

Вот-вот. Подумай над этим.

VD>>>Ну, и? Они превратятся в ~50 длл-и. Объем занимаемой ими памяти один хрен не будет определяться размером ДЛЛ-и, а будет определяться объемом хранимых в памяти данных.
I>>В том числе и размером самих ДЛЛ и размером генеренного джытом кода. Когда нужно большое окно в АП, все лишние помехи это фейл.

VD>В том числе будет 0.001%.

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

VD>И вообще, если у тебя проблемы с адресным пространством в 32-битном приложении, то перейди на 64-битный процесс или, если у тебя какие-то завязки на x86, задай при старте винды ключик позволяющий отдавать под пользовательские данные 3 гига и гиг будет в твоем распоряжении.

Спасибо, капитан(уже наверное майор). Такие решения уже отработаны.

I>>Давай вместе посмотрим, от кого здесь аргументы навроде "баттхёрт" и прочих вещей, включая намёки на квалификацию и тд и тд и тд ?

VD>Это не аргумент, а констатация факта. Чем-то тебе очень сильно задел, то ли Немерл, то ли я.

Правильно, констатация факта, пересмотри свои сообщения и забань виновного, как Кочетков

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

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

F>>>>>Делегат может быть быстрее.
A>>>>За счет чего?
F>>> За счет того, что никакого диспатчинга не происходит. Делегат — это this и массив готовых указателей на методы. Ну и их хорошенько оптимизировали в .net 2+, если память не изменяет.
A>>Work — невиртуальный метод, никакого диспатчинга нет.
F> Function.Invoke — виртуальный.

Я имел ввиду "за счет чего он может быть быстрее прямого вызова невиртуального Work?". Ну да и фиг с ним...

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

A>Я имел ввиду "за счет чего он может быть быстрее прямого вызова невиртуального Work?". Ну да и фиг с ним...
Писал-писал сообщение и прошляпил его. В общем — мы просто недопоняли друг друга. Я конечно же имел ввиду, по сравнению с виртуальным конечно же, в контексте обсуждения — других у нас нет, а в тест незасматривался.
Instance Call — требует 1 обращение к памяти (проверка this на null)
Delegate Call — требует 2 обращения к памяти (загрузка this из делегата и косвенный вызов, проверка адреса делегата на null — достаётся бесплатно)
Virtual Call — требует 3 обращений (получение описателя типа из this, получение таблицы методов из описателя типа, косвенный вызов, проверка this на null — достаётся бесплатно)
Учитывая, что даже 3x накладые расходы толком то рассмотреть не получается даже в микроскоп (с помощью тех же тестов) — подозреваю, что основная стоимость вызова лежит в инструкциях call/jmp. Хотя для тех у кого узкое место — память и малый кеш — возможно разница будет ощутимее, хотя обычно в таких ситуациях бранчинг тоже не блещет.
Иногда, кстати, микробенчи показывают, что виртуальный вызов быстрее остальных в два раза (я такого легко добивался, перемещением кода циклов вверх-вниз относительно друг друга).

Именно это и показывает несостоятельность подобного бенчмаркинга (в отрыве от задачи).

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

A>Я имел ввиду "за счет чего он может быть быстрее прямого вызова невиртуального Work?". Ну да и фиг с ним...

Какой-то косяк в тесте. Исходные тесты имеют сразу несколько скользких мест. Я бы на них не обращал внимание. Не вертуальные примитивные метода вообще инлайнятся. Так что там измерять просто не чего.

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

F> Delegate Call — требует 2 обращения к памяти (загрузка this из делегата и косвенный вызов, проверка адреса делегата на null — достаётся бесплатно)

Это очень поверхностная теория. Реально ссылка лежит на мультикаст-делегат. Это весма сложная штука. МС что-то там оптимизирует и (видимо) заменяет мультикаст на что-то другое. Это само по себе требует времени. Так что в случае вызова где делегат создается за нова — это отнюдь не дешево. Далее кэшируется все тоже не так просто (скорее всего) как ты говоришь.

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

F> Virtual Call — требует 3 обращений (получение описателя типа из this, получение таблицы методов из описателя типа, косвенный вызов, проверка this на null — достаётся бесплатно)

Это точно не верно. Таблица методов получается из объекта непосредственно. А нужны метод просто ее индексированием. Так что это налогично доступу к неуправляемому массиву. А учитывая инструкции современных проецессоров и предсказание ветвления ими это можно зачесть за одну операцию (для Core+). Подробности здесь.

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

Именно это и показывает несостоятельность подобного бенчмаркинга (в отрыве от задачи).

Зачем разбирать детали вызовов, если в итоге вывод на этом не строится?

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

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

F>> Delegate Call — требует 2 обращения к памяти (загрузка this из делегата и косвенный вызов, проверка адреса делегата на null — достаётся бесплатно)
VD>Это очень поверхностная теория. Реально ссылка лежит на мультикаст-делегат. Это весма сложная штука. МС что-то там оптимизирует и (видимо) заменяет мультикаст на что-то другое. Это само по себе требует времени. Так что в случае вызова где делегат создается за нова — это отнюдь не дешево. Далее кэшируется все тоже не так просто (скорее всего) как ты говоришь.
Понятно что в целом оно поверхностно. Но конкретно это вроде как и не поверхностная теория. Там (внутри мультикаст делегата) лежит this и адрес метода который вызывается готовым кодом. Буквально две инструкции на ассемблере. Да, CLR использует fastcall для вызова методов, а не магию.

Соотв., если это single-cast — достаточно в адрес положить реально адрес метода, который указывает делегат.
Если multi-cast — тогда он указывает на некий трамплин, который сделает всё грязное дело.
Суть в том, что заточка под single-cast она действительно есть, но она — очень простая на самом деле и по своей сути.

VD>Если хочешь разобраться, нужно декомпилять в ассемблер релизные машкоды и разбираться с ними. Причем делать это как в области создания делегата, так и в области вызова. Ну, и разные случаи рассматривать. Я вот тут рядом показывал как просаживается производительность делегатов когда делаешь делегат на обобщенный статический метод. Там явно какая-то хмия.
Создание делегата на джерениках — намного медленнее — это вроде как давно известная штука. Я не буду строить догадок — мне неинтересно это. В добавок тут я уже упоминал, что не факт что создание делегатов vs классов-функторов будет быстрее. Я не знаю как это проверить, а чистая теория именно про этот момент — не интересна.

VD>Это точно не верно. Таблица методов получается из объекта непосредственно. А нужны метод просто ее индексированием. Так что это налогично доступу к неуправляемому массиву. А учитывая инструкции современных проецессоров и предсказание ветвления ими это можно зачесть за одну операцию (для Core+). Подробности здесь.
Да... Смотрел как раз и на дизассемблер, и документацию, и жестоко затупил.

Спасибо.
Ну тогда получается ещё лучше — и виртуальный вызов и делегат — оба потребуют только двойную косвенность. Хотя в случае с делегатом — там чтение из одной линейки кеша скорее всего происходит (по адресам — два поля рядышком).

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

Именно это и показывает несостоятельность подобного бенчмаркинга (в отрыве от задачи).
VD>Зачем разбирать детали вызовов, если в итоге вывод на этом не строится?

Нет, это значит, что стоимость вызовов — существует, они не бесплатны. Но простыми циклами мы её никак за хвост не схватим. Я описанное наблюдал на бенчмарке не приведенном здесь, но суть приблизительно та же — т.е. в топку.

	От:	Аноним
	Дата:	30.07.13 17:19
	Оценка:	-2

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	08.08.13 12:16
Оценка:	-1

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	09.08.13 18:51
Оценка:	+1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	12.08.13 12:30
Оценка:	-2

	От:	fddima
	Дата:	13.08.13 13:12
	Оценка:	+2

От:	VladD2	www.nemerle.org
Дата:	17.08.13 10:58
Оценка:	-1

От:	_NN_	www.nemerleweb.com
Дата:	12.08.13 12:50
Оценка:	+1

От:	IT	linq2db.com
Дата:	31.07.13 00:07
Оценка:

	От:	catbert
	Дата:	31.07.13 14:21
	Оценка:

От:	IT	linq2db.com
Дата:	31.07.13 23:38
Оценка:

От:	IT	linq2db.com
Дата:	01.08.13 23:39
Оценка: