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

Everything old is new again: memory optimization

nibblestew.blogspot.com

Post reply on HN
Print view View original

131–140 of 168 posts

Re: Everything old is new again: memory optimization

#131

Post by gmueckl »

cataphract wrote: post #111
gmueckl wrote: post #108

Earlier quoted context omitted.

This assumes that executable code pages can be shared between processes. I'm skeptical that this is still a notable optimization on modern systems because dynamic linking writes to executable memory to perform relocations in the loaded code. So this would counteract copy on write. And at least with ASLR, the result should be different for each process anyway.

ld writes to the GOT. The executable segment where .text lives is not written to (it's position independent code in dynamic libraries). ASLR is not an obstacle -- the same exact code can be mapped into different base addresses in different processes, so they can be backed by the same actual memory.

I can't reconcile this with the code that GCC generates for accessing global variables. There is no additional indirection there, just a constant 0 address that needs to be replaced later.

Re: Everything old is new again: memory optimization

#132

Post by wat10000 »

gmueckl wrote: post #131
cataphract wrote: post #111

Earlier quoted context omitted.

ld writes to the GOT. The executable segment where .text lives is not written to (it's position independent code in dynamic libraries). ASLR is not an obstacle -- the same exact code can be mapped into different base addresses in different processes, so they can be backed by the same actual memory.

I can't reconcile this with the code that GCC generates for accessing global variables. There is no additional indirection there, just a constant 0 address that needs to be replaced later.

Are you looking at the code before or after the static linker runs?

Re: Everything old is new again: memory optimization

#134

Post by cataphract »

gmueckl wrote: post #131
cataphract wrote: post #111

Earlier quoted context omitted.

ld writes to the GOT. The executable segment where .text lives is not written to (it's position independent code in dynamic libraries). ASLR is not an obstacle -- the same exact code can be mapped into different base addresses in different processes, so they can be backed by the same actual memory.

I can't reconcile this with the code that GCC generates for accessing global variables. There is no additional indirection there, just a constant 0 address that needs to be replaced later.

Assuming the symbol is defined in the library, when the static linker runs (ld -- we're not talking ld.so), it will decide whether the global variable is preemptable or not, that is, if it can be resolved to a symbol outside the dso. Generally, by default it is, though this depends on many things -- visibility attributes, linker scripts, -Bsymbolic, etc. If it is, ld will have the final code reach into the GOT. If not, it can just use instruction (PC) relative offsets.

Re: Everything old is new again: memory optimization

#135

Post by gmueckl »

gmueckl wrote: post #131
cataphract wrote: post #111

Earlier quoted context omitted.

ld writes to the GOT. The executable segment where .text lives is not written to (it's position independent code in dynamic libraries). ASLR is not an obstacle -- the same exact code can be mapped into different base addresses in different processes, so they can be backed by the same actual memory.

I can't reconcile this with the code that GCC generates for accessing global variables. There is no additional indirection there, just a constant 0 address that needs to be replaced later.

OK, I spent a few additional minutes digging into this. It's been too long since I looked at those mechanisms. Turns out my brain was stuck in pre-PIE world.

Global variables in PIC shared libraries are really weird: the shared library's variable is placed into the main program image data segment and the relocation is happening in the shared library, which means that there is an indirection generated in the library's machine code.

Re: Everything old is new again: memory optimization

#136

Post by gmueckl »

cataphract wrote: post #134
gmueckl wrote: post #131

Earlier quoted context omitted.

I can't reconcile this with the code that GCC generates for accessing global variables. There is no additional indirection there, just a constant 0 address that needs to be replaced later.

Assuming the symbol is defined in the library, when the static linker runs (ld -- we're not talking ld.so), it will decide whether the global variable is preemptable or not, that is, if it can be resolved to a symbol outside the dso. Generally, by default it is, though this depends on many things -- visibility attributes, linker scripts, -Bsymbolic, etc. If it is, ld will have the final code reach into the GOT. If no…

I've never observed a (non-LTO) linker exchange instructions. I want to see an example before I can believe this.

Re: Everything old is new again: memory optimization

#137

Post by xantronix »

kristianp wrote: post #115

How much memory does the C++ compiler use when compiling the program? I wonder how that compares to the python program? Not a completely unrelated metric. Would the rust compiler use much more memory compiling a comparable program to the C++ version?

The point is a bit moot. The compiler is the one place where it's okay to be a little spendy, because you're not compiling each time you need to execute the program.

Re: Everything old is new again: memory optimization

#138

Post by shepherdjerred »

bigstrat2003 wrote: post #127
shepherdjerred wrote: post #105

Earlier quoted context omitted.

If you ran a business, would you rather your devs work on feature X that could bring in Y revenue, or spend that same time reducing CPU/RAM/storage utilization by Z% and gives the benefit of ???

You work on both. Sometimes you need to prioritize one, sometimes the other. And the benefit of the second option is "it makes our product higher quality, both because that is our work ethic but also because our customers will appreciate a quality product".

The business is only going to care about the bottom line. If it's not slow enough to cause business problems, they are not going to say "here's a week to make software faster"

Likewise engineers are only going to care about doing their job. If the business doesn't reward them from taking on optimization work, why would they do it?

This is not true of all engineers and all businesses. Some businesses really do 'get it' and will allow engineers to work on things that don't directly help stated goals. Some engineers are intrinsically motivated and will choose to work on things despite that work not helping their career.

What I'm really getting is, yes, engineers choose "slower" technologies (e.g. electron, React) because there are other benefits, e.g. being able to get work done faster. This is a completely rational choice even if it does lead to "waste" and poor performance.

Re: Everything old is new again: memory optimization

#139

Post by didgetmaster »

shepherdjerred wrote: post #105
ThrowawayR2 wrote: post #77

Earlier quoted context omitted.

Next time you see someone on HN blithely post "CPU / RAM is cheaper than developer time", it's them. That is the sort of coder who are collectively wasting our CPU and RAM.

If you ran a business, would you rather your devs work on feature X that could bring in Y revenue, or spend that same time reducing CPU/RAM/storage utilization by Z% and gives the benefit of ???

That is why we have slow, bloated software. The companies that create the software do not have to pay any of the operational costs to run it.

If you have to buy extra RAM or pay unnecessary electrical or cooling expenses because the code is bad; it's not their problem. There is no software equivalent to MPG measurements for cars where efficient engine designs are rewarded at the time of purchase.

Re: Everything old is new again: memory optimization

#140

Post by Cold_Miserable »

ziml77 wrote: post #117
_dain_ wrote: post #104

Earlier quoted context omitted.

>The only worthwhile change in desktop environments since the early 2000s has been search as you type launchers. Add to that: unicode handling, support for bigger displays, mixed-DPI, networking and device discovery is much less of a faff, sound mixing is better, power management and sleep modes much improved. And some other things I'm forgetting.

There are some people who would exclude all of those an enhancements because they don't care about them (yes, even Unicode, I've seen some people on here argue against supporting anything other than ASCII)

That's me. 1 byte ASCII is all that's needed for text.
Post reply on HN