Re[36]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: _NN_ www.nemerleweb.com
Дата: 14.08.13 10:47
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


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


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

А где написано что мешает ?
Кроме жалоб на размер лямбд я так и не понял что конкретно мешает
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[35]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: hi_octane Беларусь  
Дата: 14.08.13 12:05
Оценка:
_NN>Подружить Resharper (другой инструмент) с Nemerle конечно не получится без содействия с jetBrains (другим инструментом), хотя думаю это и так понятно.

В случае с Resharper вполне может получиться. У Resharper достаточно открытая архитектура, можно подцепить свой языковой плагин и как минимум навигация, всякие find usages и другие простые штуки заведутся. В SDK и в паблике есть несколько примеров языков с навигацией, и первые шаги с Nemerle идут довольно легко. У меня были экспериментальные попытки на эту тему. Но до стадии "можно что-то показать" не дошло — вылезает куча пустой работы из-за того что внутренний фреймворк решарпера заточен на выхлоп их генератора парсеров.
Re[37]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 14.08.13 12:57
Оценка:
Здравствуйте, _NN_, Вы писали:

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

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

http://www.rsdn.ru/forum/nemerle/4855827.1
Автор: fddima
Дата: 15.08.12


Неконтролируемые зависимости, непрозрачный выхлоп компилятора, размер сборок, функциональные типы идентичные стандартным дотнетовским, отсутствие поддержки полной версии языка, который могут выдавать всякие недо-,полу-, Üбер-визарды и прочие генераторы, т.к. переписать такой код нет никакой возможности.
Re[38]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: fddima  
Дата: 14.08.13 13:22
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>http://www.rsdn.ru/forum/nemerle/4855827.1
Автор: fddima
Дата: 15.08.12

I>Неконтролируемые зависимости, непрозрачный выхлоп компилятора, размер сборок, функциональные типы идентичные стандартным дотнетовским, отсутствие поддержки полной версии языка, который могут выдавать всякие недо-,полу-, Üбер-визарды и прочие генераторы, т.к. переписать такой код нет никакой возможности.
Ээээ... это были мои единоразовые хотелки, когда основная масса возможностей N — не требуется. Т.е. эдакий C# в синтаксисе N.
В остальном у меня положительный опыт с N. Улучшать там есть чего и много, но и то, что уже есть — можно успешно использовать.
Re[39]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 14.08.13 14:33
Оценка:
Здравствуйте, fddima, Вы писали:

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

F>Ээээ... это были мои единоразовые хотелки, когда основная масса возможностей N — не требуется. Т.е. эдакий C# в синтаксисе N.

У меня ровно то же, только это все обязательно в моем случае
Re[40]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: _NN_ www.nemerleweb.com
Дата: 14.08.13 14:58
Оценка:
Здравствуйте, 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-м объединить в одну сборку.
Есть идеи лучше ?

В любом случае кто-то должен будет это сделать, а если некому, то это не случится.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[41]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: artelk  
Дата: 14.08.13 16:03
Оценка:
Здравствуйте, _NN_, Вы писали:

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

Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов.
Re[42]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: _NN_ www.nemerleweb.com
Дата: 14.08.13 16:52
Оценка:
Здравствуйте, artelk, Вы писали:

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


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

A>Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов.

А какая причина ?
Скорость ?
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[19]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.13 18:09
Оценка:
Здравствуйте, IT, Вы писали:

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


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


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

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


А что тут не адекватного? Человек пришел на технический форум явно с целью устроить флэйм, а не разбираться с техническими вопросами. Если бы сам в него не влез давно бы забанил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.13 18:18
Оценка:
Здравствуйте, IT, Вы писали:

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


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


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

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

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

Если тебя волнует эта проблема, то лучше бы помог выявить ее реальные причины, а то и помочь их устранить. НН вот сделал полезное дело и подтвердил мои предположения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: artelk  
Дата: 14.08.13 19:44
Оценка:
Здравствуйте, _NN_, Вы писали:

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


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


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

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

Да. Вызов виртуального метода (который может еще и инлайниться JITом, если фактический тип известен) заметно быстрее вызова делегата.
Если есть основания, что в последнем фреймворке это уже не так, просьба показать.
Re[44]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: _NN_ www.nemerleweb.com
Дата: 14.08.13 19:49
Оценка:
Здравствуйте, 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 то карринга нет.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[22]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.08.13 12:20
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


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

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


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

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

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

В любом случае на фоне гига даже мегабайтная сборка — это 0.1%. Она рояли не играет. Чтобы создать мегабайтную сборку нужно не один мег исходников наколбасить. А ты намеренно пытаешься сделать из мухи слона.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.08.13 13:37
Оценка:
Здравствуйте, 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мб исходного кода. Ты хорошо понимаешь, что это значит ?
Re[45]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: artelk  
Дата: 15.08.13 14:07
Оценка:
Здравствуйте, _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 раза быстрее вызова виртуального метода?
Кто-нибудь может объяснить случившееся?
Re[46]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: fddima  
Дата: 15.08.13 14:24
Оценка:
Здравствуйте, artelk, Вы писали:

i3-3220, net45, x64, release:

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

Re[46]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: artelk  
Дата: 15.08.13 14:25
Оценка:
Здравствуйте, 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 быстрее...
Re[47]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: artelk  
Дата: 15.08.13 14:36
Оценка:
Здравствуйте, fddima, Вы писали:

F>Delegate — Direct: -2055

Ну давай, успокой общественность, найди в тесте ошибку.
У меня примерно те же числа при нескольких запусках.
Re[47]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: artelk  
Дата: 15.08.13 14:37
Оценка:
Здравствуйте, artelk, Вы писали:

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

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


"p" от этого в замыкание попадает, поэтому direct не совсем direct получается.
Re[47]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
От: fddima  
Дата: 15.08.13 14:38
Оценка:
Здравствуйте, artelk, Вы писали:

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


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

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


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