Здравствуйте,

какой прирост производительности даёт инлайнинг правил?

и как определён критерий инлайнинга как я понимаю, количество использований < 20?

дело в том, что я хотел попробовать сделать модульность[в бранче] и пришёл к таким рассуждениям:
а. если инлайнинг даёт заметную производительность, тогда для обеспечения модульности и производительности одновремнно, необходимо экспортировать "исходник правила", чтобы его можно было бы инлайнить в парсере-контейнере. а-ля с++, что не есть гуд.
б. если инлайнингом можно пожертвовать, тогда экспорт правила сводится к публичности

public aRule(startPos: int, res : ref ResType, text: string): int

что подозрительно просто, чтобы иметь право на жизнь.

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

P>какой прирост производительности даёт инлайнинг правил?
На грамматике C# процентов 5.

P>и как определён критерий инлайнинга
Да. Но я хочу это переделать.
Но что пока не ясно.

P>а. если инлайнинг даёт заметную производительность, тогда для обеспечения модульности и производительности одновремнно, необходимо экспортировать "исходник правила", чтобы его можно было бы инлайнить в парсере-контейнере. а-ля с++, что не есть гуд.
Бессмысленное занятие.
Расширяемость нужна динамическая.
Ты на компиляции в рантайме больше потеряешь.

P>б. если инлайнингом можно пожертвовать, тогда экспорт правила сводится к публичности
P>

P>public aRule(startPos: int, res : ref ResType, text: string): int
P>

P>что подозрительно просто, чтобы иметь право на жизнь.
Примерно так я и собирался делать. А в чем проблема?

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

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

P>>какой прирост производительности даёт инлайнинг правил?
WH>На грамматике C# процентов 5.
стоит ли заинлайнить обработчики (которые рукописные)?

P>>б. если инлайнингом можно пожертвовать, тогда экспорт правила сводится к публичности
P>>

P>>public aRule(startPos: int, res : ref ResType, text: string): int
P>>

WH>Примерно так я и собирался делать. А в чем проблема?
в этом случае оптимизация(инлайнинг) может противоречить экспорту правила что не есть идеал
импорт противоречит инлайнингу всегда


P>>а. если инлайнинг даёт заметную производительность, тогда для обеспечения модульности и производительности одновремнно, необходимо экспортировать "исходник правила", чтобы его можно было бы инлайнить в парсере-контейнере. а-ля с++, что не есть гуд.
WH>Бессмысленное занятие.
WH>Расширяемость нужна динамическая.
WH>Ты на компиляции в рантайме больше потеряешь.

не. модульность на уровне файлов .n

я имею в виду пусть есть парсер А в виде файла .n
можно было бы создать парсер В так: генератор берёт грамматику B, а также не оптимизированную грамматику А (т.к. доступен исходный код) после этого собирает в одно, оптимизирует и компилирует

такой подход позволил бы одновременно получить оптимизацию(инлайнинг) и модульность(разделение грамматик и уход от копи-паста)
но это как-то криво и противоречит принципу дотнета "модульность через сборки"

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

P>стоит ли заинлайнить обработчики (которые рукописные)?
Очень сомневаюсь.
Но ты можешь попробовать.
О результатах измерений расскажи.

P>в этом случае оптимизация(инлайнинг) может противоречить экспорту правила что не есть идеал
P>импорт противоречит инлайнингу всегда
Если правило экспортируется то просто сгенерируем для него метод. И то что мы его в других местах заинлайнили не имеет значения.
К тому же инлайнинг дает прирост только на "терминальных" правилах за счет того что укатывает их в ДКА.

P>такой подход позволил бы одновременно получить оптимизацию(инлайнинг) и модульность(разделение грамматик и уход от копи-паста)
Нафиг не упало.

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

P>>стоит ли заинлайнить обработчики (которые рукописные)?
WH>Очень сомневаюсь.
WH>Но ты можешь попробовать.
WH>О результатах измерений расскажи.

+1. Тем более, что простые методы джит и так заинлайнит. А от инлайна сложных толку мало.

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

WH>К тому же инлайнинг дает прирост только на "терминальных" правилах за счет того что укатывает их в ДКА.

т.е. инлайнинг для нетерминальных правил можно безболезненно отключать?

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

start
sumOrSub
mulOrDiv
simplExpr

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

P>т.е. инлайнинг для нетерминальных правил можно безболезненно отключать?
А давай ты ничего отключать не будешь.
В прошлый раз я так и не смог понять что делает твой код и все пришлось переписать.

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

P>>т.е. инлайнинг для нетерминальных правил можно безболезненно отключать?
WH>А давай ты ничего отключать не будешь.
WH>В прошлый раз я так и не смог понять что делает твой код и все пришлось переписать.

Зато ты завелся и сделал все что нужно .

ЗЫ

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

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

VD>Зато ты завелся и сделал все что нужно .
Нет. У меня просто руки дошли.

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

VD>>Зато ты завелся и сделал все что нужно .
WH>Нет. У меня просто руки дошли.

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

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

VD>Так что релиз упирается в тебя.

Не буду говорить за всех, лично я от релиза жду совсем не пег парсер
Правила расширения вообще задача разработки 2 версии, разве нет?

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

