Thanks Ivan! Thanks to your results, I reproduced the problem.
I thought this might be a gcc version issue, since the fast versions were
compiled with 4.2.3 and the slow ones with 4.1 (Linux) or 4.0.1 (OS X). But,
recompiling with 4.1.3 on Linux did not reproduce the issue.
However, on my Debian x86 system, gcc defaults to building for an
Intel 486 architecture. On OS X, Apple set it to build for
the Core Duo (-march=nocona). When I recompiled the entire compiler
on OS X with -march=i386, the GCs and time disparity disappeared:
VALUES
22.512 s / 812 GCs / arch=nocona
2.558 s / 9 GCs / arch=i386
LIST
0.364 s / 6 GCs / arch=nocona
1.946 s / 6 GCs / arch=i386
LIST is 6x faster under arch=nocona, but VALUES is 10x slower.
I think what's happening is the Nocona version is generating much larger
alignments or larger stack frames which is filling up the C stack significantly
faster. That's probably what's happening with your slow system too (which is
64-bit). I didn't do further experiments to nail down exactly what.
I've never noticed this huge slowdown in any other code, so maybe it is
specific to this situation. It would be interesting to track down
exactly what is happening and maybe find a small optimization tweak
(a pessimization of sorts) which benefits Chicken code.
On 2/1/08, Ivan Raikov <[EMAIL PROTECTED]> wrote:
>
> Here are some results for Core 2 Duo and 4-core Xeon in Linux. I get a
> small difference in performance of values vs. list on the Core 2 Duo:
>
> System 1 (Core 2 Duo):
> $ gcc --version
> gcc (GCC) 4.2.3 20080114 (prerelease) (Debian 4.2.2-7)
>
> 15 major GCs
> System 2 (4-core Xeon):
> $ gcc --version
> gcc (GCC) 4.1.0 (SUSE Linux)
>
> 7547 major GCs
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
