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

F> К сожалению, могу лишь только подтвердить. При том, не смотря, на то что в блогах хвастались что x64 jit умеет такое, что не умеет x86 — x86 jit стабильно выигрывает на любой платформе (в смысле windows x86/x64).

В моем тесте получилось наоборот — x64 быстрее. Но это очень узкий микробенчмарк, об общей производительности он не говорит.

F> Но — всё же зависит от задачи. Мне чего-то кажется, что от векторизации циклов толку в прикладном коде... ммм... ну не про математику — около нуля (или я ошибаюсь?).

Все правильно. Изначальная задача, вдохновившая мой бенчмарк, — это фрагмент видеокодека. В основном сравнивал компиляторы С++, а C# там чисто из любопытства.

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

DM>Все правильно. Изначальная задача, вдохновившая мой бенчмарк, — это фрагмент видеокодека. В основном сравнивал компиляторы С++, а C# там чисто из любопытства.
И какой счет?

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

А>И какой счет?

См. пост по приведенной ссылке. Если говорить про C# vs C++, то в этом тесте C# (на х64) получился шустрее, чем старые С++ компиляторы, но медленне, чем свежие. Однако даже хорошие С++ компиляторы в разы отстают от ручной векторизации.

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

_>А оно всё оказалось не очень-то надо в реальной жизни, и большая часть этих наворотов была к концу проекта просто забыта в дебрях стремительно устаревающего кода и использовалась только для того чтобы в NUnit зелёных кружочков табунами гонять.



А что конкретно из макросов пригодилось, ну, кроме логирования ?

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

I>А что конкретно из макросов пригодилось, ну, кроме логирования ?

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

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

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

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

I>>А что конкретно из макросов пригодилось, ну, кроме логирования ?

VD>А ты сам как-нить попробуй на досуге.

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

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

VD>А ты сам как-нить попробуй на досуге. Только сразу предупреждаю, что если проникнешься макросами, то у тебя все сознание сломаешь и потом писать на языках без макросов уже сможешь только с огромным батхертом (ломкой).

Мне больше нравится аналогия Wolfhound'а: макросы, они как парашют — нужны редко, но когда нужны то без них никуда. А у меня первое ощущение при переключении на С++ — как быстро он компилируется!

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

DR>Мне больше нравится аналогия Wolfhound'а: макросы, они как парашют — нужны редко, но когда нужны то без них никуда. А у меня первое ощущение при переключении на С++ — как быстро он компилируется!
Я тогда был маленький и глупый.
Сейчас я понимаю, что без них (я точнее без создания ДСЛ) нельзя сделать действительно качественную абстракцию.

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

_>А оно всё оказалось не очень-то надо в реальной жизни, и большая часть этих наворотов была к концу проекта просто забыта в дебрях стремительно устаревающего кода и использовалась только для того чтобы в NUnit зелёных кружочков табунами гонять.
Это все по тому, что вы начали наворачивать фичи на язык общего назначения.
Это ошибка.
Нужно было делать ДСЛ для задачи.
Тогда бы у вас и кода было бы много меньше.
И макры не пошли бы в мусор.

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

WH>Я тогда был маленький и глупый.
WH>Сейчас я понимаю, что без них (я точнее без создания ДСЛ) нельзя сделать действительно качественную абстракцию.

То есть, раньше ты лишь изредка использовал макросы, но позже понял, что создавал при этом недостаточно качественные абстракции? Было бы очень интересно увидеть пример.

Лично я сейчас использую Немерле как "C# с вариантами". Мой рабочий репозиторий состоит из двух частей: прикладной на плюсах и исследовательской на Немерле. Исследовательская часть больше: в ней прототипируются алгоритмы, собирается статистика и подбираются параметры.

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

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

Теперь я считаю, что нужно создавать ДСЛ под задачу.
И уже его спокойно транслировать в рабочий код. Это гораздо проще, чем писать этот код руками. Ибо не нужно думать о том, чтобы результирующий код не скатился в говно. Т.к. его руками никто не пишет. И глазами не читает.
Более того говнокод можно делать очень быстрым.

