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
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to