Boost logo

Boost :

Subject: Re: [boost] [Proposal] Adding CPUID Library in Boost
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2012-12-12 03:04:18


On 12/12/2012 07.45, Andrey Semashev wrote:
> On Fri, Dec 7, 2012 at 7:48 PM, Shakti Misra
> <shakti.misra.study_at_[hidden]> wrote:
>> Hi All,
>> Any interest in a cross platform CPU ID library? For a application I wanted
>> to get the CPUID mostly to check the SSE2 status. So I missed it in Boost.
>> So any interest for it?
>> I am currently evaluating the library
>> http://libcpuid.sourceforge.net/
>> This has a permissive license that I think can go with the Boost license.
>> I mailed the author also, although he does not use boost, he told he can
>> give any fixes or support needed.
>
> I would find this library useful, although I have already implemented
> a similar library for my closed project. I remember considering a few
> open alternatives when I was deciding whether to write my own
> implementation or not and I didn't find a suitable one. Libcpuid looks
> promising but apparently lacks CPU cache parameters detection (LLC
> size, cache line size and prefetch size would be very useful).
>
> I'm not sure that Boost implementation should be based on an external
> library. Libcpuid seems to be x86-only while I would prefer Boost
> library to be easily extensible to other architectures. I know not
> every architecture provides a cpuid-like operation but there probably
> are other means.
>
> I'm not particularly geared towards a header-only or compiled
> implementation. My main requirement is that it should be lightweight
> to include.

Does it make sense to add to a not platform dependent library a very
platform dependent feature?

Basically what I'm reading is: I have several version of the same
algorithm using different cpu features, after having spent a lot of time
to write/test all of them then now I need a cpuid provided by boost.

It's sound like eating an entire donkey and then leave the tail out.

Regards
Gaetano Mendola


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk