For optimum data locality you want threads to be explicit. Think like "thread_number_to_send_request = identifier_hash % total_threads;" balancing load between threads, where each thread contains a fraction of the data and that data remains in that thread's CPU's caches.
This statement leads me, somewhat indirectly, to some important questions, ones which I think will explain a great deal about your views on programming in general. I would like you to rank - in general, as the issues will by their nature be subjective and contextual - the importance of some design principles and tradeoffs.
- optimal time of service for system calls
- optimal memory usage for kernel operations
- reduction of the number and cost of interprocess context switches
- optimal scheduling of user and kernel processes
- optimal throughput in user applications
- stability of the operating system in normal operation
- stability of the operating system under greater than anticipated load
- stability of individual user processes
- securing access to kernel-space data
- securing access to user-space data from kernel space
- securing access to user-space data between user-space processes
- decreasing cognitive load for kernel developers (relevant in both reducing programmer error and allowing more complex software design)
- decreasing cognitive load for application developers
Hmmn, that doesn't seem to quite capture what I was aiming at, but we can start with this, I suppose.
My thoughts about this are not fully realized yet, but I get the distinct impression that you see black-box abstraction as a negative, not merely because of its performance cost, but because to you it indicates that the developers do not understand the system in detail. You seem to feel - and please correct me if I am mistaken - that a programmer who isn't aware of all aspects of the system they are working on at all times is incompetent, and that cognitive load (that is, how many pieces of information the individual needs to keep 'in scope', mentally) is of no concern.
This seems to be reflected in your language design, for example, which focuses not on providing means of abstraction for more elaborate programming systems, but on channeling the programmers' workflow and trapping common error modes - that is to say, you are seeing using a higher level language primarily as a way to add error detection and allow ease of portability for what is basically assembly level programming. Please correct me if I am mistaken, here.
And quite frankly, your aggressive defense of positions that are out of scope in discussions, and your equally aggressive mockery of anyone and everyone that you see as disagreeing with you (whether they actually are or not), comes across as rather insecure to me, and, I suspect, most of the posters here. I don't think that this is actually the case, but it is how you sound, and it interferes with clear communication in this group. How you say things affects how others interpret what you are saying, and in this case, it is impacting it in a very negative way.
Now, please do not take this as a personal attack. I am saying this mainly to give you a bit of reflection on how other perceive your statements, which should, if nothing else, help you clarify what you are saying in the future. Take it as feedback, not criticism, and I will try to do the same for your reply.