Re: [eigen] cache queries bug? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] cache queries bug?
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sat, 26 Jun 2010 18:22:26 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Ghr5H6maVZxNNZ7OsLBaST18kPNuYOQ887PE1ghJIIM=; b=A+Dvcfbd71r6f2wg5aBW4YE4NfQcnv7c/2BVU8g+sfaa6AKskcC9KImE2nX9qiiebJ Tg5iX1bs+MxO+t+ttuVcrqZTy+l3Xrj5yEU9xAzvpwTiQaiNm07uo29q5X+ZfCPGdO6c 7QmYLgiMojkfCjg181MNnb49D5QSqjoJU3HC4=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Zsb30z3HI6u16exyASXt5ks+Um76FQyu7lliBzAiQPO26Jm+9ZHcJ/G6mpOnxiueM8 3GnQKRsa45KMH5AtE1jmp1uB4YLvFZVQysY6a8IfzcI9yvm+Ue/9FLTY3RfqJ5Qlk1xs YeWsSre4BKXcyvFQlReUDEC+BfvMU83dxt/K4=
Thanks!
You are allowed to sleep now (but not too long).
Benoit
2010/6/26 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> should be fine now.
>
> gael
>
> On Sun, Jun 27, 2010 at 12:03 AM, Ben Goodrich <bgokgm@xxxxxxxxxxxxxx> wrote:
>> Hi,
>>
>> On Sat, Jun 26, 2010 at 5: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
>>
>> I get no output in over 3 minutes of CPU time. On the core duo it
>> spits out all the info almost instantly, but I imagine you already
>> know what that says.
>>
>>> Also could you retry ./check cholesky ? I've also committed a small
>>> fix which could partially solve the issue.
>>
>> Still hanging on cholesky_2.
>>
>> Ben
>>
>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>