James wrote:
It's frustratingly difficult to find any serious research comparing the two
Yes indeed.
you're still not acknowledging that static linking huge graphical libraries is unacceptable
Graphics libraries are huge because they contain many functions. Each program probably uses only only a small fraction of these. Static linking will load only what is actually used.
Programs written in different languages or using different graphics frameworks are not using the same libraries. You may have ten GUI programs loaded simultaneously using ten different graphics frameworks or different versions of the same framework. Sharing libraries saves nothing here. Multiple instances of the same program will share the code anyway. Fundamental graphics operations must be system functions anyway because they are accessing hardware ports.
Hopefully, the graphics framework in ForwardCom can be standardized so that all applications use the same framework, and much of this can be system functions.
how many printfs are simultaneously loaded
printf is used in C and C++. Other languages may have their own print functions.
printf is not very big. The current version of printf in ForwardCom is only a few kB, covering all features except floating point. Anyway, printf is a system function because it is accessing hardware devices. sprintf might be a library function, though.
"I think it is time to experiment"; all the more reason not to force decisions on people one way or another.
ForwardCom is an experimental system. The design makes it possible to do the experiments you are calling for.
Dynamic linking solves a different problem: modular system updates
That's what the relinking mechanism in ForwardCom is for. And it avoids most compatibility problems.
"static linking .. assuring optimal caching"
No, optimal caching is when the function is already in cache, as it may be if being shared by other programs or preloaded, and crucially, able to avoid eviction
Code that is randomly distributed all over the memory will not be optimally cached because some sets will be overused and other sets are underused. Low sets are likely overused because dynamic libraries are loaded at the beginning of memory pages with round addresses (unless some complicated randomization method is used, using extra hardware resources). Static linking makes all the code contiguous. This guarantees equal use of all cache sets and no partially used cache lines.
As for the page faults, I agree nobody likes them but they're not a feature of dynamic linking.
The proposed ForwardCom memory system is minimizing memory fragmentation and hence page faults.
I don't think the argument can be settled until someone makes the necessary experiments. ForwardCom is intended to inspire experiments and innovative university projects.