Здравствуйте, VladD2, Вы писали:
VD>А грамматика шарпа у тебя там собралась?
Я не так делал, я кликнул по BuildBoot.cmd А так да, ошибки валятся: ExtensibleRuleParseTreeConstructor.n(66,17): error : goto (block return?) is not allowed inside expressions
Здравствуйте, rameel, Вы писали:
R>Я не так делал, я кликнул по BuildBoot.cmd А так да, ошибки валятся: ExtensibleRuleParseTreeConstructor.n(66,17): error : goto (block return?) is not allowed inside expressions
Ну, вот и у меня это вылезло. Надо разбираться что там и как. Вопрос имеет ли в этом смысл? Я правильно понял, что использование ldlen достаточно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, rameel, Вы писали:
R>Как побороть ошибку FSM\DFSMTransform.n(198,9,229,10): error : Label 'Next' (12583) multiply defined ? Пытался по всякому, не работает.
Исправил это дело в v1.2.532.0.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, rameel, Вы писали:
R>Результы изменений: джит полностью устранил проверку выхода за границу массива, проверку на null и вызов чего-то там на каждой итерации цикла R>
Я правильно понял, что это за счет замены вызова геттара на ldlen?
Если да, то интересно сравнение с аналогичным кодом на Шарпе.
И покажи что за асм там получился, плиз.
R>5 кратное ускорение на простом цикле
Ну, это потому что цикл почти пустой. Интересно попробовать оценить разницу на той же Нитре. Мы там сурово с массивами работаем.
Откровенно говоря мне раньше даже в голову не приходило, что там оптимизация не делается, и что надо ldlen вместо get_Length использовать.
R>Кстати, перед тем как отправить пуллреквест, хочу спросить. Я в методе emit_method_call добавил такое условие: R>
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, rameel, Вы писали:
R>>А так да, ошибки валятся: ExtensibleRuleParseTreeConstructor.n(66,17): error : goto (block return?) is not allowed inside expressions
VD>Ну, вот и у меня это вылезло. Надо разбираться что там и как.
Глядя на то, во что раскрылся макрос, то ничего криминального не вижу
VD>Вопрос имеет ли в этом смысл? Я правильно понял, что использование ldlen достаточно?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, rameel, Вы писали:
R>>Результы изменений: джит полностью устранил проверку выхода за границу массива, проверку на null и вызов чего-то там на каждой итерации цикла
VD>Я правильно понял, что это за счет замены вызова геттара на ldlen?
Ага
VD>Если да, то интересно сравнение с аналогичным кодом на Шарпе.
На шарпе чуть быстрее, но не принципиально, и то это потому что тело цикла тривиальное
Здравствуйте, rameel, Вы писали:
R>Я не так делал, я кликнул по BuildBoot.cmd А так да, ошибки валятся: ExtensibleRuleParseTreeConstructor.n(66,17): error : goto (block return?) is not allowed inside expressions
В коде есть комент:
// try prevent error: goto (block return?) is not allowed inside expressions
Так что похоже это какая-то древняя проблема.
В общем, чтобы с этим разбираться сначала надо выявить минимальный пример воспроизводящий проблему и уже потом смотреть, что там не так. Это довольно муторно. Возможно косяки с расчетом Context.AllowGoto. А может что-то связанное с отладочной информацией, как в случае коментария выше.
Отлаживаться на Нитре не реально. Процесс будет слишком долгим.
Ну, и особо смысла нет во всем этом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, rameel, Вы писали:
R>Результы изменений: джит полностью устранил проверку выхода за границу массива, проверку на null и вызов чего-то там на каждой итерации цикла R>
Здравствуйте, VladD2, Вы писали:
VD>Смерджил и обновил инсталлятор. Так что теперь это изменение доступно всем.
Ага, видел
Я еще нашел, где можно получить заметное ускорение и inline ability для многих мелких методов. Это match, который очень активно используется, явно и неявно в логических выражениях и операциях (и/или). Сейчас там генерируется очень пушистый IL. Например, много бесполезных джампов типа таких (выписал из ilspy как пример):
Разбираюсь с этим потихоньку. Как первый этап: сейчас избавился от пустого else, который генерирует джамп на следующую инструкцию, коих в проекте nemerle оказалось почти 3000 штук (подсчитал через генерацию варнингов).
Здравствуйте, rameel, Вы писали:
R>Разбираюсь с этим потихоньку. Как первый этап: сейчас избавился от пустого else, который генерирует джамп на следующую инструкцию, коих в проекте nemerle оказалось почти 3000 штук (подсчитал через генерацию варнингов).
А даст ли это что-то?
Ты ассемблер к подобным случаям смотрел? Наверняка джит пустые переходы выкидывает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А даст ли это что-то?
В совокупности.
VD>Ты ассемблер к подобным случаям смотрел? Наверняка джит пустые переходы выкидывает.
Да, джит пустые переходы мержит, но это если он конкретный метод разбирает, там ве нормально, но вот инлайнинг для мелких методов просто перестает работать. Вот такой код для примера уже не инлайнится:
public IsNull(a: object, b: object, c: object) : bool
{
a != null && b != null && c != null;
}
Но это плохой пример. Здесь всего 2 перехода с ветки на ветку генерируется. В этом примере, конкретно, больше влиет то, что для самой проверки на null генерируется 6 инструкций вместо 2 или 12 байт вместо 3
И к сожалению, все это отражается на том, какой в итоге асм будет сгенерирован джитом. Текущий джит та еще редиска. Вот, что джит генерирует для шарпа
if (a != null && b != null && c != null)
00007FFBEBED04A4 test rsi,rsi
00007FFBEBED04A7 je 00007FFBEBED04BD
00007FFBEBED04A9 test rdi,rdi
00007FFBEBED04AC je 00007FFBEBED04BD
00007FFBEBED04AE test rbx,rbx
00007FFBEBED04B1 je 00007FFBEBED04BD
Console.WriteLine(10);
00007FFBEBED04B3 mov ecx,0Ah
00007FFBEBED04B8 call 00007FFC53FD7BE0
00007FFBEBED04BD
И вот что для немерле
when (a != null && b != null && c != null)
00007FFBEBEC04D7 test rsi,rsi
00007FFBEBEC04DA je 00007FFBEBEC0500
00007FFBEBEC04DC test rdi,rdi
00007FFBEBEC04DF setne cl
00007FFBEBEC04E2 movzx ecx,cl
00007FFBEBEC04E5 test ecx,ecx
00007FFBEBEC04E7 je 00007FFBEBEC0500
00007FFBEBEC04E9 test rbx,rbx
00007FFBEBEC04EC setne cl
00007FFBEBEC04EF movzx ecx,cl
00007FFBEBEC04F2 test ecx,ecx
00007FFBEBEC04F4 je 00007FFBEBEC0500
Console.WriteLine(10);
00007FFBEBEC04F6 mov ecx,0Ah
00007FFBEBEC04FB call 00007FFC53FD7C10
00007FFBEBEC0500
А так да, ошибки валятся: ExtensibleRuleParseTreeConstructor.n(66,17): error : goto (block return?) is not allowed inside expressions
