Now TRandom story. All RNDMs gave contradictory results.
Sometimes TRandom3 was twice slower than Trandom0
but sometimes result was the same.
Now I know why. It was optimized and non optimized code
I also added LCG random generator, proposed by D.Arhipkin
Optimized result is simple. All the generators about the same, but TRandom1 is very slow

TRandom0 Time =  38.19.            //Rndm float Geant3
TRandom1 Time = 841.25             //Rndm LUX
TRandom2 Time =  40.64.            //Tausworthe generator by L'Ecuyer.
TRandom3 Time =  37.26.            //T. Nishimura, Mersenne Twister
TRandom4 Time =  42.49.            // LCG proposed by Arhipkin

But it must be accounted hat STAR ROOT is non optimised.
So TpvRS could be 2 times faster
Victor

I want to clarify the problems. 

ZEBRA,Geant3, Comis and AtlSim are written in Fortran77. There is no pointers in Fortran.

So it could not be any problem in 32 to 64 conversion. But all the authors (J.Zoll,R.Brun,V.Berezhnoy and P.Nevski) are very professional and sophisticated. 

There are no pointers in Fortran, but they found a way to use them.

Some C routines return the address of the variables of functions as integers.

They know the memory organization and playing with these addresses to call functions and access to variables using shifts in addresses between them. It is working well when addresses are size of integer.  In Fortran there is 64 bit integer (integer*8) but it is close to impossible to use it in existing code. Now how to fix it:

1. Pointer to function is easy. Using std::map save the pointer in to map and return the position in map as a token;

2. Pointer in the array is more complicated. Two arrays could be very far from each other. But placing them in the main code close together, is possible to convince linker to keep them near. Using instead of pointers their  differences you can access one array using another one. 

3. The most complicated case in COMIS, where pointers are used in functions,in arrays, in local variables, even in character arrays. I solved all the cases, with exception of character variables. Hope next week will be fixed.

4. In addition I found a bug in AtlSim, Comis is used before initialization. Why it is affected only for 64 bits I do not know, I have no time to investigate it. I just change the code.

Now I have made all the needed corrections. It is working now on the kumac which I got from Jason.

 Results:

1. 32 bit version with my Comis is working exactly as in StarDev.

2. 64 bit version is working and give slightly different result, which Jason saw it in

   reconstruction.

3. 64bits is about 10% faster, as expected.

4. To be sure that the difference related not in random numbers, I wrote my own version of

   random numbers, based on integer only, to avoid real number difference. In my RNDM

   version, random numbers are not so good as official ones, but in 32/64 bits they are

   exactly the same. Result was unexpected. 32/64 versions gave again different result,

   but speed is 4 times faster both 32/64. One of explanation is that Nevski RNDM is very

   slow.
5. The official StarSim used RunLux  random. It is the best but not the fastest one. 

   I tried the standard Geant random, it is not as fast as mine, but it is 3 times faster

   than using RunLux. So, in StarSim/AtlsSim most time is spent in a random generator.

and 64bits Cosmics
=============