Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Operation Costs in CPU Clock Cycles

ithare.com

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Operation Costs in CPU Clock Cycles

#31

Post by bogomipz »

eloff wrote: post #8

A 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 se…

>"and also a lot more expensive, depending on the call, when you factor in the full cost of the cache that gets clobbered."

But a syscall doesn't necessarily mean a context switch right? It's just a mode switch if the kernel is servicing the syscall on behalf of the same process. The cache wouldn't get clobbered then because the kernel is mapped into the top of every process, for just this reason.

Or am I misunderstanding what you are saying?

Re: Operation Costs in CPU Clock Cycles

#32

Post by fdsaaf »

bogomipz wrote: post #31
eloff wrote: post #8

A 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 se…

>"and also a lot more expensive, depending on the call, when you factor in the full cost of the cache that gets clobbered." But a syscall doesn't necessarily mean a context switch right? It's just a mode switch if the kernel is servicing the syscall on behalf of the same process. The cache wouldn't get clobbered then because the kernel is mapped into the top of every process, for just this reason. Or am I misundersta…

You are correct. The author is considering the cost of accessing kernel mode code and data, which I don't think is fair

Re: Operation Costs in CPU Clock Cycles

#33

Post by quotemstr »

Honestly, it's a lot more complicated than that, and the article itself presents a pretty complicated (and flawed) model. There's no substituting for benchmarks.

Really, if you want a quick and dirty heuristic, the smallest program is likely the fastest. Everything else will bite you in the ass.

Anti exception stuf: the author repeats the old harmful "exceptions for exceptional cases" bromide while overselling the cost of exception dispatch (5k cycles is cheap in the scheme of things) and underestimating (or, rather, not mentioning) the icache cost of error checking.

Now that I'm looking, the author glosses over many other things as well, like modern system call interfaces (no exceptions!), cache pressure generally, and branch prediction efficacy. These factors are strong arguments against generating reams of template code using CRTP.

Like most analyses that purport to show the "true" cost of anything on modern superscalar virtual memory systems, it oversimplifies.

Re: Operation Costs in CPU Clock Cycles

#34

Post by bogomipz »

fdsaaf wrote: post #32
bogomipz wrote: post #31

Earlier quoted context omitted.

>"and also a lot more expensive, depending on the call, when you factor in the full cost of the cache that gets clobbered." But a syscall doesn't necessarily mean a context switch right? It's just a mode switch if the kernel is servicing the syscall on behalf of the same process. The cache wouldn't get clobbered then because the kernel is mapped into the top of every process, for just this reason. Or am I misundersta…

You are correct. The author is considering the cost of accessing kernel mode code and data, which I don't think is fair

Oh I see, that makes sense. Agreed. Thanks.

Re: Operation Costs in CPU Clock Cycles

#35

Post by globuous »

vcarl wrote: post #15
digi_owl wrote: post #10

Anyone 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...

There's a fantastic, massively upvoted StackOverflow post that can also provide some insight here. This may be a little more accessible, since it's such a significant runtime difference with very simple source code. http://stackoverflow.com/questions/11227809/why-is-it-faster...

Thanks so much for sharing this, great read !

For those, like me, that want to play with what this stackoverflow talks about, here's a fiddle of it: https://jsfiddle.net/tbinetruy/Latkmk2q/1/ (code takes 2s to run and loads firebug for console logs).

Re: Operation Costs in CPU Clock Cycles

#36

Post by School-Cotton »

OskarS wrote: post #12

I'm surprised how fast a C function call is. I would have thought that creating a stack frame would be slower than that, (and significantly slower than a floating point division), but I guess not.

Creating a stack frame is just updating a register and writing a couple of values to L1 cache.

Re: Operation Costs in CPU Clock Cycles

#37

Post by nullc »

bogomipz wrote: post #28

The post states: "in particular, tcmalloc and ptmalloc2 allocators can take as little as 200-500 CPU cycles for allocation/deallocation of a small object" Does anyone how many cycles the regular glibc malloc() takes?

I believe ptmalloc2 is glibc's malloc.

Re: Operation Costs in CPU Clock Cycles

#38

Post by eloff »

fdsaaf wrote: post #32
bogomipz wrote: post #31

Earlier quoted context omitted.

>"and also a lot more expensive, depending on the call, when you factor in the full cost of the cache that gets clobbered." But a syscall doesn't necessarily mean a context switch right? It's just a mode switch if the kernel is servicing the syscall on behalf of the same process. The cache wouldn't get clobbered then because the kernel is mapped into the top of every process, for just this reason. Or am I misundersta…

You are correct. The author is considering the cost of accessing kernel mode code and data, which I don't think is fair

It absolutely is fair. For a long time after a syscall your program will run slower thanks to the increased cache misses from the kernel clobbering your stuff in cache. That's a real price that you pay for a syscall and it would be wrong not to count it. However, if you found some other way of doing the work, e.g user code, kernel bypass, amortized bulk syscall, those will also have a (lesser) effect on the cache. So to be fair you compare a syscall against that, not against zero.

Re: Operation Costs in CPU Clock Cycles

#39

Post by eloff »

twoodfin wrote: post #27
eloff wrote: post #9

Earlier quoted context omitted.

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 c…

Some C++ compilers support "fast path" devirtualization via profiling feedback: http://hubicka.blogspot.com/2014/04/devirtualization-in-c-pa... As you suggest, it's a little misleading to talk about the runtime cost of a virtual or indirect function call in isolation. The most significant cost is often the resulting inability of the compiler to inline and perform further optimizations across the caller and callee.

Nice, I had a feeling they did that, thanks for the link.

I fully agree, missed optimization opportunity from not being able to inline is usually a bigger effect, because loops dominate the runtime and that's where those optimizations count.

Re: Operation Costs in CPU Clock Cycles

#40

Post by JoshTriplett »

eloff wrote: post #38
fdsaaf wrote: post #32

Earlier quoted context omitted.

You are correct. The author is considering the cost of accessing kernel mode code and data, which I don't think is fair

It absolutely is fair. For a long time after a syscall your program will run slower thanks to the increased cache misses from the kernel clobbering your stuff in cache. That's a real price that you pay for a syscall and it would be wrong not to count it. However, if you found some other way of doing the work, e.g user code, kernel bypass, amortized bulk syscall, those will also have a (lesser) effect on the cache. So…

If you have enough CPU cache, the CPU will cache both kernel and user code/data for your process. If you run long enough and access enough user data that the kernel bits get evicted, then you'll take more of a performance hit, but the same thing applies to accessing enough user data that different parts of your user data get evicted.
Post reply on HN