Fedora Stakeholders Debate Statically Linking Python For Better Performance

[coder]

I thought Fortran was the choice of many scientists???

Yes, in decades past.

These days, fortran seems to be a direct dependency only of older libraries, with not much new code being written in it.

[starshipeleven]

how about bash? i'm sure someone can come up with tests which are faster on statically linked bash

Bash is not used for actual productive software and scientific work (not as the main payload logic anyway)

[coder]

how about bash? i'm sure someone can come up with tests which are faster on statically linked bash

In that case, I think you hit a wall by the name of "GPL", which doesn't permit static linking (at least, not by non-GPL code).

[coder]

Instead of wrestling with this dilemma for libraries on a case-by-case basis, wouldn't it be nice if the loader could cache libraries & executables after relocation, so we could get the best of both worlds?

[pal666]

If there is something that needs all performance it can get it's stuff using python.
Even fffffing Java is faster

how about bash? i'm sure someone can come up with tests which are faster on statically linked bash

[pal666]

rebuilding/relinking isn't a huge issue with ccache

unless you are using lto/pgo like subj

[pal666]

Why? The library will still jump to the same addresses regardless of how many processes that link to it.

it doesn't work that way. for it someone has to globally decide which part of address space every library on machine takes, otherwise you'll have two libraries or library and executable clash. prelink tried to do that and prelink is obsolete. and that was even before address space layout randomization

[endrebjorsvik]

I think all the go dependencies are statically compiled and only libc is dynamically linked. BTW Rust does the same. Rust can even statically link to two different versions of the same library. Think: Dependency1 depends on fooV1 and Dep2 depends on fooV2, foo will be compiled and linked twice.

Idiomatic Go does not even depend on libc. Go encourages you to not use libc, and linking against it is disabled by default when you cross-compile.
You are correct regarding how other dependencies work in Go. All dependencies are statically linked into one fat binary together with the supplied Go-runtime. Another thing to note about dependencies in Go projects, is that they very often end up picking a plethora of random libraries from east and west on Github. As an example, consider the dependency list for Kubernetes. This is also partly encouraged by the Go eco-system and toolchain.

[pal666]

s/depending of workload/in synthetic tests/
btw, you can make python much faster by avoiding python

[pal666]

https://www.akkadia.org/drepper/no_static_linking.html