Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.16.51.137] |
|
Страницы: (56) « Первая ... 53 54 [55] 56 ( Перейти к последнему сообщению ) |
Сообщ.
#811
,
|
|
|
Цитата D_KEY @ Скорость вызова одинакова, я зырил асм.Вот мне помнится, что по крайней мере в скорости вызовов не просирает, а чуть ли не выигрывает Затем же зачем и pragma(inline, false) Иначе и clang и ldc оптимизируют bar в нуль: вернуть 20. Добавлено Сравниваем шаблонные версии: D: pragma(inline, false) void foo(alias fn)() { fn(10); } int bar() { int i = 10; foo!((int x){ i += x; }); return i; } template<typename F> __attribute((noinline)) void foo(F fn) { fn(10); } int bar() { int i = 10; foo([&i](int x){ i += x; }); return i; } |
Сообщ.
#812
,
|
|
|
Смотрим асм.
D: int example.bar(): push rax mov dword ptr [rsp], 10 mov rdi, rsp call pure nothrow @nogc @safe void example.foo!(example.bar().__lambda1(int)).foo()@PLT mov eax, dword ptr [rsp] pop rcx ret pure nothrow @nogc @safe void example.foo!(example.bar().__lambda1(int)).foo(): add dword ptr [rdi], 10 ret С++: bar(): # @bar() push rax mov dword ptr [rsp + 4], 10 lea rdi, [rsp + 4] call void foo<bar()::$_0>(bar()::$_0) mov eax, dword ptr [rsp + 4] pop rcx ret void foo<bar()::$_0>(bar()::$_0): # @"void foo<bar()::$_0>(bar()::$_0)" add dword ptr [rdi], 10 ret В данном случае дешный асм либо равен либо лучше плюсового. Так то. Добавлено Но это все ситуативные оптимизации. Полагаю, что производительность C++ и D можно считать одинаковой, при прочих равных. |
Сообщ.
#813
,
|
|
|
Нахрена?
Добавлено А, сорри, страничка новая. |
Сообщ.
#814
,
|
|
|
Цитата applegame @ Насколько я понимаю, нет синтаксиса, чтобы типизировать лямбду явно. А неявно компилятор в любом случае её типизирует (поскольку с нетипизированными объектами работать не умеет)А вот можно ли в плюсах создать "типизированную" лямбду (std::function<void(int)> например) с замыканиями, но без аллокаций в куче? И, насколько понимаю, для замыкания всегда выделяется память в стеке. |
Сообщ.
#815
,
|
|
|
Цитата amk @ Для замыканий память по любому нужна. Хоть какая-нибудь где-то там. Вопрос "можно ли без аллокаций", думаю, надо понимать как "можно ли без dynamic storage". И, насколько понимаю, для замыкания всегда выделяется память в стеке. Добавлено Вопрос в другом: почему хочется без dynamic storage? ИМХО только лишь из-за проблем с производительностью и отсутствием явных языковых правил для dynamic storage duration. С GC можно было бы не париться за duration, но вопрос производительности только ужесточился бы. std::function<> должен быть готов работать с любым объектом, чей интерфейс имеет реализацию указанного operator(), а значит не может не быть полиморфным, а значит в объектной модели C++ должен работать с объектами косвенно, а значит посредством dynamic storage и указателями. Причём с подсчётом ссылок, ибо иначе std::function<> не имел бы семантику значений. |
Сообщ.
#816
,
|
|
|
Цитата Qraizer @ std::function<> должен быть готов работать с любым объектом, чей интерфейс имеет реализацию указанного operator() Делегаты в D обладают подобным же свойством. |
Сообщ.
#817
,
|
|
|
Но я-то за Плюсы. Динамический полиморфизм за интерфейсом скрывает информацию об исходном типе, однако её сохраняет статический полиморфизм. Так что да, где спасовал std::function<>, вывозит шаблон.
|
Сообщ.
#818
,
|
|
|
Цитата Qraizer @ Какая-нибудь нужна, но в D нередко можно обойтись без дополнительной памяти для замыканий. Ни стековой ни dynamic storage ни GC. Плюсы́ такого фокуса, ЕМНИП, не умеют.Для замыканий память по любому нужна. Хоть какая-нибудь где-то там. Цитата Qraizer @ Ну этот подход работает и в D, так что здесь преимуществ нет. Но я-то за Плюсы. Динамический полиморфизм за интерфейсом скрывает информацию об исходном типе, однако её сохраняет статический полиморфизм. Так что да, где спасовал std::function<>, вывозит шаблон. |
Сообщ.
#819
,
|
|
|
Цитата applegame @ Каким образом?Ни стековой ни dynamic storage ни GC. Цитата applegame @ Причём тут преимущества? Я за недостатки. Просто иначе std::function<> не может быть устроен. Другое дело шаблон, он недостатка не имеет. Ну этот подход работает и в D, так что здесь преимуществ нет. |
Сообщ.
#820
,
|
|
|
Цитата Qraizer @ Если время жизни лямбды меньше времени жизни переменных замыкания, то можно не резервировать дополнительную память, а обращаться напрямую к данным на стеке. D так умеет. Я приводил пример:Каким образом? void foo(scope void delegate(int) fn) { fn(10); } int bar() { int i = 10; foo((int x){ i += x; }); return i; } В данном случае в foo передается делегат, время жизни которого, меньше, чем переменной замыкания i. Компилятор знает, что делегат никуда не утечет из функции foo, благодаря атрибуту scope. В foo будет передан указатель на функцию делегата и указатель на стековый фрейм с переменной i. Цитата Qraizer @ А, окай, я тебя неверно понял.Причём тут преимущества? Я за недостатки. Просто иначе std::function<> не может быть устроен. Цитата Qraizer @ Но есть другой недостаток: например, нельзя сделать массив лямбд с одинаковой сигнатурой, но разными замыканиями. Другое дело шаблон, он недостатка не имеет. |
Сообщ.
#821
,
|
|
|
А какие преимущества перед шаблоном в данном случае?
Добавлено Цитата applegame @ Но есть другой недостаток: например, нельзя сделать массив лямбд с одинаковой сигнатурой, но разными замыканиями. А для такого случая эта штука со scope как будет работать? |
Сообщ.
#822
,
|
|
|
Цитата applegame @ Так это просто оптимизация. Оптимизировать и C++ умеет. Для общего-то случая такая оптимизация не гарантируется. Если время жизни лямбды меньше времени жизни переменных замыкания, то можно не резервировать дополнительную память, а обращаться напрямую к данным на стеке. D так умеет |
Сообщ.
#823
,
|
|
|
Цитата D_KEY @ Даже с шаблоном под замыкания в плюсовой лямбде будет выделена память как минимум на стеке. Например, на стеке лежит переменная, а в замыкании ссылка на эту переменную. Ну и template code bloat никто не отменял.А какие преимущества перед шаблоном в данном случае? Цитата D_KEY @ К такой штуке scope не прикрутишь никак. Тут будут аллокации в GC. Либо можно как в плюсах хранить функторы аналогичные std::function.А для такого случая эта штука со scope как будет работать? Цитата Qraizer @ Плюсы не смогут сделать такую оптимизацию в общем случае. В плюсах нет scope.Так это просто оптимизация. Оптимизировать и C++ умеет. Для общего-то случая такая оптимизация не гарантируется. Но в целом это мелочь, я считаю. Но интересная, на мой взгляд. |
Сообщ.
#824
,
|
|
|
Цитата applegame @ Во-первых, это сделано в твоём собственном листинге вверху. Я даже проверил, визуалка тоже так умеет. Во-вторых, в Плюсах нет и Cёвого restrict. По той же причине, подозреваю, почему нет scope. Плюсы не смогут сделать такую оптимизацию в общем случае. В плюсах нет scope. |
Сообщ.
#825
,
|
|
|
Ну вон в Go нет «нормального ООП» и вообще никакого параметрического полиморфизма, да и обработка ошибок не «нормальная» (привычна разве что для махровых Сишников). Каналы, опять же, для многих «программистов на мейнстримных языках» — не сильно привычный способ синхронизации. Но достаточно много людей его таки начали использовать. |