James wrote:
I see the need to take the static vs dynamic linking debate from the top.
Thank you.
the compiler should maintain a database of functions and choose whether or not to inline them
Agree. No problem.
Disk space we can perhaps disrespect, however space in the instruction cache is precious.
Cache optimization was indeed a strong argument for static linking in ForwardCom. Static linking makes all code contiguous, assuring optimal caching and no unused code. Dynamic linking makes functions scattered everywhere in memory, including many unused functions, making caching inefficient.
ABI stability
ForwardCom is standardizing ABI and calling conventions across platforms and languages, unlike most other instruction set architectures.
functions are page-faulted in when needed
This is causing unpredictable response times that annoy users. The heavily fragmented memory space has caused a need for 5-level page tables in Windows - with a heavy cost on hardware, software and performance. I think it is time to experiment with reversing this trend of ever increasing memory management complexity.
'order files' which say what should be loaded in what order to optimize the layout and avoid page-faulting later
Static linking makes sure the compiler and linker has full control over code ordering. Dynamic linking gives random ordering, placing each DLL wherever the heap manager can find a vacant spot.
Cross module optimizations
The compiler can optimize across modules by inlining and by using the unique cross-module register allocation feature of ForwardCom.
The champion of static linking is likely rust, there compilation times are truly absurdly slow
I am not very familiar with rust, but it seems there are other reasons why the rust compiler is slow. Static linking in C++ is quite fast in my experience.
A main argument for dynamic linking is to avoid multiple copies of the same function in memory. I haven't seen any statistics on how many functions are actually shared by multiple running processes in a real-life situation, but I suspect the number is low. Especially in Linux where .so functions are shared only if they have the same version number.