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

21–30 of 69 posts

Re: Operation Costs in CPU Clock Cycles

#21

Post by CountSessine »

This is a fantastic resource; kudos to the author. But there is one thing in this reference that I found unexpected:

One further thing which is related to memory accesses and performance, is rarely observed on desktops (as it requires multi-socket machines – not to be confused with multi-core ones ... When multiple sockets are involved, modern CPUs tend to implement so-called NUMA architecture, with each processor (where “processor” = “that thing inserted into a socket”) having its own RAM

I thought that all Intel chips since Nehelem divided their SDRAM access into a NUMA-configuration based on cores? Am I wrong about that?

Re: Operation Costs in CPU Clock Cycles

#22

Post by vvanders »

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

That's a great talk, brings together a lot of different things I've seen in one place.

Re: Operation Costs in CPU Clock Cycles

#23

Post by eloff »

CountSessine wrote: post #21

This is a fantastic resource; kudos to the author. But there is one thing in this reference that I found unexpected: One further thing which is related to memory accesses and performance, is rarely observed on desktops (as it requires multi-socket machines – not to be confused with multi-core ones ... When multiple sockets are involved, modern CPUs tend to implement so-called NUMA architecture, with each processor (w…

NUMA typically affects multi-socket machines only. An exception would be high end Xeon chips since Haswell when used in a cluster-on-die configuration, but you won't find that in a desktop PC. Each socket in a multi-socket system has its own memory, and when a remote CPU accesses the memory of another CPU, it pays a fairly hefty latency penalty compared to accessing its own memory.

Re: Operation Costs in CPU Clock Cycles

#24

Post by jdub »

CountSessine wrote: post #21

This is a fantastic resource; kudos to the author. But there is one thing in this reference that I found unexpected: One further thing which is related to memory accesses and performance, is rarely observed on desktops (as it requires multi-socket machines – not to be confused with multi-core ones ... When multiple sockets are involved, modern CPUs tend to implement so-called NUMA architecture, with each processor (w…

I don't think there's much NUMA action on single socket at the moment, but as CPU area increases and more of the transistors are not actually doing CPU work (to spread out the heat-making bits) which increases distances on a single die, this will change.

Re: Operation Costs in CPU Clock Cycles

#25

Post by logicallee »

For people who make interactive applications, here is an interesting thing to add:

Making a user interpret an error message or notification of some kind (8 seconds) and have to dismiss a window (3 seconds) rather than be able to continue seamlessly:

44,000,000,000 operations, or 275,000,000,000 operations if we include the idling GPU.

Distance light travels in this time: around the world 77 times, all while we keep the user from being able to do anything.

Something to think about the next time you throw up a dialog box...

Re: Operation Costs in CPU Clock Cycles

#26

Post by CountSessine »

eloff wrote: post #23
CountSessine wrote: post #21

This is a fantastic resource; kudos to the author. But there is one thing in this reference that I found unexpected: One further thing which is related to memory accesses and performance, is rarely observed on desktops (as it requires multi-socket machines – not to be confused with multi-core ones ... When multiple sockets are involved, modern CPUs tend to implement so-called NUMA architecture, with each processor (w…

NUMA typically affects multi-socket machines only. An exception would be high end Xeon chips since Haswell when used in a cluster-on-die configuration, but you won't find that in a desktop PC. Each socket in a multi-socket system has its own memory, and when a remote CPU accesses the memory of another CPU, it pays a fairly hefty latency penalty compared to accessing its own memory.

Just thinking about it, I guess this makes perfect sense - all memory access on a socket will converge on a common L3 cache and it would be just bizarre if somehow each core would do a 'private write-through' somehow to it's own SDRAM.

Re: Operation Costs in CPU Clock Cycles

#27

Post by twoodfin »

eloff wrote: post #9
currysoup_t wrote: post #7

Earlier quoted context omitted.

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

Re: Operation Costs in CPU Clock Cycles

#29

Post by fdsaaf »

I am extremely skeptical of "full" rows in the table, the ones that purport to measure the overall costs of cache invalidation. These costs are so workload specific that a single number is meaningless and likely to mislead. My own benchmarks show costs that are nowhere near the ones cited.

Re: Operation Costs in CPU Clock Cycles

#30

Post by kikoreis »

jdub wrote: post #24
CountSessine wrote: post #21

This is a fantastic resource; kudos to the author. But there is one thing in this reference that I found unexpected: One further thing which is related to memory accesses and performance, is rarely observed on desktops (as it requires multi-socket machines – not to be confused with multi-core ones ... When multiple sockets are involved, modern CPUs tend to implement so-called NUMA architecture, with each processor (w…

I don't think there's much NUMA action on single socket at the moment, but as CPU area increases and more of the transistors are not actually doing CPU work (to spread out the heat-making bits) which increases distances on a single die, this will change.

Unless there is core-specific RAM on the die, why? Isn't the essential aspect of NUMA the fact that there is some memory which is "near", and some which is "far"?
Post reply on HN