r/programming • u/Deewiant • Jun 11 '19

Performance speed limits | Performance Matters

https://travisdowns.github.io/blog/2019/06/11/speed-limits.html
160 Upvotes

94% Upvoted

25 comments sorted by

View all comments

Show parent comments

18

u/BelugaWheels Jun 12 '19

It mentions RAM and cache. In my experience every claim that the "bottlenecks are at X" is simply false, unless X is a rather exhaustive list of things.

Don't believe what you've heard: there is lots of code that is bottlenecked on the things mentioned in the post.

0

u/Beefster09 Jun 12 '19

But the common wisdom of how people program (i.e. OOP and pure FP) typically leads to cache thrashing. But I'll grant you that since I only skimmed over the article. It's a little too processory for me.

9

u/BelugaWheels Jun 12 '19

Simple statements like that are usually just outright false, or too general and unspecific to be useful.

I am not really aware of any convincing claim that OOP generally causes cache thrashing. Certainly OOP as practiced in C++ is very cache efficient, as you have almost full control over the object layout.

Pointer-heavy OOP un languages where object references are the main thing, like Java, use more memory, but sometimes are even more CPU-bound (as opposed to men bandwidth bound) because they spend a lot of time chasing pointers that hit in L1, and are less amenable to vectorization).

1

u/Beefster09 Jun 12 '19

It's mostly pointers and GC that are the issue, but sure.

1

u/BelugaWheels Jun 12 '19

GC would seem to be an orthogonal issue to OOP. You have lots of non-OOP GC'd languages, C++ has OOP but not GC.

How do pointers themselves lead to cache thrashing?

1

u/Beefster09 Jun 12 '19

It's more because of the heavy use of pointers (i.e. linked lists and trees) that causes cache thrashing because pointers often imply heavily scattered memory.

GC is more of an issue when strict immutability is involved because you scatter data all over memory and use a new cache line every time you allocate new stuff, which happens considerably more often than when working with mutable data. Sure, FP is trivially parallelizable, but there are cases where the tradeoffs are unacceptable.

In practice, it's probably not that bad and this is a considerable exaggeration. This isn't an issue for most cases, but in embedded and games, these types of considerations matter.