Numpy slow at vector cross product?

[BartC]

On 22/11/2016 02:44, Steve D'Aprano wrote:
> On Tue, 22 Nov 2016 05:43 am, BartC wrote:
>
>> The fastest I can get compiled, native code to do this is at 250 million
>> cross-products per second.

(Actually 300 million using 64-bit code.)

> Yes, yes, you're awfully clever, and your secret private language is so much
> more efficient than even C that the entire IT industry ought to hang their
> head in shame.

The 250M/300M timing was using C and gcc-O3.

This gives an indication of the upper limit of what is possible.

The suggestion was that the numpy solution, which was *one thousand time 
slower* than these figures, wouldn't be any faster if written in C.

I'm simply suggesting there is plenty of room for improvement. I even 
showed a version that did *exactly* what numpy does (AFAIK) that was 
three times the speed of numpy even executed by CPython. So there is 
some mystery there.

(FWIW my own compiled language manages 70M, and my interpreted language 
up to 3M. Poor, so I might look at them again next time I have to do 
loads of vector-products.)

> I'm only being *half* sarcastic here, for what its worth. I remember the
> days when I could fit an entire operating system, plus applications, on a
> 400K floppy disk, and they would run at acceptable speed on something like
> an 8 MHz CPU. Code used to be more efficient, with less overhead. But given
> that your magic compiler runs only on one person's PC in the entire world,
> it is completely irrelevant.

So you're saying that numpy's speed is perfectly reasonable and we 
should do nothing about it? Because, after all, it does a few extra 
clever things (whether the programmer wants them or not!).

And the way it is written is completely beyond reproach:

     msg = "incompatible dimensions for cross product\n"\
           "(dimension must be 2 or 3)"
     if (a.shape[0] not in [2, 3]) or (b.shape[0] not in [2, 3]):
         raise ValueError(msg)

So it is fine for msg to be bound to a string value here (and having to 
unbind it again when it returns) even though it will never be used again 
in a normal call. (Or having to test both a.shape[0] and b.shape[0] for 
inclusion in a list, expensive looking operations, when they are tested 
again anyway in the next few lines.)

-- 
Bartc