программистское

[avva]

Все-таки забавно, насколько использование виртуальных методов убивает скорость. Prefetch queue - наше все.

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

Comments

[iratus.livejournal.com]

Пишем на С изначально... ;-)

[vodianoj.livejournal.com]

Можно их сделать инлайн, и тогда побежит ещё быстрее.
Зато если под словом "обрабатывает" предположить, что он на самом деле что-то делает (распространённый случай), а не копирует из одного места в другое или там прибавлят 1, то всё преимущество сведётся на нет.

[averros.livejournal.com]

Мммм... или поменять интерфейс класса на предмет заменить скалярные операции на векторные. Чтобы был один вызов виртуальной функции на весь массив.

[whoozle.livejournal.com]

по хорошему, таких узких мест не должно быть :-) что-то не так с архитектурой. :-)

[mstone.livejournal.com]

Да, возможность заменить динамический полиморфизм на статический — одна из главных радостей C++.

[fima.livejournal.com]

Верится с трудом

Comparative performance : virtual vs. ordinary methods

[alex-vinokur.livejournal.com]

http://article.gmane.org/gmane.comp.lang.c++.perfometer/66

[nine_k]

Интересно, не выиграет ли в этом месте VM с JIT, которая нужны методы не только скомпилирует, но, при небольшом размере, и за-inline-ит независимо от виртуальности.

Можно смотреть на это, кстати, не как на дефект языков с virtual dispatch, а как на дефект процессорной архитектуры, которая к нему не приспособлена. Поди, лет 40 назад в наборах команд процессоров команды для поддержки подпрограмм тоже были экзотикой, не говоря уж о поддержке многопроцессности и многопроцессорности. Ничего, появились. Или там векторные операции -- появились в "мэйнстриме" на наших глазах :)

[cmm.livejournal.com]

> Можно смотреть на это, кстати, не как на дефект языков с virtual dispatch, а как на дефект процессорной архитектуры, которая к нему не приспособлена.

это дефект языков (а точнее, реализаций — не-табличный кеширующий диспатч можно и для C++ сделать, в принципе), жёстко соптимизированных не там где надо.

[nine_k]

Тоже разумно.
В общем, с обеих сторон надо делать какие-то шаги.
Есть же, скажем, процессоры со стековой архитектурой -- кой для чего просто подарочные :)

[cmm.livejournal.com]

для Форта :)

[nine_k]

Ну да. И его более популярного братца postcsript-а.
Смешнее то, что JVM стековая, и машина CLR, кажется, тоже стековая.

[(Anonymous)]

> VM с JIT, которая нужны методы не только скомпилирует, но, при небольшом размере, и за-inline-ит независимо от виртуальности

If the dynamic types of object which you are calling do not match the static type (i.e., different virtual functions being called) then I would love to see how JVM will inline this. If it is possible to determine that dynamic and static types are the same then any decent C++ compiler will generate a direct function call and will inline it if the function was defined as inline.

[arnold3.livejournal.com]

Покажите листинг.

[cmm.livejournal.com]

> If it is possible to determine that dynamic and static types are the same

the key word here (which you conspiciously omit) is "when".

[plakhov.livejournal.com]

Собственная эмуляция виртуальной таблицы при помощи С-style callbacks часто помогает.

Еще часто помогает curiously recurring template pattern.

[(Anonymous)]

My point being that when JVM can figure out *at runtime* that a virtual function call can be made a direct call or an inline call, a decent C++ compiler can do the same *at compile time*. So no, JVM "не выиграет в этом месте".

[cmm.livejournal.com]

> when JVM can figure out *at runtime* that a virtual function call can be made a direct call or an inline call, a decent C++ compiler can do the same *at compile time*.

this claim is nonsense.  if it wasn't, late binding would never, ever, incur any overhead!

[gdy.livejournal.com]

Ещё забавнее будет, если попробуете убрать вызовы функций из тела цикла ;-)

[ivan-gandhi.livejournal.com]

Вот уж точно. Языки 20-летней давности, с соответствующим менталитетом пользователей. всё это такое прошлое...

Главное дело,Кстати, теоретически-то ведь можно на уровне компилятора решить этот вопрос. Не диспатчить миллион раз, а разобраться один раз.

[ivan-gandhi.livejournal.com]

Да-да. Когда я был студентом, нас учили, что нужно поменьше фунцкий и вызовов писать в программах, потому что это неэффективно.

[avva.livejournal.com]

В данном случае это непрактично.

[ivan-gandhi.livejournal.com]

О! Форт помянули. Вот как раз на форте-то всю эту параферналию можно превратить в очень даже эффективный код.

[(Anonymous)]

It would have been if I claimed that JVM can make *every* virtual function call a direct call or an inline call. I never did.

To elaborate a bit on my original statement, JVM can only translate a virtual function call to a direct/inline call iff it can infer from the code that dynamic type and static type at the call site are always the same. It cannot assume that just because previous 100 calls were to implementation "a()", the next call will also be to "a()". As a result, what JVM can do at runtime, a C++ compiler can do at compile time. Here is an example:

struct b
{
  virtual void f () = 0;
};

struct d1: b
{  
  virtual void f () {...}
};

struct d2: b
{  
  virtual void f () {...}
};

int main ()
{
  typedef vector<b*> bv;
  bv v;
  v.push_back (new d1);
  v.push_back (new d2);

  d1 d;

  for (bv::iterator i (v.begin ()); i != v.end (); ++i)
  {
     i->f (); // Neither JVM nor C++ can optimize something like this.
     d.f ();  // Both JVM and C++ can optimize something like this.
  } 
}

[cmm.livejournal.com]

для этого компилятор должен присутствовать во время выполнения программы.
а такое, как известно, бывает только в интерпретируемых языках.  а интерпретация — это, сами понимаете, Ужастно Медленно!