DR>Было бы очень интересно увидеть пример.
https://github.com/rampelstinskin/ParserGenerator
Удачи сделать это без ДСЛ.
А уж сравниться по скорости без ДСЛ вообще не реально.
И это при том, что я там еще далеко не все запланированные оптимизации сделал.

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

WH>https://github.com/rampelstinskin/ParserGenerator
WH>Удачи сделать это без ДСЛ.
WH>А уж сравниться по скорости без ДСЛ вообще не реально.
WH>И это при том, что я там еще далеко не все запланированные оптимизации сделал.

Ясно. Жаль, что этот пример такой нетипичный. Всё таки, очень мало людей пишет парсеры.

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

I>Евангелизм такой мутной воды принципиально не рассматриваю, так что не трать силы.

Ага. Всегда проще наклеить ярлычок вроде "евангилизм", чем в чем-то разобраться и попробовать на практике.

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

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

DR>Мне больше нравится аналогия Wolfhound'а: макросы, они как парашют — нужны редко, но когда нужны то без них никуда.

Он уже ответил на это сам. И это уже слова не мальчика, но мужа (с)

ЗЫ


Реально я не знаю как объяснить тем кто не проникся на практике, то что дают макросы. Это надо просто прочувствовать. Хотя возможно я просто пока не могу качественно это сформулировать.

Общая идея — макрос позволят добиться почти идеальной абстракции. Эта абстракция может выражать суть предметной области настолько точно насколько это только возможно, и при этом макрос позволяет сделать реализацию настолько конкретной и качественной насколько это нужно.

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

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

У Немерле есть только один фатальный недостаток: он работает поверх CLR, а не на JVM или LLVM. После этого все остальные недостатки уже совершенно фиолетовы

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

DR>Ясно. Жаль, что этот пример такой нетипичный. Всё таки, очень мало людей пишет парсеры.

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

Идеология получения правильных абстракций — продумываешь модель своей задачи (описание задачи в виде некой структуры данных или языка). Продумываешь язык описывающий модель (ДСЛ). Пишешь генератор из модели в код или интерпретатор. Описываешь задачу на полученном ДСЛ. Рефакторишь генератор/интерпретор так чтобы получить нужное качество прдукта. Если нужно развиваешь или рефакторишь ДСЛ. Повторяешь последние пункты до получения оптимального результата.

Язык (ДСЛ) обеспечивает максимальную близость абстракции к решаемой задаче. Генератор обеспечивает независимость реализации от возникающих проблем и позволяет не идти на поводу у "инструмента".

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

KP>У Немерле есть только один фатальный недостаток: он работает поверх CLR, а не на JVM или LLVM. После этого все остальные недостатки уже совершенно фиолетовы

У машины может быть любой цвет при условии, что он черный (с) Генри Форд.

I>А что конкретно из макросов пригодилось, ну, кроме логирования ?

Там две итерации было. В первой (2007-2008г) мы только учились, поэтому там было буквально пара макросов, остальное врукопашную, C# style and flow, только с упором на паттерн-матчинг и ФП.

Вторая итерация была сильно позже (2009г) и умели мы гораздо больше, но понимали всё ещё столько же . Ну правильно, макросов же ещё не писали толком. А главное, пока было оплачиваемое время между первой и второй итерациями, — лепили фреймворк. И не то чтобы он оказался совсем не нужен, просто наше представление о программирование было всё ещё сильно искажено призмой C# и даже C++.

Вот пример — подметили что многие (да наверное все) объекты, подерживающие IDisposable, делают Dispose вложенным объектам, что, в принципе, логично. Для этого придумали аттрибут AutoDispose, который должен был использоваться примерно так:

[AutoDispose]
class A : IDisposable
{
  [AutoDispose]
  private b : B;

  [AutoDispose]
  private c : C;
}

Ну и типа генерируется православный метод метод Dispose, который там Dispose(disposing : bool), GC.SuppressFinalize, и вложенным объектам тоже Dispose если надо, в общем всё хорошо. Макрос был весело написан, и через неделю использования оказалось что есть один нюанс — эти [AutoDispose] не нужны как тот скрипач. В итоге всё выродилось до полностью автоматической реализации IDisposable, без всяких аттрибутов вообще. Ориентиром было наличие самого интерфейса IDisposable. Т.е. если класс заявлял что он IDisposable, но не давал самописной реализации своего Dispose, то создавалась реализация "по-умолчанию" для всех приватных и протектед полей. Оказалось удобно и надёжно, писанины меньше, меньше места для ошибок.

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

