Макросы очень гибкий инструмент, и поэтому не до конца понятно, где их применять...
Скажем, могу-ли я заменять вызовы часто используемых функций, вызовами макросов, тем самым
имитируя inline-функции?
Здравствуйте, Аноним, Вы писали:
А>Макросы очень гибкий инструмент, и поэтому не до конца понятно, где их применять... А>Скажем, могу-ли я заменять вызовы часто используемых функций, вызовами макросов, тем самым А>имитируя inline-функции?
Можно, но это не даст большого эффекта. В дотнете и так осуществляется автоматический инлайнинг функций (в релизие, при запуске без отладчика).
А применять макросы нужно там где невозможно обойтись другими стедствами языка или где они не дают удовлетворительного результата (приводят к дублированию кода, порождают не очень быстрый код).
Кроме того макросы применимы там где руки чешутся написать некую программу генерирующую код. По сути макросы это и есть средство удобно сгенерировать код в том месте где это нужно программисту.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
А>>Макросы очень гибкий инструмент, и поэтому не до конца понятно, где их применять... А>>Скажем, могу-ли я заменять вызовы часто используемых функций, вызовами макросов, тем самым А>>имитируя inline-функции? VD>Можно, но это не даст большого эффекта. В дотнете и так осуществляется автоматический инлайнинг функций (в релизие, при запуске без отладчика).
Далеко не всегда, когда хочется. Например, функции с длинным телом как правило не инлайнятся, даже если они private.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Далеко не всегда, когда хочется. Например, функции с длинным телом как правило не инлайнятся, даже если они private.
Это потому, что инлайнинг больших функций приводк к замедлению, а не к ускорению.
ЗЫ
На мой взгляд заниматься инлайнингом с помощью макросов примерно тоже самое что забивать гвозди микроскопом. Возможно но бессмысленно и дороговато.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Далеко не всегда, когда хочется. Например, функции с длинным телом как правило не инлайнятся, даже если они private. VD>Это потому, что инлайнинг больших функций приводк к замедлению, а не к ускорению.
Почему? Я тут недавно напоролся на такой пример. "Ручной" инлайниг одной функции на ряде тестов привел к увеличению производительности 2.5-3 раза. Отчего так — я не понял сам. В функции передавался один ref, ничего не возвращалось. Исполнялась функция порядка 100 млн. раз. Инлайниг был произведен методом копи-пасте, без изменения единой буквы.
VD>ЗЫ VD>На мой взгляд заниматься инлайнингом с помощью макросов примерно тоже самое что забивать гвозди микроскопом. Возможно но бессмысленно и дороговато.
Здравствуйте, Воронков Василий, Вы писали:
VD>>Это потому, что инлайнинг больших функций приводк к замедлению, а не к ускорению.
ВВ>Почему?
По теоретическим расчетам и практическим наблюдениям. Если интересны детали, ищи их в работах посвященным теории оптимизации компиляции.
ВВ>Я тут недавно напоролся на такой пример. "Ручной" инлайниг одной функции на ряде тестов привел к увеличению производительности 2.5-3 раза. Отчего так — я не понял сам. В функции передавался один ref, ничего не возвращалось. Исполнялась функция порядка 100 млн. раз. Инлайниг был произведен методом копи-пасте, без изменения единой буквы.
Значит она была не очень большая. На большой функции выигрыш от устранения вызова будет банально невиден не вооруженным взглядом, зато появятся проблемы с кэшом.
VD>>ЗЫ VD>>На мой взгляд заниматься инлайнингом с помощью макросов примерно тоже самое что забивать гвозди микроскопом. Возможно но бессмысленно и дороговато.
ВВ>Почему дорого-то?
Потому что ты бдешь тратить свое время на то, что может сделать машина.
Я правильно понял, что по вопросу бессмысленности возражений нет?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Я тут недавно напоролся на такой пример. "Ручной" инлайниг одной функции на ряде тестов привел к увеличению производительности 2.5-3 раза. Отчего так — я не понял сам. В функции передавался один ref, ничего не возвращалось. Исполнялась функция порядка 100 млн. раз. Инлайниг был произведен методом копи-пасте, без изменения единой буквы. VD>Значит она была не очень большая. На большой функции выигрыш от устранения вызова будет банально невиден не вооруженным взглядом, зато появятся проблемы с кэшом.
Что значит "большая" в твоем понимании? По моим наблюдениям даже не самые длинные функции уже перестают инлайнится. Конкретна эта функция была на 500 строк кода где-то. Это большая или нет? Кстати, операционный стек для нее маленький. Вся функция — свитч. Меня самого удивил результат, т.к. я не ожидал подобного, даже на сотне миллионов вызовов.
VD>>>На мой взгляд заниматься инлайнингом с помощью макросов примерно тоже самое что забивать гвозди микроскопом. Возможно но бессмысленно и дороговато. ВВ>>Почему дорого-то? VD>Потому что ты бдешь тратить свое время на то, что может сделать машина. VD>Я правильно понял, что по вопросу бессмысленности возражений нет?
Странный ты Я же привел пример, когда явный инлайниг бы помог.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
ВВ>>>Я тут недавно напоролся на такой пример. "Ручной" инлайниг одной функции на ряде тестов привел к увеличению производительности 2.5-3 раза. Отчего так — я не понял сам. В функции передавался один ref, ничего не возвращалось. Исполнялась функция порядка 100 млн. раз. Инлайниг был произведен методом копи-пасте, без изменения единой буквы. VD>>Значит она была не очень большая. На большой функции выигрыш от устранения вызова будет банально невиден не вооруженным взглядом, зато появятся проблемы с кэшом.
ВВ>Что значит "большая" в твоем понимании? По моим наблюдениям даже не самые длинные функции уже перестают инлайнится. Конкретна эта функция была на 500 строк кода где-то. Это большая или нет? Кстати, операционный стек для нее маленький. Вся функция — свитч. Меня самого удивил результат, т.к. я не ожидал подобного, даже на сотне миллионов вызовов.
VD>>>>На мой взгляд заниматься инлайнингом с помощью макросов примерно тоже самое что забивать гвозди микроскопом. Возможно но бессмысленно и дороговато. ВВ>>>Почему дорого-то? VD>>Потому что ты бдешь тратить свое время на то, что может сделать машина. VD>>Я правильно понял, что по вопросу бессмысленности возражений нет?
ВВ>Странный ты Я же привел пример, когда явный инлайниг бы помог.
Если Вам так нужно инлайнить, то можете написать макрос для этого.
и получить синтаксис, как в си или даже наоборот указывать ключевое слово в момент использования функции.
теоретически так можно заинлайнить и функции из внешних сборок
взамен получите проблему с отладкой.
ЗЫ: если вам так важна производительность, сделайте длл на си или асме и p-invoke её
в противном случае, считаю вредным думать об оптимизации
Здравствуйте, para, Вы писали:
P>Если Вам так нужно инлайнить, то можете написать макрос для этого. P>и получить синтаксис, как в си или даже наоборот указывать ключевое слово в момент использования функции. P>теоретически так можно заинлайнить и функции из внешних сборок P>взамен получите проблему с отладкой.
Т.е. макросы не отлаживаются? Интересно.
P>ЗЫ: если вам так важна производительность, сделайте длл на си или асме и p-invoke её P>в противном случае, считаю вредным думать об оптимизации
Вы уж извините, но я сам разберусь на чем мне писать. А модный ныне тренд "мы не считаем байты" не всегда прокатывает, к сожалению.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вы уж извините, но я сам разберусь на чем мне писать. А модный ныне тренд "мы не считаем байты" не всегда прокатывает, к сожалению.
ни как не могу навязывать.
не хотел переводить в русло отношений, только имхо.
в 2 раза — это сколько времени .. действительно интересно?
ВВ>Т.е. макросы не отлаживаются? Интересно.
макросы отлаживаются, но сложнее отлаживать код, который они порождают.
Вопрос:
Можно ли манипулировать в макросах DebugInfo, кроме Location, например, для создания макро inline?
Здравствуйте, para, Вы писали:
ВВ>>Вы уж извините, но я сам разберусь на чем мне писать. А модный ныне тренд "мы не считаем байты" не всегда прокатывает, к сожалению. P>ни как не могу навязывать. P>не хотел переводить в русло отношений, только имхо. P>в 2 раза — это сколько времени .. действительно интересно?
Много. Точно не помню уже. Больше секунды.
ВВ>>Т.е. макросы не отлаживаются? Интересно. P>макросы отлаживаются, но сложнее отлаживать код, который они порождают.
Я не понимаю, зачем вы мне все это пишите. У макросов есть проблемы при отладке? Да, но какое это отношение имеет к обсуждаемому макросу? Ведь по забавному стечению обстоятельств как раз у этого макроса (назовем его inline), такие проблемы отсутствуют как класс. По той простой причине, что "включать" его нужно будет только в релизе, а во все остальное время он будет закомментирован — и дебажьтесь себе в удовольствие.
А мне вот тоже действительно интересно — можно ли правда сделать макрос inline? По-честному так. Особенно для методов в других классах. Учитывая то, что у нас может быть куча конфликтов имен.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А мне вот тоже действительно интересно — можно ли правда сделать макрос inline? По-честному так. Особенно для методов в других классах. Учитывая то, что у нас может быть куча конфликтов имен.
Не буду утверждать про юзабилити, покажу возможность создания подобного макроса.
Проверки использования и разрешения конфликтов имён тоже сделать реально)
основа — http://www.rsdn.ru/article/nemerle/MacrosExtCoursePart2.xml#EOCAE
public macro @inlined(expr)
syntax ("inlined", expr)
{
match (expr)
{
| <[$callExpr;]> =>
def typer = Nemerle.Macros.ImplicitCTX();
_ = typer.TypeExpr(expr);
match ( callExpr.TypedObject )
{
| TT.TExpr.Call (function, _, _) =>
match (function)
{
| TT.TExpr.StaticRef(_, m is MethodBuilder, _) =>
<[$(m.Body)]>
| _ =>
Message.Hint("Unable to inline");
<[$callExpr]>
}
| _ =>
Message.Hint("Unable to inline");
<[$callExpr]>
}
}
}
test:
public module Program
{
Main() : void
{
WriteLine("Test1");
try
{
Test();
}
catch
{
e => WriteLine(e.ToString());
}
WriteLine("Test2");
try
{
inlined Test();
}
catch
{
e => WriteLine(e.ToString());
}
_ = ReadLine();
}
public Test() : void
{
throw Exception("Throwing in Test()");
}
}
output:
Test1
System.Exception: Throwing in Test()
at Program.Test() in D:\tmp\Inline\InlineTest\Main.n:line 39
at Program.Main() in D:\tmp\Inline\InlineTest\Main.n:line 18
Test2
System.Exception: Throwing in Test()
at Program.Main() in D:\tmp\Inline\InlineTest\Main.n:line 39
P>>макросы отлаживаются, но сложнее отлаживать код, который они порождают.
заметил приятную неожиданность, что сохранилать отладочная информация "Main.n:line 39"
Здравствуйте, para, Вы писали:
ВВ>>А мне вот тоже действительно интересно — можно ли правда сделать макрос inline? По-честному так. Особенно для методов в других классах. Учитывая то, что у нас может быть куча конфликтов имен. P>Не буду утверждать про юзабилити, покажу возможность создания подобного макроса. P>Проверки использования и разрешения конфликтов имён тоже сделать реально) P>основа — http://www.rsdn.ru/article/nemerle/MacrosExtCoursePart2.xml#EOCAE
Для решения указанной задачи такой макрос подошел бы (кстати, вот МСДН говорит, что любые методы со switch не инлайнятся, а это делает явный инлайниг более приоритетной штукой), но мне все же интересно как быть с именами.
Возьмем простейший пример — инлайнинг только для методов внутри того же класса (в противном случае получаем еще проблему с доступом к деталям реализации другого класса). В Немерле, я так понимаю, все макросы гигиеничны by design? Как мне в макросе поймать внешний контекст, как быть с конфликтующими именами переменных? Интересует просто концептуальный подход, хочется ликбез.
Здравствуйте, _nn_, Вы писали:
__>В стандартную библиотеку его ! __>using Nemerle.Optimization
Не надо в стандартную. В снипеты еще можно. А так, такой хакерский бардак не нужно в инсталлятор сувать.
К тому же он работает только для методов без параметров. А это как бы далеко не то, что нужно в реальной жизни.
Плюс, боюсь, что будут проблемы с гигиеной, ведь переменные могут пересечься, а код в телах методов имеет (если не ошибаюсь) один цвет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.