Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Ты плохо понимаешь масштаб цифр. Вот замеры для итераций N = 1 млрд , в секундах, приблизительно, проц и7 примерно 2500гц под рукой профайлера нет I>>пустая итерация 2 сек (числа ниже получены вычетом этого значения из реального замера) I>>инстанцирование лямбд 2.5 сек + итерация I>>инстанцирование с вызовом лямбды 7 сек + итерация I>>вызов метода 2 сек + итерация I>>итерация по массиву лямбд с вызовом 5 сек + итерация I>>итерация по массиву вызовом метода 2.5 сек + итерация I>>итерация через итератор лямбд с вызовом 10 сек + итерация I>>итерация через итератор вызовом метода 8 сек + итерация
EP>Это какой-то простой код с выключенным оптимизатором?
Да, простой код. точность примерно пол-секунды. Позволяет внятно оценить масштаб .net vs .net
Re[23]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
I>>Это очевидно. Вопрос в издержках в пересчете на системные ресурсы и время пользователя.
VD>У спинов издержки близкие к нулю.
Спасибо, капитан.
I>>Лямбда это не самая проблемная вещь в плане перформанса.
VD>Сама, не самая — не играет рояли. Факт в том, что выши костыли порождают такие затраты повсеместно.
Вообще то имеет значение. Что бы лямбда стала узким местом это _очень_ редкий случай.
I>>Самые проблемные вещи в перформансе I>>0. кривые алгоритмы и структуры данных, включая встроеные во фремворк
VD>Одно другого не искючает. Реализация примитивов через лямбды замедляет кривые алгоритмы еще больше.
1 исправление алгоритма даёт на порядки больше профита, нежели приседания с лямбдами
2 приседания с лямбдами не отменяют исправление алгоритма
VD>Если алгоритмы оптимальны, то кроме как убрать константу ничего другого сделать и нельзя. А хороший программист, все таки, старается использовать подходящие алгоритмы.
И для чего эти общие слова ?
I>>1. неправильное кеширование, например из за write barrier
VD>Это частный случай пункта 0.
Разумеется, я перечисляю все частные случаи, при чем в порядке убывания веса. Все случаи что я перечислил, создают бОльшие проблемы нежели лямбды
I>>2. ленивый код итераторов, генераторов
VD>Это та самая константа которую можно убирать макросами.
Заметь — она дает влияние гораздо большее, нежели лямбды.
I>>3. неэффективный расход памяти, например конское количество объектов в Gen2 или туча фрагментации
VD>Опять же следствие. И опять же макры позволяют его лечить. Пишем генератор код. Описываем задачи на ДСЛ. Генерируем для них оптимальный код. Можно копипастить и плевать на все правила программирования, так как код абстрагируется за счет генерации.
Ты не отвлекайся — речь была про лямбды.
I>>4. боксинг-анбоксинг VD>Следствие ручного кодирования однотипных операций. Опять же лечится маросами.
Тем не менее это бОльшая проблема, нежели лямбды.
I>>Ты плохо понимаешь масштаб цифр. Вот замеры для итераций N = 1 млрд , в секундах, приблизительно, проц и7 примерно 2500гц под рукой профайлера нет
VD>Ты нашел кого учить.
Сильное ощущение что ты профайлер раз в год запускаешь
I>>Создание лямбды быть хуже, если много всего замыкается за раз, но не сильно.
VD>Я тут уже много раз повторял. Пример из реальной жизни. В ДжетБрэйнсе специально вычищали Линк из кода, так как он давал тормоза. А ты все какую-то синтетичекую финю рассматриваешь.
Ты линк в профайлере никогда не видел. Основной профит дает устранение энумераторов.
VD>Когда перейдешь на следующий уровень (если перейдешь), то поймешь, что измерять тоже нужно с умом. И что от синтетических тестов обычно мало толку. В них легко неучесть разных факторов. Например, того фактора, что лямбды пораждают развесистые иерархии объектов, которые, будучи созданные в больших обемах негативно влияют на ЖЦ.
Итераторы всё равно больше проблем создают, в них иерархии намного больше и тяжелее.
I>>См выше — отказ от лямбд дает тебе от силы удвоение пропускной способности в самом идеальном случае — когда лямбда ничего не делает
VD>Это дилетантские рассуждения. Если, например, запихать создание лябмд в процесс парсинга, то его легко замедлить до неприемлемых значений.
А если ты линк всунешь в свой парсинг, то будет на порядок хуже чем с лямбдами.
Re[13]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
I>>Не фичами, а конструкцию пересмотрели.
VD>Это и есть фичи.
Это _не_ фичи. Это конструктивные особнности. Фича, это когда ты в грузовой отсек кресел напихал. А если изменилась несущая конструкция это уже не фича, принципиально иное решение.
Re[14]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
VD>>Причем не случится именно из-за таких как вы, хаящих все в чем не смогли разобраться и закидывающих дерьмом всех кто пытается приблизить прогресс.
EP>Где я хаял или закидывал Nemerle?
Он всех, кто с ним не согласен, записывает во враги народа. А ты практически преступление совершил — "Нужен будет .NET — ... На данный же момент мне важна скорость, кроссплатформенность и некоторые нативные библиотеки."
Здравствуйте, Ikemefula, Вы писали:
EP>>Это какой-то простой код с выключенным оптимизатором? I>Да, простой код. точность примерно пол-секунды. Позволяет внятно оценить масштаб .net vs .net
Казалось бы, хотя бы на простых примерах оптимизатор должен был увидеть что к чему, заинлайнить и проаннигилировать лишнее. Семантика ведь позволяет это сделать, что мешает?
Re[23]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Макросы же позволяют генерировать любой код. В том числе и без лямбды и прочего оверхэда. Наши парсеры содержат код в стиле старого доброго С. Только функции и простые аргументы. И за этом мы не платим говногодом, так как говнокод генерируется по простым шаблонам. Мы же 100% времени заняты теми самыми алгоритмами.
А в чем был посыл ?
Если скорость работы С# не устраивает, то переходят не на Nemerle, а на Си, разве не так ?
Re[25]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Ikemefula, Вы писали:
EP>>>Это какой-то простой код с выключенным оптимизатором? I>>Да, простой код. точность примерно пол-секунды. Позволяет внятно оценить масштаб .net vs .net
EP>Казалось бы, хотя бы на простых примерах оптимизатор должен был увидеть что к чему, заинлайнить и проаннигилировать лишнее. Семантика ведь позволяет это сделать, что мешает?
Скорей всего компиляция в Debug
Re[26]: Nemerle через 5 лет - выстрелит или скончается?
К>>>Я этого не делаю: всегда можно что-то придумать (например generics, reflection, functional programming, на худой конец T4) и написать этот кусок только один раз. _>>foreach{} else{} — давай, придумывай К>Вот готовый http://www-jo.se/f.pfleger/.net-for-else но мне никогда не было нужно такого.
Естественно. Городить вложенные лямбды со всеми спецэффектами захвата — в таком виде оно никому не нужно, очевидно что и тебе тоже Ты, кстати, уверен что эта поделка сработает на всех тех же сценариях на которых сработает foreach else из Nemerle? Ты понимаешь что мы сейчас обсуждаем не фичу Nemerle как языка программирования, а один единственный, простейший макрос, который в случае надобности под проект на ходу пишется?
_>>Я тоже настоящий сварщик Но выбирая compile-time или runtime в C++ нужно иметь очень веские основания чтобы выбрать второе. К>В С++ конечно, но в C# уже не так однозначно, т.к. runtime намного более годный.
Если бы в C# компайл-тайм был реально годный, никто в runtime не лез бы. Но с трэндом в .NET Native и выходом roslyn мы ещё увидим ренессанс compile-time.
К>Но нужно бывает редко, потому что рефлексия + функциональщина; я например могу по пальцам одной руки пересчитать написанные за карьеру T4 templates, а reflection постоянно использую для разного.
А я к чему и веду?
К>>>Разницу в том, что nemerle наколеночное поделие, а за рослиным стоит лидер индустрии разработки ПО?
Так это проблема лидера индустрии что они оказались не в состоянии найти людей способных написать модульный компилятор с минимальным микроядром в своей основе Кстати, внезапно, в исходниках roslyn я снова вижу хардкод фич поштучно. Интересно, если Nitra таки их уделает в хлам, они будут 1)догонять по фичам поштучно 2)снова переписывать, или 3)купят JB?
К>>>Со всеми вытекающими обстоятельствами про качество реализации, качество и объем поддержки, маркетинг и обучение разработчиков? _>>А причём тут объём поддержки и обучение разработчиков? К>При том, что продукт это не только исходный код который компилируется, это ещё и поддержка, и обучение пользователей, и сообщество.
Подожди. У тебя была проблема — ты не видел "преимущества в человеко-часах одного перед другим"
. С точки зрения программиста — человека который пишет код, это преимущество линейно зависит от того сколько кода писать _не_надо_ для получения хотя-бы аналогичного решения. И там и там мы видим компиляторы. Причём один может больше чем другой. У обоих исходники открыты, объём писанины сравнить можно. Переводя стрелки на какое-то обучение, маркетинг, и некий объём, ты сейчас с темы спрыгиваешь, или как это понимать?
К>Кстати про сообщество: на SO два вопроса с тегом nemerle. Для сравнения, там 500 вопросов с тегом clojure, 4000 вопросов с тегом scala, и 140’000 вопросов с тегом C#. Даже безотносительно вопроса «почему так мало», это говорит о том, что если у меня возникнут по нему вопросы, в мире найдутся очень немного людей, способных мне помочь.
Я принимаю вызов! Там 250 000 вопросов по jquery, и темп появления новых такой, что скоро C# обойдут ровно в 2 раза. Такой рост, за каких-то 7 лет, при том что за ней вроде не замечено гиганта типа MS, говорит о том что тебе пора срочно бросать C# и переводить все проекты на чистый jquery! А также, полагаю, о никудышном качестве ПО, маркетинге, и обучении MS! Может больше денег в C# вкладывать надо?
А если серьёзно — то, имхо, чем более продвинутая относительно среднего уровная штука, тем меньше по ней вопросов на SO. SO — это выражение проблем джуниоров. Поверь, когда джуниоры навалятся на штуковину уровня Nemerle, профессионалы будут уже гораздо дальше.
Re[13]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
EP>>Язык программирования для корпоративных информационных систем, опердней и всего подобного. Некоторые руководствующие принципы: VD>Во-первых, какая же это концепция? Или ты предназначение под концепцией понимаешь?
Пусть будет предназначение. Из предназначения вытекает концепция, хотя бы частично.
VD>Во-вторых, это ошибочное утверждение. Никаких специальных для оперденей фич в Шарпе нет. И Шарп вполне успешно используют для вполне себе системного программирования. Примеры? Их есть у меня (ц):
Я сужу по тем фичам, которые в него добавляют, и с которыми носятся больше всего — например linq (по крайней мере "основное" его предназначение).
Символично высказывание которое всплывает практически в каждом холиваре — "это экономия на спичках, в реальности всё базу упирается", оно хорошо характеризует основную аудиторию — разве нет?
VD>Так что C# — это высокоуровневый язык общего назначений. Для опердени он предназначен ни чуть не меньтше, чем для написания компиляторов.
Это то как вижу я — корпоративные системы это драйвер развития, а остальное — побочные эффекты. Я же сказал — если кто знает официальные цели и идеи — цитата не будет лишней.
Например, те же опердни можно писать и на C++, и что характерно некоторые и пишут — но основное предназначение у него другое.
EP>>* надёжность и безопасность важнее скорости. VD>Спорное утвеждение. Но раз ты так считаешь про Шарп, значит то же можно утверждать про немерл. Хотя, почему-то Решарпер вполне себе быстро работает на будтчи написанным на Шарпе, а Сингулярити работает на со скоростью сравнимой со скоростью ОС написанных на С.
Во-первых, то что какая-то программа не испытывает проблем со скоростью, отнюдь не говорит о том, что язык даёт большую скорость. (мини-числодробилки можно и на динамическом языке без проблем писать)
Во-вторых, и на Java можно выкручиваться и делать быстрый код, только в этом случае язык будет работать против тебя. Например, из-за отсутствия структур приходится левой пяткой правое ухо чесать раскладывать вручную данные по массивам байт. Но да — зато код получается быстрый.
Да и далеко ходить не надо — даже в этой теме обсуждается какие же лямбды тормозные (хотя в C++ они фактически бесплатны).
BC>Если скорость работы С# не устраивает, то переходят не на Nemerle, а на Си, разве не так ?
Макросы это вообще-то про генерацию кода. Почему не генерировать код на Си из выскоуровневого кода на Nemerle? Вот есть такой проект NUDA, там в качестве примера, вычисления написанные на Nemerle выполняются на GPU, так что ничего невозможного нет.
Re[4]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Ну, что бредить то? Лагины IDE для скалы глючат много лет.
Хамить не надо. Все в мире глючит. В эклипсе Скала рабочая уже пару лет как. Люди никак не связанные с Одерски пишут на ней серьезные вещи в серьезных конторах.
VD>JetBrains посчитав Скалу очень сложной начал пилить свою лайт-версию — Котлин.
Сам от Скалы не в восторге, но это же не повод становиться страусом.
VD>Но это не значит, что кто-то там труп. VD>Вот тебя в этом мире тоже никто не знает и никто про тебя кричит. Но это же не значит, что ты труп?
Тут одно из трех:
а) у тебя отсутствует контекстное понимание слова "труп"
б) ты в привычной манере хамишь с переходом на личности
c) находишься в глубоком отказе
N>>В Скале сейчас есть все что есть в N плюс кроссплатформа и IDE-support. VD>Дык и в Немерле есть все что есть в Скале и поддержка IDE.
смотри c) ^
VD>Кроссплатформенность это хорошо.
Это не хорошо, а абсолютно необходимо для популяризации языка, если у тебя нет контроля над платформой и бюджетов сопоставимых с MS/Apple.
VD>В будущем мы тоже хотели бы ее сделать. Причем не на базе явы, а более общий вариант. И не только для Немерла, а для всех языков поднятых на базе Nitra.
Дерзайте, тогда и поговорим.
Re[6]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Все тоже саме. Есть Ди, Раст, Го.
Их никто не использует, кроме их авторов.
VD>Да и домыслы о том, что дотнет или ява не подходят для "системного программирования" — всего лишь домыслы.
Очень хочется пофлудить про Сингулярити? Нет, спасибо.
VD>На фоне Шарп, Ява, С++ эти языки имеют популярность близкую к плинтусу.
Как и на фоне Кобола, но мы вроде говорим за Немерле и Скалу. На фоне Скалы Немерле не видно даже в микроскоп.
VD>Были всплески, но они прошли.
Всплеск Скалы идет именно сейчас.
Re[6]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Дык Моно на нем тоже работает.
Дык само Моно никто не использует.
VD>Кроме того сейчас популярны облока, а с ними в дотнете все ОК.
Облако оно тем и хорошо, что платформу, как она есть, можно в него переместить. Платформу менять — адь. Делать это ради Н — глупость.
Re[5]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Это какой-то простой код с выключенным оптимизатором? I>>Да, простой код. точность примерно пол-секунды. Позволяет внятно оценить масштаб .net vs .net
EP>Казалось бы, хотя бы на простых примерах оптимизатор должен был увидеть что к чему, заинлайнить и проаннигилировать лишнее. Семантика ведь позволяет это сделать, что мешает?
Мешает политика руководства и говённый джит как следствие. До смешного доходит — кое что уже можно сварганить на джаваскрипте и это будет быстрее работать.
Re[5]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Alexey.Maletin, Вы писали:
AM>>Крупные коммерческие конторы используют скалу основным языком (из русских Тинькофф, например).
VD>С какого перепугу Тинькофф стал "крупной коммерческой конторой"?
ТКС-то не крупная? Ну не знаю. Загляни в вики, что-ле. Оборот и собственный капитал вполне себе и почти 7000 сотрудников.
Хотя куда им до команды немерле.
AM>>Тонны жаба кода переписывалась на скалу.
VD>Этому есть подтверждение?
Пардоньте, не только с жабы, но и с других языков/платформ. С руби, например, или питона.
Из крупных — библиотеки твиттера. Мелочь гуглится и её очень много.
Я думаю, ты слишком воинственно настроен. Я нисколько не хотел наезжать на немерле, только указал, на чужой опыт, которым можно было бы воспользоваться. Почему такое отрицание — яростное, немотивированное? С таким подходом, далеко не уедете.
Re[15]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
EP>>Где я хаял или закидывал Nemerle? VD>А здесь ты чем занимаешься?
Задал вопрос, на который не нашёл ответа на сайте
VD>Собственно если тебя интерсуют Плюсы, то можешь попробовать использовать Натйру для реализации кодогенерации для плюсов. Тоже интересное направление.
Есть задача сгенерировать определённый код из схемы (допустим из .xml), причём результирующий код не только на C++.
Насколько я понимаю, Nemerle/Nitra в этом контексте может использоваться как парсер схемы на компактном и удобном DSL (вместо .xml), плюс шаблонизатор (свой DSL для шаблонов), и соответственно генератор кода. Из плюшек, как я понимаю — автоматическая интеграция DSL'ей (схемы и шаблонов) в IDE, так?
Может есть какие-то другие сценарии применения для данного контекста?
Re[16]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
VD>>Собственно если тебя интерсуют Плюсы, то можешь попробовать использовать Натйру для реализации кодогенерации для плюсов. Тоже интересное направление.
EP>Есть задача сгенерировать определённый код из схемы (допустим из .xml), причём результирующий код не только на C++.
Знакомо У меня в проекте xslt этим занимается (xml-файл предоставлен другой командой, они его для своих java-нужд используют)
EP>Насколько я понимаю, Nemerle/Nitra в этом контексте может использоваться как парсер схемы на компактном и удобном DSL (вместо .xml), плюс шаблонизатор (свой DSL для шаблонов), и соответственно генератор кода. Из плюшек, как я понимаю — автоматическая интеграция DSL'ей (схемы и шаблонов) в IDE, так? EP>Может есть какие-то другие сценарии применения для данного контекста?
Главная плюшка, которой сейчас нет в Нитре для С++ — это интеграция с системой типов. Т.е. чтоб макрос сам мог покопаться в нутрях компилятора, посмотреть, какие есть классы и какие у них есть методы, и правильно заюзать их.
Без этого Нитра для меня будет просто очередным перлом, которым я сгенерю обобщенное нечто, в котором будут сплошные вызовы перегрузок и метафункций для собственно определения нужных типов и вызовов (т.е. генерится куча одинакового кода с enable_if и прочая, в расчете на то, что компилятор потом выкинет все ненужное и найдет все перегрузки). Другого пути сделать типо-корректную кодогенерацию в С++ я не придумал, в отсутствии прямой связи генератора с системой типов (это же относится и к Boost.Preprocessor — он ведь тоже никак не связан с системой типов, так что все те же самые проблемы).
Ну разве что делать плагин для GCC — у меня такая идея давно сидит (с 4.7?), но времени покопаться так и нету.
Ты, кстати, уверен что эта поделка сработает на всех тех же сценариях на которых сработает foreach else из Nemerle? Ты понимаешь что мы сейчас обсуждаем не фичу Nemerle как языка программирования, а один единственный, простейший макрос, который в случае надобности под проект на ходу пишется? 
Но выбирая compile-time или runtime в C++ нужно иметь очень веские основания чтобы выбрать второе.
Кстати, внезапно, в исходниках roslyn я снова вижу хардкод фич поштучно. Интересно, если Nitra таки их уделает в хлам, они будут 1)догонять по фичам поштучно 2)снова переписывать, или 3)купят JB? 