class ACollection : IList
{
  [ModifcationGroup("IList")]
  public Count : int { get; protected set; }

  [ModifcationGroup("IList")]
  public Add(value : object) : int
  {
  }
}

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

class ACollection : IList
{
  [ChangedBy(Add, Remove, Clear)]//это имена методов, которым разрешено менять Count
  public Count : int { get; set; }
}

Теперь если кто-то попытается изменить Count в каком-то другом методе — получает ошибку времени компиляции. Если какого-то метода нет — тоже ошибка компиляции. Для чтения Count даёт лок-фри кэшированное значение. Главное декларативно и сразу видно кто может лазить в Count. Жалко только goto definition для этой штуки не работал — с Location мы как-то не разобрались в тот раз. Посмотрим насколько проще с этим будет в N2

Или вот слепили мы хитрые методы для синхронизации, там можно было в нашей реализации lock перечислять объекты через ",". Кроме того была секция то-ли late, то-ли reserve, в которой можно было перечислить что ты собираешься лочить потом, после того как залочишь свой объект. Это было придумано для того чтобы обеспечить гарантированно без-деадлочную блокировку. Обеспечили, а оно оказалось втопку. Зато его место заняли несколько макросов вида readlock(object), writelock(object). Вот только был маленький секрет — эти макросы лочили не сам объект, а его SyncRoot, причём если у объекта не было своего SyncRoot, но ему в конструктор передавался другой объект(родитель), со своим SyncRoot, то лочился родительский SyncRoot, ну и так в цикле, пока у кого-нибудь не найдётся SyncRoot. Самое главное что если SyncRoot был object — то макросы превращались в обычнй Monitor.Enter. А вот если SyncRoot был ReaderWriterLock — то тогда в вызовы его методов. А если SyncRoot был ReaderWriteLockSlim, то ещё проверялось на то, держим мы уже лок или нет, потому как ReaderWriterLockSlim не поддерживает реентерабельность. Да, и во избежание ошибок мы библиотечный lock подменили на наш write_lock. Магии много, но пока она незаметная и её не надо держать в голове — кода рукопашного мало, а значит пользоваться удобно и накосячить сложно.

Кроме того много работы выполняли макросы и стиль программирования, за которые в C# проекте я бы руки отрывал. Например нужно было устанавливать связь с разными старыми системами, написанными чёрт знает на чём. Для каждой такой системы был заведён свой проект, с одинаковой иерархией namespace'ов. И в них была строгая иерархия наименования типа Root.Api.XyzTasks, Root.Api.XyzSerializer, Root.Comm.XyzListener и т.п. Так вот если в имени класса было Xyz, то автоматом генерировались пачками приватные члены, характерные для этой системы. Если при этом ещё и namespace Comm, то создавалась прокся с полностью асинхронными вызовами тех public методов что имелись в классе. Ну и так далее.

Или вот ещё ацкий трэш — у нас некоторые исключения имели помимо важности ещё свойство Color, которым (ааа111!!!) их надо было подсвечивать в GUI. Выставлялось это свойство автоматом, исходя из того в каком классе, в процессе работы над какой задачей, случился throw. Почему такое нарушение принципов вообще оказалось возможно — а потому что оно не выставлялось вручную вообще нигде. Т.е. GUI код просто использовал это свойство, и ему по-барабану как оно возникло, а программист который исключение кидал — даже не знал про какое-то там свойство, и его не выставлял. Соотвественно если бы мы решили эту хрень заменить, или вообще убрать — надо было бы менять только одно место, а значит принципы правильного разделения BL и GUI можно слать в конкретно этом случае лесом.

Очень полезными оказались прекомпилируемые регекспы, которые были быстрые как компилируемые, и описанные прямо в коде. Кроме того у Nemerle есть свой match/биндинг по регекспам (называется кажется rx match или regex match), и мы по образу и подобию слепили себе такой же, но почему и чем он был лучше — уже не помню.

