Re: [eigen] cache queries bug?

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

ok, don't worry I found an old laptop with same issue....

gael

On Sat, Jun 26, 2010 at 11:19 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> 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
>>
>>
>>
>