Re: [eigen] cache queries bug?

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

hi,

I've just added a small utility to help debugging this. So could you
please update your local copy, and send me back the output of the
following commands:

$ cd path_to_eigen/bench
$ g++ check_cache_queries.cpp -I .. && ./a.out

Also could you retry ./check cholesky ? I've also committed a small
fix which could partially solve the issue.

Thanks a lot for your help !

gael

On Sat, Jun 26, 2010 at 8:40 PM, Ben Goodrich <bgokgm@xxxxxxxxxxxxxx> wrote:
> Hi,
>
> If you want to postpone this until after the beta is released, that is fine.
>
> I have two machines, both with the "same" software (disregarding the
> bitness difference) with Debian unstable and g++ 4.4.4.
>
> One is a core duo desktop from a couple of years ago
>
> bgoodrich@Room320:/tmp/eigen/test$ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
> stepping        : 6
> cpu MHz         : 600.000
> cache size      : 2048 KB
> physical id     : 0
> siblings        : 2
> core id         : 0
> cpu cores       : 2
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf
> pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm
> tpr_shadow
> bogomips        : 3721.67
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:
>
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
> stepping        : 6
> cpu MHz         : 600.000
> cache size      : 2048 KB
> physical id     : 0
> siblings        : 2
> core id         : 1
> cpu cores       : 2
> apicid          : 1
> initial apicid  : 1
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf
> pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm
> tpr_shadow
> bogomips        : 3720.69
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:
>
> and one is a really old laptop (don't laugh)
>
> goodrich@X41Laptop:/tmp/eigen$ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 13
> model name      : Intel(R) Pentium(R) M processor 1.50GHz
> stepping        : 8
> cpu MHz         : 600.000
> cache size      : 2048 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts est
> tm2
> bogomips        : 1196.71
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 32 bits physical, 32 bits virtual
> power management:
>
> On the 32 bit laptop, I have encountered a problem where things like
>
> ./check.sh cholesky
>
> hang for minutes before I kill them, while on the 64 bit core duo
> desktop, this finishes in a few seconds.
>
> I bisected the problem to
>
> goodrich@X41Laptop:/tmp/eigen$ hg bisect --bad
> The first bad revision is:
> changeset:   3027:c93abfa8ffcb
> parent:      3023:c3b8e6edde53
> user:        Gael Guennebaud <g.gael@xxxxxxx>
> date:        Wed Jun 23 16:34:51 2010 +0200
> summary:     fix cache queries for non core2 CPU ;)
>
> But I don't know what to do from here because I don't really
> understand low-level issues like this.
>
> Thank you,
> Ben
>
>
>