1

As we know, modern CPU is able to execute multi commands concurrently: https://en.wikipedia.org/wiki/Out-of-order_execution

As a result, we may get such a fact as below:

When we execute the c++ code: x = a + b; y = c + d;, y = c + d; may be executed before x = a + b;.

My question is if it is possible to disable the out-of-order execution of CPU?

Yves
  • 11,597
  • 17
  • 83
  • 180
  • 5
    If it is functionally equivalent, what difference does it make? – Rishikesh Raje Oct 24 '18 at 11:20
  • You could put a serializing instruction between every normal instruction, why though? – harold Oct 24 '18 at 11:21
  • 1
    Note that the granularity of instructions being executed out of order on a CPU seldom would match individual statements in a higher-level language like C++. Also note that the C++ compiler itself may rearrange statements or even expressions or parts of expressions. – Some programmer dude Oct 24 '18 at 11:23
  • There is no apparent reason why you'd like to do such a thing. – Maxim Egorushkin Oct 24 '18 at 11:23
  • 3
    As for your question, ***why*** do you want to do this? What is the *real* problem you need to solve? What is the use-case? This looks very much like an [XY problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). – Some programmer dude Oct 24 '18 at 11:23
  • 1
    The question is why you would want to do this? Barring any bugs, the CPU are only allowed to reorder execution when the new order won't have any observable effect. The compiler will also reorder executions, and to a much larger degree than the type of out of order execution that a CPU does. – Lie Ryan Oct 24 '18 at 11:25
  • If there was a way to control the CPU's instruction scheduler, this is something that would be completely architecture-dependent (and probably processor-model-dependent), and certainly not within the scope of standard C++. – Toby Speight Oct 24 '18 at 13:15
  • 1
    @LieRyan There's always Spectre/Meltdown. :P:P:P – Mysticial Oct 24 '18 at 15:21
  • I think it's a shame that this question was tagged `c++` and thus closed as a dupe of a question that's only tangentially related. I came here to learn if modern CPUs have bits to disable this. Spectre/Meltdown is a good example on why one might want to disable fancy features like this in a security context, for debugging, or whatnot. – pipe Jan 14 '20 at 17:48

4 Answers4

4

No, you can't deactivate such hardware mechanism when it has it. That's what gives you performance. That's how the CPU is designed.

What C++ guarantees is that you won't be able to see the difference between what you want with the proper order, and what you will get. And that's also something that vendors like Intel will make sure for the assembly.

Have a look at https://www.youtube.com/watch?v=FJIn1YhPJJc&frags=pl%2Cwn for the C++ execution model.

Matthieu Brucher
  • 21,634
  • 7
  • 38
  • 62
1

All you should care about is the meaning of your program. That's not being pedantic, it is the fundamental basis around which the entire language has been designed.

A C++ program describes the meaning of a program. It is not a one-to-one mapping of source code to what a computer should literally do.

If you want that, you will have to code in assembly or perhaps some old-fashioned language from the middle ages, but even then you are going to have a hard time telling a modern CPU not to do all the clever things that it is designed to do in order to support useful programs. Certainly I'm not aware of any out-of-the-box switch, flag or setting that makes this happen; it would go against the grain of the very architecture of a CPU.

