Operation Costs in CPU Clock Cycles
ithare.com
Operation Costs in CPU Clock Cycles
1–10 of 69 posts
Re: Operation Costs in CPU Clock Cycles
#2Great overview! Would be even better as a general guideline if it included costs for HD/SSD disk writes and network usage!
Re: Operation Costs in CPU Clock Cycles
#3The small difference between direct C calls and virtual C++ calls surprised me, actually. I thought it would be much bigger.
Re: Operation Costs in CPU Clock Cycles
#4The small difference between direct C calls and virtual C++ calls surprised me, actually. I thought it would be much bigger.
A virtual call in C++ is just a vtable lookup then a direct C call. Literally one pointer away. (or perhaps one pointer then one integer addition away? For the offset)
Re: Operation Costs in CPU Clock Cycles
#5Great overview! Would be even better as a general guideline if it included costs for HD/SSD disk writes and network usage!
See the Jeff Dean numbers: https://gist.github.com/jboner/2841832
Re: Operation Costs in CPU Clock Cycles
#6The small difference between direct C calls and virtual C++ calls surprised me, actually. I thought it would be much bigger.
A virtual call in C++ is just a vtable lookup then a direct C call. Literally one pointer away. (or perhaps one pointer then one integer addition away? For the offset)
one pointer can be as slow as a sqrt if it isn't in cache.
Re: Operation Costs in CPU Clock Cycles
#7The small difference between direct C calls and virtual C++ calls surprised me, actually. I thought it would be much bigger.
As usual, memory access is the expensive operation. If the virtual function is already in L1 cache a virtual function should be only a minor slowdown. If it's all the way off in main memory it will be significantly slower.
Eric Brumer has a great talk on this: https://channel9.msdn.com/Events/Build/2013/4-329
Re: Operation Costs in CPU Clock Cycles
#8A syscall is a lot cheaper than shown here in terms of direct costs ~ 150 cycles, and also a lot more expensive, depending on the call, when you factor in the full cost of the cache that gets clobbered. More like the full cost of a context switch shown, around 10-30K cycles[1]. For this reason it's important to use system calls that allow you to amortize more work into one call, like preadv, pwritev, recvmmsg, and sendmmsg.
[1] http://www.cs.cmu.edu/~chensm/Big_Data_reading_group/papers/...
Re: Operation Costs in CPU Clock Cycles
#9The small difference between direct C calls and virtual C++ calls surprised me, actually. I thought it would be much bigger.
As usual, memory access is the expensive operation. If the virtual function is already in L1 cache a virtual function should be only a minor slowdown. If it's all the way off in main memory it will be significantly slower. Eric Brumer has a great talk on this: https://channel9.msdn.com/Events/Build/2013/4-329
Exactly. Calling a virtual function in a tight loop, almost indistinguishable from a direct (non-inlined) function call. Calling a virtual function every now and then, much more expensive, but also not as likely to matter much to the performance of your program on the whole anyway.
Still worth noting that every VM like Java or .NET or LuaJIT will optimize for the case that a virtual call usually has only one or two commonly invoked target functions. They will use a conditional fast-path for the common case(s) and fall back to slower virtual calls or less optimized paths for megamorphic calls. I don't know if any C++ compilers do this kind of thing, but I would be surprised if they did not.
Re: Operation Costs in CPU Clock Cycles
#10Anyone have the presentation from a Intel guy on how the CPU design focus has moved from cycles to cache misses handy?
Edit: never mind, it was not a Intel guy. And i actually had the thing bookmarked (and it still worked).
https://www.infoq.com/presentations/click-crash-course-moder...