Non-lazy evaluation

An interesting CINT quirk:a conditional block will be interpreted even if the condition is false. For example, the following snipped of code runs three loops, but the third loop takes significantly longer to run despite that most of it is in an “if (0 == 1)” block.

Has anyone seen / noticed this before? Is there a way to tell CINT to use lazy evaluation?

Thanks,
Kris

=====

{

for ( int i = 0 ; i < 100000 ; i++ ) {
if ( i%1000 == 0 ) cerr << i << “…” ;
}

cerr << endl ;

for ( int h = 0 ; h < 100000 ; h++ ) {
if ( h%1000 == 0 ) cerr << h << “…” ;
if ( 0 == 1 ) cerr << “0 == 1\n” ;
}

cerr << endl ;

for ( int j = 0 ; j < 100000 ; j++ ) {
if ( j%1000 == 0 ) cerr << j << “…” ;
if ( 0 == 1 ) {
double pi = acos(-1.) ;
double e = 0 ;
for ( int k = 0 ; k < 100000 ; k++ ) {
int kfact = 1 ;
for ( int l = k ; l > 1 ; l-- ) {
kfact *= l ;
}
e += pow( -1., (double) k ) / (double) kfact ;
}
cerr << "pi = " << pi << endl ;
cerr << "e = " << e << endl ;
int m = 314923243 ;
for ( int n = 1 ; n < m ; n++ ) {
switch ( m%n ) {
case 0:
for ( int o = 0 ; o < 100000 ; o++ ) double p = atan( -.145123412 ) ;
break ;
case 0:
for ( int o = 0 ; o < 100000 ; o++ ) double p = atan( -.145123412 ) ;
break ;
case 0:
for ( int o = 0 ; o < 100000 ; o++ ) double p = atan( -.145123412 ) ;
break ;
case 0:
for ( int o = 0 ; o < 100000 ; o++ ) double p = atan( -.145123412 ) ;
break ;
case 0:
for ( int o = 0 ; o < 100000 ; o++ ) double p = atan( -.145123412 ) ;
break ;
case 0:
for ( int o = 0 ; o < 100000 ; o++ ) double p = atan( -.145123412 ) ;
break ;
case 0:
for ( int o = 0 ; o < 100000 ; o++ ) double p = atan( -.145123412 ) ;
break ;
case 0:
for ( int o = 0 ; o < 100000 ; o++ ) double p = atan( -.145123412 ) ;
break ;
default:
for ( int o = 0 ; o < 100000 ; o++ ) double p = atan( -.145123412 ) ;
break ;
}
}
}
}

cerr << endl ;

}

Hello,

It looks that the cause of slow execution of 3rd loop is due to limitation of bytecode optimization. The bytecode optimization was added afterwards to Cint, it has too much architectural complexity which causes bugs and limitations. In this particular case, switch statement in the 3rd loop hits the limitation. (See cint/doc/bytecode.txt)

There are a couple of ways to workaround this.

  1. Use if-else statement instead of switch.
  2. Separate if(0==1) block as a separate function.

Thank you
Masa Goto