`JE` and `JZ` are just different names for exactly the same thing: a
conditional jump when `ZF` (the &quot;zero&quot; flag) is equal to 1.

(Similarly, `JNE` and `JNZ` are just different names for a conditional jump
when `ZF` is equal to 0.)

You *could* use them interchangeably, but you *should* use them depending on
what you are doing:

* `JZ`/`JNZ` are more appropriate when you are explicitly testing
for something being equal to zero:

        dec  ecx
        jz   counter_is_now_zero

* `JE` and `JNE` are more appropriate after a `CMP` instruction:

        cmp  edx, 42
        je   the_answer_is_42

    (A `CMP` instruction performs a subtraction, and throws the value of the result away, while keeping the flags; which is why you get `ZF=1` when the operands are equal
and `ZF=0` when they&#39;re not.)


From the [Intel&#39;s manual - Instruction Set Reference](http://download.intel.com/products/processor/manual/325383.pdf), the `JE` and `JZ` have the same opcode (`74` for rel8 / `0F 84` for rel 16/32) also  `JNE` and `JNZ` (`75` for rel8 / `0F 85` for rel 16/32) share opcodes.

`JE` and `JZ` they both check for the `ZF` (or zero flag), although the manual differs slightly in the descriptions of the first `JE` rel8 and `JZ` rel8 `ZF` usage, but basically they are the same.

Here is an extract from the manual&#39;s pages 464, 465 and 467. 

     Op Code    | mnemonic  | Description
     -----------|-----------|-----------------------------------------------  
     74 cb      | JE rel8   | Jump short if equal (ZF=1).
     74 cb      | JZ rel8   | Jump short if zero (ZF ← 1).

     0F 84 cw   | JE rel16  | Jump near if equal (ZF=1). Not supported in 64-bit mode.
     0F 84 cw   | JZ rel16  | Jump near if 0 (ZF=1). Not supported in 64-bit mode.

     0F 84 cd   | JE rel32  | Jump near if equal (ZF=1).
     0F 84 cd   | JZ rel32  | Jump near if 0 (ZF=1).

     75 cb      | JNE rel8  | Jump short if not equal (ZF=0).
     75 cb      | JNZ rel8  | Jump short if not zero (ZF=0).

     0F 85 cd   | JNE rel32 | Jump near if not equal (ZF=0).
     0F 85 cd   | JNZ rel32 | Jump near if not zero (ZF=0).









      je : Jump if equal:
       
      399  3fb:   64 48 33 0c 25 28 00    xor    %fs:0x28,%rcx
      400  402:   00 00
      401  404:   74 05                   je     40b &lt;sims_get_counter+0x51&gt;


As I `SET` cust_fax in a table in MySQL like this:

    cust_fax integer(10) NOT NULL,

and then I insert value like this:

    INSERT INTO database values (&#39;3172978990&#39;);

but then it say 
&gt; \`error 1264` out of value for column

And I want to know where the error is? My set? Or other?

Any answer will be appreciated!

MySQL Error 1264: out of range value for column

In Python, I&#39;d like to write a function `make_cylinder_volume(r)` which returns another function. That returned function should be callable with a parameter `h`, and return the volume of a cylinder with height `h` and radius `r`.

I know how to return *values* from functions in Python, but how do I return *another function*?

How do I write a function that returns another function?

In x86 assembly code, are `JE` and `JNE` exactly the same as `JZ` and `JNZ`?

Difference between JE/JNE and JZ/JNZ

<p>In x86 assembly code, are <code>JE</code> and <code>JNE</code> exactly the same as <code>JZ</code> and <code>JNZ</code>?</p>


I can&#39;t find a good source that answers this question. I know that a nop sled is a technique used to circumvent stack randomization in a buffer overflow attack, but I can&#39;t get my head around how it works.

What&#39;s a simple example that illustrates this method?

What do terms like 128-byte nop sled mean?


How does a NOP sled work?

I am working on some Java code which needs to be highly optimized as it will run in hot functions that are invoked at many points in my main program logic. Part of this code involves multiplying `double` variables by `10` raised to arbitrary non-negative `int` `exponent`s. One fast way (edit: but not the fastest possible, see Update 2 below) to get the multiplied value is to `switch` on the `exponent`:

    double multiplyByPowerOfTen(final double d, final int exponent) {
       switch (exponent) {
          case 0:
             return d;
          case 1:
             return d*10;
          case 2:
             return d*100;
          // ... same pattern
          case 9:
             return d*1000000000;
          case 10:
             return d*10000000000L;
          // ... same pattern with long literals
          case 18:
             return d*1000000000000000000L;
          default:
             throw new ParseException(&quot;Unhandled power of ten &quot; + power, 0);
       }
    }

The commented ellipses above indicate that the `case` `int` constants continue incrementing by 1, so there are really 19 `case`s in the above code snippet. Since I wasn&#39;t sure whether I would actually need all the powers of 10 in `case` statements `10` thru `18`, I ran some microbenchmarks comparing the time to complete 10 million operations with this `switch` statement versus a `switch` with only `case`s `0` thru `9` (with the `exponent` limited to 9 or less to avoid breaking the pared-down `switch`). I got the rather surprising (to me, at least!) result that the longer `switch` with more `case` statements actually ran faster.

On a lark, I tried adding even more `case`s which just returned dummy values, and found that  I could get the switch to run even faster with around 22-27 declared `case`s (even though those dummy cases are never actually hit while the code is running). (Again, `case`s were added in a contiguous fashion by incrementing the prior `case` constant by `1`.) These execution time differences are not very significant: for a random `exponent` between `0` and `10`, the dummy padded `switch` statement finishes 10 million executions in 1.49 secs versus 1.54 secs for the unpadded version, for a grand total savings of 5ns per execution. So, not the kind of thing that makes obsessing over padding out a `switch` statement worth the effort from an optimization standpoint. But I still just find it curious and counter-intuitive that a `switch` doesn&#39;t become slower (or perhaps at best maintain constant *O(1)* time) to execute as more `case`s are added to it.  

![switch benchmarking results][1]


These are the results I obtained from running with various limits on the randomly-generated `exponent` values. I didn&#39;t include the results all the way down to `1` for the `exponent` limit, but the general shape of the curve remains the same, with a ridge around the 12-17 case mark, and a valley between 18-28. All tests were run in JUnitBenchmarks using shared containers for the random values to ensure identical testing inputs. I also ran the tests both in order from longest `switch` statement to shortest, and vice-versa, to try and eliminate the possibility of ordering-related test problems.  I&#39;ve put my testing code up on a github repo if anyone wants to try to reproduce these results.

So, what&#39;s going on here? Some vagaries of my architecture or micro-benchmark construction? Or is the Java `switch` really a little faster to execute in the `18` to `28` `case` range than it is from `11` up to `17`?

[github test repo &quot;switch-experiment&quot;][2]


  [1]: http://i.stack.imgur.com/kbnan.png
  [2]: https://github.com/abissell/switch-experiment

**UPDATE:** I cleaned up the benchmarking library quite a bit and added a text file in /results with some output across a wider range of possible `exponent` values. I also added an option in the testing code not to throw an `Exception` from `default`, but this doesn&#39;t appear to affect the results.

**UPDATE 2:** Found some pretty good discussion of this issue from back in 2009 on the xkcd forum here: http://forums.xkcd.com/viewtopic.php?f=11&amp;t=33524. The OP&#39;s discussion of using `Array.binarySearch()` gave me the idea for a simple array-based implementation of the exponentiation pattern above. There&#39;s no need for the binary search since I know what the entries in the `array` are. It appears to run about 3 times faster than using `switch`, obviously at the expense of some of the control flow that `switch` affords. That code has been added to the github repo also.

Why does Java switch on contiguous ints appear to run faster with added cases?

I have been trying to get an idea of the impact of having an array in L1 cache versus memory by timing a routine that scales and sums the elements of an array using the following code (I am aware that I should just scale the result by &#39;a&#39; at the end; the point is to do both a multiply and an add within the loop - so far, the compiler hasn&#39;t figured out to factor out &#39;a&#39;): 

    double sum(double a,double* X,int size)
    {
    	double total = 0.0;
    	for(int i = 0;  i &lt; size; ++i)
    	{
    		total += a*X[i];
    	}
    	return total;
    }
    
    #define KB 1024
    int main()
    {
        //Approximately half the L1 cache size of my machine
    	int operand_size = (32*KB)/(sizeof(double)*2);
    	printf(&quot;Operand size: %d\n&quot;, operand_size);
    	double* X = new double[operand_size];
    	fill(X,operand_size);
    
        double seconds = timer();
        double result;
        int n_iterations = 100000;
        for(int i = 0; i &lt; n_iterations; ++i)
        {
            result = sum(3.5,X,operand_size);
            //result += rand();  
        }
        seconds = timer() - seconds; 
    
        double mflops = 2e-6*double(n_iterations*operand_size)/seconds;
        printf(&quot;Vector size %d: mflops=%.1f, result=%.1f\n&quot;,operand_size,mflops,result);
    	return 0;
    }



Note that the timer() and fill() routines are not included for brevity; their full source can be found here if you want to run the code:

http://codepad.org/agPWItZS

Now, here is where it gets interesting. This is the output:

    Operand size: 2048
    Vector size 2048: mflops=588.8, result=-67.8

This is totally un-cached performance, despite the fact that all elements of X should be held in cache between loop iterations. Looking at the assembly code generated by:

    g++ -O3 -S -fno-asynchronous-unwind-tables register_opt_example.cpp

I notice one oddity in the sum function loop: 

    L55:
    	movsd	(%r12,%rax,8), %xmm0
    	mulsd	%xmm1, %xmm0
    	addsd	-72(%rbp), %xmm0
    	movsd	%xmm0, -72(%rbp)
    	incq	%rax
    	cmpq	$2048, %rax
    	jne	L55

The instructions: 

    	addsd	-72(%rbp), %xmm0
    	movsd	%xmm0, -72(%rbp)

indicate that it is storing the value of &quot;total&quot; in sum() on the stack, and reading and writing it at every loop iteration. I modified the assembly so that this operand is kept in a a register:

    ...
    addsd	%xmm0, %xmm3
    ...

This small change creates a **huge** performance boost: 

    Operand size: 2048
    Vector size 2048: mflops=1958.9, result=-67.8

**tl;dr**
My question is: why does replacing a single memory location access with a register, speed up the code so much, given that the single location should be stored in L1 cache? What architectural factors make this possible? It seems very strange that writing one stack location repeatedly would completely destroy the effectiveness of a cache. 

**Appendix**

My gcc version is: 

    Target: i686-apple-darwin10
    Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
    Thread model: posix
    gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)

My CPU is: 

Intel Xeon X5650

C++: Mysteriously huge speedup from keeping one operand in a register

I&#39;m a bit confused as to what the asm instruction db actually does. I&#39;ve read that it defines a byte, but what does that actually mean? Does it move the value into a certain place in memory, or does it predefine a value before the code is assembled? 

what does the assembly instruction &#39;db&#39; actually do?

**Background:**

While optimizing some [Pascal][1] code with embedded assembly language, I noticed an unnecessary `MOV` instruction, and removed it.

To my surprise, removing the un-necessary instruction caused my program to *slow down*.

I found that **adding arbitrary, useless `MOV` instructions increased performance** even further.

The effect is erratic, and changes based on execution order: **the same junk instructions transposed** up or down by a single line **produce a slowdown**.

I understand that the CPU does all kinds of optimizations and streamlining, but, this seems more like black magic.

**The data:**

A version of my code conditionally compiles **three junk operations** in the middle of a loop that runs `2**20==1048576` times. (The surrounding program just calculates [SHA-256][2] hashes).

The results on my rather old machine (Intel(R) Core(TM)2 CPU 6400  @ 2.13&amp;nbsp;GHz):

    avg time (ms) with -dJUNKOPS: 1822.84 ms
    avg time (ms) without:        1836.44 ms

The programs were run 25 times in a loop, with the run order changing randomly each time.

**Excerpt:**

    {$asmmode intel}
    procedure example_junkop_in_sha256;
      var s1, t2 : uint32;
      begin
        // Here are parts of the SHA-256 algorithm, in Pascal:
        // s0 {r10d} := ror(a, 2) xor ror(a, 13) xor ror(a, 22)
        // s1 {r11d} := ror(e, 6) xor ror(e, 11) xor ror(e, 25)
        // Here is how I translated them (side by side to show symmetry):
      asm
        MOV r8d, a                 ; MOV r9d, e
        ROR r8d, 2                 ; ROR r9d, 6
        MOV r10d, r8d              ; MOV r11d, r9d
        ROR r8d, 11    {13 total}  ; ROR r9d, 5     {11 total}
        XOR r10d, r8d              ; XOR r11d, r9d
        ROR r8d, 9     {22 total}  ; ROR r9d, 14    {25 total}
        XOR r10d, r8d              ; XOR r11d, r9d

        // Here is the extraneous operation that I removed, causing a speedup
        // s1 is the uint32 variable declared at the start of the Pascal code.
        //
        // I had cleaned up the code, so I no longer needed this variable, and 
        // could just leave the value sitting in the r11d register until I needed
        // it again later.
        //
        // Since copying to RAM seemed like a waste, I removed the instruction, 
        // only to discover that the code ran slower without it.
        {$IFDEF JUNKOPS}
        MOV s1,  r11d
        {$ENDIF}
        
        // The next part of the code just moves on to another part of SHA-256,
        // maj { r12d } := (a and b) xor (a and c) xor (b and c)
        mov r8d,  a
        mov r9d,  b
        mov r13d, r9d // Set aside a copy of b
        and r9d,  r8d

        mov r12d, c
        and r8d, r12d  { a and c }
        xor r9d, r8d

        and r12d, r13d { c and b }
        xor r12d, r9d

        // Copying the calculated value to the same s1 variable is another speedup.
        // As far as I can tell, it doesn&#39;t actually matter what register is copied,
        // but moving this line up or down makes a huge difference.
        {$IFDEF JUNKOPS}
        MOV s1,  r9d // after mov r12d, c
        {$ENDIF}

        // And here is where the two calculated values above are actually used:
        // T2 {r12d} := S0 {r10d} + Maj {r12d};
        ADD r12d, r10d
        MOV T2, r12d

      end
    end;

**Try it yourself:**

The code is online [at GitHub][3] if you want to try it out yourself.

**My questions:**

 - Why would uselessly copying a register&#39;s contents to [RAM][4] ever increase performance?
 - Why would the same useless instruction provide a speedup on some lines, and a slowdown on others?
 - Is this behavior something that could be exploited predictably by a compiler?

  [1]: http://en.wikipedia.org/wiki/Pascal_%28programming_language%29
  [2]: http://en.wikipedia.org/wiki/SHA-2
  [3]: https://github.com/tangentstorm/coinops/tree/junkops
  [4]: http://en.wikipedia.org/wiki/Random-access_memory


Why would introducing useless MOV instructions speed up a tight loop in x86_64 assembly?

I get that at the assembly language level instruction set architectures provide compare and swap and similar operations. However, I don&#39;t understand how the chip is able to provide these guarantees.

As I imagine it, the execution of the instruction must

1. Fetch a value from memory
2. Compare the value
3. Depending on the comparison, possibly store another value in memory

What prevents another core from accessing the memory address after the first has fetched it but before it sets the new value? Does the memory controller manage this?

edit: If the x86 implementation is secret, I&#39;d be happy to hear how any processor family implements it.

How are atomic operations implemented at a hardware level?

Is the x86 Architecture specially designed to work with a keyboard while ARM expects to be mobile? What are the key differences between the two?

How does the ARM architecture differ from x86?

This question is meant to fill the vacuum of good free information on the subject.

I believe that a good answer will fit into one big SO answer or at least in a few answers.

The main goal is to give complete beginners just enough info so that they can take the manual on their own, and be able to understand basic OS concepts related to paging.

Suggested guidelines:

- answers should be beginner friendly:
    - concrete, but possibly simplified examples are very important
    - applications of the concepts shown are welcome
- citing useful resources is good
- small digressions into how OSs use paging features are welcome
- PAE and PSE explanations are welcome
- small digressions into x86_64 are welcome 

Related questions and why I think they are not dupes:

- https://stackoverflow.com/questions/10671147/how-do-x86-page-tables-work: the title is almost the same as this question, but the body asks specific questions related to cr3 and TLB. That question is a subset of this one.

- https://stackoverflow.com/questions/4710354/how-does-x86-virtualization-work: body asks for sources only.

How does x86 paging work?

Often in internet I find that `LFENCE` makes no sense in processors x86, ie it does nothing , so instead `MFENCE` we can absolutely painless to use `SFENCE`, because `MFENCE` = `SFENCE` + `LFENCE` = `SFENCE` + `NOP` = `SFENCE`.

But if `LFENCE` does not make sense, then why we have four approaches to make Sequential Consistency in x86/x86_64:

1. `LOAD` (without fence) and `STORE` + `MFENCE`
2. `LOAD` (without fence) and `LOCK XCHG`
3. `MFENCE` + `LOAD` and `STORE` (without fence)
4. `LOCK XADD` ( 0 ) and `STORE` (without fence)

Taken from here: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html

As well as performances from Herb Sutter on page 34 at the bottom: https://skydrive.live.com/view.aspx?resid=4E86B0CF20EF15AD!24884&amp;app=WordPdf&amp;wdo=2&amp;authkey=!AMtj_EflYn2507c

If `LFENCE` did not do anything, then the approach (3) would have the following meanings: `SFENCE + LOAD and STORE (without fence)`, but there is no point in doing `SFENCE` before `LOAD`. Ie if `LFENCE` does nothing , the approach (3) does not make sense.

Does it make any sense instruction `LFENCE` in processors x86/x86_64?

**ANSWER:**

**1.** `LFENCE` required in cases which described in the accepted answer, below.

**2.** The approach (3) should be viewed not independently, but in combination with the previous commands. For example, approach (3):

    MFENCE
    MOV reg, [addr1]  // LOAD-1
    MOV [addr2], reg  //STORE-1
    
    MFENCE
    MOV reg, [addr1]  // LOAD-2
    MOV [addr2], reg  //STORE-2

We can rewrite the code of approach (3) as follows:

    SFENCE
    MOV reg, [addr1]  // LOAD-1
    MOV [addr2], reg  //STORE-1
    
    SFENCE
    MOV reg, [addr1]  // LOAD-2
    MOV [addr2], reg  //STORE-2

And here `SFENCE` makes sense to prevent reordering  STORE-1 and LOAD-2. For this after STORE-1 command `SFENCE` flushes Store-Buffer.

Does it make any sense to use the LFENCE instruction on x86/x86_64 processors?

I was testing some code on Visual Studio 2008 and noticed `security_cookie`. I can understand the point of it, but I don&#39;t understand what the purpose of this instruction is.

        rep ret /* REP to avoid AMD branch prediction penalty */

Of course I can understand the comment :) but what is this prefix exaclty doing in context with the `ret` and what happens if `ecx` is != 0? Apparently the loop count from `ecx` is ignored when I debug it, which is to be expected.

The code where I found this was here (injected by the compiler for security):

	void __declspec(naked) __fastcall __security_check_cookie(UINT_PTR cookie)
	{
		/* x86 version written in asm to preserve all regs */
		__asm {
			cmp ecx, __security_cookie
			jne failure
			rep ret /* REP to avoid AMD branch prediction penalty */
	failure:
			jmp __report_gsfailure
		}
	}


Content Type	Original Author	Original Content on Stackoverflow
Question	Daniel Hanrahan	View Question on Stackoverflow
Solution 1 - Assembly	Matthew Slattery	View Answer on Stackoverflow
Solution 2 - Assembly	higuaro	View Answer on Stackoverflow
Solution 3 - Assembly	leesagacious	View Answer on Stackoverflow

Difference between JE/JNE and JZ/JNZ

Assembly Problem Overview

Assembly Solutions

Solution 1 - Assembly

Solution 2 - Assembly

Solution 3 - Assembly

How do I write a function that returns another function?

MySQL Error 1264: out of range value for column

Attributions