I'd prefer your first option - it's easy enough to check the info objects for 
existence of a particular attribute.

On Jan 29, 2014, at 1:12 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> Assuming people will confirm that ARM information isn't so simple, I wonder 
> where it's better to put architecture specific fields. With the proposed 
> solution, Intel and ARM would be different:
>     Architecture=x86_64
>     CPUVendor=GenuineIntel
>     CPUModel=Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
>     CPUModelNumber=45
>     CPUFamilyNumber=6
> and
>     Architecture=armv7l
>     CPUVendor=cardhu
>     CPUModel=ARMv7 Processor rev 9 (v7l)
>     CPUImplementer=0x41
>     CPUArchitecture=7
>     CPUVariant=0x2
>     CPUPart=0xc09
>     CPURevision=9 
> 
> We could also merge those arch-specific into a single generic one:
>     Architecture=x86_64
>     CPUVendor=GenuineIntel
>     CPUModel=Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
>     CPUModelNumber=family=6;model=45
> and
>     Architecture=armv7l
>     CPUVendor=cardhu
>     CPUModel=ARMv7 Processor rev 9 (v7l)
>     
> CPUModelNumber=implementer=0x41;architecture=7;variant=0x2;part=0xc09;revision=9
> 
> The drawback is that you'd have to parse CPUModelNumber to extract family and 
> model.
> 
> I am not sure which one is best.
> 
> Brice
> 
> 
> 
> 
> 
> Le 28/01/2014 00:09, Brice Goglin a écrit :
>> Hello,
>> I have some code that seems to work. Here's what it reports below. Does that 
>> look ok to you?
>> I had to modify quite a lot of things to make the parsing of /proc/cpuinfo 
>> more robust (the code is basically arch-specific now), so I am not sure 
>> we'll be able to backport this to OMPI.
>> Brice
>> 
>> 
>> * Sandy-Bridge Xeon E5 (Stampede)
>> CPUVendor=GenuineIntel
>> CPUModel=Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
>> CPUModelNumber=45
>> CPUFamilyNumber=6
>> * Old Nehalem-EX
>> CPUVendor=GenuineIntel
>> CPUModel=Intel(R) Xeon(R) CPU           E7540  @ 2.00GHz
>> CPUModelNumber=46
>> CPUFamilyNumber=6
>> * Itanium
>> CPUVendor=GenuineIntel
>> CPUModel=Dual-Core Intel(R) Itanium(R) Processor 9140N
>> CPUModelNumber=1
>> CPUFamilyNumber=32
>> * AMD
>> CPUVendor=AuthenticAMD
>> CPUModel=Dual Core AMD Opteron(tm) Processor 865
>> CPUModelNumber=33
>> CPUFamilyNumber=15
>> * MIC (Stampede)
>> CPUVendor=GenuineIntel
>> CPUModel=0b/01
>> CPUModelNumber=1
>> CPUFamilyNumber=11
>> 
>> 
>> 
>> 
>> Le 23/01/2014 19:50, Ralph Castain a écrit :
>>> That would be perfect! Thanks
>>> 
>>> On Jan 23, 2014, at 10:27 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
>>> 
>>>> Should be easy on Linux, sure.
>>>> The model name is already known as CPUModel in hwloc.
>>>> We should likely add CPUVendor (would be GenuineIntel or AuthenticAMD), 
>>>> CPUFamily (or CPUFamilyNumber if there's a name for these families?) and 
>>>> CPUModelNumber ?
>>>> 
>>>> Brice
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Le 23/01/2014 19:09, Ralph Castain a écrit :
>>>>> Hi folks
>>>>> 
>>>>> Looking at the current topology info, I see you capture the model name 
>>>>> for the socket, but not a couple of other key things Intel could use:
>>>>> 
>>>>> cpu family      : 6
>>>>> model           : 44
>>>>> model name      : Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz
>>>>> 
>>>>> 
>>>>> Both the cpu family and model are important to us - any issue with adding 
>>>>> them to the "infos" array?
>>>>> 
>>>>> Ralph
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> hwloc-devel mailing list
>>>>> hwloc-de...@open-mpi.org
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>>>> 
>>>> _______________________________________________
>>>> hwloc-devel mailing list
>>>> hwloc-de...@open-mpi.org
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> 
>> 
>> 
>> _______________________________________________
>> hwloc-devel mailing list
>> hwloc-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> 
> _______________________________________________
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

Reply via email to