Ultimately you may be better off building and programming a Difference Engine ;)

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • No, the meaning of your program is not all you should care about. The actual execution may have disastrous consequences, such as Spectre and Meltdown. – Eric Postpischil Oct 24 '18 at 11:30
  • @EricPostpischil When writing C++ the meaning of your program is all you should care about. The consequences of Spectre and Meltdown are not the responsibility of a C++ program author, which is why those issues were fixed by kernel patches. Of course we can probably come up with some edge case exceptions but they are not the general rule and I can't imagine they apply here. – Lightness Races in Orbit Oct 24 '18 at 11:33
  • The allegation that consequences of processors design flaws are not the “responsibility” of a C++ author does not mean it is not perfectly reasonable for a C++ author to inquire about these things, to think about what the consequences might be, to learn about the isses and reason about how they affect their role, to think about mitigations they could provide even if it is not their “responsibility,” to engage in discussions with processor designers, and to otherwise improve their professional knowledge and participation. – Eric Postpischil Oct 24 '18 at 11:37
  • 2
    @EricPostpischil Certainly one should inquire and think and learn and reason as to what the _compiled_ program is going to be doing and why. That's great. Just one should not write their original C++ code with the viewpoint that the computer is or should be under any obligation to execute their lines of source code one at a time exactly as written. Understanding _and accepting_ that C++ is an abstraction and that all you're doing is specifying a program's _meaning_ is of critical importance. – Lightness Races in Orbit Oct 24 '18 at 11:40
  • @EricPostpischil Also I take exception with your use of the term "allegation", which has a very negative/accusational connotation which is not at all warranted. Let's keep it professional. – Lightness Races in Orbit Oct 24 '18 at 11:42
  • Allegation is correct. Telling people that some knowledge is inappropriate dissuades learning and is a bad thing. Promoting ignorance is harmful, both to the profession and to humanity in general. – Eric Postpischil Oct 24 '18 at 11:47
  • The opening statement of this answer is also unnecessary to address the question. Quite likely, the OP’s question arises out of incomplete understanding of out of order execution due to compiler optimization and out of order execution due to processor design. But these issues can be explained without any assertion about what a human ought or ought not to care about. The behavior of the program, the compiler, and the processor are entirely separate from what a human “cares” about. A good answer could simply speak to the facts of the software and the computer. – Eric Postpischil Oct 24 '18 at 11:52
  • And a good answer could explain why these issues **usually** (but not always) do not matter to a C++ programmer without telling them whether or not they should care. – Eric Postpischil Oct 24 '18 at 11:54
  • First sentence is misleading and somewhat redundant. C++ could definitely include specifications of side channel leaks, nothing impossible here. C++ was once a single-threaded language. – Euri Pinhollow Oct 24 '18 at 12:10
  • Will consider revisiting this conversation when the other party finds himself capable of communicating without using terms like "ignorance". – Lightness Races in Orbit Oct 24 '18 at 13:21
1

You cannot deactivate the reordering at the hardware level (CPU level).

However, you can ensure that the compiler will not reorder by using the optimization level of debug.

This will help in debugging the program, but it will make your code slow. It is not recommended in production code.

Rishikesh Raje
  • 8,556
  • 2
  • 16
  • 31
-2

It's not possible to disable out-of-order execution from the program, this is the well-known problem of Memory Barrier. As the problem consequences appear in multi-threading programs only, you have to use synchronization primitives to ensure the execution order.

serge
  • 992
  • 5
  • 8
  • Race conditions are related to out of order execution tangentially at most. – Euri Pinhollow Oct 24 '18 at 12:08
  • The question was asking about reordering within a single thread, not about sequencing between threads. – Toby Speight Oct 24 '18 at 13:12
  • Coincidentally `lfence` turns out to also be a commonly used serializing instruction on x86, but that's not what memory barriers were really meant for – harold Oct 24 '18 at 13:24
  • @TobySpeight the question was answered in general manner including both single and multi-threaded programs. In the single-thread program there is no flaws. What's the problem? – serge Oct 24 '18 at 13:27
  • @EuriPinhollow no, as you can see in Wiki example, there are no race conditions but processing re-order shows unexpected results in the first thread. – serge Oct 24 '18 at 13:35
  • @serge the question never touched problems which arise out of speculative execution. Besides that, 1) if there was a way of disabling speculative execution it would fix something a magnitude of 0.001% of erroneous multi threaded programs which do not have synchronization because 1.1) you still have instruction reordering in most implementations of most languages 1.2) fixing order of execution does not make it possible to write correct programs without using synchronization instructions in general case. 2) your post says nothing about data leakage which does not require multiple threads. – Euri Pinhollow Oct 24 '18 at 16:39
  • @EuriPinhollow please do not flame or go offtopic. The **question is directly related to the memory barrier**. Source: _Memory barriers are necessary because most modern CPUs employ performance optimizations that can result in out-of-order execution_ – serge Oct 24 '18 at 18:46
  • @serge out of order execution is only one of the reasons for necessity of memory barriers and visibility of memory effects is only one of the aspects of out of order execution. – Euri Pinhollow Oct 25 '18 at 07:45
  • @EuriPinhollow so the memory barrier is one of solutions. Thank you to confirm my answer. – serge Oct 25 '18 at 09:33