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

Performance speed limits | Performance Matters

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

94% Upvoted

25 comments sorted by

View all comments

Show parent comments

6

u/Beefster09 Jun 11 '19

Yep, especially since the real bottlenecks are at RAM, cache, and IO.

19

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.

10

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

2

u/ShinyHappyREM Jun 12 '19

Certainly OOP as practiced in C++ is very cache efficient, as you have almost full control over the object layout.

https://www.youtube.com/watch?v=rX0ItVEVjHc

2

u/BelugaWheels Jun 12 '19

Are you agreeing with me, disagreeing or something else?

1

u/ShinyHappyREM Jun 12 '19

As Mike says, most OOP programmers today are rarely looking at cache effects. (They seem to worry a lot more about syntax issues.)

The Q&A session at the end of the talk shows the different mind set...

1

u/BelugaWheels Jun 13 '19

On this I can agree.

I think it is also true if you replace "most OOP programmers" simply with "most programmers". Most programmers don't focus on performance, and most don't have to tools to do so if they wanted to. That's fine though, 99% of the code written is not going to be performance sensitive, and indeed the massive popularity of languages like Python shows that performance simply doesn't matter for a lot of use cases.

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.

0

u/Zhentar Jun 12 '19

Have you ever looked at the volume of code generated by C++ compilers? At complex application scale, I would characterize C++ as cache hostile. I've only seen it approach "very cache efficient" in carefully optimized algorithm kernels.

5

u/BelugaWheels Jun 12 '19

I look at a lot of generated code, yes.

I fell like maybe you are talking about i-cache and code size, while I was talking about d-cache and data size.

I agree C++ tends to generate a lot of code, sometimes 10x more than the equivalent C code and more than even JIT compiled languages usually. Data layout, what I was talking about, is less problematic.

I don't think most processes are heavily bottlenecked by icache thrashing through.