[Numpy-discussion] Request for review: dynamic_cpu_branch

David Cournapeau cournape@gmail....
Thu Dec 25 23:47:08 CST 2008


On Tue, Dec 23, 2008 at 6:07 PM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
>
>
> On Mon, Dec 22, 2008 at 11:23 PM, David Cournapeau
> <david@ar.media.kyoto-u.ac.jp> wrote:
>>
>> David Cournapeau wrote:
>> > Charles R Harris wrote:
>> >
>> >> On Mon, Dec 22, 2008 at 10:40 PM, David Cournapeau <cournape@gmail.com
>> >> <mailto:cournape@gmail.com>> wrote:
>> >>
>> >>     On Tue, Dec 23, 2008 at 2:35 PM, Robert Kern
>> >>     <robert.kern@gmail.com <mailto:robert.kern@gmail.com>> wrote:
>> >>
>> >>     >
>> >>     > I think he meant that it can be discovered at runtime in
>> >>     general, not
>> >>     > at numpy-run-time, so we can write a small C program that can be
>> >> run
>> >>     > at numpy-build-time to add another entry to config.h.
>> >>
>> >>     But then we only move the problem: people who want to build
>> >> universal
>> >>     numpy extensions will have the wrong value, no ? The fundamental
>> >> point
>> >>     of my patch is that the value is set whenever ndarrayobject.h is
>> >>     included. So even if I build numpy on PPC, NPY_BIGENDIAN will not
>> >> be
>> >>     defined when the header is included for a file build with gcc -arch
>> >>     i386.
>> >>
>> >>
>> >> We can probably set things up so the determination is at run time --
>> >> but we need to be sure that the ABI isn't affected. I did that once
>> >> for an old project that needed data portability. In any case, it
>> >> sounds like a project for a later release.
>> >>
>> >
>> > It cannot work for numpy without breaking backward compatibility,
>> > because of the following lines:
>> >
>>
>> Actually, you could, by making the macro point to actual functions, but
>> that would add function call cost. I don't know if the function call
>> cost is significant or not in the cases where those macro are used,
>
> Exactly. Function calls are pretty cheap on modern hardware with good
> compilers, nor would I expect the calls to be the bottleneck in most
> applications. The functions would need to be visible to third party
> applications, however...

Would it be a problem ? Adding "true" functions to the array api,
while keeping the macro for backward compatibility should be ok, no ?

I also updated my patch, with another function PyArray_GetEndianness
which detects the runtime endianness (using an union int/char[4]). The
point is to detect any mismatch between the configuration endianness
and the "true" one, and I put the detection in import_array. The
function is in the numpy array API, but it does not really need to be
either .

cheers,

David


More information about the Numpy-discussion mailing list