I get worse perfomances with jit.expr than jit.op for a simple addition.

I get worse perfomances with jit.expr than jit.op for a simple addition.
Could someone confirm or explain ?

jit-op-jit-expr

On 15 juil. 07, at 14:53, derrickgiscloux wrote:

> I get worse perfomances with jit.expr than jit.op for a simple 

jit.expr only deals with float 32, jit.op is able to deal with 

whatever type you send to. The other point is, no matter what, an 

expression evaluator will always be slower than something which 

> I get worse perfomances with jit.expr than jit.op for a simple  
> addition.
> Could someone confirm or explain ?

jit.expr only deals with float 32, jit.op is able to deal with  
whatever type you send to. The other point is, no matter what, an  
expression evaluator will always be slower than something which  
execute the same static code.

To be a bit more precise, jit.expr converts all non-float32 matrices to 

float32 before running the expression, and then converts back before 

output. This conversion is where you lose efficiency. Nonetheless, for 

native float32 calculations, jit.expr is surprisingly efficient. In 

your case, since you are using char data, your best bet is just to make 

a subpatch with cascaded jit.op objects. This will be the most 

To be a bit more precise, jit.expr converts all non-float32 matrices to 
float32 before running the expression, and then converts back before 
output.  This conversion is where you lose efficiency.  Nonetheless, for 
native float32 calculations, jit.expr is surprisingly efficient.  In 
your case, since you are using char data, your best bet is just to make 
a subpatch with cascaded jit.op objects.  This will be the most 
efficient possible solution.

jit.op // jit.expr