Z>Не буду говорить за всех, лично я от релиза жду совсем не пег парсер
Z>Правила расширения вообще задача разработки 2 версии, разве нет?

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

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

Ну, и не секрет, что новая версия компилятора и интеграции будет писаться на Nemerle 1.0. Хорелось бы чтобы для этого можно было бы использовать инсталлированный вариант, а не собранный из исходников. Это как раз резко упростило бы вхождение в проект. А то получится аж двойная сложность. Сначала нужно будет собирать 1.0, а потом уже с его помощью 2.0.

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

провёл по три теста для исходного инлайнинга, без инлаинингаи и только для FSM
в таблице секунды:

old inline:    35.63 35.69 35.61
NO  inline:    36.48 36.46 36.59
new inline:    35.59 35.59 35.54

если интересно, залью в бранч

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

P>немного уменьшил инлайнинг
P>в результате, как ни странно, производительность незначительно, но улучшилась

А что за парсер использовался для тестирования?

P>провёл по три теста для исходного инлайнинга, без инлаинингаи и только для FSM
P>в таблице секунды:
P>

P>old inline:    35.63 35.69 35.61
P>NO  inline:    36.48 36.46 36.59
P>new inline:    35.59 35.59 35.54
P>

Еще бы понять, что эти цифры означают. Три колонки с разными цифрами .

P>если интересно, залью в бранч

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

Здравствуйте, VladD2, Вы писали:
VD>А что за парсер использовался для тестирования?
http://code.google.com/p/nemerle/source/browse/nemerle/branches/peg-2/snippets/csharp-parser/CSharpPraser.SpeedTests?spec=svn9441&r=9441

цель конечно не оптимизация как таковая, а проверить что если оставить инлайнинг только для FSM, то производительность не упадёт.

попутно наткнулся на то что это правило не заинлайнилось в FSM

spaces : void         = ' '*;

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

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

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

P>как сделать так, что первая грамматика должна быть скомпилирована (АСТ) к началу создания второй?

Это Вольфхаунд уже сделал. Макрос PegGrammar разбит на две стадии: BeforeTypedMembers и WithTypedMembers. На второй (WithTypedMembers) доступны все парсеры распознанные из кода текущего проекта. Остальные парсеры (загруженные из внешних сборок) априори доступны изначально.

Погляди вот эту ветку: http://rsdn.ru/forum/nemerle/3999768.1.aspx

Автор: WolfHound
Дата: 15.10.10

прежде чем чем-то заниматься.

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

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

P>>как сделать так, что первая грамматика должна быть скомпилирована (АСТ) к началу создания второй?

VD>Это Вольфхаунд уже сделал. Макрос PegGrammar разбит на две стадии: BeforeTypedMembers и WithTypedMembers. На второй (WithTypedMembers) доступны все парсеры распознанные из кода текущего проекта. Остальные парсеры (загруженные из внешних сборок) априори доступны изначально.

после BeforeTypedMembers -> parsed grammar
после WithTypedMembers -> compiled grammar

из внешних сборок -> скомилированная грамматика.

т.о. для грамматики "B" на стадии WithTypedMembers в случае:
одной сборки доступна только parsed grammar "А"
внешней сборки доступно уже compiled grammar "А"

можно ли как-то это унифицировать?
или делать два метода импорта грамматики?


VD>Погляди вот эту ветку: http://rsdn.ru/forum/nemerle/3999768.1.aspx

Автор: WolfHound
Дата: 15.10.10

прежде чем чем-то заниматься.
ok

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

P>т.о. для грамматики "B" на стадии WithTypedMembers в случае:
P>одной сборки доступна только parsed grammar "А"
P>внешней сборки доступно уже compiled grammar "А"

P>можно ли как-то это унифицировать?
P>или делать два метода импорта грамматики?

Получить (как ты ее называешь) parsed grammar для импортированной из другой сборки грамматики невозможно в принципе.
С другой стороны по parsed grammar можно четко определить какие скомпилированные правила у нее будут. Так что унифицировать с бинарным парсером parsed grammar можно. Надо только создать некую обвязку скрывающую детали.

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

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

Мы планировали сделать динамическую расширяемость для правил типа OrderedChoice (правда, Вольхаунд тут недавно скзал, что это суженное понимание, но пояснений не дал). OrderedChoice можно представить в виде массива (дотненого) правил. В нем может быть от нуля до бесконечности правил. При этом эти правила могут быть как загружены из грамматики где объявлен OrderedChoice, так и подключены динамически, например, в обработчиках Scope(см. документацию).

Так вот статическое расширение в принципе можно представить как динамическое. Разница с динамическим будет только в том, что статическое расширение определяется декларативно (внутри парсера) и приводит к тому, что парсер сам вмонтирует в код код расширения правил.

Синтаксически это может выглядеть так. В расширяемом парсере указываем импорт другого парсера:

