ECL chooses integer types that are large enough to fit the user type declarations. It leaves the C compiler the task of choosing the appropriate internal representation and it seems to do it just fine.<div><br></div><div>Using int8_t</div>

<div><br></div><div><div>real time : 0.475 secs</div><div>run time  : 0.463 secs</div><div>gc count  : 2 times</div><div>consed    : 4000105 bytes</div><div>#P"/Users/jjgarcia/build/ecl/faa.lsp"</div><div><br></div>

<div>Using cl_fixnum = int on a 32 bits machine</div><div> </div><div>real time : 0.475 secs</div><div>run time  : 0.462 secs</div><div>gc count  : 1 times</div><div>consed    : 4000088 bytes</div><div>#P"/Users/jjgarcia/build/ecl/faa.lsp"</div>

<div><br></div>This is with a slightly larger number of executions than Jeronimo programmed (200 instead of 50)</div><div><br></div><div>For this larger an more meaningful number we reach SBCL:</div><div><br></div><div><div>

Evaluation took:</div><div>  0.485 seconds of real time</div><div>  0.480578 seconds of total run time (0.473391 user, 0.007187 system)</div><div>  99.18% CPU</div><div>  967,508,892 processor cycles</div><div>  4,000,008 bytes consed</div>

<div><br></div><div>BTW, I just uploded the code. But please expect no improvement on stability -- I am currently using OpenAxiom and other large pieces of software as a consistency check and it takes about five hours to build it all and make sure I did not break any hidden assumption.</div>

<div><br></div>Juanjo</div><div><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>
</div>