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

EP>>Хамство это конечно отличный, а главное конструктивный аргумент. Зачем думать, анализировать, спрашивать — когда можно просто нахамить — "не понимаю значит бред"
G>Ты пытаешься говорить умные слова, не понимая их смысл. Это и есть бред.

Если тебе что-то недоступно — ты не стесняйся, спрашивай, без проблем объясню.

G>>>В замыканиях нетполиморфизма
EP>>Не в самих замыканиях. Напиши пример ФВП которая принимает простейшее замыкание.
G>Там тоже нет полиморфизма.

Ты код напиши — это несколько строк — тогда разговор будет предметным. Второе сообщение уже увиливаешь

G>>>>>Что такое "динамический IEnumerable"?
EP>>>>Динамический полиморфизм для обхода последовательностей.
G>>>Пример кода покажи, не ясно о чем ты пишешь.
EP>>Вот.
G>И зачем его использовать в performance-critical коде?

О том и речь — он тормозит. А вот диапазоны C++ — нет

EP>>std::vector, std::deque, std::string — это всё random access последовательности. На них можно писать алгоритмы на итераторах, без abstraction penalty.
G>Неправда. Эффективный sort для vector будет отличаться от эффективного sort для deque.

В случае deque — да — для неё может быть более оптимальный алгоритм, но этот будет работать в том числе. ОК, допустим вычеркнем deque — всё равно исключительно в поставке C++ имеем встроенные массивы, std::vector, std::string, std::array.

G>Abstraction penality это не потому что компилятор не умеет девиртуализировать вызовы,

По этому в том числе.

G>а потому что детали абстрагируемого кода могут повлиять на быстродейсвтие.

Могут влиять, а могут и не влиять std::find_if работает одинаково хорошо как для массивов, так и для списков.

EP>>На C# IList даст приличную просадку. И это лишь один из примеров.
G>Просадку где?

В коде использующем его вместо конкретных контейнеров.

EP>>>>Собственно о том и речь — в C++ я могу накручивать уровни абстракций даже в performance-critical коде, без жёсткого penalty.
G>>>Это только если инлайнинг сработает.
EP>>И что характерно он работает, потому что язык к этому располагает. Потому что можно использовать ФВП, замыкания, и т.п. без всякого динамического полиморфизма.
G>Язык тут не при чем. 20 лет назад C++ был почти такой же, а инлайнинга почти не было. Странно, да?

Был, менее сильный чем сейчас, но тем не менее был: http://www.osl.iu.edu/download/research/mtl/papers/iscope_final.pdf

G>Ты путеашь теплое с мягким. Быстродействие С++ — следствие миллинов трудочасов, вложенных в компилятор, а не свойство языка.

Не путаю, C++ быстрый в том числе потому что его легко оптимизировать — очевидно что встраивание обычного вызова легче чем виртуального.

EP>>Я же говорил про IEnumerable.
G>Ты хоть проверял какой код генерируется? Может там тоже нет виртуальных вызовов, девиртуализация срабатывает.

Проверял, но в другом случае

Автор: Evgeny.Panasyuk
Дата: 20.06.15

.
Если же брать этот конкретный случай — то он тормозит восьмикратно по сравнению с ручной подстановкой конкретных типов.

G>>>C IEnumerable другая проблема, которая связана с ФВП. Вообще ФП в C# довольно медленно работает, не создавался язык под него.
EP>>О чём и речь
G>Проблема в компиляторе, вернее в JIT, а не в самом языке.

В языке в том числе.

EP>>Так в том-то и фишка что буду, because I can! Зачем мне делать его руками, для всех используемых комбинаций алгоритмов * замыканий * последовательностей * прочих абстракций, когда с этим прекрасно справляется компилятор?
G>Многие как раз делают иначе, постностью отказываясь от фич C++. Тот же v8.
G>Они чего-то не знают?

Я не знаю что там конкретно внутри v8, и на основе чего они принимали какие-то там решения.
Но есть реальные и публичные примеры, где абстракции используются в полный рост, при этом давая исключительную производительность.