I usually find something to argue with but this seems pretty sensible. I'll just add that even application authors may have trouble understanding performance because they are often not running...
I usually find something to argue with but this seems pretty sensible.
I'll just add that even application authors may have trouble understanding performance because they are often not running code in the same environment as will be used in production. Consider a web application. What browsers are your users running? What machines do those browsers run on? What else is running on their machines at the same time?
And then consider that this will all change. Thanks to frequent, automatic upgrades, six months from now, most users will be running a newer browser version and a newer OS. How will future browsers optimize your code? It's not something you can test and it's out of your control. The machine mix will be somewhat different too.
To get an accurate picture of what's really going on, production logging is essential. (This is one reason why everyone wants to log metrics.) It's still useful to test locally, but you don't really know the impact until after a production release.
Embedded programming and game consoles are an exception since then you're targeting fixed hardware, so it's easier. Sometimes I wonder if we should have VM's that provide guaranteed, standardized performance like game emulation engines?
This reminded me of a lecture game developer Casey Muratori gave a while back. It's long, and it's been a while since I've seen it (so the following may be inaccurate), but the thesis he puts...
Embedded programming and game consoles are an exception since then you're targeting fixed hardware, so it's easier. Sometimes I wonder if we should have VM's that provide guaranteed, standardized performance like game emulation engines?
This reminded me of a lecture game developer Casey Muratori gave a while back. It's long, and it's been a while since I've seen it (so the following may be inaccurate), but the thesis he puts forward is that there are too many lines of code between a game and the hardware (operating system, graphics drivers, etc.), which makes it impossible to squeeze every last drop of performance out as you would have to understand the whole stack -- and of course the stack is different for different users.
In the end he proposes a versioned hardware platform, sort of like x86 provides a versioned instruction set. He envisions a game console-like system that has fixed specs and is programmed basically from bare-metal up, allowing you to have full control over the machine in order to eke out the last bit of performance -- I like to think of the idea as a standardized machine for running game-unikernels.
I'm not sure how practical all this is (probably not very), but it's still fascinating to think about.
Not really. It's more about not making promises that might break in the future. I've worked on a product where developers who used the product figured out some internal workings that were intended...
There are some feelings among library authors that libraries should be fairly opaque, and present high-level abstractions over their particular choices of algorithms, data structures, and so on. I think this represents a fundamental lack of trust with the programmer downstream.
Not really. It's more about not making promises that might break in the future. I've worked on a product where developers who used the product figured out some internal workings that were intended to be opaque and exploited them in a way that would have made our product much harder to maintain. We later changed the internal workings and their hack no longer worked. If we had documented it, they would have a legitimate grievance about it being changed out from underneath them. Because it was an undocumented implementation detail, we can rightly tell them, "We never intended it to be used that way, so we intentionally didn't document that aspect of the implementation because wanted to be able to change it in the future. If you're relying on undocumented behavior, it's on you if your product breaks with a future update of our code."
I usually find something to argue with but this seems pretty sensible.
I'll just add that even application authors may have trouble understanding performance because they are often not running code in the same environment as will be used in production. Consider a web application. What browsers are your users running? What machines do those browsers run on? What else is running on their machines at the same time?
And then consider that this will all change. Thanks to frequent, automatic upgrades, six months from now, most users will be running a newer browser version and a newer OS. How will future browsers optimize your code? It's not something you can test and it's out of your control. The machine mix will be somewhat different too.
To get an accurate picture of what's really going on, production logging is essential. (This is one reason why everyone wants to log metrics.) It's still useful to test locally, but you don't really know the impact until after a production release.
Embedded programming and game consoles are an exception since then you're targeting fixed hardware, so it's easier. Sometimes I wonder if we should have VM's that provide guaranteed, standardized performance like game emulation engines?
This reminded me of a lecture game developer Casey Muratori gave a while back. It's long, and it's been a while since I've seen it (so the following may be inaccurate), but the thesis he puts forward is that there are too many lines of code between a game and the hardware (operating system, graphics drivers, etc.), which makes it impossible to squeeze every last drop of performance out as you would have to understand the whole stack -- and of course the stack is different for different users.
In the end he proposes a versioned hardware platform, sort of like x86 provides a versioned instruction set. He envisions a game console-like system that has fixed specs and is programmed basically from bare-metal up, allowing you to have full control over the machine in order to eke out the last bit of performance -- I like to think of the idea as a standardized machine for running game-unikernels.
I'm not sure how practical all this is (probably not very), but it's still fascinating to think about.
Not really. It's more about not making promises that might break in the future. I've worked on a product where developers who used the product figured out some internal workings that were intended to be opaque and exploited them in a way that would have made our product much harder to maintain. We later changed the internal workings and their hack no longer worked. If we had documented it, they would have a legitimate grievance about it being changed out from underneath them. Because it was an undocumented implementation detail, we can rightly tell them, "We never intended it to be used that way, so we intentionally didn't document that aspect of the implementation because wanted to be able to change it in the future. If you're relying on undocumented behavior, it's on you if your product breaks with a future update of our code."