[PegGrammar(start,
grammar
{  
  using NumberParser; // Импоритруем все правила из грамматики.

  [Extensible]
  expr = Num /* правило из импортированной грамматики */ / otherExpr;
  otherExpr = ...;
  start : Ast = expr;
}]
class ParserB { ... }

При этом уже не важно будет является ли NumberParser импортированным из другой сборки или его код находится в этой же сборке. Более того правило "expr" может содержать смесь из правил импортированных из скомпилированных парсеров, из парсеров находящихся в том же проекте и из текущего парсера.

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

VD>Получить (как ты ее называешь) parsed grammar для импортированной из другой сборки грамматики невозможно в принципе.
VD>С другой стороны по parsed grammar можно четко определить какие скомпилированные правила у нее будут. Так что унифицировать с бинарным парсером parsed grammar можно. Надо только создать некую обвязку скрывающую детали.
ясно)

VD>Вопрос только в том, что статическое расширение возможно только если оба парсера (расширяющий и расширяемый) доступны в исходниках.
Давай уточним, что понимать под статическим расширением:
я понимаю статическое расширение, модульность — это возможность использования правил определённых в парсере А из парсера Б ?

тогда
в исходном парсере есть правило aRule. его использование означает вызов метода

public aRule(startPos: int, res : ref ResType, text: string): int

в новом парсере мы создаём ссылку на первый

def usedParser  = ......

а использование имортированного правила компилируется как

def pos = usedParser.aRule(startPos, res, text);

что равносильно и для исходника и для сборки

VD>Динамическая же расширяемость доступна для любого типа парсеров и должна делаться на основе подмены содержимого правил.

VD>Мы планировали сделать динамическую расширяемость для правил типа OrderedChoice (правда, Вольхаунд тут недавно скзал, что это суженное понимание, но пояснений не дал). OrderedChoice можно представить в виде массива (дотненого) правил. В нем может быть от нуля до бесконечности правил. При этом эти правила могут быть как загружены из грамматики где объявлен OrderedChoice, так и подключены динамически, например, в обработчиках Scope(см. документацию).

т.е суть динамического расширения-это возможность изменять списки в правилах типа OrderedChoice

VD>Так вот статическое расширение в принципе можно представить как динамическое. Разница с динамическим будет только в том, что статическое расширение определяется декларативно (внутри парсера) и приводит к тому, что парсер сам вмонтирует в код код расширения правил.

VD>Синтаксически это может выглядеть так. В расширяемом парсере указываем импорт другого парсера:
VD>

VD>[PegGrammar(start,
VD>grammar
VD>{  
VD>  using NumberParser; // Импоритруем все правила из грамматики.

VD>  [Extensible]
VD>  expr = Num /* правило из импортированной грамматики */ / otherExpr;
VD>  otherExpr = ...;
VD>  start : Ast = expr;
VD>}]
VD>class ParserB { ... }
VD>

VD>При этом уже не важно будет является ли NumberParser импортированным из другой сборки или его код находится в этой же сборке. Более того правило "expr" может содержать смесь из правил импортированных из скомпилированных парсеров, из парсеров находящихся в том же проекте и из текущего парсера.

как-то запутано выглядит — как будто собираемся расширять exp
вроде изначально планировалось

[PegGrammar(start,
grammar
{  
  using NumberParser; // Импоритруем все правила из грамматики.

  expr = NumberParser.Num /* правило из импортированной грамматики */ 
  //...;
  start : Ast = expr;
}]
class ParserB { ... }

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

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

VD>>Получить (как ты ее называешь) parsed grammar для импортированной из другой сборки грамматики невозможно в принципе.
VD>>С другой стороны по parsed grammar можно четко определить какие скомпилированные правила у нее будут. Так что унифицировать с бинарным парсером parsed grammar можно. Надо только создать некую обвязку скрывающую детали.
P>ясно)

VD>>Вопрос только в том, что статическое расширение возможно только если оба парсера (расширяющий и расширяемый) доступны в исходниках.
P> Давай уточним, что понимать под статическим расширением:
P>я понимаю статическое расширение, модульность — это возможность использования правил определённых в парсере А из парсера Б ?

Статическое значит, что не в рантайме, т.е. о подключаемой грамматике известно во время компиляции основной (той в которую подключаются правила из внешней грамматики).

P>тогда
P>в исходном парсере есть правило aRule. его использование означает вызов метода
P>

P>public aRule(startPos: int, res : ref ResType, text: string): int
P>

P>в новом парсере мы создаём ссылку на первый
P>

P>def usedParser  = ......
P>

P>а использование имортированного правила компилируется как
P>

P>def pos = usedParser.aRule(startPos, res, text);
P>

P>что равносильно и для исходника и для сборки

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

P>т.е суть динамического расширения-это возможность изменять списки в правилах типа OrderedChoice

Да. Правда Вольхаунд тут намекал на большее. Но он так и не пояснил своего видения.

P>как-то запутано выглядит — как будто собираемся расширять exp

Дык, так и есть.

P>вроде изначально планировалось
P>

P>[PegGrammar(start,
P>grammar
P>{  
P>  using NumberParser; // Импоритруем все правила из грамматики.

P>  expr = NumberParser.Num /* правило из импортированной грамматики */ 
P>  //...;
P>  start : Ast = expr;
P>}]
P>class ParserB { ... }
P>

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