What about the hardware and CPU/GPU optimizations? Sure, if you’re running on bare metal, a metaprogram that decides what to compile and when it probably a good idea. If you’re running code inside a Linux Docker image preset for an x64 architecture, you might be getting in the way of what the CPU on the actual box is trying to do and create bizarre behavior or get slowed performance as the chip, the OS, the toolchain, and your metaprogram fights out what’s FI and what’s FO.
Are you disagreeing with the third (control) or fourth (performance) point? I don't understand what you're worrying about regarding containers? I have some strong opinions about containers, which I won't get into here. But notice that the metaprogram itself is just a program, the same way your compiler is a program. So if the container has problems with your metaprogram, the same would apply to your compiler.
I’m arguing that computers and operating systems today have their own optimizations and ways to run software, and your metaprogram could get in the way of that. It’s the same issue as when you try to micromanage multithreading. Instead of a performance boost, the result may actually be slower than sequential processing because you disrupted thread management processes with suboptimal behavior.
I don't understand what is the problem here. If somehow my "metaprogram could get in the way of that", then wouldn't the same apply for the compiler? The compiler could generate code that's slower on specific machines. It's important to note that the typical metaprogram doesn't generate machine code. It only generates normal language code that later get feed into the same compilation pipeline of the chosen compiler.
Theoretically, the compiler could generate suboptimal routines, yes. This is why languages have JIT optimization features that are customized for certain chipsets and operating systems. You’re effectively arguing for writing your own JIT optimizer instead of using one out of the box because you’re sure you can do better. My argument is that this is probably not going to be true more often than not:
Ah, I guess I've been misunderstanding what you've been trying to say. When you first mentioned containers, I thought you were worrying about running the metaprogram inside a container. That's why I keep saying running the metaprogram is just like running the compiler (emphasize the running part).
Docker is a weird example of platform-specific code (that's why I was confused). When I mentioned platform/target, I meant things like x86, x64, SSE, AVX, etc (ISA). Nowhere in the thread have I mentioned "writing your own JIT optimizer". I already said "the typical metaprogram doesn't generate machine code", and just to be clear, I also meant bytecode, IL, and IR.. What I had in my mind was something relatively simple, like switching between SSE and AVX intrinsics based on the target machine. You obviously can make something more complicated if you know what you're doing. The point is that with metaprogramming, you have the option to choose. You can do nothing, do something, or do a lot.
"Theoretically, the compiler could generate suboptimal routines, yes."
This, plus the Docker example, gives me the vibe that you haven't (nor know how to) read the generated code of any compiler, which is fine. If you don't want to or know how to do it, then just don't do it in your metaprogram. But don't go around arguing with people who do.
I’m trying to very politely hint that metaprograms the way you explain and approach them is a spherical chicken in a vacuum proposal to a very complicated topic with many different use cases. It’s not that I have a skill issue with IL code, I’ve had to decompile stuff plenty. It’s that I have an issue with blanket recommendations like this.
Part of the reason why the standard library suck so much is because C++ as a language is so poorly designed. Even so, creating a library API that bad is also an accomplishment.
Nice one! Waiting for the next post :)
What about the hardware and CPU/GPU optimizations? Sure, if you’re running on bare metal, a metaprogram that decides what to compile and when it probably a good idea. If you’re running code inside a Linux Docker image preset for an x64 architecture, you might be getting in the way of what the CPU on the actual box is trying to do and create bizarre behavior or get slowed performance as the chip, the OS, the toolchain, and your metaprogram fights out what’s FI and what’s FO.
Are you disagreeing with the third (control) or fourth (performance) point? I don't understand what you're worrying about regarding containers? I have some strong opinions about containers, which I won't get into here. But notice that the metaprogram itself is just a program, the same way your compiler is a program. So if the container has problems with your metaprogram, the same would apply to your compiler.
I’m arguing that computers and operating systems today have their own optimizations and ways to run software, and your metaprogram could get in the way of that. It’s the same issue as when you try to micromanage multithreading. Instead of a performance boost, the result may actually be slower than sequential processing because you disrupted thread management processes with suboptimal behavior.
I don't understand what is the problem here. If somehow my "metaprogram could get in the way of that", then wouldn't the same apply for the compiler? The compiler could generate code that's slower on specific machines. It's important to note that the typical metaprogram doesn't generate machine code. It only generates normal language code that later get feed into the same compilation pipeline of the chosen compiler.
Theoretically, the compiler could generate suboptimal routines, yes. This is why languages have JIT optimization features that are customized for certain chipsets and operating systems. You’re effectively arguing for writing your own JIT optimizer instead of using one out of the box because you’re sure you can do better. My argument is that this is probably not going to be true more often than not:
Ah, I guess I've been misunderstanding what you've been trying to say. When you first mentioned containers, I thought you were worrying about running the metaprogram inside a container. That's why I keep saying running the metaprogram is just like running the compiler (emphasize the running part).
Docker is a weird example of platform-specific code (that's why I was confused). When I mentioned platform/target, I meant things like x86, x64, SSE, AVX, etc (ISA). Nowhere in the thread have I mentioned "writing your own JIT optimizer". I already said "the typical metaprogram doesn't generate machine code", and just to be clear, I also meant bytecode, IL, and IR.. What I had in my mind was something relatively simple, like switching between SSE and AVX intrinsics based on the target machine. You obviously can make something more complicated if you know what you're doing. The point is that with metaprogramming, you have the option to choose. You can do nothing, do something, or do a lot.
"Theoretically, the compiler could generate suboptimal routines, yes."
It's not only theoretical, but it happens in practice a lot: https://x.com/cmuratori/status/1422771295989637121
This, plus the Docker example, gives me the vibe that you haven't (nor know how to) read the generated code of any compiler, which is fine. If you don't want to or know how to do it, then just don't do it in your metaprogram. But don't go around arguing with people who do.
I’m trying to very politely hint that metaprograms the way you explain and approach them is a spherical chicken in a vacuum proposal to a very complicated topic with many different use cases. It’s not that I have a skill issue with IL code, I’ve had to decompile stuff plenty. It’s that I have an issue with blanket recommendations like this.
Most of the C++ spec covers the standard library, not the language itself.
Don't even get me started on the standard library: https://www.twitch.tv/molly_rocket/clip/PlausibleRoughLeopardWutFace
Part of the reason why the standard library suck so much is because C++ as a language is so poorly designed. Even so, creating a library API that bad is also an accomplishment.
But just the base language itself is already very complex (especially compared to C). Parsing alone is already undecidable: https://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html