Ticket #644 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

distutils/cpuinfo fails to detect some nocona based hardware

Reported by: jsbronder Owned by: cdavid
Priority: normal Milestone: 1.1.0
Component: numpy.distutils Version: devel
Keywords: Cc:

Description

Reference: https://bugs.gentoo.org/show_bug.cgi?id=183236

Basically, cpuinfo is failed to verify that the following cpuinfo is, in fact, nocona. This has been verified against numpy-1.0.4.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Genuine Intel(R) CPU                  @ 2.40GHz
stepping        : 4
cpu MHz         : 2400.130
cache size      : 4096 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
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 syscall nx lm
constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips        : 4802.95
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Attachments

numpy-1.0.4-nocona-cpuinfo.patch (1.1 KB) - added by jsbronder 3 years ago.
Based on gcc/config/i386/driver-i386.c, patch correctly identifies nocona.

Change History

Changed 3 years ago by jsbronder

Based on gcc/config/i386/driver-i386.c, patch correctly identifies nocona.

Changed 2 years ago by cdavid

This patch does not work for me (compilation fails). I added the part which fixes typo in linux kernel for sse3 (sse3 vs ssse3), though, in r4917.

I am looking at the problem for the correct nocona detection, now.

Changed 2 years ago by cdavid

  • owner changed from cookedm to cdavid
  • status changed from new to assigned

Ok, I guess I did something wrong, the patch does work. Included in r4920

Changed 2 years ago by cdavid

  • status changed from assigned to closed
  • resolution set to fixed

Changed 2 years ago by charris

What do you mean by typo? SSSE3 is a valid acronym that stands for Supplemental Streaming SIMD Extension 3.

Changed 2 years ago by cdavid

  • status changed from closed to reopened
  • resolution fixed deleted

Hm, ok... I thought it was a typo because on my machine, I do have sse, sse2 and ssse3, but no sse3. Well, that may not be a typo, but if you have ssse3, you have sse3, right ?

I find a bit strange that there is a discrepancy between sse 1/2 and 3. The software x86info does tell me that I have sse3, but not ssse3...

Changed 2 years ago by cdavid

Ok, I tried the last cpuinfo from there:

http://gwenole.beauchesne.info/en/projects/cpuinfo

This one tells me I have both sse3 and ssse3.

Changed 2 years ago by charris

Agreed, it's a bit strange. When I first saw it, I thought it was a typo too and googled it just to be sure. Wikipedia has a good, short description: http://en.wikipedia.org/wiki/SSSE3. It looks like ssse3 does imply sse3.

Changed 2 years ago by cdavid

  • status changed from reopened to closed
  • resolution set to fixed

I took a look at the linux kernel sources for the values put into /proc/cpuinfo (arch/x86/kernel/cpu/proc.c), and I don't see any sse3, only ssse3 (there is sse4 related flags, though). It *looks* like the real name of sse3 is pni:

http://gwenole.beauchesne.info/en/blog/2007/04/15/cpuinfo_1.0-prerelease

I committed the changes in r4931 and r4933 (has_sse3 returns true when pni is detected, a function has_ssse3, and detected nocona if both has_sse3 and !has_ssse3() are true). I think this should fix the issue for good.

Note: See TracTickets for help on using tickets.