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

Common Systems Programming Optimizations and Tricks

paulcavallaro.com

Post reply on HN
Print view View original

11–20 of 98 posts

Re: Common Systems Programming Optimizations and Tricks

#11

Post by notacoward »

jcelerier wrote: post #7
eschneider wrote: post #6

Earlier quoted context omitted.

As someone who's worked on old Macs and has also done lots of 32 -> 64-bit porting, this is the sort of trick that works wonderfully...until it doesn't. And then you've got a nightmare on your hands. I'm not saying never do that (ok, maybe I am...) But definitely think long and hard about how long your code will be around before you do it.

> As someone who's worked on old Macs and has also done lots of 32 -> 64-bit porting, this is the sort of trick that works wonderfully...until it doesn't. And then you've got a nightmare on your hands. That's why you hide the trick behind a zero-cost abstraction which checks at compile-time if the platform supports this

One of my favorite system programming tricks is to never believe that a "zero cost abstraction" lives up to the name.

Re: Common Systems Programming Optimizations and Tricks

#12

Post by groby_b »

legulere wrote: post #3

Instead of repurposing top bits you can also repurpose the Bits beyond alignment. E.g 32 bit integers are aligned to 4 bytes, so you can use the lower two bits of pointers to them instead.

That does not hold for Intel x86 architecture chips, which are perfectly happy to have unaligned integers.

As for struct members, the alignment is (of course) "implementation defined", which is the fancy way of throwing up your hands and saying "whatever". (Since C++11 we actually have alignas(), which at least gives manual control)

Re: Common Systems Programming Optimizations and Tricks

#13

Post by ajross »

josalhor wrote: post #8
jacobush wrote: post #4

Earlier quoted context omitted.

Taken to the extreme, ONE lock in Python. :)

I know this is a joke, but you still need locks in Python

I didn't read it as a joke, you're just operating at a different abstraction level. The CPython interpreter famously uses a single global interpreter lock to protect the language internals and runtime, so it has trouble scaling beyond a single CPU on interpreter-heavy workloads. You're saying that threads in python scripts can be arbitrarily preempted, and so locking is required to protect them against each other, which is also true.

Re: Common Systems Programming Optimizations and Tricks

#14

Post by dbcurtis »

jacobush wrote: post #4
dbcurtis wrote: post #2

Good article. Basics that everyone can benefit from knowing. Just one nit/warning... breaking coarse locks into fine-grained locks can be taken too far. There is a point of diminishing returns where you end up spending increased time acquiring/releasing/waiting-for locks. At some point you want to clump together under a single lock resources that tend to often be used together, even if you often end up locking an ext…

Taken to the extreme, ONE lock in Python. :)

Ha Ha! Yes. The gillectomy project collected some interesting data on that a couple of years ago, creating very fine-grained locks and measuring. Not unexpectedly, with a zillion locks performance suffered. The reason though, had much to do with how much it thrashed the cache on a modern CPU. Lots of cache invalidation traffic back and forth between cores. The C-Python implementation is architected around the GIL, and that is a tough problem to crack.

My favorite too-many-locks story goes back quite a long time, a former coworker is an old-time Unix guru, who was at Sequent back in the day when 8 CPU's was kind of a big deal. He spent about 9 months on a project putting lots of fine-grained locks into their Unix kernel. After shipping that, his next project was 6 months taking about 25% of them out :)

Re: Common Systems Programming Optimizations and Tricks

#15

Post by jjuhl »

notacoward wrote: post #11
jcelerier wrote: post #7

Earlier quoted context omitted.

> As someone who's worked on old Macs and has also done lots of 32 -> 64-bit porting, this is the sort of trick that works wonderfully...until it doesn't. And then you've got a nightmare on your hands. That's why you hide the trick behind a zero-cost abstraction which checks at compile-time if the platform supports this

One of my favorite system programming tricks is to never believe that a "zero cost abstraction" lives up to the name.

Modern optimizing C++ compilers (especially with Link Time Optimization enabled) are pretty amazing and can very often actually achieve that abstraction collapsing.. But, of course, always measure.

Re: Common Systems Programming Optimizations and Tricks

#16

Post by vardump »

notacoward wrote: post #11
jcelerier wrote: post #7

Earlier quoted context omitted.

> As someone who's worked on old Macs and has also done lots of 32 -> 64-bit porting, this is the sort of trick that works wonderfully...until it doesn't. And then you've got a nightmare on your hands. That's why you hide the trick behind a zero-cost abstraction which checks at compile-time if the platform supports this

One of my favorite system programming tricks is to never believe that a "zero cost abstraction" lives up to the name.

Yeah, don't believe in dogmas, measure. Zero cost abstractions sometimes are anything but.

Re: Common Systems Programming Optimizations and Tricks

#17

Post by groby_b »

vymague wrote: post #5

Interesting article. Is there a reason why there isn't a book/article that has a more comprehensive list?

I guess partially because it can quickly become very dependent on the system you work on. But if you're specifically interested in caching issues, one good keyword to look for is "cache aware algorithms" - or "cache oblivious algorithms".

On the locking side, the counterpart would probably be "lock-free algorithms", but I still don't believe their complexity means that in most cases you shouldn't look at those :)

Re: Common Systems Programming Optimizations and Tricks

#18

Post by ibrault »

vardump wrote: post #10

Very good article, facts looked correct and it had useful advice. I'd add, keep things local. Don't access memory (or cache) outside core (L1 & L2), NUMA region or processor socket boundary unnecessarily. Keep networking, GPU, etc. code in same NUMA region where the physical adapters are. Use memory like tape, stream through. CPU branch predictors love that kind of access pattern. Oh, and perhaps most importantly: us…

Could you elaborate on what it means to "use memory like tape"?

Re: Common Systems Programming Optimizations and Tricks

#19

Post by saagarjha »

notacoward wrote: post #11
jcelerier wrote: post #7

Earlier quoted context omitted.

> As someone who's worked on old Macs and has also done lots of 32 -> 64-bit porting, this is the sort of trick that works wonderfully...until it doesn't. And then you've got a nightmare on your hands. That's why you hide the trick behind a zero-cost abstraction which checks at compile-time if the platform supports this

One of my favorite system programming tricks is to never believe that a "zero cost abstraction" lives up to the name.

The abstraction necessary to make tagged pointers platform-dependent is quite small and trivially removed by any optimizing compiler.

Re: Common Systems Programming Optimizations and Tricks

#20

Post by tyingq »

ibrault wrote: post #18
vardump wrote: post #10

Very good article, facts looked correct and it had useful advice. I'd add, keep things local. Don't access memory (or cache) outside core (L1 & L2), NUMA region or processor socket boundary unnecessarily. Keep networking, GPU, etc. code in same NUMA region where the physical adapters are. Use memory like tape, stream through. CPU branch predictors love that kind of access pattern. Oh, and perhaps most importantly: us…

Could you elaborate on what it means to "use memory like tape"?

Sequential access instead of random. Like arrays instead of linked lists, for example.
Post reply on HN