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

51–60 of 98 posts

Re: Common Systems Programming Optimizations and Tricks

#51

Post by vardump »

simcop2387 wrote: post #42
vardump wrote: post #38

Earlier quoted context omitted.

It'll probably be quite a while before operating systems rush to turn on extra level of page walk fun, increasing TLB miss penalty even more. If only x86 could have 64 kB pages... Of course you're right it's not a great idea to use those bits. Eventually they will be in use, although it's probably 10+ years.

The linux kernel has patches for it submitted now, ready for when the hardware arrives https://www.phoronix.com/scan.php?page=news_item&px=Linux-De...

My point was that very few need more than 48 bits of virtual address space. Having extra layer of lookup will reduce page walk performance.

52-bit physical & 57-bit virtual address space is a no brainer if you have more than 128 TB of RAM installed, of course. :-)

Re: Common Systems Programming Optimizations and Tricks

#52

Post by floatboth »

muricula wrote: post #32
kabdib wrote: post #28

"Repurposing Top Bits" - don't do that. Honest. The IBM 360 shipped with 32-bit addresses but only 24 bits decoded. "Hey, there's a whole byte up top that nobody's using today, let's put some stuff there!" When they wanted the address space IBM found themselves architecturally hamstrung, and the cost to dig out was significant. The 128K Macintosh used a 68000; it had 32-bit addresses but only 24 bits were decoded. "H…

Armv8 has an opt-in feature you can turn on to ignore the top byte: https://en.wikichip.org/wiki/arm/tbi This is also where the pointer authentication code goes for arm pointer authentication: https://lwn.net/Articles/718888/ On x86_64 and arm without those features enabled, the top bits of the pointer must be sign extended. This means that x86_64 by default gives you the top two bytes to play with as long as you don…

The coolest thing this enables is a way more precise ASAN: https://clang.llvm.org/docs/HardwareAssistedAddressSanitizer...

Re: Common Systems Programming Optimizations and Tricks

#53

Post by y7 »

> Now, to support multiple processors on a single machine reading and writing from the same memory in a coherent way, only one processor on a machine can have exclusive access to a given cache line.

Does this also apply when multiple processors are only reading memory?

Re: Common Systems Programming Optimizations and Tricks

#54

Post by vardump »

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…

> CPU branch predictors love that kind of access pattern.

My brain's "branch predictor" had some sort of issue. CPU prefetchers of course. :-)

Re: Common Systems Programming Optimizations and Tricks

#55

Post by esotericn »

pjungwir wrote: post #44
kabdib wrote: post #28

"Repurposing Top Bits" - don't do that. Honest. The IBM 360 shipped with 32-bit addresses but only 24 bits decoded. "Hey, there's a whole byte up top that nobody's using today, let's put some stuff there!" When they wanted the address space IBM found themselves architecturally hamstrung, and the cost to dig out was significant. The 128K Macintosh used a 68000; it had 32-bit addresses but only 24 bits were decoded. "H…

Back around 2001 I was part of a webdev shop that had its own proprietary application server. It pre-parsed HTML files for or and would run whatever you put there. We linked in slightly patched perl/python libraries so we didn't have to start a new interpreter every request. There were a couple in-house RPN languages too, and other comment-based markup for easy loops/interpolations. One design goal was to let you rou…

This is majestic. Is your current work anywhere near as interesting? :P

Re: Common Systems Programming Optimizations and Tricks

#56

Post by bogomipz »

kabdib wrote: post #28

"Repurposing Top Bits" - don't do that. Honest. The IBM 360 shipped with 32-bit addresses but only 24 bits decoded. "Hey, there's a whole byte up top that nobody's using today, let's put some stuff there!" When they wanted the address space IBM found themselves architecturally hamstrung, and the cost to dig out was significant. The 128K Macintosh used a 68000; it had 32-bit addresses but only 24 bits were decoded. "H…

Interesting history, thanks.

Sorry if this is a silly question but is the "upper" in these examples the most significant bit end of the address then?

Re: Common Systems Programming Optimizations and Tricks

#57

Post by ufo »

> Part of why the change couldn’t be enabled by default is because various high performance programs, notably various JavaScript engines and LuaJIT, use this repurposing trick to pack some extra data into pointers.

Does any one know if this sentence can be backed up by a citation?

I know that the NaN-tagging trick assumes that pointers have 48 bits (small enough to fit inside a floating point mantissa), but was this ever a factor for deciding whether 5-level page tables should be added to the Linux kernel or not?

Re: Common Systems Programming Optimizations and Tricks

#58

Post by atq2119 »

y7 wrote: post #53

> Now, to support multiple processors on a single machine reading and writing from the same memory in a coherent way, only one processor on a machine can have exclusive access to a given cache line. Does this also apply when multiple processors are only reading memory?

No. That's what MESI-based cache protocols are all about. Multiple cores/processors can have the same cache line in a shared/read-only state. Only writes require exclusive access.

Re: Common Systems Programming Optimizations and Tricks

#59

Post by CalChris »

kabdib wrote: post #28

"Repurposing Top Bits" - don't do that. Honest. The IBM 360 shipped with 32-bit addresses but only 24 bits decoded. "Hey, there's a whole byte up top that nobody's using today, let's put some stuff there!" When they wanted the address space IBM found themselves architecturally hamstrung, and the cost to dig out was significant. The 128K Macintosh used a 68000; it had 32-bit addresses but only 24 bits were decoded. "H…

Apple’s market cap is $983B and IBM’s is $125B. So somehow they’ve survived this lowbrow hack.

Seriously, with 64 bit addresses available on the iPhone I’m typing this into, this is an excellent trick, especially for applications. Even ARM’s TBI leaves 56 bits which is more address space than a data center’s DRAM.

  log2(16 billion * 100,000) is about 50
You have a point at 32. You’re just wrong at 64.

Re: Common Systems Programming Optimizations and Tricks

#60

Post by __jal »

CalChris wrote: post #59
kabdib wrote: post #28

"Repurposing Top Bits" - don't do that. Honest. The IBM 360 shipped with 32-bit addresses but only 24 bits decoded. "Hey, there's a whole byte up top that nobody's using today, let's put some stuff there!" When they wanted the address space IBM found themselves architecturally hamstrung, and the cost to dig out was significant. The 128K Macintosh used a 68000; it had 32-bit addresses but only 24 bits were decoded. "H…

Apple’s market cap is $983B and IBM’s is $125B. So somehow they’ve survived this lowbrow hack. Seriously, with 64 bit addresses available on the iPhone I’m typing this into, this is an excellent trick, especially for applications. Even ARM’s TBI leaves 56 bits which is more address space than a data center’s DRAM. log2(16 billion * 100,000) is about 50 You have a point at 32. You’re just wrong at 64.

Right, because the quality of every lesson one learns about programming practice should be evaluated by the market cap of the firm where it was learned.
Post reply on HN