Множественное наследование оказалось не нужно вовсе. traits на интерфейсах оказалось что использовались только для сериализации, больше впихнуть было некуда, а сериализация была на лямбдах удобнее. Так и стали traits зомбями nUnit'ными.

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

И ещё — оказались очень нужны и важны макросы которые не добавляют функционал, а наоборот ограничивают использование чего-то откуда не планировалось, причём во время компиляции. Например нельзя лезть в объекты неймспейса GUI из объектов неймспейса Threading или Comm. Или нельзя приводить какой-то интерфейс больше ни к какому другому интерфейсу (полагаясь на тайное знание о том что там за интерфейсом какой-то конкретный объект). Это позволяет очень сильно снизить число ошибок причём без единого теста или захода в отладку. Таких штук мы вообще не задумывали в фреймворке, а потом использовали повсеместно.

А теперь ДЗЕН вынесенный из этого проекта:
Ближе к концу мы уже не стремились лепить библиотечные навороты и расширять фреймворк, а скорее старались заменять макросами рукопашный код насовсем но локально. Т.е. гораздо проще разработать какую-то феньку нужную в 5 местах и без параметров, и какую-то очень похожую феньку (даже внешне точно такую-же) для 5 других мест, чем лепить универсальную, конфигурируемую через кучу параметров мега-фень, способную покрыть все эти 10 мест и ещё 20 гипотетических похожих.

Ну и экономический момент. Ожидая проблем с отладкой макросов и самого проекта в котором будет много макро-магии, я сознательно завысил оценку времени на отладку раза в 3. Причём первый раз завысил, руководствуясь тем что язык новый, и тогда (2007-й год), интеграция ещё работала очень слабо, и некоторые штуки было проще написать в Far+Colorer чем в студии. А второй раз — завысил исходя из того что всю эту макро-магию потом отладчиком разбирать будет сложно. Оба раза зря.

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

Собственно о чем я и говорил.
Когда вы перестали расширять язык общего назначения фичами общего назначения и начали делать конкретные решения у вас все начало получаться.
Но дзен вы постигли не до конца.
Следующая ступень в просветлении это понимание того что если бы вы изначально не использовали ЯОН то все было бы еще проще.
Проблема в том что в данный момент ДСЛ даже на Н1 делать довольно тяжело. Н2 исправит эту проблему.

WH>Собственно о чем я и говорил.
WH>Когда вы перестали расширять язык общего назначения фичами общего назначения и начали делать конкретные решения у вас все начало получаться.

Ну да, так это я и называю "перестали фреймворк писать".

WH>Но дзен вы постигли не до конца.
WH>Следующая ступень в просветлении это понимание того что если бы вы изначально не использовали ЯОН то все было бы еще проще.
WH>Проблема в том что в данный момент ДСЛ даже на Н1 делать довольно тяжело. Н2 исправит эту проблему.

Тут просто нехватка понятий. Обычно под ДСЛ понимают именно языковые конструкции, ключевые слова там новые и т.п. В этом случае у нас от ДСЛ не так и много было — readlock, writelock, ещё что-то такое-же простое. А получилось что язык вообще стал отступать, под давлением всяких "неявных" реализаций. Это уже даже не DSL а Domain Specific Runtime что-ли. И чем дальше тем сильнее мы уходили от декларативного программирования, всё больше полагаясь на магию автогенерации, завязанную на совершенно нетрадиционные вещи — имена классов и namespace'ов, объявленные но не реализованные интерфейсы, тот же тип поля SyncRoot, значение константы Offset (там была магия с DateTime на разных системах). Что было очень неожиданно, так как первое правило которое мы сами себе придумали — это что код не должен браться из ниоткуда. Типа там нам самим будет непонятно, если не будет аттрибута [AutoDispose] хотя-бы на классе, а лучше на мемберах. А оказалось наоборот, что аттрибуты тоже код, и если избавляться по-возможности и от них — то жить проще.

Да, и ещё интересный момент — связность кода за счёт иерархий наследования реализации стала сильно падать. Сейчас мне даже кажется что virtual и override это неправильный костыль, и можно выкатить язык на одних только интерфейсах и с макропрограммированием, и будет epic win. Но пока не потренируюсь на прототипе, выносить эту идею в philosophy/flame.comp не готов