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

[avva]

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

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

Comments

[nine_k]

1) Речь не о скорости извлечения, а о том, что процессор ничего про VMT не знает и предвыборку по адресу из неё не осуществит, а заинлайненный код, показанный выше, рискует весь оказаться в prefetch queue и соотв. все его инструкции имеют шанс быть заранее в какой-то мере исполненными, или хоть целиком дешифрованными, ко времени их очередного исполнения. Выборка-то нынче дорога.

2) Речь не о статических компиляторах (которые, конечно, много что могут), а о JIT, т.е. кодогенерации в runtime. У статического компилятора есть граф зависимостей, у JIT -- заодно и статистика настоящего исполнения кода, что может иногда вести к решениям, которые статический компилятор просто не в силах придумать, за неимением этой статистики.

[109.livejournal.com]

ах да, prefetch.

теперь я про jit не понимаю :-)

он же не каждое исполнение компилирует, а только первое, когда ещё нет никакой статистики?

[nine_k]

JIT компилирует не сразу, а именно just in time, т.е. набрав статистику. Что-то компилируется после N вызовов, что-то перекомпилируется и инлайнится после M > N вызовов, etc. Большая часть кода исполняется редко, а компилируется только самое частое за последнее время, по результатам непрерывного профилирования.

[109.livejournal.com]

а можно ссылочку? а то я не понимаю, какой смысл не компилировать после первого, ну на крайняк второго вызова.

[nine_k]

Компиляция стоит времени и памяти (на откомпилированное в том числе).
Компиляция после N > 2-го вызова имеет смысл потому, что набрана статистика на тему, как именно оптимизировать данный кусок, в реальных условиях приложения. Разумеется, если можно позволить себе компиляцию перед первым вызовом, это тоже хорошо. Но не всегда возможно: так придётся компилировать код, который исполнится 1-2 раза и больше не пригодится. Куда интереснее оптимально скомпилировать critical path.

С другой стороны, CLI-шный Ngen.exe умеет сначала статически (до загрузки и исполнения) скомпилировать байткод в родной, а потом дооптимизировать (перекомпилировать) критические куски по ходу выполнения.

Хороших ссылок что-то не найду; всё лезет или совсем популярно "что тако JIT вообще", или длинные специализированные учёные статьи.