I really wish that you can advice me on how to present this problem because
it does seem like I may be incapable of putting it into words. Like please
do a counter proposal, I would really appreciate it.
Regards, Muneem.

On Sat, 4 Apr 2026, 6:43 am Muneem, <itfllow123_at_[hidden]> wrote:

> I am really really sorry if my response was no satisfactory.
> In short, all I want is to solve the problem where we can't tell the
> compiler to "render an object of any type in place at the intermediate code
> level". This problem is a problem because we have to do it our selves
> unlike in languages like GO. One this problem is solved then heterogenous
> lists would be possible.
> Regards, Muneem
>
> On Sat, 4 Apr 2026, 6:24 am Steve Weinrich via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> Hi Maneem,
>>
>> I had hoped by asking you to explain the problem you are trying to solve,
>> I might be able to help you describe things in a way that would make it
>> easier for you to describe the exact language feature you are proposing.
>>
>> Either am not smart enough to understand you (a good probability) or you
>> are incapable of describing what you seek in C++ language terms. Keep in
>> mind that the committee only deals on the language!
>>
>> I wish you all the best.
>>
>> Cheers,
>> Steve
>>
>> On Fri, Apr 3, 2026, 19:09 Muneem via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Thank you for your response!
>>> what is the problem(the question you asked)?
>>> There are many possible answers to what your question might have
>>> meant(hope any of these answer you):
>>>
>>> 1.This problem before c++ existed and before it had this static type
>>> system could be quantified as branching overhead and verbosity, and why we
>>> needed better techniques that avoided it.
>>> This wilkipedia article explains the first time that branching was a
>>> problem(all credits to wilkipedia:
>>> https://en.wikipedia.org/wiki/Branch_table):
>>> Use of branch tables and other raw data encoding was common in the early
>>> days of computing when memory was expensive, CPUs were slower and compact
>>> data representation and efficient choice of alternatives were important.
>>> This fact is truer now more than ever. In particular the issue in
>>> branching: pointer redirection using any implementation like vtables or
>>> function pointers. Sometimes, branching may infact be faster, but again,
>>> constructs that give no context and intent to the compiler are hard for the
>>> compiler to decide what to do with. This is why c++ came and provides if
>>> statements, switch statements, ternary statements, and many more so that it
>>> can provide the best intermediate code representation possible. Each type
>>> of branch statements isn't just a new syntax but it makes a user write a
>>> certain way, and let's the compiler do optimizations before the compiler
>>> backend reads the code.
>>>
>>> 2. The problem is the lack of a construct for describing a language
>>> level construct for type erasure that can result in optimized intermediate
>>> representation of the code.
>>>
>>> 3.The problem is virtual functions don't do it, switch case statements
>>> don't do it, nothing does, manual type erasure code dosent so it. The "it"
>>> is type erasure patterns. Switch case (and others) statements fails
>>> completely if you don't write code for each object again and again.
>>>
>>> 4. The problem is verbosity of current branching/polymorphism techniques
>>> for type erasure. Not only that but you can't even overload a polymorphic
>>> function to return a different type based on an argument(unless the return
>>> type is a polymorphic class(known as "Return Type Relaxation" in C++ 4th by
>>> Bajrne Stroustrup" section 20.3.6)) in order to fix this problem by the
>>> visitor pattern or some other double dispatch pattern.
>>>
>>> 5. The problem is lack of clear expression of type erasure.
>>>
>>>
>>> 2. I don't want make an heterogeneous list in the traditional sense, but
>>> rather a list of const references of any type, so it isnt against c++
>>> philosophies, it's just trying to automate the process of manual type
>>> erasure and leave it to the compiler to produce optimal intermediate code
>>> representation based on the specific program, context of every
>>> subscripting, and the source of every subscripting operation. That is as
>>> c++ as one can get. It would not be c++ if I were to just ask for
>>> heterogeneous list that is completely up to the implementation, but rather
>>> I want type erasure for const lvalue references at a language
>>> level(optimized intermediate code representation). Think of it like
>>> templates, if it helps making it easy to reason. In fact, this is a form of
>>> "Return Type Relaxation"(in C++ 4th by Bajrne Stroustrup" section 20.3.6),
>>> but instead of pointers and references, but I want only want to use const
>>> references.
>>>
>>>
>>>
>>> On Sat, 4 Apr 2026, 5:22 am Steve Weinrich via Std-Proposals, <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> Hi Muneem,
>>>>
>>>>
>>>>
>>>> I am not trying to be difficult, but the “problems” that you have
>>>> described are {potentially} the result of implementation choices and/or C++
>>>> limitations. What I am currently interested in is the problem that was
>>>> presented before making those choices.
>>>>
>>>>
>>>>
>>>> Let me see if I can give an example. Someone says, I have a problem.
>>>> Every time I insert on object into std::vector, I have to re-sort the
>>>> vector. Obviously, they are using the wrong container. *But even if
>>>> they switch to a std::map, we don’t know if the data truly needs to be
>>>> sorted. Or how frequently it needs to be sorted.*
>>>>
>>>>
>>>>
>>>> You say, “You want to choose between three container objects but they
>>>> don't have different type.”
>>>>
>>>>
>>>>
>>>> That could look like:
>>>>
>>>>
>>>>
>>>> std::vector<int> alpha;
>>>>
>>>> std::vector<int> beta;
>>>>
>>>> std::vector<int> gamma;
>>>>
>>>>
>>>>
>>>> This immediately raises the question, “Why three vectors?”
>>>>
>>>>
>>>>
>>>> You say, “You want to choose between any three objects but they have
>>>> different types.”
>>>>
>>>>
>>>>
>>>> That could look like:
>>>>
>>>>
>>>>
>>>> class Alpha
>>>>
>>>> {
>>>>
>>>> public:
>>>>
>>>> int funcA ();
>>>>
>>>>
>>>>
>>>> private:
>>>>
>>>> // Some Alpha specific data
>>>>
>>>> };
>>>>
>>>>
>>>>
>>>> class Beta
>>>>
>>>> {
>>>>
>>>> public:
>>>>
>>>> int funcA ();
>>>>
>>>>
>>>>
>>>> private:
>>>>
>>>> // Some Beta specific data
>>>>
>>>> };
>>>>
>>>>
>>>>
>>>> class Gamma
>>>>
>>>> {
>>>>
>>>> public:
>>>>
>>>> int funcA ();
>>>>
>>>>
>>>>
>>>> private:
>>>>
>>>> // Some Gamma specific data
>>>>
>>>> };
>>>>
>>>>
>>>>
>>>> That immediately raises the question, “Will virtual functions work?”
>>>>
>>>>
>>>>
>>>> So I ask again, what is the problem (not the solution)?
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Steve
>>>>
>>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On
>>>> Behalf Of *Muneem via Std-Proposals
>>>> *Sent:* Friday, April 3, 2026 6:03 PM
>>>> *To:* std-proposals_at_[hidden]
>>>> *Cc:* Muneem <itfllow123_at_[hidden]>
>>>> *Subject:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>>>> proposed
>>>>
>>>>
>>>>
>>>> An extended reason to why this class of problems described in the
>>>> previous emails exists is because the current constructs dosent give enough
>>>> context to intermediate code generation, and solely rely on llvms or other
>>>> backends to be advanced enough, which for languages don't make sense
>>>> because language are meant to be less verbose and more explicit than a
>>>> compiler backend code generation tools.
>>>>
>>>>
>>>>
>>>> (Really Sorry for sending two emails at one)
>>>>
>>>>
>>>>
>>>> Regards, Muneem.
>>>>
>>>>
>>>>
>>>> On Sat, 4 Apr 2026, 4:54 am Muneem, <itfllow123_at_[hidden]> wrote:
>>>>
>>>> The actual class of problems is code repitition and obscurement of
>>>> intent:
>>>>
>>>> 1.Say you want to choose between three container objects but they don't
>>>> have different type.
>>>>
>>>> 2. Say you want to choose between any three objects but they have
>>>> different types.
>>>>
>>>>
>>>>
>>>> The current fix for both, to allocate those objects in a
>>>> std::vector/array of std::variant element type or to use switch statements.
>>>> All of these obscure intent making it hard to optimize code in intermediate
>>>> code generation. This is actually more common than we think, infact, we can
>>>> destroy 99% of germs(branch statements) with function objects that can be
>>>> indexed.
>>>>
>>>>
>>>>
>>>> In short the class of problems is using too many branch statements for
>>>> everything that can't be indexed by current containers.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, 4 Apr 2026, 4:24 am Steve Weinrich via Std-Proposals, <
>>>> std-proposals_at_[hidden]> wrote:
>>>>
>>>> Hi Muneem,
>>>>
>>>>
>>>>
>>>> You mention “this class of problems” I would like to know what that
>>>> is? Please forget about a heterogenous list. What is the root problem
>>>> that the heterogenous list solves? Please describe an actual problem, not
>>>> a “it would be nice to solve.”
>>>>
>>>>
>>>>
>>>> To make this a little easier and to involve less people, here is my
>>>> email: weinrich.steve_at_[hidden]
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Steve
>>>>
>>>>
>>>>
>>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On
>>>> Behalf Of *Muneem via Std-Proposals
>>>> *Sent:* Friday, April 3, 2026 5:17 PM
>>>> *To:* std-proposals_at_[hidden]
>>>> *Cc:* Muneem <itfllow123_at_[hidden]>
>>>> *Subject:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>>>> proposed
>>>>
>>>>
>>>>
>>>> Thanks for your interested ❤️❤️❤️
>>>>
>>>> If you believe that any other solution maybe a better option for this
>>>> class of problems then please let me know. In fact, we would collaborate on
>>>> the proposal. This is not at odds with c++ because the (recommended)
>>>> semantics is a construct that captures values using const references, as
>>>> opposed to storing them directly as a struct would, and for the compiler to
>>>> access the value by reference, inline code for each branch, or do what it
>>>> thinks it best. It is similiar to the heterogeneous lists provided by GO
>>>> but it isn't because it captures by const value reference, and references
>>>> aren't the same as non const pointers, in the that they can be optimized
>>>> like const pointer can't be. Sorry for writing too much, I just got too
>>>> excited by someone taking openly interest in this proposal ❤️❤️❤️❤️.
>>>>
>>>>
>>>>
>>>> Regards, Muneem
>>>>
>>>>
>>>>
>>>> On Sat, 4 Apr 2026, 4:11 am Steve Weinrich via Std-Proposals, <
>>>> std-proposals_at_[hidden]> wrote:
>>>>
>>>> Hi Muneem,
>>>>
>>>>
>>>>
>>>> Thanks. I am interested in the original problem. I am curious if a
>>>> heterogeneous list is the optimal solution for the problem at hand. Over
>>>> the last 50+ years of programming, I have encountered many questions like
>>>> yours, which presume a particular solution. Sometimes that solution is at
>>>> odds with the language at hand (or other issues). I find that
>>>> understanding the original problem allows me to better understand why one
>>>> is suggesting a particular language enhancement.
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Steve
>>>>
>>>>
>>>>
>>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On
>>>> Behalf Of *Muneem via Std-Proposals
>>>> *Sent:* Friday, April 3, 2026 5:03 PM
>>>> *To:* std-proposals_at_[hidden]
>>>> *Cc:* Muneem <itfllow123_at_[hidden]>
>>>> *Subject:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>>>> proposed
>>>>
>>>>
>>>>
>>>> >context for readers:second one was a class of problems fixed by
>>>> heterogeneous lists.
>>>>
>>>> It's the second one, and I am really really sorry for the confusion.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, 4 Apr 2026, 3:58 am Steve Weinrich via Std-Proposals, <
>>>> std-proposals_at_[hidden]> wrote:
>>>>
>>>> If I may, a heterogeneous list is not a problem, it is a solution to a
>>>> problem. So there are now two possibilities:
>>>>
>>>> 1. You are trying to create a new std container to solve a class of
>>>> problems.
>>>> 2. You have some other problem that you have used a heterogenous
>>>> list to solve.
>>>>
>>>>
>>>>
>>>> What say you?
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Steve
>>>>
>>>>
>>>>
>>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On
>>>> Behalf Of *Muneem via Std-Proposals
>>>> *Sent:* Friday, April 3, 2026 4:54 PM
>>>> *To:* std-proposals_at_[hidden]
>>>> *Cc:* Muneem <itfllow123_at_[hidden]>
>>>> *Subject:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>>>> proposed
>>>>
>>>>
>>>>
>>>> Sorry, I meant "heterogeneous lists is the problem", so really really
>>>> sorry for that mistake, It was an auto correct mistake.
>>>>
>>>>
>>>>
>>>> On Sat, 4 Apr 2026, 3:52 am Muneem, <itfllow123_at_[hidden]> wrote:
>>>>
>>>> Heterogeneous problems is the problem that leads to the code bloat or
>>>> verbosity that I described, but it's hard to chose weather chicken came
>>>> first or the egg in this regard.
>>>>
>>>>
>>>>
>>>> Regards, Muneem
>>>>
>>>>
>>>>
>>>> On Sat, 4 Apr 2026, 3:50 am Steve Weinrich via Std-Proposals, <
>>>> std-proposals_at_[hidden]> wrote:
>>>>
>>>> Hi Muneem,
>>>>
>>>>
>>>>
>>>> If you don’t mind, I would like to limit this portion of our
>>>> interaction to simply describing the problem. I want to get a 100%
>>>> understanding of the problem, unfettered by any assumptions (including C++
>>>> limitations) or previous solutions. Is a heterogenous list actually the
>>>> problem or is that simply a solution that you think fits the problem at
>>>> hand?
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Steve
>>>>
>>>>
>>>>
>>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On
>>>> Behalf Of *Muneem via Std-Proposals
>>>> *Sent:* Friday, April 3, 2026 4:40 PM
>>>> *To:* std-proposals_at_[hidden]
>>>> *Cc:* Muneem <itfllow123_at_[hidden]>
>>>> *Subject:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>>>> proposed
>>>>
>>>>
>>>>
>>>> Hi!
>>>>
>>>> Thanks for your response!!!
>>>>
>>>>
>>>>
>>>> Yes, your understanding of the problem is mostly correct with a few
>>>> details left out. The alternative to using classes would be switch
>>>> statements that as discussed would lead to code bloat and might backfire.
>>>> The goal is to make a construct that makes the indexing into heterogenous
>>>> lists more easy. There is how ever one thing that I would like to clarify:
>>>>
>>>> The goal isn't the classic polymorphism but to be able to return an
>>>> object of any type through a specified interface(indexing heterogenous
>>>> lists), which your example dosent do. Basically, just like GO and many
>>>> other compiled languages support heterogenous lists, I want c++ to do so as
>>>> well. Say you want index a bunch of containers(to use top()
>>>> function),std::visit fails because it can't return any return type that you
>>>> would wish for, so you can either use switch case to write expression top
>>>> for each container or this long verbose technique:
>>>>
>>>> #include<vector>
>>>>
>>>> #include<deque>
>>>>
>>>> template<typename T>
>>>>
>>>> struct Base{
>>>>
>>>> virtual T top_wrapper();
>>>>
>>>> };
>>>>
>>>>
>>>>
>>>> template<typename T>
>>>>
>>>> struct Derived_1: Base<T>, std::vector<T>{
>>>>
>>>> T top_wrapper() override{
>>>>
>>>> return T{*this.top()};//T{} is just to show that it works
>>>> even if top had some other return type
>>>>
>>>> }
>>>>
>>>> };
>>>>
>>>> template<typename T>
>>>>
>>>> struct Derived_2: Base<T>, std:: deque<T>{
>>>>
>>>> T top_wrapper() override{
>>>>
>>>> return T{*this.top()};//T{} is just to show that it works
>>>> even if top had some other return type
>>>>
>>>> }
>>>>
>>>> };
>>>>
>>>> int main(){
>>>>
>>>> std::vector<Base<int>> a;
>>>>
>>>> //The compiler would probably optimize this example, but not an example
>>>> where you index the vector using real time input
>>>>
>>>> return 0;
>>>>
>>>> }
>>>>
>>>> //An vector of std::variant only works if I am willing to write a
>>>> helper top(std::variant<Args...> obj) function that includes std::visit to
>>>> call top(), that in of itself is not only verbose but obscures intent and
>>>> context.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards, Muneem.
>>>>
>>>>
>>>>
>>>> On Sat, 4 Apr 2026, 2:43 am Steve Weinrich via Std-Proposals, <
>>>> std-proposals_at_[hidden]> wrote:
>>>>
>>>> Hi Muneem,
>>>>
>>>>
>>>>
>>>> I would like to make sure that I understand this problem before going
>>>> on.
>>>>
>>>>
>>>>
>>>> I think there are several classes that have a portion (or all) of their
>>>> interface in common. Each method of the interface returns a constant value:
>>>>
>>>>
>>>>
>>>> class First
>>>>
>>>> {
>>>>
>>>> public:
>>>>
>>>> int funcA () const { return 1123; }
>>>>
>>>> int funcB () const ( return 1234; }
>>>>
>>>> int funcC () const { return 1456; }
>>>>
>>>> };
>>>>
>>>>
>>>>
>>>> class Second
>>>>
>>>> {
>>>>
>>>> public:
>>>>
>>>> int funcA () const { return 2123; }
>>>>
>>>> int funcB () const ( return 2234; }
>>>>
>>>> int funcC () const { return 2456; }
>>>>
>>>> };
>>>>
>>>>
>>>>
>>>> class Third
>>>>
>>>> {
>>>>
>>>> public:
>>>>
>>>> int funcA () const { return 3123; }
>>>>
>>>> int funcB () const ( return 3234; }
>>>>
>>>> int funcC () const { return 3456; }
>>>>
>>>> };
>>>>
>>>>
>>>>
>>>> 1. We would like a means to be able to add more classes easily.
>>>> 2. We would like a means to be able to add to the shared interface
>>>> easily.
>>>> 3. We would like to be able to use the shared interface in a
>>>> polymorphic way (like a virtual method).
>>>> 4. Performance is of the utmost importance.
>>>>
>>>>
>>>>
>>>> Is my understanding correct?
>>>>
>>>>
>>>>
>>>> Steve
>>>>
>>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On
>>>> Behalf Of *Muneem via Std-Proposals
>>>> *Sent:* Friday, April 3, 2026 1:54 PM
>>>> *To:* std-proposals_at_[hidden]
>>>> *Cc:* Muneem <itfllow123_at_[hidden]>
>>>> *Subject:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>>>> proposed
>>>>
>>>>
>>>>
>>>> Sorry for sending two emails at once!
>>>>
>>>> I just wanted to revise the fact that the point of the whole proposal
>>>> is to provide intent, the code that Mr. Maciera was kind enough to bring
>>>> forward proves my exact point, that with enough intent, the compiler can
>>>> optimize anythjng, and these optimizations grow larger as the scale of the
>>>> program grows larger. Microbenchmarks might show a single example but even
>>>> that single example should get us thinking that why is it so slow for this
>>>> one example? Does this overhead force people to write switch case
>>>> statements that can lead to code bloat which can again backfire in terms of
>>>> performance?
>>>>
>>>> Regards, Muneem.
>>>>
>>>>
>>>>
>>>> On Sat, 4 Apr 2026, 12:48 am Muneem, <itfllow123_at_[hidden]> wrote:
>>>>
>>>> Hi!
>>>>
>>>> Thanks again for your feedback, Macieira. 👍
>>>>
>>>> >micro benchmark is misleading
>>>>
>>>> 1. The reason that I gave you microbenchmarks is that some asked for
>>>> it, and even I was too relectunt to use them despite the quote of Bjarne
>>>> Stroustrups
>>>>
>>>> "Don't assume, measure" because in this case, the goal is to either
>>>> make the compiler smaller or runtime faster, both of which are targeted by
>>>> my new proposal.
>>>>
>>>> 2. You are right that the compiler might have folded the loop into
>>>> half, but the point is that it still shows that the observable behaviour
>>>> is the same, infact, if the loop body was to index into a heterogeneous
>>>> set(using the proposed construct) and do some operation then the compiler
>>>> would optimize the indexing if the source of the index is one. This proves
>>>> that intent. An help the compiler do wonders:
>>>>
>>>> 1.Fold loops even when I used volatile to avoid it.
>>>>
>>>> 2.Avoid the entire indexing operations (if in a loop with the most
>>>> minimal compile time overhead)
>>>>
>>>> 3. Store the result immediately after it takes input into some memory
>>>> location (if that solution is the fasted).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 3.Optimize a single expression for the sake of the whole program.
>>>>
>>>> Currently, the optimizer might in fact be able to optimize checks in a
>>>> loop, but it's not as easy or as gurrentied because there are no semantical
>>>> promises that we can make with the existing constructs to make it happen.
>>>>
>>>> 4.My main point isn't weather my benchmark is correct or wrong, but
>>>> rather that expressing intent is better. The bench mark was merely to show
>>>> that std::visit is slower (according to g++ and Microsoft visual studio
>>>> 2026 compiled programs, using std::chorno and visual studio 2026 CPU usage
>>>> measurement tools to prove my point), but even if some compiler or all
>>>> compilers optimize their performance; we still have compile time overhead
>>>> for taking std::visit and making it faster, and the optimization might
>>>> backfire since it would be to optimize single statements independent of
>>>> what's in the rest of the program. Why? Because unlike my proposed
>>>> construct, std::visit does not have enough context and intent to tell the
>>>> compiler what's going on so that it can generate code that has the exact
>>>> "book keeping" data and access code that fits the entire program.
>>>>
>>>>
>>>>
>>>> 3. In case, someone's think a few nano seconds in a single example
>>>> isn't a big deal, then rethink it because if my construct is passed then
>>>> yes, it would not be a big deal because the compiler can optimize many
>>>> indexing operations into a single heterogenous set and maybe cache the
>>>> result afterwards somewhere. The issue is that this can't be done with the
>>>> current techniques because of the lack of intent. Compilers are much
>>>> smarter than we could ever be because they are work of many people's entire
>>>> career, not just one very smart guy from Intel, so blaming/restricting
>>>> compilers whose job is to be as general for the sake of the whole program.
>>>>
>>>> 4.>I suppose it decided to unroll the loop a >bit
>>>>
>>>> >and made two calls to sink() per loop:
>>>>
>>>> >template <typename T> void sink(const T >&) { asm volatile("" :::
>>>> "memory"); }
>>>>
>>>> Even if it optimized switch case statement using volatile("" :::
>>>> "memory"); but not std::visit
>>>>
>>>> That's my point isn't that switch case is magically faster, but rather
>>>> the compiler has more room to cheat and skip things. Infact the standard
>>>> allows it a lot of free room as long as the observable behaviour is the
>>>> same, even more so by giving it free room with sets of observable
>>>> behaviours (unspecified behaviours)
>>>>
>>>> 5. Microbe marking wasent to show that std::visit is inherintly
>>>> slower, but rather the compiler can and should do mistakes in optimizing
>>>> it, in order to avoid massive compile time overhead.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, 3 Apr 2026, 8:33 pm Thiago Macieira via Std-Proposals, <
>>>> std-proposals_at_[hidden]> wrote:
>>>>
>>>> On Thursday, 2 April 2026 19:15:42 Pacific Daylight Time Thiago
>>>> Macieira via
>>>> Std-Proposals wrote:
>>>> > Even in this case, I have profiled the code above (after fixing it and
>>>> > removing the std::cout itself) and found that overall, the switched
>>>> case
>>>> > ran 2x faster, at 0.113 ns per iteration, while the variant case
>>>> required
>>>> > 0.227 ns per iteration. Looking at the CPU performance counters, the
>>>> > std::variant code has 2 branches per iteration and takes 1 cycle per
>>>> > iteration, running at 5 IPC (thus, 5 instructions per iteration).
>>>> > Meanwhile, the switched case has 0.5 branch per iteration and takes
>>>> 0.5
>>>> > cycle per iteration, running at 2 IPC. The half cycle numbers make
>>>> sense
>>>> > because I believe the two instructions are getting macrofused
>>>> together and
>>>> > execute as a single uop, which causes confusing numbers.
>>>>
>>>> This half a cycle and ninth of a nanosecond problem has been on my mind
>>>> for a
>>>> while. The execution time of anything needs to be a multiple of the
>>>> cycle
>>>> time, so a CPU running at 4.5 GHz line mine was shouldn't have a
>>>> difference of
>>>> one ninth of a nanosecond. One explanation would be that somehow the
>>>> CPU was
>>>> executing two iterations of the loop at the same time, pipelining.
>>>>
>>>> But disassembling the binary shows a simpler explanation. The switch
>>>> loop was:
>>>>
>>>> 40149f: mov $0x3b9aca00,%eax
>>>> 4014a4: nop
>>>> 4014a5: data16 cs nopw 0x0(%rax,%rax,1)
>>>> 4014b0: sub $0x2,%eax
>>>> 4014b3: jne 4014b0
>>>>
>>>> [Note how there is no test for what was being indexed in the loop!]
>>>>
>>>> Here's what I had missed: sub $2. I'm not entirely certain what GCC was
>>>> thinking here, but it's subtracting 2 instead of 1, so this looped half
>>>> a
>>>> billion times (0x3b9aca00 / 2). I suppose it decided to unroll the loop
>>>> a bit
>>>> and made two calls to sink() per loop:
>>>>
>>>> template <typename T> void sink(const T &) { asm volatile("" :::
>>>> "memory"); }
>>>>
>>>> But that expanded to nothing in the output. I could add "nop" so we'd
>>>> see what
>>>> happened and the CPU would be obligated to retire those instructions,
>>>> increasing the instruction executed counter (I can't quickly find how
>>>> many the
>>>> TGL processor / WLC core can retire per cycle, but I recall it's 6, so
>>>> adding
>>>> 2 more instructions shouldn't affect the execution time). But I don't
>>>> think I
>>>> need to further benchmark this to prove my point:
>>>>
>>>> The microbenchmark is misleading.
>>>>
>>>> --
>>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>