Why there is no ISO hardware query interface?

Question

I'm currently reading a book, chapter about I/O, and one question came to my mind.

Basically, when you program in C/C++, you have an amazing opportunity to optimize for hardware behavior. Using buffering for block devices, use streaming and async I/O for high latency network devices and so on.

And if you're writing a server application that is targeted at high load applications, and you can optimize for I/O devices, that can actually change the hardware requirements tremendously. Say, you know that HDD cache is around 32MB, and it likes to stream data in 8MB blocks, and you have 16GB of RAM that's cheap and sitting idle, you could just use low level _read with a 8MB buffer and be done with it. Which would remove ton of locking and user->kernel->user transitions that's caused by smaller reads, say 64KB each.

The problem is, you basically have to run the program on target platform to get the actual performance data, and optimize for it. And if you port that application to say ARM, the optimizations can even backfire.

So why is there no API to get the sweet-spot values for architecture you're running on.

Say QueryOptimalHddReadBuffer, QueryOptimalHddWriteBuffer, QueryHddSeekTimeCharacteristics, QueryOptimalNetworkCardReadBuffer, etc.

Answer 1

I'd guess there are basically two reasons. First and foremost, I'd guess nobody's even attempted to submit a proposal for anything similar in a form that the committee could even hope to accept if they wanted to.

Second (and probably secondarily), I suspect there's an attitude that the implementation can and should do most such optimization more or less automatically. To use your example, there's a reason _read isn't standardized by C or C++, and fread is standardized instead -- it allows the implementation to do buffering, so instead of querying for the optimal read size for the system, it should just do the optimal read size automatically. I realize that what it chooses isn't optimal for every purpose, but I doubt a QueryOptimalHDDReadBuffer (etc.) would necessarily be any better.